Tools vs. Questions: The Cyber-Resilience Gap

Five categories. Five real problems solved. None of them is the question the board is asking.

The recovery question every executive is now asking

It's the quarterly board meeting, and a board member references a recent industry outage before asking the question. In audit prep, the same question shows up in a different form. So does the COO's version during a new product launch. And the CRO's, the morning a key service goes dark. It isn't phrased the same way twice, but it's the same recurring business question: when disaster strikes, what customer-facing services stay running, and how fast does the revenue they generate come back?

I've spent the bulk of my career in backup and recovery, including stints on the buyer side. I've sat across the table from a lot of CISOs at every stage of this conversation. The honest ones tell me, usually somewhere after the second round of vendor pitches, that they have answers ready for the board but they're not fully confident in those answers themselves. That isn't a failure of effort. The conditions for an honest answer haven't existed yet. Most of us still don't have a clean way to assess the restoration of end-to-end business capabilities against a real disruption, cyber or otherwise.

It's the gap Curtis Simpson, who spent two decades on the CISO side of the table at Sysco and Armis and is now CSO at Gambit, named for me as "storytelling, not data-based." Stakeholders hear confidence. The CISO walks out knowing the answer was an estimate dressed up for the room. None of us got into security careers wanting to be in that position.

If you're sitting in evaluation cycles with three resilience vendors right now, the rest of this post is a set of questions to take into your next meeting with them. The answers will tell you which one is selling a slice and which one is building a platform.

And the audience for the answer keeps widening. Resilience used to be a tier-1 concern of IT alone. Times have changed. Boards, regulators, insurers, and customers now treat the continuous availability of customer-facing capabilities as table stakes. The EU's Digital Operational Resilience Act made it a regulatory obligation across financial services in early 2025. Customer expectations, industry competition, the volume of attacks, and the AI-era pace of change have all changed the mandate. The CISO's risk management program is expected to assess and manage digital resilience risks now, even when no one stated that expectation explicitly until a material disruption forced it into the open.

Why resilience tools each answer the wrong question

The resilience market has been responding to evolving needs for years, the way our industry usually does: with more tools, each focused on an isolated capability. I've sold some of them. Most have real value. None of them, on their own, answers the question the board is actually asking.

Each of these tools earns its place in a stack. Five real problems solved. None of them, on their own, answers the question that matters most when customer-facing services and the revenue they generate are on the line.

True resilience is delivered as an extension of digital risk management; a CISO responsibility

Historically, the market has addressed resilience through isolated technical capabilities. Each tool answered a question that lived inside the infrastructure team, where resilience tooling has historically sat. That's the structural problem. Security has been pulled in to own the risk, but resilience itself doesn't live in either team. The business needs an answer that lives across both. "Will the business actually recover?" is the harder question, and it doesn't get answered by any one of the “slice-tools” above. Answering it requires business-aligned visibility and management that spans applications, the digital estate that powers them (cloud and on-premises), infrastructure-as-code, backups, and SLAs, end to end.

It has to account for the cascading failures individual tools can't see: the app that restores cleanly against a database that didn't, the IaC that redeploys to a VPC that's been quietly drifting for six weeks, the backup that's pristine for a service whose dependency chain isn't, the dashboard that's green because nothing has tested the chain in eleven months.

Rebuild isn't recovery. Clean bytes aren't clean recovery. Until something proves the chain end to end, the answer to the board's question is still a story. Cyber resilience is a business survival question, not a security one. The CISO is the executive whose job description has grown to include it. Their partners in infrastructure own the remediation. The risk assessment, the prioritization, and the answer to the board belong to the CISO.

What end-to-end cyber resilience actually requires

Take the business question as the spec, and a small number of capabilities fall out of it. None of them is exotic. None sits inside a single category. All of them have to work together.

Map the business system across the stack. Apps, data, cloud, IaC, on-prem, and every dependency that links them belong in the same picture. End-to-end resilience can't stop at the cloud edge, because the customer-facing services you're protecting don't stop there either.

‍Measure reality, not intent. Documented RTOs and once-a-year tabletop exercises are intent. The time an end-to-end business system actually takes to come back during a real incident is reality. A real answer measures the recovery and reports the gap against what's documented.

‍Cover hybrid without punishing it. Multi-cloud is normal. So is on-prem. So is partial IaC adoption. Any scoring model that ignores systems not managed by infrastructure-as-code will flatter the cloud team and mislead the business.

‍Validate restore points against real attack scenarios. "We have backups" is not the same statement as "we have backups that survive the attack we're modeling." That's the difference between an audit checkbox and an actual recovery.

‍Produce continuous evidence, not annual artifacts. The board asks the recovery question every quarter. The auditor's version is being asked for DORA-relevant jurisdictions at the same frequency. Both want evidence that was true this month, not the one from last fiscal year's tabletop.

‍

Read back as a checklist:

• One business system map that spans apps, cloud, on-premises, IaC, backups, and SLAs
• Live state, not declared state
• Restore validated against real incidents
• Continuous, not annual

How I'd evaluate a resilience platform

On the buyer side, I learned this the hard way. If your evaluation criteria are written category by category, you'll buy category-by-category answers (the slices), and you'll end up where the market is now: a stack of competent tools and an average enterprise ransomware recovery time of 24.6 days. Long enough to break a quarter.

The question I wish I'd asked sooner is different. Stop asking vendors which slice they cover. Start asking which slices they connect, and what they can prove on a Tuesday with no incident in sight.

In practice, that's an RFP question that doesn't fit on a single line: in this multi-cloud, partly on-prem, partly IaC environment, with these backups and these SLAs, what percentage of customer-facing services would actually be running an hour after this attack, and show me how you know. The vendors who can answer that across the stack are the ones building a resilience platform, not a dashboard that shows you gaps but a system that helps close them, automatically where it can and with guided next steps where it can't. The ones who can't answer it will sell you a slice, and a slice is what you'll be holding the next time something hits.

The CISOs who own the recovery question, not the security question, are the ones who hold their ground in every conversation that matters: the board, the auditor, the COO when a launch is at risk, the CRO the morning a key service goes dark. Storytelling gets you through a quarter. Evidence gets you through a year.