ISO 27001 penetration testing requirements 2026 — Annex A controls + auditor expectations

Why ISO 27001 makes pentesting the de-facto default

The 2022 update to ISO/IEC 27001 reorganised Annex A from 14 control families into 4 themes (Organisational, People, Physical, Technological) with 93 controls total. Three Technological controls explicitly imply penetration testing as the evidence path:

• A.8.8 — Management of technical vulnerabilities. Information about technical vulnerabilities of information systems in use shall be obtained, evaluated, and appropriate measures taken.
• A.8.29 — Security testing in development and acceptance. Security testing processes shall be defined and implemented in the development life cycle.
• A.5.36 — Compliance with policies, rules and standards for information security. Compliance with the organisation's information security policy + topic-specific policies + standards shall be regularly reviewed.

Plus Clause 9.1 (Monitoring, measurement, analysis and evaluation) of the main body — covered below.

Auditors interpret "vulnerabilities of information systems in use" + "security testing processes" + "regularly reviewed compliance" as a chain that requires periodic empirical testing. Pentest is the canonical method. Vulnerability scanning alone (Nessus / Qualys / Tenable) is increasingly insufficient — auditors want exploitation evidence, not just CVE matching.

The Annex A controls that imply pentest evidence — detail

A.8.8 — Management of technical vulnerabilities

Pentest evidence directly satisfies the "obtained, evaluated, appropriate measures taken" structure. Each finding includes obtained (what was discovered), evaluated (CVSS scoring + business impact), and appropriate measures (remediation guidance + retest result).

A.8.29 — Security testing in development and acceptance

Pre-release / per-release pentests document the "in development" cycle. SQUR's per-engagement model fits this directly — run a pentest at each significant release, build a finding-trend chart over the SDLC.

A.5.36 — Compliance with policies, rules and standards

The "regular review" obligation is satisfied by recurring pentest cadence (annual minimum, quarterly or per-release for entities with active development).

Indirect coverage from other Annex A controls

• A.8.7 — Protection against malware: partially evidenced when pentest scope includes malware-detection bypass scenarios.
• A.8.23 — Web filtering: partially evidenced by pentest's URL-based access-control findings.
• A.8.24 — Use of cryptography: directly evidenced by pentest's cryptography-category findings (weak TLS, deprecated ciphers, missing HSTS).
• A.5.7 — Threat intelligence: the pentest report's finding-categories serve as input to the entity's threat-intelligence process.

Clause 9.1 — performance evaluation

The main body of ISO 27001:2022 requires the organisation to determine "what needs to be monitored and measured" and "the methods for monitoring, measurement, analysis and evaluation." Penetration testing is the most common method for measuring the effectiveness of technical controls.

Auditors look for: written measurement methodology (the entity's pentest scoping policy) + recurring evidence (engagement history) + analysis (finding-trend chart) + management review (Clause 9.3 evidence that pentest results feed the leadership review cycle).

What Stage 1, Stage 2, and surveillance audits look for

Stage 1 audit

Documentation review. Auditor checks the entity's ISMS scope, Statement of Applicability, risk treatment plan, and pentest scoping policy. Doesn't run findings analysis yet — looks for the documented framework.

Stage 2 audit

Implementation review. Auditor samples evidence from the past 12 months. Expected pentest artefacts: most recent pentest report + remediation tracking log + retest results for high-severity findings + Clause 9.3 management review minutes referencing pentest findings.

Surveillance audit (annual)

Follow-up. Auditor checks that the pentest cadence has been maintained, new findings have been addressed, and remediation isn't accumulating into a backlog. Pentest reports from each cycle are sampled.

Recertification audit (every 3 years)

Full re-audit. Same evidence requirements as Stage 2 but covering the full 3-year cycle. Finding-trend chart becomes important here — auditors want to see remediation closing faster than new vulnerabilities accumulate.

Cadence — annual minimum, often more

ISO 27001 doesn't prescribe pentest frequency. Auditor expectations 2026:

• Annual minimum for all certified entities, regardless of scope.
• Per-release for entities with active development of in-scope systems. Pentest after every significant architecture change, third-party integration, or feature release.
• Post-incident retesting after any significant security incident.
• Targeted on net-new functionality added between full-scope engagements.

The €1,995-per-engagement SQUR model exists to make quarterly + per-release viable for entities with limited security budget. Boutique-firm pricing (€10K–€30K per engagement) often forces annual-only cadence, which leaves 9-12 months of release-cycle drift between engagements.

What the pentest report should contain (auditor checklist)

1. Scope statement — explicit in-scope + out-of-scope assets, methodology, period, tooling.
2. Findings with CVSS — per finding: description, reproduction steps, impact, affected asset, evidence artefact.
3. Risk treatment alignment — finding severity maps to the entity's risk-treatment plan thresholds.
4. Remediation guidance — concrete fix per finding, effort estimate, compensating control if applicable.
5. Retest evidence — confirmation per closed finding.
6. Statement of Applicability (SoA) alignment — finding categories cross-reference the entity's SoA controls.
7. Executive summary — for Clause 9.3 management review.

SQUR reports include all of the above by default. The SoA alignment column is optional — added by request for entities going through ISO 27001 certification.

Intersection with NIS2, DORA, SOC 2

• NIS2: ISO 27001 certification is increasingly cited as evidence of "appropriate and proportionate" Article 21 measures. Not a substitute for the Art. 21 submission itself, but strong supporting evidence.
• DORA: ISO 27001 certification is one path to demonstrating the ICT risk management framework required by Article 6. The pentest used for ISO 27001 evidence often satisfies DORA Article 24 simultaneously.
• SOC 2: SOC 2 Type II reports often cite ISO 27001 evidence. The pentest used for both is typically the same engagement; the report sections cross-reference both control frameworks.

For EU SMEs pursuing multiple compliance regimes simultaneously, a single quarterly SQUR pentest produces evidence usable across ISO 27001 + NIS2 + DORA + GDPR Article 32. Cost-efficient compared to running separate engagements per regime.