Recovery Sequencing for a Service

Recovery sequencing is the order in which the parts of a service return after a cyber incident or outage. It matters because a service is a chain of dependencies, and restoring a later link before an earlier one is sound creates a service that looks alive while acting on untrustworthy foundations. A sensible sequence usually restores identity, core records, and the controls around them before reopening customer channels, and reopens journeys in an order the firm can check and, if needed, reverse. The sequence should be written down before an incident, and followed, or deliberately departed from, with reasons recorded.

Sequencing is also a way of managing risk during the return. Each stage is a chance to learn whether the restored parts behave correctly before more is put on top of them. A firm that restores everything at once learns about all its problems at once, under full customer load, with no clean point to step back to. A firm that restores in stages may be slower to full service, but it knows, at each stage, what has been proven and what has not, and that knowledge is what makes the final return defensible.

A sequence starts with a map of what the service depends on. For a mortgage servicing service, for example, the customer portal depends on account records, which depend on a core ledger, which depends on identity checks and on data feeds from providers. The map does not need to be exhaustive to be useful. It needs to be honest about the dependencies that would block a safe return, and about the ones that could be worked around for a limited period. A map that omits a provider because the provider is reliable is not a map. It is a hope.

Foundations come first because everything else trusts them. Identity and access matter early, because a restored service that cannot tell legitimate users and staff from intruders is not safe to open. Core records matter early, because transactions recorded against wrong balances or wrong accounts create errors that spread with every new transaction. Monitoring and logging matter earlier than they often appear in plans, because a firm returning a service without a trustworthy way to see what it is doing is flying without instruments.

Channels and journeys return after the foundations they rely on, and usually one at a time. Returning a mobile channel, a web channel, and a telephone service simultaneously may feel efficient, but it multiplies the load on newly restored systems and multiplies the places where an error can appear. Returning one journey, watching it, and then widening the return gives the firm evidence at each step. It also gives customers a clearer story: this part of the service is back, this part is still limited, and this is what the firm is checking next.

Providers and shared dependencies often decide the sequence, whether the firm wants them to or not. A service cannot safely return before a provider it depends on has itself recovered, or before the firm has a workable alternative. The sequence should therefore include provider recovery as a stage, not as an assumption. A firm should know, for each important provider, what the provider's own recovery sequence is, how the firm will learn that it has completed, and what the firm will check independently before trusting the connection again.

Planned sequences will sometimes prove unworkable. A system expected to restore may fail its checks, a provider may return later than expected, or new evidence may change the understanding of what was affected. Departures from the plan are not failures in themselves. They become failures when they are silent, when no one records why the order changed, or when the change removes a check without replacing it. A departure should be treated as a new decision, with the same care as the original plan: what changed, what risk the change creates, and who approved it.

After the return, the sequence itself should be reviewed. Did the order hold up in practice. Did any stage prove unnecessary, or any missing stage cause trouble. Did the firm learn that a dependency it thought minor was actually blocking. Those lessons should be written back into the plan, so the next sequence is based on experience rather than on the same untested assumptions. A sequence that is never reviewed after use is not a plan that improves. It is a document that ages, and ageing plans are a quiet risk to the next recovery.