What you actually receive
A report is the entire product of a penetration test. It is worth knowing what one looks like before you buy — particularly since the industry norm is a scanner export with a cover page. This is our structure, with a worked finding written exactly as it would appear in yours.
This is a constructed specimen
Every detail below is fictional. The target, findings, evidence and identifiers were written for this page. We do not publish client reports, redacted or otherwise, and we would not show yours to anyone either. It is presented to demonstrate structure and writing standard, nothing more.
How the document is organised
Two audiences read a pentest report and they need different things. Rather than compromising for both, the document separates them cleanly.
Executive summary
Two to three pages, no jargon, readable by a board or a customer's procurement team. What was tested, what the overall posture looks like, the themes behind the findings, and what we would prioritise. A risk rating that reflects exploitability and business impact — not a count of issues.
Scope and limitations
Precisely what was in scope, what was excluded and why, the testing window, and anything that constrained coverage — a WAF in blocking mode, an environment that differed from production, credentials that arrived late. Stating limitations is what makes the rest of the report trustworthy.
Findings
One entry per issue, ordered by severity. Each carries a CVSS vector, affected components, reproduction steps a developer can follow, evidence, business impact in your context, and specific remediation.
Attack narrative
Where findings chain, we describe the path end to end — how three medium-severity issues combined into account takeover. This is usually the section that changes how an organisation prioritises, because individual severities rarely convey what the combination enables.
Remediation plan
Findings grouped into a sequence, separating quick configuration fixes from work needing a sprint. Where several findings share a root cause, that is called out so you fix the cause once rather than the symptoms repeatedly.
Retest addendum
Issued after remediation. Each original finding marked verified fixed, partially addressed or still present, with fresh evidence. This is typically the document your assessor cares most about.
A finding, written out in full
Fictional target, real format. This is the level of detail every finding receives.
Engagement summary
Specimen- Client
- Northgate Retail Ltd (fictional)
- Target
- checkout.example-northgate.co.uk
- Type
- Web application, grey box
- Roles
- Guest, Customer, Merchant admin
- Window
- 04–14 March 2026
- Driver
- PCI-DSS v4.0 requirement 11.4.3
- Report ref
- LS-2026-0142
Findings index
7 issuesBroken object-level authorisation in order retrieval API
- CVSS v3.1
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N — 9.1 Critical
- Affected
- GET /api/v2/orders/{orderId}
- Category
- OWASP API1:2023 — Broken Object Level Authorisation
- Status
- Verified fixed at retest, 27 March 2026
Summary
The order retrieval endpoint authenticates the requesting user but does not verify that the requested order belongs to them. Any authenticated customer can read any order in the platform by changing a single numeric identifier, exposing full name, delivery address, email address, telephone number, order contents and the last four digits of the payment card.
Business impact
Order identifiers are sequential, so the entire order history is enumerable by a single script running from any registered account. At the observed rate limit an attacker could retrieve approximately 180,000 order records in twenty-four hours. This is a personal data breach under UK GDPR Article 4(12), engaging the Article 33 notification duty, and directly contravenes PCI-DSS requirement 7.2 on need-to-know access.
Because registration is open and requires only email confirmation, the barrier to exploitation is creating an account — no prior compromise is needed.
Reproduction
- Register a customer account and place one order. Note the returned orderId (observed: 48213).
- Authenticate and capture the session bearer token.
- Issue GET /api/v2/orders/48212 with that unmodified token.
- The response returns HTTP 200 with the full record of an order belonging to a different customer.
- Decrementing the identifier returns further records belonging to unrelated accounts, confirming the absence of any ownership check.
Evidence in the delivered report: full request and response pairs, a screen recording of the enumeration, and a redacted extract demonstrating records from three unrelated accounts. Personal data captured during testing was limited to what evidences the issue and destroyed on delivery.
Remediation
Enforce an ownership check server-side in the order retrieval handler: resolve the order, compare its customerId against the authenticated principal, and return 404 rather than 403 where they differ, so the endpoint does not confirm which identifiers exist.
The same pattern appears across the order, invoice and returns controllers, all of which derive identity from the request path rather than the session. We recommend a shared authorisation filter applied at the controller layer instead of per-handler checks, which are easy to omit on new endpoints. Sequential identifiers should be replaced with UUIDs as defence in depth — but note this is a hardening measure, not a fix. The authorisation check is the fix.
Root cause: findings LS-01, LS-02 and LS-04 all stem from authorisation being enforced in client-side routing rather than server-side. Addressing that pattern resolves three findings at once, and is the single highest-value change available from this engagement.
How it is delivered
- PDF — the primary deliverable, encrypted in transit, suitable for auditors and customer due diligence.
- Findings export — CSV or JSON so issues drop straight into Jira, ServiceNow or your tracker without retyping.
- Executive summary — extractable as a standalone document for board or customer circulation.
- Debrief call — a walkthrough with the tester who did the work, so your engineers can ask questions directly.
- Retest addendum — issued after fixes are verified, referencing the original findings.
Placeholder — downloadable specimen PDF
Not yet produced. A downloadable specimen report is the single strongest asset this page could carry, and prospects will look for one. It needs to be generated as a real PDF from a fictional engagement before launch. Flagging it rather than linking a file that does not exist.
See this standard applied to your systems
Take a free verified finding on one scoped target — written up to exactly the standard shown above, at no cost and with no obligation.