From Policy to Evidence: Closing the Gap That Costs the Most

There is a specific moment in most readiness programmes when progress appears to stop. The policies are written. The folder looks impressive. And yet nothing feels ready.

Nothing has gone wrong. The programme has simply reached the boundary of what documentation can achieve.

Three states, not one

We find it useful to think of every requirement as passing through three states.

Defined. Something written says what should happen. A policy, a procedure, a standard.

Operating. The thing described actually happens, across the whole scope, whether or not a particular person remembers.

Demonstrable. A record exists showing that it happened, dated and attributable, retrievable without a search operation.

A policy moves a requirement into the first state only. It says nothing about the second and nothing at all about the third. The distance between "defined" and "demonstrable" is where readiness programmes spend most of their real effort — and where the ones that skip it discover the cost late.

This three-state framing is ISAREADY methodology, not a framework requirement. We use it because it makes an otherwise vague problem assignable.

Why documentation feels like more progress than it is

Writing a policy is bounded, visible and satisfying. You can finish it on a Thursday.

Making a policy operate is unbounded, invisible and involves persuading people in other departments to change what they do. It never finishes on a Thursday.

So programmes front-load the documentation, feel productive, and then stall at exactly the point where the difficult work begins. A useful counter-measure is to refuse to mark any policy complete until it has an owner, a review date, a communication record, and a named record that will demonstrate it operating.

From defined to operating

Four things move a requirement from written to working.

An owner with capacity. Not just a name in a document, but someone whose workload was actually adjusted.

A trigger. What causes the activity to happen? A calendar entry, a stage in an existing process, a ticket queue. Activities that depend on someone remembering are activities that stop when that person is on leave.

A definition of done. What state ends the activity? "Reviewed access" is ambiguous. "Every account on the three in-scope systems confirmed against the current role list, with changes made" is not.

Somewhere it lands. If the activity produces an output that has no home, it will not survive contact with a busy quarter.

From operating to demonstrable

This is the shorter step and the more commonly skipped.

For each operating activity, decide three things before it runs: what record demonstrates it, who produces that record, and where it lives. Then check the record has the three properties that make it usable — dated, attributable, retrievable.

The cost asymmetry here is stark. Deciding these things in advance costs a few minutes per activity. Reconstructing them afterwards costs days, and produces weaker evidence.

A worked example. "Access rights are reviewed quarterly" as a policy line is defined. Add a calendar trigger, a named reviewer, a list of in-scope systems and a definition of what a completed review means, and it is operating. Add a one-page review record — date, reviewer, systems checked, accounts changed, sign-off — produced as part of the review rather than afterwards, and it is demonstrable. Same activity, three very different positions.

The test that settles arguments

Pick a control. Ask for representative, current evidence. Time it.

This test resolves most internal disagreements about readiness faster than any discussion, because it converts an opinion into an observation. We run the demanding version — twelve months, within one working day — as an ISAREADY benchmark rather than because any framework asks for it. It also has a useful side effect: it identifies which activities depend on one person, since those are the ones where the answer begins "I'll need to ask…".

What this changes about how you plan

If evidence is a property of how an activity is performed rather than a separate workstream, then evidence design belongs at the start of implementation, not at the end of the programme.

Practically, that means the evidence map — activity, record, owner, location — is built during the gap assessment, not after it. Every finding closes with a named record. Every new process ships with its record defined.

It is a small procedural change with a disproportionate effect on the final month.

The free readiness checklist pairs each activity with the record that would normally demonstrate it, which is a reasonable starting point for building your own map. Our evidence management guide covers the structure in more depth.