Business impact analysis and recovery objectives¶
What you'll be able to do in this lesson
- Explain how a business impact analysis turns a disruption into a measured business cost over time.
- Define RTO and RPO, and set them from the business's tolerable disruption (the MTPD).
- Distinguish recovering the systems (disaster recovery) from continuity of the business (Lesson 4.9.B).
From disruption to recovery requirements¶
Every scenario in this Module has imagined an attack succeeding. When one does halt Scaldimet's line, three questions follow: how much does the disruption cost over time, how fast must the systems be recovered, and how much data can be lost? This lesson measures the disruption and sets the recovery requirements.
The measurement is concrete at Scaldimet because a line-halt is not abstract: a stoppage runs straight into the OEM's contractual penalty clauses, which convert downtime into euros per hour. This gives the impact a defensible basis in euros rather than a guess.
The business impact analysis¶
A business impact analysis (BIA) looks at what a disruption would cost the business, and how that impact changes over time. For each critical activity, you ask: if this stops, what happens after one hour, one day, three days or a week?
For Scaldimet, the impact of the production line stopping may be limited at first. But after a certain point, missed just-in-time deliveries trigger penalties and the cost rises sharply. If the disruption continues, the OEM may start qualifying a second supplier, a far more serious business impact. The BIA makes these consequences explicit, and it gives the line-halt scenario from Chapter 4.3 a defensible business basis for its severity rating rather than a guess.
The BIA also names the outer limit: the maximum tolerable period of disruption (MTPD), the point beyond which the harm is no longer acceptable to the business. This is a business judgement and Scaldimet's appetite already states it: "no foreseeable risk of a multi-day production stoppage" (Lessons 2.1 and 6.2). Every recovery objective below must sit inside that limit.
RTO and RPO¶
The BIA feeds two recovery objectives that must be distinguished clearly.
- Recovery Time Objective (RTO): how fast you must restore an activity after a disruption. It answers "how long can we be down?" It must sit below the MTPD. If the OEM penalty exposure becomes significant after, say, three days, the RTO for the line must be well under that. RTO is about time to recover.
- Recovery Point Objective (RPO): how much data (in time) you can afford to lose. It answers "how far back can our last good copy be?" An RPO of one hour means backups no more than an hour apart, or you lose more work than the business can tolerate. RPO is about acceptable data loss.
The two are independent, and both matter. A fast restore (good RTO) from a backup that is a week old (bad RPO) still means losing a week of production data. Frequent backups (good RPO) that take three days to restore (bad RTO) are no better if the business cannot wait that long.
A backup that has never been restored is not evidence that the RTO can be met. An untested backup has an unknown, and usually worse, real recovery time; the check-box trap of Lesson 3.7 applies directly here.
Disaster recovery and business continuity¶
Disaster recovery (DR) is the technical capability and process for restoring systems and data to meet the required RTO and RPO.
The division of responsibility is important. The business owns the BIA: the process owners decide what is critical and how long its loss is tolerable (the MTPD). The first line then designs DR (backups, redundancy, recovery procedures) to meet the RTO and RPO those requirements imply. And where the achievable recovery is slower than the required RTO, the gap goes back to the business to close: by investment, by acceptance, or by a workaround. That iteration between the business and the technical first line is central to continuity, and it is the subject of Lesson 4.9.B, along with what the business does while the systems are down and when they cannot be recovered in time at all.
Closing the loop¶
The recovery requirements tie the whole Module together. The scenario (Chapter 4.4) describes how the line stops; the BIA measures the business impact over time and fixes the MTPD; the RTO and RPO set how fast and how completely the systems must be recovered; and those objectives size the recovery controls in the treatment plan (Chapter 4.6) and the register (Chapter 4.7), linked back to the Module 3 applied controls. Recovery therefore connects the disruption scenario to the business impact considered by the board (Module 6). But recovering the systems is not the same as keeping the business running, which is why the loop is only complete with Lesson 4.9.B.
Scaldimet's line-halt, in recovery terms
The operational scenario stops Beta's line. The BIA shows the impact increasing significantly as OEM just-in-time deliveries are missed and penalty clauses are triggered. The MTPD is therefore short. The analysis leads to an RTO that requires recovery before the penalty threshold and an RPO that limits the loss of production and configuration data. Those objectives size the disaster-recovery work: tested backups of OT configurations, a rehearsed recovery procedure, and enough redundancy to meet the RTO. The recovery side is only half the treatment; the business side follows in Lesson 4.9.B.
Application: a mini BIA and recovery objectives¶
On paper, take Scaldimet's line-halt scenario and sketch its BIA: the impact at one hour, one day and three days, marking where the OEM penalties trigger and naming the MTPD. Then set a defensible RTO and RPO for the line, and write one sentence each on what control that objective forces. Check that your RTO sits comfortably below the MTPD; if it does not, the recovery plan does not actually protect the business.
Model answer (open after you've drafted yours)
BIA (line-halt impact over time):
-
1 hour — minor: buffer stock and work-in-progress absorb it; no delivery effect.
-
1 day — moderate: the schedule slips, overtime recovers it; still inside the delivery margin.
-
3 days — severe: the OEM delivery is missed, the penalty clause triggers, and customer trust is damaged.
The impact increases significantly between day 1 and day 3 as the penalty and supplier-qualification consequences emerge.
MTPD: the 3-day penalty-and-qualification threshold, which Scaldimet's appetite already implies ("no multi-day stoppage"). Every recovery objective must sit below it.
Objectives: RTO = 24 hours (restore the line well before the 3-day threshold); RPO = 1 hour for the control and recipe data (little production data lost on recovery).
What each requires: the RTO requires a rehearsed and sufficiently fast recovery process, including known-good controller images and a tested runbook rather than merely the existence of backups; the RPO requires frequent and tested backups of OT configuration and data.
Check: a 24-hour RTO sits comfortably below the 3-day MTPD, so the plan protects the business. If the realistic RTO were four days, it would breach the MTPD, and that gap is exactly what Lesson 4.9.B and the treatment in Chapter 4.6 must resolve.
Key takeaway
A business impact analysis maps how a disruption's impact changes over time and establishes the MTPD, the maximum period of disruption the business can tolerate. It provides the basis for two recovery objectives: RTO (how quickly the activity must be recovered) and RPO (how much data, measured in time, can be lost). Both objectives must be consistent with the MTPD and determine the recovery controls required. Disaster recovery is the technical recovery of systems and data to meet these objectives. The business owns the BIA and the MTPD; the first line designs and operates recovery measures to meet the required objectives; and any gap between the required and achievable RTO becomes a business continuity issue (Lesson 4.9.B).
Next: Lesson 4.9.B · Business continuity — operating through the disruption →