Key Takeaways
- Resilience depends on how quickly and confidently the business can recover – not solely on keeping every threat out.
- Turn recovery plans into evidence – tested results are more credible to boards, regulators, and insurers than targets or assumptions.
- Make ResOps a shared operating model for security, infrastructure, business continuity, and service owners.
- Measure what matters: Teams should know whether critical services can be restored, how long recovery actually takes, and whether they can prove it.
- Select one or two critical services, define successful recovery, run an honest exercise, and document the results.
- Twenty years in security leadership teaches you one thing early: The attack you stopped never makes the board meeting. The one you didn’t is the only story anyone remembers. Somewhere along the way I stopped measuring my team by how many hits we absorbed alone and started also measuring us by how fast we got back up.
- That’s the reason I want every CISO, CIO, and board member I know to read a new O’Reilly report, ResOps: An Executive Guide, out this week. Commvault sponsored it, but I’d be recommending it either way.
The Wall Was Never the Whole Plan
For most of my career, the job was building higher walls. Better detection, tighter controls, faster response. That work still matters, and it always will. But a wall only answers one question, and it’s not the one your board is asking anymore.
Last September, ransomware forced Jaguar Land Rover to halt global manufacturing. Assembly lines stopped. Supply chains froze. The UK’s Cyber Monitoring Centre put the cost to the broader economy at roughly £1.9 billion, and JLR posted its lowest monthly production output in 73 years. JLR had defenses. What the incident tested wasn’t whether the wall held. It was whether the business could get back up once it didn’t.
I’ve said this before and I’ll keep saying it: Disruption isn’t an if, it’s a when. The CISOs who sleep at night aren’t those who believe they can keep everything out; they’re those who’ve practiced getting back up so many times that the practice itself is the confidence.
Three Questions I Ask My Own Team
The report organizes the whole problem into three questions, and I’ve started opening every resilience review with them:
- If we were hit tonight, could we recover?
- How long would it actually take?
- Can we prove it, with evidence, to the board?
Most organizations answer the first two with a plan and the third with silence. That silence is the resilience gap, and it’s bigger and more expensive than most executives realize.
Proof, Not Promises
Here’s a distinction the report makes better than I’ve heard it made anywhere else: A recovery time objective is a target. It tells you what you’re aiming for – but it doesn’t tell you whether you’ll hit it.
Compare “we believe we can recover the payments service in four hours” to “we restored it in 3.2 hours last quarter, from a verified clean recovery point, against a four-hour tolerance.” The first sentence is a plan. The second is evidence. Only one of them holds up when your board, your regulator, or your cyber insurer starts asking harder questions, which they will.
The report calls this discipline ResOps, short for resilience operations. It’s not a product you buy or a binder you file. It’s an operating model that connects security, infrastructure, business continuity, and the business owners who depend on these services, all working from the same evidence instead of separate plans.
The Part That Should Worry Every CISO
The report also names something I’ve felt for a while and finally have language for: the AI paradox. The same AI capability helping us find vulnerabilities faster is helping attackers close the gap between discovery and exploitation just as fast, maybe faster. Finding more problems doesn’t make you safer if you can’t recover from the ones that get through. Detection speed was never the finish line. Recovery capability is.
Start with One Service
None of this requires boiling the ocean, and I’d be lying if I said my own team got it right on the first try. The report lays out a 90-day path: Pick one or two of your most critical services, define what “recovered” really means for each, run one honest recovery exercise, and produce your first piece of real evidence. That’s a project any team can start this quarter, mine included.
Proof over promises. Readiness over perfection. That’s the standard I hold my team to, and it’s the standard this report gives you a real path toward.
Get your copy of ResOps: An Executive Guide here.
FAQs
Q: What is ResOps?
A: ResOps, short for resilience operations, is an operating model that connects security, infrastructure, business continuity, and service owners around shared, evidence-based recovery practices.
Q: How is ResOps different from traditional disaster recovery?
A: Traditional disaster recovery often centers on plans and technical targets. ResOps emphasizes continuous validation, cross-functional ownership, and measurable proof that critical services can be restored within business tolerances.
Q: Why is recovery evidence important?
A: Recovery evidence shows what an organization has actually tested and achieved. It helps give boards, regulators, insurers, and business leaders greater confidence than plans or recovery targets alone.
Q: What should organizations measure in a ResOps program?
A: Organizations should measure whether critical services can be restored, how long recovery actually takes, whether recovery points are clean and verified, and whether results meet defined business tolerances.
Q: Who should be involved in ResOps?
A: ResOps should bring together security, infrastructure, business continuity, application and service owners, and executive stakeholders so that recovery priorities and evidence reflect business needs.
Q: How can an organization get started with ResOps?
A: Start with one or two critical services. Define what successful recovery means, run an honest recovery exercise, document the results, and use that evidence to improve the next test.
Bill O’Connell is Chief Security Officer at Commvault.
