Glossary

Business impact analysis (BIA)

A business impact analysis (BIA) is a structured assessment of how the disruption of each business process, and of the systems supporting it, affects an organization as the disruption lengthens. Its outputs are recovery priorities and the recovery objectives that continuity and disaster recovery arrangements are built to meet.

Why a BIA matters

The BIA produces the numbers that infrastructure is built to. Recovery time and recovery point targets, the order in which systems come back and the tier each dataset belongs to all trace back to it. Without one, every application owner describes their system as critical, every system ends up in the top recovery tier, and the cost of resilience grows with the size of the estate rather than with what the business actually needs.

It also separates two questions that are easy to blur: how long a process can be stopped, and how much recent data it can lose. The answers often differ, and each drives a different part of the design.

How a BIA is carried out

NIST SP 800-34 describes three steps for an information-system BIA:

  1. Determine processes and recovery criticality: identify the processes each system supports, assess the impact of their disruption and set outage tolerances.
  2. Identify resource requirements: list the hardware, software, data, facilities and people needed to resume each process.
  3. Identify recovery priorities: rank system resources by the criticality of the processes they support.

Information is gathered through questionnaires and interviews with process owners, then reconciled across departments so ratings are consistent. Impacts are rated across several dimensions: financial, operational, legal and regulatory, customer and reputational, and health and safety. A process is ranked by its highest rating, so one with modest revenue exposure but a regulatory filing deadline can outrank one with higher revenue at stake.

Impact over time and recovery objectives

Impact is assessed at fixed intervals, such as one hour, four hours, one day, three days and one week, because most consequences escalate with duration. The interval at which impact becomes unacceptable sets the maximum tolerable downtime (MTD) for the process. Two further values follow:

  • Recovery time objective (RTO): the longest a supporting system can be unavailable. It sits inside the MTD, leaving time to verify recovered systems and clear backlogs. With an MTD of 24 hours and 8 hours of verification and backlog, the system's RTO is at most 24 − 8 = 16 hours.
  • Recovery point objective (RPO): how much recent data the process can lose or re-enter. A reporting system can tolerate days of downtime and minutes of data loss; a cache the reverse.

Dependencies then convert process objectives into system objectives. A shared service inherits the strictest target among the processes that rely on it, so a directory service or a shared storage platform can end up with a tighter RTO than any single application it serves.

What a BIA means for storage architects

BIA results usually collapse into three or four recovery tiers, and each tier maps to a storage protection pattern with a very different price. The top tier may justify synchronous replication across sites; the middle tier asynchronous replication with point-in-time copies; the lowest tier backup and restore. The data volume in each tier is what turns those patterns into cost. If 5% of a 10 PB estate is tier 1, synchronous multi-site protection applies to 500 TB; if a loose analysis puts 40% there, it applies to 4 PB, with the matching hardware, network and power at a second site.

Shared platforms deserve particular attention. An object store holding data for many applications carries the highest tier among them unless data is separated into classes with their own protection, and that separation is far easier to plan than to retrofit at petabyte scale.

New workloads change the answers. An AI pipeline that turns document collections into a retrieval service, or a data lake that becomes an input to regulated reporting, can move data from the bottom tier to the top without any change to the storage itself. A BIA describes the organization at the time it was carried out, so its value to infrastructure depends on being repeated when processes, systems or obligations change, and on its results reaching the disaster recovery plan.

BIA tiers and Scality RING storage classes

In Scality RING, erasure coding schemes are defined per storage class, so data from different recovery tiers can sit in classes with different protection levels on the same platform. Retention for each tier can be enforced with S3 Object Lock in governance or compliance mode, and data in the tier with the shortest outage tolerance can be held on a stretched RING running synchronously across sites within 10 Gb/s or greater bandwidth and under 5 ms latency. Tiering decisions made in the BIA can therefore be expressed as placement and protection settings within one RING.