ISO 27001 Penetration Testing Requirements: What Auditors Actually Expect

ISO 27001 penetration testing requirements are not spelled out as a single named clause. Annex A control 8.8 expects you to identify technical vulnerabilities in a documented way. The standard’s own guidance names penetration testing as one way to do that. Skip it, and an auditor will usually raise a nonconformity at Stage 2.

That gap between “not written down” and “expected in practice” trips up a lot of first-time applicants. Here is what the standard actually asks for. We cover which controls pull penetration testing in, how often auditors want to see it, and who is allowed to run the test.

ISO 27001 penetration testing requirements at a glance

Two Annex A controls carry the weight. An annual test is the de facto expectation, even though the standard itself doesn’t print a number. The test also needs to be independent of whoever built the system. The next sections work through each point in turn.

Does ISO 27001 require penetration testing?

Not by name. ISO/IEC 27001:2022 is a risk-based standard. It tells you to manage technical vulnerabilities and to test security before systems go live, but it leaves the method up to you. Two Annex A controls carry the weight.

• A.8.8 Management of technical vulnerabilities requires you to obtain information about vulnerabilities in the systems you run, assess your exposure and take timely action. Its guidance text recommends organisations “perform periodic, documented penetration tests, either by internal staff or by an authenticated third party.”
• A.8.29 Security testing in development and acceptance requires security testing before a system or a change reaches production. It covers authentication, access control and secure coding. Penetration testing is listed as one method for finding weak coding and design before release.

Both controls sit inside your Statement of Applicability unless you can justify excluding them. Clause 9.1 also requires you to monitor and evaluate how well your controls perform. Put those together, and an auditor will ask to see evidence that someone actually tried to break into your live systems, not just scanned them.

What auditors expect to see as evidence

A vulnerability scan report on its own rarely satisfies an experienced auditor. Scanners are good at flagging known, signature-based issues. They miss chained exploits, business logic flaws and misconfigurations that only show up when a person actively tries to abuse the system. Auditors typically want:

• A dated, scoped penetration test report covering the systems in your ISMS scope, less than twelve months old.
• Evidence that findings were triaged, assigned an owner, and either fixed or formally risk-accepted.
• A record that critical or high findings were retested after remediation.
• Proof the tester was independent of the team that built or manages the system, so the assessment is not marking its own homework.

If your ISMS scope includes a public-facing application, expect the auditor to ask about application-layer testing under A.8.29 too. That sits separately from the infrastructure-level testing under A.8.8.

How often do you need a penetration test for ISO 27001?

The standard does not print a number. It talks about “planned intervals” and leaves the interval to your own risk assessment. In practice, certification bodies converge on an annual test as the working baseline. That timing sits inside your surveillance audit cycle. Add an extra test after any significant change too: a new external-facing service, a major architecture change, or a material shift in what data the system handles.

A static, low-change environment can sometimes justify a longer interval, if the risk assessment says so. Frequent application changes usually need testing closer to each release, or a rolling programme instead of one annual snapshot. Either way, write the reasoning down. Auditors accept a lighter schedule far more readily when a risk decision backs it up, rather than a budget line.

Internal team or independent third party?

A.8.8’s guidance allows either, but independence matters more than the standard makes explicit. If the same engineers who built and patch a system also test it, an auditor may question how rigorous that really was. CREST-accredited testers, or any tester holding a recognised offensive security certification, remove that question. The auditor can trust the report’s quality without re-checking every finding themselves.

For smaller organisations, an external, independent test also solves a practical problem. Most in-house IT teams do not have the day-to-day exploitation experience a dedicated tester builds up. Findings tend to be more thorough and better explained when the work is contracted out. If you would rather not build that capability in-house, Aardwolf Security runs scoped penetration tests designed to hold up against exactly this kind of scrutiny.

Scoping the test to your ISMS

Your penetration test scope should map to your Statement of Applicability, not to whatever is easiest to test. That usually means:

• External infrastructure: anything internet-facing within the ISMS boundary, including VPN endpoints and remote access services.
• Internal infrastructure: servers, workstations and network segments holding in-scope information. This matters most where lateral movement from a compromised account is a realistic threat.
• Applications: any web application, API or mobile app that processes in-scope information. Test these under A.8.29 before major releases, and again on the periodic schedule once live.

Leaving a system out of scope because it is inconvenient to test is a common finding. It usually means the risk assessment and the actual testing programme have drifted apart.

What the report needs to contain

Keep the full report, not just a summary. That is what an auditor will ask to review. A report an auditor can work with shows the scope and dates tested, the methodology used, and each finding with a severity rating and clear reproduction steps. It also needs a remediation status for every item, including anything the business formally accepted as a risk rather than fixed. Retain reports and remediation evidence for at least your certification cycle, so a surveillance auditor can trace the history.

Penetration testing feeds naturally into A.8.8 and A.8.29. It also strengthens Clause 9.1 monitoring evidence and gives your management review something concrete to discuss, rather than a generic line about vulnerability management being “in place.” Not sure where your current evidence stands? Get in touch and we can talk through what your ISMS scope actually needs before your next audit.

Frequently asked questions

Is a vulnerability scan enough for ISO 27001?

Not on its own. Scanning is a useful continuous check. Auditors still expect a human-led penetration test as well, since scanners miss the chained and logic-based issues manual testing finds.

Do I need separate tests for infrastructure and applications?

Usually yes. A.8.8 covers your general technical estate. A.8.29 specifically expects security testing of applications before they go live, so businesses often commission the two as separate pieces of work.

What happens if I have no penetration test evidence at all?

Expect a nonconformity at your Stage 2 audit. Auditors treat an absence of testing evidence as a gap in your technical vulnerability management control. You will usually need to close it with a corrective action before certification is granted.

Can automated tooling substitute for a manual tester?

It can support the process, but not replace it. Automated scanning helps with coverage and frequency. The manual element is what auditors actually want when they ask about penetration testing.

Does a retest count as a new penetration test?

A retest confirms a specific finding was fixed. It is not a substitute for the periodic, full-scope test that A.8.8 and your own risk assessment call for. Keep both as separate, dated records.