ISO 27001 Penetration Testing Requirements: What You Need to Know

ISO 27001 penetration testing: what the standard actually says

ISO 27001 doesn't have a clause that says "you must get a penetration test." Full stop.

But if you're going for certification and you haven't done one, expect your auditor to ask why. Because two Annex A controls — A.8.8 and A.8.29 — point almost directly at pentesting, and "we didn't get around to it" isn't going to satisfy a certification body.

This post covers which controls apply, what evidence auditors want, how to scope your test to align with your ISMS boundary, and the difference between a test that satisfies ISO 27001 and one that just checks a box.

What ISO 27001:2022 actually requires

The standard was updated in 2022, and the control set changed significantly. ISO 27001:2022 has 93 controls across four themes: Organizational (37), People (8), Physical (14), and Technological (34). That's down from 114 controls in the 2013 version.

Two controls are the primary drivers for penetration testing:

A.8.8 — Management of technical vulnerabilities

This control requires organizations to "obtain information about technical vulnerabilities of information systems in use in a timely fashion, evaluate the organization's exposure to such vulnerabilities, and take appropriate measures to address the associated risk."

A.8.8 is primarily about vulnerability management — patching, scanning, tracking. But the phrase "evaluate the organization's exposure" is where pentesting comes in. A scanner finds vulnerabilities. A pentest tells you whether they're actually exploitable and what the real-world impact would be. Auditors know the difference.

A.8.29 — Security testing in development and acceptance

This control requires security testing to be defined and implemented for new and updated information systems during development. If you're building or changing systems that handle personal data, financial records, or anything sensitive, A.8.29 requires you to test them before they go live.

This is where application-layer pentesting fits directly. New features, API changes, architecture updates — all of them fall under A.8.29 if they're part of your in-scope information systems.

Clause 9.1 — Monitoring, measurement, analysis and evaluation

This is the broader clause that ties it together. ISO 27001 requires you to evaluate the performance of your information security controls. A pentest is one of the strongest forms of evidence that your controls actually work under adversarial pressure. Auditors reviewing Clause 9.1 evidence frequently look for testing data — not just policies saying controls exist.

The ISMS boundary determines your scope

Your ISMS (Information Security Management System) defines what's in scope for ISO 27001 certification. Whatever falls inside that boundary should drive your pentest scope.

Get this wrong and you'll either:

1. Conduct a pentest that covers systems auditors don't care about, while leaving in-scope systems untested
2. Spend money on testing that doesn't generate usable certification evidence

For most organizations, the ISMS boundary includes:

• Applications and databases that store or process the data your certification covers
• The infrastructure supporting those applications (cloud environments, servers, networking)
• External-facing systems: customer portals, APIs, remote access points
• Internal systems with privileged access to in-scope data (admin panels, support tools, identity providers)

A common mistake: defining a narrow ISMS scope to make certification easier, then scoping the pentest even narrower — to just the web application — and missing the API layer or the cloud infrastructure sitting behind it. Auditors look for coherence between your scope statement and your testing evidence.

Talk to your lead auditor before finalizing scope. Most certification bodies will give informal guidance on whether your planned scope would support the evidence they need. It's worth the call.

How often do you need to test?

ISO 27001 doesn't specify a frequency. But "whenever we feel like it" isn't a defensible answer during a Stage 2 audit.

The standard's Annex A controls and Clause 9.1 together create an expectation of ongoing evaluation. In practice, most ISO 27001-certified organizations pentest at least annually. If your systems change significantly — new architecture, major feature releases, cloud migration — you should test after those changes, not just on a calendar schedule.

For surveillance audits (the annual check-ins that follow initial certification), auditors will look at whether your security testing is current. A pentest from 18 months ago raises questions. A test from 3 months ago, with remediation evidence for the findings, tells a much cleaner story.

A practical rule of thumb: pentest at least once during each certification cycle, with additional scoped tests after major changes. Document your rationale in your ISMS. Auditors respect a risk-based approach — they want to see that you've thought it through, not just that you have a standing rule.

What evidence auditors actually want

Passing a pentest isn't the goal. Generating useful certification evidence is.

Your auditor will review your testing evidence as part of the Stage 2 audit and during surveillance. What they want to see:

Scope statement: Which systems were tested, and why. Explicitly tie the scope back to your ISMS boundary.

Independent provider: The test should be conducted by a qualified third party. Self-testing doesn't satisfy the independence requirement implied by ISO 27001's audit and evaluation controls.

Documented methodology: OWASP, PTES, CREST methodology — doesn't matter which one, as long as it's recognized and documented. Auditors want evidence that your test was systematic, not ad hoc.

Findings with severity classifications: CVSS scores or equivalent. Each finding should include a description, severity rating, and potential business impact.

Remediation plan and status: For every finding, document whether it was fixed, mitigated, or accepted as residual risk. Accepted risks need to be formally registered in your risk register.

Retest evidence: For high and critical findings, document that remediations were verified. This is where a lot of companies get tripped up — they fix the issues but don't get a retest, and they can't prove the fixes worked.

Risk register entries: If the pentest surfaces a new risk, it should flow into your formal risk treatment process. Auditors look at whether your pentest findings are actually integrated into your ISMS, or just filed away in a folder.

ISO 27001 vs SOC 2: how the evidence requirements differ

If you're pursuing both certifications — which is common for SaaS companies selling to enterprise — it's worth understanding how pentest evidence overlaps and where the requirements diverge.

The good news: a single well-scoped pentest can generate evidence for both certifications simultaneously. The scope, methodology, and report format requirements are close enough that one test — with slightly different framing in how you present the evidence — works for both.

As we covered in our SOC 2 penetration testing guide, the biggest difference is timing: SOC 2 Type II requires the test to fall within the audit observation period, while ISO 27001 is more flexible as long as the evidence is current when auditors review it.

Choosing the right type of test for ISO 27001

ISO 27001 doesn't mandate a specific type of pentest. Your choice should be driven by what's in scope and where your highest residual risk sits.

Web application pentest: The most common starting point. Covers the external attack surface — customer-facing apps, login flows, APIs, authentication logic. Required if any of these are within your ISMS boundary.

Internal network / infrastructure pentest: Tests whether an attacker who's already inside your network perimeter can move laterally and reach sensitive systems. Important if internal access controls and segmentation are part of your ISMS.

Cloud configuration review: If your ISMS boundary includes AWS, Azure, or GCP environments, an adversarial cloud assessment tests whether misconfigurations in IAM policies, storage permissions, or network controls would allow unauthorized access.

Gray box vs. black box: For ISO 27001 purposes, a gray box test (where the tester has some knowledge of the system, like a documented user account) usually generates more useful findings than a fully blind test. It tests realistic attack scenarios — an attacker who's phished a credential, or a malicious insider — rather than purely external reconnaissance.

Our penetration testing compliance guide covers how to sequence multiple test types if you're managing several frameworks at once.

The risk register piece everyone misses

This is the gap that trips up companies who treat ISO 27001 purely as a paperwork exercise.

ISO 27001 is a risk management standard. Your pentest findings are evidence of real risks. Every finding — whether you fix it, mitigate it, or accept it — needs to be formally handled through your risk treatment process and reflected in your risk register.

An auditor reviewing your ISO 27001 implementation will look at whether your pentest findings made it into your risk register with appropriate treatment decisions. If they're just sitting in a PDF on a shared drive, that's a gap.

The process should look like this:

1. Pentest report delivered with findings and severity ratings
2. High and critical findings entered into your risk register as new or updated risks
3. Risk treatment decision documented: fix, mitigate, or accept (with justification)
4. Remediation tracked to completion
5. Retest confirms fixes for high/critical items
6. Risk register updated with residual risk status

It's more process than most companies expect. But it's also what separates an ISO 27001 program that provides real security value from one that just gets the certificate.

---

Preparing for ISO 27001 certification and want to make sure your pentest scope actually satisfies your auditor? Book a free consultation with our team and we'll walk you through what a test engagement looks like for your ISMS boundary.