Cyber Resilience Board Briefing Series 3: Why Recovery Capability Is Now a Board-Level Risk

Written By Jimmy Blake

The Issue

For many years, boards have been briefed on cyber risk through the lens of prevention and detection.

  • How many attacks were blocked?

  • How quickly were alerts triaged?

  • How many vulnerabilities were patched?

  • How much investment has been made in security tooling?

These are all important questions, but they are no longer sufficient.

In an era of destructive cyberattacks, the defining question is not simply whether the organisation can stop the attacker. It is whether the organisation can continue operating, make informed decisions under pressure and recover its most important services to a state that can be trusted - that makes recovery capability a board-level risk.

Not because the board needs to understand every technical step involved in restoring systems, but because recovery determines whether the organisation can survive the operational, financial, regulatory and reputational consequences of a destructive cyber event.

The uncomfortable truth is that while many organisations have a backup and disaster recovery capability, very few have a coherent operational cyber recovery capability.

Why This Matters at Board Level

Boards are ultimately accountable for organisational resilience. In a serious ransomware or wiper event, the consequences are not contained within the IT function.

A destructive cyberattack can affect:

  • Revenue-generating services

  • Customer access

  • Payment processing

  • Manufacturing operations

  • Logistics and supply chain execution

  • Regulatory reporting

  • Employee productivity

  • Legal obligations

  • Market confidence

  • Public trust

  • Public safety

In that context, recovery capability becomes a measure of organisational survivability.

The problem is that many board briefings still reduce recovery to a narrow technical statement: “We have backups.” That may be true, but it does not answer the questions that matter during a real incident:

  • Which services must be recovered first?

  • What is the minimum viable organisation we need to operate?

  • Can we trust the identity systems used to perform the recovery?

  • Can we validate attack surface and attacker persistence have been remediated?

  • Can we restore into an environment that is not still compromised?

  • Who has authority to resume operations under uncertainty?

  • What level of residual risk is acceptable?

  • Can we evidence the basis on which recovery decisions were made?

These are governance questions, not just technology questions.

If the board has not asked them before the incident, the executive team will be forced to answer them during the incident, under pressure, with incomplete information and while the organisation is already degraded: that is not resilience, that is cyber resilience improv.

Recovery Capability vs Recovery Technology

Recovery technology is what the organisation owns, recovery capability is what the organisation can reliably do under adverse conditions.

Recovery Technology

Recovery Capability

  • Clear recovery priorities based on business impact

  • Tested cross-functional recovery workflows

  • Trusted identity and privileged access pathways

  • Defined decision rights

  • Response & recovery playbooks

  • Evidence-led recovery point selection

  • Clean restoration environments

  • Ability to validate recovered systems before reconnecting them

  • Executive governance over risk acceptance

The difference is similar to owning a fire engine versus having a trained fire service:one is just an asset, the other is an operational capability.

Boards should care deeply about the second.

Where Organisations Commonly Fail

Across real-world destructive cyber incidents, I’ve seen several recurring failure patterns emerge.

Confusing Backup Success with Business Recovery

Many organisations can successfully restore individual systems from backup, but have not tested whether they can recover an end-to-end business service.

A business service may depend on:

  • Identity

  • Network connectivity

  • DNS

  • Databases

  • Middleware

  • Application servers

  • Third-party integrations

  • Cryptographic certificates and keys

  • File shares

  • Licence keys

  • End-user devices

  • Operational procedures

  • Supplier support

Restoring one application server does not mean the business service is operational.  It may simply mean one component has come back online in an environment where the dependencies needed to use it are still unavailable, untrusted or compromised.

This is why recovery must be planned around business services, not isolated systems.

Prioritising Everything, Which Means Prioritising Nothing

During a destructive cyberattack, every business function will believe its services are critical.

  • Finance needs payment systems.

  • Operations needs production systems.

  • HR needs payroll.

  • Customer service needs CRM.

  • Legal needs evidence.

  • Communications needs channels.

  • Security needs telemetry.

  • IT needs administrative control.

All of these may be important, but they cannot all be first.  Without a pre-defined minimum viable operating model, recovery prioritisation becomes political, emotional and reactive.

The board’s role is to ensure that management has defined, in advance, which services are genuinely necessary to keep the organisation viable during a severe cyber event.

That does not mean everything else is unimportant. It means the organisation has accepted that recovery is a sequencing problem, not a popularity contest.

Restoring Faster Than the Organisation Can Validate

Speed matters in recovery, but speed without assurance can be dangerous.

A system restored from backup may still contain:

  • Malware, backdoors and Trojan Horses

  • Web shells

  • Compromised accounts

  • Evaded security tooling

  • Vulnerable applications and operating systems

  • Vulnerable misconfigurations

  • Scheduled malicious tasks

  • Persistence mechanisms

  • Attacker-created access paths

The pressure to resume operations can drive organisations to restore quickly and validate later.  This is commercially understandable, but creates systemic risk.

The organisation may bring services back online while the original attack path still exists, while the attacker still has access, or while restored systems are reconnecting to compromised identity and management infrastructure.

In the worst cases, the organisation does not recover from the incident; it restarts the incident.

Treating Recovery as an IT Problem

Cyber recovery is often placed primarily in the hands of infrastructure and operations teams.  While those teams perform much of the technical restoration activity, destructive cyber recovery also requires input from:

  • Security operations

  • Digital Forensics and Incident response

  • Identity teams

  • Application owners

  • Business service owners

  • Risk and compliance

  • Legal

  • Communications

  • Procurement

  • Suppliers

  • Executive leadership

If recovery is treated as an IT restoration activity, the organisation will miss the broader risk questions:

Recovery is technical in execution, but strategic in consequence, which is why it belongs on the board agenda.

The Board’s Role

Boards do not need to manage the recovery, but they do need to govern the conditions under which recovery is considered acceptable.  This means ensuring that management can answer several fundamental questions:

What Are Our Most Important Services?

The board should ensure that the organisation has identified its Minimum Viable Company.  These are the services that must be recovered first to maintain safety, liquidity, customer confidence, regulatory compliance or operational continuity.

This requires more than a list of critical applications. It requires a mapped understanding of the business services that matter most and the dependencies required to deliver them.

What Recovery Outcomes Are Acceptable?

Boards should challenge whether recovery objectives are defined only in terms of time and data loss.

Traditional measures such as Recovery Time Objective and Recovery Point Objective are useful, but incomplete.  In a cyber context, the organisation also needs to define assurance conditions, such as:

Recovery objectives should include trust, not just time and amount of data.

Who Makes Recovery Decisions Under Uncertainty?

Following a destructive cyberattack, perfect information will rarely be available.  The organisation may not know:

Exactly when the attacker first gained access

Despite this uncertainty, decisions still need to be made.  The board should ensure that decision rights are explicit before the incident occurs.

Without clear decision rights, organisations either delay unnecessarily or restore unsafely, both these outcomes create risk.

Has Recovery Been Tested Realistically?

Many recovery exercises I have been asked to observe test idealised scenarios that bear little resemblance to the reality of destructive cyberattacks. Based on hands-on experience supporting hundreds of ransomware incidents, these exercises often assume away the very conditions that make recovery difficult and create uncertainly. In these scenarios:

  • The backup platform is available.

  • Identity works.

  • Documentation is accessible.

  • Key staff are available.

  • Suppliers respond quickly.

  • Communications channels remain intact.

  • The recovery environment is trusted.

  • The attacker is no longer active.

Real incidents are rarely this convenient.  Boards instead should ask whether cyber recovery exercises include realistic degradation, such as:

  • Compromised identity

  • Unavailable privileged access

  • Loss or compromise of normal communications

  • Uncertainty over backup integrity

  • Compromised administrative workstations

  • Supplier delays

  • Conflicting business priorities

  • Media pressure

  • Regulatory notification deadlines

  • Coercion of staff

  • Incomplete forensic evidence

The value of an exercise is not proving that the plan works in perfect conditions, it is discovering where the plan fails before the organisation has to rely on it.

A Practical Analogy

Cyber recovery capability is like emergency surgery:

  • Having the operating theatre is important.

  • Having the surgical instruments is important.

  • Having blood supplies, anaesthesia and monitoring equipment is important.

None of that means the hospital can successfully perform emergency surgery.  That capability depends on trained teams, clear decision-making, sterile conditions, triage, tested procedures, specialist judgement and the ability to operate under pressure when the patient is deteriorating.

Backups are part of the operating theatre equipment, they matter enormously: but they are not the surgery.  Cyber recovery capability is the organisational ability to perform the surgery when your business is on the table.

Key Takeaways for the Board

  • Recovery capability is now a board-level risk because it determines whether the organisation can survive a destructive cyberattack

  • Backups and disaster recovery tooling are necessary, but they do not automatically create cyber recovery capability

  • The board should focus on recovery of critical business services, not just restoration of technical systems

  • Recovery must include assurance that systems, data, identity and control planes can be trusted

  • Decision rights, risk appetite and recovery criteria must be defined before the incident

  • Realistic exercises should test degraded conditions, not ideal recovery scenarios

  • The central question is not “Can we restore?” but “Can we safely resume the business services that matter most?”

What to Ask Your Executive Team

  • ·Are you partnering with a backup vendor that is selling you a product, or helping you build an operational cyber recovery capability?

  • What are the minimum viable services we must recover first after a destructive cyberattack?

  • Have we mapped the dependencies required to restore those services end to end?

  • How do we determine whether a recovered system or service can be trusted?

  • Do our recovery objectives include assurance criteria, or only time and data loss targets?

  • Who has authority to approve recovery under uncertainty?

  • What level of residual risk are we prepared to accept when resuming operations?

  • Have we tested recovery where identity, security tooling or administrative access is compromised?

  • Can we identify and validate clean recovery points during an active incident?

  • Are our recovery plans aligned to business service priorities or technical infrastructure silos?

  • Can we evidence recovery decisions to regulators, insurers, customers and internal stakeholders?

Closing Thought

The organisations I’ve seen recover effectively and efficiently from destructive cyberattacks are not simply the ones with the best technology, they are the ones that have already decided what matters most, how recovery decisions will be made, what level of trust is required and how business services will be restored under degraded conditions.

Recovery capability is now a board-level risk because, during a serious cyberattack, it becomes the practical expression of resilience.  It is where strategy, governance, technology and operational reality collide.

If the organisation cannot recover what matters most, safely and defensibly, then cyber risk has not been managed, it has merely been deferred.

Next Briefing

The Illusion of Clean Backups: Why Historical Data Does Not Automatically Mean Trusted Recovery.

The perspectives shared here are my own, based on practitioner experience in cyber resilience and incident response, and do not necessarily represent the official views or positions of my employer.
Jimmy Blake

Next

Ransomware in Education Part 2: Why Schools, Colleges and Universities Struggle to Recover and How to Improve