A penetration test report has two audiences: executives who read summaries and make risk decisions, and engineers who implement fixes. Structure the report to serve both — never bury the business impact in technical jargon, and never strip technical depth from the findings section.
- Cover page — engagement name, client, dates, classification
- Executive summary — business risk, key findings, overall severity
- Scope & methodology — what was tested, how, and when
- Attack narrative — chronological story of the engagement
- Technical findings — detailed per-finding breakdown
- Remediation summary — prioritized action list
- Appendices — raw output, tooling used, cleanup confirmation
- Executive summary filled with technical jargon
- No business impact stated — only technical description
- Screenshots without annotation or explanation
- Generic remediation ("patch your software")
- No evidence of cleanup / artifacts removed
- CVSS scores without contextual risk adjustment
- Vague scope definition — causes scope creep disputes
The executive summary is the most-read section and often the only section read by decision-makers. It must communicate business risk clearly — without technical prerequisites. Write it last, after all findings are documented.
- What was the objective of the engagement?
- What was the overall outcome? (e.g., "Domain Admin achieved in 4 hours")
- What are the highest-risk findings in plain language?
- What is the potential business impact if exploited by an actual threat actor?
- What are the top 3 remediation priorities?
- Positive observations — controls that worked
- 1–2 pages maximum
- No CVE IDs, no tool names, no command-line output
- Business language: "unauthorized access to payroll data" not "SAM dump"
- Active voice: "An attacker could…" not "It was found that…"
- Lead with risk — don't bury the lede
Every finding must follow a consistent structure. Inconsistent findings are harder for engineers to implement and look unprofessional. Each finding is a standalone unit — it should be fully understandable without reading surrounding findings.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — base score 9.8 CriticalSeverity is a function of exploitability, impact, and context — not just CVSS score. A CVSS 9.8 on a dev-only server with no sensitive data may be Medium in context. A CVSS 5.0 exposing PII to the internet may be Critical in context. Always document your contextual adjustment reasoning.
| Severity | CVSS Range | Criteria | Remediation SLA |
|---|---|---|---|
| Critical | 9.0–10.0 | Remote code execution, unauthenticated access to sensitive data, full system compromise, active exploitation in the wild | 24–48 hours |
| High | 7.0–8.9 | Authenticated RCE, significant data exposure, privilege escalation to admin, lateral movement enablement | 7 days |
| Medium | 4.0–6.9 | Limited data exposure, requires user interaction, weak cryptography, password spraying feasibility | 30 days |
| Low | 0.1–3.9 | Minimal impact, defense-in-depth gaps, information disclosure without sensitivity, hardening opportunities | 90 days |
| Info | N/A | Observations, best practice gaps, configuration recommendations, positive findings — no risk rating | Best effort |
CVSS v3.1 Base Score measures the intrinsic properties of a vulnerability. Use the Base Score as a starting point, then apply Temporal and Environmental adjustments for context. Never report raw CVSS as the final severity without environmental consideration.
Remediation guidance is the most actionable part of your report — and the most frequently written poorly. Generic advice ("apply the vendor patch") provides no value beyond what a Google search returns. Write remediation that a developer or sysadmin can execute without needing to research further.
- Specifies the exact configuration change, file path, or code fix
- References the specific vendor advisory or CVE
- Distinguishes short-term mitigations from long-term fixes
- Notes when a fix requires testing before production rollout
- Includes verification step — "confirm fixed by…"
- Prioritizes findings by effort vs. risk reduction
- Immediate: Disable or isolate the affected system now
- Short-term: Patch, config change, credential reset — within SLA
- Medium-term: Architectural change, policy update, additional tooling
- Long-term: Security program maturity improvement, training, process
- Compensating control: Reduce risk when full fix is not immediately possible