How Penetration Testing Supports ISO 27001 Compliance

If you are working toward ISO 27001, or you already hold it and a surveillance audit is coming up, someone has likely told you you need a penetration test. This is something we deal with regularly, and it is one of the most common assumptions in the whole certification process, and also one of the most misunderstood, because the standard itself never actually says so.

Read ISO/IEC 27001:2022 from front to back, and you will not find the words “penetration test” anywhere, neither in the clauses nor in Annex A. Yet auditors routinely ask about technical testing, and most certified organisations answer with a well-run penetration test. 

This guide explains where testing actually fits, which Annex A controls a pentest helps you evidence, and what an auditor expects to see when the time comes.

Does ISO 27001 require penetration testing?

The short answer is no, at least not in the sense of a named, mandatory activity. ISO 27001 is a risk-based, method-agnostic standard, meaning it tells you what outcome to achieve rather than prescribing the exact technique you must use to get there. As mentioned in the introduction, nowhere does it actually say you need a penetration test, to set a scope, or fix an interval.

What it does require is that you identify your technical vulnerabilities and treat them in line with your risks, and that you can show your chosen security controls are actually working rather than simply written down. 

That is a subtle but important distinction, because instead of asking “which rule forces me to test?”, the standard effectively asks “can you justify testing this little?” 

For anything internet-facing or business-critical, the honest answer is usually that you cannot, and a penetration test becomes the most credible way to close the gap. If you are still getting to grips with the fundamentals, our explainer on what ISO 27001 is covers the groundwork this article builds on.

Where penetration testing fits in the standard

The mandatory clauses, numbered 4 to 10, set out how you run your Information Security Management System (ISMS), the standard’s core. Annex A then provides a catalogue of 93 reference controls, grouped under four themes in the 2022 version: Organisational, People, Physical, and Technological. You select the controls that apply to your risks, justify any you leave out, and record those decisions in your Statement of Applicability.

Worth noting here is that ISO/IEC 27001:2022 is now the only valid version, as the older 2013 edition reached the end of its transition period on 31 October 2025, so every current certificate is held against the 2022 structure, and it is the 2022 control references that matter in any audit from here on.

Penetration testing lands squarely in the Technological theme, and it does two jobs at once. It generates evidence for several specific Annex A controls and feeds the wider requirement under Clause 9.1 to monitor and evaluate how well your controls perform. In other words, a good test is not just a tick against one box, but rather one of the clearest ways to demonstrate that your ISMS works in practice and not only on paper.

Which Annex A controls does penetration testing support?

Two controls carry most of the weight, and the supporting guidance in ISO 27002 points to both. The first is A.8.8, management of technical vulnerabilities, which expects you to find technical weaknesses, assess them and act on them. The second is A.8.29, security testing in development and acceptance, which requires you to define and carry out security testing before systems go live and after significant change. A penetration test with a proper remediation trail hits both.

Several further controls benefit from the same engagement, which is why a single test can provide evidence across your ISMS rather than in one isolated place.

The practical point is that your findings should map back to the controls in your Statement of Applicability. A report that lists raw vulnerabilities without connecting them to anything in your ISMS leaves your team to map them by hand, and the evidence is far weaker as a result.

What an auditor actually expects to see

An auditor is not looking for the most expensive test on the market. They are looking for evidence that a defined process ran, produced results, and led to action.

They expect a defined scope that reflects your ISMS, so the systems you tested line up with the systems you claim to protect. They expect a named methodology rather than a vague promise that “the platform handles it”, which is one reason a consultant-led penetration test stands up to scrutiny in a way that an unattended scan rarely does.

They expect risk-rated findings, so significant issues are clearly separated from trivial ones. Perhaps most importantly, they expect a remediation trail, meaning evidence that you acted on what was found and, where it mattered, retested to confirm the fix held.

Crucially, this is why a basic vulnerability scan presented as a penetration test tends to fail under audit scrutiny. A templated report can tick the box on paper, but it does not prove that the underlying process worked, and an experienced surveillance auditor will spot the difference. 

If you want the full picture of why this matters so much, our piece on what businesses get wrong about penetration testing goes into it. It is also worth understanding the genuine difference between automated scanning and human-led testing, because both have a place and the standard expects you to use each appropriately.

How often should you run an ISO 27001 penetration test?

The standard sets no fixed interval, but the widely accepted baseline is an annual test, plus testing after any significant changes to your systems or architecture. The logic is straightforward. 

A penetration test is a point-in-time result, so a report from eighteen months ago says little about the environment you run today. Annual testing, combined with responses to major changes, is usually enough to satisfy an auditor that you are keeping your assurance current rather than relying on a stale snapshot. 

Running continuous vulnerability assessments between tests strengthens the picture further, since it shows you are watching for new weaknesses as they emerge.

Turning findings into audit evidence

A penetration test only becomes compliance evidence once you have done something with it. The finding itself is the start of the process, not the end. What an auditor values is the closed loop, which means a clear record of how you triaged each issue, what you fixed, what you accepted and why, and how you confirmed the important fixes actually worked.

That last step matters more than many businesses expect, because a vulnerability you believe you have closed is only truly closed once it has been checked. 

Our guidance on penetration test remediation and the importance of retesting explains how to build that trail properly, so when an auditor asks what you did with your results, you can answer confidently rather than shrug.

Ready to make your ISO 27001 testing audit-proof?

At Fortifi, our CREST-accredited consultants run ISO 27001-aligned penetration tests, map findings to the Annex A controls your auditor will actually ask about, and back them with remediation and retest support that turns those findings into solid evidence. 

Whether you are preparing for your first certification or keeping a surveillance audit on track, we will help you test the right things and prove it properly. Book a call today.

Frequently asked questions

Is penetration testing mandatory for ISO 27001 certification?

No. ISO/IEC 27001:2022 never names penetration testing and does not make it a hard requirement. It requires you to manage technical vulnerabilities and demonstrate that your controls are effective, and for most organisations, a penetration test is the most practical way to meet that expectation, particularly for internet-facing systems.

Which ISO 27001 controls does a penetration test cover?

A pentest most directly supports A.8.8, management of technical vulnerabilities, and A.8.29, security testing in development and acceptance. It also provides evidence for controls such as A.8.25 secure development, A.5.7 threat intelligence, and A.8.9 configuration management, and it supports Clause 9.1’s requirement to evaluate how well your controls are performing.

Is a vulnerability scan enough for ISO 27001?

Scanning is useful and plays a real role, especially for continuous monitoring between tests, but on its own it rarely satisfies an auditor probing control effectiveness. A scan checks for known weaknesses, whereas a penetration test shows what an attacker could actually do with them. Presenting a scan as a full penetration test is one of the most common ways organisations fall short in audits.

How does ISO 27001 compare with other frameworks on testing?

ISO 27001 sits in the middle of the spectrum. Some frameworks, such as PCI DSS, mandate penetration testing outright, while lighter schemes like Cyber Essentials focus on baseline technical controls. ISO 27001 is risk-based, so rather than compelling a test, it asks you to justify your decisions, which for most environments leads to the same place.

Do the testers need a particular accreditation?

The standard doesn’t require a specific certification, but auditors place more weight on testing carried out by competent, independent testers using a recognised methodology. In the UK, CREST accreditation and individual qualifications such as OSCP or CRT are the usual markers of that competence.