How to Write a Penetration Testing Report (Step by Step)

A penetration testing report is the deliverable that justifies the engagement. You can find critical vulnerabilities during testing, but if the report is disorganized, vague, or missing reproduction steps, the client cannot prioritize fixes — and your work loses impact. This guide walks through the exact structure professional pentesters use, from executive summary to individual finding write-ups, so you deliver reports that get read, understood, and acted on.

Whether you are a solo consultant or part of a red team, the principles are the same: scope clearly, write for two audiences (executives and engineers), and make every finding reproducible. Start from our penetration testing report template if you want a ready-made structure, then follow the steps below to fill it in.

Why report structure matters

Clients receive pentest reports under time pressure. Security leaders need a risk summary for leadership; developers need HTTP requests and exact URLs. A single wall of technical jargon serves neither audience. The standard approach splits the document into an executive-facing front section and a technical findings section, each with predictable headings.

Consistent structure also helps you write faster. When every finding follows the same template — title, severity, description, impact, proof of concept, remediation — you spend less time deciding what to include and more time validating vulnerabilities. Tools like PoCcraft automate the repetitive formatting so you focus on accuracy.

Step 1: Document scope and methodology

Before listing findings, establish what was tested and how. Include:

• In-scope assets: domains, IP ranges, applications, API endpoints, and environments (production vs staging).
• Out-of-scope items: third-party SaaS, denial-of-service, social engineering — whatever you excluded and why.
• Testing window: dates, time zones, and any blackout periods.
• Methodology: frameworks referenced (OWASP Testing Guide, PTES, NIST SP 800-115) and testing types performed (external, internal, web app, API).
• Tools used: Burp Suite, Nmap, custom scripts — enough detail for transparency, not a full tool dump.

This section protects you legally and sets client expectations. If a finding is on an out-of-scope subdomain, the scope section makes that boundary clear. For help mapping common web flaws to standard categories, see our OWASP Top 10 guide for report writers.

Step 2: Write the executive summary

The executive summary is the most-read page in the report. Write it last, but place it first. Aim for one to two pages covering:

• Overall security posture (e.g., "moderate risk with two critical issues requiring immediate attention")
• Total findings by severity (Critical, High, Medium, Low, Informational)
• Top three to five risks in plain language — what could happen, not just CVE numbers
• Recommended priority order for remediation

Avoid jargon like "reflected XSS in the search parameter." Instead: "An attacker could run malicious code in users' browsers via the site search box, potentially stealing session cookies." Executives fund fixes when they understand business impact, not CVSS vectors.

Step 3: Structure each finding consistently

Every vulnerability entry should use the same template. A proven structure:

1. Finding title — specific and searchable (e.g., "Stored XSS in /api/comments endpoint")
2. Severity — Critical / High / Medium / Low / Info, with CVSS score and vector
3. Affected assets — URL, host, version, parameter name
4. Description — what the vulnerability is and how you found it
5. Impact — what an attacker could achieve (data theft, account takeover, RCE)
6. Proof of concept — steps, screenshots, request/response pairs
7. Remediation — specific fix, with code or config examples where possible
8. References — CWE, OWASP, vendor advisories

Need a filled example? Our vulnerability assessment report example shows what each section looks like with real content.

Step 4: Write reproducible proof of concept

A finding without reproduction steps is an opinion. Developers and triage engineers need to verify the issue independently. Include:

• Numbered steps from a clean starting point (logged-out user, specific role, etc.)
• Full HTTP requests and responses (Burp copy-paste or curl commands)
• Screenshots with annotations highlighting the vulnerable behavior
• Any prerequisites (specific user role, feature flag, test account)

Redact sensitive tokens and passwords, but keep enough context to reproduce. If the PoC requires multiple chained steps, show the full chain — partial reproduction leads to "cannot reproduce" pushback. The same standard applies to bug bounty reports, where missing repro is the top rejection reason.

Step 5: Provide actionable remediation

Generic advice like "apply security patches" or "use input validation" wastes everyone's time. Instead:

• Name the specific control (parameterized queries, Content-Security-Policy, output encoding)
• Point to framework-native fixes (e.g., Django's escape, React's default JSX encoding)
• Suggest verification steps the client can use to confirm the fix
• Note any defense-in-depth measures beyond the primary fix

When scoring severity, document your rationale. Use our CVSS calculator and explain which metrics drove the score — especially if you deviate from the calculator's base score based on environmental factors.

Step 6: Review, peer-check, and deliver

Before delivery, run through this checklist:

• All findings have consistent severity labels and CVSS vectors
• Executive summary numbers match the findings table
• No out-of-scope assets appear in findings
• PoC steps were re-tested on a fresh session
• Client names, internal hostnames, and credentials are properly redacted
• Spell-check and formatting are consistent throughout

Schedule a walkthrough call for critical or complex engagements. Live explanation reduces misinterpretation and builds client trust. For ongoing engagements, compare against previous reports to highlight regressions and improvements.

Common mistakes to avoid

Burying the lead. Do not make executives read 80 pages to find the two critical issues. Front-load risk in the summary and findings overview table.

CVSS without context. A CVSS 9.8 on an internal-only admin panel behind VPN may not warrant the same urgency as a 7.5 on a public registration form. Document environmental adjustments.

Copy-paste findings. Each finding should reflect the specific asset and context. Templated language is fine; generic filler is not.

Missing positive observations. Note effective controls you encountered (strong MFA enforcement, proper WAF rules). Balanced reporting builds credibility.

The bottom line

A strong penetration testing report is structured, reproducible, and written for two audiences. Define scope first, summarize risk for leadership, then document each finding with consistent severity, clear impact, working PoC, and specific remediation. Use a report template to stay consistent, validate scores with a CVSS calculator, and let PoCcraft handle the formatting so you deliver faster without sacrificing quality.