ISO/IEC 27001 does not use the phrase penetration test. Annex A 8.8 requires management of technical vulnerabilities and A 8.29 requires security testing. ISO/IEC 27002:2022, the implementation guidance for those controls, names penetration testing directly, which is why certification bodies expect it at Stage 2.
The answer has two halves, and quoting only the first one is how this question gets answered wrongly.
The standard does not require a penetration test. ISO/IEC 27001:2022 does not contain the phrase. The guidance does. ISO/IEC 27002:2022, which provides implementation guidance for the same controls, names penetration testing explicitly. Certification bodies work from both.
Where the obligation comes from
ISO 27001 is structured as management system clauses plus an Annex A of controls. Two Annex A controls create the testing expectation.
A 8.8, management of technical vulnerabilities. Information about technical vulnerabilities in systems in use must be obtained, the organization's exposure evaluated, and appropriate measures taken. Obtaining information about your exposure is where testing enters.
A 8.29, security testing in development and acceptance. Security testing processes must be defined and implemented in the development lifecycle. This one is about testing before things ship rather than testing what already has.
Neither says how. ISO/IEC 27002:2022 fills that in, and its guidance for these controls references penetration testing among the methods that satisfy them.
Why the Statement of Applicability matters here
ISO 27001 lets you exclude a control if you justify it. In theory an organization could exclude A 8.8.
In practice, try writing that justification. The Statement of Applicability is the central document a certification auditor works from, and a justification for excluding management of technical vulnerabilities, from a software company, will not survive contact with a Stage 2 auditor. The flexibility is real, and it is not flexibility about this.
What the 2022 revision changed
The 2022 revision reorganized Annex A from 114 controls in 14 domains to 93 controls in four themes: organizational, people, physical and technological. Eleven controls were new, including threat intelligence, information deletion, data masking, and secure coding.
Old control numbers no longer map cleanly. A 12.6.1 in the 2013 version, technical vulnerability management, became A 8.8. If you are reading guidance written before the revision, check which numbering it uses, because a Statement of Applicability referencing 2013 numbers is an immediate flag.
Stage 1 and Stage 2
Certification runs in two stages. Stage 1 reviews documentation and readiness: does an ISMS exist, is it documented, is it auditable. Stage 2 audits the system in operation and leads to the certification decision.
Testing evidence is a Stage 2 artifact. The expensive order is to reach Stage 2 without it, take a nonconformity, and then commission a test under time pressure with a corrective action plan already filed. A major nonconformity blocks the certificate until it is resolved.
After certification, surveillance audits happen annually and recertification every three years. Testing becomes a recurring obligation rather than a one-off, and A 8.8 is about an ongoing process rather than a single event.
What a certification auditor asks
Not usually "show me your pen test". More often:
- How do you obtain information about technical vulnerabilities in your systems
- How do you evaluate your exposure when you learn of one
- What did you do about the last significant vulnerability that affected you
- How does security testing fit into your development lifecycle
A penetration test report answers the first one and contributes to the second. It does not answer the third or fourth on its own, which is the thing teams miss: A 8.8 describes a process, and a report filed once a year is evidence of an event. The process is what gets certified.
If you are doing both ISO 27001 and SOC 2
One test can usually serve both, with a caveat worth checking before you commission it. The ISO scope is defined by the ISMS scope statement. The SOC 2 scope is defined by the system description. They are written separately, by different people, for different purposes, and they rarely match exactly.
Compare the two documents before testing and scope to the union. Discovering a gap afterwards means either a second engagement or an awkward paragraph explaining why the artifact does not quite cover the system.
Questions people ask
Does ISO 27001 require a penetration test?
ISO/IEC 27001:2022 does not use the phrase. Annex A 8.8 requires management of technical vulnerabilities and A 8.29 requires security testing in development and acceptance. ISO/IEC 27002:2022, the implementation guidance for those controls, names penetration testing explicitly, so certification bodies expect testing evidence at Stage 2.
Can I exclude Annex A 8.8 from my Statement of Applicability?
In theory any Annex A control can be excluded with justification. In practice a software company justifying the exclusion of technical vulnerability management will not get that past a Stage 2 auditor.
When does the ISO 27001 auditor ask for the penetration test?
At Stage 2, which audits the management system in operation. Arriving at Stage 2 without testing evidence risks a nonconformity, and a major nonconformity blocks certification until resolved.
Does one penetration test cover both ISO 27001 and SOC 2?
Usually, if the scope covers both the ISMS scope statement and the SOC 2 system description. Those two documents are written separately and rarely match exactly, so compare them before commissioning the test rather than after.