ISO 27001 Penetration Testing: What Annex A Requires
Like SOC 2, ISO 27001 doesn't contain the literal phrase "penetration test." Unlike SOC 2, its controls give you two specific Annex A clauses to point at, and a broader ISMS structure that expects you to define your own risk-based testing cadence rather than following one auditors hand you. Here's what that actually means in practice.
Where penetration testing fits in ISO 27001:2022
ISO/IEC 27001:2022's Annex A was restructured from the 2013 version's 14 domains into four themes, and two controls are the ones penetration testing is evidence for:
- A.8.8 — Management of technical vulnerabilities. Requires that information about technical vulnerabilities be obtained in a timely fashion, the organization's exposure evaluated, and appropriate measures taken. Penetration testing is the exploitation-led way to genuinely evaluate that exposure rather than infer it from a vulnerability database.
- A.5.36 — Compliance with policies, rules and standards for information security. Requires regular review that security policies and technical standards are actually being followed. A penetration test is a direct, empirical check of whether your stated security controls hold up against real testing.
Neither clause names "penetration test" as the specific mechanism — this is the same structural pattern as SOC 2, where the standard states an outcome and leaves the method to you, and penetration testing has become the widely accepted way of satisfying it. Certification bodies broadly expect to see it as part of a functioning ISMS, and its absence is a common finding during external audits, particularly for organizations handling sensitive data or operating internet-facing systems.
Cadence: risk-based, not fixed by the standard
Unlike PCI-DSS, ISO 27001 doesn't specify "annually" or any other fixed interval. Cadence is meant to be risk-based and defined within your own ISMS documentation — typically your vulnerability management or technical testing policy — proportional to the sensitivity of what you're protecting and the rate of change in your environment. In practice, most organizations land on annual testing as the working baseline, with more frequent testing for higher-risk systems or those under rapid development, because that's what a reasonable risk assessment tends to conclude and what auditors are accustomed to seeing.
The trap here is treating "risk-based" as license to skip testing indefinitely. An auditor reviewing your ISMS will ask how you arrived at your stated cadence — if the honest answer is "we haven't actually assessed the risk, we just haven't tested," that's a finding, not a defensible risk-based decision.
"ISO 27001 trusts you to set your own testing cadence. It does not trust you to set it to 'never.'"
Vulnerability assessment vs. penetration test under A.8.8
A.8.8 covers vulnerability management broadly, which technically includes both automated vulnerability assessment and exploitation-led penetration testing as complementary activities, not interchangeable ones. A vulnerability assessment catalogs known weaknesses at scale, often through automated scanning; a penetration test actively attempts exploitation to prove real impact. Auditors generally expect to see genuine testing evidence behind the broader vulnerability management process A.8.8 describes — a scan report alone tends to read as incomplete evidence for a control this central to the standard.
How ComplyArmor supports ISO 27001 evidence
ComplyArmor's Smart PTaaS maps every validated finding to ISO 27001 Annex A control language, alongside OWASP Top 10, ASVS, PCI-DSS and SOC 2 — see our full compliance mapping. Continuous testing through Smart PTaaS gives you a defensible answer to the "how did you determine your testing cadence" question auditors ask, since coverage runs on an ongoing basis rather than a single annual snapshot you have to justify was frequent enough.
Frequently asked questions
Does ISO 27001 require penetration testing?
Not by that exact name, but it's the practical expectation. ISO 27001:2022 Annex A control 8.8 requires management of technical vulnerabilities, and A.5.36 requires review of compliance with security policies and standards. Certification bodies and auditors widely treat penetration testing as the appropriate evidence for both, even though "penetration test" isn't the literal wording used in the standard.
How often does ISO 27001 require penetration testing?
The standard doesn't mandate a fixed interval — cadence should be risk-based and defined within your own ISMS, typically documented in a vulnerability management or testing policy. In practice, annual testing is the common baseline auditors expect to see, with more frequent testing justified for higher-risk or frequently-changing systems.
What's the difference between a vulnerability assessment and a penetration test for ISO 27001?
A vulnerability assessment identifies and catalogs weaknesses, often through automated scanning, without proving they're exploitable. A penetration test actively attempts exploitation to demonstrate real impact. Annex A 8.8 covers vulnerability management broadly; auditors generally want to see genuine exploitation-led testing as part of how that management process is validated, not scanning alone.
Does the ISO 27001 auditor check the penetration test report directly?
Yes, typically as part of the surveillance or certification audit, the auditor reviews evidence that vulnerability management and compliance review activities (Annex A 8.8 and A.5.36) are actually operating — which usually means examining the scope, findings, and remediation status of your most recent penetration test.
Can an internal team run the ISO 27001 penetration test?
ISO 27001 doesn't strictly require an external tester, but independence from the team responsible for building and operating the tested systems is important for the result to be credible evidence within your ISMS. Many organizations use external testers specifically to demonstrate that independence clearly to auditors.
If your ISMS documentation states a testing cadence you can't actually point to evidence for, that's worth resolving before your next surveillance audit finds it first.