Business impact analysis and recovery priorities

Recovery planning starts with a simple question that is surprisingly hard to answer: if this stopped working, how long could the organization survive without it, and what would it cost? An organization cannot recover everything at once after a major disruption, and it cannot afford to make everything instantly recoverable. The business impact analysis (BIA) is the structured way of answering the question so that recovery investment and recovery order follow business priorities rather than the loudest voice or the newest system.

The CISSP outline addresses recovery in sub-domains 7.10 (implement recovery strategies), 7.11 (implement disaster recovery processes), 7.12 (test disaster recovery plans) and 7.13 (participate in business continuity planning and exercises). CISSP-111 introduced business continuity as part of security governance. This lesson goes deeper into the BIA and the recovery objectives it produces; Lesson 10 covers backup and resilience strategies; Lesson 11 covers disaster recovery sites, plans and testing. The standards most often cited are ISO 22301, the international standard for business continuity management systems, its companion guidance ISO/TS 22317 on the BIA, and NIST SP 800-34 Revision 1, the contingency planning guide for information systems.

Continuity planning in context

Business continuity management (BCM) is the organization-wide capability to keep delivering products and services at acceptable levels during a disruption. Disaster recovery (DR) is the technology part of that capability: restoring IT systems, data and infrastructure. Crisis management deals with leadership, decision making and communication during a major event. Incident response, covered in Lessons 5 and 6, handles security incidents, which may themselves trigger continuity or DR plans; a ransomware attack that takes down core systems is both a security incident and a continuity event.

ISO 22301 sets out a management system for BCM using the Plan-Do-Check-Act cycle: understand the organization and its context, obtain leadership commitment, plan, carry out the BIA and risk assessment, develop continuity strategies and plans, exercise and test them, evaluate performance and improve. NIST SP 800-34 Revision 1 sets out a seven-step contingency planning process for information systems: develop the policy; conduct the BIA; identify preventive controls; create recovery strategies; develop the contingency plan; plan testing, training and exercises; and maintain the plan.

The business impact analysis

A BIA identifies the organization's activities, the resources they depend on, and the impact of disrupting them over time. It is primarily a business exercise: interviews and workshops with process owners, supported by data on revenue, contracts, regulatory duties and dependencies. It asks, for each activity: what happens if this stops for an hour, a day, a week; what legal, contractual, financial, safety and reputational consequences arise; what people, systems, data, suppliers and facilities are needed; and how long the activity could be performed by workaround.

The key output of the BIA is a set of time-based measures for each activity and the resources behind it. The maximum tolerable downtime (MTD), also called the maximum tolerable period of disruption (MTPD) in ISO terminology, is the longest an activity can be unavailable before the impact becomes unacceptable to the organization. The recovery time objective (RTO) is the target time for restoring an activity or system after a disruption, and must be shorter than the MTD to leave a margin for verifying and resuming work. The recovery point objective (RPO) is the maximum acceptable amount of data loss, measured in time: an RPO of four hours means the organization can tolerate losing at most four hours of transactions. Work recovery time (WRT) is the time needed after systems are restored to verify data, catch up on backlogs and resume normal work.

The relationship RTO + WRT less than or equal to MTD is a classic exam point. If an order system's MTD is 24 hours and it takes six hours after restoration to reconcile orders and clear the backlog, the RTO for the system cannot exceed 18 hours. Setting an RTO equal to the MTD leaves no time for the work that has to happen after the technology comes back.

# Derive recovery objectives from BIA interview data (synthetic)
activities = [
    # name, impact per hour ($), hours until impact becomes unacceptable (MTD), work recovery hours, tolerable data loss (h)
    ('Online ordering', 18000, 12, 2, 0.25),
    ('Payroll processing', 400, 72, 8, 24),
    ('Customer support line', 3500, 24, 1, 4),
    ('Warehouse dispatch', 9000, 24, 4, 1),
    ('Internal wiki', 50, 336, 2, 24),
    ('Regulatory reporting', 1200, 120, 16, 24),
]
print(f'{"activity":22s} {"MTD":>5s} {"WRT":>5s} {"max RTO":>8s} {"RPO":>6s} {"loss at MTD":>12s}')
for name, cost_h, mtd, wrt, rpo in activities:
    rto = mtd - wrt
    print(f'{name:22s} {mtd:4d}h {wrt:4d}h {rto:7d}h {rpo:5.2f}h ${cost_h * mtd:>11,.0f}')

activity                 MTD   WRT  max RTO    RPO  loss at MTD
Online ordering          12h    2h      10h  0.25h $    216,000
Payroll processing       72h    8h      64h 24.00h $     28,800
Customer support line    24h    1h      23h  4.00h $     84,000
Warehouse dispatch       24h    4h      20h  1.00h $    216,000
Internal wiki           336h    2h     334h 24.00h $     16,800
Regulatory reporting    120h   16h     104h 24.00h $    144,000

The table shows why RPO and RTO are set separately. Payroll can be unavailable for days but loses little by restoring yesterday's data, while online ordering needs both a short RTO and a near-zero RPO because every lost order is lost revenue and customer trust. Each pair of objectives implies a different recovery strategy and cost, which Lessons 10 and 11 explore.

Dependencies and recovery priority

Activities depend on resources, and resources depend on each other. Online ordering might rely on the web front end, the order database, the payment gateway, the identity service, DNS, the network and a third-party fraud screening service. If the identity service has an RTO of 24 hours, the ordering system cannot meet a 10-hour RTO no matter how quickly its own servers return. A good BIA maps these dependencies so that the RTO of a supporting resource is at least as short as that of the most demanding activity that relies on it.

Recovery priority follows from the BIA. Shared foundations such as network, identity, DNS and backup infrastructure come first because everything else depends on them. Then activities are restored in order of urgency, usually by shortest MTD, while respecting dependencies. Executives should approve the priority list in advance; in a crisis there will be pressure from every department to go first, and an agreed list prevents that argument from consuming recovery time.

import heapq
# Recovery order: a resource can start once its dependencies are restored; among those ready, most urgent (shortest MTD) first
mtd = {'network': 4, 'identity': 6, 'dns': 4, 'backup-platform': 8, 'order-db': 10, 'web-store': 12,
       'fraud-screening-saas': 48, 'dispatch-app': 24, 'phone-system': 24, 'payroll': 72, 'wiki': 336}
deps = {'identity': {'network'}, 'dns': {'network'}, 'backup-platform': {'network'},
        'order-db': {'identity', 'backup-platform'}, 'web-store': {'order-db', 'dns', 'fraud-screening-saas'},
        'dispatch-app': {'order-db'}, 'phone-system': {'network'}, 'payroll': {'identity'}, 'wiki': {'identity'}}
restored, step = set(), 1
ready = [(mtd[k], k) for k in mtd if not deps.get(k)]
heapq.heapify(ready)
while ready:
    m, k = heapq.heappop(ready)
    restored.add(k)
    print(f'{step:2d}. {k} (MTD {m}h)')
    step += 1
    for other in mtd:
        if other not in restored and all(d in restored for d in deps.get(other, ())) and (mtd[other], other) not in ready:
            heapq.heappush(ready, (mtd[other], other))
# Check that every supporting resource is at least as urgent as what depends on it
for k, ds in deps.items():
    for d in sorted(ds):
        if mtd[d] > mtd[k]:
            print(f'WARN {d} MTD {mtd[d]}h exceeds dependent {k} MTD {mtd[k]}h')

 1. network (MTD 4h)
 2. dns (MTD 4h)
 3. identity (MTD 6h)
 4. backup-platform (MTD 8h)
 5. order-db (MTD 10h)
 6. dispatch-app (MTD 24h)
 7. phone-system (MTD 24h)
 8. fraud-screening-saas (MTD 48h)
 9. web-store (MTD 12h)
10. payroll (MTD 72h)
11. wiki (MTD 336h)
WARN fraud-screening-saas MTD 48h exceeds dependent web-store MTD 12h

The dependency check is as important as the order. In the example, the web store cannot return until the third-party fraud screening service does, so its 48-hour objective pushes the store behind dispatch and the phone system and is flagged as a gap to fix with the supplier or with a fallback. A supporting service with a longer recovery objective than the activities that depend on it is a hidden gap that only appears during a real disaster. Common examples are identity platforms, license servers, certificate services and third-party software-as-a-service providers whose own recovery commitments, set out in their contracts and SOC 2 reports, do not match the organization's needs.

Running and maintaining the BIA

A BIA is usually carried out by a continuity coordinator with each business unit, using a consistent questionnaire and impact scale so results can be compared. Results are validated with senior management, who must agree the MTDs because they represent the organization's risk appetite for disruption. The BIA should be reviewed at least annually and whenever there is a significant change, such as a new product, a merger, moving to a cloud service or a new regulatory requirement.

Common difficulties include business owners who rate everything as critical, missing dependencies on suppliers and shadow IT, and BIAs that sit on a shelf. Asking owners to quantify impact over time, and to describe what they would actually do during an outage, produces more realistic answers than asking them to rate criticality. Linking the BIA to budgets, by showing the cost of meeting each RTO, also concentrates minds: short RTOs are expensive, and owners who must justify them become more selective.