What Good Resilience Evidence Looks Like

Good resilience evidence is a record that lets a stranger reconstruct what happened, what was decided, and what changed as a result, without needing to take the author's word for it. It names the service it concerns, carries a date and an owner, and shows its working: the map it relies on, the tolerance it is judged against, the test or incident it records, and the outcome in plain terms. If a record cannot answer those points, it may be a useful note, but it is not yet evidence.

The simplest test is to hand the record to someone who was not involved and ask what they can conclude from it alone. Can they tell which service was affected, which dependency mattered, and whether the result was within tolerance? Can they see who decided what, and what follow-up was agreed? If the answer depends on background knowledge held only by the author, the record needs more context before it can support assurance to an auditor, a supervisor, or a board.

Specificity comes first. A record about resilience in general proves very little, while a record about one service, one dependency, or one test proves something checkable. The service should be named in the same terms used in its map and tolerance, so that records can be joined up without guesswork. Vague labels, shifting service names, and summaries that blend several services together all weaken the trail, even when each underlying fact is true.

Weak evidence often looks impressive at first glance. It is long, well formatted, and full of confident language, but it floats free of any particular service. It may state that testing takes place, without saying which service was tested, what scenario was used, or what failed. It may list controls without showing whether they operated when they were needed. It may quote a tolerance without showing a single occasion on which performance was measured against it.

Another weak pattern is evidence that only ever reports success. A testing programme that never finds a fault, an incident record that never identifies a delay, and an audit trail with no follow-up actions all invite scepticism, not because failure is expected, but because a genuine programme of testing and operation will surface friction. The absence of any awkward finding usually means the checking was not searching hard enough, or that awkward findings were filtered out before they reached the file. A healthy file contains problems, owned and dated, alongside the fixes.

A single good record is useful, but assurance comes from records that link together. The map identifies the service and its dependencies. The tolerance states what the service must withstand. A test exercises a chosen dependency against that tolerance and records the result. An incident, when it occurs, tests the same arrangement for real and adds its own timeline. A review then connects the test and the incident, deciding what changes and who owns the change.

Honesty in evidence is protected by small disciplines. Separate the record of what happened from the judgement about what it means, so that a later reader can disagree with the judgement while still trusting the facts. Record failures and near misses with the same care as successes, because the file that only preserves good news will not be believed when good news is what is needed most. Keep the original version when a record is corrected, and make the correction visible.

Start with one important service and assemble its trail before attempting to perfect the whole portfolio. Gather its map, its tolerance, its most recent test record, and its most recent incident or near miss, and read them together as a stranger would. Note every place where a link is missing, a date is absent, an owner is unclear, or a result is asserted without a record behind it.

Those notes are the improvement plan, and they are more valuable than a new template or a longer report. Work through them in order of risk to the service, not in order of ease, and re-read the trail after each fix to check that the fix is visible in the record itself. A firm that can do this for one service has learned the skill that the rest of the cluster depends on, and repeating it service by service is how a credible evidence base is actually built.