Business Impact Analysis

Purpose of the Business Impact Analysis

The Business Impact Analysis (BIA) identifies the organization's critical business processes, estimates the operational and financial impact of their disruption over time, and establishes the recovery objectives that the Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) must meet. On CISM, the BIA is the foundation of all continuity work: you cannot rationally decide how fast to recover, how much redundancy to buy, or what to fund first without it.

A BIA answers three management questions. First, which processes, if interrupted, threaten the enterprise? Second, how does the impact escalate the longer the process is down (impact is rarely linear, it accelerates)? Third, what dependencies, applications, data, staff, suppliers, must be restored to bring each process back? The output is a prioritized list with defensible numbers, not opinion.

Recovery Objectives the BIA Produces

These metrics appear constantly on the exam. Know the definition and the directional relationships.

The key relationship: MTD (or MTO) must be greater than or equal to RTO. RTO is set inside the tolerable limit; if RTO exceeds MTD, the recovery plan fails by design. RPO drives backup frequency: a one-hour RPO requires backups or replication at least hourly.

Conducting and Using the BIA

A BIA is performed with the business process owners, not by IT in isolation, because only the business can say what an outage truly costs in revenue, penalties, reputation, safety, and contractual breach. The information security manager facilitates the analysis, validates assumptions, and translates results into recovery requirements that vendors and engineers can build to.

Worked RPO/RTO example

An order-entry system processes 500 transactions per hour worth roughly 100,000 USD. Management sets RTO = 2 hours (it can survive two hours offline) and RPO = 15 minutes (it can afford to lose at most 15 minutes of orders). The DRP must therefore restore the application within two hours and replicate transaction data at least every 15 minutes. If the BIA later shows MTD is only 90 minutes, the 2-hour RTO is invalid and must be tightened, because RTO cannot exceed MTD.

Common CISM Traps

• Confusing RTO and RPO: RTO is about time to restore; RPO is about data currency. They are independent and often different numbers.
• Letting IT set objectives: Recovery objectives are business decisions; an answer where process owners and senior management own them is stronger.
• Skipping the BIA: Buying a hot site or backup tooling before the BIA is putting controls ahead of requirements, ISACA penalizes solutions chosen without a documented need.
• Treating impact as linear: Impact typically accelerates with outage duration, which is why short RTOs cost disproportionately more.

The BIA is also the document a security manager uses to justify budget to the board: it converts "we should have a DR site" into "a four-hour outage of process X costs 400,000 USD, so a recovery investment of Y is defensible."

How a BIA Is Performed, Step by Step

A defensible BIA follows a repeatable method, and exam questions sometimes test whether a step was skipped or done out of order:

1. Identify business processes, not just systems. Map each process to the applications, data, people, facilities, and suppliers it depends on.
2. Gather impact data from process owners through interviews, questionnaires, and workshops. Capture financial loss, regulatory penalties, contractual breach, reputational harm, and safety consequences.
3. Determine how impact escalates over time, building an impact-over-duration curve for each process. This reveals the point where consequences become unacceptable.
4. Set recovery objectives (RTO, RPO, MTD, SDO) with the business, validated by senior management.
5. Prioritize processes by criticality so recovery investment and sequencing follow the numbers.
6. Document and obtain sign-off, then schedule periodic review as the business changes.

Impact Categories the Exam Expects

A BIA quantifies more than lost revenue. ISACA expects a broad view of consequences:

• Financial: lost sales, idle labor, recovery costs, penalties
• Regulatory and legal: fines, breach-notification obligations, litigation
• Operational: inability to deliver products or services
• Reputational: customer attrition, brand damage, loss of investor confidence
• Health and safety: harm to people where systems support physical operations

Connecting the BIA to Risk and Continuity

The BIA is distinct from a risk assessment: a risk assessment estimates the likelihood and impact of specific threats, while the BIA assumes a disruption has occurred and measures what it costs over time. Both inform planning, but they answer different questions, a common distractor confuses the two. The BIA's outputs flow directly into the BCP (which processes to resume first) and the DRP (how fast and to what data currency to recover systems).

Without a current BIA, every downstream recovery decision rests on opinion, and ISACA consistently rewards the answer that grounds continuity choices in documented business impact rather than technical preference or vendor recommendation. Re-running or refreshing the BIA after major change, mergers, new product lines, large system migrations, is therefore a maintenance obligation, not a one-time project.