Do you need a penetration test to get ISO 27001 certified?

By the QuantumSec team

The short answer: the standard doesn't literally require it, but in practice it's very hard to pass a certification audit without one if your organization has internet-facing systems or sensitive data. The reason lies in how ISO 27001 is built: it doesn't mandate specific tools, it requires you to prove you manage risk effectively — and for many technical risks, a penetration test is the only credible way to prove that.

What the standard literally says (and doesn't say)

ISO/IEC 27001:2022 does not mention the word "pentest" in any Annex A control. What it does require is a technical vulnerability management control (A.8.8) and security controls in development (A.8.25 through A.8.29, which explicitly include "security testing"). Control A.8.29 talks about testing security during development and operations — penetration testing is, in practice, the standard way to satisfy that control whenever applications or critical infrastructure fall within the ISMS scope.

Why the auditor asks for it even though it's not named explicitly

ISO 27001's approach is risk-based: if your risk assessment identifies an exposed web application as a critical asset, and the control chosen to mitigate it is "periodic security testing," the auditor will ask for evidence that testing has actually happened and what it found. An automated vulnerability scan may not be sufficient evidence if the identified risk is high: that's where a manual pentest becomes, in practice, the evidence the auditor expects to see.

When you're most likely to be asked for one

Internet-facing web applications or APIs handling customer data. Critical infrastructure within the ISMS scope (internal network, Active Directory). A regulated sector or one with third-party requirements (fintech, healthcare, e-commerce). An ISMS scope that includes in-house software development. In these cases, the total absence of any pentest or technical security testing evidence is one of the most common findings in certification audits.

How often and what scope

There's no fixed figure in the standard, but common practice is an annual pentest of the critical assets identified in the risk assessment, plus additional testing after significant changes (a new application version, an infrastructure change). The scope must be consistent with what your own risk assessment says: if you identified the web application as a critical asset, the pentest must explicitly cover it, not a generic perimeter scan.

FAQ

Is an automated vulnerability scan enough?

For low or medium severity risks, it may be. For assets your own risk assessment classifies as critical, an experienced auditor expects evidence of manual testing confirming real exploitability, not just an unverified list of CVEs.

Does the full pentest report have to be handed over to the auditor?

Usually the executive report and confirmation that critical vulnerabilities were remediated (or an in-progress remediation plan) are presented as evidence, not necessarily the full technical detail with PoC, which can be treated as sensitive information.

What if the pentest finds critical vulnerabilities right before the audit?

It's better for your own pentest to find them than for the auditor to find them some other way. What's being assessed isn't "zero vulnerabilities" but that a risk management process exists that detects and remediates them with a reasonable plan and timeline.