info@cetonix.com +91 (966) 512-1196 Mon–Fri, 09:30–18:00 IST
HomeInsightsUsing a Penetration Test as ISO/IEC 27001 Audit Evidence

Using a Penetration Test as ISO/IEC 27001 Audit Evidence

Annex A 8.8 and 8.29 are where a test report becomes audit evidence — provided the scope, timing and independence line up.

Compliance Cetonix
Using a Penetration Test as ISO/IEC 27001 Audit Evidence

Organisations frequently commission a penetration test for an ISO/IEC 27001 audit and then find the report does not evidence what they needed. The test was competent; the fit was wrong. Three things determine whether a report works as audit evidence, and all three are decided at scoping.

The two controls

A.8.8 — Management of technical vulnerabilities. Information about technical vulnerabilities of information systems in use shall be obtained, the organisation’s exposure to such vulnerabilities evaluated, and appropriate measures taken.

Note the three verbs: obtain, evaluate, act. A test report satisfies the first. It supports the second. It does not, by itself, satisfy the third — that requires evidence of what you did about the findings.

A.8.29 — Security testing in development and acceptance. Security testing processes shall be defined and implemented in the development life cycle.

The word doing the work here is processes. A single test evidences an activity. The control asks for a defined and implemented process — testing that happens at defined points, triggered by defined events, with defined handling of results. An auditor examining A.8.29 will ask when you test, what triggers it, and what happens to findings.

Scope alignment

The test must cover systems inside your ISMS scope. This sounds obvious and is the most common mismatch we see: a certificate scoped to the production platform and data centre operations, and a test covering the corporate website.

Before scoping a test for audit purposes, read your Statement of Applicability and your scope statement, and make sure the systems named there are the systems being tested. Where your ISMS scope covers multiple systems, a test of one does not evidence the others, and your auditor will notice.

Timing

Evidence must be current relative to the audit, and findings need time to be closed.

The sequencing that works: test early enough that critical and high findings can be remediated and retested before the audit. A report full of open critical findings is evidence that you evaluated your controls and that they failed — technically responsive to A.8.8, and not the impression you want at Stage 2.

A practical pattern is testing about three months before certification or recertification audit, which leaves room for remediation and a retest.

Independence

Testing should be performed by a party independent of the team that built and operates the system. Internal testing can contribute, but an auditor will weight independent testing more heavily.

A specific case worth raising deliberately: where the organisation arranging your certification audit also performs your penetration test, the same commercial party sits on both sides of the evidence. That is a conflict, and the right way to handle it is disclosure — to you, and to the conformity assessment body, so it can apply its own impartiality controls under ISO/IEC 17021-1 clause 5.2. The CAB may decide not to accept the report as evidence, and that decision is theirs to make.

If you want maximum defensibility at surveillance, using unrelated providers for certification and for testing is the cleanest arrangement. It is worth raising with your CAB before appointment rather than at surveillance.

What to present

For A.8.8: the report, the risk evaluation of the findings, the remediation record, and retest evidence. The chain from “we found this” to “we did this about it” is what the control asks for.

For A.8.29: the documented testing process — when testing occurs, what triggers it, who performs it, how findings are handled and by when — with the report as evidence that the process was followed. Secure coding under A.8.28 sits alongside this, and a secure code review evidences both.

The recurring mistake

Treating the test as the evidence. The test is an input. The evidence is the process it belongs to: how you decided what to test, what you concluded, what you changed, and how you verified the change. Organisations that present the whole chain pass this part of the audit without difficulty. Organisations that present a PDF are asked for the rest of it.

← What a Penetration Test Report Should Contain — and What It Should Not