Defensible Audit Evidence: What Makes an Audit Trail Hold Up
defensible audit evidence · audit trail · tamper-evident records · Updated 2026-10-12
Audit evidence is defensible when a reviewer can trust it without re-doing the work: it was made when the work happened, it shows who did it, it cannot be quietly changed, nothing is missing, and it can be handed over in a form the reviewer can check. This page explains each property and gives a short test you can run on your own evidence.
Five properties of defensible audit evidence
- Captured at the source, at the time. The record is created by the system or process when the work happens: the access grant, the approved change, the closed alert. A screenshot taken the week before an audit shows the state on that day, not that the control ran all period.
- Attributable. Each record shows who or what acted, with a unique user or service ID and a timestamp. Shared accounts and unsigned spreadsheets break attribution.
- Tamper-evident. If a record were edited or deleted, it would show. Common ways to get there are hashing each record, chaining records in sequence, and storage that cannot be overwritten.
- Complete. The reviewer can see that nothing is missing: sequence numbers without gaps, a full population to sample from, and the exceptions recorded alongside the successes.
- Retrievable and scoped. The evidence can be found for any period you are asked about, and handed to the reviewer without giving them more access than they need.
Weak evidence and defensible evidence
| Control | Weak | Defensible |
|---|---|---|
| Access review | A spreadsheet, edited later, with no record of who signed off | The review exported from the identity system with reviewer, date, and the access removed as a result |
| Change approval | A screenshot of a merged pull request | The ticket, the review and the deployment record, linked by one change ID |
| Incident handling | A summary written after the incident closed | The alert, each action with its time and owner, and the closing decision, as they happened |
| Payment record | Transaction data rebuilt from several databases on request | A log from which any single payment can be reconstructed, with integrity data. See audit-ready payment logs |
How StackWeaver records it
In the StackWeaver platform each uploaded or collected file becomes an Evidence Object with a SHA-256 hash, review decisions are written to a per-workspace chained decision record that can be re-verified, and evidence can be exported as an evidence package a reviewer can check offline. The evidence lifecycle walkthrough follows one record from capture to sign-off.
A five-minute test
Pick one control and the last period it covered. Ask: was the record made at the time, by the system? Does it name who acted? Would an edit show? Can you show the full population, not only the good examples? Could a reviewer get it without broad access? Every "no" is a gap to close before someone else finds it. For the wider picture, see audit readiness for fintechs, and the continuous audit-preparation guide lists which trails to keep current.
If you want an outside view of where your evidence stands, our evidence readiness assessment is a five-day readiness review, not an audit.