Resilience: verify recovery

Recovery depends on people, systems, data and shared services. A plan becomes useful when these dependencies are understood and exercised under relevant conditions.

Recovery means the business can work

When I am told a restore completed successfully, I want to know what was recovered. It may be a file, a machine or a database. The business usually needs an activity working again, with usable data and access for the right people.

I would begin by describing that activity and agreeing how we will confirm recovery. An order application, for example, may need to retrieve records, create a transaction and complete integrations. The service owner should validate which journey represents the need. If success means only that the machine starts, we could finish the exercise without testing the function that justified its recovery priority. The business outcome should remain visible throughout the technical procedure and its acceptance checks.

Prioritize from the business

Determine which services must recover first and what interruption is tolerable. Validate priorities with service owners.

Connect objectives to the service

The recovery time objective, RTO, describes the targeted restoration timescale. The recovery point objective, RPO, expresses tolerable data loss in time. Both should reflect service needs and be checked against actual capabilities.

I would not assume that backups taken at a particular interval guarantee the RPO by themselves. We must check the availability, integrity and restoration of the required data. Nor would I confuse machine restoration time with recovery of the complete process. If the current architecture cannot meet the objectives, record the gap and decide which capability is missing or which trade-off the business needs to reconsider. That conversation is better held before an incident, while there is time to validate alternatives and assign responsibilities.

Map dependencies

Include identity, DNS, connectivity, keys, suppliers and people. Document recovery order and required access.

Sequence matters as much as backups

I would map technical and operational dependencies: identity, DNS, network, certificates, keys, licences, suppliers and staff. Some can recover in parallel; others require a sequence. An application may depend on a database that needs keys held in another service.

I would also review access to documentation and recovery tools during failure. If the procedure lives in the unavailable environment, we need a protected alternative. Emergency access must work without reproducing the dependency we are trying to recover. An account existing is not enough: we need to know who can retrieve it, from where and which records its use will leave. That sequence should be rehearsed rather than discovered during the crisis, including the handovers between responsible teams.

Example: restoring a critical application

A database is restored successfully, but users cannot access it because identity services and DNS remain unavailable. The test demonstrates technical restoration, not service recovery. A useful exercise defines which user journey must work, which dependencies enable it and what evidence confirms the business can operate.

Recovery after a security compromise

A technical outage and a security compromise do not necessarily require the same response. Restoring a compromised system without understanding what must be cleaned or replaced can reintroduce the problem. The procedure needs coordination between recovery and incident response.

I would review the restoration environment, required credentials and available evidence about the data. Checks should cover integrity and functionality as well as time. If we cannot confirm something, make that uncertainty visible to those deciding how activity resumes. Suppliers and external services also matter: knowing their commitments does not prove we have tested our integrations or the availability of the people needed for coordinated recovery. The exercise should establish which parts we can validate directly and which depend on external evidence.

People and decisions are dependencies too

A technically sound procedure can still require decisions nobody knows who should make. Who declares that recovery begins? Who prioritizes when two services compete for resources? Who validates that the business can operate again? Those responsibilities need agreement.

We also need to plan team coordination if normal channels are unavailable. Contact lists, escalation paths and supplier access must work under exercise conditions. If the procedure works only when one particular person is present, that dependency should be recognized.

I would include shift changes and handovers in the test. The receiving team needs to know what was restored, with which data and which limitations remain. Partial recovery may enable one activity while leaving another blocked; communicate that difference clearly.

I would also prepare the return to normal operation. Recovery in an alternative environment introduces changes that must later be maintained, reviewed or reversed. The procedure should explain who controls that state and prevents temporary permissions or emergency configurations from remaining indefinitely. Recovery ends when the service and its operation are in a known state, with outstanding decisions identified. That requires evidence and ownership for the transition, not merely a message saying restoration succeeded. The next exercise should use the updated procedure and confirm that the lessons were applied.

Collect evidence

Test service restoration and recovery, not just the existence of backups. Compare results with objectives and assign owners to gaps.

Close the improvement loop

Each exercise should end with assigned findings and a decision on when to verify them again. Record what was not tested: a laboratory environment or a reduced dataset may not reflect real recovery times. Documenting these limits avoids presenting partial evidence as a recovery guarantee.

An exercise ends when findings are resolved

I would design tests with explicit scope, success criteria and owners. We can begin with partial exercises, but should explain what they demonstrate and what remains untested. A restore with limited data or in a different environment may reveal problems without representing production times.

Afterwards, I would record results, unexpected dependencies and improvement tasks. Each task needs an owner, priority and subsequent verification. If the same issue returns without its cause being corrected, we are repeating exercises without improving capability. I would measure recovered business journeys, deviations from objectives and verified closure of findings. Architecture changes too: a new integration or identity change can make a procedure obsolete even if it worked during the last test.

Further reading

Official sources for checking and exploring these concepts. This article presents a practical approach; it does not reproduce the references’ full requirements.

• NIST Cybersecurity Framework 2.0

Examples are illustrative. Implementation decisions should be adapted to each organization’s requirements and dependencies.