A penetration testing report is a document produced by penetration testers that records the test scope, methods, validated vulnerabilities, supporting evidence, risk levels, and remediation guidance for security, engineering, leadership, and compliance teams.

The report converts a controlled security assessment into an actionable record. It explains what was tested, what remained outside the scope, how weaknesses were confirmed, what each weakness could affect, and which corrective actions require attention.

A strong penetration testing report is not a scanner export. It should clearly communicate:

• What systems, applications, networks, and assets were tested
• How the testing was performed, including the methods, tools, and attack techniques used
• What vulnerabilities were identified and how they were validated
• How serious each vulnerability is and what business or technical impact it may have
• What evidence supports each finding
• What actions are required to remediate the identified weaknesses

The report should serve both executive and technical readers. Leadership teams need a clear summary of the overall security posture, business risks, and major priorities. Technical teams need detailed findings, evidence, affected assets, reproduction steps, and practical remediation guidance.

Penetration Testing Report Deliverables

A penetration testing engagement does not always end with a single report. Different stakeholders may require different deliverables, ranging from a detailed technical report to a concise executive summary or customer-facing version. 

Here is what a a pen test should deliver: 

Engagement scope may cover external or internal networks, web applications and APIs, cloud configuration, segmentation, social engineering, or red team work. The types of penetration testing an organization selects determine which surfaces appear in the report. These labels describe scope; the deliverable types above describe reader and format.

These are deliverables for different readers, not different testing methods. Black-box, gray-box, and white-box are better treated as testing access levels inside the report rather than separate report types.

What a Penetration Testing Report Should Include

A penetration testing report should help business leaders understand the organization’s exposure and give technical teams enough information to correct each confirmed weakness. It should clearly explain what was tested, what was not tested, which vulnerabilities were found, how serious they are, and what actions should happen next.

The sections below provide a practical structure for a report that supports remediation, risk decisions, and compliance reviews:

1. Executive Summary

The executive summary provides a nontechnical overview of the engagement. It should state the following: 

test objective

scope

• Testing dates 
• Overall risk level
• Important finding
• Affected business functions 
• Actions that require immediate attention

A reader should be able to understand the main outcome without reviewing the technical findings.

Include a short breakdown of findings by severity, the systems or processes facing the greatest risks and recurring security weaknesse.. Keep exploit code, raw logs, payloads, and lengthy reproduction steps in the detailed findings section.

2. Scope and Rules of Engagement

The scope within a report defines exactly what the tester was authorized to assess. It should list the included domains, IP addresses, applications, APIs, cloud environments, network segments, physical locations, user roles, supplied credentials, testing dates, approved techniques, and permitted testing windows.

The report should separately list excluded systems and important limitations, such as unavailable assets, missing credentials, unstable environments, blocked test types, or restricted production actions. An excluded or inaccessible system remains untested and should not be described as secure.

Any scope change made during testing should be recorded with the reason and approval. The section should include emergency contacts, stopping conditions, data-handling rules, production restrictions, and other boundaries that may have affected test coverage or confidence in the results.

3. Methodology and Testing Approach

The methodology in a pen test report explains how the testing was performed from initial discovery through validation. It should describe reconnaissance, enumeration, vulnerability analysis, controlled exploitation, post-exploitation activities where authorized, cleanup, and retesting. 

The report should state whether the engagement used a black-box, gray-box, or white-box perspective and explain the balance between manual testing and automated tools. Tool names may be included to clarify coverage, but scanner output should not be presented as a complete penetration test.

4. Risk Summary and Severity Assignment

The risk summary groups findings by severity and highlights the systems, data, or business processes exposed to the greatest harm. 

It should show the number of critical, high, medium, low, and informational findings and explain how likelihood, technical impact, business impact, asset sensitivity, external exposure, exploit difficulty, and existing controls affected the final priority.

The following CVSS score ranges provide a consistent starting point for technical severity:

The score range provides a common technical label, but the final remediation priority should reflect the environment in which the vulnerability exists.

A CVSS score should not determine remediation order by itself. Roughly 78% of organizations prioritize vulnerabilities using the CVSS severity rating, and 73% treat exploitability as extending beyond the score, applying a risk-based method instead.

Further penetration testing statistics cover remediation timelines and resolution rates by severity. An internet-facing medium-severity issue involving sensitive data may require faster action than a higher-scoring issue protected by several strong controls.

The report should clearly explain any adjusted rating, custom priority, or difference between the technical score and the business priority.

5. Detailed Findings and Evidence

Each finding within a penetration testing report should contain a unique ID, clear title, severity, score and scoring rationale, affected asset, exact location, description, required access, reproduction steps, supporting evidence, observed result, expected secure behavior, technical impact, business impact, remediation guidance, useful references, assigned owner, target date, and retest status.

The finding should contain enough detail for an engineer who did not participate in the test to reproduce the issue safely and understand why it matters. Reproduction steps should be ordered, specific, and connected to the evidence so the remediation team can confirm both the weakness and the eventual correction.

Evidence may include redacted screenshots, request and response samples, logs, configuration excerpts, proof-of-concept output, or a short attack narrative. 

Passwords, tokens, personal information, customer data, and other sensitive values should be masked. Include only the evidence needed to prove the finding and support remediation.

6. Business Impact and Likelihood

Technical impact describes what the vulnerability allows at the system level, such as unauthorized data access, privilege escalation, remote code execution, service interruption, authentication bypass, or security control evasion. 

Business impact explains what that technical result could mean for customers, operations, revenue, contracts, reputation, or regulated information.

Likelihood should reflect the access required, attack complexity, system exposure, available defenses, attacker prerequisites, and conditions needed for successful exploitation. The report should separate realistic outcomes from theoretical worst cases and state any assumptions used. An internet-facing weakness connected to sensitive data will usually require faster action than the same weakness in a tightly restricted internal system.

7. Remediation Guidance and Retesting

Remediation guidance should address the underlying cause rather than only blocking the exact test payload. It should name the affected component or control, provide specific corrective actions, identify temporary containment where needed, and define how the fix will be validated. Each finding should have an owner, target date, and documented disposition.

The retest should record the original finding, original test date, retest date, systems reviewed, validation method, supporting evidence, and current result. Use one status set throughout the report, such as resolved, partially resolved, still exploitable, or risk accepted. Retesting should confirm that the root cause was corrected and not merely that the original proof of concept no longer works.

8. Compliance Mapping and Appendices

Compliance mapping connects relevant test activities and findings to applicable security or regulatory requirements. The mapping should show what evidence the penetration test supports, what remains outside the test scope, and where additional evidence is still required. 

A penetration test can support SOC 2, ISO 27001, HIPAA, PCI DSS, CMMC, and similar programs, but it does not certify the entire compliance program.

Appendices should hold supporting material that is useful but too detailed for the main report. Common examples include asset inventories, tested IP ranges, test accounts, tool versions, sanitized output, network diagrams, coverage records, glossary terms, and methodology notes. Raw scanner exports may be included as supplemental evidence, but they should not replace analyst-reviewed findings in the main report.

Other Reporting Considerations 

Some penetration testing engagements must meet additional reporting requirements for specific compliance frameworks. These requirements build on the standard report structure by documenting evidence needed to support audits, regulatory reviews, and compliance assessments.

SOC 2 Penetration Test Evidence

For SOC 2, a penetration testing report can provide evidence that the organization periodically tests relevant systems and addresses identified weaknesses. An auditor may review the signed report or attestation, scope, test date, finding summary, remediation tickets, documented risk acceptance, and retest evidence. For a Type 2 examination, the test should fall within the observation period when it represents the operation of a periodic testing control.

The report should connect testing activities, findings, and remediation records to the applicable Trust Services Criteria without claiming that the penetration test proves full SOC 2 compliance. Scope, timing, and retest expectations are covered further in our guide to SOC 2 penetration testing requirements.

Detailed exploit evidence may remain restricted, while an executive summary, attestation, or redacted report can be provided to auditors, customers, or procurement teams when appropriate.

PCI DSS Requirement 11.4

PCI DSS v4.0.1 places penetration testing requirements under Requirement 11.4. A report used for PCI DSS should make the scope, methodology, tester independence, testing dates, findings, remediation, retesting, and segmentation testing traceable to each applicable sub-requirement.

Older reports may refer to Requirement 11.3 because penetration testing moved to Requirement 11.4 in PCI DSS v4.x. The report should state the PCI DSS version used so reviewers can follow the correct requirement numbers and testing frequency.

Letter of Attestation, Full Report, and Redacted Report

A letter of attestation confirms that a penetration test was completed. It usually summarizes the testing provider, scope, dates, test type, and high-level outcome. This document is often suitable for prospects, customers, or third parties completing a security questionnaire because it confirms that testing occurred without revealing sensitive technical details.

The full penetration testing report contains the complete record of the engagement. It may include detailed findings, affected systems, reproduction steps, screenshots, evidence, payloads, internal diagrams, and remediation guidance. Access should remain limited to authorized security, engineering, legal, compliance, risk, and audit personnel.

A redacted report provides more detail than a letter of attestation while protecting confidential information. It may retain the executive summary, scope, methodology, severity totals, and remediation status. Specific targets, credentials, sensitive screenshots, raw requests, exploit payloads, and internal architecture details should be removed before the report is shared externally.

The correct document depends on the reader and the level of technical detail they are authorized to receive.

How Penetration Testing Reports Are Produced

A penetration testing report is usually prepared through a structured review process. The lead tester develops the final narrative, while contributing testers provide supporting evidence, reproduction steps, screenshots, logs, and notes about affected systems. The completed draft then goes through technical and editorial review to confirm that the scope is accurate, severity ratings are consistent, evidence supports each finding, remediation guidance is practical, and sensitive information is handled properly.

Report delivery time depends on the size of the engagement and the number of findings. A smaller assessment may be completed within a few business days after testing ends, while a broad engagement may require more time for analysis and review. The expected delivery date should be stated in the signed statement of work.

There is no standard page count for a penetration testing report. A limited assessment may produce a short document, while a large network, application, or cloud assessment may produce a much longer report. Quality should be judged by the clarity of the scope, the strength of the evidence, the accuracy of the findings, and the usefulness of the remediation guidance rather than the number of pages.

The final report may be delivered through a secure customer portal, a dedicated penetration testing platform, or an encrypted PDF. The delivery method should limit access to approved recipients and protect sensitive technical information.

How to Read a Penetration Testing Report

If you haven’t skimmed through a penetration test report before, it may seem a bit cryptic at first. Here’s a brief overview of the key things you should focus on while reading one:

1. Start with the executive summary. Note the overall risk level, the most serious findings, and the business functions that may be affected. This section should help leadership understand which issues require immediate attention or additional resources.
2. Review the scope and rating method. Confirm that the tested systems, exclusions, testing dates, access level, and engagement limitations match the signed statement of work. Check how severity ratings were assigned and whether business impact was considered alongside the technical score.
3. Examine each high-priority finding. Review the affected asset, supporting evidence, reproduction steps, technical impact, business impact, and recommended correction. The information should be clear enough for the technical team to understand the issue and begin remediation.
4. Build and track the remediation plan. Assign an owner and deadline to each finding. Record any temporary controls, accepted risks, or dependencies that may delay correction. Findings should remain open until remediation has been validated through retesting.

How to Handle a Penetration Testing Report Securely for Compliance

A penetration testing report contains sensitive security information, including vulnerability details, affected systems, exploit paths, screenshots, payloads, logs, and remediation status. Access should be limited to authorized security leaders, technical owners, legal counsel, compliance teams, and executives who need the findings.

The report should include a confidentiality statement, approved recipient list, and clear handling instructions. Deliver it through encrypted channels or a secure client portal, and avoid uncontrolled copies across email, shared drives, or external systems.

Legal authorization should be documented before testing begins. The report should reflect the approved scope, rules of engagement, testing windows, excluded systems, emergency contacts, and activity limits.

After delivery, store the report in a restricted location, define the retention period, track access, and protect archived copies. Keep retesting results, remediation notes, risk acceptance decisions, and closure evidence with the report so future reviews can follow each finding.

NIST SP 800-115 treats architecture, security configurations, and vulnerability information as sensitive assessment data and recommends documented controls for collection, storage, transmission, and destruction. OWASP recommends encryption so that only the intended recipient can use the report.

Penetration Testing Report Example

The following sample uses the documentation address block 198.51.100.0/24, which RFC 5737 reserves for examples.

Finding ID: WEB-001

Title: Unauthenticated SQL Injection in Order Lookup Endpoint

Severity: Critical

CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H with a base score of 9.8

Scoring Rationale: AV:N applies because the endpoint is reachable over HTTPS across a network boundary, and PR:N applies because the request requires no authentication. No environmental adjustment was made because this example assumes no organization-specific asset or control modifiers.

Affected Asset: https://portal.example.com/api/v1/orders at 198.51.100.24

Description: The customer_id parameter is concatenated into a database query without parameter binding. An unauthenticated remote user can alter the query structure and influence the database operation.

Reproduction Steps:

1. Send a baseline request to GET /api/v1/orders?customer_id=1001.

2. Repeat the request with customer_id=1001′ and record the database error.

3. Send customer_id=1001′ AND ‘1’=’1 and record the successful response.

4. Send customer_id=1001′ AND ‘1’=’2 and record the changed response.

5. Compare the responses to confirm that the parameter changes the server-side SQL condition.

Evidence Description: The report contains sanitized request and response pairs, response hashes, timestamps, and a screenshot showing the controlled difference between the true and false conditions. No customer records or database contents were copied.

Technical Impact: Successful exploitation could permit unauthorized database reads and, depending on database permissions, modification or deletion of records.

Business Impact: An attacker could access customer order information, alter transaction records, disrupt order processing, and create contractual or regulatory exposure related to protected data.

Remediation Guidance: Replace string concatenation with parameterized queries or prepared statements. Apply server-side type validation to customer_id, reduce the application’s database permissions, return generic error messages, and add automated tests for injection conditions.

References: OWASP WSTG-INPV-05; CWE-89; FIRST CVSS v3.1 Calculator.

Retest Status: Open. Remediation has not been submitted for validation.

The finding ID, affected asset, and numbered reproduction steps make the issue easy to route and repeat. Evidence proves the result without forcing the remediation owner to reconstruct the tester’s work, while the vector shows how the numerical severity was derived.

The technical and business impact fields explain why the issue matters to different readers. Remediation guidance names the code-level correction and supporting controls, and the retest field prevents a fixed ticket from being mistaken for a validated correction.

Penetration Testing Report Acceptance Checklist

Before accepting a penetration testing report, review it for accuracy, completeness, technical usefulness, and safe distribution. 

This checklist helps confirm that the report matches the approved scope, supports each finding with credible evidence, provides practical remediation guidance, and separates sensitive technical details from customer-facing versions: 

Penetration Testing Report FAQs

What Is the Difference Between a Vulnerability Scan Report and a Penetration Testing Report?

A vulnerability scan report lists suspected or known weaknesses found mainly through automated checks and ranks their potential risk. A penetration testing report documents manual validation, exploitation attempts, attack paths, evidence, and the practical extent of compromise. PCI SSC describes scanning as finding and ranking vulnerabilities, while penetration testing seeks ways to exploit weaknesses and defeat security controls.

What Is the Difference Between an Executive Summary and a Technical Report?

An executive summary explains the objective, overall risk, significant findings, business impact, and priority actions for leadership. A technical report gives security and engineering teams the affected assets, evidence, reproduction steps, scoring rationale, and remediation instructions needed to correct each weakness.

Do I Need a PCI-Specific Penetration Testing Report Format?

PCI DSS Requirement 11.4 does not require one universal report template. The report needs enough detail to document methodology, internal and external scope, significant-change testing, segmentation controls where applicable, findings, remediation, and retesting. The evidence should let a QSA trace each applicable clause without exposing unnecessary exploit detail.

How Are Severities Assigned in a Penetration Testing Report?

Severity combines a repeatable technical method with the target organization’s context. CVSS can describe exploitability and technical impact, while exposure, asset sensitivity, business function, existing defenses, and regulatory consequences affect remediation priority. The report should explain the rating method and document any departure from the standard score.

Bright Defense Penetration Testing Services

Bright Defense provides penetration testing for web applications, APIs, external and internal networks, cloud environments, and other systems included within the approved scope. We combine automated assessment with manual testing to confirm exploitable weaknesses, examine realistic attack paths, and determine the technical and business impact of each finding.

At the end of the engagement, we provide a structured penetration testing report containing an executive summary, scope, methodology, severity breakdown, detailed findings, supporting evidence, and practical remediation guidance. Bright Defense can also perform retesting to confirm whether completed fixes have corrected the underlying vulnerabilities.

Our penetration testing services can support requirements associated with SOC 2, ISO 27001, HIPAA, PCI DSS, CMMC, and customer security reviews. Contact Bright Defense to discuss your testing scope, reporting requirements, and compliance deadlines.