Evidence demonstrates that a requirement is met or a control is effective. In audit language it stands opposite the audit criterion: the criterion is the requirement being tested against, the evidence is the verifiable information about how matters actually stand. Verifiable means a second person would reach the same conclusion. An assertion without support is therefore not evidence.
Types of audit evidence and their limits
| Type | Example | Limit |
|---|---|---|
| Document | policy, procedure, contract | shows the intent, not the practice |
| Record | approval, ticket, log, training attendance | shows a single transaction |
| System export | entitlement listing, patch status, configuration report | shows a state as at the moment of export |
| Observation | walkthrough, demonstration of a procedure | shows the moment of the audit |
| Statement | interview with a role holder | the weakest form; needs corroboration by other evidence |
| Third-party evidence | a certificate or assurance report from a provider | valid only within that provider's scope and reporting period |
Management system standards group documents and records together as documented information; ISO/IEC 27001 governs its control in clause 7.5: creation and updating, approval, availability to those who need it, and protection against loss or unauthorised change. The distinction that matters more in practice stays simpler: a document says how work is supposed to be done, a record says how it was done.
What makes a piece of evidence hold up
Evidence carries weight when six things are settled. It is worth keeping them as a fixed field set per item of evidence: a gap then surfaces when the evidence is filed, not in the audit.
| Field | Question it answers |
|---|---|
| Source | Which system or function did it come from? |
| Date of creation | When was it produced? |
| Period of validity | For what period does its statement hold? |
| Trigger for renewal | What makes it invalid: a deadline, a change, an event? |
| Object referred to | Which system, application, provider or process does it say something about? |
| Owner | Who produces it and stands behind its accuracy? |
If one of these is missing, an examination cannot establish what the assertion of compliance actually rests on.
Why evidence expires
Evidence describes a state, and states change abruptly: a system is rolled out, a rule is opened up for a migration, a provider changes subcontractor, a role is filled by someone new. Any of those events can devalue a statement that was correct when it was gathered. An entitlement listing exported in spring says nothing about the autumn.
Some evidence is rightly tied to a date because it evidences an event: a training session, a penetration test, a continuity exercise, a management review. What separates that from expired evidence is not its age but whether the expiry date is known and monitored, or only surfaces when somebody asks. Time pressure makes the difference visible: reporting duties with deadlines measured in hours leave no room to assemble a body of evidence after the fact. What continuous evidence means in practice, and why the asset makes a sturdier anchor for it than the document, is explained in compliance evidence that does not go stale.
Evidence and effectiveness
Evidence that exists demonstrates existence, and at first nothing more. Adequacy asks whether a control is suitable to address the risk; effectiveness asks whether it actually bites in operation. Documents are not enough for effectiveness. It shows in records covering a period, in samples that come back clean, and in metrics that move the way they were expected to.
Findings auditors raise most often
- Evidence with no date, no source system or no discernible period of validity.
- Screenshots that cannot be reproduced because the filter, the point in time and the system context are missing.
- Evidence attached to a clause of a framework rather than to the object it makes a statement about.
- Provider certificates whose scope does not cover the service actually bought.
- A collection that looks complete but consists entirely of documents.
Why where it is filed decides how much it is worth
Evidence does not become weaker for sitting in a folder, but it becomes harder to attribute. In an audit the question is not whether a screenshot exists, but which system it evidences, for what point in time, and who confirmed it.
In Rizzqo that attribution does not have to be reconstructed afterwards, because the evidence hangs on the requirement on the object concerned, together with the answer and its reasoning. Attached files are held as non-public on the server side. The finalisation is where the statement becomes binding: it is recorded under a name and a timestamp, and until then the requirement still counts as a gap, even when already marked fulfilled. That strictness is why computed coverage and the audit result do not drift apart.