Penetration Testing for ISO 27001: What Annex A Requires

If you are pursuing or maintaining certification, penetration testing for ISO 27001 is one of the cleanest ways to demonstrate that your technical controls are not just documented but actually effective. ISO/IEC 27001:2022 never uses the words “penetration test”, which leads some organisations to assume it is optional. In practice, several Annex A controls expect you to identify and verify the treatment of technical vulnerabilities, and an external test is the evidence auditors recognise most readily. This guide explains exactly which controls apply, what an auditor looks for, and how to scope a test that produces usable certification evidence. Our ISO 27001 penetration testing service page is the parent guide this post supports.

Does ISO 27001 require a penetration test?

Strictly, no single clause says “you must run a penetration test”. ISO 27001 is a risk-based standard: it requires you to identify information security risks, select controls to treat them, and then demonstrate those controls are implemented and effective. Penetration testing for ISO 27001 is not mandated by name, but it is the method most organisations choose to satisfy the technical-vulnerability and testing controls, because the alternative is to argue, with an auditor, that an untested control is nonetheless working.

The controls that drive this sit in Annex A of ISO/IEC 27001:2022, with detailed guidance in ISO/IEC 27002:2022. Two carry most of the weight. A.8.8, management of technical vulnerabilities, expects you to obtain information about vulnerabilities in your systems, evaluate your exposure and take appropriate action. A.8.29, security testing in development and acceptance, expects security testing to be defined and performed across the development life cycle. A penetration test produces direct evidence for both. Once you have decided these controls apply to you, which for almost any organisation handling data of value they will, a test stops being optional in any practical sense.

Which Annex A controls a pen test evidences

It helps to be precise about which controls a test maps to, because that mapping is what your Statement of Applicability and your auditor will care about. The table below sets out the Annex A 2022 controls most directly supported by penetration testing, and what the test contributes to each.

Annex A 2022 control	What it covers	What a pen test contributes
A.8.8 Management of technical vulnerabilities	Obtaining, evaluating and acting on vulnerability information	Independent identification of exploitable vulnerabilities and their real-world impact, plus retest evidence that fixes worked
A.8.29 Security testing in development and acceptance	Defining and running security testing through the life cycle	Structured manual testing of applications and infrastructure before and after release
A.8.9 Configuration management	Establishing and monitoring secure configurations	Findings on hardening gaps, default credentials and insecure services
A.8.25 Secure development life cycle	Building security into development	Application-layer findings that feed back into secure coding and review
A.5.36 Compliance with policies and standards	Reviewing that controls operate as intended	Independent assurance that technical policy is enforced in practice, not just on paper

The point of this mapping is that a single, well-scoped engagement can supply evidence across multiple controls at once. When you commission the test, ask your provider to reference these control numbers in the report so the link to your Statement of Applicability is explicit. That small request turns a generic security report into a document your certification auditor can read against your controls directly.

What an ISO 27001 auditor actually looks for

Certification and surveillance auditors are not penetration testers, and they are not assessing the technical detail of each finding. They are checking that you have a defined, repeatable process and that you act on what it produces. In our experience supporting clients through audit, an assessor reviewing your technical-vulnerability controls is looking for a short, consistent chain of evidence.

• A defined scope and cadence: evidence that you decided what to test and how often, usually annually and after significant change, and that this is written into a policy or procedure rather than improvised.
• An independent, competent test: a report from a credible provider, ideally one whose accreditation and testers can be verified, so the assurance is external rather than self-asserted.
• Risk-rated findings: issues prioritised by severity so the auditor can see you are treating the serious ones first, consistent with your risk methodology.
• A tracked remediation trail: a record showing each finding was triaged, assigned, fixed or formally risk-accepted, with dates, not a report that was filed and forgotten.
• Evidence of closure: a retest or other confirmation that the high and critical issues are actually resolved, closing the loop on A.8.8.

The single most common gap we see is the last two. Organisations commission a competent test, then leave the findings sitting in a PDF. An auditor reading A.8.8 wants to see the action you took, not just the vulnerabilities you found. A test that ends without a remediation trail and a retest leaves the control only half-evidenced.

How often should you test for ISO 27001?

ISO 27001 does not prescribe a frequency, but auditors and the wider community have settled on a sensible default: at least annually, and additionally after any significant change to systems in scope. “Significant change” is the phrase that matters. A major application release, a migration to a new cloud platform, a substantial network redesign or the addition of a new internet-facing service all reset your risk and, in most Statements of Applicability, trigger a fresh test of the affected scope.

Annual testing aligns naturally with the ISO certification cycle: an initial certification audit followed by annual surveillance audits and a three-yearly recertification. Running a test on a yearly rhythm means you always have current evidence to hand when an auditor asks, rather than scrambling to commission one in the weeks before an assessment. For organisations releasing software frequently, A.8.29 points towards testing tied to the development life cycle as well, so security testing happens at release rather than only once a year.

Scoping a pen test for certification evidence

Scope is where ISO 27001 testing goes right or wrong. Your test scope should follow the boundary of your Information Security Management System and the assets your risk assessment flagged as significant, not an arbitrary slice chosen to keep the invoice down. Under-scope and you leave material risk untested, which an auditor may challenge; over-scope and you pay for testing of assets that carry little risk and sit outside your certified boundary.

A defensible scope is built from your asset inventory and risk assessment. For most organisations that means the internet-facing infrastructure, the web applications and APIs that handle sensitive data, the corporate and cloud environments where that data lives, and any system your risk assessment rated as high impact. The cost of the engagement is driven by that scope, specifically the number of tester days a competent team needs to cover it properly, rather than by any per-asset price list. A focused external and web application test is a small number of days; a broad estate spanning multiple applications, cloud accounts and an internal network is several more. We break the cost mechanics down in detail on our UK penetration testing cost guide, so you can sanity-check a quote against scope rather than guessing.

One practical tip: scope the test to match your ISMS boundary as documented in your Statement of Applicability, and say so to your provider. When the report covers exactly the systems your certification covers, the evidence lines up cleanly and your auditor spends less time reconciling what was tested against what is certified.

How EJN Labs approaches ISO 27001 penetration testing

EJN Labs is a CREST-accredited UK penetration testing firm, and we are ourselves certified to ISO 27001 and ISO 9001, with Cyber Essentials and Cyber Essentials Plus alongside. That means we run our own information security to the standard you are evidencing, and we understand the audit from both sides of the table. Every engagement is delivered by senior and principal testers, never juniors, so the report carries the weight an assessor expects.

For certification work we map findings to the relevant Annex A 2022 control numbers, risk-rate every issue against a clear methodology, and write reports designed to drop straight into your audit evidence. Pricing is fixed and built from a defined scope agreed on a named scoping call, not an open-ended day rate that drifts. Crucially, we include a free retest so you can prove to your auditor that high and critical findings are actually closed, which is the part of A.8.8 most organisations struggle to evidence. You can see the full approach on our ISO 27001 penetration testing page, or review the wider range on our services overview.

Frequently Asked Questions

Is penetration testing mandatory for ISO 27001 certification?

No single clause makes penetration testing mandatory by name, because ISO 27001 is risk-based rather than prescriptive. In practice, the technical-vulnerability and security-testing controls in Annex A, principally A.8.8 and A.8.29, expect you to identify and verify the treatment of technical vulnerabilities, and an independent penetration test is the evidence auditors recognise most readily. For almost any organisation handling data of value, a test is the practical way to satisfy these controls.

Which Annex A controls does a penetration test help evidence?

A penetration test most directly supports A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance). It also contributes to A.8.9 (configuration management), A.8.25 (secure development life cycle) and A.5.36 (compliance with policies and standards). Asking your provider to reference these control numbers in the report links the findings cleanly to your Statement of Applicability.

How often do I need a pen test for ISO 27001?

ISO 27001 does not set a fixed frequency, but the accepted default is at least annually and additionally after any significant change to systems in scope, such as a major release, a cloud migration or a new internet-facing service. Annual testing aligns with the certification and surveillance audit cycle, so you always have current evidence ready when an assessor asks.

What should the scope of an ISO 27001 pen test be?

Scope the test to your Information Security Management System boundary and the assets your risk assessment rated as significant, typically your internet-facing infrastructure, the web applications and APIs handling sensitive data, and the cloud and corporate environments where that data lives. Matching the test scope to your Statement of Applicability keeps the evidence aligned with what your certification covers.

Does the report need to map to specific ISO 27001 controls?

It does not have to, but it should. A report that references the relevant Annex A 2022 control numbers, risk-rates each finding and records remediation lets an auditor read the evidence directly against your controls. Without that mapping, an assessor has to reconcile a generic security report against your Statement of Applicability themselves, which slows the audit and weakens the link to A.8.8.

Get a test that produces ISO 27001 evidence

If you need penetration testing for ISO 27001 that an auditor will accept without question, the right test is independent, control-mapped and closed out with a retest. EJN Labs delivers exactly that, at a fixed price built from a scope agreed on a short call, with senior and principal testers and a free retest to prove your fixes worked. Request your CREST pentesting quote and we will scope it against your ISMS boundary, or read more first on our ISO 27001 penetration testing page.