What is Business Continuity Management (BCM) in the context of cybersecurity? BCM is the discipline of keeping critical operations running during disruption – not merely of restoring IT systems. A Business Impact Analysis (BIA) identifies which processes matter most, how long they can be down, and what dependencies they rely on. Recovery Time Objective (RTO) defines how fast a service must return. Recovery Point Objective (RPO) defines the maximum tolerable data loss. Traditional BCM plans were built around physical disasters with known causes, contained blast radii, and recoverable environments. Cyber warfare breaks all three assumptions simultaneously — and NIS2 Article 21 and DORA now make resilience a regulated baseline, not a best practice.
Business continuity in cyber warfare – at a glance:
- Traditional BCM plans assume a known cause, a contained blast radius, and a recoverable environment – cyber attacks break all three simultaneously
- Kyivstar, December 2023: Sandworm maintained access for at least seven months before activating destruction – 24 million subscribers lost services; Reuters reported approximately USD 90 million in recovery-related costs (Reuters, May 2024)
- Indonesia National Data Centre, June 2024: USD 8 million ransom demand; 282 government services disrupted; recovery revealed that much data was not properly backed up
- MOVEit, May 2023: one trusted file-transfer tool became the entry point for a global supply-chain incident affecting more than 2,700 organisations – Emsisoft estimated aggregate damages above USD 15 billion
- NIS2 Article 21(2)(c) explicitly requires business continuity measures, including backup management, disaster recovery, and crisis management
- DORA requires documented ICT business continuity policies, tested recovery arrangements, and defined recovery objectives for financial entities
- Sophos 2024: average ransomware downtime is 22 days – organisations with tested backups and stronger preparation recover materially faster
Table of Contents
Why do traditional BCM frameworks fail against deliberate cyber attacks?
Traditional continuity plans fail against cyber warfare because they were designed for accidental outages. A wiper gives you no negotiation path. Backups connected to the production domain can be encrypted or deleted along with everything else. Supplier failures cascade across customers who did nothing wrong. That means an organisation may discover, mid-crisis, that it has a disaster recovery document but no genuine continuity capability.
The Kyivstar case illustrates the failure. On 12 December 2023, Ukraine’s largest telecom operator was hit by a destructive attack that knocked out mobile and internet services for roughly 24 million subscribers. The attackers had been inside the network since at least May 2023 – nearly seven months before activation. Most continuity plans are built around accidental outages. They rarely assume an adversary has been inside for months, understands administrative pathways, and chooses the timing of detonation. A better plan would have included segmented management networks, independent crisis communications channels, tested restoration pathways for core network components, threat hunting for long-dwell intrusions, and executive playbooks for prolonged service degradation rather than a simple failover event.
What does the five-element BCM framework for cyber warfare scenarios look like?
| Framework element | What it means in practice | Board assessment question |
|---|---|---|
| 1. Threat-aware BIA | Run the Business Impact Analysis against cyber scenarios – not just power loss or building loss. Include identity-platform failure, telecom outage, SaaS outage, destructive malware, and multi-supplier failure | If our identity platform or core SaaS failed for 72 hours because of an attack, which three business processes must continue first – and do we know how? |
| 2. Immutable offline backups | Backups that cannot be altered from the production domain, tested against full-environment recovery. Write-once storage, offline copies, and separate credentials matter more than backup frequency alone | Would our backups survive if an attacker gained domain admin rights today – and can we prove it with a restoration test from the last six months? |
| 3. Supplier dependency mapping | Identify not only critical vendors but critical functions, hidden sub-processors, managed file-transfer tools, telecom dependencies, and alternate providers. Build playbooks for supplier compromise, not only supplier outage | Which ten suppliers could stop revenue, customer service, or compliance if they were compromised tomorrow – and what is our workaround for each? |
| 4. Geopolitical monitoring process | A trigger-based process for elevating readiness when your sector, geography, or supply chain faces heightened threat activity. Use CERT alerts and sector intelligence as BCM inputs | Who decides when geopolitical tension requires elevated continuity readiness, and what changes operationally when that trigger is pulled? |
| 5. Tested restoration and communications | Recovery rehearsed in a degraded environment. Test restore order, manual workarounds, board communications, customer notifications, and out-of-band channels when e-mail or mobile networks are unavailable | Have we run a cyber-specific tabletop or live restoration exercise in the last 12 months that proved both technology recovery and executive communication? |
Why are your RTO and RPO values probably wrong in a ransomware scenario?
Many companies still set Recovery Time Objective and Recovery Point Objective values as though they are planning for hardware failure. In hardware failure: you know what failed, the clean backup is available, and the environment is trustworthy. In ransomware or wiper scenarios, none of those assumptions automatically hold.
In a ransomware incident, you may need to re-image devices, rebuild identity services, validate backups for malware-free integrity, rotate credentials, and complete forensic preservation before critical systems return. That takes significantly longer than a hardware recovery.
For a 150-person company with five operationally critical platforms – identity and e-mail, ERP, CRM, customer support, and payment processing – a more honest recovery sequence is: first restore identity services and privileged access controls; second restore core communications; third restore finance and payments; fourth recover less critical productivity services. Sophos found that average ransomware downtime was 22 days in 2024. Organisations with better preparation, tested backups, and stronger response capability recovered materially faster.
What do NIS2 and DORA now require from your BCM documentation?
NIS2 makes business continuity a regulated baseline. Article 21(2)(c) explicitly requires business continuity measures – including backup management, disaster recovery, and crisis management — as minimum risk-management measures for covered entities. That shifts BCM from discretionary resilience language into regulated security governance.
DORA goes further for financial entities. It requires documented ICT business continuity arrangements, defined recovery objectives, and regular testing. A continuity plan that exists only in policy form will not satisfy the direction of modern European regulation.
Learn more about DORA compliance requirements and NIS2 implementation.
FAQ
What is business continuity management in cybersecurity?
BCM in cybersecurity is the discipline of maintaining critical operations during and after a cyber incident. It goes beyond restoring systems – it covers people, communications, suppliers, manual workarounds, recovery priorities, and board-level decisions about what the business must keep doing while technology is unstable.
How does ransomware affect business continuity plans?
Ransomware turns continuity planning into a test of recoverability. It can encrypt production systems, connected backups, and even recovery tooling. BCM must therefore assume delayed restoration, untrusted environments, and the need to prioritise services in sequence rather than recover everything simultaneously.
What is RTO and RPO in the context of a cyberattack?
RTO is the maximum acceptable downtime for a service; RPO is the maximum acceptable data loss. In cyber incidents, both typically need to be more conservative because the last clean restore point may be older than expected and restoration takes longer when credentials, identities, and forensic evidence all require attention.
What does NIS2 require for business continuity?
NIS2 Article 21 requires business continuity measures as part of minimum cyber risk management. This includes backup management, disaster recovery, and crisis management. For covered entities, continuity is therefore not optional resilience language – it is part of the regulated baseline.
What is the difference between disaster recovery and business continuity?
Disaster recovery restores systems and data. Business continuity keeps the organisation operating through disruption. DR is a technical subset; BCM is the broader management framework that includes priorities, communications, suppliers, people, processes, and alternate ways of working.
How do you test a business continuity plan for cyber scenarios?
Start with tabletop exercises involving senior leaders, then run technical restoration tests for critical systems, supplier-failure simulations, and communications drills that assume normal channels are unavailable. A plan is only credible when the documented sequence has been rehearsed under realistic conditions.
BCM gap assessment – free consultation
Patronusec can facilitate a BCM gap assessment and a board-level tabletop exercise focused on ransomware, supplier failure, and geopolitical cyber scenarios – to understand whether your continuity assumptions would survive a real attack before a regulator, customer, or incident forces the answer.
Book a no-commitment call with our team.
