Business impact analysis for IT: from downtime impact to MTD, RTO, RPO and recovery tiers

What a business impact analysis for IT produces

A business impact analysis (BIA) for IT links each business process to the systems it runs on and measures how the damage grows while the process is down. From that it derives a maximum tolerable downtime per process, a recovery time objective (RTO) and recovery point objective (RPO) per system, and the order in which systems come back. Grouped by target, these become the recovery tiers of the disaster recovery design.

The method here follows section 3.2 of NIST Special Publication 800-34 Revision 1, the Contingency Planning Guide for Federal Information Systems, whose Appendix B holds a sample BIA and a template. The guide, updated in November 2010, is still final on NIST’s site in October 2026. NIST wrote it for US federal systems, which start from their FIPS 199 availability category; a company uses its own impact scale. ENISA’s Technical Implementation Guidance (version 1.0, June 2025) for the NIS2 implementing regulation points to the same guide and to ISO/TS 22317:2021, the ISO guidelines for business impact analysis. The definitions of RPO and RTO and their cost curve are in our guide on how to set RPO and RTO for each system.

The three BIA steps in NIST SP 800-34 Rev. 1

Section 3.2 names three steps, and a BIA document can follow the same structure:

1. Determine mission/business processes and recovery criticality, with their “outage impacts and estimated downtime”; the downtime “should reflect the maximum time that an organization can tolerate while still maintaining the mission.”
2. Identify resource requirements, with NIST’s examples “facilities, personnel, equipment, software, data files, system components, and vital records”.
3. Identify recovery priorities for system resources, “the last step of the BIA process”, whose result is “an information system recovery priority hierarchy.”

NIST runs the steps from one information system outwards. Company-wide, run the first step per business process with its owners, then map processes to systems and set priorities per system, so owners are not asked the same questions for every system. The BIA measures consequences and leaves likelihood to the risk assessment, and ENISA bases the recovery objectives on the results of both.

BIA interview questions for process owners

NIST has the coordinator determine the acceptable downtime “with the process owners, leadership and business managers”, so the input comes from interviews with the people who run each process, with IT present to translate answers into systems. Record the answers per process in one format; the output column lists the fields a BIA template needs.

Structure after the BIA steps in NIST SP 800-34 Rev. 1, section 3.2; the questions and outputs are our suggestion.

Impact categories and impact over time

NIST leaves the scale to the organisation: impacts “can be expressed in values or units of measurement that are meaningful to the organization”, as in its example category Costs, “with impact values expressed in terms of staffing, overtime, or fee-related costs.” We suggest five or six categories: financial loss, customers and contracts, legal and regulatory duties, operations, health and safety where relevant, and reputation. Management defines beforehand what minor, moderate and severe mean in each, as amounts, customers affected or days of backlog.

Rate each process at fixed points after the outage begins, such as 1 hour, 4 hours, 1 day, 3 days and 1 week, at the worst plausible time in its calendar of critical periods. NIST states the reason in its cost-balancing discussion: “The longer a disruption is allowed to continue, the more costly it can become to the organization and its operations.” The first point at which any category reaches severe sets an upper bound, and the process owner places the maximum tolerable downtime between it and the point before, or at an earlier hard deadline from the interviews. Each severe rating should name its source, such as a contract clause, so that departments rate alike.

Maximum tolerable downtime (MTD), MTPD, RTO and RPO

The maximum tolerable downtime belongs to the business process. NIST’s glossary defines it as “The amount of time mission/business process can be disrupted without causing significant harm to the organization’s mission”, and section 3.2.1 adds that it “includes all impact considerations.” The RTO belongs to a system resource, and “Because the RTO must ensure that the MTD is not exceeded, the RTO must normally be shorter than the MTD.” NIST’s example is reprocessing, whose time “must be added to the RTO to stay within the time limit established by the MTD”.

ENISA’s guidance calls the business-side limit maximum acceptable outage (MAO) or maximum tolerable period of disruption (MTPD), “the time it would take for the potential impacts of not providing a product/service or performing an activity to become unacceptable or significant”, and adds: “Typically they are longer than RTOs.” Its service delivery objective (SDO), “the minimum level of performance that needs to be reached by business functions during the alternate processing mode”, is where the workaround answers belong.

NIST keeps the RPO outside this clock (“Unlike RTO, RPO is not considered as part of MTD”) and ties it to “how much data loss the mission/business process can tolerate during the recovery process.” The redo question answers it, and the same answer decides when a shorter RPO is worth paying for: when the work lost or re-entered in the gap outweighs the cost of copying more often.

Dependency mapping from process to infrastructure

The second step turns each process into resources, in more layers than the process owner sees. We suggest mapping five layers: applications with their databases and interfaces; the platform, meaning hypervisors, storage, backup system and management plane; shared services such as the directory service, DNS, certificate authority, time sources and licence servers; the network, from core switches and firewalls to WAN links and remote access; and external services such as SaaS, payment or EDI providers. Inventory, monitoring and firewall flow data and the application owners’ interface lists are the usual sources.

For each system that needs a dependency, subtract the time needed to restore and start that system on top of it from the system’s RTO; the smallest result is the dependency’s RTO. Among ENISA’s criteria for the order of recovery are “dependencies (services or assets that are essential for others are restored first)”. That puts infrastructure that no process owner names in the top tier, together with the backup and replication system, since every restore waits for it. External services are restored by their providers, so record each provider’s recovery commitment from the contract; one longer than the RTO the map gives that service is a gap to close in the contract or with a workaround.

Worked example: three processes, from impact to recovery tiers

Take an invented distributor with 900 staff, one data centre and a virtualised estate, after interviews on three processes.

Invented example; the ratings at 4 hours and 3 days are omitted.

Order to shipment sets the shortest limit, because after 8 hours the day’s truck departures are missed and the penalty clauses apply. Re-entering phone orders and checking stock take about 2 hours after the restore, which leaves the ERP and warehouse management system an RTO of 6 hours. Restoring and starting the ERP takes about 3 hours once the directory service, DNS, network, hypervisors, storage and backup system run, so these get 3 hours. Payroll is rated at its worst timing, and its application gets 16 hours, leaving a working day for the pay run. The RPOs follow the redo answers, since stock movements lost beyond 30 minutes would need a physical count, payroll inputs can be re-entered from the time recording system and the designers accept losing half a day of work.

Invented example; RTOs are kept shorter than the MTD, as NIST SP 800-34 Rev. 1 says they normally must be. Tier 1 means an RTO up to 8 hours, tier 2 up to 2 days. These are not targets of our service.

On a first call, free of charge, we work through your critical systems, current backup and target RPO and RTO, and you leave with two or three possible DR scenarios. Send us your critical processes and the systems behind them.

From the tier list to the DR design and runbooks

Each tier gets a recovery strategy matched to its RTO and RPO, from restores out of backup copies to replicas waiting at a warm or hot site, as compared in our guide to hot, warm and cold DR sites. The steps for each system go into a disaster recovery runbook, timed against the tier RTO in each disaster recovery test. When a test misses its target, check the BIA as well as the technology, because a component may be missing from the dependency map.

Our disaster recovery service runs regular failover tests in an isolated environment, with a report after each one on what came up, how fast and what to fix. Tell us which tier you would test first and how it is restored today.

Business impact analysis under NIS2, and when to repeat it

The NIS2 Directive requires business continuity measures in Article 21(2)(c) without naming a BIA. For the providers listed in Article 1 of Commission Implementing Regulation (EU) 2024/2690, among them cloud computing, data centre and managed service providers, point 4.1.3 of the Annex requires them to “carry out a business impact analysis to assess the potential impact of severe disruptions to their business operations” and to base continuity requirements for network and information systems on it. ENISA’s non-binding guidance says its indications “may be considered useful by other public or private bodies”, and for the plan it names ISO 22301:2019 among the standards to take into account. Our guide to NIS2 backup and business continuity requirements covers the rest of points 4.1 and 4.2. Which text binds your company is a legal assessment for your legal department.

Point 4.1.4 requires the plans to be tested and reviewed at planned intervals and after significant incidents or changes, and ENISA’s guidance advises doing so at least annually. NIST notes that as a system’s design evolves during development, “the BIA may need to be conducted again”. Repeat it with each plan review and whenever a new core application, a migration, a new customer contract or a reorganisation changes who depends on what.

What we do

In the DR strategy design of our disaster recovery service, we define together with you the critical systems, target RPO and RTO for each tier of systems and the disaster scenarios you protect against; the output is a continuity plan, not just copies. Our engineering partner Vixen.UNO then sets up replication on Veeam technology to a recovery site in Baltneta’s Tier-3 data centres in Lithuania (ISO 27001, PCI DSS), runs scheduled test restores and provides support, with RPO and RTO fixed in the SLA. The price of the technical assessment is fixed before work begins. Eurokommerz holds the contract, so site, replication, tests and support come under one agreement.

FAQ