Pentest Evidence That Survives Peer Review

Pentest evidence survives peer review when another tester could reproduce the finding from it alone, weeks later, without asking you anything: the full request and response, the named identity that made it, a timestamp, and the facts that show what should have happened instead. Most evidence fails that test because it is captured under time pressure by somebody who already understands what they are looking at, and read later by somebody who does not.

That gap is where most evidence quietly fails, usually at the worst moment, which is when a client disputes a finding. It was sufficient to remind the tester what happened; it was never sufficient to prove it to anybody else.

The reproduction test

Before a finding leaves your hands, ask whether a colleague could reproduce it from the finding alone. Not from the finding plus a conversation with you, and not from the finding plus your memory of which account you were using.

If the answer is no, the finding is not finished. This single question catches more evidence problems than any checklist, because it forces the perspective of the reader rather than the writer.

Capture the exchange, not a picture of a browser

A screenshot of a rendered page shows that something appeared on a screen. It does not show what was requested, which account requested it, what the server actually returned, or whether the page was cached from a previous request.

• The full request, including the method, path, relevant headers and the body.
• The full response, or enough of it to establish the point, including the status line.
• Which identity made the request, by name, because "as a low privileged user" is not reproducible.
• A timestamp, because systems change and a finding without a date cannot be argued about later.

Screenshots still earn their place where the point is visual: a rendered payload, an interface exposing data it should not, a workflow that can be skipped. Use them for what only an image shows, alongside the exchange rather than instead of it.

State the system, not just the request

A request and response prove what happened. They do not prove what should have happened, and that is usually the finding. The reader needs the surrounding facts: which user owns the record you retrieved, what the application shows that user in the interface, what the role is supposed to permit.

For an authorisation finding this is the whole point, as testing authorisation properly sets out. "User B retrieved user A's order history" is a finding. The evidence has to establish that the orders belong to A, that B is a different account, and that B has no legitimate route to them, and none of that is visible in the response body alone.

Negative evidence is evidence

Showing that a control worked is worth capturing, and almost nobody does it. When the client later asks whether you tested something you found nothing on, the honest answer is much stronger with a record behind it.

It also protects the finding you did raise. If you demonstrate that the same request is correctly refused on nine endpoints and succeeds on the tenth, the tenth stops looking like a fluke and starts looking like what it is.

Redact at capture, not at review

Real records make the best evidence and the worst liability. A single capture can carry a customer name, address and payment detail into a document that will be forwarded well beyond the people who were in scope.

Do the redaction when you take the capture. Review time is deadline time, and a redaction pass planned for the end of the engagement is a redaction pass that gets shortened. Where the specific value matters to the finding, keep enough to make the point and remove the rest: the last four digits, a truncated identifier, the shape of the record rather than its contents. Handling evidence and client credentials safely covers how to flatten an image so the redaction holds.

What peer review should actually check

A reviewer reading for quality rather than for typos is asking a short list of questions, and it is worth making them explicit so the review is consistent between people and survives a busy month.

• Could I reproduce this without asking anybody?
• Does the evidence show the behaviour, or only the tester's conclusion about it?
• Is the identity that performed the action named?
• Does anything here need redacting before it leaves the building?
• Does the severity follow from what is shown, rather than from the title?

Custody, without the ceremony

Full chain of custody is a forensics discipline and most testing work does not need it. What testing work does need is enough that nobody can reasonably suggest the evidence was assembled after the fact.

Three habits get you most of the way. Capture at the time rather than reconstructing at write-up. Keep the raw capture alongside the tidied version that goes in the report. Store it somewhere with timestamps you did not set yourself.

The reconstruction habit is the dangerous one, and it is common under deadline: the tester remembers the behaviour clearly, re-runs the request on the last day, and captures it then. Usually that is harmless. Occasionally the system has changed, the capture no longer shows what was originally seen, and the finding now rests on a memory with a screenshot attached to it.

Evidence for something you could not exploit

Some of the most valuable findings are ones you could not carry to a conclusion: the deserialisation you identified but could not weaponise inside the window, the credential you found but were not authorised to use, the path that clearly exists but ends in a system outside scope.

These need different evidence and much more careful language. Show what you established, state plainly what you did not attempt and why, and do not let the severity imply a demonstration that did not happen. "Exploitable" and "we did not have time to demonstrate exploitation" are different claims and a report should never blur them.

Done well, this is a strength. A client can tell the difference between a firm that reports only what it finished and one that tells them where it ran out of road, and the second is the one they trust when the next report says something is fine.