31 October 2026 · 12 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
The Penetration Testing Report: What a Good One Contains, How Auditors Read It, and How to Spot a Bad One
The report is the only thing that survives a penetration test. The testers leave, the findings get fixed, and twelve months later the report is what your auditor, your customer and your board judge the engagement by. This guide walks through the anatomy of a report that serves all three, section by section, and explains what separates it from a scanner export with a cover page.
What a penetration testing report is for
A penetration testing report has four audiences with four different questions. The executive sponsor wants to know how exposed the organisation is and whether the money was well spent. The engineering teams want to know exactly what is broken, how to reproduce it and how to fix it. The compliance officer wants to know which control the finding affects and whether the evidence will satisfy the auditor. The customer or supervisor who later receives a summary wants assurance that a competent, independent party tested the right things and that what they found was dealt with. A good report answers all four without making any of them read the others' sections.
The report is also a legal and contractual document. It defines what was and was not tested, under which rules of engagement, on which dates, by whom. When a breach happens six months later through a system that was out of scope, the scope section is what determines whether the test was adequate or whether the organisation chose not to test the system that failed. Treat the report as the record of a decision, not only as a list of vulnerabilities.
Because the report outlives the engagement, its structure matters more than its length. The sections below are the ones every serious methodology (PTES, OWASP WSTG, NIST SP 800-115 section 7 on reporting, OSSTMM) agrees on, and the ones auditors have learned to look for.
Anatomy of a good penetration testing report
Eight sections, in the order a reader encounters them. If one is missing, ask why before you accept the report.
1. Management summary
One to two pages, written for someone who will not read the rest. It states what was tested and why, the overall risk posture in plain language, the number of findings by severity, the two or three issues that matter most and what they would allow an attacker to do, and the recommended priorities. No CVE numbers, no tool names. A good test of the summary: a board member can repeat its conclusion correctly after one reading.
2. Scope and rules of engagement
The exact systems, applications, IP ranges, environments (production, acceptance), user roles and credentials provided; what was explicitly excluded and why; the test dates and time windows; the testing position (external, internal assumed breach, authenticated as which roles); the depth (black, grey or white box); constraints such as no denial of service or no social engineering; and the escalation path used for critical findings during the test. Also the names and certifications of the testers. This section is what the auditor reads second, after the summary.
3. Methodology
The frameworks followed (OWASP WSTG and ASVS for web, OWASP MASVS and MASTG for mobile, PTES or NIST SP 800-115 for infrastructure, MITRE ATT&CK for internal and red team work), the phases executed, the balance of manual and automated work, and the tools used with their role. Methodology lets a reader judge coverage: a web application test that lists only automated scanning under methodology did not test business logic, and the report should say so.
4. Risk rating: CVSS v4.0 plus business context
Each finding carries a severity. The current industry standard is CVSS v4.0, published by FIRST in November 2023, which scores the base metrics (attack vector, complexity, attack requirements, privileges, user interaction, and impact on the vulnerable and on subsequent systems) and allows threat and environmental metrics to adjust the score to your situation. A good report states which metric groups were used (CVSS-B alone, or CVSS-BTE with threat and environmental context) and then adds a business-context rating: a medium CVSS finding on the payments database is not the same as a medium on the marketing site. Both numbers belong in the report, with the reasoning.
5. Findings with evidence and reproduction steps
One entry per finding, in a fixed format: title, affected asset, severity (CVSS vector and score plus business rating), description of the weakness, the attack scenario in one paragraph, step-by-step reproduction with requests, responses, commands and screenshots, the evidence of impact (what data or access was actually obtained, redacted where needed), the affected control or requirement (OWASP category, CWE, and the compliance mapping), and the remediation. Reproduction steps are the difference between a finding an engineer can fix in an afternoon and a finding that triggers a week of meetings.
6. Remediation with owner and priority
Each finding gets a specific fix (not 'implement input validation' but which parameter, which encoding, which library setting), a suggested owner by role, a priority that follows from the risk rating, and where useful a compensating control for the period until the fix ships. A consolidated remediation table, sorted by priority, is what the engineering lead pins to the wall. Strategic recommendations (the three root causes behind twenty findings) belong in a separate short section and are often the most valuable page in the report.
7. Retest section
After remediation, the tester verifies each fix and appends the result: resolved, partially resolved (with what remains), or not resolved. The retest section records the date, the method and the evidence per finding, so the report becomes a closed loop. Compliance frameworks that require evidence of remediation, such as PCI DSS v4.0.1 Requirement 11.4.4, are satisfied by this section and by nothing else.
8. Attestation letter
A one- to two-page letter, separate from the full report, that states who tested what, when, under which methodology, the number of findings by severity and their remediation status after retest, signed by the testing firm. It contains no technical detail and can be shared with customers, auditors, insurers and supervisors without exposing the findings. Most organisations need this document more often than the full report.
How auditors and supervisors read the report
Each framework has a reader with a specific question. A report written with those questions in mind is filed once; a report written without them generates follow-up requests.
ISO 27001:2022
The certification auditor checks Annex A controls A.8.8 (technical vulnerabilities), A.8.29 (security testing in development and acceptance) and A.5.36 (compliance with policies and standards). They want to see scope aligned with the ISMS scope, a date within the audit period, findings tracked through your corrective action process, and the retest.
SOC 2
The service auditor maps the report to the Trust Services Criteria, typically CC4.1 (monitoring activities) and CC7.1 (detection of vulnerabilities and configuration changes). They look for the control operating during the review period, so the test date and the remediation dates matter, and for the finding-to-ticket trail that shows management responded.
DORA and NIS2
Financial supervisors read against DORA Articles 24 and 25: does the test cover the ICT systems supporting critical or important functions, were the testers independent, and were findings remediated. NIS2 supervisors read against Article 21(2)(f): does the organisation assess the effectiveness of its measures. Both expect a management summary the board has seen.
DigiD and BIO
The Register EDP-auditor reads the report as evidence for specific norms in the Logius DigiD norm or the BIO. They need the scope to cover the full connection or system, the test to be recent and on the production release, and the findings mapped to norm numbers so they can trace each norm to evidence without interpreting the technical detail themselves.
PCI DSS v4.0.1
The QSA reads against Requirement 11.4: a documented methodology (11.4.1), internal and external tests at least annually and after significant change (11.4.2, 11.4.3), remediation and retest of exploitable vulnerabilities (11.4.4) and segmentation testing (11.4.5). Scope must cover the cardholder data environment and the segmentation controls around it.
GDPR and supervisory authorities
After a data breach, the supervisory authority may ask what testing was done under Article 32(1)(d), which requires a process for regularly testing the effectiveness of security measures. The scope section, the dates and the remediation trail are what demonstrates the process existed and was followed.
A good report versus a scanner export with a cover page
Many documents sold as penetration testing reports are the output of an automated scanner, lightly edited. The differences are visible in five minutes if you know where to look.
| Section | Good report | Scanner export |
|---|---|---|
| Management summary | Plain-language risk posture, the issues that matter, priorities | Chart of finding counts by severity, no narrative |
| Scope | Exact assets, roles, dates, exclusions, testers by name | List of IP addresses or URLs scanned, no roles, no testers |
| Methodology | Named frameworks, manual phases described, tool roles explained | Tool name and version, nothing else |
| Findings | Attack scenario, reproduction steps, evidence of actual impact, business context | Generic plugin description, CVSS base score copied from the database, no proof of exploitability |
| Business logic and authorisation | Tested and reported, often the most severe findings | Absent, because scanners cannot test them |
| Remediation | Specific fix per finding, owner, priority, root causes | Vendor boilerplate: update to the latest version |
| Retest | Per-finding verification with evidence and date | Rescan, or nothing |
| Attestation | Signed letter stating scope, method and remediation status | None |
How to share the report safely
A penetration testing report is a map of your weaknesses. Handle it like one.
- Sign a mutual NDA with the testing firm before the engagement, covering the report, the evidence and any data obtained during testing, with a defined retention and destruction period for the tester's copies
- Receive the report through an encrypted channel, not as an e-mail attachment; store it in a restricted location with access logging, not on a shared drive
- Share the attestation letter, not the full report, with customers, prospects, insurers and most auditors; the letter proves the test happened and findings were remediated without disclosing how your systems fail
- When a customer or supervisor insists on more, provide a redacted version: management summary, scope, methodology and the finding titles with severities and remediation status, with reproduction steps and evidence removed
- Ask the tester to redact personal data and credentials from screenshots before delivery; evidence of impact should show that data was reachable, not the data itself
- Agree how long the testing firm keeps its working data and the report (typically until the retest is complete plus a short period) and request written confirmation of deletion
- Keep your own copies for at least the audit cycles that rely on them; ISO 27001 and SOC 2 auditors will ask for the previous year's report as well as the current one
- Version the report: the original, the retest addendum and the attestation letter are three documents with three dates, and auditors need to see all three
What a HackersHub report contains
Every HackersHub report follows the structure above. The management summary is written by the lead tester, not generated, and reviewed for plain language before delivery. The scope section records the assets, roles, dates, exclusions and the named testers with their certifications; the lead tester holds OSCP as a minimum, and the team includes OSWE and CREST qualifications where the engagement calls for them. The methodology section names the frameworks per component and states where manual testing concentrated.
Findings carry a CVSS v4.0 vector and score, a business-context rating agreed with you during the engagement, the attack scenario, full reproduction steps with redacted evidence, the CWE and OWASP category, and the compliance mapping to the frameworks you named at scoping (ISO 27001 Annex A, SOC 2 criteria, PCI DSS requirements, DORA articles, NIS2, the DigiD norm, the BIO or NEN 7510 controls). Critical and high findings are escalated during the test, not saved for the report. The remediation table is sorted by priority with suggested owners, and a short root-cause section explains what connects the findings.
The retest is part of every engagement. After you remediate, we verify each finding and append the results with evidence and date, and we issue the attestation letter once the retest is complete. You receive the full report, the retest addendum and the attestation letter through an encrypted channel, with our data retention and deletion terms stated in the contract. We do not publish a downloadable sample report, because every real report contains a customer's weaknesses; we do walk prospective customers through an anonymised structure during a scoping call.
Frequently asked questions
Want a report your auditor, your engineers and your board can all use?
Every HackersHub engagement ends with a structured report, a verified retest and an attestation letter, mapped to the frameworks you name at scoping. Talk to an expert.