Does ISO 27001 require a penetration test?

The claim, and why it is wrong

Search for “ISO 27001 penetration testing” and most of the first page will tell you, in one form or another, that the standard requires an annual penetration test. It does not. ISO/IEC 27001:2022 contains ten clauses and an Annex A of information security controls, and the phrase “penetration test” appears in none of them. There is no mandated frequency. There is no mandated methodology. There is no requirement for the tester to be external, certified, insured or a member of any scheme.

This is not a technicality. Getting it wrong costs money in both directions. Organizations buy tests they do not need, at scopes nobody derived from anything, because a vendor told them the standard demanded it. Others skip evidence they genuinely do need, because they read the same page, could not afford the test it described, and concluded the whole area was out of reach. Both outcomes come from the same mistake: treating a practice as a requirement.

What is true is subtler and more useful. The standard requires you to decide, on the basis of risk, which controls are necessary, and then to show they are implemented and effective. For most of the technological controls in a modern Statement of Applicability, an independent test is the cheapest and most legible way to show that. Auditors know this, which is why they ask. But they are asking about the control, not about the test.

The chain that actually produces a test

Follow the standard the way an auditor does and the demand appears at a predictable point.

1. Clause 6.1.2 and 6.1.3. You assess information security risk, choose treatment options, and determine which controls are necessary. The output is the Statement of Applicability: every Annex A control marked applicable or excluded, each with a justification.
2. Annex A 8.8, management of technical vulnerabilities. Almost nobody excludes this. Once it is applicable you have to show that technical vulnerabilities are being identified, assessed and acted on.
3. Annex A 8.29, security testing in development and acceptance. Applicable to anyone who writes, assembles or configures software, which now includes most organizations that thought of themselves as pure service businesses.
4. Clause 9.1, monitoring, measurement, analysis and evaluation. You determine what needs measuring and evaluate whether the ISMS and its controls are effective. A test report is a measurement of control effectiveness, expressed as findings.
5. Clause 9.2, internal audit. The programme must be objective and impartial, which is what makes an outsourced internal auditor legitimate and useful.
6. Annex A 5.35 and A.8.34. The independent review of information security, and the control governing how tests on operational systems are planned and agreed so they do not disrupt the business.

Notice the shape. Nothing in that chain says “buy a penetration test”. Each link says “decide, then evidence the decision”. The test is one way of producing evidence for two or three of those links, and a poor way of producing it for most of the rest. That distinction is the whole of the argument, and the Annex A evidence mapper on the home page exists to make it concrete for your own scope.

What an auditor is actually entitled to ask

A certification auditor works against your Statement of Applicability, not against a generic checklist. For each control you declared applicable, they will ask two questions: is it implemented, and is it effective. Implementation is usually documentary. Effectiveness is where testing enters, because a policy that says vulnerabilities are managed is not evidence that they are.

In practice the exchange for A.8.8 goes something like this. Show me how you find technical vulnerabilities. Show me the register. How quickly do you act on a critical one, and show me a case where you did. What looks for things your scanner cannot see. Show me the last report. What happened to the findings. Show me the retest.

A nonconformity in that conversation is never “you have no penetration test”. It is “you could not demonstrate that a control in your own Statement of Applicability is implemented and effective”. If you can answer those questions with a scanning programme, a well-kept register, evidence of remediation inside your stated service levels and an independent review, you can answer them without a test. Most organizations discover that assembling that alternative costs more effort than the test would have, which is a commercial conclusion rather than a compliance one.

Claim versus text

The most common assertions on competing pages, set against what the standard and the accredited-certification framework actually say.

Where a penetration test proves nothing

The corollary of the honest answer is that a test is the wrong instrument for a large part of Annex A, and buying a bigger engagement to cover those controls is the most common waste in an ISO 27001 budget.

• People controls. Awareness and training under A.6.3, screening, terms of employment, the disciplinary process. A penetration test produces no evidence for any of them. A social-engineering assessment or a phishing exercise produces evidence for one of them, and it is a separate engagement with a separate report.
• Physical controls. Perimeters, entry controls and physical monitoring under A.7.1 to A.7.4. A network test says nothing about a door. If you want them tested, a physical intrusion assessment is the instrument.
• Governance and documentation controls. Policies, roles, the supplier register, contract clauses, identification of legal and regulatory requirements. These are evidenced by the documents themselves and by records of them being used.
• Lifecycle controls. A.8.25, the secure development life cycle, is evidenced by the lifecycle definition and by records that its gates were applied. A test evidences the output of that lifecycle, not the lifecycle. Secure code review and pipeline records are the matching instruments.
• Supplier controls. A.5.19 to A.5.22 are due-diligence, contractual and review activities. A test of your own estate says nothing about how you manage a supplier.

There is a middle band that is easy to misread. Logging under A.8.15 and monitoring under A.8.16 are not evidenced by a test, but a test creates a superb opportunity to evidence them: ask the tester for their timestamps and source addresses, then produce the matching log lines and the alert that fired. That one exhibit is worth more to an auditor than a monitoring policy. It only exists if you plan for it before the test starts.

If you conclude you do not need one

That is a legitimate outcome, and this site would rather you reached it deliberately than by accident. It is defensible when your estate is genuinely small and standard, when you develop no software, when your externally reachable surface is a handful of managed SaaS products you do not control, and when your risk assessment says so in writing.

What you then need is a written decision, not a silence. Record it where the auditor will find it: in the risk treatment plan, or as a note against A.8.8 in the Statement of Applicability. State what you do instead, at what cadence, and what would change the decision. Something like: authenticated vulnerability scanning of all internet-facing assets weekly, critical findings remediated inside seven days, an annual configuration review of the cloud tenant, and a commitment to commission an independent test if the organization begins developing software or exposes a custom application.

Two things make that hold up. First, it is a decision with criteria, not an omission. Second, it is testable: the auditor can ask for the scan schedule, the remediation records and the review, and you can produce them. An unwritten “we did not think we needed one” fails on both counts.

Where the requirement stops being optional

ISO/IEC 27001 leaves the instrument to you. Other regimes that sit on top of it do not, and most certified organizations in Europe now sit under at least one of them.

Commission Implementing Regulation (EU) 2024/2690, which lays down the technical requirements for several categories of NIS2 entity, states in recital 3 that those requirements “are based on European and international standards, such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401”. Its Annex then makes testing explicit. Point 6.5.1 requires entities to “establish, implement and apply a policy and procedures for security testing”. Point 6.5.2 requires them to establish the need, scope, frequency and type of tests from the risk assessment, to carry them out “according to a documented test methodology”, to document type, scope, time and results including criticality and mitigating actions for each finding, and to apply mitigating actions for critical findings.

That is a different legal character from an Annex A control. If the implementing regulation applies to you, the security testing policy is a requirement, and your ISO 27001 evidence pack is where it will most naturally live. Contractual regimes work the same way from a different direction: enterprise customers and public buyers increasingly require a current third-party test report as a condition of signature, and that obligation has a date attached to it.

What to do with the answer

Assuming you land where most certified organizations land, and conclude that a test is the sensible evidence for two or three controls, the answer changes three practical things.

• Scope. Derive it from the Statement of Applicability rather than from a vendor package. If your certificate covers a platform, a test of one URL is not evidence for the platform. See how to scope an ISO 27001 penetration test.
• Timing. Six to ten weeks before Stage 2, and annually thereafter against the surveillance calendar, so that the evidence pack shows closure rather than a list of open items.
• Report content. Findings on your own risk criteria as well as a public scale, reproducible evidence, and a dated retest. See what an ISO 27001 penetration test report must contain.

And one thing that is not practical but matters more than any of them: you now know what you are buying and why. When a supplier tells you the standard requires something, you can ask which clause. If they cannot answer, that tells you what the rest of their advice is worth.