Having a policy proves intent. It doesn’t prove behaviour.
This distinction matters more than almost anything else in compliance, because confusing the two creates the most common failure pattern in audit evidence.
A policy documents what should happen. Evidence shows what did happen. They serve completely different purposes, and one cannot substitute for the other.
Understanding this difference explains why organisations can have comprehensive documentation and still struggle to demonstrate compliance.
What policies actually prove
When you show someone your information security policy, your data retention policy, or your incident response procedure, you’re proving that you’ve thought about the issue. You’ve documented an approach. You’ve stated an intent.
This is valuable. It shows governance. It demonstrates that someone has considered what good practice looks like and written it down.
But it doesn’t prove that anyone follows the policy. It doesn’t show that the procedure gets used. It doesn’t demonstrate that the control operates in practice.
A policy is a statement about how things ought to work. Evidence is a record of how things actually worked.
The policy-evidence gap in practice
This gap appears in every audit and every compliance review, usually in the same pattern.
“Do you encrypt data at rest?” “Yes, we have a policy requiring encryption for all sensitive data.”
“Can you show me that encryption is actually enabled?” Pause. “I’ll need to check with IT.”
Or:
“How do you handle data breach notifications?” “We have a breach response procedure that covers notification timelines.”
“When was the last time you used it?” “We haven’t had a breach recently.”
“When did you last test it?” Silence.
The policy exists. It might even be a good policy. But there’s no evidence that it operates in reality. No trail showing that encryption gets configured correctly. No record of the breach procedure being tested or practised.
Why policies feel like evidence
The reason organisations often offer policies as proof of compliance is that policies are easy to produce. They exist in a clear, finished form. You can share them, reference them, point to them.
Evidence is messier. It’s distributed across systems and time. It requires showing specific instances of activity, particular decisions, concrete outcomes.
It’s much simpler to say “here’s our vendor risk assessment policy” than to show three recent examples of vendor assessments, complete with the decisions made, the risks identified, and the approvals obtained.
But simplicity isn’t the same as sufficiency. When someone is assessing your compliance programme, they need to know whether your controls work, not just whether you’ve documented them.
What evidence actually looks like
Evidence of a control operating has a different character from the policy that describes it.
Take access reviews as an example.
The policy might say: “User access permissions will be reviewed quarterly by system owners. Access that is no longer required will be removed within 5 business days.”
That’s the intent. It’s clear, it’s measurable, it’s appropriate.
Evidence that this policy is operating would include:
- Records showing when reviews happened (12 March, 14 June, 11 September)
- Who conducted each review (Alice for Finance systems, Bob for HR systems)
- What they found (15 accounts reviewed, 3 required changes, 1 was a former employee still with access)
- What actions were taken (access removed on 13 March, 16 June, 12 September)
- Who approved the changes (finance director signed off on removals)
This is proving compliance. Not stating intention, but demonstrating operation. Not documenting what should happen, but showing what did happen.
The evidence is specific, timestamped, attributed, and connected to actual activity.
The documentary evidence trap
One particularly common variant of the policy-evidence confusion is treating all documents as evidence.
An organisation might produce:
- A data protection policy
- A data retention schedule
- A list of data processing activities
- Templates for privacy notices
- Training materials on data handling
These are all useful documents. They show that the organisation has thought about data protection. But none of them is evidence that data protection controls operate.
Evidence would be:
- Records of data deletion runs showing that retention schedules are enforced
- Completed data processing records for current activities
- Training completion records showing who completed what training when
- Incident logs showing how data breaches or near-misses were handled
- Subject access request logs showing that requests are being processed within legal timeframes
The documents explain the framework. The evidence proves the activity.
When policies become evidence
There is one situation where a policy itself can serve as audit evidence: when you need to prove that a policy exists.
If a compliance requirement says “you must have a documented incident response procedure”, then having the documented procedure is evidence of meeting that requirement.
But even then, the policy only proves one thing: that the document exists. It doesn’t prove anything about whether the procedure works, whether anyone knows about it, or whether it gets used.
Most compliance requirements go beyond “you must have a policy.” They require “you must have a process that operates effectively.” And that requires operational evidence, not documentary evidence.
The difference this makes
Understanding the difference between policies and evidence changes how you approach compliance work.
Instead of: “We need to create a vendor assessment policy” You ask: “What process will ensure we actually assess vendors, and what trail will that process create?”
Instead of: “We need to document our backup procedure” You ask: “How will we prove that backups run successfully and that we test restoration?”
Instead of: “We need an access review policy” You ask: “How will we record who reviews access, what they find, and what they change?”
This shift moves compliance from being document-focused to being activity-focused. The question isn’t what you can write down, but what you can show actually happens.
This is what evidence-based compliance means. Not more documentation, but better capture of operational reality.
What happens when evidence is missing
When an organisation can show policies but not evidence, several problems emerge.
First, auditors lose confidence. A gap between documented intent and provable operation suggests that controls might not be working. Even if they are working, the inability to prove it raises questions.
Second, decision-making suffers. If you can’t prove that access reviews happen consistently, you don’t actually know whether your access controls are effective. If you can’t show evidence of vendor assessments, you don’t know whether your third-party risk is being managed.
Third, compliance becomes stressful. Every audit or review becomes an exercise in trying to reconstruct what happened from fragments and memory, rather than simply retrieving evidence that accumulated naturally.
The structure evidence needs
For evidence to serve its purpose, it needs particular characteristics that policies don’t naturally have:
Specific – Not “we review risks annually” but “we reviewed risks on 15 January, here’s the assessment, here are the changes from last year’s assessment.”
Timestamped – Not “we train people regularly” but “23 employees completed training between March and May, here are the completion dates.”
Connected – Not “here’s a risk register” but “here’s the risk register, here’s when it was last updated, here’s the decision meeting where these risks were discussed, here’s the action log showing what we’re doing about the high risks.”
Policies can’t provide this level of specificity because they’re generic by design. They describe how things should work in general. Evidence shows how things worked in particular instances.
Making evidence accumulate naturally
The practical implication of all this is that compliance programmes need to focus less on creating better policies and more on ensuring that policies translate into activities that create evidence.
When you implement a new security control, the question isn’t just “what should we do?” but “how will we know we did it, and how will we prove it to someone else?”
When you roll out a new process, ask not just “is this documented?” but “what evidence will this process create, and how will we retrieve it when we need it?”
This doesn’t mean creating evidence as a separate activity. It means ensuring that when operational work happens, it naturally creates a retrievable record.
When someone completes a risk assessment in a proper risk management system, the evidence is the assessment itself. When someone reviews and approves a policy in a document management system, the evidence is the version history and approval log. When someone completes training in a structured training system, the evidence is the completion record.
The work creates the evidence. You don’t need to document the work separately.
What to do with existing policies
If you have comprehensive policies but limited evidence, the solution isn’t to throw away the policies. They serve a purpose. They guide behaviour, set expectations, establish standards.
But you do need to build the capability to prove that those policies translate into action.
For each policy, ask:
What activity does this policy describe? When that activity happens, what record gets created? How would someone find that record six months later? What would credible evidence of this control look like?
The goal isn’t documentation. It’s operational proof.
The real test
The real test of whether you have compliance evidence isn’t whether you have policies. It’s whether you can answer specific questions about specific instances of activity.
Not “do you have a change management process?” but “show me the last three system changes, including who requested them, who approved them, and what testing was done.”
Not “do you assess vendors?” but “show me the assessment you did for your last new supplier, including the security review, the contract terms, and the risk acceptance decision.”
Not “do you train employees on data protection?” but “show me training completion records for your current staff, including who completed what and when.”
If you can answer these questions quickly and confidently, you have evidence. If you need to hunt through email and reconstruct what happened, you have policies but not evidence.
This is why evidence needs to be thought about as a trail — not as a collection of documents. Policies explain intent. Evidence proves behaviour. They’re both necessary, but they’re not interchangeable.
