Penetration Testing Report Example
The report is the deliverable that actually matters. Two tests can find the same issues, but the one with a clear, well-structured report is the one your engineers can fix from, your auditors can accept, and your board can understand. A good report translates raw technical findings into prioritised, defensible business risk.
This page breaks down exactly what a professional penetration testing report should contain, section by section, and includes an annotated illustrative finding — complete with a CVSS v3.1 score, CWE reference, sanitised proof-of-concept, and remediation — so you can see how a single issue is documented end to end. Use it as a template to benchmark the reports you receive.
What a Penetration Testing Report Should Contain
A professional report follows a consistent structure so every reader — executive, engineer, or auditor — can find what they need. These are the sections you should expect, in the order they typically appear.
1. Executive Summary
A business-readable overview written for leadership, not engineers. It states the overall risk rating, summarises the most important findings in plain language, and explains what they mean for the organisation. A good executive summary lets a non-technical stakeholder understand the security posture in a single page without reading any of the technical detail that follows.
2. Scope & Rules of Engagement
Defines exactly what was tested — the in-scope applications, IP ranges, accounts, and environments — and, just as importantly, what was excluded. It records the testing window, the authorisation, the type of test (black, grey, or white box), and any constraints. This section makes the report defensible: it shows precisely what the conclusions cover and what they do not.
3. Methodology
States the recognised standards the engagement followed so the work is repeatable and credible — for example the OWASP Web Security Testing Guide (WSTG), PTES, MITRE ATT&CK, and NIST SP 800-115. It describes the phases (reconnaissance, mapping, exploitation, post-exploitation) and the balance of manual testing versus automated tooling, so the reader can judge how thorough the assessment was.
4. Findings
The core of the report. Each finding is documented consistently with a title, severity, CVSS v3.1 score and vector, the relevant CWE identifier, the affected assets, a clear description, reproducible evidence or proof-of-concept, the business impact, and specific remediation. Findings are ordered by risk so the reader sees what matters most first.
5. Risk Rating Methodology
Explains how severity was decided so ratings are consistent and transparent. It documents the CVSS v3.1 base metrics used and how likelihood and impact were weighed against the business context — a critical-CVSS issue on an internet-facing system carries more urgency than the same issue behind several layers of compensating controls.
6. Remediation Roadmap
Turns the findings into an actionable, prioritised plan. Issues are grouped and sequenced — quick wins, short-term fixes, and longer-term hardening — so the team knows what to fix first and why. A good roadmap is realistic about effort and dependencies, not just a restatement of the findings list.
7. Retest Results
After the client remediates, the tester re-examines the affected areas and records whether each finding is closed, partially fixed, or still open. This section provides independent confirmation that fixes actually worked — the evidence auditors, customers, and boards look for before they accept that risk has been reduced.
8. Appendices
Supporting material that backs up the body of the report: the tools used, raw scanner output, full request and response logs, host and port inventories, and any custom scripts. Appendices keep the main report readable while preserving the detailed evidence a technical reviewer or auditor may want to inspect.
An Annotated Sample Finding
Here is what a single finding looks like in a professional report. The example below is illustrative — a realistic but fictional issue created to show structure, not a real client vulnerability — and it demonstrates the fields every finding should carry.
Insecure Direct Object Reference (IDOR) in Account API
Illustrative example — fictional data
CVSS v3.1 Score
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weakness (CWE)
CWE-639: Authorization Bypass Through User-Controlled Key
Affected Asset
GET /api/v1/accounts/{accountId} (api.example-corp.com)
Description
The Account API resolves the requested account from the accountId path parameter without verifying that the authenticated session is authorised to access it. Any authenticated user can read another tenant's account record by incrementing or substituting the accountId value, exposing personal and financial data belonging to other customers.
Evidence / Proof-of-Concept
Authenticated as user A (own account 10472), the tester requested a different tenant's account and received it in full:
# Request (session belongs to account 10472)
GET /api/v1/accounts/10473 HTTP/1.1
Host: api.example-corp.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
# Response — another tenant's data is returned
HTTP/1.1 200 OK
Content-Type: application/json
{
"accountId": 10473,
"owner": "Acme Holdings Ltd",
"email": "[email protected]",
"balance": 482190.55,
"currency": "AED"
}Business Impact
A low-privileged authenticated attacker can enumerate and exfiltrate the full account dataset across every tenant — names, contact details, balances, and statement history. This is a direct confidentiality and integrity breach with regulatory (PDPL / GDPR) and reputational consequences, and it requires only a valid account and a script.
Remediation
Enforce server-side object-level authorisation on every request: confirm the authenticated principal owns or is explicitly entitled to the requested accountId before returning data. Replace sequential integer identifiers with unguessable UUIDs as defence-in-depth, and add automated authorisation tests to the CI pipeline to prevent regressions.
What Separates a Good Report From a Bad One
The structure above is necessary but not sufficient. The difference between a report you can act on and one that gathers dust comes down to a handful of qualities.
Manual validation, not a scanner dump
A bad report is a raw export from an automated scanner — pages of CVE IDs with no triage, no false-positive removal, and no human judgement. A good report shows that a tester manually validated each issue, removed the noise, and chained findings to demonstrate real impact.
Proof-of-concept and evidence
Every serious finding should be reproducible. A good report includes sanitised requests, responses, screenshots, or step-by-step proof-of-concept so your engineers can confirm the issue themselves rather than take the tester's word for it.
Business context, not just technical detail
A finding rated 'High' means little without context. A good report explains what an attacker actually achieves — data exposed, accounts taken over, money moved — so leadership can prioritise on impact, not just on a CVSS number.
Actionable, specific remediation
Generic advice like 'apply input validation' is not enough. A good report gives concrete, technology-specific guidance an engineer can implement, and points at the exact code path, configuration, or control that needs to change.
A retest to confirm the fix
A report that ends at the findings list leaves you guessing whether your fixes worked. A complete engagement includes a retest that independently verifies remediation and updates each finding's status.
How OraSec Reports Are Structured
Our reports follow the structure described on this page, and they are built to serve two audiences at once. The executive summary gives leadership and auditors a clear, business-readable view of risk and posture, while the technical body gives engineers the reproducible detail they need to fix each issue — proof-of-concept evidence, affected code paths, and specific remediation.
Every finding carries a CVSS v3.1 score and vector, a CWE identifier, and risk rated on likelihood and business impact rather than a raw scanner severity. Where you need it, findings are mapped to the compliance frameworks your auditors consume — PCI DSS, SOC 2, ISO 27001, or HIPAA — so the report can be used as evidence directly instead of requiring a translation pass from your team.
And because a finding is not closed until it is verified, every engagement includes a retest: we re-examine the remediated areas and update each finding's status in the report. That is the difference between a document and genuine, defensible assurance.
In every OraSec report
- An executive summary written for leadership and a separate technical body for engineers
- Every finding carrying a CVSS v3.1 score and vector, a CWE identifier, and reproducible evidence
- Risk rated on CVSS plus likelihood and business impact, not a raw scanner severity
- A prioritised remediation roadmap your team can work straight from
- Findings mapped to compliance frameworks (PCI DSS, SOC 2, ISO 27001, HIPAA) where relevant
- A free retest after remediation, with each finding's status updated in the report
Penetration Testing Report FAQs
What does a penetration testing report include?+
A complete penetration testing report includes an executive summary, the scope and rules of engagement, the methodology followed (such as OWASP WSTG, PTES, MITRE ATT&CK, and NIST), a detailed findings section, a risk rating methodology, a prioritised remediation roadmap, retest results, and supporting appendices. Each finding should carry a title, severity, CVSS v3.1 score and vector, the relevant CWE identifier, affected assets, a description, proof-of-concept evidence, the business impact, and clear remediation guidance. The combination of a business-readable summary and a reproducible technical body is what makes a report usable by both leadership and engineers.
What is a good CVSS score and how is severity rated?+
CVSS (Common Vulnerability Scoring System) v3.1 produces a base score from 0.0 to 10.0, mapped to severity bands: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). A 'good' score is a low one — lower means less severe. The score is derived from a vector string describing attack vector, complexity, privileges required, user interaction, scope, and the confidentiality, integrity, and availability impact. A quality report does not stop at the CVSS number, though: it combines that base score with the likelihood of exploitation and the real business impact in your environment, so a finding is prioritised on actual risk rather than the raw metric alone.
Can I see a sample penetration test report?+
Yes. This page walks through the full structure of a professional report and includes an annotated illustrative finding so you can see how a single issue is documented end to end — from CVSS and CWE through to evidence and remediation. For a complete, sanitised sample report tailored to the type of engagement you are considering, request one through our contact page and we will share a representative example.
Who reads the penetration testing report?+
A good report serves two distinct audiences. Executives, board members, and auditors read the executive summary and risk ratings to understand posture and make decisions about budget and acceptance of risk. Engineers, developers, and security teams read the detailed findings, proof-of-concept evidence, and remediation guidance to actually fix the issues. Compliance and GRC teams use the framework mappings to satisfy requirements such as PCI DSS, SOC 2, ISO 27001, or HIPAA. A well-structured report keeps these audiences served without forcing any of them to wade through detail they do not need.
Do you provide a retest after remediation?+
Yes. A retest is part of a complete OraSec engagement, not an optional extra. After you remediate the findings, we re-examine the affected areas and record whether each issue is closed, partially fixed, or still open, then update the report accordingly. This gives you — and your auditors, customers, and board — independent confirmation that the fixes actually worked, which a one-off test with no verification can never provide.
Request a Sample Report
Want to see a complete, sanitised report for the type of engagement you're considering? Tell us what you need tested and we'll share a representative example and a scoped plan — typically within one business day.