Reporting and retest

Two readers, one report

A pentest report is read by two very different people. Your engineers need enough detail to reproduce and fix each issue. Your client’s or customer’s reviewer needs to know, in a minute, what was tested, what was found and what is now fixed. The report is structured for both: a short summary and scope record at the front, detailed findings in the middle and a verification ledger at the end. The sample report annotates why each section exists.

The evidence standard

Every finding is confirmed by hand. Automated tool output that could not be confirmed is not reported as a finding. Each finding records the asset, the account, role and tenant used, the request, the part of the response that proves the problem, and the condition that makes it a problem. Evidence is kept to the minimum needed, using synthetic data where possible.

Severity with a rationale

Severity combines impact and likelihood for your system, and each rating comes with a sentence or two explaining it. CVSS v4.0 vectors are included where the proposal asks for them and inform the rating, but they do not decide it. The same weakness can deserve different severities in different products, and the rationale lets your team challenge a rating constructively.

Remediation

Each finding has a specific fix: where the check belongs, what it should compare and which related endpoints are likely to share the flaw. Where one design change would close several findings, the report says so.

Readout

After the report is issued, we walk through it with the engineers who will fix the issues. Findings come first, background later. Questions about reproduction and priorities are answered here, and any disagreements about severity are discussed and recorded.

Retest and the verification ledger

When fixes are ready, we retest the original condition and the obvious variants, and confirm that legitimate access still works. Each finding’s status (verified fixed, fix pending or accepted risk) is recorded in the verification ledger with the date, and a new report version is issued. Retest rounds and timing are agreed in the proposal.

Sharing the report

Reports are written to be shared with clients, customers and auditors. Who receives the report, and in what form, is agreed before testing starts. A report is evidence of testing at a point in time; it is not a certification, and it does not claim that no other issues exist.