Evidence Decays: Why 'We Do X' Doesn't Survive the Audit

TL;DR

A control is a claim about what your organization does. Claims decay. The document you wrote in year one stops describing reality in year two, and nothing you do in between tells the auditor that. The failure is not missing evidence — it’s stale evidence: the artifact is real, it was true once, and it no longer is. Keep evidence current by tying it to a change event, not a calendar, and by making the artifact generate itself from the process rather than being hand-maintained.

The distinction that matters

There are two things people conflate, and the conflation is where audits fail.

The control is the mechanism. “We review access rights quarterly.” “We encrypt data at rest.” “We require MFA on administrative systems.” It is a property of how the system behaves right now.

The evidence is the artifact that proves the mechanism ran. The completed access review. The encryption configuration export. The MFA enforcement policy from the identity provider.

The control is live. The evidence is a snapshot. And a snapshot, by nature, goes quiet.

Most ISMS documentation is structured around the snapshot. Someone writes a procedure, someone runs the control, someone files the output, and the folder closes. Then six months later a new hire changes the process, a tool upgrade changes the configuration, or a team splits in two — and the artifact in the folder is still there, still legible, still “the evidence.” It just no longer describes what happens today.

The auditor finds a genuine document. The document is genuine. And the control it was supposed to prove is gone.

Why “we do X” fails

“We do X” is a present-tense claim about a recurring behavior. The only way to verify it is to observe the behavior in the recent past, under current conditions. But the evidence model in most organizations is one-shot:

Build the control.
Produce the artifact.
File it.
Repeat, maybe, next year.

Steps 2 and 4 assume the world between them hasn’t changed. It always has. The identity provider got upgraded. The access-review tool was replaced. The team that ran the review left. The configuration that matched the artifact drifted. None of those events generated a new artifact, because nothing in the process was watching for them.

So the evidence folder contains one good artifact and a long silence. The silence is the problem. A good artifact with no updates is not the same as a current artifact.

The failure modes

The decay shows up in predictable shapes:

The one-time export. “Here is the encryption config from when we deployed the new storage platform.” Fine in 2024. In 2026 the platform is on a new version, the config was changed during a migration, and the export is a historical record, not a current one.
The orphaned procedure. “Here is our access review procedure.” It’s well written. Nobody runs it anymore, or they run it and file nothing, and the last completed review is three years old.
The stale training record. “Employees complete security awareness annually.” The LMS was replaced. The completion records migrated. Now “the evidence” is a PDF of last year’s export, and this year’s completion is in a system nobody exports from.
The un-mapped change. A change request approved a new cloud region. The data-residency control document never got updated to name that region. The control still works — the new region is encrypted and access-controlled — but the document doesn’t say so, and the auditor sees a gap they can’t rule out.

The common thread: the control may still be intact. The proof that it is intact has gone stale. And in an audit, or an incident review, you are graded on the proof, not on your memory of what the system does.

The fix: evidence that regenerates itself

The durable pattern is to make the evidence a byproduct of the process rather than a task attached to it. If the artifact is generated the moment the control runs, it is current by construction — you don’t have to remember to update it.

Access reviews generate their own record. The access-review tool produces a dated, signed, exported result every cycle. The artifact is the output of the run, not a document about the run.
Configuration drift is the trigger. The encryption configuration is pulled from the identity platform or the storage layer on demand, not transcribed. “What is encrypted” is a query, not a paragraph.
The control is owned by the process, not the document. The procedure describes the intent; the system that executes it owns the record of execution. When the procedure changes, the process changes, and the next run produces evidence that reflects the change.

This is the same discipline as detection: build on what the system does, not on what you wrote about it. The artifact is the trace, and the trace has a timestamp and a source.

The change-event trigger

Calendar-based re-verification (“review the evidence every 12 months”) catches decay only at the next tick, and it treats every control as equally volatile. A better trigger is the change event.

When one of these happens, the affected evidence goes stale immediately and must be regenerated before it is relied on again:

A tool or platform is replaced or materially upgraded.
The process owner or responsible team changes.
A configuration relevant to the control changes.
A new system, region, or data flow enters the scope of the control.
An incident or near-miss touches the control.

The control document doesn’t need a calendar reminder. It needs a dependency list: the set of changes that, if they occur, invalidate its evidence. That list is short, it’s explicit, and it turns “is this still true?” from a vague question into a checkable one.

Why the auditor (or the incident) catches you

The reason stale evidence is so costly is that the two moments you most need current proof are the two moments the world has just changed:

The audit. You’re showing the folder. The auditor samples the most recent artifact. It’s from a cycle that’s already been superseded. You have to explain the gap, and now you’re reconstructing from memory whether the control is actually live.
The incident. You’re demonstrating that a control that should have prevented the breach was in place. The evidence is a year old. The question stops being “did the control exist?” and becomes “did the control exist at the time?” — and you can’t answer it from a stale artifact.

Both situations reward the organization whose evidence regenerates: the proof is current because it’s the live output, not a relic.

Trade-offs

Making evidence self-generating costs setup. You need the process to be instrumented — the tool that produces the artifact, the query that pulls the config, the ownership that knows which changes matter. For a small team, that’s real work, and it can feel heavier than writing a document once.

But the alternative is worse over time: hand-maintained evidence has a maintenance cost that compounds, because every change silently invalidates it and you’re never notified. The one-time setup of self-generating evidence is paid once; the compounding staleness of hand-maintained evidence is paid every year, forever, and it’s paid at the worst possible moment.

The honest trade-off: front-load the instrumentation, and you stop paying the compounding tax.

The takeaway

A control is a claim, and claims decay. Don’t build your ISMS on the assumption that a document from year one still describes year two. Tie evidence to the process so it regenerates when the process runs, and tie evidence to the change events that invalidate it so it regenerates when the world shifts. The goal is not more documents. It’s evidence that is current by construction, so that when the auditor asks — or the incident forces you to prove it — the artifact in front of you is the one that’s true today.