Reporting findings and driving remediation

A finding that nobody understands or acts on has no value. The best testers write so that an executive sees the risk and an engineer can fix it in an afternoon.

CVSS calculatorDradis / PlexTrac / SerpicoMarkdown and PDF toolingissue trackersretest checklistOWASP risk rating methodology

Structure of a report

Executive summary: for non-technical readers. What was tested, the overall risk in plain language, the few things that matter most and what to do first.
Scope and method: what was in and out of scope, the dates, the approach and any limitations (what you could not test).
Findings: one entry each, ordered by severity, with a unique id.
Strategic recommendations: patterns behind the findings (for example, no central authorization layer) and how to fix the cause, not just the instances.
Appendices: evidence, tool output and the methodology details.

A good finding

Each finding should stand on its own and be reproducible by someone who was not there.

finding-template.mdmarkdown

## F-01  Broken object-level authorization on /api/invoices/{id}

**Severity:** High (CVSS v3.1 8.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
**Affected:** https://api.example.com/v2/invoices/{id}
**Category:** OWASP API Security: Broken Object Level Authorization

### Summary
Any authenticated user can read and modify any customer's invoices by changing the id.

### Impact
An attacker with a free account can read all customers' billing data and alter invoice totals. Affects every customer.

### Steps to reproduce
1. Log in as tester-a and note an invoice id (1041).
2. Log in as tester-b and send `GET /api/invoices/1041`.
3. The response is 200 with tester-a's invoice.

### Evidence
evidence/F-01-request.txt, evidence/F-01-response.txt

### Remediation
Authorize on the server by ownership for every request (scope the query by the authenticated user). Return the same 404 for "not found" and "not yours". Add a regression test with two users.

### References
OWASP Top 10 A01 Broken Access Control

Rating risk

gives a consistent technical score, but it ignores your context. Adjust severity by real exploitability, the value of the data and systems affected, whether controls compensate, and whether the issue is already being exploited. Explain the reasoning in the report so that the client can prioritize, instead of copying the scanner's number.

After the report

Walk the client's engineers through the critical findings; a conversation resolves doubts faster than a document.
Agree on owners and dates, and track fixes in the client's own issue tracker.
Retest: verify each fix actually closes the issue and report the result. Fixes that only block the exact test case are common.
Handle the data: deliver the report securely, and delete or return client data as agreed.
Feed lessons back: recurring root causes should become design guidance, tests and training.

CVSScommon vulnerability scoring systemA score from 0 to 10 that measures the technical severity of a vulnerability: how it is exploited (network or local, complexity, required privilege, user interaction) and what the impact is. 9.0+ is critical, but the number is theoretical: it does not know whether you are exposed.see in glossary →

connections on the map

Penetration testing methodologyends withReporting findings and driving remediation
Red team, purple team and adversary emulationis summarized inReporting findings and driving remediation
Attack paths and privilege escalationis reported inReporting findings and driving remediation

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

SASTappseca well-written finding becomes a rule and a test in the pipeline

Study before

Penetration testing methodology

test what you learned

Loading questions…