Business continuity — operating through the disruption¶
What you'll be able to do in this lesson
- Tell disaster recovery (restoring systems) from business continuity (keeping the business running).
- Set a minimum business continuity objective and sketch how Scaldimet operates below it.
- Say what happens when the RTO cannot be met, and who owns each part of the plan.
Recovery is not continuity¶
Lesson 4.9.A sized how fast Scaldimet must restore its systems (RTO) and how little data it can lose (RPO). Meeting those objectives is disaster recovery: the first line's technical work of bringing systems and data back.
Business continuity is the wider question the business itself must answer: while the line is down, and even if it comes back slower than the RTO demands, how does Scaldimet continue serving the OEM during the disruption? Disaster recovery restores the line; business continuity keeps the business operating during the outage. Restoring a system does not by itself let the business deliver: without a continuity plan, an organisation can bring systems back and still be unable to ship.
The minimum level of operation¶
Continuity does not aim to run everything as normal; it aims to maintain a defined minimum level of operation. The minimum business continuity objective (MBCO) is the lowest level of delivery the business will accept during a disruption. For Scaldimet, an MBCO might be: keep the OEM supplied from buffer stock and partial manual operation, keep order intake and payroll running, and protect safety at all times. Everything above the MBCO can wait; everything at or below it needs a plan that does not depend on the failed systems.
Operating through the disruption¶
The business continuity plan defines how the business continues operating during the disruption. It is not a technical recovery plan. Measures may include running critical steps manually, drawing down buffer stock, shifting work to an alternate line, site or subcontractor, and communicating early with the OEM. These decisions belong to operations and commercial leaders and should be prepared in advance rather than improvised during the incident.
For operational technology, safety imposes an additional constraint: safety leads. A halted line is often safer than a line coerced back into a partial or unverified state, so continuity for OT sometimes means staying down deliberately until a safe, verified restart is possible. Continuity does not trade safety for uptime.
When the RTO cannot be met¶
If the realistic recovery is slower than the RTO (e.g. the 24-hour target turns out to be four days) disaster recovery alone does not meet the business requirement, and continuity addresses the gap: operate at the MBCO for longer, invoke the alternates, and manage the OEM relationship and any penalties as part of the continuity response.
Some impacts cannot be reversed through recovery. The design-data exfiltration risk from Chapter 4.4 has no RTO or RPO, because confidentiality cannot be restored once the data has been disclosed. The response instead consists of incident response, legal and contractual notification (including the NIS2 reporting requirements in Lesson 3.4), and damage limitation with the customer. That is a business-and-legal response, with no system to bring back. Recognising which risks can be recovered and which can only be contained is itself a continuity decision.
Who owns what: the business and the first line, together¶
The continuity plan should not be treated as a CISO-owned document. In the three-lines model (Lesson 2.2), the business process owners are first line for their processes: they own the BIA inputs, the MTPD and the continuity plan. IT and OT are first line for their systems: they own disaster recovery. The CISO is second line: facilitate, challenge the assumptions, and assure that the plan is workable and maintained. The board (Lesson 6.2) sets the appetite that sets the organisation's tolerance for disruption. This requires iteration across the first line: the business states the RTO it needs; IT and OT state the RTO they can actually achieve; the gap is then closed by investment, by a business workaround at the MBCO, or by a documented, accepted residual. The continuity plan records these requirements, capabilities, decisions and named owners, using the same ownership discipline as the risk register.
Preparing: invocation and exercising¶
An unexercised continuity plan has untested assumptions, just as an unrestored backup has an untested recovery process. Preparation means agreeing the invocation trigger (who declares an incident and starts the plan), the roles and the communications (to the OEM, staff, authorities), and then exercising it — a tabletop walk-through of the line-halt scenario with operations, IT/OT and the CISO in the room. A continuity exercise serves a similar purpose to a backup restoration test: it identifies gaps while they can still be addressed. The NIS2 reporting clock (Lesson 3.4) runs in parallel during a real invocation, so the two procedures should be rehearsed together.
Application: Scaldimet's continuity plan for the line-halt¶
On paper: state Scaldimet's MBCO for a multi-day OT outage; list three business-side moves that keep it at or above the MBCO without the failed systems; then handle the hard case — the realistic recovery is four days but the RTO was 24 hours — and say who owns each part.
Model answer (open after you've drafted yours)
MBCO: keep the OEM supplied at a reduced rate from buffer stock; maintain order intake and payroll on unaffected IT; preserve safety at Beta throughout.
Three business-side moves: (1) release buffer stock and re-sequence deliveries to protect the OEM first; (2) run the most critical production steps manually where the process and safety permit, or shift them to the Alpha-side capacity if feasible; (3) notify the OEM promptly, provide the expected delay and recovery plan, and agree the revised delivery arrangements.
When the RTO cannot be met (4 days vs 24 hours): The achievable recovery time exceeds the RTO, so business continuity measures must support the MBCO for the full four days. Invoke the workarounds above, and manage the penalty exposure and OEM relationship deliberately. The gap between the 24-hour need and the 4-day reality then becomes a treatment decision back in Chapter 4.6: invest to shorten recovery, or accept the residual with the board (severity 4), or both.
Ownership: BIA/MTPD and the continuity plan — the Beta operations director (business process owner, first line); disaster recovery of the OT — IT/OT (first line); OEM communication — commercial leadership; facilitation and assurance — the CISO (second line); appetite — the board.
Key takeaway
Disaster recovery restores systems to meet the required RTO and RPO; business continuity keeps the business operating during the disruption and when recovery cannot meet the RTO. It is based on a minimum business continuity objective, the minimum level of operation the business must maintain, supported by business measures such as manual operation, buffer stock, alternate capacity and early OEM communication, with safety leading in OT. When the RTO cannot be met, continuity addresses the gap and the shortfall becomes a treatment decision. The plan is owned across the first line: process owners own the BIA and continuity plan, while IT and OT own system recovery. The CISO facilitates and provides second-line challenge and assurance, and the board sets the risk appetite and tolerable disruption. The plan should be regularly exercised so that gaps can be identified and addressed.