ISO 27001 penetration testing: what Annex A actually requires.
ISO/IEC 27001:2022 never uses the phrase "penetration test". Two Annex A controls make one the evidence a certification auditor expects, and your own Statement of Applicability is what commits you. This page explains the mechanism, and what the report has to contain. New to the format first? See a real sample report.
No clause makes a penetration test mandatory.Your Statement of Applicability does.
ISO 27001 is risk-based, not prescriptive. It does not hand you a list of tools. That is a genuine feature of the standard, and it is why "is a pentest required?" has no clean yes or no.
The route to the answer runs through your own documentation. Annex A control A.8.29, security testing in development and acceptance, requires security testing to be defined and performed across the development lifecycle. Your Statement of Applicability has to state which Annex A controls apply to you and justify how they are implemented. For any organisation with internet-facing systems or software it develops itself, A.8.29 is in scope, and once you have declared it in scope, you have to evidence it.
If you cannot show technical testing evidence at that point, Stage 2 becomes uncomfortable.
So the accurate position:
- Not mandated by any clause
- Named explicitly in ISO 27002:2022's implementation guidance
- Effectively binding once A.8.29 and A.8.8 are declared applicable in your SoA
A.8.8 and A.8.29 do the binding.
| Control | What it requires | What a pentest evidences |
|---|---|---|
| A.8.8 — Management of technical vulnerabilities | Obtain information about vulnerabilities in systems in use, evaluate your exposure, take appropriate measures | That you are actively finding exploitable weaknesses, not only running a scanner against a CVE list |
| A.8.29 — Security testing in development and acceptance | Security testing processes defined and implemented across the development lifecycle | Testing performed before release, with results fed back into development |
ISO 27002:2022, which carries the implementation guidance for the Annex A controls, states plainly under control 8.8 that organisations should perform periodic, documented penetration tests, carried out either by internal staff or by an independent third party.
Add Clause 9.1 (monitoring, measurement, analysis and evaluation) and the picture is complete: your ISMS has to demonstrate that its technical controls actually work, not merely that they are documented.
A documented control proves it exists. A pentest proves it holds.
These are the 2022 control references. If you hold a certificate issued under ISO 27001:2013, the equivalents are A.12.6.1 (management of technical vulnerabilities), A.14.2.8 (system security testing) and A.18.2.3 (technical compliance review). The 2022 revision merged A.14.2.8 and A.14.2.9 into the new A.8.29. Check which edition your SoA is written against before mapping findings.
Plan backwards from your Stage 2 date.
Before Stage 2. Stage 1 reviews your documentation; Stage 2 examines whether the ISMS works in practice. Technical testing evidence belongs in place before Stage 2, with enough margin to remediate what is found.
Before recertification. Certificates run on a three-year cycle. Recertification is the point where stale evidence gets challenged.
For surveillance audits. Annual surveillance audits typically expect current evidence rather than the same report for three years running. Most organisations test annually.
After significant change. A new authentication provider, a major architecture change or a new externally exposed application resets the question.
Turnaround from intake to final report is typically 1 to 3 weeks. Plan backwards from your Stage 2 date, allowing time to patch and retest.
What an auditor looks for.
For the report to serve as ISMS evidence rather than a loose PDF in a folder, an auditor looks for:
- A scope statement that matches your ISMS boundary as defined in the SoA. A test of systems outside the certified scope evidences nothing.
- A current date. Within twelve months is the working expectation.
- Methodology and named tester qualifications. Against which standard, by whom, with which credentials.
- Findings with severity ratings and business impact.
- Reproduction steps your development team can act on.
- A remediation log and retest evidence confirming that fixes actually work.
- Documented rules of engagement agreed before testing.
- Findings mapped to the Annex A controls they evidence, so the link to your SoA is explicit rather than implied.
Automated scans alone do not satisfy A.8.29. Scanners identify known vulnerabilities; they do not test business logic, chain exploits, or model attacker behaviour. ISO 27002's own guidance for A.8.8 distinguishes scanning tools from penetration tests and calls for both.
A report that ties directly to your SoA.
- Fully manual testing. OWASP and PTES methodology, OSCP and eWPTxv2 certified, MSc Cyber Security. Not a scanner you could run yourself.
- Retest included in the fixed price. After remediation I verify the findings are genuinely closed and issue a written retest declaration. That is the closing evidence your auditor asks for, and it is not a separate quote.
- Annex A mapping appendix. For compliance-scoped engagements, each finding is mapped to the control it evidences (A.8.8, A.8.29, and others where relevant), so the report ties directly to your SoA.
- Executive summary and technical detail in one document. Usable by management and developers without translation.
- Digitally signed report. Your certification body or auditor can verify authenticity independently at re-sync.nl/verify, in their own browser, with no upload.
- NDA standard. Rules of engagement agreed in writing before testing starts.
Fixed price based on scope.
No hourly billing, no separate retest invoice.
| Scope | Indicative price | Typical fit |
|---|---|---|
| Security Quick Scan | from €1,000 | One day, focused. Establishes whether a full test is needed. |
| Compact | from €2,500 | One web application or API with limited roles. |
| Standard | from €4,500 | SaaS product or portal with multiple roles. |
| Extensive | from €7,500 | Complex platform, multiple applications or infrastructure. |
An ISO 27001 engagement is scoped for ISMS evidence rather than coverage alone. It adds Annex A control mapping, a report aligned to your certified boundary and Statement of Applicability, and a retest declaration that closes the loop. In practice most certification-scoped work falls in the Extensive band, from €7,500, and rises from there for larger or multi-application environments.
ISO 27001 questions, answered precisely.
Does ISO 27001 require a penetration test?
Which Annex A controls does a pentest evidence?
Can I use an internal test instead of an external one?
Is a vulnerability scan enough?
How often should we test?
Do you have ISO 27001 experience?
We are also pursuing SOC 2. Can one test cover both?
Testing for ISO 27001 certification?
Tell me what is in scope and when your Stage 2 or surveillance audit is scheduled. You will hear back within one business day.
Book a free intake → Pursuing SOC 2 too?