How to Write a Pentest Report: Structure, Evidence, CVSS, and Remediation
A practical pentest reporting guide covering structure, evidence quality, CVSS usage, remediation writing, audience-specific communication, and a reusable checklist for actionable security reports.
Six months after an engagement, go and look at what happened to your findings. Not the ones marked Critical — those get fixed, because a red badge does its own advocacy. Look at the Mediums. A depressing share of them are still open, still in the same backlog, with a comment from a developer asking what the finding actually meant.
That is a writing failure, not a testing failure. The exploitation was real, the evidence was captured, and then the finding was described in language that gave nobody enough to act on. The report is the only part of a penetration test that outlives the engagement, and it is the part testers are least often trained to do.
Finding a SQL injection is a skill. Writing it up so a developer knows which function to change, a delivery manager knows what it displaces from the sprint, and an auditor can tie it to a control gap — that is three different documents living inside one, and doing it well is a separate discipline.
How to write a pentest report
What follows is a practical framework for reports that survive contact with the organisations that receive them.
1) The report is the real deliverable
The client did not buy your testing time. They bought a document, and everything the engagement produces reaches them through it. Access is revoked, the notes stay on your laptop, and what remains is the report — which means every judgement you made and did not write down is lost.
- It converts findings into prioritised work engineering can schedule
- It gives leadership a current, honest view of where risk sits
- It is a point-in-time record for compliance and governance
- It defines what retesting will check, so closure can be proven rather than asserted
- It gets security, engineering and leadership arguing about the same list
There is a trade-off buried in that list, and it is the one nobody warns junior testers about: time spent writing is time not spent testing. On a fixed-fee engagement, a day of report quality is a day of coverage you did not get. The right split depends on the client’s maturity — a team that has never had a pentest needs the writing more than the extra day of testing, and a mature security function usually needs the opposite. Decide deliberately at scoping rather than discovering it on the Thursday.
2) Write for multiple audiences in one document
Four groups will open your report and three of them will read only one section. Knowing which section that is for each reader is most of the job.
| Audience | What they are asking | What they need from you |
|---|---|---|
| Executive leadership | “How much business risk are we carrying?” | Risk themes, severity breakdown, timelines, and who owns what |
| Technical leads | “Which systems are affected and what do we fix first?” | Asset mapping, prioritised remediation steps, sequencing advice |
| Developers | “What exactly broke and how do I fix it?” | Reproduction steps, clear evidence, implementation-level guidance |
| Compliance and risk teams | “Is this documented well enough to satisfy an audit?” | Scope details, methodology, severity rationale, retest tracking |
Writing for four audiences in one document has a cost, and it is length. A report that fully serves all four is long enough that nobody reads it end to end — which is fine, provided the structure lets each reader find their part in under a minute. It stops being fine when the executive summary is on page nine because the methodology section came first. Order the document by who needs it soonest, not by the order in which you did the work.
3) Report structure that works in real projects
Use the same section order on every engagement, even when a particular test does not need all of it. Clients who receive reports from you repeatedly learn where things are, and that familiarity is worth more than a structure optimised for any single engagement. An empty “Retest status — not yet scheduled” section is more useful than a missing one, because it makes the gap visible.
Recommended sections
- Cover page
- Scope and rules of engagement
- Methodology summary
- Executive summary
- Risk overview and severity distribution
- Detailed findings
- Affected assets and service mapping
- Evidence appendix
- CVSS scoring and rationale
- Business impact mapping
- Remediation plan and ownership
- Retest status and results
- Appendix (references, exclusions, assumptions)
What each section should accomplish
| Section | Purpose | Mistake to avoid |
|---|---|---|
| Scope | Sets the legal and technical boundary of the test — and, read the other way, documents everything nobody looked at | Vague target lists, and omitting exclusions; the exclusions are what protect you when a breach later occurs somewhere you were never asked to test |
| Methodology | Shows how testing was performed, so a reader can judge how much weight the results carry | A tool list with no process. “We ran Burp” tells the reader nothing about coverage |
| Executive summary | Gives leadership an honest risk picture in under two minutes | Technical detail, or generic risk language that would fit any report for any client |
| Findings | Delivers the technical detail an engineer needs to reproduce and fix | Pasted scanner output. If you did not verify it by hand, say so explicitly rather than presenting it as tested |
| Remediation | States what to change, where, and how “fixed” will be judged | “Apply best practice.” Also: prescribing a fix you have not thought through, which wastes an engineering sprint |
| Retest | Establishes whether the risk actually went away | Leaving it empty and never returning. An untracked finding is an open finding |
4) A finding template you can reuse every time
A fixed finding template does two things. It speeds up triage, because the reader knows where the impact statement lives. More importantly, it makes omissions obvious — an empty preconditions field is visible in a way that a missing paragraph in free-form prose never is.
What to include in each finding
- Finding ID and a title describing the behaviour, not the tool that found it
- Affected asset, endpoint, or component
- Severity with the full CVSS vector, not just the score
- Technical description of what you observed — observed, not inferred
- Preconditions: which role, what access level, what state the application had to be in
- Evidence that is safe to circulate and sufficient to reproduce
- Business impact, in terms that mean something to the person funding the fix
- Remediation a developer can act on without a follow-up call
- One or two relevant references
- Named owner and SLA target
- Retest status with a date
The preconditions field is the one most often left thin, and it is the one that decides priority. “Any unauthenticated internet user” and “an authenticated user who has already been granted the finance role” describe wildly different risks, and if you omit that line the reader will assume whichever one suits their argument.
Example finding skeleton
| Field | Example |
|---|---|
| Title | “Cross-Tenant Access Allowed on Invoice Detail Endpoint” |
| Asset | api.billing.example — GET /v2/invoices/{id} |
| Severity | High (CVSS score and vector documented) |
| Evidence | Redacted request/response pair showing role comparison |
| Impact | Exposes confidential invoice metadata across tenants |
| Remediation | Enforce tenant ownership checks at the API service layer |
| Retest | Pending / Passed / Failed with date |
5) Evidence quality standards
Evidence has to do two contradictory things: prove the finding, and not become a liability once the report is circulating in email, ticket attachments and a shared drive with permissions nobody has reviewed since 2022. Assume your report will end up somewhere you did not intend, because it will. That assumption is what drives every redaction rule below.
What strong evidence looks like
- Screenshots cropped to the relevant element, with sensitive fields redacted before the image is saved
- Request/response pairs including method, path, authenticated role, and UTC timestamp
- Log excerpts tied to a specific tested action, so the defender can correlate against their own telemetry
- The exact endpoint, path and environment — including which environment, because “we fixed it in staging” is a real conversation
- A reproduction summary detailed enough to repeat and general enough not to be a weaponisable script
Comparing strong and weak evidence
| Evidence type | Strong example | Weak example |
|---|---|---|
| Screenshot | Focused on the relevant element, sensitive data redacted | Full-screen capture with passwords visible |
| Request/response | Includes method, endpoint, authenticated role, and result | Partial payload with no context |
| Timeline | Events in order with UTC timestamps | Unordered notes with no time references |
| Reproduction steps | Conditions and steps described safely | “Issue was reproduced” with nothing else |
| Logs | Correlated event IDs with system context | A random log line with no connection to the finding |
Redaction ground rules
- Strip customer personal data and secrets entirely — not blurred, removed
- Mask tokens, API keys and session identifiers, keeping enough leading characters to identify which credential it was
- Redact by editing the image, never by drawing a black box over a layer that can be moved. The same applies to PDF text under a rectangle, which is still selectable
- Keep the unredacted originals in access-controlled storage with a defined destruction date, and honour it
Any credential you saw during testing should be treated as compromised and rotated, whether or not it appears in the report. Say so explicitly in the findings, because the client will otherwise assume redaction covered it.
6) Using CVSS correctly in your reports
CVSS is a technical severity scale that the industry keeps using as a risk scale, and almost every argument about scoring comes from that substitution. The base score deliberately knows nothing about your business: it does not know the affected system holds regulated data, or that it is behind a VPN, or that it is scheduled for decommission next month. That is not a flaw in CVSS. It is the design, and it is what makes scores comparable across organisations.
The practical consequence is that CVSS should never be the sole input to your remediation order. Use the base score for consistency, then state business context separately and let the two disagree in the open. A 6.1 on the customer payments path outranking an 8.8 on an internal reporting tool is a defensible decision — it is only indefensible if you hide it by adjusting the 6.1 upward.
CVSS v4.0 was published in late 2023 and splits things out considerably more (attack requirements, separate vulnerable and subsequent system impacts). Most tooling and most client expectations still centre on v3.1. Whichever you use, state the version alongside the vector; a bare “7.5” is ambiguous between them.
How to get CVSS right
- Always publish the vector string with the score, and name the CVSS version
- Keep the base score technical. If someone asks you to raise it to force attention, that is a request to falsify a measurement
- Carry business urgency in a separate, explicitly labelled field
- Where a metric is genuinely uncertain — scope change is the usual culprit — document the assumption you scored under
How CVSS elements map to your report
| CVSS element | How it helps the report |
|---|---|
| Base score | Provides a standardised technical severity baseline |
| Vector string | Shows the logic behind the score so others can verify it |
| Context overlay | Captures business or operational urgency that lives outside the base score |
| Retest status | Tells readers whether the scored risk is still active |
Never inflate a score to force attention. Beyond the honesty problem, it is self-defeating: a team that has been handed three inflated Criticals stops believing the fourth, and the fourth is usually the real one. Persuasion comes from a clear impact statement, not from a number you nudged.
7) Weak vs. strong report writing
Every weak version below is technically accurate. That is the point — accuracy is not the bar. The strong versions differ by naming the actor, the mechanism and the consequence, which is what lets a reader decide anything.
| Weak version | Strong version |
|---|---|
| “Broken access control found.” | “A standard user can reach the admin-only billing export endpoint because the server skips role verification.” |
| “Critical vulnerability in API.” | “An authenticated low-privilege user can access invoices belonging to other tenants through the API due to missing authorisation checks.” |
| “Fix authentication issue.” | “Invalidate all active sessions after a password reset and require MFA on the account recovery endpoint.” |
| “Potential data breach risk.” | “Without tenant ownership checks, any authenticated user can pull invoice metadata from production by guessing endpoint IDs.” |
| “Patched by dev team.” | “Fix deployed on 2026-04-18. Retest confirmed that unauthorised role requests now return 403 Access Denied.” |
A useful test: could a developer who has never spoken to you open the ticket, find the code, and know when they are done? If the answer needs a meeting, the finding is not finished.
8) Writing remediation that developers can actually use
“Harden the API” is not remediation, it is a restatement of the finding in the imperative mood. Remediation names the change, the place, and the test that proves it worked.
There is a limit to how far a tester should go here, and it is worth being honest about it. You have seen the application from the outside for two weeks; the team has lived in it for three years. Prescribing an implementation you have not read the code for is how you end up recommending a fix that breaks a workflow you never knew existed. State the required security property precisely, suggest the enforcement point, and leave the implementation to people who know the codebase — while being clear that “we log it now” does not satisfy a property that requires blocking.
A good remediation entry should include
- The desired security behaviour after the fix
- Which layer needs the change (API gateway, service logic, auth middleware, database)
- Sequencing guidance if multiple fixes depend on each other
- Clear validation criteria so the retester knows what “fixed” looks like
Quick self-check for remediation quality
- Is there a named owner or team responsible?
- Is the scope of the change defined?
- Is the enforcement point identified?
- Is the retest condition explicit?
- Is the timeline realistic given the team’s SLA?
What good and bad remediation looks like
Bad: “Harden API authorisation.”
Better: “Add server-side tenant ownership verification in the invoice retrieval service. Before fetching data, compare the tenant ID in the JWT against the record’s owner. If they do not match, return 403. Add integration tests that cover cross-tenant access attempts.”
9) Using OWASP and MITRE references without cluttering the report
References earn their place when they tell the reader something the finding does not. A CWE identifier attached to a well-written description usually adds nothing for the developer — but it may be exactly what the compliance team needs to map the finding into their control framework. Include them for that reader, and keep them out of the way of the one who has to write the patch.
How to reference effectively
- Use OWASP categories (Top 10 or API Security Top 10) to classify the type of weakness
- Use MITRE ATT&CK when the finding maps clearly to an attack technique — especially useful for detection and response teams
- Keep each reference tied directly to the specific finding
- One or two relevant references per finding is usually enough
When to use which reference
| Reference | Best use case |
|---|---|
| OWASP Top 10 / API Top 10 | Classifying application and API weaknesses |
| MITRE ATT&CK | Giving behavioural context to detection and response teams |
| Internal standards | Connecting findings to your organisation’s own control framework |
| Compliance controls | Providing traceability for audits and governance reviews |
10) Common mistakes that weaken pentest reports
These are the patterns that get reports sent back, and most of them are habits rather than mistakes — which is why peer review catches them and self-review does not.
- Impact statements written in generic risk language that would fit any client
- Findings that read like scanner output because they are scanner output
- No owner and no priority, leaving the client to do the triage they paid you to do
- No retest commitment, so nothing is ever formally closed
- Evidence engineering cannot reproduce — often because the test data has since been wiped
- Narrative that buries the action item three paragraphs down
- Severity inflation to manufacture urgency
- The opposite failure, rarer and worse: softening a finding because the client pushed back in the readout
Three rules that catch most problems
- Every finding must answer: what happened, where, why it matters, how to fix it, and who owns it
- Every severity rating must include a CVSS vector with documented rationale
- Every critical or high finding must have an explicit retest plan
11) Pre-delivery checklist
Run this before the report leaves your organisation. Preferably with someone who did not do the testing, because the author is the worst possible reviewer of their own clarity.
| Checklist item | Status |
|---|---|
| Scope and exclusions are documented and approved | ☐ |
| Methodology reflects what was actually tested | ☐ |
| Executive summary highlights the top business risks clearly | ☐ |
| All findings use consistent structure and IDs | ☐ |
| Evidence is redacted, timestamped, and reproducible | ☐ |
| CVSS score and vector documented for every finding | ☐ |
| Remediation steps are specific and assigned to owners | ☐ |
| References (OWASP, MITRE, policy) are relevant and concise | ☐ |
| Retest status and dates are included or scheduled | ☐ |
| Final QA pass completed for clarity and consistency | ☐ |
12) Delivering the report and driving follow-through
A report delivered as an email attachment with no walkthrough gets read by one person, forwarded once, and stalls. The delivery is part of the deliverable.
One rule that saves relationships: leadership should never see a Critical finding for the first time in a document. Brief the security owner while testing is still running, so they can prepare their own stakeholders rather than being ambushed in writing. Nobody advocates for your findings if you have made them look uninformed.
Delivery sequence
- Internal QA review — check technical accuracy and writing quality
- Stakeholder pre-brief — walk leadership through the high-risk themes before they read the full report
- Report release with version tracking
- Remediation kickoff with an owner matrix so everyone knows their assignments
- Retest scheduling and closure tracking
What to deliver and to whom
| Artifact | Audience | Purpose |
|---|---|---|
| Executive risk summary | Leadership | Decision support and budget prioritisation |
| Technical findings report | Engineering and security teams | Detailed guidance for remediation work |
| Remediation tracker | Team leads | Ownership visibility and progress tracking |
| Retest addendum | All stakeholders | Proof that risk was actually reduced |
Length is not quality. The best report is the one whose findings get closed, and page count correlates with that outcome weakly at best — and negatively past a certain point.
Reporting operations worksheet
| Workstream | Owner | First action | How you know it is working |
|---|---|---|---|
| Template governance | Report lead | Enforce a single finding format across all engagements | Fewer inconsistencies between reports |
| Evidence QA | Technical reviewer | Validate reproducibility before every delivery | Fewer back-and-forth clarification loops |
| Remediation alignment | Engineering liaison | Map each finding to an owner, team, and control layer | Faster remediation start times |
| Retest closure | Security QA | Track closure states with proof references | More defensible closeout decisions |
Weekly reporting hygiene
- Review any open findings that still lack a clear owner or SLA
- Validate CVSS vectors for newly submitted high-impact issues
- Make sure business impact language stays specific and evidence-backed
- Confirm retest schedules for all critical findings
Delivery and handoff pack
| Artifact | What it must contain | Who uses it |
|---|---|---|
| Executive summary brief | Top risks, affected business functions, priorities | Leadership stakeholders |
| Technical remediation pack | Detailed findings with implementation-level actions | Engineering teams |
| Retest tracker | Status, dates, evidence, residual risk notes | Security governance |
| Lessons register | Common root causes and recurring control gaps | Security programme owners |
Final quality gut-checks
- Can each finding be acted on without a follow-up meeting to clarify it?
- Are remediation actions specific, scoped, and testable?
- Are closure decisions backed by clear retest evidence?
90-day reporting maturity plan
Days 1–30: Foundation
- Standardise templates and QA criteria across all report types
- Baseline your current report quality — track rework rates, closure delays, evidence gaps
- Tighten executive summary writing so it consistently lands with leadership
Days 31–60: Refinement
- Sharpen remediation language and improve owner mapping
- Reduce weak findings through peer review calibration
- Make retest packages more complete and self-contained
Days 61–90: Optimization
- Audit report quality against actual closure outcomes
- Publish recurring root-cause trends to inform the broader security programme
- Update your reporting playbook based on what you learned this cycle
| KPI | Why it matters |
|---|---|
| Findings requiring rewrite | Shows whether your reports are clear and well-structured |
| Remediation kickoff lead time | Reveals how quickly engineering can act on your output |
| Retest-backed closure ratio | Measures whether risk is actually being reduced, not just tracked |
| Recurring finding trends | Exposes systemic control issues that need programme-level attention |
One caution about that KPI table: remediation lead time and closure ratio are only partly yours to influence. A client with no engineering capacity will produce terrible numbers against a report you wrote well. Track the metrics you control — rewrite rate, clarification requests per finding — as your own quality signal, and treat closure outcomes as a conversation with the client rather than a scorecard for the report.
Report QA and acceptance criteria
Twenty minutes of QA removes most of what makes engineering teams distrust a report. The cost is that it has to happen when everyone is tired and the deadline is today, which is exactly why it needs to be a gate rather than a good intention.
Finding acceptance checklist
- The title describes the core issue, not just a symptom
- Scope context is clear: which component, environment, and role
- Evidence proves impact without exposing unnecessary sensitive data
- CVSS scoring matches the described impact and stated assumptions
- Remediation guidance is specific, testable, and prioritised
- Retest criteria define “fixed” in one sentence
Evidence map template
| Finding ID | Evidence artefacts | Where stored |
|---|---|---|
FND-01 | Request/response, screenshots, logs | 02-evidence/FND-01/ |
FND-02 | Configuration excerpts, scan output | 02-evidence/FND-02/ |
Executive summary standards
- Cover 3–5 top risks, each tied to a business impact and remediation theme
- Include one sentence on scope and any testing limitations
- If this is a retest, add a brief “what improved” section
Closing discipline
- Give engineering a remediation brief with priorities and quick wins highlighted
- Track remediation owners and due dates actively
- Close findings with before-and-after evidence from retesting
Consistent acceptance criteria, disciplined evidence handling and predictable closure are what separate a professional report from a document dump. None of it is difficult. All of it is work that happens after the interesting part of the engagement is over, which is precisely why so few reports get it right — and why the ones that do are remembered.
