There is a persistent muddle around penetration testing and ISO 27001. Some organisations are convinced the standard mandates a penetration test and panic accordingly. Others read the standard cover to cover, notice that the words “penetration test” never appear, and conclude that testing is optional. Both are wrong, and getting this wrong is an expensive way to walk into a certification audit.

The reality sits in between, and it is more useful than either myth. ISO 27001 does not name penetration testing as a hard requirement, but several of its controls make a credible test practically unavoidable for most organisations, and certification auditors expect to see the evidence. This guide sets out what you actually need: which controls a test supports, how often to test, what to put in scope, and exactly what your auditor will want to see.

Does ISO 27001 actually require a penetration test?

Strictly speaking, no. ISO/IEC 27001:2022 is a risk-based framework for an information security management system, or ISMS. The 2022 revision reorganised its Annex A controls into 93 controls across four themes, being organisational, people, physical and technological. Nowhere in those controls does it instruct you to commission a penetration test by name.

In practice, however, testing is effectively expected. The standard requires you to identify and treat technical risks, to verify that your controls actually work, and to evaluate your security at planned intervals. For any organisation with internet-facing systems or software in scope, a penetration test is simply the most credible and widely recognised way to prove those things.

It is telling that most certification bodies, and the UKAS-accredited auditors who assess against the standard, treat missing test evidence as a common cause of non-conformity. The honest summary is this: not mandatory by name, but something you will struggle to pass a Stage 2 audit without.

Why a vulnerability scan alone will not satisfy the auditor

A frequent and costly assumption is that an automated vulnerability scan is enough to tick these boxes. It is not. A scan identifies known weaknesses, but it does not prove whether they can actually be exploited, it misses business logic flaws, and it cannot chain several small issues into one serious breach the way a human attacker can. Experienced auditors draw a clear line between a vulnerability assessment and a penetration test, and they expect the latter as evidence of active, effective control evaluation. If you have previously had scan results accepted in place of a test, that reflects a lenient auditor rather than a sufficient control. Scanning has its place as ongoing hygiene, but it complements a penetration test rather than replacing it.

How often do you need to test?

ISO 27001 does not prescribe a frequency. Instead, Clause 9.1 asks you to evaluate at “planned intervals” that you define and justify through your own risk assessment. In practice, a clear norm has emerged, and auditors are familiar with it.

Annual testing is the accepted minimum across almost all sectors, and it is sensible to align it with your surveillance audit cycle so your evidence is always current. On top of that annual rhythm, you should test again whenever something significant changes, because change reintroduces risk that your existing controls may not cover. Common triggers include:

• Launching a new application or major feature
• A significant infrastructure change or network re-architecture
• A cloud migration or a move to new hosting
• A merger or acquisition that brings new systems into scope
• Any material change to systems that handle sensitive data

Higher-risk systems, such as internet-facing platforms or those processing sensitive information, often warrant more frequent testing than the annual baseline.

What should you actually put in scope?

Your testing scope should follow your ISMS boundary and your Statement of Applicability, not an arbitrary line. The aim is to cover the systems that matter to the information you are protecting, which typically means your external and internal networks, your web applications and APIs, and your cloud configuration, along with anything else that falls inside the certified environment.

Scoping too narrowly leaves gaps an auditor may question; scoping without focus wastes budget on systems that carry little risk. A good provider will help you define a scope that is defensible, proportionate and aligned to the standard.

The evidence your auditor will want to see

Passing the audit is not just about having a test done. It is about producing the right evidence and showing that the test fed back into your management system. When your assessment date approaches, make sure you can present the following:

• A signed penetration test report, typically dated within the last twelve months, setting out the scope, methodology, tester qualifications, and findings with clear severity ratings
• A remediation log showing that high and critical findings have been addressed, together with retest evidence confirming the fixes actually work
• A documented testing plan with agreed rules of engagement
• A mapping of findings to specific Annex A controls, feeding into your risk treatment plan

The thread running through all of this is continual improvement. Auditors are not looking for a one-off certificate to file away. They want to see that findings became risks, that risks were treated, that treatment was evidenced, and that the evidence supports your next audit. A penetration test that disappears into a drawer has failed its real purpose.

Where testing fits in the certification life cycle

ISO 27001 certification is not a single event. It begins with an initial assessment, usually a Stage 1 documentation review followed by a Stage 2 audit of your controls in practice. After that, your certification body carries out surveillance audits in the following years and a full recertification roughly every three years.

Penetration testing evidence is relevant at every one of these stages, which is precisely why an annual testing cycle aligned to your audit calendar is the pragmatic approach. It keeps your evidence current and removes the last-minute scramble to commission a test the month before an auditor arrives.

Making ISO 27001 testing straightforward

So, what do you actually need? Not a panic-driven box-ticking exercise, but a proportionate, well-scoped penetration test, carried out at least annually and after significant change, documented properly, mapped to the relevant Annex A controls, and fed back into your risk treatment and continual improvement. Do that, and testing stops being an audit headache and becomes genuine assurance that your controls hold up.

CodeShield is a CREST-accredited penetration testing provider that scopes every engagement to your ISMS boundary and Statement of Applicability, delivers audit-ready reports with findings mapped to ISO 27001 controls, and retests fixes before your assessment so you walk in with clean, current evidence. If you are pursuing or maintaining certification, get in touch to plan testing that fits your audit calendar and satisfies your auditor with room to spare.