CISM Business Impact Analysis, Business Continuity and Disaster Recovery

The business impact analysis (BIA) decides what must be recovered and how fast, the business continuity plan (BCP) keeps the organization's critical processes running through a disruption, and the disaster recovery plan (DRP) restores the IT systems and data those processes need. They form a chain: the BIA comes first, its validated recovery priorities and objectives set the requirements, and the BCP and DRP are designed, funded and tested to meet them.

The DRP is part of business continuity, not a substitute for it. Restoring servers does not help if staff have nowhere to work, suppliers cannot deliver or customers are not told what is happening. Both plans are cause-agnostic: they apply whether the disruption comes from a fire, a supplier failure or a cyberattack. They do not replace the incident response plan either; during a security incident the response plan and the continuity plans run side by side, linked by agreed invocation criteria.

What a BCP contains. A business continuity plan sets out how the organization responds to a disruption and keeps its critical processes going: who decides, who does what, how people are kept safe and informed, and how work continues while systems and sites are restored. A typical BCP covers:

• Scope and objectives taken from the validated BIA, including the recovery priorities.
• Emergency response and personnel safety: evacuation, accounting for staff and the first actions after an event. People come first in every plan.
• Crisis management: the crisis team, its authority, and invocation criteria for the continuity and recovery plans.
• Communications: call trees and contact lists, and messages for staff, customers, regulators, suppliers and the media.
• Alternate processing procedures: manual workarounds and alternate ways of working that keep a process running at its service delivery objective until systems return.
• Recovery and return: references to the DRP for IT restoration, and the steps to move back to normal operations.
• Distribution and maintenance: who holds current copies (including copies available off site and offline), version control and review triggers.

The plan has to be usable when the normal environment is not: copies that live only on the systems that have failed are of no help.

Where the information security manager fits. In CISM the security manager does not own business continuity. They align the incident response plan with the BCP and DRP, make sure information stays protected during recovery, bring security threats (such as ransomware against backups) into recovery design, and escalate gaps between objectives and capability to the people who own the business risk. Incident response planning, classification and exercising have their own lesson; this one covers the BIA and the continuity and recovery plans.

The primary purpose of a BIA is to identify the organization's critical business processes, measure the impact their disruption would cause over time, and from that rank them by criticality and set how quickly each must resume. Everything else in continuity planning depends on it: recovery strategies, site choices, backup schedules and test objectives are all judged against the BIA's results.

A BIA typically:

• lists the business processes and the systems, data, people, facilities and suppliers each relies on;
• asks process owners what harm a disruption would cause: financial loss, regulatory and contractual penalties, operational knock-on effects, customer harm and reputational damage;
• measures that harm at several time intervals (for example after one hour, one day, three days, one week);
• derives the recovery objectives for each process (RTO, RPO, maximum tolerable downtime, service delivery objective);
• ranks processes by criticality, which sets the order of recovery.

Impact over time matters more than a single number. Some processes cause little harm for a day and then fail badly as penalties fall due or customers leave; others are severe within minutes. A single impact figure per process flattens that curve, and the recovery time objective is set from the point where the curve becomes unacceptable.

The BIA comes before any recovery strategy. A strategy answers the question "how will we meet this process's objective?". Without a BIA there is no objective to meet, so any strategy chosen first rests on assumptions. Wherever continuity work starts from nothing, whether a new line of business or a newly opened office, it starts with a BIA carried out with the people who own the processes.

A BIA measures the consequences of losing a process regardless of what causes the loss or how likely it is; a risk assessment weighs the likelihood and impact of specific threats to decide how to treat them. The two inform each other, but they answer different questions and must not be blended.

Keep likelihood out of criticality. How reliable a process has been, or how rarely a threat occurs, is a likelihood argument: it belongs in the risk assessment and cannot lower a process's criticality in the BIA. Any rating method that multiplies impact by frequency lets likelihood decide criticality. The BIA asks what happens when the process stops, whatever the cause.

Process owners supply the impact data. How long a process can be interrupted is a business judgement: how long before lost revenue, missed obligations or customer harm become unacceptable. Only the owners and managers of each process can give it. Technical, security and assurance functions contribute facts, method and review, but the tolerance for disruption is the business's to state.

Senior management validates the results. Every owner tends to rate their own process as critical. Before the BIA is used to design strategies, senior management, who own the business risk and approve the budget, review and agree the criticality ratings and objectives and settle conflicts between units. Only validated results are a sound basis for strategies whose cost management will be asked to fund.

The BIA expresses each process's tolerance for disruption as recovery objectives: how fast it must resume (RTO), how much data it can lose (RPO), the longest outage the business can survive (maximum tolerable downtime) and the level of service it must deliver while recovering (service delivery objective).

A note on ISACA terms. ISACA uses allowable interruption window (AIW) for the total time the business can wait from disruption to restored normal service. Maximum tolerable outage (MTO) is a different measure: how long the organization can sustain processing in alternate (recovery) mode. They are not synonyms, and neither should be confused with the RTO.

RPO looks back, RTO looks forward. The RPO is about data already created that could be lost; the RTO is about the time until the process is running again. Worst-case data loss equals the gap between recoverable copies, so copies taken every six hours can lose up to six hours of data and cannot meet a one-hour RPO. Speed of restore is an RTO matter and does nothing for data that was never copied; a tighter RPO needs more frequent backups, replication or transaction journaling.

Test each objective on its own. A strategy can comfortably meet its time objective and still fail its data objective, or the reverse. Each objective is a separate requirement, so passing one, or staying inside the outer downtime limit, never covers for failing another.

How they constrain each other. The RTO is set shorter than the maximum tolerable downtime, leaving room for the decision to invoke, for restoring data and for checks before going live. The SDO decides how big the recovery capacity must be: a payments service that must process a fixed fraction of its normal transactions while in alternate mode needs capacity for that fraction, not for its full peak.

Recovery objectives are set where the cost of a longer outage meets the cost of a faster recovery capability, and senior management decides that trade-off. The cost of disruption rises the longer a process is down; the cost of recovery capability rises steeply as the objective gets shorter, because seconds need a mirrored site, hours a hot site and weeks only a contract for space. An objective shorter than the balance point costs more than it saves; a longer one allows losses the business has said it cannot accept.

When the objective and the cost conflict, the security manager presents the trade-off rather than resolving it. Whenever the capability an objective needs costs more than the losses it would avoid, the information security manager quantifies the impact and the cost of each option and puts them to senior management, who decide whether to fund the capability, revise the objective or knowingly accept the residual risk. Settling it alone, in either direction, takes a business decision away from the people accountable for it.

Objectives come from business impact. The technology and budget available today shape the strategy chosen to meet an objective; they do not decide where the objective sits.

A process can recover only as fast as its slowest dependency, so every upstream system, service and supplier inherits the recovery objective of the critical process that relies on it. A BIA that rates each system by its own direct users misses this. A shared database cluster that no business user ever logs into may look low priority, but if a payroll process with a one-day RTO cannot run without it, the cluster needs an objective at least as tight, with the capability and funding that go with it. The dependency's own objective has to change; recovery order alone cannot make a slow capability fast.

Dependency mapping covers infrastructure (networks, directory and identity services, DNS, key management), shared applications and data feeds, people with specialist skills, facilities, and external providers.

Outsourcing a service does not outsource its recovery objective. When a critical process runs on a cloud or other third-party service, the provider's continuity capability becomes part of the organization's. The security manager should confirm that the provider's recovery capability is tested and meets the BIA's objective, and make that a contractual obligation with reporting and the right to evidence, because only the provider can restore the provider's service. Supplier management as a whole is covered with the security program's third-party controls; here the point is that suppliers appear in the BIA and the plans.

Alternate sites are chosen by matching each process's recovery objectives to the cheapest option that meets them: the shorter the RTO and RPO, the more ready, and more expensive, the site must be.

Mirrored versus hot. Synchronous replication commits each transaction at both sites before it is acknowledged, so no committed data is lost. Asynchronous replication acknowledges a transaction before the remote copy has it, so the transactions in flight at the moment of failure can be lost. A ready site therefore does not guarantee zero data loss: the replication mode decides the RPO, and the site's readiness decides the RTO.

The weakness of reciprocal agreements. Each partner usually runs close to its own capacity, configurations drift apart, security requirements may conflict and the agreement is hard to enforce. The core weakness is that the spare capacity may not exist when it is needed, which makes reciprocal arrangements a poor fit for time-critical processes.

One recovery tier per objective, not one tier for everything. When the BIA gives processes very different objectives, a single hot site for all of them overspends, and a single warm or cold site misses the tight objectives. A hospital can justify near-immediate recovery for its patient-record system while its staff training portal, which can wait weeks, is covered by a low-cost option. Tiered strategies are also how recovery order is put into practice.

Backup and replication arrangements must meet the RPO and must leave at least one copy that a site disaster or an attacker cannot destroy along with production. Frequency answers the RPO; location and isolation answer the question of whether a copy survives.

• Frequency against the RPO. Worst-case data loss equals the interval between recoverable copies. Daily backups suit a 24-hour RPO; shorter RPOs need more frequent backups, journaling or replication.
• Offsite storage against physical disasters. Backups kept in the same room or building as the systems can be lost in the same fire, flood or physical attack. Copies held at a separate, secure location survive it. Retrieval time from offsite storage has to be allowed for in the RTO.
• Isolation against logical attacks. Ransomware operators commonly take over administrator accounts and delete or encrypt backups before encrypting production. A copy is only safe from them if it is isolated: offline, immutable, or managed with separate credentials that the production administrators do not hold. Distance is not isolation: if the same accounts administer both copies, one compromise reaches both.

Replication is not a backup. Replication keeps a second copy identical to the first, so it copies destructive changes, such as encryption or mass deletion, as faithfully as good ones. Copies kept inside the same administrative domain as production can be wiped by whoever controls that domain. Replicas and local copies protect against losing hardware or a site; recovery from corruption or ransomware depends on a copy that is both isolated and older than the corruption. Good designs combine the two: replication for tight RTO and RPO, plus isolated, versioned backups kept long enough to reach back before an attack that went unnoticed for some time.

Backups are only as good as the last successful restore, so restore tests (including integrity checks of the restored data) belong in the test programme.

The BCP and DRP are invoked by a senior manager named in the plan, with deputies, applying criteria agreed in advance, normally the expected outage time measured against the process's recovery objectives. Moving to alternate arrangements is expensive and disruptive, so the decision belongs to someone with business authority; technical and security leads supply the facts, such as how long restoration or containment is expected to take.

Make the criteria measurable. A vague, judgement-based trigger invites debate at the worst moment, and time spent deciding comes out of the RTO: an objective can be lost before recovery even starts. Measurable thresholds tied to the recovery objectives, plus a named decision-maker with deputies, let the call be made quickly. The fix for slow decisions is a better decision process, not a longer objective or a shift of business authority to technical staff.

Continuity does not wait for containment. During a security incident, containment and continuity answer different questions: containment stops the attack, continuity keeps the business running. When the invocation criteria are met during an attack, the named authority invokes the alternate arrangements while the incident response team carries on with containment. Waiting for containment lets the impact pass the limit the BIA set. The alternate arrangements must of course be kept separate from the compromised environment, which is one reason isolated recovery copies and separate credentials matter. This handover is why the incident response plan is written in alignment with the BCP and DRP.

Data keeps its classification and protection requirements when it moves to a recovery site or recovery mode; a disaster changes where the data lives, not how sensitive it is. Attackers exploit disruption, and recovery is when shortcuts are most tempting.

• Agree minimum controls in advance. The security manager defines, during planning, the minimum controls the recovery environment needs for the classification of the data it will hold, balancing speed of recovery against protection, and gets them agreed with the business. Decisions made under pressure in the middle of a disaster are the ones most likely to trade away protection.
• Verify a recovery provider's controls before signing. A recovery provider must offer the protections as well as the capacity. For regulated or highly classified data (health records, for example) the full set of controls the data requires, not one or two of them, must be verified at the alternate site and written into the contract.
• Restored systems meet the security baseline before they go live. Systems restored from old images can be missing security patches and hardening. Patching and baseline checks belong in the recovery procedure before go-live, and the RTO should allow for them: if restore plus patching still fits inside the objective, there is no reason to run exposed systems during a crisis. Deferring hardening until after the crisis leaves the exposure in place exactly when attackers are watching.

Continuity and recovery plans are tested against the BIA's objectives, and a test passes only when those objectives are met, not merely when systems eventually come back. Tests range from paper-based to fully operational:

A parallel test is the one that proves the recovery site can process real work without risking an interruption to production; a full interruption test is the most realistic but deliberately stops production. (Choosing and evaluating incident response exercises is covered in the incident response planning lesson.)

A missed objective is a finding for management. A system that comes back later than its RTO is a gap even if everything else went well. The security manager reports it to the process owner and senior management, who can fund a faster strategy or knowingly accept a longer objective; any handling that keeps the gap from them leaves a real exposure unmanaged.

The BIA and the plans are refreshed when the business, its systems or its suppliers change. New products, a change of hosting or supplier, regulatory change and reorganizations can all change impacts and dependencies, and those live in the BIA. The order is: update the BIA, revise the plan from it, then test the revised plan; testing or tidying a plan whose basis is out of date proves little. Administrative changes that leave impacts and dependencies untouched call for plan maintenance (contacts, training), not a new BIA. Scheduled reviews and audits are useful, but tying plan review to change management and procurement is what keeps the content current.