What is a penetration testing report?
A penetration testing report is a formal document that details the security vulnerabilities discovered during a controlled, simulated attack against an organization's systems, applications, or network. This report turns raw exploitation activity into a structured narrative that tells stakeholders exactly what an attacker could do, what data or systems are at risk, and what to fix first.
Reports are typically produced by internal red teams or third-party pen test firms and consumed by CISOs, security engineers, compliance teams, and developers. What separates a pen test report from automated scanner output is the human-driven analysis behind it: attack path analysis showing how one weakness led to the next, proof-of-concept exploitation proving real-world impact, and business-context analysis explaining why a finding matters.
Depending on the engagement scope, you may also hear this deliverable called a VAPT report (vulnerability assessment and penetration testing report). Regardless of the label, the end result of a penetration test is always this document: a prioritized, evidence-backed roadmap for reducing risk.
Vulnerability Management Buyer's Guide
This buyers guide will not only help you objectively choose or replace a vulnerability management solution, but also provide insights on how your organization can work together to own the responsibility of security as one team.
Why penetration testing reports matter
Cloud-native architectures, faster CI/CD deployment cycles, and AI-generated code are expanding attack surfaces faster than periodic security reviews can track. A pen test report is how an organization converts testing effort into measurable action. Without it, findings live in a tester's notes and never reach the teams that need to fix them.
The report drives three core outcomes:
Remediation accountability: Each finding is assigned to a specific team with clear fix guidance and retesting expectations, creating a trackable workflow.
Compliance evidence: Frameworks like PCI DSS, SOC 2, HIPAA, and ISO 27001 mandate regular penetration testing. PCI DSS requirement 11.4 states that external and internal penetration testing must be regularly performed, and exploitable vulnerabilities and security weaknesses must be corrected.
Business risk quantification: Technical findings are translated into language executives and board members understand, such as potential data exposure, breach costs, regulatory penalties, and reputational damage.
A standard engagement follows five stages: reconnaissance, scanning, exploitation, post-exploitation, and reporting. The report is the stage that makes all prior work actionable. Modern pen test firms increasingly deliver findings through collaborative platforms, not just static PDFs. Platforms such as PlexTrac, AttackForge, and Cobalt let teams track status in real time, attach evidence, retest fixes, and sync findings into Jira or ServiceNow. Interactive delivery shortens the gap between discovery and remediation because security, engineering, and compliance teams work from the same live record.
Types of penetration testing reports
The format and depth of a pen test report vary based on the engagement type and testing scope. Understanding these variants helps you interpret findings correctly and match report expectations to your security goals.
Black-box (external) testing reports: The tester has no prior knowledge of the environment. The report focuses on what an external attacker could discover and exploit from the outside.
White-box (internal) testing reports: The tester has full access to source code, architecture diagrams, and credentials. The report provides deep analysis of internal weaknesses.
Gray-box testing reports: The tester has partial knowledge, such as user-level credentials. The report reflects a realistic insider or compromised-account scenario.
Beyond testing approach, reports also vary by scope: external network, internal network, web application, API, cloud infrastructure, and wireless. Cloud penetration testing reports differ in a key way: they must account for shared responsibility models, cloud-provider-specific misconfigurations like overpermissioned IAM roles or publicly exposed storage buckets, and ephemeral workloads that may not exist by the time the report is delivered.
Key sections of a penetration testing report
Every well-structured pen test report follows a predictable format that serves both technical and non-technical audiences. The sections below represent the industry-standard components that compliance frameworks and security teams expect.
Executive summary
This section is written for C-suite executives, board members, and non-technical stakeholders. A strong executive summary communicates the overall risk posture, the number and severity of findings, the key business-impacting vulnerabilities, and a high-level recommendation on next steps.
Keep it to one or two pages, free of technical jargon. It should include the testing date range, overall risk rating, and a clear statement of whether critical business assets were compromised during the engagement. If a reader only opens one page of your report, this is the page that needs to land.
Scope and methodology
This section defines which assets were in scope (IP ranges, domains, applications, cloud accounts), which were explicitly excluded, and the rules of engagement including testing windows, allowed techniques, and emergency contacts. NIST SP 800-115 assists organizations in planning and conducting technical information security tests and provides practical recommendations for designing, implementing, and maintaining security testing processes.
Common testing frameworks and standards referenced here include PTES, the OWASP Testing Guide, and NIST SP 800-115. MITRE ATT&CK is often used to map discovered attack techniques to known adversary behaviors rather than to define a step-by-step testing methodology. Tools used should be documented (Burp Suite, Nmap, Metasploit, custom scripts) for reproducibility and audit purposes. A penetration testing checklist mapped to your methodology keeps the scope section clean and auditable.
Findings and evidence
Each finding should be documented with enough detail for another tester to reproduce it. The standard components include:
Description: What the vulnerability is and where it exists.
Affected components: Specific hosts, endpoints, applications, or cloud resources impacted.
Proof of concept: Screenshots, request/response pairs, or code snippets that prove exploitation.
Steps to reproduce: Clear instructions another tester could follow to verify the finding.
CWE/OWASP mapping: Classification against the Common Weakness Enumeration or OWASP Top 10 categories for standardized tracking.
Evidence quality determines report credibility. Findings without proof of concept are suggestions, not validated risks. In cloud environments, this might mean showing a screenshot of an S3 bucket listing returned via an SSRF, not just flagging "potential SSRF" from a scanner.
Risk ratings and prioritization
The Common Vulnerability Scoring System (CVSS), managed by FIRST.org, captures the principal technical characteristics of a vulnerability and produces a numerical Base score that maps to ratings like low, medium, high, and critical. CVSS v4.0 also defines Threat, Environmental, and Supplemental metric groups so organizations can adjust severity based on exploit maturity and the environment in which the vulnerability exists. Most reports use CVSS as a baseline, but base scores alone are insufficient.
A vulnerability's real risk depends on whether the affected asset is internet-facing, has access to sensitive data, holds elevated privileges, or sits on a path to critical infrastructure. Platforms that model relationships between vulnerabilities, network paths, identity permissions, and data stores can surface these contextual risk factors automatically, helping teams move beyond static CVSS scores to understand what is truly exploitable. This is where concepts like blast radius (how much damage results from exploitation) and exploitability (whether a working exploit exists in the wild) should override raw CVSS numbers. The best reports explain the rationale behind each severity rating, connecting vulnerability data to cloud infrastructure context like network exposure and identity permissions. For example, 54% of cloud environments have exposed VMs granting access to sensitive data.
Remediation recommendations
Each finding should include at least one recommended fix, and ideally multiple vulnerability remediation options: a patch, a configuration change, a compensating control, or an architectural redesign. After fixes are applied, the pen tester should verify the remediation, and the report should track status as verified-fixed, risk-accepted, or partially remediated.
Strong reports identify the responsible team or owner for each fix, not just the technical action. In cloud-native environments, the best remediation workflows trace a production vulnerability back to the relevant code repository, CI/CD pipeline, and developer or platform team that introduced it. They also pair short-term tactical fixes with long-term architectural recommendations. A pen test report template that standardizes this format across engagements keeps remediation workflows consistent.
Appendices
Appendices contain supporting artifacts that would clutter the main report body: raw tool output, full scan results, network diagrams, detailed request/response logs, and change logs. These serve audit and compliance purposes and should be referenced from the findings section rather than left as standalone data dumps.
Watch 12-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Pen testing report example
To illustrate what a pen test report looks like in practice, here is a simplified sample finding modeled after a real cloud scenario:
| Attribute | Detail |
|---|---|
| Finding title | SSRF on internet-facing web application reaches AWS metadata service |
| Severity | Critical |
| Affected asset | web-app-prod-01 (EC2 instance, us-east-1) |
| CVSS score | 9.1 |
| Description | The application accepts user-supplied URLs without validation, allowing server-side requests to the internal metadata endpoint (169.254.169.254). The tester retrieved temporary IAM credentials with read access to production S3 buckets. |
| Remediation | Enforce allowlist-based URL validation on all user-supplied inputs. Migrate all EC2 instances to IMDSv2 to require session tokens for metadata requests. Scope down the attached IAM role to least privilege. |
| Status | Open |
In the 2019 Capital One breach, an attacker exploited an SSRF vulnerability in a misconfigured WAF to send requests to AWS's instance metadata service (IMDSv1). IMDSv1 returned temporary IAM role credentials, and the role's broad S3 permissions allowed access to more than 100 million customer records. This is exactly the kind of end-to-end attack chain a strong pen test report should document.
Organizations can find public pen test report examples from resources like PentestReports.com and open-source repositories on GitHub for reference. However, every report should be customized to the engagement. The best templates are living documents that evolve with the threat landscape.
What is application penetration testing?
Application penetration testing is a simulated cyberattack against a software application designed to identify exploitable security vulnerabilities before malicious actors do.
En savoir plus
What makes a good penetration testing report?
Not all pen test reports are created equal. The difference between a report that gathers dust and one that drives action comes down to a few quality markers:
Contextual risk ratings: Severity reflects real-world exploitability and business impact, not just CVSS base scores.
Clear attack chain narratives: Findings tell the story of how an attacker moved through the environment, not just isolated vulnerability descriptions.
Audience-appropriate language: The executive summary avoids jargon while technical findings include full reproduction steps.
Actionable remediation: Every finding includes at least one specific fix with an identified owner.
Timeliness: The report is delivered quickly enough that findings are still relevant to the current state of the environment, a need underscored when Shell cut detection to near real-time.
Common mistakes to avoid: padding reports with informational findings that dilute critical issues, using generic remediation advice like "apply patches" without specifying which patches, and delivering reports weeks after testing ends, by which point cloud environments have changed significantly.
How to read and act on a penetration testing report
How should teams act on a penetration testing report?
Receive and classify the report as confidential.
Triage critical and high findings by business impact, exploitability, and asset exposure.
Assign each finding to the owning team in Jira or ServiceNow.
Remediate within SLA using the report's proof of concept and fix guidance.
Retest each fix and record the result as verified-fixed, partially remediated, or risk-accepted.
Review recurrence trends and control gaps before the next engagement.
This workflow gives CISOs, security engineers, developers, and compliance teams a common operating model.
After receiving a report, track three KPIs: MTTR for critical and high findings, critical fix rate within SLA, and recurrence rate across consecutive engagements. These metrics matter because Verizon's 2025 DBIR reported a 34% surge in vulnerability exploitation, while Wiz found that 54% of cloud environments have exposed VMs with access to sensitive data. Together, those numbers show why teams should measure not just closure speed, but whether the same cloud risk paths keep returning.
Each finding should be routed to the team that owns the affected asset, with clear SLAs and escalation paths. Integrate findings into ticketing systems like Jira or ServiceNow so remediation is tracked alongside other engineering work, not in a separate silo. Between scheduled pen tests, continuous cloud security posture management helps teams detect new misconfigurations, identity drift, and infrastructure changes before those changes recreate the same risk classes the last report uncovered.
Penetration testing reports and compliance
Many compliance frameworks explicitly require penetration testing and prescribe what the report must include.
| Framework | Pen test report requirement |
|---|---|
| PCI DSS v4.0 | Requires internal, external, and segmentation penetration testing to identify and mitigate vulnerabilities. Tests must follow a documented methodology, be conducted annually or after significant changes, and include proper scoping, reporting, and remediation. |
| NIST SP 800-115 | A federal standard that defines how organizations should conduct penetration testing and technical security evaluations, focusing on planning, execution, and reporting to ensure consistent testing practices. |
| ISO 27001 | Annex A controls reference penetration testing as part of vulnerability management; reports serve as audit evidence. |
| SOC 2 | Penetration testing supports Trust Services Criteria for security; reports demonstrate control effectiveness. |
| HIPAA | Penetration testing is part of the required risk analysis; reports document identified threats to ePHI (electronic protected health information). |
Pen test reports contain sensitive exploitation details and should be classified as confidential, encrypted in transit and at rest, and distributed only to authorized recipients. Some frameworks like PCI DSS require the testing firm to hold specific qualifications such as PCI QSA or ASV status.
Penetration testing reports vs. vulnerability assessments and SAST/DAST reports
These three report types are complementary, not interchangeable.
| Attribute | Pen test report | Vulnerability assessment report | SAST/DAST report |
|---|---|---|---|
| Approach | Manual exploitation with human reasoning | Automated scanning with minimal manual validation | Automated code or application scanning |
| Depth | Proves exploitability through attack chains | Identifies potential weaknesses without exploitation | Flags code-level or runtime flaws |
| Output | Narrative of how an attacker moved through the environment | Prioritized list of detected vulnerabilities | List of code defects or application-layer issues |
| Frequency | Annual, quarterly, or per-engagement | Continuous or scheduled | Integrated into CI/CD pipelines |
| Best for | Validating real-world attack impact | Broad coverage of known vulnerabilities | Catching issues early in development |
Modern security programs layer all three approaches, especially because 35% of breaches involve weaponized vulnerabilities. Automated scanning and SAST/DAST catch known issues continuously, while penetration testing validates exploitability and discovers logic flaws that scanners structurally cannot detect. Neither replaces the other.
Wiz's approach to penetration testing and continuous validation
Pen test reports capture a point-in-time snapshot, but cloud environments change constantly. By the time a report is delivered, new workloads, configurations, and identities may have already shifted the attack surface. The gap between annual testing cycles and daily cloud changes is where real risk hides.
Wiz closes that gap by connecting pen test-style findings to live cloud infrastructure context. Its agentless scanning covers VMs, containers, serverless functions, and managed services across AWS, Azure, GCP, and other providers without requiring agents or impacting performance. The Wiz Security Graph then correlates vulnerabilities with network exposure, identity permissions, and data sensitivity to surface the attack paths that actually matter. Think of it as what a skilled pen tester would map manually, but running continuously.
For organizations that need active exploitation testing between scheduled engagements, the Wiz Red Agent provides AI-powered autonomous testing that discovers complex logic flaws, authentication bypasses, and multi-step attack chains in custom applications and APIs. It adapts its approach based on application behavior, helping teams find issues that traditional scanners miss. When the Red Agent identifies an exploitable issue, the Green Agent accelerates remediation by tracing the finding to its root cause in code, routing it to the responsible owner, and providing contextual fix guidance, closing the loop that a traditional pen test report opens.
AI-generated code and AI workloads like models, training pipelines, and inference endpoints are expanding the attack surface that pen test reports must now account for. Wiz treats these as first-class cloud workloads, giving teams visibility into AI-specific risks as part of the same unified platform.
Pen test reports start the conversation. Wiz keeps it going, connecting every finding to live cloud infrastructure, identity context, and data sensitivity so your team can prioritize what is truly exploitable. Get a demo to see how continuous validation extends the value of your penetration testing program.
Uncover Vulnerabilities Across Your Cloud
Stop chasing alerts—Wiz maps your entire cloud to find and prioritize real risks immediately.
