Professional Penetration Test Reporting

The penetration test report is the primary deliverable of any engagement — it is what clients pay for, and what determines whether technical findings translate into real security improvements. An expert-level pentest report is not simply a list of vulnerabilities; it is a professional document that communicates risk clearly to both technical and executive audiences, provides actionable remediation guidance, and stands up to scrutiny from security teams, auditors, and legal counsel.

Many technically excellent pentesters produce poor reports that clients cannot action. The report is where the engagement either succeeds or fails commercially and professionally. At Expert level, report writing is a core technical skill equal in importance to exploitation — arguably more important, because a finding that isn't understood cannot be fixed.

Why Most Reports Fail

Reports fail for predictable reasons, and understanding them is the starting point for producing work that stands out. The most common failure modes are: writing entirely for a technical audience (executives stop reading and findings don't get resourced), writing entirely for executives (developers cannot reproduce or fix anything), providing generic remediation advice (teams can't implement it without additional research), and failing to connect individual findings into a coherent risk narrative (the severity of the overall security posture is understated).

The professional standard for a penetration test report has converged across the industry — frameworks such as the Penetration Testing Execution Standard (PTES), OWASP's Testing Guide, and the reporting guidance published by CREST and PNPT all describe similar document structures. Understanding this standard means your reports match what clients, audit teams, and compliance frameworks expect to receive.

Professional Report Architecture

Cover Page          Client name, engagement type, date, classification, version
Executive Summary   Business risk overview (1-2 pages, non-technical)
Scope and Methodology What was tested, how, when, from what access position
Risk Rating Summary Visual chart of findings by severity, trend vs prior tests
Technical Findings One section per finding — the bulk of the report
Attack Narrative   How findings chained to achieve worst-case impact
Remediation Roadmap Prioritised fix list with estimated effort and timeline
Appendices         Raw tool output, methodology detail, additional evidence

Report Classification and Handling

A penetration test report contains information that an attacker would find highly valuable — exact reproduction steps for critical vulnerabilities, confirmed credentials, and maps of internal network topology. It must be treated as sensitive by default. Professional reports include a clear classification marking on every page (typically "Confidential — Restricted Distribution"), a list of named recipients, and explicit destruction instructions for unused copies. Distributing a pentest report outside the agreed recipient list — or storing it unencrypted — is a serious breach of professional responsibility that your engagement contract should address explicitly.

The report should also carry a clear statement of scope limitations: what was not tested, what access was granted that a real attacker would not have, and what findings may exist outside the tested perimeter. Clients sometimes assume that an absence of findings in a particular area means it is secure — the scope statement prevents that dangerous misreading.

Report Writing in Practice

POOR (technical, no business context):
"We identified an unauthenticated SQL injection vulnerability in the
/patient endpoint that allows UNION-based extraction of the database
via the id parameter with a CVSS score of 9.8."

GOOD (business risk, clear consequence):
"An attacker with no account or prior access could extract the complete
patient database — including 847,000 patient records with personal
health information — from the internet in approximately 4 hours.
This represents a critical HIPAA breach risk with potential fines
exceeding $1.9M and significant reputational damage."

Finding ID    CORP-PT-2026-001
Title         Unauthenticated SQL Injection in Patient Record Endpoint
Severity      Critical
CVSS Score    9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE           CWE-89: SQL Injection
Affected      https://portal.corp.com/patient?id=[parameter]

Description
  The id parameter in the /patient endpoint is concatenated directly
  into a SQL query without sanitisation or parameterisation. An
  unauthenticated attacker can inject arbitrary SQL and extract,
  modify, or delete any database record.

Evidence      [Screenshot: UNION SELECT output showing patient PII]
Reproduction  1. Navigate to: portal.corp.com/patient?id=1
              2. Append: ' UNION SELECT 1,username,password FROM users--
              3. Observe: database credentials returned in response

POOR (generic, not actionable):
"Use parameterised queries to prevent SQL injection."

GOOD (specific, technology-matched, with code):
Immediate (24-48 hours):
  Replace string concatenation in patient.php line 47 with
  PDO prepared statements:

  BEFORE: $query = "SELECT * FROM patients WHERE id = " . $_GET['id'];

  AFTER:  $stmt = $pdo->prepare("SELECT * FROM patients WHERE id = ?");
          $stmt->execute([$_GET['id']]);

  Add input type validation as defence-in-depth:
  if (!filter_var($_GET['id'], FILTER_VALIDATE_INT)) { die(); }

Long-term:
  Deploy WAF rule to block SQLi patterns as compensating control.
  Add SAST scanning for SQL concatenation patterns to CI/CD pipeline.

Attack Narrative — Full Domain Compromise

Day 1, 09:14  Phishing email delivered to j.smith@corp.com [CORP-PT-2026-008]
              Employee opened attachment, executing macro payload

Day 1, 09:26  Meterpreter C2 session established from CORP-WS-022
              Initial access: standard user, no admin rights

Day 1, 11:44  Kerberoasting identified svc_sql with weak password [CORP-PT-2026-003]
              Password cracked in 4 minutes: Sql@dmin2024!

Day 1, 14:22  svc_sql used to access SQL server, xp_cmdshell enabled
              Lateral movement to CORP-SRV-02 as SYSTEM

Day 2, 02:14  DCSync executed from CORP-SRV-02 -- all 2,847 domain hashes extracted
              Full domain compromise achieved 17 hours after initial phishing email

Vulnerability: Kerberoastable Service Account (svc_sql)

CVSS Base Score Calculation:
  Attack Vector: Network (N)         -- any domain user can request tickets
  Attack Complexity: Low (L)         -- trivial with Rubeus
  Privileges Required: Low (L)       -- requires domain user account only
  User Interaction: None (N)
  Scope: Changed (C)                 -- escalation to other systems
  Confidentiality: High (H)          -- access to SQL server data
  Integrity: High (H)                -- can modify database records
  Availability: High (H)             -- can drop tables/databases

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9 Critical

Environmental adjustment:
  ConfidentialityRequirement: High (healthcare data in scope)
  Modified Score: 10.0 Critical (maximum)

  Justification: svc_sql has DBO on the patient records database
  containing 847,000 records subject to HIPAA. Compromise of this
  account directly impacts regulatory compliance posture.

Immediate (0-72 hours) — Stop active exploitation risk
  1. Patch SQL injection (CORP-PT-2026-001)               4 hours dev effort
  2. Reset svc_sql password, remove from DBO role          1 hour
  3. Force MFA for all O365 accounts (CORP-PT-2026-008)   2 hours IT effort

Short-term (2-4 weeks) — Address high severity findings
  4. Deploy EDR on all endpoints (CORP-PT-2026-012)       1 week
  5. Implement LAPS for local admin passwords              1 week
  6. Enable SIEM alerting on Event 4728, 4769             3 days

Long-term (1-3 months) — Structural improvements
  7. AD tiering model implementation                      6 weeks
  8. Security awareness training programme                ongoing
  9. Quarterly penetration testing cadence                ongoing

What You Need to Know

Severity Ratings — Calibrating Risk Accurately

Severity rating is where many junior practitioners get it wrong in both directions — either rating everything Critical to emphasise urgency (which leads to alert fatigue and clients deprioritising genuine Critical findings) or being overly conservative to seem measured (which obscures real risk from decision-makers). Accurate calibration builds credibility; miscalibration erodes it.

The industry has largely standardised on a five-level severity scale, typically aligned to CVSS base score bands. But CVSS alone is an incomplete picture — a finding's severity in context depends on the exploitability given the target environment, the business value of what is exposed, and the existence of compensating controls. The environmental CVSS score, adjusted for these factors, produces the contextual severity that should appear in your report.

When CVSS Understates Risk

The CVSS scoring system was designed to be vendor-neutral and context-agnostic — which means it cannot account for business-specific factors. Several situations consistently produce CVSS scores that understate actual risk in the client's context:

• Regulatory exposure: A Medium CVSS vulnerability affecting a database containing PHI (HIPAA), PCI cardholder data, or GDPR-regulated personal data carries regulatory consequence that dwarfs the technical severity. Always note applicable regulatory frameworks in the finding.
• Operational criticality: A denial-of-service vulnerability (often scored Medium because it "only" affects availability) against a 24/7 trading system, hospital life-safety infrastructure, or e-commerce platform during peak season may warrant elevation to Critical based on business impact.
• Chaining potential: An information disclosure that by itself scores Low can elevate other findings significantly when it provides prerequisites for exploitation — such as disclosing internal hostnames that allow a scanner to reach otherwise unreachable targets.
• Exploitability in context: A vulnerability rated High on CVSS due to theoretical complexity may be trivially exploitable with a published Metasploit module. When a working exploit is publicly available, practical exploitability should be reflected in your severity rating even if CVSS does not capture it.

Capturing and Presenting Evidence

Evidence is what transforms a finding from an assertion into a proven fact. Every finding in a professional report must be supported by evidence that a third party — a developer who wasn't in the room, an auditor reviewing the report six months later, or a lawyer assessing liability — can independently evaluate. The standard for evidence is that it must be unambiguous, reproducible, and sufficient.

What Constitutes Good Evidence

• Screenshots with annotations: A raw screenshot of a database dump is evidence. A screenshot with red arrows indicating exactly which field contains the injected payload, and which line of the response contains the extracted data, is better evidence — it tells the story without requiring the reader to already understand SQL injection output format.
• HTTP request and response pairs: For web application findings, include the exact HTTP request sent (including all relevant headers and the payload) alongside the server's response. Burp Suite's "Copy as curl" function produces a reproducible request any developer can verify.
• Tool output with context: Raw tool output without context is insufficient. Include the command used to produce it, the timestamp, the target system, and an annotation identifying which line proves the finding. A block of Nmap output with no indication of what to look at serves no one.
• Timestamps: Every piece of evidence should carry a timestamp. This establishes that the vulnerability existed at the time of the test, provides a timeline for the attack narrative, and is legally important if the report is used in regulatory proceedings.

Evidence: SQL Injection — CORP-PT-2026-001
Tested: 2026-03-14 11:32:17 UTC | Tester: J. Harlow

REQUEST:
GET /patient?id=1'+UNION+SELECT+1,username,password+FROM+users-- HTTP/1.1
Host: portal.corp.com
Cookie: session=a3f9b2c1[...redacted...]

RESPONSE (truncated):
HTTP/1.1 200 OK
{"patient_id":1,"name":"admin","dob":"5f4dcc3b5aa765d61d8327deb882cf99"}
                                      ^^ MD5 hash of 'password' — admin cred

# The UNION SELECT injected a row from the users table into the patient
# response. The 'dob' field contains the admin password hash, confirming
# UNION-based SQL injection with cross-table data extraction capability.

Handling Sensitive Evidence

During testing you will inevitably encounter real sensitive data — actual employee records, actual credentials, actual patient information. How you handle this data is an ethical and often legal obligation. Best practices for evidence handling are: capture only the minimum necessary to prove the finding (a single row of a database is sufficient to demonstrate SQL injection; you do not need to download the whole table), redact or partially mask credentials and personal data in your report (use format-preserving masking — show enough to confirm the format, not the actual value), document in your methodology section how sensitive data encountered during testing was handled and destroyed, and never exfiltrate real data from the client environment to your own systems unless explicitly authorised for that specific purpose in the statement of work.

Writing for Executive Audiences

The executive summary is the most read — and most miswritten — section of any pentest report. Executives and board members are not security professionals. They are decision-makers who need to understand risk in financial, operational, and reputational terms so they can allocate resources and direct remediation. The technical detail belongs in the technical findings section. The executive summary is for business consequence.

What Executives Need to See

The executive summary should answer four questions that every business leader will have after receiving a pentest report: How bad is it? How likely is it to be exploited? What could an attacker actually do? What are we doing about it?

A strong executive summary answers all four concisely, uses plain language throughout, includes a simple visual risk rating summary (a chart showing Critical/High/Medium/Low/Info counts is worth many paragraphs), and ends with a clear statement of recommended priorities. It should be readable in under five minutes — if it requires more time than that, it will not be read by the people who need to act on it.

Disclosure Ethics and Professional Responsibility

Report writing is not just a technical skill — it is where professional ethics become concrete. The way a finding is documented, how sensitive data encountered during testing is handled, how evidence is preserved and protected, and how the report is distributed all carry ethical and sometimes legal weight. Understanding the ethical framework that governs penetration testing reporting is essential for anyone operating at expert level.

Coordinated Disclosure vs Full Disclosure

In the context of a contracted penetration test, the "disclosure" question primarily applies when you discover vulnerabilities in third-party software or services that the client uses — not vulnerabilities in the client's own configuration. If testing reveals a zero-day in a commercial product, responsible disclosure means notifying the vendor through their security reporting channel, typically with a 90-day timeline to patch before public disclosure, coordinated through processes like CVD (Coordinated Vulnerability Disclosure).

For findings that are configuration or implementation issues specific to the client (the overwhelming majority of pentest findings), disclosure is governed by your statement of work, which should specify who receives the report, how long findings remain confidential, and what happens to report copies at engagement close. These terms protect both parties — clients don't want their vulnerabilities public, and testers don't want liability exposure from findings being misused.

What Happens When You Find Something Unexpected

During testing you may discover evidence of an active compromise — logs showing a command-and-control beaconing pattern, an unexpected user account, or data that suggests an attacker is already present. This situation is not covered by the standard pentest workflow and requires immediate, careful handling:

1. Stop active testing in the area where the evidence was found to avoid contaminating forensic evidence or interfering with an ongoing incident.
2. Immediately notify the primary client contact and document the notification with a timestamp.
3. Preserve your own logs and evidence from the moment of discovery — you may be called as a witness or consultant in subsequent incident response.
4. Do not attempt to investigate the suspected attacker's activity beyond what is needed to document the finding — you may be operating outside your engagement scope and potentially interfering with law enforcement considerations.

Your engagement contract should ideally address this scenario in advance. Many professional pentest engagements include an incident response escalation clause that defines exactly this procedure. If yours does not, raise it before testing begins.

Core Concepts Summary