Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Does ISO 27001 require a penetration test?
Last verifiedISO/IEC 27001:2022 does not say “penetration test.” It names technical vulnerability management (A.8.8), security testing in development and acceptance (A.8.29), and secure development (A.8.25). A pen test is one way to evidence those controls. This page is not legal advice.
ISO 27001 testing expectations, last verified 10 September 2026 against ISO/IEC 27001:2022 Annex A (A.8.8, A.8.29, A.8.25) and ISO/IEC 27002:2022 guidance. “Pen test” is not the ISO wording. Certifier practice is not the clause. Not legal advice. Not a determination that YOU need certification.
Normative clause versus certifier habit
Audience: a security lead pursuing ISO/IEC 27001:2022. This page is not legal advice. Kind of text: Annex A controls are normative if they appear in YOUR Statement of Applicability. ISO/IEC 27002:2022 is guidance on how to implement them. A certifier who “always wants to see a pen test” is certifier practice, not a rewrite of A.8.8. ShipReady Metrics recommendation: map whatever testing you do to the SoA with honest coverage — the product does not issue a certificate.
Annex A control-mapping table
Last verified 10 September 2026. Not YOUR SoA. Not legal advice.
| Control | What ISO/IEC 27001:2022 names | How a pen test may evidence it | Kind of text |
|---|---|---|---|
| A.8.8 Technical vulnerability management | Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure evaluated, and appropriate measures taken. | A scoped test is one evaluation input. Scanning and SCA also support this control. | Normative if in the SoA. Wording is not “pen test.” |
| A.8.29 Security testing in development and acceptance | Security testing processes shall be defined and implemented in the development life cycle. | SAST, DAST, acceptance tests, and a pen test can all be part of that process. One annual test alone may be thin if SDLC testing is absent. | Normative if in the SoA. |
| A.8.25 Secure development life cycle | Rules for the secure development of software and systems shall be established and applied. | Testing gates are part of those rules. A pen test does not by itself create a secure SDLC. | Normative if in the SoA. |
Certifier-expectation note
Some certification bodies ask to see an independent penetration test for internet-facing systems. That is certifier practice. ISO/IEC 27002:2022 discusses vulnerability management and testing as guidance, still without making “annual pen test” the clause title. Document why YOUR mix of scanning, SDLC testing, and (if used) independent testing meets A.8.8 and A.8.29. Last verified 10 September 2026. Not legal advice.
What to do now
Operational steps. Last verified 10 September 2026. Not legal advice.
- Open YOUR Statement of Applicability. If A.8.8 or A.8.29 is excluded, write the justification — this page does not write it.
- Map current SAST/DAST/SCA and any independent test to those controls. Do not claim a pen test if you only have a scan.
- Keep documented information per Clause 7.5. Open the evidence-retention guide on this site.
- An ISO 42001 versus EU AI Act comparison guide is not on this site yet. Naming it is not a link. The ISO 42001 and EU AI Act framework pages on this site are live.
Checklist
Question list. Not a certification decision. Not legal advice.
- Are A.8.8, A.8.29, and A.8.25 in the SoA?
- What evidence will the auditor sample for each?
- Is SDLC testing actually running, or only an annual PDF?
- Does the controls crosswalk show density, not a fake “certified” badge?
Where this shows up in ShipReady Metrics
ISO 27001 evidence collection and the controls crosswalk (density-honest) map testing artifacts. Vulnerability ingest is a technical-vulnerability evidence source. The product does not issue ISO certification, does not replace an independent pen test, and does not determine that ISO/IEC 27001 applies to YOU.
Primary sources (last verified 10 September 2026)
ISO/IEC 27001:2022 Annex A A.8.8, A.8.29, A.8.25 (normative if in the SoA). ISO/IEC 27002:2022 (guidance). Those texts do not use “penetration test” as the control title. Not legal advice.