Penetration testing evidence for your ISO 27001 audit

ISO 27001 penetration testing: what the standard states, and where 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 with expert human validation before customer delivery, retesting whose availability depends on the subscribed scope, and reports you can hand to the auditor and attach to your Statement of Applicability.

Reference: ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements (ISO), accessed 29 July 2026. Annex A control numbering follows the 2022 revision. Strike does not issue certificates; certification is granted by an accredited certification body following its own audit.

Strike-reported metrics on this page: 97% precision / 3% false positives, and more than 6,000 critical vulnerabilities reported. These are figures Strike reports about its own platform, not third-party benchmarks; the scope, definitions and measurement dates behind each are set out in how Strike measures results.

ISO 27001 penetration testing, answered

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.

What role does Strike play for ISO 27001?

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 reports that support audit and compliance programs, which 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. Setup takes under 5 minutes once the target information and access are ready, for supported scopes. Separately, once testing is running, findings arrive in 1–2 hours. Contact us for a scoped quote.

Kind of — ISO/IEC 27001:2022 makes clauses 4 to 10 the mandatory part of the standard, and per the text of the standard Annex A is a reference set of controls from which an organisation selects on the basis of its own risk assessment, recording any exclusion and its justification in the Statement of Applicability. What ISO 27001 asks for is a risk assessment, a risk treatment plan and evidence that the controls you selected are effective. Penetration testing is the evidence auditors recognise most readily behind Annex A 8.8, 8.25 and 8.29, and most certified organisations run one. The standard leaves the method open; the audit rarely does. Source: ISO/IEC 27001:2022 (ISO), accessed 29 July 2026.