From Policy to a Service That Recovers

A policy becomes a service that recovers when each general commitment in the policy is translated into a specific fact about a named service: who owns it, who uses it, what it depends on, what harm a stop would cause, how it will be restored, and what evidence shows that restoration works. Until that translation happens, the policy is an intention, however well written.

A current account payment service shows the translation in miniature. The policy may promise resilient services, but the service view must name the payment outcome, trace its channel and settlement dependencies, set a harm tolerance, rehearse a failure, fix what the rehearsal reveals, and file the evidence against that service. The policy did not recover the payment. That sequence did.

Policies often stall at the point where general language must meet a particular service. A policy can promise that important services will be identified and tested, while no team has yet agreed which services are important, who owns them, or what testing would prove. The stall is rarely a lack of intent. It is a lack of a named service to attach the intent to.

Policies also stall when ownership is assigned to a programme rather than to service owners. A programme can coordinate, but it cannot answer for a payment service during a disruption. Only a service owner, supported by the teams and suppliers behind the service, can do that, and the policy must make that ownership explicit.

A workable sequence begins by naming the important services and their owners, then mapping each service end to end, then setting a harm tolerance with reasoning, then testing the service against a severe but plausible scenario, then fixing what the test reveals, and then recording the whole chain as evidence. Each step depends on the previous one, and skipping a step usually shows up later as a gap.

The sequence is not a one off project. Services change, so mapping and testing must be revisited, and tolerances must be re-examined when user harm changes. A firm that treats the sequence as a single pass will find its policy drifting away from its services, while a firm that repeats it will keep policy and service in contact.

Good translation looks like documents that agree with each other for one service. The policy commitment, the service map, the tolerance, the test record, and the action list should all refer to the same service, the same users, and the same dependencies, without contradiction. A reader should be able to follow the chain without needing to interpret which service a document meant.

Good translation also looks like decisions made in advance. Recovery order, communication to users, escalation on breach of tolerance, and the person who decides during a disruption should all be settled before an incident, because an incident is a poor time to discover that those decisions were never taken.

The translation stays alive when service owners review their services after change, after tests, and after incidents, and when those reviews produce owned actions rather than general notes. A service that has changed its supplier, its channel, or its user base, but whose map and tolerance have not changed with it, is a service whose policy no longer describes it.

Governance supports that liveliness when it reviews services rather than programmes, asks about open actions for particular services, and follows them to completion. A governance rhythm built around services will notice drift early, while a rhythm built around programme milestones may notice it only when a disruption exposes it.

Choose one policy commitment and trace it to one service. Can the service, its owner, its map, its tolerance, its last test, and its open actions all be produced? If the trace breaks, the break is where policy has not yet become recovery.

This guide is educational and does not prescribe a policy for any firm. It describes the translation that must happen for a policy to matter to users, and the sequence by which that translation can be checked.