Business Continuity

Continuity, disaster recovery and incident response

Business continuity is an organization's ability to keep delivering its critical products and services at an acceptable level during and after a disruption. The disruption does not have to be a cyberattack: a power outage, a flooded building, a pandemic, a bankrupt supplier or the sudden absence of the only person who knows a system can all stop the business. Three related disciplines are often confused:

They work together. During a ransomware attack, incident response contains the attacker; disaster recovery rebuilds servers and restores data; business continuity keeps the customer service desk working on paper in the meantime. Disaster recovery is the IT part of continuity, not a replacement for it.

Business impact analysis

A business impact analysis (BIA) identifies an organization's critical processes, the resources they depend on, and the impact of their disruption over time, and from that determines recovery priorities and targets. It is done with the business, not only with IT: the people who run a process know what happens when it stops. For each process the BIA records:

• What it delivers and to whom: customers, regulators, other processes.
• Dependencies: people and skills, buildings, IT systems, data, suppliers, utilities such as power and water.
• Impact over time: financial loss, legal and contractual consequences, safety, reputation. Impact grows with duration; an hour without billing is harmless, a month is not.

MTD, RTO and RPO

From the impact over time follows the maximum tolerable downtime (MTD): the longest a process can be unavailable before the damage becomes unacceptable for the organization. ISO standards call it the maximum tolerable period of disruption (MTPD). Two recovery targets are then set for the supporting systems, both explained on the backup and recovery page:

• The recovery time objective (RTO): how long restoring may take. It must be shorter than the MTD, with room for detecting the problem and deciding to recover.
• The recovery point objective (RPO): how much data, measured in time, may be lost. It determines how often backups or replication must run.

Deriving recovery priorities

Dependencies change the order of recovery. A telephone system may seem unimportant on its own, but if the fault reporting line depends on it, it must be back within that line's MTD. The program below works through a fake BIA for a small water utility: each supporting system inherits the shortest MTD of the processes that depend on it, and the result is a recovery order.

# Fake business impact analysis for a small water utility.
# MTD = maximum tolerable downtime in hours; needs = what the process depends on.
processes = {
    "Drinking water treatment": {"mtd": 4, "needs": ["Process control network", "Power supply"]},
    "Customer service desk": {"mtd": 24, "needs": ["Telephony", "Customer database"]},
    "Billing": {"mtd": 120, "needs": ["Customer database", "Office network"]},
    "Payroll": {"mtd": 72, "needs": ["Office network"]},
    "Fault reporting line": {"mtd": 8, "needs": ["Telephony"]},
}

# A supporting system must come back before the most urgent process that needs it.
effective = {}
for name, info in processes.items():
    effective[name] = info["mtd"]
    for system in info["needs"]:
        effective[system] = min(effective.get(system, info["mtd"]), info["mtd"])


def recovery_order(item):
    name, hours = item
    # Most urgent first; at equal urgency, dependencies before the processes.
    return (hours, name in processes, name)


print(f"{'Recover in this order':<26} {'MTD':>5}  kind")
for name, hours in sorted(effective.items(), key=recovery_order):
    kind = "process" if name in processes else "dependency"
    print(f"{name:<26} {hours:>4}h  {kind}")

Recover in this order        MTD  kind
Power supply                  4h  dependency
Process control network       4h  dependency
Drinking water treatment      4h  process
Telephony                     8h  dependency
Fault reporting line          8h  process
Customer database            24h  dependency
Customer service desk        24h  process
Office network               72h  dependency
Payroll                      72h  process
Billing                     120h  process

The office network, needed by both payroll (72 hours) and billing (120 hours), gets the stricter 72 hours. Telephony jumps to 8 hours because of the fault line, even though the service desk could wait a day. A real BIA follows longer chains (the customer database itself needs a network, storage and authentication), which is why dependency mapping takes most of the effort.

Continuity strategies

Once the priorities are known, the organization chooses how to meet them. Strategies cover four areas:

• People. Cross-training and documented procedures so that no process depends on one person; deputies for key roles; plans for when many staff are absent at once.
• Sites. Working from home, a second office, or a dedicated recovery site for systems (see the table below).
• Suppliers. Knowing which suppliers are critical, what their own continuity arrangements are, contractual guarantees, and where possible an alternative supplier or a stock of critical materials.
• Manual workarounds. Paper forms, phone trees, printed customer lists and local operation of equipment: slower, but they keep a process alive while IT recovers. They only work if people have practiced them and the paper is up to date.

Alternate sites

Cloud infrastructure has made recovery sites much more accessible: a copy of the environment can wait in another region and be started when needed. The cloud disaster recovery strategies map roughly onto hot, warm and cold; a cloud warm standby recovers much faster than a classic warm site. Whatever the form, a recovery site should be far enough away not to share the same disaster (the same flood plain or power grid), yet reachable for the staff who must work there.

Continuity and disaster recovery plans

The strategies are written down in two related plans. A business continuity plan (BCP) is the documented set of procedures and information for keeping critical business processes running at an acceptable level during a disruption and returning to normal afterward. It names who decides to activate it, which workarounds to use, where people work and how they communicate.

A disaster recovery plan (DRP) is the documented procedure for restoring IT systems, data and infrastructure after a disruption, within the agreed recovery time and recovery point objectives. It is technical and specific: the restore order (which follows the BIA), where backups are, which credentials and installation media are needed, and how to check that a restored system is complete.

Crisis management and communication

A major disruption needs decisions that no procedure can fully script: do we shut down the plant, do we inform the press, do we accept a longer outage to preserve evidence? A crisis management team, usually senior managers with communications, legal and the relevant technical leads, takes those decisions, while operational teams carry out the plans. The plan defines who may activate the team, where it meets (physically or on a channel that does not depend on the affected systems), and how decisions are logged.

Communication is a large part of crisis management. Staff need to know what to do and where to work; customers need honest updates and alternatives; regulators may need formal notifications (see legal notification duties); and in critical infrastructure, municipalities, emergency services or the public may need to be warned. Prepared message templates and a single spokesperson keep the story consistent. Plan for the case where normal channels are gone: if email and telephony are down, how does the crisis team reach anyone?

Testing and exercises

An untested plan contains errors nobody has noticed: a phone number that changed, a backup that cannot be restored, a step that assumes a system that no longer exists. Exercises find them in a safe setting. They range from cheap discussions to real failovers:

A tabletop exercise is a discussion-based exercise in which the people with a role in a plan talk through a realistic scenario to check their decisions, roles and communication, without touching any system. It is the most common exercise because it is cheap and reveals a surprising number of gaps: "who has the supplier's emergency number?", "who can authorize shutting down the website?". Each exercise ends with a short evaluation and a list of improvements, just like the lessons-learned phase of incident response.

Keeping plans current

Organizations change faster than their plans. New systems, reorganizations, a move to the cloud, a new supplier or simply staff turnover make parts of a plan wrong. Plans therefore have an owner, are reviewed at least yearly and after every major change, exercise or real incident, and have a version and date on every copy. Contact lists need checking more often than that.

ISO 22301, the international standard for business continuity management systems, describes this as a management cycle: understand the organization, perform a BIA and risk assessment, choose strategies, write plans, exercise, review and improve. Organizations can be certified against it, much as with ISO/IEC 27001 for information security; see governance, frameworks and compliance. NIS2, for essential and important entities, also requires business continuity and crisis management measures.

Examples from critical infrastructure

Organizations that deliver water, energy, healthcare or transport have little room for downtime, and their disruptions affect the public directly. The scenarios below are illustrative; they show the kind of questions a BIA and BCP must answer.

• Regional power outage. Emergency generators and an uninterruptible power supply (UPS) bridge the gap, but for how long? How much fuel is stored, and who delivers more when roads are busy? Mobile networks and internet connections may fail after their own backup power runs out, so how do field teams and the control room communicate?
• Ransomware in the office network. If the process control network is properly separated, the plant can keep running while the office IT is rebuilt; if not, operators may have to switch to local, manual operation. Can they, and have they practiced it? Customer service and billing fall back to workarounds, and incident response and disaster recovery run in parallel.
• Supplier failure. A managed IT provider is hit by an attack, a cloud service has a long outage, or the single supplier of a treatment chemical stops delivering. Which processes depend on that supplier, how much stock or alternative capacity is there, and does the contract say anything about the supplier's own continuity?

In each case the help desk and operations staff are among the first to notice and among the people the plan relies on, which is why they belong in the exercises too.