A penetration test is only as useful as the document you receive afterwards. Boards skim the summary. Engineers need reproduction steps. Auditors want scope, dates and methodology. Underwriters often ask for evidence that independent testing happened and that serious issues were tracked. If any of those audiences cannot use the report, you paid for paperwork.
This checklist is for buyers who need to judge report quality before they sign a statement of work, and again when the PDF arrives.
Buyer checklist
- Plain-language executive summary with severity counts and overall posture
- Exact scope, exclusions, dates, environments and credentials used
- Named methodology (for example OWASP WSTG, PTES, NIST SP 800-115) and limitations
- Findings register ordered by risk, each with evidence and reproduction steps
- Transparent severity method (typically CVSS with context)
- Remediation guidance your team can prioritise; not a promise that the tester will fix your estate
- Optional retest path and how residual risk is recorded
1. Executive summary written for decision makers
The first one to two pages should answer: what was tested, when, how serious is the picture, and what should leadership do next.
Look for:
- Scope in business language (not only IP lists)
- Finding counts by severity
- Two or three themes (for example "remote access authentication" or "object-level authorisation on the API")
- Clear statement of residual risk and testing limitations
Red flag: an executive summary that is only a paste of CVE titles, or that claims the organisation is "secure" because no criticals were found in a tiny scope.
2. Scope, rules of engagement and limitations
A usable report states:
- In-scope assets (URLs, APIs, IP ranges, cloud accounts, user roles)
- Explicit exclusions
- Environment (production, staging, or both) and known parity gaps
- Testing window and any change freezes
- Authentication model (black box, grey box, white box) and accounts provided
- Constraints (no denial-of-service, no phishing, rate limits)
Without this section, neither an auditor nor your future self can interpret the findings. A clean bill of health on half an application is not the same as a clean bill of health on the product.
3. Methodology and tools in proportion
Buyers should see which industry approaches guided the work (OWASP Web Security Testing Guide for web applications, OWASP API Security Top 10 for APIs, PTES or similar for infrastructure, and so on). Tool names matter less than whether manual validation happened.
Red flag: a report that reads like raw scanner export with a cover page. Automated findings without human confirmation waste remediation time.
4. Findings register: the core of the report
Each finding should stand alone so an engineer who was not on the kick-off call can verify it. A strong finding typically includes:
| Element | Why it matters |
|---|---|
| Specific title | "Unauthenticated access to invoice PDF by ID" beats "IDOR" |
| Severity label | Critical / High / Medium / Low / Informational |
| Scoring detail | CVSS v3.1 or v4.0 vector (or equivalent) plus business context |
| Affected assets | Exact host, URL, parameter, role or object ID pattern |
| Description | What is wrong, in clear English |
| Steps to reproduce | Numbered, deterministic |
| Evidence | Requests/responses, screenshots, or other proof |
| Impact | What an attacker gains in business terms |
| References | CWE, OWASP category, vendor advisory where useful |
| Remediation guidance | Specific enough to act on; owned by your team |
Attack Vector reports identify security weaknesses and give remediation guidance so clients can prioritise fixes. The report is not a remediation-as-a-service contract. Your engineers, vendors or managed service partners implement changes; a retest can then confirm whether the weakness still reproduces.
5. Severity that you can defend internally
Severity inflation trains organisations to ignore reports. Ask how ratings are decided. CVSS base scores are a common anchor; environmental context (internet-facing versus internal-only, presence of compensating controls, sensitivity of data) should be explained when ratings are adjusted.
A medium issue on an internet-facing authentication flow may outrank a high CVSS finding on an isolated lab VLAN. The report should help you see that difference.
6. Attack narrative or chaining (when relevant)
Individual tickets are necessary. A short narrative that shows how findings combine into a realistic path (for example phishing foothold to privilege escalation to data access) helps leadership understand urgency. Not every small scope needs a novel-length kill chain; larger infrastructure and red-team-style engagements almost always benefit from one.
7. Remediation roadmap and retest
Useful extras:
- Grouped recommendations (identity, patching, configuration, design)
- Suggested priority order without inventing your internal owners for you
- How to request a retest window
- How informational items differ from exploitable weaknesses
If a compliance regime such as PCI DSS requires correction and retesting of exploitable issues, the commercial proposal should say whether retest days are included or quoted separately.
8. Appendices buyers actually use
Common useful appendices: raw tool output summaries, host lists, certificate details, user accounts tested, timeline of testing activity. Avoid stuffing the main body with noise that belongs in an appendix.
What any report cannot prove
- A report describes a point in time. Deployments the next week can reopen risk.
- Scope exclusions are not "passed"; they are untested.
- Screenshots prove what was observed under the stated conditions; they are not a guarantee against every variant of the same class of bug.
- No reputable firm should claim that delivering a report means they have remediated your systems. Identification and clear guidance are the tester's job; prioritisation and fixing sit with the organisation.
When you compare quotes, ask each supplier for a sanitised sample report and score it against this checklist. Attack Vector can share a sanitised sample report on request. Price without report quality is a false saving.
For indicative UK pricing and scope planning, use the instant quote calculator or email [email protected]. Engagements start from £1,500 for a small, well-defined job. Credentials and approach are summarised on the About page.
FAQ
Should every finding include a CVSS score?
It is good practice for technical findings. Informational observations may not need a full vector. What matters is consistency and transparency so your team can prioritise.
How detailed should reproduction steps be?
Detailed enough that a competent engineer can reproduce the issue without calling the tester for every click. Exact URLs, parameters, roles and preconditions belong in the write-up.
Is a shorter report worse?
Not necessarily. Clarity beats page count. A short report with solid evidence on a small scope is better than a long scanner dump on a vague scope.
Do we need an attack narrative?
For simple single-host tests, a narrative may be thin. For internal network, cloud identity or multi-role application work, chaining helps decision makers.
What if critical findings are still open at renewal?
Document remediation status honestly for auditors and insurers. A report plus a tracked remediation plan is usually stronger than hiding open issues. Retest when fixes land.
Can we share the full report with customers?
Many organisations issue a summary letter or redacted extract under NDA. Agree handling in the statement of work so sensitive evidence is not forwarded casually.
Suggested Resources
Ready to strengthen your security?
Talk to our consultants about your penetration testing requirements, or get a fast, transparent quote.