ISO 27001 Penetration Testing Guide

Which controls testing evidences

Two Annex A areas carry the weight. Technical vulnerability management requires that you obtain information about vulnerabilities in your systems, evaluate exposure, and take appropriate action. Security testing in development and acceptance requires that testing be part of how software reaches production.

Penetration testing evidences both, and also supports the management review and continual improvement clauses in the main body of the standard, because findings and their treatment demonstrate the management system operating rather than merely existing.

The statement of applicability is the anchor

ISO 27001 audits are conducted against what you said you would do. If your statement of applicability claims a control and your evidence does not support it, that is a nonconformity — and it is a worse outcome than having excluded the control with a documented justification.

So the useful sequence is to check what your statement of applicability commits you to, then scope testing to produce exactly that evidence. Testing more than your ISMS claims is optional; testing less than it claims is a finding.

How findings should enter your ISMS

Auditors are more interested in your process than in your findings. A report with twelve findings and a documented risk treatment decision for each is a strong result. A report with two findings and no evidence that anyone assessed or dispositioned them is weaker, because it demonstrates testing without demonstrating a management system.

Each finding entered in the risk register with its assessed risk, not just its technical severity
A treatment decision per finding — mitigate, accept, transfer or avoid — with an owner and a date
Retest evidence for items treated by mitigation
Documented justification for anything accepted, which is legitimate and expected
A link from the test into your management review inputs, closing the continual improvement loop

Certification, surveillance and recertification

The initial certification audit examines whether the management system is established and operating. Surveillance audits then check that it continues to operate, which means testing cannot be a one-off performed shortly before certification. An annual cadence with evidence of treatment between audits is what a surveillance auditor expects to find.

The 2022 revision

The 2022 revision restructured Annex A and introduced controls on areas including threat intelligence and secure coding. If your ISMS was built against the earlier structure, your control references will have changed even where your practice has not, and evidence mapped to the old numbering causes avoidable friction. We map findings to the structure your ISMS currently uses.

Common questions

Does ISO 27001 require penetration testing?

Not explicitly. The standard requires that technical vulnerabilities be managed and that security testing occur in development and acceptance, without naming penetration testing as the method. In practice it is the usual way organisations evidence those controls, and certification bodies expect some form of technical testing.

How often do we need to test for ISO 27001?

The standard does not set a frequency; your own ISMS does. Most organisations commit to annually and after significant change, and are then audited against that commitment. Choose a cadence you will actually maintain, because failing to meet your own documented frequency is itself a nonconformity.

Can we exclude penetration testing from our statement of applicability?

You can exclude controls with documented justification, but excluding technical vulnerability management is very difficult to justify for any organisation running software. It is usually easier and cheaper to satisfy the control than to defend its exclusion to a certification body.

Do you provide evidence formatted for our certification body?

We provide the report, scope statement, methodology description and retest evidence, mapped to the Annex A control references your statement of applicability uses. Certification bodies rarely mandate a format; what they check is that scope is defined, competence is evidenced, and findings have documented treatment decisions. We ask what your body has requested before scoping.

How does testing support our surveillance audits?

By demonstrating that the management system keeps operating rather than that it existed once. Surveillance auditors look for evidence generated since the last audit: testing performed at your committed frequency, findings entered in the risk register, treatment decisions taken, and mitigations retested. A single test before certification with nothing afterwards is a common source of nonconformity.

Should our statement of applicability name penetration testing?

It does not need to name the method, and naming it commits you to it. What your statement of applicability should do is claim the controls on technical vulnerability management and on security testing in development and acceptance, then let your documented procedures describe how you satisfy them. That gives you room to adjust method without amending the statement.

Does ISO 27001 certification mean our application is secure?

It means you have a functioning management system for information security, which is a genuine achievement and a different claim. Certification assesses process; it does not assert that any particular application is free of exploitable vulnerabilities. The two are complementary, and conflating them is a mistake we see in vendor security questionnaires regularly.

Let's scope your infrastructure.

Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.

Request a Technical Scope Direct line himanshu@wimd.in +91 88600 00832