Guideline: Evidence That Holds Up
The difference between a governance record and a governance document, and how to write records that survive being read by someone who does not believe you.
The failure this prevents
Governance programmes produce documents easily and evidence rarely. The difference matters at exactly one moment — when an outcome has gone wrong and somebody external is reconstructing what was known, decided and checked — and by then the difference cannot be retrofitted.
The failure is not dishonesty. It is records written to satisfy a gate rather than to answer a future question, controls recorded with nothing they emit, and summaries maintained by hand until they quietly contradict their sources.
[Practice recommendation] Everything on this page is advice from this documentation rather than a requirement of IRGF. Disagreeing with it does not put you outside the framework; all practice recommendations are collected in Appendix B.
Three grades of evidence, and where each is acceptable
Not everything must be machine-generated. But the grade must be recorded, because a reader cannot otherwise tell what they are looking at.
| Grade | What it is | Acceptable for |
|---|---|---|
| Observed | Emitted by the system as a by-product of operating: logs, comparison output, test results, IAM exports, index build manifests. | Any tier. The only grade that is cheap to produce continuously and hard to produce falsely. |
| Attested | A named person states that something was done or checked, with the date and what they examined. | Any tier, where observation is impractical. At Tier 3–4 an attestation must say what was examined, not only that it was. |
| Asserted | A claim in a document with no observation and no named attester — “controls are in place”, “the model is monitored”. | Tier 1 at most, and even there it is a placeholder for evidence you have not built yet. |
The practical test for a control: what does it emit? A control that emits nothing cannot be assured, which means it cannot be relied on at a gate, which means recording it as a mitigation is misleading. Either give it an output or delete it.
Writing records that answer future questions
- Write the version, always. A decision taken on version 3 of an assurance summary is not a decision about version 5. Unversioned references are the most common defect in gate records.
- Record what was not done. Scope statements that omit exclusions are the ones that fail under scrutiny. “We did not evaluate X because Y” is strong; silence about X is not.
- Name people, not functions. “Risk” did not approve anything.
- Date everything, including the criteria. Pass criteria dated after the test run are results.
- Preserve, do not overwrite. Scores, boundaries and authorizations are re-issued. The previous version is the evidence that the process operated.
- Write for a reader who is not on your side. Not defensively — plainly. The sentence you would be uncomfortable seeing quoted is the sentence to fix now.
The rule that keeps evidence true
One authoritative owner and one location per primary record; every derived view compiled by reference and never re-entered. This is the non-duplication rule, and it is the difference between governance data that stays accurate and governance data that is confidently wrong.
The AI System Card is the standing example. It is the summary everyone wants — tier, owner, architecture, controls, authorization, open changes, assurance status — and every field already exists in another record. Maintained by hand, it drifts within weeks, and because it looks authoritative nobody checks it against the source. If you cannot compile it, do not create it.
Retention and retrievability are different things
Retention is a policy question answered by the longest applicable obligation. Retrievability is an engineering question nobody tests: can the evidence be produced, in readable form, after the platform that created it has been replaced?
Test one retrieval per year on a system that has already been retired. It is a two-hour exercise that reliably finds something — an export in a proprietary format, a link to a decommissioned wiki, an archive nobody has credentials for.
When you cannot produce the evidence
Sometimes the evidence genuinely cannot be obtained: a vendor will not disclose, a legacy system emits nothing, a control lives in someone's judgement. The framework's answer is not to pretend. It is to cap the tier at which the system may operate, or to record an explicit acceptance with a named accepter and a date, and to put the gap in the exception register with an expiry.
An acceptance that is recorded is governance. The same acceptance left unrecorded is the finding that appears in someone else's report.
How to tell it is working
Every practice needs a failure signal, or it is a belief. These are the ones that show this guideline has stopped operating in your organization.
| Signal | What it means | What to do |
|---|---|---|
| Gate records cite documents without versions | Decisions cannot be tied to the evidence they were taken on | Add versions to the minute template; it is a five-minute fix with disproportionate value |
| A derived view is maintained by hand | Your single-pane summary is drifting from its sources right now | Compile it or delete it; there is no third option that stays true |
| Controls appear in the matrix with no evidence column | Those controls cannot be assured and should not be relied on | Give each an output or remove it, and re-check the residual risk |
| Nobody can retrieve evidence from a retired system | Retention was implemented, retrievability was not | Run the annual retrieval test and fix the format before the next retirement |
| Scope statements never say what was excluded | Records are being written to pass gates, not to answer questions | Require the exclusions section first in assurance summaries |