On August 24, in the year AD 79, Pompeii woke to an ordinary morning. Vesuvius had rumbled for years — tremors that cracked plaster, wells running low, small quakes the city had learned to live with rather than investigate. Pliny the Elder, curious rather than alarmed, sailed toward the eruption to observe it up close and never made it home. Nobody in Pompeii had rehearsed what actually happened that afternoon. They had years of warning signs and a story that explained each one away.
Two thousand years later, the mountain is different. The pattern isn’t.
The real obstacle to cyber recovery testing
In a prior blog, I argued that the biggest barrier to cyber recovery testing isn’t budget or technology, it’s organizational fear of what a real test might reveal. Testing sits at the intersection of IT, security and business continuity, three teams that rarely share an owner or an agreed definition of what “passed” really means. When a test surfaces a serious gap, someone has to own it. Leadership that already assumes the organization is ready has little incentive to find out otherwise.
An independent perspective on resilience testing
According to Gartner, “Most resilience testing is the kind that cannot fail —tabletop walkthroughs, maturity assessments, recovery times that live on a slide and were never exercised.”¹ A walkthrough on paper or a score on a dashboard can look like progress without anything real being tested. In my own view, an organization that only ever runs that kind of exercise never finds out whether it’s actually ready, it just keeps generating reports that say it is.
In short, a test that can’t fail isn’t testing anything.
What a real cyber resilience test requires
Dell’s Cyber Resilience Insights research shows why the distinction matters. Only 39% of organizations describe their cyber resilience strategy as fully established and continuously optimized, and 63% believe their own leadership overestimates readiness for a major cyber event. The differentiator isn’t intent, it’s cadence: organizations that ran simulated attacks monthly or more recovered 55% of the time, well ahead of those (38%) that only test sporadically.
Cyber recovery testing needs a minimum viable business target
The other piece missing from most testing programs is a real target. In his recent post on AI-era threats, my colleague Simon Jelley made the case that most organizations assume they know their minimum viable business — what has to come back online first, in what order — and discover under pressure that they don’t. That’s the gap a real test should be built to find. A recovery exercise run without a defined minimum viable business to restore against is an exercise in general direction, not a real answer to whether it worked.
How to start cyber resilience testing, and make it count
None of this requires a full-scale simulated attack to begin. A tabletop exercise still has its place — the fastest way to surface who owns what. A structured assessment, like Dell’s Cyber Resilience Assessment, shows where your posture actually stands. But neither is capable of failing on its own; both belong in the category built to produce a report, not proof. The test that counts is a restore: pick a non-critical workload, recover it against your minimum viable business and time it against your actual RTO. If it holds, you’ve learned something real. If it doesn’t, you’ve found the gap before an attacker did. Use the tabletop exercise and the assessment to decide where to point that test next time, not as a stand-in for running it. If it can’t fail, it isn’t a test.
Pompeii had years of warning signs and never rehearsed for the day the mountain actually erupted. Most organizations aren’t short on signals or time to prepare, just the willingness to run the one test that might prove them wrong.
Read the post this builds on: Why Cyber Recovery Testing Fails — And How to Start.
Dell reported this
Source: www.dell.com
Source link
