Does ISO 27001 Require a Penetration Test

Does ISO 27001 require a penetration test? It is one of the most common questions we hear from UK firms preparing for certification, and the honest answer sits between a flat yes and a flat no. The 2022 version of the standard is deliberately outcome-based: it tells you what assurance to achieve, not which tool to buy. This guide explains which clauses and Annex A controls drive the expectation, what your auditor actually looks for, and when a scan is enough. For the full service view, see our guide to ISO 27001 penetration testing.

The short answer: not mandated, but often justified by risk

ISO/IEC 27001:2022 is a management-system standard, not a technical checklist. It never contains the phrase “penetration test”, which is why a literal reading suggests testing is optional. That reading is a trap. Annex A controls are apply-or-justify: clause 6.1.3 asks you to compare your chosen controls against Annex A and justify every inclusion and exclusion in your Statement of Applicability. Excluding 8.8 is possible on paper and vanishingly rare in practice, because once you declare it applicable, finding and fixing technical weaknesses becomes an obligation you set yourself. A vulnerability scan and a penetration test are the two recognised ways to produce that evidence, and for any organisation running web applications, external infrastructure or sensitive data, in our experience a scan alone rarely convinces an auditor looking for proof that controls hold up against a capable attacker, though the standard itself sets no such bar.

So in a strict legal sense, no. In practice, the certification process expects one for most scopes. The distinction puts the decision where it belongs: on your own risk assessment. If that assessment concludes exploitable technical vulnerabilities are a credible threat, and for almost every modern business it does, your own risk treatment plan commits you to validating and treating that risk. Penetration testing is the obvious answer.

The clauses that make technical assurance relevant

The pressure to test comes from the management-system clauses, not Annex A alone. Three sections of the main body do the heavy lifting.

• Clause 6.1 (actions to address risks and opportunities): you must run a documented risk assessment. If that assessment identifies technical exploitation as a risk, you have committed yourself to treating it, and an untested control is hard to defend as treated.
• Clause 9.1 (monitoring, measurement, analysis and evaluation): you must determine what needs monitoring and measurement, including your information security processes and controls, and evaluate the performance and effectiveness of the management system. Penetration testing is a direct, evidence-producing way to measure whether technical controls actually work rather than merely existing on paper.
• Clause 9.2 and 9.3 (internal audit and management review): findings from testing feed your audit and management-review cycle, closing the loop that auditors expect to see operating.

Read together, these clauses mean an organisation that claims its controls are effective but has never tested them is making an unsupported assertion. An auditor is trained to challenge exactly that gap, which is why penetration testing has become the default evidence rather than a nice-to-have.

What Annex A actually says about technical testing

Annex A of the 2022 standard lists 93 controls. None is titled “penetration testing”, but two are the controls auditors most often map a test against.

Control 8.8: Management of technical vulnerabilities

Control 8.8 requires you to obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate action. Vulnerability scanning addresses the discovery side well. Penetration testing goes further by confirming which discovered vulnerabilities are genuinely exploitable in your environment, removing the false positives a raw scan produces and giving you a defensible basis for prioritising remediation. Worth being precise about where the expectation comes from. ISO 27001 itself never names penetration testing. ISO/IEC 27002:2022, the implementation guidance for the same controls, does: under 8.8 it lists performing periodic, documented penetration tests, by internal staff or an authorised third party. Guidance is not a mandate, and anyone telling you ISO 27001 obliges a pen test is overstating it.

Control 8.29: Security testing in development and acceptance

Control 8.29 requires security testing to be defined and carried out during development and before systems are accepted into production. For anyone building or significantly changing software, this is the control that most clearly points toward application penetration testing as part of your release process, not a one-off event before the audit.

Because Annex A controls are justified in your Statement of Applicability, how you satisfy 8.8 and 8.29 is documented and visible to the auditor. Declaring these controls applicable, then producing no testing evidence, is one of the cleaner ways to attract a nonconformity.

Scan or test: when each one is enough

A frequent and expensive misunderstanding is that a vulnerability scan and a penetration test are interchangeable. They are not. A scan is automated, broad and shallow: it flags known signatures but cannot reason, chain weaknesses together, or distinguish a theoretical finding from a genuine breach path. A penetration test is human-led: our testers verify exploitability, chain low-severity issues into a real attack, and assess business impact in your specific context.

For ISO 27001, a defensible position usually combines both. Regular scanning supports continuous vulnerability management under control 8.8, while at least annual penetration testing provides the deeper, validated assurance that clause 9.1 effectiveness evaluation expects. A single low-risk internal system may be defensible with frequent scanning and strong patching. If your scope includes internet-facing applications, customer data or payment flows, expect your auditor, and your own clients, to want a penetration test on the record.

What your certification auditor really looks for

An ISO 27001 auditor does not arrive with a rule that says “show me a pen test”. They look for consistency between what you claim and what you can evidence. In practice, the testing-related questions sound like this:

• Your risk assessment flags technical exploitation as a risk: how have you treated and validated that control?
• You declared controls 8.8 and 8.29 applicable: what is the evidence they operate?
• Clause 9.1 requires you to evaluate control effectiveness: how do you measure that your technical defences actually work?
• When testing found issues, how did they flow into remediation, retesting and management review?

A current penetration test report, with a clear remediation trail and ideally a retest confirming fixes, answers all four cleanly. The report is rarely the prize; the auditor wants to see the management system using it, which is why a one-off test bought purely to pass certification, with no follow-through, can still leave a gap.

How often, and what scope, for ISO 27001

Test at least annually, and additionally after any significant change to in-scope systems, such as a major application release, an infrastructure migration or a move to a new cloud environment. ISO 27001 sets no fixed frequency itself, so your risk assessment determines the exact cadence and scope.

EJN Labs recommends annual testing plus testing after significant change for higher-risk internet-facing environments. That is our risk-based recommendation, not a frequency set by ISO 27001, which prescribes none. Tying testing to change, not just to the calendar, is exactly the risk-based behaviour auditors like to see.

Scope should follow your ISMS boundary. If certification covers a customer-facing SaaS platform, the application and its supporting infrastructure belong in scope; if it covers a corporate network holding sensitive records, external and internal infrastructure testing is the priority. Because price is driven by scope complexity in tester days rather than a fixed list, a focused, well-defined scope keeps cost proportionate. We explain how day counts translate into budget in our guide to UK penetration testing cost, so you can plan the spend before you commit.

How EJN Labs approaches ISO 27001 testing

EJN Labs is a CREST-accredited penetration testing firm, and we hold ISO 27001 ourselves, alongside Cyber Essentials, Cyber Essentials Plus and ISO 9001. We understand the standard from both sides: as testers producing the evidence, and as a certified organisation audited against the same clauses you are working toward. Our testing is delivered by UK-based testers working to CREST-accredited standards, so the report your auditor reads reflects examined competence.

Every engagement maps findings to the relevant Annex A controls and management-system clauses, so the report drops straight into your ISMS evidence rather than needing translation. We scope on a defined day count with fixed pricing, give you a clear remediation narrative, and include a free retest to confirm fixes, which is precisely the closed loop an ISO 27001 auditor wants to see. For how we structure an ISO-aligned engagement, see our ISO 27001 penetration testing service, or browse our services.

Frequently Asked Questions

Does ISO 27001 require a penetration test by law?

No. ISO 27001 is a voluntary standard rather than a law, and its text never names penetration testing or requires it word for word. In practice, however, the certification process expects a penetration test for any meaningful scope, so treating it as optional rarely survives an audit.

Clauses on risk treatment and control effectiveness, together with Annex A controls 8.8 and 8.29, mean most organisations need a penetration test to produce the evidence an auditor expects.

Will I fail my ISO 27001 audit without a penetration test?

Not automatically, but you raise the risk of a nonconformity. If your risk assessment identifies technical exploitation as a credible risk and you have declared controls 8.8 or 8.29 applicable, an auditor will ask how you evidence control effectiveness. With no testing and no equivalent evidence, that gap is hard to defend, so for most internet-facing or data-handling scopes a penetration test is the safest route to a clean audit.

Is a vulnerability scan enough for ISO 27001?

Usually not on its own, although it can be for low-risk scopes. A scan supports continuous vulnerability management under control 8.8, yet it cannot confirm exploitability or measure real-world impact the way the effectiveness evaluation in clause 9.1 expects, so most scopes need more than scanning.

For applications, external infrastructure or sensitive data, auditors and clients generally want a human-led penetration test alongside regular scanning.

How often should I run a penetration test for ISO 27001?

Run a penetration test at least annually, plus after any significant change to in-scope systems, such as a major release, an infrastructure migration or a cloud move. ISO 27001 itself sets no fixed frequency, which leaves your risk assessment to decide the cadence that fits your estate.

The annual figure is our recommendation rather than a rule. Tying testing to change as well as the calendar is the risk-based approach auditors prefer to see.

Get ISO 27001 testing that satisfies your auditor

If you are working toward or maintaining ISO 27001, a penetration test is the most reliable way to evidence that your technical controls actually work, mapping cleanly to clauses 6.1, 9.1 and Annex A controls 8.8 and 8.29. To get a fixed scope and price delivered by a CREST-accredited UK team, request a penetration testing quote, or read our full ISO 27001 penetration testing service guide first.