# An Untested Recovery Path Is an Assumption Not a Capability ## Claim A recovery mechanism you have never exercised end to end is a belief about what would happen in a crisis, not a demonstrated capability, and the two are indistinguishable until the crisis arrives. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for any untested failover: backups, disaster recovery runbooks, failover DNS, incident-response escalation paths, a rollback script nobody has run against production. - The gap is invisible by construction — a backup that exists but has never been restored looks identical, from the outside, to a backup that would actually restore cleanly. - Weakest where the recovery path is exercised routinely as part of normal operations (a blue-green deploy that already performs the "restore" motion every release) — routine use converts assumption into capability automatically. - Does not claim untested paths always fail; only that their success is unverified, which is a different epistemic state than verified success even when the outcome would be identical. ## Evidence > [!quote] ID:rw_01m1s3h636csf5z85k9y6yc047 > What matters is not "do you have backups" but: are they stored off-server, are they versioned far enough back to predate a slow-burning compromise, do they include the database as well as files, and, the part everyone skips, have you ever actually restored one? Sucuri's own WordPress security guide names restoration testing as the one item on its backup checklist that "everyone skips" — the only test on the list that cannot be satisfied by intention alone. Every other backup property (off-server storage, retention depth, database inclusion) can be verified by inspecting configuration. Whether a restore actually works can only be verified by doing it. ## Links - [[3. Resources/Permanent Notes/A Control Inside the System It Protects Falls With It]] — because pairs-with; both from the same source, both about the gap between a control's assumed and actual behavior under the exact conditions it exists for. - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — because applies-in; restore-testing belongs in the same operational checklist as the security controls this MOC tracks. - [[3. Resources/Permanent Notes/Release Frequency Should Rise in Announced Reversible Steps Before Automation]] — has evidence from: raise release frequency one announced, reversible step at a time (Thomas, LeadDev). ## Tests / falsifiers - Attempt a full restore from courtneyr.dev's actual backup, the deploy repo, and the vault's backup path. A clean restore supports treating the current setup as a real capability; a failed or degraded restore confirms the claim and converts an assumption into a known gap before a real incident does. - Survey a sample of WordPress site owners on backup practices and restoration history — if restore-testing rates are high, the "everyone skips it" framing overstates the problem; if low, it corroborates the claim at scale. ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/WordPress Security Plugins How to Choose the Right One]] — Sucuri vendor guide, 2026-09-05. Vendor content; Sucuri is GoDaddy-owned — disclose if citing publicly.