ISO 27001: How Penetration Testing Helps You Comply

Where pentest sits inside ISO 27001

ISO 27001 does not include a control labeled "penetration testing". The standard sets requirements for an Information Security Management System (ISMS) and references Annex A controls — most of which are technical, organizational, or process controls written at a principle level. Penetration testing is the operational practice that supports several of those controls, particularly the ones around technical vulnerability management.

The 2022 revision of ISO 27001 reorganized Annex A from 114 controls in 14 sections to 93 controls in four themes. The substantive expectations around vulnerability management and security testing did not change materially — the framing did.

Annex A controls pentest evidence supports

Control	Theme	What pentest contributes
A.8.8 — Management of technical vulnerabilities	Technological	Identifies vulnerabilities and tracks remediation; the primary control pentest supports.
A.5.7 — Threat intelligence	Organizational	Adversarial findings inform threat modeling and intelligence activities.
A.8.16 — Monitoring activities	Technological	Pentest can validate detection and monitoring effectiveness.
A.8.29 — Security testing in development and acceptance	Technological	Testing before production release maps to this control.
A.5.36 — Compliance with policies, rules, and standards	Organizational	Periodic third-party assessment supports the compliance-review element.
A.8.25 — Secure development life cycle	Technological	Pentest of pre-production builds supports the SDLC control.

If you are mapping a single engagement to multiple controls, the report should call out each control explicitly rather than leaving the cross-walk for your ISMS team to do later.

Aligning pentest scope with the ISMS

Three principles keep the engagement audit-ready:

Match (or exceed) the ISMS scope

If your ISMS scope statement covers a customer-facing SaaS product plus its supporting infrastructure, your pentest scope should cover the same systems. Pentest scope can be broader than ISMS scope; it should not be narrower.

Document the scope statement explicitly

The pentest report's scope section should reference the ISMS scope statement. Auditors compare these two documents during certification and surveillance audits — making the alignment explicit saves you from follow-up questions.

Cover the technical and integrative surfaces

For most ISMSes, that means web/API testing of the customer-facing product, network/cloud testing of the supporting infrastructure, and authenticated testing where multi-tenant or role-rich behavior is involved.

Cadence under ISO 27001

Annual penetration testing aligned with surveillance audits is the de facto standard. Most certified organizations time their pentest so the report and retest land at least four weeks before the surveillance audit window.

Beyond the annual cadence, the standard expects that significant changes trigger renewed testing. The "significant change" trigger is where most teams underestimate their cadence: a new authentication system, a new tenant model, a new region, or a new partner integration generally warrants a fresh pentest within the relevant scope.

What the certification auditor looks for in the report

1. Scope statement that matches or exceeds the ISMS scope.
2. Methodology aligned to a recognized standard (NIST 800-115, OWASP, OSSTMM, PTES).
3. Findings with severities using a documented rating method.
4. Evidence per finding sufficient to reproduce.
5. Remediation status for each finding — closed (with retest evidence), open (with planned remediation date), accepted (with documented risk acceptance).
6. Annex A control mapping for each finding.
7. Retest evidence dated before audit field work begins.

2013 vs 2022 — what actually changed

If your ISMS is still on ISO 27001:2013, you should plan transition to 2022 (the deadline for transition was October 31, 2025). For pentest scoping purposes, the practical changes are:

• Control numbering changed from 14 sections / 114 controls to four themes / 93 controls.
• Eleven new controls in 2022, including A.5.7 (threat intelligence), A.8.9 (configuration management), A.8.10 (information deletion), A.8.11 (data masking), A.8.12 (data leakage prevention), A.8.16 (monitoring), A.8.23 (web filtering), A.8.28 (secure coding), and A.5.23 (cloud services).
• Pentest reports should map to 2022 control numbering if you have transitioned.