What an ISO 27001 penetration test report must contain

What the report is for

A penetration test report has three readers and they want different things. The engineer wants reproduction steps. The risk owner wants a severity they can compare with everything else in the register. The auditor wants to follow one finding all the way from discovery to closure and see that the process worked. Most reports serve the first reader well and the other two badly, which is why an otherwise good test can be weak evidence.

The specification below is written for the third reader, because that is the one who decides whether your evidence pack holds. None of it is a requirement of ISO/IEC 27001, which specifies no report at all. All of it exists because of what clause 9.1 asks you to evaluate and what clause 6.1.3 asks you to do with the result.

One: a scope statement traceable to the ISMS

The report must state what was tested, in terms that map onto your certificate. Systems named the way your ISMS names them, then the technical identifiers: hostnames, address ranges, cloud accounts, application bundle identifiers, API base paths. Then the perspectives tested, including which authenticated roles were exercised.

And then the exclusions, each with a reason. Provider infrastructure you are not permitted to test. Denial-of-service testing you deliberately declined. Systems outside the ISMS scope. A silence where an exclusion should be reads as an oversight, and an auditor who cannot tell the difference will assume the worse case.

Add one sentence naming the ISMS scope statement and the Annex A controls the test is intended to evidence. That sentence is the difference between a technical document and a piece of audit evidence, and it costs the tester nothing to write.

Two: dates that are still current

The test window and the report date, both on the cover. Two dates, because an eight-week gap between the last day of testing and the issue date tells an auditor something about the supplier and about how much of the report reflects a system that has since changed.

The hard rule is that the report must postdate your last significant change. A report describing an architecture you migrated away from is not evidence about your current controls, however good it was at the time. This is also why a single annual test is fragile for organizations shipping weekly: by the surveillance audit, the tested system and the running system have diverged.

Three: a named, versioned methodology

Name the methodology and its version. For web and API work, the OWASP Web Security Testing Guide, currently version 4.2, published 3 December 2020, which gives you stable identifiers of the form WSTG-INFO-02 to cite against individual checks. For the overall process, NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment.

NIST SP 800-115 is worth citing because it defines the shape of the engagement in language an auditor can follow. It describes four phases of penetration testing. In the planning phase, in its words, “rules are identified, management approval is finalized and documented, and testing goals are set”, and no actual testing occurs. Discovery follows, then the attack phase, with a documented loop back from attack into further discovery as new access reveals new targets. And, importantly for report quality, “the reporting phase occurs simultaneously with the other three phases of the penetration test”, which is why a supplier who writes the report weeks afterwards from memory produces a thinner document.

What you are avoiding is the phrase “industry standard methodology” with nothing behind it. It tells the reader nothing, and an auditor who notices it will start asking what else in the pack is decorative.

Four: signed rules of engagement

Authorization to test, the timing windows, systems explicitly out of bounds, emergency contact routes, and the handling rules for anything sensitive discovered. This document is usually treated as contractual paperwork. In audit terms it is evidence for A.8.34, the control governing how audit tests on operational systems are planned and agreed so that they do not disrupt the business.

Keep it with the report rather than in a contracts folder. It is also the artefact that answers the awkward question of what would have happened if the test had caused an outage, which is a question a thorough auditor does ask.

Five: severity on a public scale, then on yours

Use a stated, published scale so the numbers mean something outside the engagement. CVSS v4.0 is the defensible default. The current specification document, version 1.2 of 18 June 2024, defines four metric groups, Base, Threat, Environmental and Supplemental, and the qualitative bands most people know: none at 0.0, low from 0.1 to 3.9, medium from 4.0 to 6.9, high from 7.0 to 8.9 and critical from 9.0 to 10.0.

Then do the part almost every report skips. Re-express each finding on your own risk criteria. Clause 6.1.2 requires the organization to establish and apply its own information security risk criteria, and a CVSS base score knows nothing about your asset values, your impact scale or your risk appetite. A report that stops at CVSS hands the ISMS manager an unfinished job, and the auditor will notice that the risk register severities and the report severities do not agree.

In practice this is a two-column table: the tester supplies the technical score and vector, and you or the tester supplies the mapped rating on your scale, with a note where the two diverge. A finding that is medium on CVSS and high on your scale, because the affected asset is your most sensitive, is exactly the kind of reasoning an auditor wants to see recorded.

Six: reproducible evidence for every finding

For each finding: the affected asset, the request and response or the exact command, the observed result, and a screenshot where a screenshot adds something. Enough that a competent third party could reproduce the issue, and enough that an auditor can see it was demonstrated rather than inferred.

This is where scanner exports fail. “Server discloses version 1.2.3, which is affected by CVE-2024-XXXX” is a hypothesis. It may be right. It is not a demonstration, and a report full of unconfirmed hypotheses gives you a remediation backlog rather than evidence of control effectiveness. It also erodes trust in the findings that were confirmed.

A good report is explicit about which findings were exploited, which were confirmed by inspection and which are advisory. Three categories, labelled. That distinction alone raises the quality of the remediation conversation.

Seven: remediation guidance a ticket can be cut from

Specific to the finding and to the platform in front of you, not a link to a generic hardening guide. If the guidance cannot become a task with an owner and an estimate, it will not become a risk treatment action either, and the finding will sit in the report until the next test finds it again.

Where a fix is genuinely hard, the report should say so and offer a compensating control. That is more useful than an instruction nobody can follow, and it gives the risk owner a real decision to record.

Eight: dated retest evidence

The single most common gap in the evidence packs auditors see, and the cheapest one to close. A report listing fourteen findings, presented at surveillance with no retest, is evidence that fourteen things were wrong. The same report with a retest annex is evidence that your vulnerability management control works.

The annex needs a date, the list of findings retested, the outcome for each, and a note on anything accepted rather than fixed. Findings closed by risk acceptance are fine, provided the acceptance is recorded by someone with authority to accept it. Findings marked closed with no verification are worse than open ones, because they show a process that reports success without checking.

Buy retest in the original engagement. It is always cheaper scoped up front, and its absence is the thing most likely to weaken an otherwise strong pack.

Nine: the trail into the risk treatment plan

Finding, risk register entry, owner, due date, closure record. Auditors follow this trail, and the report should make it a short walk. In practice that means each finding carries a stable identifier that also appears in the risk register, so the two documents can be laid side by side without translation.

This is the mechanism clause 6.1.3 and clause 8.3 describe: risk treatment is planned and implemented, and the results are retained as documented information. Clause 10.1 and 10.2 then expect nonconformities to be corrected and the correction to be verified. A report that never reaches the risk register has satisfied none of that, no matter how good the testing was.

Ten: a customer-shareable summary

Separate from the technical report, a one- or two-page summary or attestation letter: who tested, when, what scope, what methodology, the severity distribution, and a statement that findings were remediated or accepted. No exploit paths, no unremediated detail, no internal hostnames.

This exists for the security questionnaires that arrive after certification, and it prevents the worst habit in the industry, which is emailing a full technical report to a prospect. It also has an ISO life: it is a reasonable artefact to hold under A.5.20 and A.5.22 when your own customers ask what assurance you can give them.

The specification as a table

Report sections, what they serve, and how they fail

Section	Serves	Failure mode
Scope statement	ISMS scope, clause 6.1.3	The certificate covers a platform, the report covers one URL
Test window and report date	Clause 9.1	The report predates the last significant change
Named methodology and version	A.8.29	“Industry standard methodology” with nothing behind it
Signed rules of engagement	A.8.34	No written authorization for testing production
Severity on CVSS and on your criteria	Clause 6.1.2, clause 9.1	CVSS only, so the risk register disagrees with the report
Reproducible evidence	A.8.8	Scanner hypotheses presented as confirmed findings
Remediation guidance	Clause 6.1.3, clause 8.3	Advice too generic to become a task
Dated retest annex	A.8.8, clause 10.2	Findings closed in a spreadsheet with no verification
Risk treatment trail	Clause 6.1.3, clause 10.1	The report never reaches the risk register
Customer-shareable summary	A.5.20, A.5.22	The full technical report is sent to a prospect

What actively damages a report

Beyond the missing sections, a few things make an auditor read the rest of your pack more sceptically.

• An unedited scanner export. Recognizable within seconds, and it invites the question of what else was outsourced to a tool.
• A severity scale invented for the engagement. Four colours with no definitions is not a scale.
• Findings with no affected asset. If it cannot be located, it cannot be fixed or retested.
• An executive summary that grades your ISMS. A tester is not in a position to assess an ISMS, and a report claiming the organization is “ISO 27001 compliant” is the fastest way to make an auditor start hunting for other overstatements.
• Marketing in the body. Pages about the supplier’s methodology maturity model displace pages about your systems.

The useful test before you accept a report: hand it to somebody in your own organization who was not involved, and ask them to pick one finding and tell you what was wrong, where, how bad, what was done about it and when it was verified. If they can do that from the document alone, the auditor can too.

Getting the scope right in the first place is the other half of this problem, and it is covered in how to scope an ISO 27001 penetration test. If you are still deciding whether you need a test at all, start with does ISO 27001 require a penetration test.