Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

2.5.2. Business Continuity Requirements and BIA

💡 First Principle: Organizations need to determine, before a disaster happens, which business functions are so critical that their extended unavailability would be catastrophic — and what it would actually take to maintain those functions in degraded conditions. The Business Impact Analysis (BIA) produces this analysis with enough rigor to drive real investment decisions.

BIA outputs — these are directly tested on the CISSP:

OutputDefinitionUsed For
MTD (Maximum Tolerable Downtime)Maximum time a function can be unavailable before organizational viability is threatenedSets the outer bound — recovery must happen before MTD expires
RTO (Recovery Time Objective)Target time to restore the function after a disruptionMust be shorter than MTD; drives recovery architecture investment
RPO (Recovery Point Objective)Maximum age of data that can be recovered (how much data loss is acceptable)Drives backup frequency investment
MTBF (Mean Time Between Failures)Average time between system failuresUsed for availability calculations and maintenance planning
MTTR (Mean Time to Repair)Average time to restore after failureCombined with MTBF to calculate system availability
BIA process:
  1. Identify critical business functions — What does the organization do that, if unavailable, would cause significant harm?
  2. Identify supporting resources — Which IT systems, people, facilities, and supplier relationships does each function depend on?
  3. Determine MTD per function — Interview business owners; what's the longest they could operate without this function?
  4. Assess financial and non-financial impacts — Revenue loss per hour, regulatory penalties, reputational damage, safety risks
  5. Prioritize functions — Rank by combination of criticality and dependency
  6. Feed into BCP — BIA outputs become the requirements that BCP must meet (RTO, RPO, MTD per function)

Critical relationship: MTD > RTO. If a business function can tolerate 24 hours of downtime (MTD), the recovery plan must restore it in less than 24 hours (RTO). If MTD is 4 hours and RTO is 8 hours, the recovery plan fails the business requirement before you've even tested it.

💡 Key Point: BIA focuses on impact to the business, not technical recovery steps. It answers "what happens if we can't do X?" not "how do we restore system X?" The technical recovery question belongs to DRP. BIA defines the requirements; DRP defines the solution.

⚠️ Exam Trap: Many candidates confuse RTO and RPO. RTO measures time (how quickly must we restore?). RPO measures data age (how old can our recovered data be?). They answer different questions and drive different investments: RTO drives redundancy and recovery infrastructure spending; RPO drives backup frequency and replication architecture.

Reflection Question: A hospital's electronic health record (EHR) system fails. The BIA shows: MTD = 4 hours, RTO = 2 hours, RPO = 15 minutes. The current DR solution restores in 6 hours from a backup taken every 2 hours. Identify the specific gaps and what investments are required to meet the BIA requirements.

Alvin Varughese
Written byAlvin Varughese
Founder15 professional certifications