Readiness Checklists That Help

A readiness checklist that helps is a short, service-specific list of checks that confirm whether the arrangements for one service actually exist and can be used. Each item should point to something that can be shown: a current map, a named owner, a tested recovery sequence, a supplier contact route that has been tried. The checklist is completed by checking those things, not by asserting them, and a failed check leads to an owned action, not to a tick added in hope.

A checklist that does not help is a long, generic list completed from memory, in which every item is ticked because it sounds familiar. Such a list creates comfort without knowledge, and it is worse than no list at all, because it gives the firm a record of assurance that its evidence cannot support. The difference between the two kinds of checklist is not length or format; it is whether completing the list requires the checker to look at the service, or merely to remember that the service exists.

Design starts from the service and its tolerance, not from a template. For one important service, list the arrangements that would need to operate in a disruption: the people who would act, the map that shows the dependencies, the recovery sequence, the supplier steps, and the communications to users. Turn each arrangement into a check that asks for evidence, such as showing the current version, naming the second person who can use it, or describing the last occasion on which it was tested.

The checker should be close enough to the service to know it, but independent enough to report a failure honestly. A checklist completed solely by the person who owns the arrangements will tend to confirm them, while a checklist completed by someone with no knowledge of the service will tend to misunderstand them. The best arrangement is often a pairing: the service owner provides the evidence, and a second person, from another team or function, checks that the evidence answers the item.

Seniority is less important than honesty and access. A junior checker with access to the records and permission to report gaps will produce a more useful checklist than a senior checker who ticks items between meetings without looking. The firm should therefore protect the checker's ability to record a fail, and should treat a completed checklist with failures as a success of the checking process, not as a failure of the service. A checklist that never fails is a checklist that is not checking.

Results should be filed against the service, with failed checks turned into owned actions and dated. A checklist filed in a general folder, without a link to the service it concerned, is difficult to use when the service is next tested or examined, and its findings are easily lost. Filing against the service also lets a later reader see the pattern over time: which checks repeatedly fail, which arrangements are fragile, and which improvements have held.

Checklists do harm when they replace judgement. A checker who ticks an item because the document exists, without asking whether the document is current or usable, has performed a ritual rather than a check. A firm that measures readiness by the proportion of ticks, rather than by the quality of the arrangements behind them, will optimise for ticks, and its checklists will become longer, easier, and less honest over time.

Imagine a checker working through a short list for one service. For each item, the checker asks the owner to show the record, reads it, and notes whether it answers the item. One item fails, because the recovery sequence names a supplier contact that has changed. The checker records the failure, the owner agrees an action and a date, and the updated contact is tested before the checklist is closed. The checklist itself, with its failure and its fix, is filed against the service.

That completed checklist is now evidence in its own right, and it is more persuasive than a clean checklist would have been, because it shows the firm finding and fixing a real weakness. A supervisor, auditor, or board member reading it can see that checking happened, that it was specific, and that it led to change. That is the standard a readiness checklist should be judged by: not whether it is clean, but whether it is true, and whether it made the service readier than it was before.