What is Business Continuity Planning in Cybersecurity?
Business continuity planning ensures operations continue during cyber disruptions.
Business Continuity vs. Disaster Recovery
Business continuity and disaster recovery are related but distinct disciplines that are frequently conflated. Business continuity planning addresses how an organization continues to deliver critical functions during a disruption — the operational response while the incident is ongoing. Disaster recovery addresses how systems and data are restored after a disruption — the technical recovery process that returns the environment to normal operating state.
A comprehensive resilience program requires both: BCP that ensures critical operations can continue in degraded mode during a cyber incident, and DR that enables rapid restoration of systems and data after containment and eradication. Organizations that have disaster recovery plans without business continuity plans can recover their systems but may not be able to sustain critical operations during the recovery period. Organizations that have operational continuity procedures but inadequate recovery capabilities may sustain operations temporarily but cannot return to normal operations in an acceptable timeframe.
Recovery Time and Recovery Point Objectives
Recovery Time Objective (RTO) defines the maximum acceptable time from a disruption to restoration of normal operations. Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss measured in time. These two metrics define what business continuity actually means in operational terms: how quickly the organization can resume operations and how much data it can afford to lose.
The board-level question is whether stated RTOs and RPOs are actually achievable under the conditions of a real cyber incident. A documented 4-hour RTO is meaningless if the recovery procedure has never been tested at full operational scale, if backup data has been compromised by the same attacker, or if the personnel required to execute recovery procedures are not available. Most mid-market BCP documents specify RTOs that the organization cannot achieve in practice — they reflect aspiration rather than capability.
The diligence question for management and the board is not whether RTOs and RPOs are documented, but when they were last tested against a realistic cyber incident scenario, what the actual recovery time was, and what gaps that test surfaced. Untested recovery objectives are the single most expensive assumption in most cybersecurity programs.
Cyber-Specific Business Continuity
Traditional business continuity plans address physical disruptions — facility damage, power outages, natural disasters. Cyber incidents present different recovery characteristics: the incident may have compromised the systems on which BCP procedures are stored and accessed, communication systems may be compromised or under attacker control, and the scope of impact may be unclear at the time response decisions must be made.
Cyber-specific BCP addresses: out-of-band communication procedures that do not rely on potentially compromised corporate systems, manual procedures for critical processes when system access is unavailable, pre-identified alternative systems for critical functions, and clear criteria for invoking continuity procedures when incident scope is still being assessed. The communications component is frequently the most critical and most underprepared: if corporate email is compromised, how does the security team communicate? How does the CEO reach the board?
Real-World Example: Irish Health Service Executive — When BCP Fails at Scale
In May 2021, Ireland's national health service — the Health Service Executive (HSE) — suffered a Conti ransomware attack that encrypted its IT systems across the entire national health infrastructure. The HSE had business continuity procedures on paper but had never tested them at the scale the incident required. The result was a reversion to manual paper-based processes across 54 hospitals, cancellation of thousands of outpatient appointments, and inability to access patient records digitally for weeks. The full recovery took months. The decryption key was eventually provided without payment after significant public pressure. The incident demonstrated that a functioning BCP must be tested at realistic scale to be meaningful — procedures that work in a tabletop discussion may be operationally unworkable when applied across an organization of HSE's size and complexity.
Related Executive Analysis
The HSE case is a ransomware-driven BCP failure. The same governance question — whether RTOs match operational reality — appears in non-adversarial contexts too. Wells Fargo's seven-year outage pattern is a parallel BCP failure mode: a tier-one vendor with mission-critical infrastructure that has demonstrated 24- to 48-hour recovery times for customer-impacting incidents the company itself describes as "routine maintenance." For any organization running treasury, payroll, or vendor payments through a single banking relationship, the Wells Fargo pattern is the BCP scenario that should be modeled, not the rare ransomware tail event.
- Seven Years. Five Major Outages. Wells Fargo Still Calls It "Routine Maintenance." — vendor concentration risk and recovery time objective failure in tier-one financial services.
Average time to restore full operations after a ransomware attack, even with cyber insurance coverage — compared to the 4-hour RTO that most mid-market BCP documents specify. Untested recovery assumptions are the most expensive assumption in your risk management program.
.png)