What a penetration test report should contain

A penetration test is only as useful as its report. The testing itself may take a few weeks; the report is what your IT team, your management and your auditors will use for months afterwards. Yet many organizations accept reports that are long, generic and hard to act on — sometimes little more than scanner output with a cover page.

Whether you are comparing proposals, reviewing a report you have just received or writing requirements for a tender, this checklist will help you judge whether a report does its job.

1. A clear statement of scope and rules of engagement

The report should say exactly what was tested and what was not. Look for:

• The systems, applications, IP ranges and user roles in scope, and any exclusions.
• The testing window, including dates and times.
• The type of test: external, internal, web application, mobile, wireless or social engineering.
• The starting knowledge and access given to testers (black box, grey box or white box).
• Any limits agreed with you, such as no denial-of-service or no testing of production data.

Without this, you cannot tell whether a clean result means the system is secure or simply that it was not tested.

2. A methodology you can recognize

A good report names the method it followed and explains how it was applied. For web applications, that is usually the OWASP Web Security Testing Guide; for infrastructure, recognized frameworks such as NIST SP 800-115 or the Penetration Testing Execution Standard. The point is not the name itself but evidence that testing was structured and repeatable, not improvised.

3. An executive summary a manager can read in five minutes

Senior management will rarely read past the first two pages. The executive summary should explain, without jargon:

• The overall level of risk and what an attacker could realistically achieve.
• The most important findings, in business terms.
• Whether any issue needs urgent action.
• The main themes behind the findings, such as missing patches, weak passwords or poor segmentation.

If the summary is just a count of findings by severity, it is not doing its job.

4. Findings backed by evidence

Every finding should be reproducible. For each one, check that the report includes:

• A clear title and description of the weakness.
• The affected systems, URLs or parameters.
• Step-by-step reproduction details.
• Evidence such as screenshots, requests and responses, or command output — with sensitive data masked.
• References to the relevant weakness category, such as a CWE identifier or CVE record where one applies.

Findings without evidence are hard to verify, hard to fix and easy to dispute.

5. Severity that reflects your environment

Generic scores are a starting point, not an answer. A medium-rated vulnerability on an internet-facing system that handles payments may matter more than a critical one on an isolated test server. Good reports:

• State which rating system they used (for example, CVSS) and how they adjusted it.
• Explain the real-world impact in your environment.
• Show attack chains, where several lower-severity issues combine into a serious compromise.

Attack chains are often the most valuable part of a penetration test, because automated scanners cannot find them.

6. Remediation guidance your team can follow

“Apply patches” and “follow best practice” are not remediation guidance. Each finding should say what to change, where and how — ideally with configuration examples or links to vendor documentation. Where a full fix will take time, the report should suggest interim measures that reduce risk in the meantime.

7. Positive observations and limitations

A balanced report also records what worked: controls that blocked attacks, alerts that fired, users who reported a phishing test. This helps you protect what is already effective. It should also state any limitations, such as systems that were unavailable during testing or areas that could not be fully assessed.

8. A retest

The job is not finished when the report is delivered. Check whether the proposal includes a retest of fixed findings and a short updated report confirming which issues are closed. Auditors and regulators increasingly ask for this evidence.

9. Secure handling of the report itself

A penetration test report is a map of your weaknesses. Agree in advance how it will be delivered (for example, encrypted and to named recipients), how long the tester will keep your data and when it will be securely deleted.

Using this checklist

When you issue a request for proposal, ask bidders for a sanitized sample report and judge it against these points. It will tell you more about the quality of the work than any price comparison.

How we can help

Our penetration testing reports are written for two audiences — management and the engineers who fix the issues — and include retesting of remediated findings. If you want a broader view of weaknesses across your estate, a vulnerability assessment or configuration review can complement testing.