What is a penetration testing report? Components and examples

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.

Your work email here

Get the guide

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.

Your work email here

Watch now

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:

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.

wiz academy

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.

Read more

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?

1. Receive and classify the report as confidential.

2. Triage critical and high findings by business impact, exploitability, and asset exposure.

3. Assign each finding to the owning team in Jira or ServiceNow.

4. Remediate within SLA using the report's proof of concept and fix guidance.

5. Retest each fix and record the result as verified-fixed, partially remediated, or risk-accepted.

6. 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.

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.

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.

Work Email*

First Name*

Last Name*

Country

Phone Number*

Company*

Keep me updated about Wiz product releases, industry news, and events (You can unsubscribe at any time)

Subscribe me to the Wiz blog digest emails

Submit

For information about how Wiz handles your personal data, please see our Privacy Policy.

Your work email here

Get a demo

FAQs about penetration testing reports