2 October 2026 · 9 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
ISO 27001 Penetration Testing: What the Standard Asks and What Auditors Expect
ISO 27001 never says the words "penetration test". Your certification auditor will still ask for one. This guide explains which controls a test satisfies, how to scope it, and what a certification-ready report looks like.
Does ISO 27001 require a penetration test?
Not by name. ISO/IEC 27001:2022 is a management-system standard: it tells you to identify risks, choose controls, and prove those controls work. It does not prescribe a specific test. In practice, almost every certification body treats an independent penetration test as the normal way to prove that technical controls hold up against a real attacker, because the alternative (asking you to assert it) is not evidence.
The 2022 revision made this harder to sidestep. Annex A was restructured into 93 controls, and several of the new or reworded controls explicitly deal with vulnerability management and security testing. Organisations certified against the 2013 edition had to transition by 31 October 2025, so from 2026 every audit runs against the 2022 control set.
The ISO 27001:2022 controls a penetration test gives evidence for
Auditors do not ask "did you do a pentest?" They ask "show me evidence for this control". A well-scoped test produces evidence for at least these five.
A.8.8 Management of technical vulnerabilities
You must obtain information about technical vulnerabilities in the systems you use, evaluate your exposure, and take measures. Scanning finds known weaknesses; a penetration test finds the exploitable chains that scanners miss, and the report is dated evidence that you evaluated exposure.
A.8.29 Security testing in development and acceptance
Security testing processes must be defined and implemented in the development life cycle. An application penetration test before go-live, and after major releases, is the most direct evidence that this control exists in practice and not only in a policy document.
A.8.25 and A.8.26 Secure development and application security requirements
These controls expect secure engineering rules and security requirements for applications. Test findings mapped to OWASP categories show the auditor where the rules are followed and where they are not.
Clause 9.1 Monitoring, measurement, analysis and evaluation
The management system itself must evaluate whether information security performance is effective. Penetration-test results, retest results, and the trend between them are the measurement most auditors want to see for the technical side of the ISMS.
Clause 10 Improvement and A.5.36 Compliance with policies
Findings become nonconformities or improvement actions. A report with severity, root cause, and a retest confirming the fix closes the loop the standard requires: detect, correct, verify.
What auditors accept, and what they reject
Certification bodies differ, but the patterns below come up in every ISO 27001 audit we have supported.
| Topic | Generally accepted | Usually challenged |
|---|---|---|
| Who tested | Independent third party, named testers, recognised certifications (OSCP, OSWE, CREST) | Internal staff testing their own systems, or an anonymous automated service |
| Scope | Written scope tied to the ISMS statement of applicability: the systems that process in-scope information | A single public website while the ISMS covers the whole company |
| Method | Manual testing plus tooling, methodology stated (OWASP, PTES, NIST SP 800-115) | Vulnerability scan output presented as a penetration test |
| Cadence | At least annually, and after significant change | A test older than 12 months, or none since a major migration |
| Report | Severity, evidence, root cause, remediation advice, retest results | Finding list without evidence or without proof of remediation |
How to scope an ISO 27001 penetration test
Scope follows the ISMS, not the other way round. Start from the statement of applicability and the asset inventory, then confirm each of these.
- External perimeter: every internet-facing system that handles in-scope information, including cloud consoles and remote-access gateways
- Internal network: assumed-breach testing from a standard user position, covering segmentation between in-scope and out-of-scope zones
- Applications: the business applications named in the scope, tested against OWASP Top 10 and business-logic abuse
- Identity: Active Directory or Entra ID, single sign-on, MFA enforcement, privileged accounts
- Change-driven tests: a focused test after each major release or infrastructure change, not only the annual cycle
- Retest: a verification round after remediation so the auditor sees closed findings, not open ones
ISO 27001 pentest cadence: annual is the floor
The standard does not state a frequency. Auditors look for a documented, risk-based cadence that you actually follow. For most certified organisations that means a full external and internal test once a year, application tests tied to releases, and a retest after every round of remediation. Organisations in regulated sectors, or those that also fall under NIS2 or DORA, usually test more often because those frameworks pull the cadence up.
The common mistake is treating the test as an audit-week deliverable. A test run two weeks before the certification audit with no remediation window produces an open findings list, which is worse evidence than a test run four months earlier with a clean retest.
What a certification-ready report contains
An auditor reads a penetration-test report differently from a CISO. They want to trace a line from the ISMS scope to the test scope, from each finding to a control, and from each control to a corrective action. Our ISO 27001 reports therefore include a scope statement that references your statement of applicability, a methodology section, findings with CVSS severity and reproducible evidence, a mapping of findings to Annex A controls, a remediation plan with owners, and a retest appendix.
If you are preparing for a first certification, share the report with your implementation lead before the stage 2 audit. If you are already certified, the surveillance auditor will expect the previous year's findings to show as closed.
Frequently asked questions
Preparing for an ISO 27001 audit?
Our OSCP-certified testers scope the test to your statement of applicability and deliver a report your certification auditor can read line by line. Talk to an expert.