Penetration Testing Report

One-liner: The formal deliverable that documents findings, business impact, and remediation guidance from a penetration test.

🎯 What Is It?

A penetration testing report is the primary output of a security assessment. It translates technical findings into actionable intelligence for multiple audiences—from executives to developers—ensuring vulnerabilities are understood, prioritized, and remediated. Unlike raw tool output, a pentest report provides context, business impact, and clear remediation steps.

🤔 Why It Matters

• The only lasting deliverable — Long after shells close and tools exit, the report remains
• Drives remediation — Without a clear report, findings get ignored or misunderstood
• Legal/compliance evidence — Documents due diligence for audits and regulations
• Communication bridge — Connects technical findings to business risk

For Different Audiences

• Developers — Need technical details and code examples to fix issues
• Security teams — Need to prioritize remediation and track progress
• Executives — Need business impact and risk context to allocate resources

📊 Report Structure

Three Core Sections

Summary Section

The summary provides a non-technical overview for decision-makers:

Executive Summary (Business Focus)

• What was tested (application/network description)
• Overall security posture
• Key business risks
• High-level recommendations

Findings & Recommendations (Security Focus)

• Vulnerability statistics and risk ratings
• Common vulnerability themes
• Attack chains (how low/medium findings combine for high impact)
• Systemic issues to prevent future vulnerabilities

Vulnerability Write-Ups

Each vulnerability gets a standalone write-up with consistent structure:

Essential Elements:

• Title — Clear, descriptive (e.g., "Unauthenticated SQL Injection in Login Form")
• Risk Rating — Using CVSS or client's matrix; rated in isolation
• Summary — Brief explanation and impact in plain language
• Background — Context for non-security experts (what is SQL Injection?)
• Technical Details & Evidence — HTTP requests, responses, screenshots, code snippets
• Impact — Real-world consequences specific to the tested system
• Remediation Advice — Actionable steps that address root cause, not just symptoms
• References — Links to vendor docs, OWASP, security resources

The Golden Thread: As expertise grows, these sections flow naturally without rigid headings. The report tells a story that readers can follow from discovery to resolution.

Appendices

Supporting documentation for completeness and future testing:

Assessment Scope

• Originally scoped vs. achieved coverage
• Out-of-scope items
• Limitations and constraints
• Recommendations for follow-up testing

Assessment Artifacts

• Files created during testing (webshells, test accounts, uploaded files)
• Changes made to the system
• Cleanup recommendations
• Credentials used

🔬 Technical Deep Dive

Contextualizing Vulnerabilities

A great write-up explains the finding in the context of the specific system:

❌ Generic: "SQL Injection allows database access"
✅ Contextualized: "This SQL Injection in the login form bypasses authentication on the customer portal, allowing access to 50,000+ customer records including PII"

Risk Rating Best Practices

• Rate vulnerabilities in isolation — Assume all other findings don't exist
• Use CVSS v3.1 or client's matrix consistently
• Document rating justification
• Highlight attack chains separately in findings summary

Remediation: Root Cause First

Your primary recommendation must fix the vulnerability at its core:

Example: SQL Injection

• ✅ Primary Fix: Use Parameterized Queries — Prevents SQL confusion regardless of input
• ✅ Defense-in-Depth: Input validation and WAF rules can help but cannot replace parameterization
• ❌ Mitigation Only: Input sanitization alone doesn't fix the root cause

🛡️ Writing Best Practices

Clarity and Professionalism

• Past tense — "The vulnerability was discovered..." (not "we pwned the login")
• No first person — Avoid "I", "we", "our" (write as neutral observer)
• Objective tone — Stick to facts, no exaggeration or emotion
• Consistent terminology — Don't switch between "parameter", "variable", "input"
• Mask sensitive data — Never include real passwords or PII without authorization

Quality Assurance Process

• Self-review — Read your own work with fresh eyes
• Read aloud — Catches awkward phrasing and errors
• Peer review — Have another tester check technical accuracy and clarity
• Consistency check — Same format, terminology, and style throughout
• Evidence verification — Ensure screenshots and code snippets match descriptions

🎤 Interview Angles

Common Questions

• "Walk me through the structure of a pentest report"
• "How do you explain technical findings to non-technical stakeholders?"
• "What's the difference between an executive summary and findings summary?"
• "How do you prioritize and rate vulnerabilities?"

STAR Story

Situation: Completed a web application penetration test for a healthcare client with multiple critical findings.
Task: Write a report that would drive remediation across technical and business stakeholders.
Action: Structured the report with an executive summary focusing on HIPAA compliance risk for the CISO, detailed technical write-ups with .NET/MS SQL code examples for developers, and a findings summary highlighting how medium-risk XSS + session fixation could lead to PHI exposure. Included assessment artifacts appendix listing all test accounts and webshells requiring cleanup.
Result: Client remediated all critical findings within 2 weeks. Development team used the code examples to fix not just reported issues but similar patterns throughout the codebase. Report was used as template for subsequent assessments.

✅ Best Practices

Do's

• Write summary last after completing technical sections
• Provide client-specific remediation (not generic copy-paste)
• Include working exploit code when safe and authorized
• Document systemic issues (not just individual findings)
• Use screenshots with sensitive data redacted
• Explain why a fix works, not just what to do

Don'ts

• Never use first-person language ("we", "our", "I")
• Don't copy findings from old reports without contextualizing
• Don't use informal language or humor
• Don't include unverified or assumed information
• Don't rely on tools alone — provide manual validation
• Don't just describe the vuln without explaining impact

📈 Real-World Importance

• Legal evidence — Reports used in breach litigation and regulatory proceedings
• Compliance — Required for PCI-DSS, SOC 2, ISO 27001 audits
• Vendor assessment — Third-party security validation
• Risk management — Informs insurance and risk decisions

❌ Common Misconceptions

• "The report is just documentation" → It's the primary deliverable, not an afterthought
• "More findings = better report" → Quality and context matter more than quantity
• "Technical teams don't need context" → Even experts benefit from clear explanations
• "Tools can generate reports" → Tool output lacks context, business impact, and remediation guidance

🔗 Related Concepts

• CVSS
• SQL Injection
• Parameterized Queries
• OWASP
• Vulnerability Management
• Risk Rating
• Technical Writing

📚 References

• PTES Technical Guidelines: http://www.pentest-standard.org/
• OWASP Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• SANS Pentest Report Template
• NIST SP 800-115 - Technical Guide to Information Security Testing