What a penetration test report contains

A penetration test simulates, with your written authorization, what an attacker would try against your websites, applications or network. The deliverable is not the list of tools used: it is a report your management can read in ten minutes and your technical team can follow step by step. Here is what it must contain, and what should worry you if it is missing.

1. Scope and method

The first page says what was tested, what was not, when, and under which rules. An honest scope names the systems (domains, addresses, applications, accounts provided), the testing window, the excluded techniques (denial of service or social engineering, for example) and the starting level of knowledge: black box (no information), grey box (a user account) or white box (source code and documentation).

The method rests on public frameworks. NIST SP 800-115 describes the phases of a technical assessment (planning, discovery, attack, reporting) and serves as the general reference. For web applications, the OWASP Web Security Testing Guide (stable version 4.2, with 5.0 in development) lists the test categories: configuration, authentication, session management, input validation, business logic, and so on. A report that names its framework lets you compare two tests, or two suppliers, on the same basis.

2. The executive summary

One page, no jargon. It answers three questions: can an attacker get in, how far can they go, and what stops them today? It gives the number of findings per severity and the two or three decisions to make this week. If the summary runs five pages or repeats the technical details, it is not doing its job.

3. Findings ranked by severity

Each finding has a title, a severity, the affected systems, a description and the concrete business impact ("an unauthenticated visitor can read other customers' invoices" rather than "SQL injection on the id parameter").

Severity is scored with a recognized system, usually CVSS (Common Vulnerability Scoring System, published by FIRST). CVSS measures technical severity; the report must also state the risk in your context, because a "critical" vulnerability on an isolated test server is not as urgent as the same flaw on your customer portal. Both ratings must appear, with their justification.

4. Evidence

For each finding: the reproduction steps, the requests or commands used, screenshots, and what was obtained. Without evidence, your team can neither verify the finding nor confirm the fix. Evidence must be scrubbed of real personal information; if the tester accessed customer data to demonstrate impact, the report says so and states what was done with that data.

5. Recommendations and remediation plan

One recommendation per finding, written for the person who will fix it: what to change, where, and how to verify it is done. Good recommendations distinguish the immediate fix (close the hole) from the root cause (the process that let it through). The plan orders fixes by risk and effort, not by order of discovery.

6. The retest

A penetration test ends with a verification of the fixes. The final report, or an addendum, states for each finding whether it is fixed, partially fixed or still open, with the retest date. That is the document you show a customer, an insurer or an auditor.

What the standards ask for

If you handle payment card data, PCI DSS requires penetration testing under a defined methodology, on the internal and external networks of the cardholder data environment, at least annually and after any significant change, and the correction of exploitable vulnerabilities found. SOC 2 and ISO/IEC 27001 audits impose no report format, but your auditors will want to see the scope, the date, the findings, the remediation plan and the retest: exactly the six sections above.

Cadence matters as much as format. A test is a photograph of one moment; a site that changes every month deserves a new photograph after each significant change, and a yearly test at the very least. Keep every report: the series shows whether the same categories of findings come back, which is the real measure of whether your development and operations practices are improving.

What should worry you

• A report with no written scope or date: you cannot know what was covered.
• Raw scanner output presented as a penetration test: automated scanning is a step, not the test.
• Severities without justification or score: impossible to prioritize.
• No reproducible evidence: impossible to verify.
• No mention of the real data consulted: a confidentiality problem and, in Québec, a Law 25 question.
• No retest planned: the test measures a state; it improves nothing until something is fixed and verified.

How we work

Our penetration tests follow this structure. The scope is agreed in writing before the first packet is sent, findings are rated with CVSS and placed in your context, no real data is kept after delivery, and the retest is part of the engagement. The report is written for two readers: management, who decides, and the technical team, who fixes.