Penetration Testing Reports: A Section by Section Guide for Engineers, Buyers, and Auditors

The test finds the weakness. The report decides whether anyone fixes it.

A penetration testing report is the document a testing team produces at the end of an engagement. It records the tested scope, the methods used, every validated vulnerability, the supporting evidence, the assigned risk level, and the corrective action each finding requires. Security teams, engineering owners, executives, and compliance reviewers all read the same document for different reasons.

Plenty of organizations pay for a competent test and receive a document that cannot be acted on. Scanner output arrives with a cover page. Findings carry a severity label and no reproduction path. Remediation guidance says to sanitize input and stops there. The engagement was real, the deliverable was not.

The sections below cover what belongs in each part of the report and what a reviewer should confirm before signing off.

The Report Is the Deliverable

A test produces findings. A report produces decisions. Six things need to be legible to a reader who was not present during testing:

• The systems, applications, networks, and assets that were assessed
• The methods, tools, and attack techniques applied to them
• The vulnerabilities confirmed, along with how each one was validated
• The severity of each vulnerability and its technical or business consequence
• The evidence supporting every claim
• The corrective work required, stated at the component or control level

Leadership needs the posture summary and the priority list. Engineering needs affected assets, reproduction steps, and a named fix. One document serves both audiences when the structure separates the two layers cleanly.

One Engagement, Several Deliverables

A single test commonly produces more than one document. The distinction matters during vendor reviews, where the wrong version gets sent to the wrong reader.

Full report. The complete engagement record, covering scope, methodology, findings, evidence, impact analysis, remediation guidance, and appendices. Distribution stays with security, engineering, risk, legal, and audit personnel.

Executive summary or attestation letter. A short account of the engagement, the major risks, and the outcome, written for boards, prospects, and procurement teams. Exploit detail stays out.

Technical findings export. Finding-level evidence, reproduction steps, affected components, and corrective actions routed to developers and administrators.

Retesting report. Validation of remediation, with the current status of each retested finding.

Redacted customer-facing report. More substance than an attestation letter, with sensitive architecture, credentials, payloads, and screenshots removed.

Black-box, gray-box, and white-box describe tester access. Those labels belong inside the report as a methodology detail, not on a list of report types.

Section One: Executive Summary

The summary states the objective, the scope, the testing dates, the overall risk level, the significant findings, the affected business functions, and the items needing attention this week.

A severity breakdown and a note on recurring weakness patterns belong here. Exploit code, raw logs, payloads, and long reproduction sequences do not.

A reader who stops after this page should still walk away with the correct picture of the organization's exposure.

Section Two: Scope and Rules of Engagement

Scope defines what the tester was authorized to touch. The section lists included domains, IP ranges, applications, APIs, cloud environments, network segments, physical locations, user roles, supplied credentials, testing windows, and approved techniques.

Exclusions carry equal weight. Unavailable assets, missing credentials, unstable staging environments, blocked test categories, and restricted production actions all limit coverage. An untested system is untested. Reports that quietly imply otherwise create false assurance during the next audit cycle.

Mid-engagement scope changes need a record with the reason and the approver. Emergency contacts, stopping conditions, and data-handling rules belong in the same section.

Section Three: Methodology

Methodology explains the path from discovery to validation: reconnaissance, enumeration, vulnerability analysis, controlled exploitation, authorized post-exploitation activity, cleanup, and retesting. The report should state the access perspective used and describe the split between manual work and automated tooling.

Tool names help a reviewer judge coverage. Scanner output presented as a finished penetration test signals a deliverable problem worth raising before payment.

Section Four: Severity and Risk Rating

The risk summary counts findings at each severity level and names the systems, data stores, and business processes carrying the most exposure. CVSS gives the technical baseline:

• None: 0.0
• Low: 0.1 to 3.9
• Medium: 4.0 to 6.9
• High: 7.0 to 8.9
• Critical: 9.0 to 10.0

The score is a starting position rather than a remediation queue. Survey data on vulnerability management shows roughly 78% of organizations prioritizing work from the CVSS severity rating, while 73% treat exploitability as a separate factor and apply a risk-based method on top of the score.

An internet-facing medium-severity issue sitting in front of regulated data often deserves faster attention than a higher-scoring issue buried behind several working controls. Any adjusted rating needs its reasoning written down, along with the gap between the technical score and the assigned business priority.

Section Five: Findings and Evidence

Each finding should carry a unique ID, a specific title, a severity value with its scoring rationale, the affected asset and exact location, a description, the access required, ordered reproduction steps, supporting evidence, the observed result, the expected secure behavior, technical impact, business impact, remediation guidance, references, an assigned owner, a target date, and retest status.

The test for sufficiency is practical. An engineer who never spoke to the tester should be able to reproduce the issue safely and explain why it matters.

Evidence may include redacted screenshots, request and response pairs, log excerpts, configuration snippets, or proof-of-concept output. Credentials, tokens, personal data, and customer records need masking. Volume is not the goal. Include what proves the finding and supports the fix.

Section Six: Business Impact and Likelihood

Technical impact describes what the vulnerability permits at the system level: unauthorized data access, privilege escalation, remote code execution, authentication bypass, service interruption, control evasion.

Business impact translates that result into customer exposure, operational disruption, revenue effect, contractual consequence, or regulatory reach.

Likelihood reflects required access, attack complexity, system exposure, attacker prerequisites, and the defenses already in place. Realistic outcomes and theoretical worst cases need to sit in separate sentences, with stated assumptions.

Section Seven: Remediation and Retesting

Useful guidance addresses the underlying cause instead of blocking the specific payload the tester sent. The report should name the affected component or control, give the corrective action, note temporary containment where a permanent fix will take time, and define the validation method. Every finding gets an owner, a target date, and a documented disposition.

Retest records need the original finding, the original test date, the retest date, the systems reviewed, the validation method, the evidence, and the current result. One status vocabulary throughout the report keeps the tracking clean: resolved, partially resolved, still exploitable, risk accepted.

A retest confirms that the root cause was corrected. A proof of concept that stopped working is weaker evidence than most closure tickets assume.

Section Eight: Compliance Mapping and Appendices

Mapping connects test activities and findings to the security or regulatory requirements in play. Honest mapping states three things: what evidence the test supports, what fell outside test scope, and where additional evidence remains outstanding.

A penetration test supports SOC 2, ISO 27001, HIPAA, PCI DSS, and CMMC programs. It certifies none of them.

Appendices hold asset inventories, tested IP ranges, test accounts, tool versions, sanitized output, network diagrams, coverage records, and glossary terms. Raw scanner exports work as supplemental material and never as a substitute for analyst-reviewed findings.

Compliance Specific Reporting

SOC 2. The report serves as evidence that relevant systems undergo periodic testing and that findings receive treatment. An auditor typically reviews the signed report or attestation, the scope, the test date, the finding summary, remediation tickets, documented risk acceptance decisions, and retest evidence. For a Type 2 examination, the test date should fall inside the observation period when the report supports a periodic testing control.

PCI DSS Requirement 11.4. Penetration testing moved from Requirement 11.3 to 11.4 in v4.x, so the report should state the version used. Traceable evidence covers:

• 11.4.1: a documented methodology spanning the cardholder data environment, critical systems, internal and external testing, application and network layers, segmentation controls, recent threats, risk treatment, and record retention
• 11.4.2: internal testing at least every 12 months and after significant changes, performed by a qualified and organizationally independent tester
• 11.4.3: external testing on the same cadence and independence conditions
• 11.4.4: correction of confirmed exploitable weaknesses according to risk, with retesting to verify effectiveness
• 11.4.5: segmentation control testing at least every 12 months and after relevant changes
• 11.4.6: service provider testing of every segmentation method at least every six months, with results and corrective actions recorded

No universal PCI report template exists. The document needs enough detail for a QSA to trace each applicable clause without exposing unnecessary exploit material.

A Sample Critical Finding

The example below uses 198.51.100.0/24, reserved for documentation under RFC 5737.

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, base score 9.8 Scoring Rationale: AV:N applies because the endpoint is reachable over HTTPS across a network boundary. PR:N applies because the request requires no authentication. No environmental modifiers were applied. 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 with a single appended quote and record the database error
3. Send a true condition variant and record the successful response
4. Send a false condition variant and record the changed response
5. Compare the responses to confirm server-side SQL condition control

Evidence: Sanitized request and response pairs, response hashes, timestamps, and a screenshot showing the controlled difference between true and false conditions. No customer records were copied. Technical Impact: Unauthorized database reads, with modification or deletion possible depending on database permissions. Business Impact: Access to customer order data, altered transaction records, disrupted order processing, and contractual or regulatory exposure tied to protected data. Remediation Guidance: Replace string concatenation with parameterized queries or prepared statements. Add server-side type validation on customer_id, reduce the application database account permissions, return generic error messages, and add automated tests covering injection conditions. References: OWASP WSTG-INPV-05, CWE-89, FIRST CVSS v3.1 Calculator Retest Status: Open, remediation not yet submitted for validation

Each field does work here. The ID routes the ticket. The steps repeat the issue. The vector shows where the number came from. The two impact fields serve two audiences. The retest field stops a closed ticket from passing as a validated fix.

Reading a Report in Four Passes

Pass one: the executive summary. Note the overall risk level, the worst findings, and the business functions in scope for consequences.

Pass two: scope and rating method. Match tested assets, exclusions, dates, and access level against the signed statement of work. Check how severity was assigned and whether business context factored into priority.

Pass three: high-priority findings. Read the affected asset, the evidence, the reproduction steps, both impact fields, and the recommended correction. Vague findings go back to the provider.

Pass four: the remediation plan. Assign an owner and a deadline per finding. Record temporary controls, accepted risks, and blocking dependencies. Findings stay open until retesting validates the fix.

Handling and Distribution

The report contains vulnerability detail, affected system names, exploit paths, screenshots, payloads, and logs. Access belongs to security leadership, technical owners, legal counsel, compliance staff, and executives with a reason to read it.

Include a confidentiality statement, an approved recipient list, and handling instructions. Deliver through encrypted channels or a secure portal. Uncontrolled copies spreading across email threads and shared drives are the most common failure here.

Legal authorization needs documenting before testing starts, and the report should reflect the approved scope, rules of engagement, testing windows, excluded systems, and activity limits. NIST SP 800–115 treats architecture data, security configurations, and vulnerability information as sensitive assessment material requiring documented controls for collection, storage, transmission, and destruction. OWASP recommends encryption limiting use to the intended recipient.

After delivery, store the report in a restricted location, set a retention period, track access, and protect archived copies. Retest results, remediation notes, and risk acceptance decisions stay attached so a future reviewer can follow each finding to closure.

Acceptance Checklist

Ten checks before the report gets accepted:

1. Scope. Assets and exclusions match the signed scope. Unexplained gaps go back.
2. Authorization. Dates, tester identity, and approved boundaries are traceable.
3. Methodology. Performed phases match the stated method. Contradictions go back.
4. Findings. Serious issues reproduce from the written steps.
5. Evidence. Proof holds up and sensitive values are masked.
6. Severity. Ratings trace to a vector and to business context.
7. Remediation. Guidance names a practical correction rather than generic advice.
8. Compliance. Mappings stay inside tested controls, with no certification claims.
9. Retesting. Dates, method, evidence, and final status are present. Untested closures reopen.
10. Versions. Full, attestation, and redacted deliverables exist as separate files.

A report clearing those ten points supports remediation work, audit review, and customer questionnaires without further translation.

The vulnerability scan comparison, SOC 2 evidence expectations, and the full section framework are covered in more depth in the source guide: What Is a Penetration Testing Report?