Earthshaker Security Book a scan

← All field notes

Field note 30 September 2026 · 15 min read

Security Teams: Copy Ready Penetration Testing Report Templates

Copy ready penetration testing report templates and an annotated sample for security teams. Reproducible finding fields, CVSS prioritization, and a...

Security Teams: Copy Ready Penetration Testing Report Templates

Security report template title card

A penetration testing report is the evidence-and-remediation document that turns a security assessment into fixed vulnerabilities. It must serve three audiences at once: executives who need business impact, technical teams who need reproducible evidence, and auditors who need a defensible record. At minimum it needs an executive summary, scope and rules of engagement, a findings summary, detailed findings, remediation and retest status, and appendices.

TL;DR:

  • The executive summary must clearly highlight the most critical finding, such as a bypass or high-risk vulnerability, over less significant issues.
  • The scope section must explicitly list tested assets, exclusions, and testing constraints, serving as a clear contract to prevent scope misunderstandings.
  • The findings summary should prioritize and color-code issues by severity, affected system, and remediation status to facilitate quick triage by technical teams.
  • Detailed finding records need reproducible steps, specific fix guidance, and evidence cropping to avoid confusion, with each record answered with what is wrong, how to see it, and how to fix it.
  • Remediation workflows must assign clear owners and target dates, and updates such as retest artifacts are essential to prevent vulnerabilities from remaining open indefinitely.

Table of Contents

Executive summary template for business stakeholders

The executive summary is the only section most decision makers will read, so it has to stand on its own. OWASP recommends separating this section entirely from the technical material that follows, writing it so a nontechnical reader understands the organization's security posture without opening a single findings table.

A working executive summary has three parts. First, a short posture statement: what was tested, what was found in plain terms, and whether the overall risk is high, moderate, or low. Second, a snapshot of findings by severity so leadership can see the shape of the problem at a glance. Third, a prioritized list of next steps, ranked by business risk rather than by the order findings happened to be discovered.

A penetration test report's core value is its evidence-and-remediation structure, as OWASP's reporting guidance describes it: a report that stops at detection without connecting findings to fixes has not done its job.

Keep the posture statement honest. If the engagement found a critical authentication bypass alongside a dozen low-severity header misconfigurations, the summary should lead with the bypass, not with a finding count that makes the report look busier than it is. Executives read this section once, often in a meeting, so the sentence order matters as much as the content.

Scope, objectives, and rules of engagement

Before anyone reads a single finding, the report has to establish exactly what was tested, how, and under what constraints. NIST SP 800-115 treats this documentation as a planning artifact, not an afterthought: the guide includes templates for rules of engagement and recommends recording scope, assumptions, and logistics clearly enough that nobody later mistakes an untested area for a secure one.

This section should read like a contract, because in practice it functions as one when disputes arise about what was or was not covered.

A report that skips the limitations line invites the wrong conclusion: that a clean result means the whole application is safe, when it may only mean the tested paths were safe during the tested window.

Findings summary for fast triage

Between the executive narrative and the deep technical detail sits a section that most reports underuse: a findings summary built for triage. Engineers need to know which findings to open first, and managers need to see workload before it turns into a sprint backlog. The right format is compact, sortable, and free of prose.

Format severity counts by category, not just by number: a critical in payment processing carries different urgency than a critical in an internal admin tool nobody uses. Group affected assets logically, by application, subdomain, or API, so a team that owns one service can find its slice without reading the whole report. CVSS scores and vector strings belong in this summary when the audience is technical enough to use them for triage, alongside the base rating; save the full metric breakdown for the detailed finding record.

Findings summaries work best as a compact table rather than paragraphs, following the structure OWASP's WSTG reporting guidance lays out: identifier, severity, affected asset, and status in one row per finding, with everything else pushed to the detailed record.

A status column that never gets updated after delivery is worse than no status column at all. Treat the findings summary as a living document during remediation, not a snapshot frozen at delivery.

Detailed finding record template

This is the section engineers actually work from, and it lives or dies on reproducibility. A finding that cannot be reproduced from the report alone forces a round trip back to the tester, which slows remediation and erodes trust in the whole document. OWASP's WSTG reporting guidance lays out the practical fields a finding record needs: identifier, severity, affected asset, description, reproducible steps or request and response evidence, screenshots or commands, remediation, references, and retest status.

Here is a field-by-field template built from that structure, written so a team can copy it directly into a report or ticketing system.

  1. Finding ID: a short, stable identifier (for example, WEB-014) used consistently across the report, the retest, and any ticket created in the client's tracker.
  2. Title: a specific, descriptive name, such as "Broken Object-Level Authorization on /api/v1/invoices/{id}" rather than a vague label like "Access control issue."
  3. Affected asset: the exact URL, endpoint, parameter, or component, not just the application name.
  4. Classification: the relevant CWE number and, where applicable, the OWASP Top 10 category the finding maps to.
  5. Technical description: a plain explanation of the flaw, written so a developer unfamiliar with the specific test can understand the mechanism without reading the proof of concept first.
  6. Prerequisites: what an attacker needs to exploit the issue: a valid account, network position, a specific role, or nothing at all.
  7. Reproduction steps: a numbered sequence precise enough that a second engineer can follow it and get the same result, including exact requests, parameters, and payloads used.
  8. Supporting evidence: screenshots, request and response captures, or command output that proves the finding, cleaned of unrelated session data.
  9. Impact analysis: both the technical consequence (data exposure, privilege escalation, remote code execution) and the business consequence (customer data at risk, regulatory exposure, service disruption).
  10. CVSS score and vector string: the numeric score alongside the full vector so anyone can verify how the score was derived.
  11. Remediation guidance: a specific fix, not a general instruction: "Add a server-side ownership check on the invoice ID before returning the resource" rather than "Improve access control."
  12. References: links to the relevant CWE entry, OWASP guidance, or vendor advisory that supports the finding.
  13. Retest status and date: open, remediated, or verified closed, with the date of the last check.

A finding written this way answers three questions in order: what is wrong, how do I see it myself, and what do I change to fix it. Skip any of those and the finding becomes a conversation instead of a document.

The description and the reproduction steps are the two fields teams get wrong most often, usually by merging them. A description that includes step-by-step commands buries the "why" under the "how," and a developer skimming for context has to read the whole proof of concept just to understand what the vulnerability actually is. Separate them cleanly: the description explains the mechanism in two or three sentences, and the reproduction steps are a numbered sequence that assumes no context beyond the finding title.

Evidence deserves the same discipline. A screenshot of a full browser window with ten open tabs and a visible session cookie is not evidence, it is a liability. Crop screenshots to the relevant response body or UI element, and redact tokens, cookies, and personal data before they go anywhere near the report. Earthshaker's methodology applies this same discipline: every automated finding gets manually verified before it reaches the report, and verification artifacts are cleaned before inclusion, which is part of why the reports read as a working document rather than a raw scanner export.

Illustration of cropped and redacted security evidence

Impact analysis is where technical and business framing genuinely need to coexist in the same field, not in two disconnected sentences. "Remote code execution on the checkout service" is technical; "an attacker could execute arbitrary code on the server that processes customer payments" is the same fact translated into something a CFO understands without a glossary. Write both in the same short paragraph.

Pro Tip: Write the remediation field before you write the reproduction steps. If you cannot describe a concrete fix in one sentence, the finding probably needs more investigation before it goes in the report.

References matter more than they get credit for. A finding tied to CWE-639 (Authorization Bypass Through User-Controlled Key) gives the engineering team a search term that connects to broader guidance beyond the single instance you found, and it gives auditors a standard classification to check the finding against.

Turning CVSS scores into remediation priority

A severity rating is only useful if it changes what gets fixed first, and that is where a lot of reports fall short. CVSS v4.0 organizes scoring into Base, Threat, Environmental, and Supplemental metric groups, with the vector string recording exactly which metric values were chosen so anyone can verify the score. Every finding record should show the score and the full vector string together, never the number alone.

The Base score alone is not enough to prioritize a remediation backlog. FIRST's CVSS guidance is explicit that a numeric Base score should not be treated as the sole prioritization mechanism: Threat and Environmental context change what a score means in a specific environment. A 9.0 Base score on a system with no internet exposure and strong compensating controls may warrant a lower practical priority than a 7.5 on a customer-facing login page.

Environmental and threat context can shift where a finding lands in the remediation queue, according to FIRST's CVSS v4.0 documentation, which is why the report should explain asset criticality and exploit availability in plain language next to the score, not leave the reader to infer it.

Remediation workflow from assignment to verified closure

A finding that sits at "open" for months is a report that failed at its actual job. The remediation section should give engineering teams a process, not just a list of problems.

  1. Categorize the fix: label each finding as a quick fix (config change, patch), a recommended fix (code change, architectural adjustment), or a temporary mitigation (compensating control while a permanent fix is scheduled).
  2. Assign an owner and a target date: every finding needs a name attached, not just a team, and a date that gets tracked alongside other engineering work.
  3. Collect retest artifacts: before requesting a retest, gather the same evidence types the original finding used, updated to show the fix in place.
  4. Verify against a checklist: confirm the fix addresses the root cause, not just the specific proof of concept that was demonstrated.
  5. Update status and close: mark the finding verified closed only after an independent retest confirms it, with the date recorded in the finding record.

Communication matters as much as the technical steps. Set an expectation for retest turnaround at the start of the engagement rather than negotiating it after remediation is already underway, and keep the client updated when a fix category shifts, for instance when a "quick fix" turns out to require a schema change.

Appendices and safe evidence handling

Appendices carry the material that supports the findings without cluttering them: methodology notes, severity rating definitions, cleaned tool output, and any checklists used during testing. OWASP's reporting guidance is direct about the risk here: a report is not complete just because it includes raw scanner output, and full unfiltered dumps belong nowhere near the main findings.

Pro Tip: Run every screenshot and log excerpt through a second pass specifically looking for auth headers and cookies before the report goes out. Most leaks happen in appendices, not in the main findings.

What a filled-in sample report looks like

An annotated example makes the templates concrete faster than any description does. A typical exec-summary snippet reads: "Testing identified one critical finding (broken authorization on the invoicing API) and four medium findings related to session handling. We recommend addressing the critical finding before the next release." Notice there is no jargon and no CVSS number in that sentence, both belong further down.

A filled detailed finding for that same issue would carry the ID, the exact endpoint, a CWE-639 mapping, reproduction steps showing the request with a swapped invoice ID, a CVSS vector, and a remediation line specifying a server-side ownership check.

A sample report built on this structure is available online, useful as a working reference when adapting the templates above to a specific engagement.

Classifying and distributing the finished report

A penetration testing report is sensitive evidence, and it should be treated that way from the cover page onward. OWASP recommends securing and encrypting these documents, since they effectively contain a map of an organization's weaknesses alongside real credentials and session data captured during testing.

Retention policy deserves a line too: agree upfront on how long the report and its raw evidence are kept before secure deletion.

Why Earthshaker builds reports this way

Automated scanners are fast and noisy in roughly equal measure, and the biggest mistake we see when findings get handed to engineering teams is a report that reads like a scanner export: hundreds of low-confidence items with no verification and no prioritization attached. Manual verification is what turns a list of possibilities into a list of confirmed problems worth an engineer's time.

The other common failure is a finding record missing the one field that actually matters to the person fixing it: a concrete remediation step instead of a category name. We keep every finding tied to a specific fix and a retest date, because a report that cannot be acted on immediately tends to stay open indefinitely.

— caleb

Get a professionally verified penetration test report

Earthshaker Security runs web application penetration tests, API and endpoint testing, external attack surface reviews, and configuration and hardening audits, each one combining automated scanning with hand-verification so the report you get only contains confirmed findings, not raw scanner noise.

Earthshaker Security

Every engagement delivers the structure covered above: an executive summary written for nontechnical stakeholders, detailed findings with reproduction steps and remediation guidance, and a retest to confirm closure. You speak directly with the tester who did the work, not a sales contact.

Engagement pricing details are available on the pricing page. Check current availability and share your application's scope to get started.

Sources

FAQ

What is a penetration test report?

A penetration test report is the document that records what was tested, what vulnerabilities were confirmed, and how to fix them. It typically includes an executive summary, scope and rules of engagement, detailed technical findings with evidence, and remediation guidance with retest status, following the structure OWASP's reporting guidance recommends.

What are the stages of a penetration test?

Definitions vary slightly by framework, but a common structure follows planning and scoping, reconnaissance, exploitation, and reporting, with NIST SP 800-115 treating planning and rules of engagement as a distinct phase before testing begins. Reporting is the final stage, where confirmed findings are documented with evidence and remediation steps.

Can you provide an example of a penetration test report?

A filled example typically pairs a plain-language executive summary, such as a one-line posture statement, with a detailed finding record showing the finding ID, affected endpoint, reproduction steps, CVSS vector, and a specific remediation step. Earthshaker Security publishes a sample report built on this structure for reference.

What is a CVE report?

A CVE report documents a publicly cataloged vulnerability with an assigned identifier, separate from a penetration test report, which documents what was actually found in a specific environment during a specific engagement. Many pentest findings, such as authorization flaws or business logic errors, never have a CVE because they are unique to the tested application rather than a shared software product.

Recommended

Next
Want this run against your app?
Book a scan