Penetration Test Report
Also known as: pen test report, pentest report, security assessment report, ethical hacking report
A penetration test report is the formal output of a penetration test: an authorized, simulated cyberattack conducted by security professionals (ethical hackers or pen testers) to identify vulnerabilities in an organization's systems, networks, or applications before malicious actors can exploit them.
The report documents the scope of testing, the methodology used, each finding with its severity rating, proof of exploitation (screenshots, logs, or payloads), and prioritized remediation recommendations. Penetration test reports are required by PCI DSS and are common evidence for SOC 2, ISO 27001, and many other compliance frameworks.
Penetration Test Report, explained at three levels
At home
A penetration test is when a company pays security experts to try to hack into their own systems (legally) so they can find weaknesses before real attackers do. The penetration test report is the document the experts hand back at the end, listing everything they found: what vulnerabilities existed, how they exploited them (often with screenshots as proof), and what needs to be fixed first. Think of it as hiring someone to pick the locks on your building to find out which ones are weak.
At work
A penetration test report is a formal security assessment document used to prioritize remediation efforts, demonstrate security due diligence to regulators and customers, and track improvements over time. Reports are classified by severity (typically Critical, High, Medium, Low, Informational) and include the finding title, description, evidence, CVSS score or custom severity rating, business impact, and recommended fix. Most organizations receive the report in draft, respond to each finding, and receive a final version after confirming remediation.
At home
A penetration test report typically contains: an executive summary (non-technical overview of scope, key findings, and overall risk level), a technical summary (methodology, testing dates, scope boundaries), detailed findings (one finding per vulnerability, with proof of concept), remediation recommendations (specific fixes, not vague advice), and appendices (tools used, full output, scope confirmation). The executive summary is written for a non-technical audience (board members, auditors, and clients) while the technical sections are written for the security and engineering teams who will remediate.
At work
Penetration tests are categorized by the information provided to the tester: Black box (no prior knowledge, simulating an external attacker), Grey box (limited knowledge such as a low-privilege account, simulating an insider threat or authenticated attacker), and White box (full knowledge of systems, code, and architecture, simulating an attacker with insider access or a thorough code review). Grey box is the most common approach for web application testing: it provides a more thorough test than black box while remaining realistic about attacker capability.
At home
The real value in a report sits in how findings are rated and connected. Most testers start from a CVSS base score, which measures a flaw in isolation, then adjust it for context: a medium-rated bug on an internal test server matters less than the same bug on the payment API. Good reports also show attack chains, where two modest findings combine into a critical path to customer data. In my view, a report that lists scanner output without chains or business context is a vulnerability scan with a more expensive label.
At work
From a practitioner standpoint, the quality of penetration testing varies enormously between providers. An automated scan rebranded as a penetration test is not the same as a skilled tester manually chaining vulnerabilities together to demonstrate business impact. When procuring penetration testing, specify the methodology (PTES, OSSTMM, or NIST SP 800-115), require evidence of manual testing (not just automated scan output), and ask for a remediation meeting where testers walk the engineering team through each finding. Retesting (where the tester verifies that remediation was effective) should be included in the engagement scope.
Real-world examples
At home
Jerome launched a small SaaS product and wanted to offer it to enterprise clients. A prospect's security questionnaire asked whether the product had been penetration tested in the last 12 months. Jerome hired a security firm to conduct a grey-box web application test; the report found two High severity findings (an IDOR vulnerability and a missing rate limit on the authentication endpoint) that Jerome fixed before sharing the final report with the prospect.
At work
The CISO at Clearwater Insurance contracted an external penetration testing firm to test their externally facing web applications and internal network. The resulting report identified a Critical finding: the firm had chained a misconfigured S3 bucket with a server-side request forgery vulnerability to exfiltrate customer records. The engineering team remediated within 48 hours, and the CISO presented the report and remediation evidence to the audit committee.
How it compares
| Feature | Penetration Test | Vulnerability Scan | Red Team Exercise |
|---|---|---|---|
| What it does | Manually exploits vulnerabilities to demonstrate real impact | Automatically identifies known vulnerabilities | Simulates a full adversary campaign including social engineering and physical access |
| Who conducts it | Certified ethical hacker / pen tester (external) | Security team using automated tools (internal or external) | Specialist red team (external) |
| Output | Detailed report with proof-of-exploitation per finding | List of vulnerabilities by severity with CVSS scores | Detailed attack narrative, indicators of compromise, and detection gaps |
| Frequency | Annually or after major changes | Continuously or monthly | Typically annual or bi-annual |
| Compliance use | Required by PCI DSS; common evidence for SOC 2 and ISO 27001 | PCI DSS, vulnerability management programs | Advanced compliance, regulated sectors, large enterprises |
A vulnerability scan is automated and broad; a penetration test is manual and targeted, demonstrating exploitability. A red team exercise simulates a full adversary campaign and tests detection and response as well as technical defences. Most organizations need all three at different frequencies.
For analysts
In BA artefacts, penetration testing requirements surface as acceptance criteria and NFRs for new systems or significant changes. Specify the testing scope (application, network, or combined), the methodology, the severity threshold that must be remediated before go-live (typically Critical and High findings), and the timeframe for a remediation retest. A common gap is ordering a penetration test only at go-live rather than earlier in the development cycle: architectural flaws found at go-live are far more expensive to fix than those found during design. Useful acceptance criterion: 'No Critical or High severity penetration test findings may remain open at production deployment; Medium and Low findings require a documented remediation plan within 30 days.'
History & origin
Penetration testing as a discipline emerged from the 'tiger team' exercises used by the US Department of Defense in the 1970s, where specially trained teams were tasked with attempting to breach the physical and logical security of military installations. The concept migrated to the commercial sector in the 1980s as organizations began using computer systems for business-critical processes. The term 'penetration test' was formalized in the 1990s as commercial security firms began offering structured offensive security services. OWASP's Testing Guide (first published 2002) and the PTES (Penetration Testing Execution Standard, 2012) introduced consistent methodologies and reporting standards.