ISO 27001 never names a penetration test as a requirement in those words. But two Annex A:2022 controls — A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) — plus auditor expectation make the pentest the de facto default evidence. At DeepMantis, such a test starts at €890, and the report is built audit-ready: every finding backed by a reproducible proof of concept, not scanner output. This article states exactly what the standard requires — and what it does not.
Does ISO 27001 require a penetration test?
The honest answer: no, not literally. The text of ISO/IEC 27001:2022 and its companion control set ISO/IEC 27002:2022 do not contain the word "penetration test" as a mandatory requirement. Anyone telling you otherwise has not read the standard.
And yet almost every ISMS path leads to a pentest — through two controls from Annex A:2022. A.8.8 requires the management of technical vulnerabilities; A.8.29 requires security testing in development and acceptance. The implementation guidance lives in ISO 27002:2022; a well-structured breakdown of A.8.29 is available at ISMS.online. Both controls describe, in intent, what a pentest delivers — without using the word.
The consequence: auditors do not ask "Did you run a pentest?" They ask "How do you demonstrate that you actively find technical vulnerabilities and test security-relevant releases?" To that question, a signed pentest report is the most defensible answer. Since the transition to ISO 27001:2022 — binding for new certifications since 2024 — the updated Annex A with exactly these control IDs applies.
Which controls make the pentest the evidence?
Two controls from Annex A:2022 are relevant here. The table below maps what each requires in intent, what auditors want to see for it, and how a pentest satisfies it. The control wording is paraphrased — the standard text itself is paywalled; the official source of reference is the ISO page for 27001.
| Control (Annex A:2022) | What it requires, in intent | What auditors want to see | How a pentest satisfies it |
|---|---|---|---|
| A.8.8 — Management of technical vulnerabilities | Identify, assess, and treat vulnerabilities in deployed systems in a timely way | Evidence that you actively search for vulnerabilities — not just wait for them | A pentest proves, with an exploit per finding, that you actively search rather than only run a scanner |
| A.8.29 — Security testing in development and acceptance | Test security requirements during development and before acceptance | Signed test reports for major releases and architectural changes | A pentest per major release delivers exactly that documented acceptance evidence |
A.8.29 is a consolidation in the 2022 edition: the older controls A.14.2.8 (system security testing) and A.14.2.9 (system acceptance testing) from ISO 27001:2013 were merged into one control. The breakdown at ISMS.online describes that security testing must be integrated across the development lifecycle and documented before acceptance. In practice that means: anyone shipping a security-relevant release or an architectural change should be able to produce a test report.
A.8.8 targets ongoing operations. Here the difference between a scan and a pentest is decisive — more on that next.
What do auditors actually accept?
Not every security test counts as evidence. Auditors check three properties before a report passes as evidence for A.8.8 or A.8.29: Was the test conducted independently? Is every finding proven, not merely flagged? Is there a signed, dated report?
A plain vulnerability scan fails these criteria. A scanner finds known patterns and produces a list of potential vulnerabilities — without verifying whether they are actually exploitable. But that verification is the core of the evidence. A finding without an exploit proof is an alert, not a confirmed risk.
What matters in the audit comes down to three points:
- Independence: the test is conducted by a party that was not involved in building or operating the system — external, or clearly separated internally.
- Proof of concept per finding: every reported vulnerability is reproducibly proven, not just inferred from a scan.
- Signed, dated report: the report names scope, methodology, findings, and date — and is producible as a document.
DeepMantis delivers exactly this profile: an audit-ready PDF report with a reproducible proof of concept per finding, conducted as an external, independent test. Verification runs in isolated browser instances per finding — the report contains the proof, not just the claim.
How often must you test for ISO 27001?
The standard sets no fixed frequency. But A.8.8 and A.8.29 imply a clear pattern: test at major releases and architectural changes — and at least annually to cover ongoing operations. Auditors expect your ISMS not to rest on a two-year-old test report.
Plan two triggers in:
- Event-based: before the acceptance of every security-relevant major release, or after an architectural change — the direct implementation of A.8.29.
- Periodic: at least annually for production systems — covering A.8.8 in ongoing operations.
If your organisation is also NIS2-regulated, the requirements overlap. NIS2 requires regular assessment of the effectiveness of technical measures; a single pentest cycle satisfies both frameworks at once. The details are in the sibling article on NIS2 penetration testing requirements — a shared test plan saves effort when both standards apply.
For teams shipping weekly, an annual snapshot is too coarse. Continuous testing keeps the evidence current without costing new person-days per run.
What does an ISO 27001-ready pentest cost?
The price is no different from other pentests — what matters is that the report is audit-ready. A full breakdown of market ranges and day rates is in the penetration testing cost article; here, just the ISO 27001 framing.
Manual providers often bill an audit-ready report as 1–3 additional person-days on top. At DeepMantis, the audit-ready report is included in every tier — no surcharge for the form the audit requires. The public price list starts at €890 for a single-surface application and reaches €7,500 for a distributed system with regulated data. Every tier delivers the proof of concept per finding that makes A.8.8 and A.8.29 evidence defensible in the first place.
Important for scope planning: DeepMantis tests web applications and APIs. Binary exploitation, mobile pentests, social engineering, and physical access testing are deliberately out of scope. If your ISMS scope covers those areas, you need a supplementary manual test for them.
Frequently asked questions about ISO 27001 and pentests
Is a vulnerability scan enough for ISO 27001?
No. A scan lists potential vulnerabilities but does not verify whether they are exploitable. A.8.8 requires active vulnerability management, and auditors want to see proof that you find and assess vulnerabilities — not just file a scanner report. The exploit proof per finding is the difference between an alert and a confirmed risk.
Is a pentest mandatory for ISO 27001 certification?
Literally no, in practice almost always yes. The standard names no pentest, but A.8.8 and A.8.29 are hard to evidence without documented security testing. In theory you could provide other evidence — in practice a signed pentest report is the path of least resistance in the audit.
Which ISO 27001 controls relate to penetration testing?
A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) from Annex A:2022. A.8.29 consolidates the former controls A.14.2.8 and A.14.2.9 from the 2013 edition. The implementation guidance is in ISO 27002:2022.
Is an internal pentest enough as evidence?
Possible, but risky. Auditors treat independence as a quality criterion — the testing party should not have been involved in building or operating the system under examination. An external, independent test — manual or autonomous — produces more usable evidence than an internal review by the same team that built the system.
As of June 2026. Control IDs and wording are paraphrased from ISO/IEC 27001:2022 Annex A and the implementation guidance of ISO/IEC 27002:2022; the official standard text is paywalled. DeepMantis methodology and scope limits are documented on the security page.
