ISO 27001:2022 contains 93 Annex A controls, and not one of them says "penetration test." Like SOC 2 and HIPAA, the standard is outcome-based: it tells you to manage technical vulnerabilities and to test security during development, then leaves the method to you. Penetration testing is not a named requirement, but it is the most credible evidence you can put in front of an ISO auditor that controls 8.8 and 8.29 are operating. Skip it and you will struggle to show your information security management system (ISMS) does what your Statement of Applicability claims.
This post maps penetration testing to the specific ISO 27001:2022 controls it supports, explains how the 2022 revision changed the relevant Annex A structure, covers the cadence and scope auditors expect, and clarifies where a pentest is evidence versus where it is a hard requirement (it is the former).
No, ISO 27001 does not explicitly require a penetration test. The 2022 standard and its Annex A controls never name penetration testing as a mandatory activity.
What ISO 27001 requires is a working information security management system: you assess risks, select controls (documented in your Statement of Applicability), and demonstrate those controls operate effectively. A penetration test is the standard way to provide evidence for the technical controls related to vulnerability management and secure development. So while no auditor can fail you for "not having a pentest" against a named clause, an auditor can and will raise a nonconformity if you cannot show that controls 8.8 and 8.29 are implemented and effective, and a pentest is usually how you show it. The honest framing is that ISO 27001 sits between PCI DSS and HIPAA on this spectrum: more demanding than HIPAA because the Annex A controls are concrete and the auditor checks each one you marked applicable in your Statement of Applicability, but less prescriptive than PCI DSS because it never dictates a method or cadence. You decide how to satisfy 8.8 and 8.29; you just have to prove the decision works.
Penetration testing most directly supports Annex A control 8.8 on technical vulnerability management and control 8.29 on security testing in development and acceptance. These are the controls an auditor will tie your testing evidence to.
The pentest report becomes an artifact in your ISMS evidence trail, and the cleanest reports tag each finding to the control it evidences. A misconfigured S3 bucket maps to 8.9; an outdated, vulnerable library maps to 8.8; an injection flaw caught in a pre-release build maps to 8.29. For what a defensible report should contain, see the key elements of a penetration testing report.
The 2022 revision reorganized Annex A from 114 controls in 14 domains down to 93 controls in 4 themes, and merged the old vulnerability management control into the current 8.8. The substance for testing did not weaken; it was renumbered and consolidated.
Under ISO 27001:2013, technical vulnerability management lived in control 12.6.1. In the 2022 version it became control 8.8 within the Technological controls theme. Control 8.29 on security testing in development and acceptance was clarified and given its own identity. Eleven new controls were introduced in 2022 (such as 5.7 threat intelligence, 8.16 monitoring activities, and 8.28 secure coding), several of which a pentest can help evidence. If your ISMS was certified against the 2013 version, the transition deadline of 31 October 2025 has passed, so your testing evidence and certificate should already map to the 2022 control numbers. Practically, update your Statement of Applicability and control mappings so your pentest report references 8.8 and 8.29, not the retired 12.6.1. In our experience auditors notice when a report still cites 2013 numbering: it signals the evidence trail was not refreshed for the new version, even when the testing itself was sound.
ISO 27001 specifies no testing frequency. The standard requires that controls remain effective and that you perform internal audits and management reviews, which in practice means testing on a cycle that keeps your evidence current, typically annually.
Most certified organizations run a penetration test at least once a year, timed to feed the surveillance audit, plus an additional test after significant changes to in-scope systems. Clause 9 (performance evaluation) and Clause 10 (improvement) push you toward regular, evidence-producing activity rather than a one-time test, so a stale two-year-old report is a weak position at a surveillance audit. The certification rhythm reinforces this: after the initial Stage 1 and Stage 2 audits, you face annual surveillance audits and a full recertification every three years, so an annual pentest naturally feeds each surveillance cycle with current evidence. Aligning the pentest to your ISMS audit calendar keeps the evidence fresh when the auditor asks for it. Our guide on penetration testing frequency covers setting a risk-based interval, and how to prepare for a penetration test helps you align scope with your ISMS boundary.
An ISO auditor asks to see the pentest report, then asks how it connects to your risk assessment, your Statement of Applicability, and your risk treatment plan. They are auditing the management system, not the test, so the test on its own proves little.
In a Stage 2 certification audit or a surveillance audit, the auditor typically wants the dated report mapped to controls 8.8 and 8.29, evidence that findings entered your risk register, the risk treatment decisions (accept, treat, transfer) under Clause 6.1.3, and the records that close the loop under Clause 10 corrective action. In our experience the most common nonconformity here is not a missing pentest, it is a pentest that lives in a PDF nobody fed back into the ISMS. The findings never reached the risk register, no treatment was recorded, and there is no retest, so the auditor cannot see the controls operating. A scoping example: if your ISMS boundary is your SaaS product and its supporting AWS infrastructure, scope the production app, its APIs, the cloud account, and the CI/CD pipeline that builds it (8.29 territory), but not the corporate finance system that sits outside the boundary in your scope statement.
Scope follows your defined ISMS boundary, and the evidence an auditor wants is a methodology-driven report with rated findings tied to risk treatment and remediation. The pentest must connect back to your risk assessment, not float as a standalone document.
Define scope to match the assets and systems inside your ISMS, the same boundary in your scope statement and risk assessment. Use recognized methodologies so the report is defensible: OWASP WSTG and ASVS for applications, the OWASP API Security Top 10 for APIs, and NIST SP 800-115 or PTES for engagement structure. Rate findings with CVSS so severity feeds your risk treatment plan under Clause 6.1.3, with EPSS or CISA KEV context where it sharpens prioritization. The auditor's real test is the loop: did the pentest find issues, did you assess them as risks, did you treat them, and can you show the retest? Because ISMS environments evolve continuously, pairing the annual test with ongoing validation through agentic pentesting keeps your 8.8 evidence current between surveillance audits. For the testing fundamentals behind all of this, see what penetration testing is.
