The usual complaint about penetration test reports is not that they are wrong. It is that they cannot be acted on without a second conversation. A finding says “improper access control on the reporting endpoint”, a developer reads it, and the first thing they have to do is reconstruct what the tester actually did.
That reconstruction is where remediation time goes. Not in writing the fix.
What a finding looks like when it is re-runnable
Suppose a tester establishes that a low-privileged user can read another tenant’s export by changing an identifier. In an illustrative report, the finding would carry:
- The exact HTTP call, headers included, that produced the result.
- The account and role it was issued from, and what that role is supposed to be able to do.
- The confirming response, showing the data that came back.
- The re-run instruction: what to change to prove the fix, and what a fixed system should return instead.
The last item is the one that changes the working day. The developer does not need the tester to be available. They fix, they re-run the call, and they read the response. A 403 where a 200 used to be is not an opinion.
The loop it creates
- Finding is delivered with its reproduction call.
- Developer reproduces it locally, in minutes, without scheduling anyone.
- Fix is written against an observable failure, not a description of one.
- Developer re-runs the same call and sees the fix hold.
- Retest confirms it against the deployed environment, and the attestation records the change.
Every step in that loop is available to the customer without us in the room. That is deliberate. A finding you can only verify by asking the person who wrote it is a finding you are taking on trust.
Why we hold ourselves to it
Reproducible evidence cuts both ways. If a finding ships with the call that produced it, the customer can also demonstrate when we are wrong. We would rather be corrected against evidence than believed on authority.
