Does ISO 27001 require penetration testing?
No. Nothing in ISO/IEC 27001:2022 names penetration testing, in Annex A or anywhere else. But two controls, A.8.8 and A.8.29, require you to find technical vulnerabilities and to test security, and a penetration test is the cheapest defensible evidence that both operate. That is why auditors expect one.
On this page: what the standard says · why auditors expect a test · certificate vs report · scope · how often · evidence · cost
What the standard actually says
ISO/IEC 27001:2022 carries 93 controls in Annex A, grouped into four themes: organizational, people, physical and technological. Search all 93 for the words “penetration test” and you will not find them. The standard’s own catalogue entry describes an information security management system, not a testing regime.
Two controls do the work instead.
A.8.8, management of technical vulnerabilities
This is the one most testing programmes are hung on. It requires that information about technical vulnerabilities in the systems you use is obtained, that your exposure is evaluated, and that suitable measures follow. It says nothing about how you obtain that information, which is deliberate: a scanner, a vendor advisory feed and a penetration test are all valid inputs, and the standard leaves the choice to your risk assessment.
A.8.29, security testing in development and acceptance
This one is narrower and more often missed. It requires security testing to be defined and carried out within the development lifecycle, which means testing before things reach production, not only afterwards. If you ship software, this control is where “we run a test once a year on the live site” starts to look thin.
The two that quietly widen the scope
A.8.25, secure development lifecycle, and A.8.31, separation of development, test and production environments, both interact with how you test. If you test in an environment that does not resemble production, you have evidence for one control and a gap in another.
Why auditors expect one anyway
Assurance is the word the standard keeps using
Because the certification body’s job is to see whether the controls you claimed in your Statement of Applicability actually operate, and testing is the evidence that is hardest to argue with. The UK’s National Cyber Security Centre, whose penetration testing guidance is the reference most European auditors reach for, defines the exercise in terms that map neatly onto A.8.8:
Penetration testing is a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might.
Assurance is the operative word. An advisory feed tells you a vulnerability exists somewhere in the world. A test tells you whether it exists in your system, which is the question A.8.8 actually asks.
The difference from SOC 2 that matters
This is worth being precise about, because the two get discussed interchangeably and they are structurally different.
| ISO 27001 | SOC 2 | |
|---|---|---|
| What you get | A certificate with a scope statement and an expiry | A report containing a CPA firm’s opinion |
| Who issues it | An accredited certification body | A licensed CPA firm |
| Oversight | National accreditation bodies such as UKAS under the IAF multilateral agreement | State boards of accountancy and AICPA peer review |
| Cycle | Initial audit, surveillance in years 1 and 2, recertification in year 3 | A new report every period, typically annually |
| ”Certified” is correct | Yes | No, there is no such thing |
One caveat on the certificate, because unaccredited certificates circulate and they are not equivalent:
Certification issued by a body that is not itself accredited carries no assurance that the certification process met an international standard.
Check that the body appears on a national accreditation register before you pay, and check the same for a supplier’s certificate before you accept it.
So “show me your ISO certificate” is a reasonable request, while “show me your SOC 2 certificate” is a category error, as our SOC 2 compliance guide explains at length. If you are being asked for both, note that the testing evidence is largely reusable while the paperwork is not.
Scope is the finding nobody expects
The most common testing-related nonconformity here is not “you did not test”. It is that the test scope and the ISMS scope do not match.
Your Statement of Applicability records which controls apply and why. Your risk assessment records what you decided to worry about. If those documents identify application-layer risk across three services and your test covered one, the gap is visible in your own paperwork before the auditor even reads the report.
The fix is boring and it works: write the scope down first, test to it, and keep the two in step whenever either changes. A test that is narrower than your documented risk is worse than no test, because it is a written admission.
How often you actually need to test
There is no mandated interval, and anyone who tells you the standard says annually is describing convention rather than text. What the standard requires is that your approach follow from risk.
That said, the convention exists for a reason and auditors are comfortable with it. Once a year plus after any significant change is the defensible baseline. Significant change means what you would expect: a new internet-facing service, an authentication rewrite, a cloud migration, a new processing location.
The awkward case is the one most software companies are actually in. If you deploy weekly, an annual test describes a system that has since been replaced many times over, and the certificate does not care but your enterprise buyer’s security questionnaire will. Continuous testing resolves that mismatch by making the evidence continuous too, which also happens to suit the three-year certification cycle better than a single annual burst.
What to hand the auditor
Four things, and the fourth is the one people forget.
| Evidence | Why the auditor wants it |
|---|---|
| The test report, with methodology | Shows what was actually done, not just what was found. This section is read first |
| Scope agreed in advance | Ties the test to the ISMS boundary and the risk assessment |
| A remediation record, with dates | A.8.8 requires that measures follow. Findings with no closure record are the gap |
| Retest evidence for anything material | Proves the measure worked, rather than that a ticket was closed |
Our compliance evidence page covers the format, and does SOC 2 require a penetration test covers the equivalent expectation on the SOC 2 side, including the observation window rule that catches first-time buyers.
What it costs
The test itself is priced like any other penetration test: tester-days times a day rate, so $5,000 to $30,000 for a web application from a credible boutique, with cloud estates running higher. Our penetration testing cost breakdown has the bands by engagement type.
The certification is separate and is where ISO differs from SOC 2 on cost structure. You pay an accredited body for the initial audit and then again for surveillance, and the fee scales with the size of the ISMS and the number of sites rather than with trust criteria. Budget for the three-year cycle rather than the first invoice.
Ours is published: $299 a month under ten people and $499 at ten or more, which includes a penetration test every month rather than once a year, unlimited if you bring your own Anthropic key. A human-led engagement is $2,999 per engagement on top. There is no quote call, and if your situation is genuinely unusual a 20-minute call will settle it faster than a scoping form.
Frequently asked questions
Does ISO 27001 require a penetration test?
No. No control in Annex A of ISO/IEC 27001:2022 names penetration testing, and you will not find the phrase in the requirements clauses either. What the standard requires is that technical vulnerabilities be identified and evaluated (A.8.8) and that security testing be carried out as part of development and acceptance (A.8.29). A penetration test is the most common and most defensible way to evidence both, which is why certification bodies expect to see one even though no clause demands it.
How often does ISO 27001 expect penetration testing?
The standard sets no interval, because the whole framework is risk-based rather than prescriptive. In practice, once a year plus after any significant change is the defensible default, and it lines up with the certification cycle: an initial audit, surveillance audits in years one and two, then recertification in year three. If you ship weekly, an annual test certifies a system that no longer exists, which is an argument your auditor will accept but your enterprise customer may not.
Is ISO 27001 a certification, unlike SOC 2?
Yes, and this is the cleanest difference between them. ISO 27001 is certified by an accredited certification body, and you receive an actual certificate with a scope statement and an expiry. SOC 2 produces an attestation report containing a CPA firm's opinion, and there is no certificate at all. So asking what your ISO certificate costs is a coherent question, while asking what your SOC 2 certificate costs is not.
Will a vulnerability scan satisfy the auditor instead?
Sometimes for A.8.8, rarely for A.8.29, and it depends on your risk assessment. A scan finds known, published weaknesses in things it recognises. It does not chain findings, abuse business logic, or test whether your authorization actually holds, which is where real breaches live. If your own risk assessment identifies application-layer risk and your only evidence is a scan output, expect the gap to be raised.
Does the penetration test have to cover everything in scope?
It has to cover what your Statement of Applicability and risk assessment say matters, which is not the same as everything you own. The ISMS scope defines the boundary, and a test scoped narrower than the risks you documented is the most common finding here. Write the scope down first, then test to it, then keep the two in step when either changes.
How can HackZero test every month for 299 dollars when a single test costs thousands?
Stack ownership. The attack agents, the exploitation toolchain and the reporting are built in-house, so the marginal cost of a run is compute plus senior review rather than tester-weeks, and the day-rate arithmetic that sets consultancy prices stops applying. AI does the continuous coverage no human team could afford monthly, and hackers stay in the loop to confirm findings actually exploit and to write the report an auditor will read. Our prices are published rather than quoted: 299 dollars a month under ten people, 499 at ten or more. The honest catch is that the subscription is AI-led with human validation, so if you want hackers driving a named engagement that is 2,999 dollars per engagement on top.