ISO 27001 sits in an honest middle ground that neither SOC 2 nor PCI DSS occupies. It is more demanding than HIPAA on technical controls because each Annex A control you mark applicable in your Statement of Applicability is concrete and the auditor checks it. It is less prescriptive than PCI DSS because it never dictates a method or a cadence. None of its 93 Annex A controls contains the words "penetration test," yet a pentest is the most credible single artifact you can put in front of an auditor to show controls 8.8 and 8.29 are operating.
That gap is where teams stumble: they buy a pentest, file the PDF, and never feed it back into the ISMS, then take a nonconformity at the surveillance audit for an evidence trail that does not close. This post maps testing to the specific 2022 controls it evidences, traces the 2013 lineage so your numbering is current, scopes a SaaS-plus-AWS-plus-CI/CD environment, shows the surveillance-audit document request, and walks the loop an auditor actually wants to see close.
No. 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: assess risks, select controls (documented in your Statement of Applicability), and demonstrate they operate effectively.
A pentest is the standard way to evidence the technical controls for vulnerability management and secure development. No auditor can fail you for "not having a pentest" against a named clause, but an auditor can and will raise a nonconformity if you cannot show controls 8.8 and 8.29 are implemented and effective, and a pentest is usually how you show it. So the honest framing: ISO 27001 does not mandate a pentest, but if you marked 8.8 and 8.29 applicable in your SoA (almost everyone does), you have committed to evidencing them, and assumption-based answers do not survive a Stage 2 or surveillance audit.
A penetration test most directly evidences Annex A 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance). Knowing the lineage matters because stale numbering signals a stale evidence trail.
The 2022 revision reorganized Annex A from 114 controls in 14 domains down to 93 controls in 4 themes and introduced 11 new controls. Auditors notice when a report still cites the 2013 12.6.1 numbering: it suggests the evidence was not refreshed for the new version, even when the testing itself was sound. The cleanest reports tag each finding to the control it evidences. For what a defensible report contains, see the elements covered in the major testing standards.
If your certificate or your testing evidence still references the 2013 control numbers, you are behind. The transition period for organizations certified against ISO 27001:2013 ended on 31 October 2025. After that date, certificates map to ISO 27001:2022, and your evidence should too.
Practically, that means three things. Update your Statement of Applicability and control mappings so your pentest report references 8.8 and 8.29, not the retired 12.6.1. Confirm your risk treatment plan and risk register use the 2022 control identifiers. And make sure the 11 new 2022 controls you marked applicable, particularly 5.7 threat intelligence, 8.16 monitoring activities, 8.23 web filtering, and 8.28 secure coding, have evidence behind them, several of which a pentest can help supply. The substance of the testing requirement did not weaken in 2022; it was renumbered and consolidated. An auditor cares that the paper trail caught up.
Scope follows your ISMS boundary, the same boundary in your scope statement and risk assessment. For a typical SaaS company that boundary spans three layers most teams test unevenly: the running product, the cloud account beneath it, and the pipeline that builds and ships it. 8.29 specifically pulls the pipeline in.
Map the boundary to assets and to the controls each asset evidences, then keep that mapping as your evidence index:
ISMS scope + control evidence index (SaaS / AWS / CI-CD)
ASSET IN/OUT EVIDENCES
app.product.io (prod web) IN A.8.8, A.8.29
api.product.io (REST/GraphQL) IN A.8.8, A.8.29
AWS prod account (VPC/IAM/S3) IN A.8.8, A.8.9 (config)
GitHub Actions CI/CD IN A.8.29, A.8.28 (secure coding)
-> SAST/dep-scan gate A.8.8 (known-vuln libs)
staging env (prod-like) IN A.8.29 (pre-acceptance)
corp finance system OUT outside ISMS scope stmt
RETIRED REF: do NOT cite A.12.6.1 (2013) -> now A.8.8The CI/CD line is the one teams underweight. 8.29 wants security testing before acceptance into production, so a pipeline gate (dependency scanning, SAST, and a security test stage) is itself control evidence, not just engineering hygiene. The corporate finance system is out because your scope statement places it outside the ISMS, not because it is unimportant. For the cloud layer, our AWS penetration testing guide and cloud security posture checklist cover what "in scope" actually means at the IAM and config level.
An auditor asks to see the 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 report on its own proves little. In a Stage 2 or surveillance audit the request reads:
ISO 27001 audit evidence request
[1] Penetration test report, dated, mapped to A.8.8 / A.8.29
[2] Statement of Applicability showing 8.8, 8.29 applicable
[3] Risk register entries created from the findings
[4] Risk treatment decisions (treat/accept/transfer) - Clause 6.1.3
[5] Corrective action / closure records - Clause 10
[6] Retest evidence for treated findings
[7] Evidence the CI/CD security gate runs - A.8.29The most common nonconformity 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 (item 3 missing), no treatment was recorded (item 4 missing), and there is no retest (item 6 missing), so the auditor cannot see the controls operating. The bar is the loop, not the document. A clean evidence trail walks the auditor from item 1 straight through to item 6.
The auditor's real test is whether the pentest connects back to the management system: did it find issues, did you assess them as risks, did you treat them, and can you show the retest? Use recognized methodologies so the report is defensible (OWASP WSTG and ASVS for apps, the OWASP API Security Top 10 for APIs, NIST SP 800-115 or PTES for structure) and 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 priority.
On a recent ISO 27001 surveillance prep for a SaaS vendor, the prior year's pentest had flagged a vulnerable, outdated image-processing library, a textbook 8.8 finding. It was fixed in code, but the finding never entered the risk register and there was no treatment record, so on paper control 8.8 had no evidence of operating during the period. We reconstructed the trail (register entry, treatment decision, retest) before the surveillance audit, which turned a likely nonconformity into a clean control. The mapping below shows how findings land on controls. Because ISMS environments evolve continuously, pairing the annual test with ongoing validation through agentic pentesting keeps your 8.8 evidence current between surveillance audits, rather than letting it age into a stale snapshot.