What “we can recover” means in practice
Assumptions, dependencies, and uncomfortable timelines
Assumptions, dependencies, and uncomfortable timelines
Recovery confidence is rarely examined closely before anything happens because organisations believe they are well-placed to recover from a cyber incident.
Backups exist, systems are designed with redundancy, and recovery processes are documented. This confidence is usually well-intentioned and, in many cases, based on experience.
The difficulty is that recovery is often treated as a capability that exists in theory, rather than one that is continually validated in practice. As environments evolve, so do the assumptions that underpin recovery confidence.
“Recovery confidence often exists as an assumption until someone asks for a timeline, a dependency, or a decision owner.”
Modern systems rarely operate in isolation; Applications depend on data sources, identity services, third-party platforms, and network connectivity. When an incident disrupts part of this chain, recovery becomes less about restoring a single system and more about re-establishing a functioning ecosystem.
These dependencies are not always visible until something fails. Documentation may reflect how systems were designed, not how they are currently used. As a result, recovery timelines are often based on incomplete pictures of what needs to come back online, and in what order.
Having backups is not the same as being able to restore with confidence. During an incident, leadership teams often discover that key questions remain unanswered. How recent is the last clean backup? Has it been tested under realistic conditions? Can it be restored without reintroducing risk?
When these answers are uncertain, recovery slows. Teams hesitate, weighing speed against safety. This hesitation is understandable, but it exposes how recovery confidence can erode under pressure.
Recovery time objectives are often defined during calmer periods. They assume the availability of people, clarity of information, and cooperation across teams. During an incident, those conditions rarely exist.
Staff may be stretched across response and recovery tasks. External providers may be involved. Decisions that normally take days are compressed into hours. Under these conditions, previously accepted timelines can quickly feel unrealistic.
The discomfort that follows is not a sign of poor planning. It is a signal that assumptions have not been tested against current operational realities.
One of the least discussed aspects of recovery is decision ownership. At what point is it acceptable to restore a system with partial confidence? Who accepts residual risk? How are those decisions recorded?
Without clarity, recovery decisions can become cautious by default. Systems remain offline longer than necessary, not because restoration is impossible, but because accountability is unclear.
While technical teams provide critical input, recovery ultimately affects the entire organisation. Customer experience, regulatory exposure, and commercial commitments are all at stake.
When recovery is framed solely as a technical exercise, these broader considerations are addressed late, often under time pressure. Organisations that manage recovery more smoothly tend to integrate business decision-making earlier, even when technical uncertainty remains.
Over time, organisations accumulate assumptions about recovery. “We restored quickly last time.” “This system isn’t critical.” “Our provider handles that.” Individually, these assumptions may be reasonable. Collectively, they can create blind spots.
Incidents have a way of revealing these blind spots quickly, often in ways that are uncomfortable but instructive.
After examining recovery confidence, many leadership teams begin to ask different questions. Which assumptions matter most? Which dependencies have the greatest impact on timelines? And which recovery decisions would be hardest to make under pressure?
These reflections are not about assigning blame. They are about understanding where confidence is grounded in evidence and where it relies on expectation. In practice, that distinction often determines whether recovery feels controlled or uncertain when it matters most.
This series is featured in our community because it reflects conversations increasingly happening among senior security and risk leaders.
Much of the industry focuses on tools and threats with far less attention given to how confidence is formed, tested, and sustained under scrutiny. The perspective explored here addresses that gap without promoting solutions or prescribing action.
Core to Cloud is referenced because its work centres on operational reality rather than maturity claims. Their focus on decision-making, evidence, and validation aligns with the purpose of this publication: helping leaders ask better questions before pressure forces answers.
When a cyber incident is contained, it is often viewed as a success, it feels “successful”.
Building confidence without triggering disruption
When confidence dissolves under scrutiny
What insurers, regulators, and boards expect after an incident
What cyber readiness looks like from the inside
The moment something feels wrong, it's rarely borne out of any certainty.
Operational drag, trust erosion, and regulatory aftermath
Shadow usage, data leakage and invisible risk
Control, confidence, and accountability at scale
Why Security Incidents Are Shaped More By People Than Technology
Most cyber incidents don’t begin as crises
Let us know what you think about the article.