Recovery Integrity

Recovery Integrity

"We have backups" is the answer to "did the backup job run." It is not the answer to "can we recover," and the gap between those two questions is where organizations discover, mid-ransomware, that their recovery plan was a hope with a cron schedule. A backup is not a recovery until it has been proven restorable and proven untampered — and both proofs are routinely skipped because the backup job's green checkmark feels like one.

The reframe: the backup is a target, and it is inside the blast radius. A modern ransomware operator's first move is not to encrypt — it is to find and destroy the backups, because backups are the one thing that makes the ransom optional. If your backups are reachable with the same domain admin credential that the attacker now holds, on the same network, retained on a system they can log into, then they are not a safety net; they are line one of the attacker's checklist.

The failure modes:

• The untested restore. Backups run green for two years; the first actual restore attempt, during the incident, fails — wrong scope, corrupted media, a dependency not captured, an encryption key that was itself only stored in the thing you are trying to restore.
• The backup in the blast radius. Online, credential-reachable backups get encrypted or deleted alongside production. "We had backups" becomes "we had backups until Tuesday."
• The tampered restore. You restore successfully — from a point after the attacker was already inside — and you have faithfully recovered the compromise. A restore is only clean if you can trust the point it came from.

Composes with the library:

• honest-degradation — an unverified restore is a WARN; "backups exist" reported as "we can recover" is the overclaim
• tamper-evident-audit-chain — proving a backup was not altered (and that its restore point predates the compromise) needs integrity you can verify
• assume-breach-modeling — assume the attacker holds domain admin; are the backups reachable from that position?
• credential-material-triage — the credential that can reach/delete the backups is the one whose blast radius includes your recovery
• containment-under-uncertainty — recovery timing depends on knowing when the compromise started; restoring to a bad point re-infects

Step 1 — Is the backup reachable from the compromise?

Before anything about media or schedules, run assume-breach-modeling: assume the attacker holds the highest privilege in the environment (domain admin, cloud admin) as of now. From that position:

• Can they reach the backups (same network, same directory, mapped share)?
• Can they authenticate to the backup system (same credentials, same SSO, a service account they captured)?
• Can they delete or encrypt them (write access, admin on the backup server, API keys to the backup cloud)?

If the answer to all three is yes, the backups share the fate of production and are not a recovery plan. The defense is separation: offline/air-gapped copies, immutability (write-once, time-locked object lock), and credentials for the backup system that are not the credentials that got compromised.

Step 2 — Proven restorable, or it does not exist

A backup that has never been restored is Schrödinger's recovery — both present and absent until observed, and the incident is the worst time to open the box. Require actual evidence:

• Test restores, on a schedule, to a clean environment — not "the job succeeded," but "we restored it and it came up." The metric is a completed restore, the way detection-engineering requires a rule to have fired on a true positive.
• Scope completeness — does the backup capture everything a restore needs: the data, the config, the schema, the dependencies, and the keys? A classic dead-end is backups encrypted with a key stored only inside the system you are restoring.
• Restore-time honesty — how long does a full restore actually take, measured, not estimated? "We can recover" with an unmeasured RTO is a WARN; the business decision (pay vs restore) depends on a real number.

Step 3 — Restore to a point before the compromise, not just before the encryption

A successful restore of a compromised system is not recovery; it is re-infection with downtime. The restore point must predate the intrusion, not merely the detonation:

• Dwell time is often weeks or months, so the "clean" backup from last night may already contain the attacker's persistence. Recovery timing depends on the timeline (incident-timeline-reconstruction): when did they actually get in?
• Retain enough history to have a restore point before the earliest confirmed compromise — and treat "we only keep 7 days and they were in for 30" as a finding.
• Verify the integrity of the chosen restore point (tamper-evident-audit-chain): can you show it was not altered, and that it is from before the breach?

Step 4 — State the recovery claim honestly, with its gaps

Close with a claim someone can bet the business on, not a reassurance:

• What is proven — last successful test restore, its date, scope, and measured RTO.
• What is assumed — components never actually restore-tested, dependencies not verified, restore points whose integrity is unconfirmed.
• What is exposed — backups reachable from the compromise position, retention too short to predate dwell time.

"We can fully recover in 6 hours to a verified-clean point from immutable, offline backups, last restore-tested Tuesday" is a recovery plan. "We have backups" is a hope, and the honest report says which one you actually have — because the ransom negotiation is not the place to find out.

The one-line test

If your recovery plan has never been executed as an actual restore, you do not have a recovery plan — you have backup jobs and optimism. Prove the backups are unreachable from the compromise, prove a restore comes up clean from a point before the intruder arrived, and measure how long it takes — until then, "we have backups" is answering a question nobody asked.