Cyber Recovery Readiness: The Dark Side of “We Have Backups”

Why recovery playbooks unravel under pressure—and how to stop familiar failures becoming expensive surprises.

Conceptual illustration: the gap between protected data
and a trustworthy return to business.

Picture a recovery call that begins with relief. The backups are intact. Someone announces that restoration can start. Then the questions arrive. Who can unlock the vault? Where are the encryption keys? Why does the restored application refuse to authenticate? And who is authorised to reconnect it?

This is an illustrative scene, not a reported incident. Its point is simple: a backup can survive while the ability to use it does not.

That is the dark side of cyber recovery readiness. The reassuring evidence—a green dashboard, a signed playbook, a successful file restore—may prove something much narrower than leaders think. The awkward question is not whether data exists somewhere. It is whether the organisation can rebuild a trustworthy service while its normal tools, identities and working assumptions are unavailable.

The threat to backups is not hypothetical. In a Sophos-commissioned survey conducted by Vanson Bourne in early 2024, 94% of 2,974 ransomware-hit respondents said attackers had attempted to compromise their backups; 57% of backup compromise attempts succeeded. These are self-reported findings from affected organisations, not a prediction for every business.

The failures below are recurring risk patterns drawn from recovery guidance, incident lessons and practical synthesis. They are not a statistically ranked league table: the available evidence does not establish which playbook failure is universally “most common”.

Recovery means rebuilding trust, not just restoring files

A conventional outage asks, “What broke?” A hostile incident adds, “What can we still trust?” That distinction changes the job. A recovery plan must account for compromised access, questionable restoration assets and the possibility that returning systems will recreate the conditions of the attack. The NIST Cybersecurity Framework 2.0 explicitly separates verification of restoration assets, verification of restored services, and criteria-based recovery closure.

Think of cyber recovery as restoring an operating capability, with evidence that it is safe enough to use. A server booting is a milestone. A customer transaction completing correctly, under restored controls, is closer to the outcome that matters.

Where the playbook breaks

1. The backup survives. Its control plane does not.

“Immutable” is a useful property, not a complete recovery strategy. A protected copy is little comfort if the attacker can remove access to it, compromise its administration, or make the decryption keys unavailable. The UK National Cyber Security Centre treats destructive actions, customer access, historical versions, key management and alerting as separate cloud-backup concerns.

Prevent the surprise: Separate backup administration from everyday production privileges. Protect retention settings and destructive operations with controls appropriate to the platform, including independent approval where supported. Establish an out-of-band recovery route with the provider. Test key retrieval from an approved independent location, rather than assuming the production secrets store will still work.

Prove it: Run a restore exercise with corporate authentication unavailable and the usual backup administrator absent. Retrieve the catalogues, credentials and keys through the approved emergency process. Record what genuinely worked, not what someone believes support could probably arrange.

2. The newest backup is not the safest backup.

Immutability protects a copy against subsequent alteration; it does not certify that the original contents were trustworthy. An older compromise or corrupted configuration may already be inside the data being preserved. NCSC therefore calls for historical recovery versions and regular monitoring and testing, while NIST calls for restoration-asset integrity verification before use.

Prevent the surprise: Make recovery-point selection a joint security and recovery decision. Use the investigation timeline, available logs, configuration baselines and isolated restore tests to assess candidate copies. Distinguish restoring business data from restoring an entire machine image: the latter also brings back operating-system state and settings.

A clean-room scan is one piece of evidence, not a certificate of innocence. Define who can approve a candidate, what unresolved uncertainty remains, and when to reject it. Have the business owner assess the operational consequences of an older restore point. Otherwise, the argument about missing transactions starts only after restoration has already begun.

3. Identity becomes a circular dependency.

The recovery team needs authentication to reach its tools. The authentication service needs those tools to be recovered. Meanwhile, privileged credentials may be untrustworthy. This is the access-denial problem NCSC warns about: attackers can obstruct recovery without deleting a single backup by disabling the identities used to reach it.

Prevent the surprise: Document how recovery starts without the normal directory, federation service, administrator workstation or multi-factor device. Maintain protected, monitored emergency access and clean administrative devices. Specify the sequence for recovering identity services and rotating affected secrets, including machine and application credentials—not just human passwords.

Emergency access needs ownership, secure custody, periodic testing and an auditable use record. It must not become an unmanaged shortcut around security.

Prove it: Begin the exercise from an untrusted-production assumption. Ask the team to establish the first trusted administrative session. If the answer is “log in with the usual account”, the bootstrap procedure needs another pass.

4. Recovery order ignores what services depend on.

A priority list can look perfectly sensible and still be impossible to execute. “Restore customer ordering first” says little about the identity, name resolution, network routes, database, certificates and partner interfaces that ordering requires. NIST recovery guidance explicitly highlights interdependencies across people, processes and technology.

Prevent the surprise: Build the sequence around minimum viable business services, not a list of important servers. Map each service to its technical dependencies, accountable owners, external connections and acceptance tests. Identify which foundations must return first and which integrations can temporarily remain disconnected.

For each dependency, record the recovery source, required access, fallback and evidence needed before the next step starts. Revisit the map after architectural changes; a forgotten integration can turn yesterday’s working runbook into today’s dead end.

Prove it: Have a business user complete a representative transaction across the recovered chain. Successful component restores are not a substitute for a working service.

5. There is nowhere viable to restore.

The British Library’s March 2024 incident review is a sobering example. It reported secure copies of its digital collections, but a lack of viable infrastructure on which to restore them. Major software systems could not simply return in their pre-attack form because they were unsupported or incompatible with the new secure infrastructure.

The lesson is not “buy more backup storage”. It is that surviving data and executable recovery are different things.

Prevent the surprise: Maintain a rebuild bill of materials: supported installation media, configuration exports, infrastructure definitions, licences, certificates, keys and supplier contacts. Validate replacement capacity and compatibility before the crisis. Identify legacy systems that need migration rather than restoration, and fund that work as a readiness gap.

Include cloud and hosted applications in the exercise scope. Ask exactly what can be recovered: records, attachments, permissions, configuration and integrations may require different procedures. Treat each provider’s documented capability as a boundary to test, not an assumption that “the cloud” will take care of recovery.

6. Recovery-time promises exclude most of the work.

A laboratory restore measures what happened in that laboratory. It does not automatically establish how long a real incident will take when access must be rebuilt, copies validated, infrastructure provisioned and services tested. NIST recommends realistic recovery scenarios, milestones and actionable metrics—not simply a document that describes intended timings.

Prevent the surprise: Measure the whole journey to an agreed usable service. Include declaration and mobilisation, trusted access, recovery-point selection, data transfer, rebuilding, security checks, business validation and controlled reconnection. Record delays separately so that an apparently slow restore is not blamed for a procurement or approval bottleneck.

Define both the recovery time objective—the recovery-phase duration before unacceptable business impact—and the recovery point objective—the point in time to which data must be recovered after an outage. Treat them as business requirements to validate, not product guarantees.

Test representative data volumes and concurrent demand. Pre-arrange required capacity and escalation paths. Publish measured results alongside targets, with assumptions visible. An honest gap can be funded; an invisible gap only becomes a surprise.

7. The application works, but the business records do not.

Imagine, illustratively, an order database restored to one point in time while a payment feed resumes from another. Screens load, yet staff cannot tell which orders were paid, shipped or duplicated. The service is technically available but operationally uncertain. NIST’s recovery outcomes include confirming normal operating status, not merely returning assets to service.

Prevent the surprise: Specify consistency checks across connected systems. Assign ownership of transaction reconciliation, duplicate detection, queue replay and records entered during manual workarounds. Identify which external records can support reconciliation and how access to them will be obtained.

Have business owners write acceptance tests before the incident: what must balance, which workflows must complete, and what temporary limitations are tolerable? Preserve a clear boundary between validated data and unresolved items.

Prove it: Exercise a deliberately mismatched recovery point and a backlog of manual transactions. The team should show how it resolves ambiguity without guessing or silently overwriting evidence. “The database restored successfully” is not the final sign-off.

8. Reconnection happens before trust is established.

The pressure to bring something back is understandable. But the decision to restore a workload and the decision to reconnect it should be separate. NIST places verification of restored assets and confirmation of normal operating status explicitly within recovery execution.

Prevent the surprise: Use an isolated recovery environment with controlled administration and connectivity. Before release, require documented checks appropriate to the incident: known entry weaknesses addressed, affected credentials replaced, security monitoring functioning, configurations reviewed and business tests passed. Confirm that connected systems and supplier interfaces are ready too.

Define a release authority and a rollback trigger. If suspicious behaviour appears, the team needs a pre-agreed way to isolate the service again without a fresh argument about who can interrupt business.

Do not demand an impossible promise of zero residual risk. Require an explicit, evidence-backed decision about what is known, what remains uncertain and what compensating controls are in place. Urgency should change prioritisation, not erase the release criteria.

9. The people and decision paths are missing.

The British Library’s account of its response describes alternative communication channels, staff cascades and in-person briefings, and stresses regular updates and staff wellbeing. It also highlights practising business continuity for total systems outages, rather than only single-system failures.

Prevent the surprise: Keep a securely accessible, independent copy of the playbook, contact tree, supplier escalation details and decision log. Agree approved alternative communications. Name deputies for key roles and prepare shift handovers so the response does not depend on one exhausted expert.

Clarify who can authorise isolation, emergency spending, external assistance, recovery-point selection and service release. Have legal counsel and insurance advisers help document applicable notification, evidence-preservation and supplier-approval requirements in advance; those obligations vary.

Coordinate containment and forensic preservation rather than letting recovery teams wipe systems independently. Predetermine how urgent safety or containment decisions will be recorded. A useful playbook makes the next decision easier when normal governance is under strain; it does not pretend that governance disappears.

10. The rehearsal is easy—and “recovered” is declared too soon.

A scripted demonstration can prove that a script works. It may say little about recovery with missing credentials, unavailable staff or compromised dependencies. NIST’s recovery guidance calls for realistic scenarios and continual improvement from exercises and past events. Its framework also requires criteria-based closure and completed incident documentation.

Prevent the surprise: Combine discussion-based exercises with controlled technical restores. Introduce plausible obstacles: an inaccessible key store, an older recovery point, a failed supplier escalation or a business owner who rejects inconsistent records. Do this within an approved exercise boundary; testing resilience should not endanger production.

Define recovery completion in business terms, including validated transactions, restored controls, reconciled backlogs, user communications and remaining restrictions. Assign every exercise finding an owner and a retest. Otherwise, the same surprise simply moves from the exercise report into the incident call.

Finally, resist closing the entire incident because services are available. Stolen information can still require a separate response: NCSC explicitly notes that ransomware-resistant backups do not address data-theft extortion.

A backup is an asset. Recovery is an organisational capability.

Make readiness uncomfortable before recovery becomes urgent

The following is a proposed exercise design, not a prescribed standard. Choose one critical business service and assume production identities, normal collaboration tools and the primary administrative environment cannot be trusted. Keep the test isolated and its boundaries agreed.

Ask the team to demonstrate five gates:

• Access: Obtain the playbook, trusted administrative devices, backups and keys without relying on the failed environment.
• Trust: Select and justify a recovery point, validate restoration assets, and record unresolved uncertainty.
• Capability: Rebuild the dependencies and application in a supported, controlled environment.
• Business acceptance: Complete representative workflows and reconcile missing, duplicated or manually entered records.
• Release: Approve reconnection, demonstrate monitoring and rollback, and document residual restrictions.

Capture elapsed time at each gate, the people and approvals required, the failed assumptions and the evidence produced. Review the result with business owners, not just the infrastructure team. The useful measures are time to a validated minimum service, reconciliation effort, dependency gaps and whether emergency access actually worked.

Then fix and retest the failures. Schedule further exercises according to service criticality and change, rather than treating last year’s success as permanent evidence. CISA recommends offline, encrypted backups and regular backup testing; the broader exercise asks whether the organisation can turn those copies into service.

The uncomfortable question worth asking

Cyber recovery readiness is not pessimism. It is a willingness to challenge comforting assumptions while there is still time to change them.

The dark side is the gap between owning recovery technology and being able to execute recovery under hostile conditions. Close that gap with independent access, defensible recovery points, dependency-aware sequencing, realistic timings and business-owned acceptance.

At the next readiness review, replace “Do we have backups?” with a harder question: “Can we prove that the business will work again when the things we normally depend on cannot be trusted?”

That conversation may be uncomfortable. It is still the cheaper place to discover the answer.

Research and further reading

The following are the sources consulted. The survey is historical, the opening and transaction scenario are illustrative, and the exercise design and mitigations are practical synthesis—not claims of measured failure prevalence.

• NIST SP 800-184: Guide for Cybersecurity Event Recovery, with NIST planning and metrics overview.
• NIST CSF 2.0 recovery outcomes, reproduced by CSF Tools; NIST glossary definitions of RTO and RPO.
• NCSC ransomware-resistant backups and cloud-backup principles.
• CISA StopRansomware guidance.
• British Library cyber incident review, 8 March 2024, hosted by Research Information; British Library lessons presentation, October 2024.
• Sophos: The impact of compromised backups on ransomware outcomes, March 2024.