ISO 27001 Penetration Testing: What’s Actually Required?
ISO 27001 Penetration Testing: What’s Actually Required
ISO 27001 does not explicitly require a penetration test. If you’re looking for the clause that says “you must hire a pentester,” you won’t find it.
What the standard does require is that you identify risks, assess them, apply appropriate controls, and produce evidence that you’re doing so consistently. For any organization running a web application, an API, or cloud infrastructure, that last part is where penetration testing earns its place.
What the Standard Actually Says
ISO 27001 is a risk management framework. It doesn’t prescribe specific technical controls so much as it asks you to demonstrate that you’ve thought seriously about your risks and done something meaningful about them.
A few controls are worth knowing:
A.12.6.1 covers technical vulnerability management, which requires organizations to identify, evaluate, and address technical vulnerabilities in a timely manner. A.18.2.3 covers technical compliance review, which asks whether information systems are regularly reviewed for compliance with security policies. A.15.2 addresses supplier relationships and managing third-party risk, which can come into play depending on your environment.
None of these say “penetration test.” All of them point toward it.
If your risk assessment identifies technical vulnerabilities as a meaningful risk, and for most SaaS companies it does, your auditor is going to want to see how you addressed that. A penetration test is one of the most recognized and auditor-legible ways to demonstrate you did.
Why Most ISO 27001 Programs Include a Pentest
The companies that skip penetration testing during ISO 27001 prep usually fall into one of two categories: those with very narrow technical scope who have a credible alternative, and those who are hoping the auditor doesn’t push too hard on vulnerability management.
The companies that include it do so for practical reasons. It produces evidence. It identifies things internal reviews miss. It satisfies overlapping requirements if you’re also working toward SOC 2, PCI DSS, or HIPAA at the same time. And it gives your engineering team something actionable rather than a theoretical risk register that nobody reads after the audit closes.
That last point matters more than most teams realize going in. The audit produces a moment of accountability. What happens to your actual security posture after that moment depends entirely on whether the pentest findings were specific enough for anyone to act on.
What ISO 27001 Pentest Scope Actually Looks Like
The standard doesn’t specify how to test, which means scope is driven by your risk assessment rather than a checklist. That’s a feature, not a bug. It means the test should reflect what you actually built and where the real risk lives.
For most SaaS companies, that means web application testing as the primary surface: authentication, authorization, session handling, API security, business logic. Depending on the environment, it might also include external network testing, cloud configuration review, or internal network assessment.
The methodology should be manual and risk-based rather than scanner-driven. Automated tools have a role in any engagement, but they find what they’re programmed to find. The business logic vulnerabilities, the chained findings, the things that require actually understanding how your application works, those require a human tester paying attention.
Testing aligned to OWASP ASVS for web applications gives you a structured framework that maps clearly to ISO 27001 controls and holds up when an auditor asks about your methodology. It also produces more credible evidence than a scanner dump, because you can show what was tested and how, not just what was found.
What the Report Needs to Show
For ISO 27001, the report is evidence. It needs to demonstrate that an independent third party tested your environment, that findings were risk-ranked and prioritized, that remediation steps are documented, and that the scope was appropriate for your environment.
That’s the auditor read. But the engineering team read matters too, and it’s often the one that gets ignored during compliance-driven engagements.
A report that satisfies an auditor but gives your developers nothing to work with is a compliance document. A report that satisfies an auditor and gives your developers clear reproduction steps, specific remediation guidance written for your actual stack, and enough context to understand the real-world impact of each finding is something more durable. It’s evidence you can use again when a customer asks, when an investor asks, or when you’re renewing the certification next year.
The difference between those two reports isn’t the auditor’s problem. It’s yours.
The Practical Bottom Line
ISO 27001 doesn’t require a penetration test. It requires you to demonstrate that you’re managing technical risk seriously. For most organizations, those end up being the same thing in practice.
The test you commission for the audit is the same test your engineering team has to act on, the same report your next enterprise customer may request, and the same evidence your auditor will look at when you go for recertification. Getting it right the first time is cheaper than getting it wrong and finding out later.
If you want to know what “right” looks like before you choose a vendor, the guide we put together, Audit-Proof Your Pentest: 17 Mistakes That Will Blow Your Audit, covers exactly that. Written for technical leaders who don’t want to discover the problem after the deadline has passed.
