Most business continuity plans were written for a fire, a flood or a power cut. Then a ransomware crew encrypts the file servers, the backups and the very document that explains what to do next. The plan that looked solid in the audit binder dies in the first hour of a cyberattack.
This is the gap between BCP as a compliance artifact and business continuity planning as a real capability. Here is how to close it.
What a BCP is actually for
A business continuity plan (BCP) is the documented arrangement that lets your organization keep its essential activities running, even in degraded mode, during and after a major disruption. It answers one question before the crisis does: who does what, in what order, with what resources?
A common mistake is to reduce the BCP to an IT recovery plan. Continuity depends on far more than servers:
- People: who can act if the crisis team lead is on a plane, and who covers critical roles held by a single person?
- Sites and equipment: where do teams work if a facility, a plant floor or a call centre is unavailable?
- Suppliers: which third parties are so critical that their outage becomes your outage, and what is the workaround?
- Communications: how do you keep talking to employees, customers, regulators and media when your usual channels are down or untrusted?
The disaster recovery plan (DRP) that restores IT systems is one component. The BCP is the business-wide layer above it.
Why a cyberattack breaks classic BCP assumptions
A ransomware attack is not a flood. Traditional continuity planning quietly assumes the disruption is external, local and neutral: the building is gone but the network is fine, so you fail over to another site and carry on. Ransomware violates every one of those assumptions.
- The network itself is hostile. The attacker may still be inside. Failing over to your secondary site can simply hand them a second environment. Recovery starts with containment and eviction, not with restoration.
- Backups are a target, not a given. Modern crews hunt for backup consoles first. Backups may be encrypted, deleted, or poisoned weeks earlier so that restoring reinstalls the attacker's access.
- Recovery order matters. Identity, DNS, and network services must come back before business applications, on rebuilt or verified-clean infrastructure. Restoring the ERP onto a compromised domain wastes days.
- The clock is legal, not just operational. Regulators expect notification within tight deadlines, insurers expect evidence of what you did and when, and forensic preservation constrains how fast you can wipe and rebuild.
If your BCP treats "cyberattack" as one scenario among others, with the same recovery logic as a fire, it will not survive contact with a real incident.
Start with an honest business impact analysis
The business impact analysis (BIA) is the foundation of any credible BCP. It identifies your critical business processes, their dependencies (systems, people, sites, suppliers), and the point at which their interruption becomes unacceptable.
From the BIA flow your recovery objectives: RTO and RPO per process. The RTO is the maximum tolerable downtime; the RPO is the maximum tolerable data loss. Two disciplines matter here:
- Differentiate. Not everything is critical. A four-hour RTO for payroll on the 2nd of the month is theatre; a four-hour RTO for the order-taking system may be existential. Short targets are expensive: reserve them for processes that genuinely warrant them.
- Be honest. An RTO of four hours means nothing if a full restore from backup takes three days. Set targets your architecture can actually meet, or invest until it can. The gap between the stated RTO and the real restore time is exactly where incidents become disasters.
The cyber annexes your BCP needs
To survive a cyberattack, a classic BCP needs a cyber-specific layer. At minimum:
- Offline runbooks. Printed or stored outside the corporate environment: recovery procedures, network diagrams, asset inventories, license keys, and the plan itself. If it only exists on the encrypted file server, it does not exist.
- Out-of-band communications. A channel that does not depend on corporate email, chat or telephony, with pre-agreed contact points. Assume the attacker reads your inbox.
- A pay-or-not decision tree. Decide in advance who is in the room, what legal and sanctions checks apply, what your insurer requires, and what evidence you need before any decision about a ransom demand. Deciding this at 3 a.m. under pressure is how bad calls get made.
- Legal and notification duties. Map your obligations before you need them: Law 25 in Quebec for privacy incidents, NIS2 for essential and important entities in the EU, DORA for financial entities and their ICT providers. Each comes with its own clock and format, and "we were busy recovering" is not a defence.
Test the restore, not the backup
An untested BCP is a hypothesis. Testing runs on a spectrum, and mature organizations climb it deliberately:
- Tabletop exercises: the crisis team walks through a scenario, decisions and communications included. Cheap, revealing, and the right place to start.
- Functional tests: restore specific systems, activate the fallback site, switch to out-of-band communications for a day.
- Full failover: run critical processes on recovery infrastructure, with the primary deliberately offline.
One rule above all: test the restore, not the backup. A green checkmark on last night's backup job proves nothing. Restoring a critical system end to end, onto clean infrastructure, within the stated RTO, proves everything. Time it, document it, and fix what the test breaks.
Continuity is now a board and insurer conversation
BCP is no longer a back-office document. It is a pillar of operational resilience: the organization's demonstrated ability to withstand, adapt to and recover from disruption. Boards are asking for evidence that critical services can survive severe scenarios. Cyber insurers increasingly condition coverage and pricing on tested backups, documented recovery capability and exercise reports. Regulators, from DORA to NIS2, want proof, not policy statements.
The common thread: it is no longer enough to have a plan. You must be able to show that it works.
Where BCPs actually fail
The same failure modes appear in almost every post-incident review:
- The plan was written for auditors. Formally complete, operationally useless, and unknown to the people supposed to execute it.
- Contact lists were stale. Half the names had left the company; the insurer's hotline number was from the previous policy.
- One person held everything. The only admin who knew the backup system was unreachable, and nothing was documented.
- It was never tested against a cyber scenario. The failover worked perfectly, straight into a compromised network.
Each of these is cheap to fix before the incident and ruinous to discover during it.
Where FortaRisks fits
Continuity does not live in a binder; it lives in controls: tested backups, documented recovery procedures, exercised crisis roles, notification readiness. FortaRisks maps these continuity-relevant controls across more than 30 frameworks, including DORA, NIS2 and Law 25, and turns the gaps into a costed, prioritized roadmap in the Compliance module. You see where your continuity posture really stands, what to fix first, and what evidence you can already show a board, an insurer or a regulator.