Mapping Backup and Recovery Dependencies

Mapping backup and recovery dependencies shows what recovery itself needs in order to succeed. A service may have backups, a recovery site, and a written plan, yet still fail to recover because the recovery process depends on a system, a person, a supplier, or a network path that is itself affected by the incident. Recovery dependencies include the copies of data and configuration, the tools used to restore them, the people authorised to make recovery decisions, and the suppliers whose help is needed to rebuild. The map should trace recovery as a service in its own right, with its own dependencies, rather than assuming that recovery will somehow happen once the incident is declared.

Recovery typically depends on several things at once. It needs a usable copy of data and configuration, stored somewhere that the incident has not affected. It needs the platform or site on which to restore that copy, with sufficient capacity and access. It needs the tools and credentials to perform the restoration, held by people who are available and authorised. It may need a supplier to restore a hosted component, a network provider to reconnect a site, or a communications platform to coordinate the response. Each of those is a dependency of recovery, and each can fail. A map that lists backups without listing what is needed to use them has described storage, not recovery.

The recovery route is weak because it is rarely used in full. Backups may be taken regularly but restored rarely, recovery sites may be maintained but never run the live service, and recovery tools may be updated without being tested in a realistic scenario. Assumptions accumulate: that a copy is complete, that a credential still works, that a supplier will respond promptly, that a network path to the recovery site is intact. Each assumption is reasonable in isolation, but together they create a recovery plan that has never been proven end to end. Mapping recovery dependencies forces those assumptions into the open, where they can be checked rather than trusted.

Record them alongside the service map, but as a distinct recovery trace. For each service, show the recovery sequence in order, the dependency behind each step, and the alternative if that dependency fails. Note where recovery depends on the same system, site, supplier, or person as the live service, because that shared dependency may mean recovery is impossible while the original incident persists. Also note the order in which stores and systems must be restored, where one depends on another. That sequencing is part of the map, not an afterthought, because restoring components in the wrong order can create inconsistency that is harder to fix than the original loss.

Backup copies should be mapped like any other data store, with attention to location, completeness, and freshness. The map should show where each copy lives, which store it protects, how it is isolated from the live environment, and how its usability is verified. A copy that has never been restored is an unproven copy, and the map should say so. It should also show whether a copy depends on the same supplier, site, or network as the live service, because a copy that shares the fate of the original offers little protection. Diversity of location and provider, where it exists, should be visible, so that a single incident cannot plausibly destroy both the live service and its recovery copy.

Test by actually restoring, not merely by reviewing the plan. A rehearsal that restores a service to a recovery environment, using only the map and the recorded dependencies, will expose missing credentials, incomplete copies, unavailable suppliers, and sequencing errors that a paper review would miss. The rehearsal should also test decision making: who authorises a fallback to an older copy, who decides that reconciliation is needed, and who communicates the recovery state to customers. Under DORA in the EU and under FCA and PRA policy in the UK, recovery capability is part of the resilience expectation, labelled separately in these guides, and a restored service is the strongest evidence that its recovery dependencies were mapped correctly.