How to Write a Penetration Test Findings Summary in English

A penetration test findings summary needs to serve two very different readers at once — engineers who need exact technical detail to reproduce and fix each issue, and leadership who need to understand overall risk without getting lost in exploit chains. Writing this clearly in English, with consistent severity language, is what makes the report drive action instead of just sitting in a shared drive.

Key Vocabulary

Finding — a single identified security issue documented in the report, typically including a description, evidence, severity rating, and recommended remediation. “This finding describes an authentication bypass in the password reset flow, with a proof-of-concept request attached showing exactly how it was triggered.”

Severity rating — a standardized classification (often Critical, High, Medium, Low) assigned to each finding based on its potential impact and how easily it can be exploited. “We rated this finding Critical because it allows unauthenticated access to other users’ data with no special conditions required.”

Proof of concept (PoC) — a minimal, reproducible demonstration that a vulnerability is real and exploitable, usually included so engineers can verify the fix against the same steps. “The proof of concept is a single curl command that returns another user’s private data — reproduce it against staging before and after your fix.”

Remediation — the recommended fix or mitigation for a finding, ideally specific enough that an engineer can act on it directly without further research. “The remediation here is straightforward: validate that the requested resource belongs to the authenticated user before returning it.”

Attack surface — the total set of points where an unauthorized user could potentially interact with or attempt to compromise a system, which a penetration test aims to map and probe. “This engagement focused on the external attack surface — public APIs and the customer-facing web app — internal services were out of scope for this round.”

Structuring the Summary

• Executive summary: “State overall risk posture in two or three sentences, and the count of findings by severity, before any technical detail — leadership reads this section and stops.”
• Scope: “Define precisely what was and wasn’t tested, so nobody assumes an untested system was implicitly cleared.”
• Findings: “One entry per issue, each with severity, description, proof of concept, and remediation — never bundle multiple unrelated issues into one finding.”
• Remediation timeline: “Pair each finding’s severity with an expected fix timeline, since ‘Critical’ should imply urgency that’s actually reflected in a deadline.”

Communicating to Different Audiences

• “For leadership: ‘This engagement identified one Critical and three Medium findings; the Critical issue has already been patched and verified, and the Mediums are scheduled for this sprint.’”
• “For engineers: ‘This finding is an IDOR on the /api/orders/{id} endpoint — see the attached proof of concept for the exact request that returns another user’s order.’”
• “For compliance stakeholders: ‘All findings are tracked with severity, owner, and remediation deadline in the linked ticket system, and we’ll provide a retest confirmation once each is closed.’”

Professional Tips

1. Rate severity consistently, not by gut feeling. Using a documented rubric (exploitability plus impact) for every finding, rather than an intuitive label, prevents disagreements later about whether something was really “Critical” or just alarming-sounding.
2. Include a proof of concept for every technical finding. A clear, reproducible PoC removes ambiguity about whether an issue is real and lets engineers verify their own fix against the exact same steps.
3. Pair every finding with a specific, assignable remediation. A finding without a concrete recommended fix reads as criticism without direction — always end each finding with what should change, not just what’s wrong.

Practice Exercise

1. Write a one-sentence executive summary describing a hypothetical penetration test with one Critical and two Low findings.
2. Draft a sample finding entry (description, severity, remediation) for an endpoint that returns data without checking the requester’s permissions.
3. Explain, in one sentence, why a proof of concept matters even after a finding has already been described in words.