ISO 27001 doesn't name penetration testing as a mandatory control, but it effectively requires it. Annex A A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) require you to identify, evaluate and act on technical vulnerabilities — and pentesting is the recognised way to do it. Testing also feeds the Clause 6 risk assessment at the heart of the ISMS. Certification auditors expect to see it. There's no fixed frequency; the accepted baseline is annual plus after significant change, justified by your risk assessment. The evidence that satisfies auditors is a recent report plus a tracked remediation record showing findings were assessed, actioned and closed. Detail below; map all your obligations with the requirements-by-framework guide.
// 01 The “it's not required” myth
Search the ISO 27001 text for “penetration testing” and you won't find a control that mandates it by name. Some teams stop there and conclude they can skip it. That's a misread of how the standard works. ISO 27001 is risk-based and outcome-focused: it tells you what to achieve — identify and manage technical vulnerabilities — and leaves the how to you. Penetration testing is the widely recognised, auditor-accepted way to achieve that outcome. So while it's technically true that no clause says “you must pentest,” it's practically true that you can't demonstrate the required outcome without testing. Certification auditors know this, and they look for it.
// 02 The Annex A controls that drive testing
Technical vulnerabilities
Obtain, evaluate and act on information about technical vulnerabilities in a timely way — pentesting is the primary means.
Security testing
Define and perform security testing in development and acceptance — testing before and as systems go live.
Secure development
Secure development lifecycle controls that penetration testing helps validate.
Risk & evaluation
The risk assessment and performance evaluation that testing feeds with objective data.
The key insight: one good penetration test provides evidence for several controls at once, and — more importantly — feeds the risk assessment that is the spine of the whole ISMS.
// 03 Testing feeds the risk assessment
This is what auditors really care about. ISO 27001 lives or dies on its risk assessment and treatment: you identify risks, decide how to treat them, and demonstrate the ISMS actually works. A penetration test injects objective, real-world data into that loop — here are the actual exploitable weaknesses in your environment, ranked by impact. Without testing, your risk assessment is theoretical; with it, you can show risks were identified from real evidence, treated through remediation, and re-verified. That closed loop — identify → evaluate → treat → verify — is exactly the managed process the standard demands, and it's why a test filed and forgotten counts for little while a test that drives your risk treatment plan counts for a lot.
// 04 How often, and how auditors view it
ISO 27001 sets no fixed frequency — it expects a risk-based cadence. The widely accepted baseline that keeps auditors comfortable is an annual penetration test plus testing after any significant change; higher-risk systems and frequent-release teams test more often. What the auditor assesses is whether your cadence is justified by your risk assessment and consistently followed — not whether it hits a magic number. A defensible position is: “our risk assessment sets this frequency, here are the reports, here's the remediation record.” Compare the approach with the more prescriptive regimes in requirements by framework — ISO trusts your risk process where PCI DSS hard-codes the interval.
// 05 The evidence that satisfies the auditor
Bring three things to the audit. First, a recent report from a competent tester covering the systems in your ISMS scope — not a different asset, not a bare scan. Second, evidence the findings were assessed for risk and fed into your risk treatment plan — showing the test connects to the ISMS, not sitting in a drawer. Third, proof that significant findings were remediated and retested, closing the loop. The auditor is verifying a managed process: identified, evaluated, actioned, closed. A report plus a tracked remediation record beats a thicker report with no follow-through every time. Learn to present it well with how to read a pentest report and building a remediation plan.
// 06 Frequently asked questions
Does ISO 27001 require penetration testing?
Not by name, but effectively yes. Annex A A.8.8 (technical vulnerabilities) and A.8.29 (security testing) require you to identify, evaluate and act on technical vulnerabilities, and pentesting is the recognised way to satisfy them and feed the risk assessment. Certification auditors routinely expect to see it, so most certified organisations run it.
Which Annex A controls relate to testing?
Primarily A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance), plus A.8.25–A.8.28 on secure development and the Clause 6 risk assessment and Clause 9 performance evaluation. Testing provides evidence for several controls at once rather than mapping to a single line item.
How often should you pentest for ISO 27001?
There's no fixed frequency — it's risk-based. Annual testing plus testing after significant change is the accepted baseline; higher-risk systems test more often. Auditors want the cadence justified by your risk assessment and consistently followed, not an arbitrary number.
What evidence does the auditor want?
A recent report from a competent tester covering your ISMS scope, evidence that findings were risk-assessed and fed into the risk treatment plan, and proof that significant findings were remediated and retested. The auditor is checking testing is a managed process — identified, evaluated, actioned, closed — not a one-off filed and forgotten.
// 07 Related reading
- Pentest requirements by framework — ISO vs SOC 2 vs PCI vs the GCC regimes.
- Pentest for Vanta / Drata / Secureframe users and PCI DSS requirements.
- How to read the report and building a remediation plan.