Business Impact Analysis

What is a Business Impact Analysis?

A Business Impact Analysis (BIA) is a structured analysis that determines, for each business process, how the damage from a disruption grows over time, how long an outage can be tolerated at most, and which systems, people and suppliers are needed to restore the process. The BIA is the quantitative foundation of Business Continuity and part of Risk Management: it delivers the recovery objectives RTO and RPO, the priorities for recovery and the dependencies on which continuity plans are built.

In OT environments, a BIA helps rank systems such as SCADA, PLCs, DCS, MES and their supporting infrastructure by their role in production, safety and the environment. Unlike the office environment, the question is not only about data but also about process safety, product quality and the time needed to restart a plant safely.

🧠 What does a Business Impact Analysis deliver?

A BIA does not ask how likely a disruption is, but what happens if a process fails. The result is a set of key figures per process, which together frame Disaster Recovery, the Backup policy and Incident Response.

The order matters: first the MTPD, then the RTO with sufficient margin. If a process must run again after 48 hours and restarting the plant itself takes 12 hours, system recovery must not take longer than 36 hours. That calculation makes the BIA concrete and testable.

🔧 How do you carry out a Business Impact Analysis?

ISO 22301:2019 (clause 8.2.2) specifies what a BIA must deliver, ISO/TS 22317:2021 gives guidelines for carrying it out, and NIST SP 800-34 Rev. 1 (2010) describes a similar approach in three steps: determine business processes and their recovery criticality, identify resource requirements, and set recovery priorities. In practice this comes down to the following steps:

1. Define scope and impact criteria - decide which sites and processes are included and which impact categories you use, such as safety, environment, production, quality, finance, legal and regulatory, and reputation. Define what “limited”, “serious” and “unacceptable” mean for each category.
2. Inventory processes and activities - start from the products and services you deliver and work back to the processes behind them, such as batch production, power supply, cooling or water treatment.
3. Assess the impact over time - estimate the damage per process after, for example, 1 hour, 4 hours, 24 hours, 72 hours and one week. The point at which the damage becomes unacceptable is the MTPD.
4. Map dependencies and resources - link each process to HMIs, an Engineering Station, IO modules, network components such as a Switch, staff, spare parts and external parties. An up-to-date Asset Inventory is indispensable here.
5. Set recovery objectives and priorities - RTO, RPO and MBCO per process, plus the order in which systems come back.
6. Have top management endorse the outcome - the BIA drives investment in redundancy and fallback sites, so the choices belong to management, not just to IT or OT.
7. Repeat periodically - at least annually and after every major change to the plant, the organisation or the supply chain.

The most common format is a series of interviews or workshops with process owners, operators and maintenance staff, supplemented with data from failure records and production planning.

🏭 What does a BIA look like in an OT environment?

In a factory or utility, the impact categories are weighted differently than in an office. An hour without email is a nuisance; an hour without a cooling system in a chemical plant can become a safety incident. An OT BIA therefore looks at:

• Process safety and environment - which failures are caught by the SIS and which are not? A safe shutdown following the fail-safe principle is often the starting point, but that also has a cost.
• Process type - in continuous processes a restart can take days; in a batch process an interrupted batch may be lost.
• Manual operation as a fallback - can the plant keep running locally or manually, and have the procedures been exercised?
• Restoring configurations - the RPO applies not only to data but also to PLC programs, recipes and DCS configurations.
• External dependencies - suppliers with remote access, licence servers, Cloud services and spare parts with long lead times. See also Supply Chain Risk.

A simplified example for a food plant shows what the outcome looks like. The values are illustrative and differ from company to company:

A table like this makes choices visible: an RPO of 15 minutes for the historian requires replication or frequent backups, while an RTO of 2 hours for the cold store requires spare equipment or a manual emergency procedure.

🔄 What is the difference between a BIA and a risk assessment?

The BIA and the risk assessment complement each other. The BIA looks at the consequences of an outage regardless of its cause; the risk assessment looks at threats, vulnerabilities and the likelihood that they lead to an incident.

IEC 62443-3-2 contains a similar idea: the initial risk assessment (ZCR 2) looks at the worst-case consequences if a system is compromised, before likelihood is taken into account. A good BIA already supplies those consequences and prevents zones and security levels from being chosen on gut feeling.

🔐 What role does the BIA play in cybersecurity and regulation?

Without a BIA, the context for prioritising security measures is missing and cybersecurity becomes a collection of loose controls. The BIA shows which OT Assets need the strongest protection, where Defense in Depth needs extra layers, and which scenarios belong in an Incident Response Plan or a tabletop exercise.

• NIS2 and the Dutch Cybersecurity Act - NIS2 Article 21(2)(c) requires business continuity, such as backup management, disaster recovery and crisis management. In the Netherlands, Article 9 of the Cybersecurity Decree elaborates this; both have applied since 15 August 2026. The term BIA does not appear literally, but without an impact analysis recovery times and backup intervals cannot be justified.
• ISO 27001 - controls A.5.29 (information security during disruption) and A.5.30 (ICT readiness for business continuity, new in the 2022 edition) assume recovery objectives derived from a BIA, which helps demonstrate compliance.
• IEC 62443 - the consequences from the BIA feed the risk assessment and the choice of target security levels per zone.
• Wwke and BIO - the Dutch Critical Entities Resilience Act (Wwke) requires critical entities to carry out a risk assessment and take resilience measures for their essential services. BIO2, the Dutch government security baseline, builds on ISO 27002:2022, including the control for ICT readiness for business continuity. In both cases a BIA supplies the consequences and recovery times on which those choices rest.

Ransomware makes the importance concrete. At Colonial Pipeline (May 2021), only the IT network was hit, yet the pipeline was shut down as a precaution for six days, partly because without the affected IT systems, including billing, the company could not properly manage deliveries. A BIA that exposes such dependencies in advance also guides immutable backups and realistic recovery tests.

❓ Frequently asked questions

How often should a Business Impact Analysis be repeated?

A Business Impact Analysis is commonly reviewed at least once a year. A review is also needed after major changes, such as a new production line, a migration of the control system or a new critical supplier. ISO 22301 does not prescribe a fixed frequency, but requires the BIA to be reviewed at planned intervals and when significant changes occur.

Who should be involved in a BIA?

A BIA needs process owners, operators, maintenance, OT and IT administrators, quality and safety staff at the table. Only they know the real consequences of an outage and the existing emergency procedures. Top management endorses the outcome, because it determines where the organisation invests in continuity.

What is the difference between MTPD and RTO?

The MTPD is the maximum duration of a disruption before its consequences become unacceptable. The RTO is the target time for recovery and must always be shorter than the MTPD, leaving margin for start-up, quality checks and unforeseen problems. A BIA records both for each process.

Is a Business Impact Analysis mandatory under NIS2?

NIS2 and the Dutch Cybersecurity Act do not name the BIA explicitly, but they do require business continuity, backup management and disaster recovery. In practice, a BIA is the usual way to show that recovery times and backup intervals match the critical processes. Supervisors and auditors therefore often ask how RTOs and RPOs were justified.

Can I use an IT BIA template for OT?

An IT template for a Business Impact Analysis is a good starting point, but it usually lacks the categories of process safety, environment and product quality. In OT, the start-up time of the plant and the availability of manual operation must also be considered. Extend the template with OT-specific impact criteria and dependencies.

How does a BIA relate to a disaster recovery plan?

The Business Impact Analysis determines what must be restored, in which order and within what time. The disaster recovery plan describes how that is done technically, with backups, fallback sites and recovery procedures. Without a BIA, a disaster recovery plan is a technical exercise without justified priorities.

📌 In summary

A Business Impact Analysis translates “what if this fails?” into hard figures per process: MTPD, RTO, RPO and MBCO, together with the dependencies that make recovery possible. In OT, the BIA weighs safety, environment and start-up time alongside financial damage, and it forms the basis for continuity plans, backup policy, investment in redundancy and the priorities of cybersecurity measures.

A Business Impact Analysis determines for each process how long an outage is acceptable and how quickly recovery must happen, so that continuity and security measures focus on what really matters.