Penetration Test Report Example

Standard Operating Procedure: penetration test report example

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Clinical Statement of Operational Boundaries

This Standard Operating Procedure (SOP) defines the mandatory lifecycle, structural requirements, and analytical rigor required for drafting, verifying, and publishing an enterprise penetration test report. This document governs all offensive security assessments performed within internal networks, external perimeters, cloud infrastructures, and application layers.

2.2 Regulatory Standards & Compliance Alignment

All reporting outputs generated under this framework must comply with and map directly to the following regulatory and technical standards:

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.
• OSSTMM: Open Source Security Testing Methodology Manual.
• PCI-DSS v4.0: Requirement 11 (Regularly Test Security Systems and Networks).
• ISO/IEC 27001:2022: Information Security Management Systems (Control A.12.6.1 - Management of Technical Vulnerabilities).
• SOC 2 Type II: Trust Services Criteria (Security, Confidentiality, and Availability).

---

3. Prerequisites & Tool Requirements

3.1 Software & Platform Access

• Enterprise Reporting Platform (e.g., PlexTrac, Dradis, or Markdown/LaTeX automated document generation pipelines).
• Vulnerability Management Database (e.g., Tenable.sc, DefectDojo).
• Cryptographic validation tools (GPG for report delivery encryption).

3.2 Certifications & Competency Requirements

• Lead Authors must hold at least one of the following industry-recognized certifications: OSCP, GPEN, OSCE3, or CISSP.
• Technical Reviewers must possess demonstrable experience in threat modeling and CVSS metric calculation.

3.3 Equipment & Safety Protocols

• Air-gapped or encrypted local workstations utilizing Full Disk Encryption (AES-256).
• All draft reports containing raw assessment data, credentials, or PII must reside exclusively on restricted-access, access-logged institutional repositories.

---

4. Roles & Responsibilities (RACI Matrix Table)

• R - Responsible (The role that performs the activity)
• A - Accountable (The role with final approval and ownership)
• C - Consulted (The role providing advisory input)
• I - Informed (The role kept updated on progress)

---

5. Step-by-Step Operational Procedure

Phase 1: Data Aggregation & Evidence Verification

• Aggregate all raw tool outputs (Burp Suite logs, Nessus/Nmap XMLs, custom exploit logs, and manual testing notes).
• Scrub all captured data to eliminate false positives via manual verification.
• Confirm that all discovered vulnerabilities map to specific evidence blocks containing request/response pairs, screenshots, or terminal outputs.

Phase 2: Executive Summary & Risk Contextualization

• Draft a high-level narrative for executive leadership, omitting technical jargon and focusing on business risk, financial exposure, and regulatory impact.
• Generate a high-level graphical breakdown of findings categorized by severity (Critical, High, Medium, Low, Informational).
• Summarize the overall security posture compared against industry benchmarks.

Phase 3: Technical Findings & CVSS Scoring

• Document each vulnerability using the standard structural template: Title, Affected Asset, Severity, CVSS v3.1/v4.0 Vector String, Description, Proof of Concept (PoC), Impact, and Remediation Guidance.
• Calculate and verify CVSS base, temporal, and environmental scores for consistency.
• Ensure every finding includes a realistic, actionable remediation timeline based on institutional SLA guidelines.

Phase 4: Quality Assurance & Technical Review

• Submit draft report to the Senior Security Auditor for technical and editorial review.
• Validate that all intellectual property, scope boundaries, and target IP addresses match the signed Statement of Work (SOW).
• Perform cryptographic signing or secure channel packaging for client delivery.

---

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist

• Completeness: Are all agreed-upon scope items accounted for in the results section?
• Accuracy: Do all PoC screenshots match the reported asset and vulnerability description?
• Clarity: Is the remediation guidance specific enough for a tier-3 system administrator to execute without external clarification?

6.2 Tolerance Thresholds & Acceptance Benchmarks

• Zero Tolerance: No unverified or automated-only vulnerability scanner output may be pasted directly into the report without human validation and contextual impact analysis.
• Scoring Accuracy: 100% of reported vulnerabilities must feature a mathematically validated CVSS vector string. Typographical errors in target hostnames or IP addresses result in immediate rejection of the draft.

---

7. Practical Troubleshooting Scenarios

Scenario A: Discrepancy Between Automated Scanner Output and Manual Exploitation

• Symptom: An automated scanner reports a Critical vulnerability (e.g., Remote Code Execution via unpatched library), but manual penetration testing reveals the implementation wrapper neutralizes the vector, rendering it a Low-severity or Informational finding.
• Immediate Corrective Action Protocol:
  1. Do not include the raw scanner metric in the final report.
  2. Document the manual verification step, including the exact state of the library wrapper.
  3. Classify the finding based on actual operational impact (Low/Informational), adding a note explaining why the scanner output was a false positive to prevent client audit confusion.

Scenario B: Client Dispute Over Finding Severity

• Symptom: The asset owner disputes a "High" severity rating assigned to an internal misconfiguration, claiming compensating controls mitigate the risk.
• Immediate Corrective Action Protocol:
  1. Convene a technical review meeting between the Lead Penetration Tester and the client’s security team within 24 hours of report delivery.
  2. Review the environmental metrics of the CVSS score together. If documented, verifiable compensating controls are proven to reduce the attack vector or user interaction requirements, adjust the environmental score accordingly.
  3. If controls are theoretical or non-enforced, maintain the original rating while adding an addendum noting the client's planned compensating controls as a future remediation milestone.

Scenario C: Missing Evidence Block During Final QA Review

• Symptom: During Phase 4 QA, an auditor notes that a Medium-severity privilege escalation finding lacks the required screenshot or terminal log proving the state change.
• Immediate Corrective Action Protocol:
  1. Halt report finalization immediately.
  2. Task the Lead Penetration Tester with reproducing the finding in a controlled staging environment or extracting the missing artifact from the session logs.
  3. If the evidence cannot be recovered or reproduced, downgrade the finding to an Informational advisory or remove it from the report entirely until re-assessment can occur.