The report is the part of a penetration test that stays with you after the testers leave. Reading it well means fixing the right things first and getting real value from the retest. It also helps you spot a "pentest" that was really an automated scan with a cover page.
What a good report contains
The OWASP Web Security Testing Guide describes a report structure that makes a useful benchmark. Each part serves a different reader, and the guide suggests that sections can be printed separately for the teams that need them.
| Section | Main reader | What to check |
|---|---|---|
| Executive summary | Management | One page in plain language - what is wrong and how to fix it |
| Test parameters | Everyone | Objective, scope, schedule, targets and limitations |
| Findings summary | IT and security leads | Every finding with its severity in one table |
| Remediation summary | IT and security leads | Grouped actions, not only a list of issues |
| Detailed findings | Engineers | Evidence, impact, reproduction steps and a fix for each issue |
| Appendix | Engineers and auditors | Tools used and any custom scripts |
Read the limitations section carefully. If account lockouts stopped testing, or a server was taken out of scope on day two, the report should say so. A clean result for an area that was never tested tells you nothing.
The UK National Cyber Security Centre (NCSC) adds two items that are easy to overlook. A good report gives the testers' opinion of how accurate your own vulnerability assessment was, and advice on how to improve that process.
Anatomy of a good finding
Each finding should let an engineer who was not involved in the project understand the issue, reproduce it and fix it. Look for:
- a unique ID and a clear title
- a severity rating, with the CVSS vector when CVSS is used
- the exact affected assets, such as hosts, URLs, parameters or roles
- a description of the weakness and why it matters to your business
- evidence, such as requests and responses, screenshots or command output
- steps to reproduce
- specific remediation advice, with references such as a vendor advisory
Here is a condensed example of what that looks like in practice:
ID AF-07 Invoice download does not check ownership
Severity Medium CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (6.5)
Affected GET /api/v1/invoices/{id}/pdf on portal.example.eu
Evidence Logged in as customer A, a request for invoice 10452
(customer B) returned customer B's PDF.
Impact Any customer can download other customers' invoices,
including names, addresses and amounts.
Fix Check on the server that the invoice belongs to the
logged-in customer for every request.
Retest Request another customer's invoice and expect 403 or 404.The vector lets you see why this scores Medium: confidentiality is affected, integrity and availability are not. It also lets you disagree with good reason. Because the invoices contain personal data, you might decide this deserves a higher priority than the score suggests.
How findings are rated
Many reports rate findings with the Common Vulnerability Scoring System (CVSS) maintained by FIRST, and the NCSC lists it among the rating schemes you can ask for. CVSS v3.1 and v4.0 use the same qualitative bands:
| Rating | CVSS score |
|---|---|
| None | 0.0 |
| Low | 0.1 - 3.9 |
| Medium | 4.0 - 6.9 |
| High | 7.0 - 8.9 |
| Critical | 9.0 - 10.0 |
Three points help when you read these ratings:
- A base score measures severity, not your risk. FIRST describes it as reflecting the vulnerability's intrinsic characteristics under a reasonable worst case. It says consumers should supplement it with information about their own environment.
- Severity is an input. The OWASP guide recommends that the executive summary states this explicitly: the rating feeds your risk management process rather than replacing it.
- Testers lack business context. The NCSC advises you to assess findings yourself, because ratings can be too high or too low. It also warns against using this as a way to play issues down.
What to fix first
- Anything exploitable from the internet without logging in, especially where it leads to code execution, data access or administrative control.
- Attack chains. A good report shows how several lower-rated findings combine into a serious one. NIST SP 800-115 notes that scanners cannot detect weaknesses that only appear when vulnerabilities are combined. Finding these chains is much of what a human tester adds.
- Systems that hold the keys, such as identity providers, backup servers, remote access gateways and anything handling personal data.
- Quick wins. One configuration change can sometimes close several findings at once.
- Root causes. NIST recommends root cause analysis after an assessment, because results can point to weak processes as well as weak systems. Five missing patches on five servers is one finding about patch management, not five unrelated problems.
The NCSC frames a penetration test as a check on your own vulnerability management, not the main way to find vulnerabilities. In its words, new discoveries "should be the exception, not the rule". If the report surprises you, that tells you something about your internal processes too.
Retesting
Agree the retest when you sign the contract, including what it covers and how long you have to fix things first. Ask for the results as an updated report or an annex, with a status against each finding: fixed, partly fixed, not fixed, or risk accepted.
A retest confirms specific fixes. It is not a new test. The NCSC points out that a test only shows the state of your systems on the day it ran, and that a year or more between tests is common. Keep checking in between.
Red flags in a cheap "pentest"
Automated scanning has its place, and NIST SP 800-115 covers it as one of the standard assessment techniques. It also notes that scanners can have a high false positive rate and need someone with the right expertise to interpret them. The problem starts when unreviewed scan output is sold as a penetration test. Warning signs include:
- findings with generic, copied text and no evidence that anyone confirmed them
- dozens of low-impact items about banners and TLS ciphers, but nothing on access control, authentication or business logic, which need a human to test
- severities taken straight from the tool; NIST says assessors should set the risk level themselves instead of accepting scanner ratings
- no scope, methodology or limitations section
- no reproduction steps, so your team cannot verify a fix
- no named testers or stated qualifications; the NCSC says testing should be done only by qualified and experienced staff
- a "retest" that is simply the same scan run again
Where to start
Before your next test, ask the provider:
- What exactly is in scope, and what is excluded?
- Will testers have accounts for each user role you want covered?
- Can you see an anonymised sample report?
- How are findings rated, and will each one include a CVSS vector?
- Is a retest included, and within what time window?
If you are planning a test and want to talk through scope first, see our penetration testing service.
