Business impact analysis (BIA)

A business impact analysis is deliberately cause-agnostic: it does not ask what might go wrong or how likely it is, only what happens to each activity when it stops and how that damage grows over time. That is the line between a BIA and a risk assessment, which pairs threats and vulnerabilities with likelihood. ISO 22301:2019 clause 8.2.2 requires the organisation to define impact types and criteria, identify the activities that deliver its products and services, assess impacts over time, set prioritised time frames for resuming each activity, and identify the dependencies and resources behind them, including suppliers. ISO/TS 22317:2021 gives detailed guidance; NIST SP 800-34 Rev. 1 describes a system-level BIA for contingency planning.

The core outputs are time parameters. The maximum tolerable period of disruption (MTPD in ISO terms, MTD in NIST SP 800-34) is the point after which impact becomes unacceptable. The recovery time objective (RTO) is the target for resuming an activity or restoring a system and must sit inside the MTPD with margin; the recovery point objective (RPO) is the maximum acceptable data loss expressed as time, which drives backup and replication frequency. ISO also uses the minimum business continuity objective (MBCO), the reduced service level acceptable during disruption. The chain must be consistent: an activity with a four-hour RTO cannot rest on a system restored in 24 hours or a supplier with next-business-day support.

BIAs are usually run as interviews or questionnaires with process owners, scoring impact categories (financial, customer, legal and regulatory, reputational, health and safety) at time points such as 1 hour, 4 hours, 1 day, 3 days and 1 week. Impact curves are rarely linear: payroll is harmless for days and then critical just before pay day, so peak periods must be captured. Dependency mapping then walks from activities to applications, data, infrastructure, people, sites and third parties, which is where hidden single points of failure such as a shared identity provider surface.

Typical failure modes are owners declaring every process critical with an RTO of zero, IT-led BIAs that list systems instead of business activities, RTOs never compared with actual recovery capability, and analyses not refreshed after reorganisations or SaaS migrations. Regulation now names the BIA explicitly: DORA (Regulation (EU) 2022/2554) Art. 11(5) requires financial entities to conduct a BIA of their exposure to severe business disruptions, and NIS2 Art. 21(2)(c) requires business continuity and disaster recovery measures for which a BIA is the practical basis.