Penetration testing evidence for your ISO 27001 audit

What ISO 27001 asks for — and where penetration testing fits

ISO/IEC 27001:2022 never names the penetration test as a mandatory activity. What it requires is a risk-based information security management system: you identify risk, you treat it, and you demonstrate that your controls actually work. Penetration testing is the evidence that carries the most weight in that demonstration, because it shows a control holding or failing under a real attack rather than on paper.

An ISO 27001 certificate is valid for three years. Year one and year two bring surveillance audits — sampled reviews confirming the ISMS is still operating — and year three is a full recertification audit that resets the cycle. A single pentest booked four weeks before the Stage 2 audit documents one moment in a thirty-six-month story. Everything shipped in the other thirty-five months has no evidence behind it.

Annex A 8.8 — Management of technical vulnerabilities: you have to obtain information about vulnerabilities in the systems you use, evaluate your exposure and act on it. Penetration testing surfaces the exposures no vulnerability feed will ever tell you about, because they live in your own business logic.

Annex A 8.25 — Secure development life cycle: security has to be designed into development rather than bolted on afterwards. Testing that runs with each release is the practical proof that the lifecycle is real and not a document.

Annex A 8.29 — Security testing in development and acceptance: a defined testing strategy, executed during development and before acceptance, in properly separated environments, by competent testers. The control does not mandate a penetration test — code review and automated testing also qualify. Most organisations run one anyway, because it is the method an auditor recognises immediately.

Traceability: what was in scope, who tested it and with what competence, what they found, how each finding was rated, when it was fixed, and proof that the fix works. And the stop button — evidence that a release was genuinely held back because a security test failed. Continuous testing produces that trail as a by-product; an annual engagement produces one report and then eleven months of silence.

Strike does not certify ISO 27001 and cannot: the certificate is issued by an accredited certification body after its own audit. What Strike produces is the technical evidence that body asks for — continuous penetration testing executed by AI and validated by expert hackers at 97% precision and under 3% false positives, a documented retest tied to every finding, and reports you can hand to the auditor and attach to your Statement of Applicability.

ISO 27001 and penetration testing, answered

Does ISO 27001 require a penetration test?

Not in those words. ISO/IEC 27001:2022 requires a risk assessment, a risk treatment plan and evidence that your controls are effective. Penetration testing is the evidence auditors expect behind Annex A 8.8, 8.25 and 8.29, and in practice almost every certified organisation runs one. The standard leaves the method open; the audit rarely does.

What testing evidence does an ISO 27001 auditor actually ask for?

Scope, methodology, the competence of the testers, the findings with their severity ratings, remediation dates, proof that each fix was retested, and the link back to your risk treatment plan and Statement of Applicability. A report with no retest and no traceability to the risk register is weak evidence.

When in the certification process should we test?

Before the Stage 2 audit at the latest, so findings arrive closed rather than open. Ideally testing is continuous, because the surveillance audits in years one and two also sample control effectiveness, and the recertification audit in year three looks back across the whole cycle.

Can the same testing also serve SOC 2 and PCI DSS?

Largely yes. The technical work overlaps heavily across frameworks; what changes is how the evidence is packaged and which controls it maps to. Strike runs one continuous testing programme and produces reports that support each framework rather than three disconnected engagements.

Does Strike certify ISO 27001?

No. Strike supports ISO 27001 with penetration testing evidence — only an accredited certification body can issue the certificate, after its own audit. Strike provides the technical evidence, retest records and audit-ready reports that the audit relies on.

How much does it cost and how long does it take?

Strike works as a continuous subscription scoped to your attack surface rather than a one-off fixed-price project, so cost depends on scope and assets. Onboarding takes days, and validated critical findings typically land within hours to days of testing starting. Contact us for a scoped quote.