Does ISO 27001 Require a Penetration Test? (2026 Auditor Guide)
Short answer: ISO 27001 does not name "penetration test" as a required word, but it does require you to manage technical vulnerabilities and prove your controls work. A pentest is the standard, audit-accepted way to do both. So while it is not literally mandated, most certified and recertifying organizations need one to pass.
That nuance matters, because it is exactly where buyers get stuck. The standard text never says "you must run a pentest." Yet your auditor will ask how you find and treat technical vulnerabilities, and a clean vulnerability scan rarely satisfies that question on its own. Below is what ISO 27001 actually demands, why auditors expect a pentest anyway, and what an ISO-aligned test has to include to count as evidence.
What ISO 27001 Actually Says About Testing
ISO 27001:2022 is a management-system standard. It tells you to build a risk-based information security management system (ISMS), not which specific tools to run. The pentest expectation lives in two places.
Annex A control 8.8, Management of technical vulnerabilities
This control requires you to obtain information about technical vulnerabilities in your systems, evaluate your exposure, and take action. You cannot manage vulnerabilities you have never gone looking for. A penetration test is the most thorough way to find them, because it does what an automated scanner cannot: it chains weaknesses together the way a real attacker would.
The risk assessment and risk treatment process (clauses 6 and 8)
ISO 27001 requires you to identify risks, decide how to treat them, and verify that the controls you chose are actually effective. A pentest produces direct evidence of control effectiveness. It shows whether your firewalls, authentication, and application logic hold up under attack, or whether they have gaps you did not know about.
So the standard does not say "pentest." It says "find your technical vulnerabilities and prove your controls work." A penetration test is how serious organizations answer both.
Why Auditors Expect a Pentest Even Though the Standard Does Not Name It
Certification auditors are not checking a box that says "pentest completed." They are checking whether your evidence convincingly shows that control 8.8 is operating and that your risk treatment is grounded in reality.
Here is the practical problem. If you tell an auditor you manage technical vulnerabilities, they will ask to see how. A vulnerability scan report shows you ran a scanner. It does not show whether the findings were exploitable, whether they were treated, or whether your defenses stopped an attacker from going further. Auditors have seen too many clean scans sitting next to a system that any tester could break in an afternoon.
A penetration test closes that gap. It is performed by a human who validates findings, demonstrates real impact, and tells you which issues actually put your data at risk. That is the difference between "we scanned" and "we proved." Most certification bodies now treat an annual pentest as the expected baseline for any organization whose ISMS scope includes internet-facing or business-critical systems.
In short: the standard gives you flexibility, but the path of least audit friction runs straight through a pentest.
Need an ISO 27001-ready pentest? Map your assets to the controls your auditor checks and get a dashboard-delivered report built for your Statement of Applicability.
What an ISO 27001-Aligned Pentest Must Include
Not every pentest satisfies an ISO audit. To serve as evidence, it has to map to your ISMS scope and produce a report the auditor can read. Three things matter.
Scope and asset coverage
Your pentest scope should match the boundary you defined in your ISMS and your Statement of Applicability. If your certified scope covers a customer-facing web application, an internal network, and a cloud environment, a test that only covers the website leaves a gap the auditor will flag. The test has to cover the assets where your in-scope information lives.
This is where scoping goes wrong most often. Companies buy a generic "website pentest" and then discover at audit time that half their risk surface was never touched.
Budget Security solves this with AI goal-based scoping. You register your IT assets once, then pick the goal: in our case, ISO 27001 readiness. The scoping engine maps your assets to the control expectations behind 8.8 and your risk treatment, then proposes exactly what gets tested and how deep. If a tighter budget would leave an in-scope asset uncovered, the engine tells you plainly that the scope no longer meets the ISO goal and why. No guesswork, no over-scoping, no expensive surprises at audit time.
Frequency: annual, plus after major change
ISO 27001 does not set a fixed pentest interval, but auditor expectation and good practice have converged on a clear rule. Run a penetration test at least once a year, and again after any significant change to your in-scope systems. A new application, a major infrastructure migration, or a new public-facing service all reset your risk picture and warrant a fresh test.
For ongoing certification across the three-year cycle, an annual cadence keeps your evidence current at every surveillance audit. A test from two years ago does not reflect the system your auditor is looking at today.
The report as Statement of Applicability evidence
This is the part most articles skip. The pentest only counts if the deliverable works as audit evidence. Your auditor wants to see the scope tested, the findings, the risk ratings, the remediation status, and ideally proof of retesting on the issues you fixed. That trail is what links control 8.8 to a working reality.
Budget Security delivers all of this through a dashboard rather than a static PDF buried in an email thread. You get an issue tracker, remediation status per finding, retest results, and a full history across engagements. When your auditor asks for evidence that you manage technical vulnerabilities over time, you open one view that shows the finding, the fix, and the verification. That continuity is precisely what a Statement of Applicability needs to back control 8.8, and it is far more convincing than a one-off report that documents a single moment.
How Budget Security Scopes an ISO 27001 Pentest
Most providers scope from a sales call, where a senior tester estimates your needs from a conversation. That introduces guesswork and usually padding. We replaced that with objective, goal-based scoping.
- Register your assets. Web apps, APIs, networks, cloud, all in one place.
- Pick the goal: ISO 27001 readiness. The engine maps your in-scope assets to what control 8.8 and your risk treatment expect.
- See the test plan and the tradeoffs live. Add days to deepen coverage, or trim them and see exactly what gets cut and whether the scope still meets the ISO goal.
- Get a dashboard-delivered report built to drop straight into your audit as control evidence.
The test itself is run by OSCP-certified veterans. We kept the caliber of a premium consultancy and modernized everything around it: the scoping, the delivery, the program management. The result is a test that is genuinely ISO-aligned, not a generic scan with a compliance label slapped on the cover.
Cost and Timeline
Pricing starts from 849 EUR per day, published on the site, with no "contact sales" wall. The day count depends on your in-scope assets and the depth your ISO goal requires, which the scoping engine sets transparently rather than guessing. For a full breakdown of what drives pentest pricing, see our guide to what a pentest costs.
On timeline: most certification clients move from booking to test kickoff within 7 days. That matters when your audit date is fixed and your evidence window is closing.
Get an ISO 27001-Ready Pentest, Scoped in Minutes
Map your assets to the controls your auditor checks, then get a dashboard-delivered report built for your Statement of Applicability.
OSCP-certified veterans, transparent day rates from 849 EUR, and a dashboard-delivered report built as Statement of Applicability evidence. Still planning your cadence? Read how often you should run a pentest to set the right ISO 27001 frequency.