Ethical Hacking Report Writing and Penetration Test Documentation

A penetration test is only as valuable as the report that comes out of it. An ethical hacker who finds critical vulnerabilities but writes an unclear, unstructured, or incomplete report has delivered limited value to the client. The report is the primary deliverable — it is what the client pays for, presents to management, uses to prioritize remediation, and potentially shares with auditors and regulators.

Writing excellent penetration test reports is a professional skill that separates junior testers from senior practitioners.

Who Reads the Report

A penetration test report has multiple audiences with different needs:

  • Executive management / board — Needs a high-level understanding of business risk, not technical details. Reads the executive summary only.
  • IT management / security team lead — Needs prioritized findings with risk ratings to plan and resource remediation.
  • Developers and system administrators — Needs precise technical details and step-by-step reproduction instructions to understand and fix each issue.
  • Auditors and compliance teams — Needs evidence that the test was properly scoped, authorized, and executed according to standards.

A well-structured report serves all these audiences simultaneously through layered information architecture.

The Report Structure

Cover Page

The cover page includes the client name, the testing organization's name, the report classification (Confidential), the date of the report, and the report version. Every penetration test report is highly confidential — it contains a complete map of an organization's security weaknesses.

Table of Contents

Longer reports require a table of contents. Readers navigate directly to the sections relevant to their role.

Executive Summary

The executive summary is the most important section. It is the section that non-technical decision-makers read. It must communicate clearly in plain language:

  • The overall security posture of the tested environment (not a letter grade — a clear written assessment)
  • The most critical risks in business terms: "An attacker with internet access could access the company's customer database, exposing personal and financial records of all 500,000 customers."
  • A brief summary of the scope, timeline, and testing approach
  • Top three to five recommendations in priority order

The executive summary contains no CVE numbers, no exploit names, no command-line syntax. It uses the language of business risk, not security technology.

Scope and Methodology

This section documents the authorized scope exactly as defined in the engagement agreement: IP ranges, domains, applications, and testing periods. It describes the methodology used — which framework (PTES, OWASP, NIST) guided the test, and what testing types were performed (external, internal, web application, social engineering). This section proves the test was properly authorized and bounded.

Findings

The findings section is the technical core of the report. Each finding requires a standardized structure:

Finding Structure
FieldContent
Finding TitleShort, descriptive name: "SQL Injection in Login Form"
Severity RatingCritical / High / Medium / Low / Informational
CVSS ScoreNumerical severity score (0.0–10.0)
Affected SystemSpecific host, URL, or component: https://portal.example.com/login
DescriptionPlain-language explanation of the vulnerability and how it works
ImpactWhat an attacker could do if they exploited this: "An attacker could read, modify, or delete all records in the customer database."
Steps to ReproduceExact, step-by-step instructions a defender can follow to confirm the issue exists
EvidenceScreenshots, tool output, and request/response captures proving the vulnerability
RecommendationSpecific, actionable fix: "Use parameterized queries / prepared statements for all database interactions."
ReferencesCVE number, OWASP entry, vendor advisory, or CWE ID

Risk Rating: CVSS Scoring

CVSS (Common Vulnerability Scoring System) provides a standardized numerical score from 0.0 to 10.0. The score is calculated from metrics including: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction required, scope, and impact on confidentiality, integrity, and availability.

CVSS scores map to severity ratings:

  • 0.0 — None
  • 0.1–3.9 — Low
  • 4.0–6.9 — Medium
  • 7.0–8.9 — High
  • 9.0–10.0 — Critical

Recommendations Summary

A consolidated table listing all findings, their severity, and their remediation recommendation — sorted from Critical to Informational. Management uses this table to prioritize remediation work and assign it to the right teams.

Appendices

Appendices contain detailed tool output, full lists of enumerated hosts and ports, raw scan results, and other supporting technical evidence that would make the main findings section too long but is valuable as reference material during remediation.

Writing Quality Standards

Use Active Voice

Active voice is clearer and more direct. "The attacker accessed the database" is better than "The database was accessed by the attacker." In findings, "An attacker can read all user records" is better than "All user records can be read."

Write for the Fixer

Every finding description should answer: "If I were the developer who wrote this code, what would I need to know to fix it?" Include the exact affected URL, the exact parameter tested, the exact payload used, and the exact expected versus actual behavior.

Evidence Standards

Screenshots must clearly show the affected system, the testing action, and the result. Annotate screenshots to highlight the key evidence. Request and response captures should include all relevant headers. Command-line output should be copied verbatim rather than retyped.

Reproducibility is Non-Negotiable

Every finding must include steps to reproduce that actually work when followed exactly. A finding that cannot be reproduced from the report cannot be confirmed by the remediation team, cannot be verified as fixed, and loses credibility. Test your own reproduction steps before submitting the report.

The Retesting Process

After the client remediates findings, a retest verifies that each fix is effective. The tester revisits each finding and confirms whether the vulnerability has been resolved. Findings marked as remediated in the retest reduce the client's risk exposure and provide evidence of improvement for auditors.

Retest reports are typically shorter documents that reference the original report and confirm the status of each finding: Remediated, Partially Remediated, or Not Remediated.

Report Confidentiality and Handling

A penetration test report is one of the most sensitive documents an organization can possess. It contains a complete, proven map of exploitable vulnerabilities with exact reproduction steps. The ethical hacker handles this document with extreme care:

  • Transmit the report only through encrypted channels (encrypted email, secure client portal)
  • Do not store copies on personal devices or unsecured cloud services
  • Define document retention and destruction terms in the engagement contract
  • Password-protect the PDF report file with a strong, unique password

Key Points

  • The report is the primary deliverable of a penetration test; its quality determines the value the client receives.
  • The executive summary communicates risk in business language for non-technical audiences; findings sections provide technical detail for remediation teams.
  • Each finding requires a title, severity, description, impact, exact steps to reproduce, evidence, and a specific recommendation.
  • CVSS scoring provides a standardized numerical severity rating used for prioritizing remediation.
  • Reproducibility is essential — every finding must be exactly replicable by the remediation team from the report alone.
  • Reports are highly confidential documents that must be transmitted and stored securely.

Leave a Comment