Business continuity and business impact analysis

Every organization eventually faces disruption: a ransomware attack, a flood, a failed data center, a pandemic, a supplier going out of business. Business continuity is the capability to keep delivering critical products and services at acceptable levels during and after such events. Sub-domain 1.7 of the CISSP outline asks you to identify, analyze, assess, prioritize and implement business continuity requirements, with emphasis on the business impact analysis (BIA) and external dependencies. Domain 7 covers disaster recovery and continuity exercises in operational detail; this lesson focuses on the requirements and planning decisions that leadership must make.

Continuity, recovery and resilience

Several related terms are easy to confuse. Business continuity planning (BCP) is the overall process of preparing to keep critical business functions running during disruption. Disaster recovery planning (DRP) is the part focused on restoring IT systems and data after an outage. Incident response deals with detecting and containing security incidents, which may trigger continuity or recovery plans. Crisis management covers leadership decisions and communication during a major event. Resilience is the broader ability to anticipate, withstand, recover from and adapt to disruption. ISO 22301:2019 specifies requirements for a business continuity management system, and many organizations follow its approach.

Senior management owns business continuity, because it decides which functions matter most and how much to spend protecting them. A business continuity steering group, with representatives from operations, IT, security, facilities, human resources, communications, legal and finance, usually guides the program. The security function contributes threat knowledge, protects data and systems during recovery, and makes sure that recovery itself does not open new vulnerabilities.

The planning process

Most continuity programs follow a similar sequence, drawing on ISO 22301 and NIST SP 800-34. First, obtain management commitment and define scope through a policy. Second, conduct a BIA to identify critical functions and recovery requirements. Third, assess risks to those functions. Fourth, develop recovery strategies. Fifth, write plans. Sixth, train people, test and exercise the plans. Seventh, maintain the program through regular review and updates. The BIA is the foundation; without it, recovery spending is guesswork.

The business impact analysis

A BIA identifies an organization's business functions, the resources each depends on and the impact of disruption over time. It answers three questions: what are our critical functions, how quickly must each be restored, and what does each need in order to run? A BIA is usually carried out through interviews and questionnaires with business owners, supported by financial data and system inventories.

Impacts are assessed in several categories: financial (lost revenue, penalties, extra costs), operational (inability to deliver services), legal and regulatory (breaches of law or contract), reputational (loss of customer trust) and safety or health (harm to people). Impacts usually grow with time: a one-hour outage of an online store costs a little; a one-week outage may threaten the business. The BIA records how impact rises at intervals such as four hours, one day, three days and one week.

From those impact curves, the BIA derives recovery metrics:

• Maximum tolerable downtime (MTD), also called maximum tolerable period of disruption (MTPD): the longest a function can be unavailable before the impact becomes unacceptable.
• Recovery time objective (RTO): the target time to restore a system or function after disruption. RTO must be shorter than MTD.
• Recovery point objective (RPO): the maximum acceptable amount of data loss, measured as time. An RPO of one hour means backups or replication must capture data at least hourly.
• Work recovery time (WRT): the time after systems are restored needed to verify data, catch up on backlog and resume normal work. RTO plus WRT should not exceed MTD.
• Minimum business continuity objective (MBCO): the minimum level of service acceptable during disruption.

The BIA also identifies dependencies: the people, facilities, applications, data, equipment and suppliers each function needs. A payroll function may depend on the HR system, the bank's file transfer service, a specific team and a time-limited processing window before payday. Mapping dependencies often reveals single points of failure, such as one person who knows how to run a critical batch job.

External dependencies

The 2024 outline specifically names external dependencies. Modern organizations rely heavily on cloud providers, software-as-a-service vendors, telecommunications carriers, payment processors, logistics firms and utilities. A disruption at one of them can stop critical functions as surely as an internal failure. Continuity planning must identify these dependencies, understand their resilience, and plan for their failure.

Useful steps include asking critical suppliers for their continuity plans and test results, reviewing SOC 2 reports and contractual recovery commitments, checking concentration risk (many functions relying on one provider or one region), identifying alternative suppliers or manual workarounds, and including key suppliers in exercises. Supply chain risk management (Lesson 10) and continuity planning overlap here. Large outages at single providers, such as a faulty security software update in July 2024 that crashed millions of Windows computers worldwide, showed how widely one dependency can spread.

Recovery strategies

Strategies should match the BIA's recovery objectives and the organization's budget. For facilities, options range from cold sites (space and power only, weeks to set up) through warm sites (some equipment, days) to hot sites (fully equipped and ready within hours), mirrored sites, mobile sites and remote work. For IT, options include backups with offsite or immutable copies, replication to another region, high-availability clusters and cloud disaster recovery services. For people, options include cross-training, documented procedures, succession plans and arrangements with staffing agencies. For suppliers, options include dual sourcing and contractual commitments.

Cost and recovery speed trade off against each other. A hot site in a second region may cost a large share of the primary environment's budget; a cold site costs little but recovers slowly. The right choice is the cheapest strategy that still meets the RTO and RPO for each function. Spending more than the BIA justifies wastes money; spending less leaves the organization exposed.

Plans, testing and maintenance

Plans should be concise, action-oriented and usable under stress: who declares a disaster, who does what, contact lists, recovery procedures, communication templates and criteria for returning to normal operations. Testing moves from checklist reviews and tabletop exercises to walkthroughs, simulations, parallel tests and, rarely, full interruption tests. Every test should produce lessons learned and plan updates. Plans must also be maintained as the business changes: new systems, reorganizations, mergers and supplier changes all affect continuity.

In the United States, NIST SP 800-34 Revision 1 guides contingency planning for federal systems, and FEMA's continuity guidance covers government continuity of operations (COOP). Financial regulators, through the FFIEC's Business Continuity Management booklet, expect institutions to manage continuity risk, and NFPA 1600 provides a standard for emergency management and business continuity programs.

People and communication in a disruption

Continuity plans often focus on systems and sites, but people decide whether recovery succeeds. Plans should identify who can declare a disaster and activate the plan, with alternates if those people are unavailable; how staff will be contacted if email and phones are down, for example through an out-of-band notification service; where people will work; and how the organization will support staff who are themselves affected by the event, such as during a regional flood. Key-person dependencies identified in the BIA should be reduced through cross-training and documentation.

Communication is part of continuity. Customers, regulators, suppliers, investors, the media and employees all need timely and accurate information during a disruption. Pre-approved message templates, a designated spokesperson and a clear approval path prevent conflicting statements and speculation. For cyber incidents, communications must also be coordinated with legal counsel and with breach notification duties, and should avoid claims that may later prove wrong, such as stating too early that no data was taken.

Security must also be maintained during recovery. Restoring systems from backups that contain the original malware, re-enabling accounts that attackers created, or relaxing controls to speed recovery can turn one incident into two. Recovery procedures should include steps to verify that restored systems are clean, reset credentials and apply missing patches before reconnecting them.

Continuity planning is never finished. Each exercise, real incident, reorganization or new system should prompt a review of the BIA, the recovery objectives and the plans. Many organizations refresh the BIA annually and after major changes, and report continuity readiness to leadership alongside other risk metrics, such as the percentage of critical functions with tested plans and the results of the latest recovery tests.

A plan that has been exercised recently, with lessons applied, is worth far more than a thick binder that has never been tested in practice.