The claim
A specific, checkable statement: access to production data requires approval; the deployment can be rolled back; the primary user journey meets the agreed accessibility standard.
Working structure
Release evidence index.
Most audit pain is not caused by weak controls. It is caused by evidence that was never captured at the moment it existed, and has to be reconstructed months later from memory, screenshots, and chat history.
An evidence index fixes the cheaper problem: deciding in advance what each release must prove, and where that proof will live.
Build your briefFORMATMarkdown template
CAPTUREDPer release
BOUNDARYEngineering, not certification
01 / WHAT GETS INDEXED
One row per claim the release makes.
The index is deliberately narrow. It records claims and their proof, not intentions.
The artifact
The thing that demonstrates the claim — a passing pipeline stage, a decision record, a test report, a configuration export, a review sign-off. Named, not described.
The owner
A person, not a team. Owners answer questions about their artifact during review, so ambiguous ownership is treated as a gap.
The location
Where the artifact is stored and how long it is retained. Evidence that cannot be retrieved on request does not count as evidence.
The generation point
The moment in delivery when the artifact is produced. Evidence generated by the pipeline is cheap and trustworthy; evidence generated by a person at quarter-end is neither.
The review date
When the claim is re-checked. Controls decay quietly, and an index without review dates becomes stale within two quarters.
02 / WHEN IT HELPS
Useful when evidence is the bottleneck.
- Enterprise procurement asks security and control questions your team answers inconsistently.
- Audit preparation currently means reconstructing screenshots and logs after the fact.
- A regulated workflow needs technical controls and a reviewable trail.
- Control ownership is split across product, engineering, security, and operations.
- You want evidence produced by delivery rather than alongside it.
- Independent certification, attestation, or an audit opinion.
- Legal advice on jurisdiction, lawful basis, or regulatory applicability.
- An authorised penetration test or specialist safety validation.
- Organisational policy outside the agreed product scope.
Sample working structure
Take the index.
The Markdown file carries the columns and prompts described above. It is a template and contains no customer evidence or certification claim.
03 / QUESTIONS
Evidence questions.
What is a release evidence index?
It is a per-release record of what the release claims to be true, the artifact that demonstrates each claim, the owner of that artifact, and where it is stored. It converts audit preparation from an archaeology exercise into a lookup.
Does an evidence index make an organisation compliant?
No. It makes delivery evidence traceable within an agreed scope. Certification, attestation, and audit opinions are issued by qualified independent assessors, and legal applicability is determined by the accountable organisation and its advisors.
Which frameworks does this structure suit?
The structure is framework-neutral. It has been shaped by the evidence expectations common to SOC 2, ISO 27001, GDPR, HIPAA, and WCAG work, but applicability must be confirmed per product and jurisdiction.
Can this be added to a product that already shipped?
Yes, though retrofitting is more expensive than generating evidence from the start, because historic claims have to be re-established rather than simply recorded.
Next decision
Make the next release provable.
Decide what it has to demonstrate before the work starts.