Business Continuity Requirements
Identify, analyze, assess, prioritize, and implement Business Continuity requirements
Business continuity starts with the BIA (Business Impact Analysis). The BIA identifies critical business functions and determines three key metrics:
RPO (Recovery Point Objective) — maximum acceptable data loss, measured in time
RTO (Recovery Time Objective) — maximum acceptable downtime
MTD (Maximum Tolerable Downtime) — the point of no return for the business
The critical relationship: MTD > RTO always. RTO is your target. MTD is your deadline. And the most important principle: business decides what’s critical, not IT. The BIA is a business-driven process — IT provides feasibility input, but the business owns the priorities.
The 2024 exam update added external dependencies as a key BIA consideration. Your BIA must identify not just internal systems but the vendors, utilities, telecom providers, and cloud services your critical functions depend on.
At a mature organization, the BIA follows a structured process:
- Step 1: Identify critical business functions. Not IT systems — business functions. “Process payroll” is a business function. “Run the SQL server” is an IT system that supports it.
- Step 2: Determine MTD for each function. How long can this function be down before the business faces irreversible harm? The business unit owner answers this, not IT.
- Step 3: Set RTO and RPO. RTO must be less than MTD (your recovery target must beat the deadline). RPO determines backup frequency — a 4-hour RPO means you back up at least every 4 hours.
- Step 4: Identify dependencies. Payment processing depends on the database, the network, DNS, and the payment gateway. A single dependency failure can take down the entire function.
- Step 5: Establish recovery priorities. Based on business impact, not technical complexity. The simplest system to restore might be the lowest priority if its business impact is minimal.
Step 6: Map external dependencies. The 2024 exam outline specifically calls out external dependencies. For each critical function, identify every outside provider it relies on:
- Cloud service providers — if your critical app runs on AWS and AWS has a region-wide outage, your BIA must account for this. A single cloud region is a single point of failure.
- Telecom providers — internet connectivity, phone systems, VPN tunnels. If your ISP goes down, can your employees work? Can customers reach you?
- Utility providers — power, water, HVAC. Data centers need cooling — a sustained power outage without generator backup means servers shut down from thermal protection.
- Key vendors and suppliers — payment processors, shipping partners, SaaS tools (CRM, HR systems, ticketing). If Stripe goes down, can you still process orders?
- Single points of failure — if one vendor provides both your primary and backup services, that’s not real redundancy. Two AWS regions is better than one, but true resilience means multi-cloud or hybrid.
The BIA should map each dependency chain: critical function → internal system → external dependency → what happens if it fails → alternative or workaround.
The BIA output drives everything: backup strategy (RPO), recovery infrastructure (RTO), and DR site selection (MTD). Without a BIA, recovery planning is just guessing.
| Metric | What It Measures | Example | Drives |
|---|---|---|---|
| RPO | Max acceptable data loss (time) | “4-hour RPO = backup every 4 hours” | Backup frequency & replication strategy |
| RTO | Max acceptable downtime | “2-hour RTO = system back in 2 hours” | Recovery infrastructure & DR site type |
| MTD | Point of business failure | “24-hour MTD = business cannot survive beyond this” | Overall DR strategy & priority ranking |
External Dependency Matrix (2024 Exam Addition)
| Dependency Type | Example | BIA Question | Mitigation |
|---|---|---|---|
| Cloud Provider | AWS, Azure, GCP | What if the region goes down? | Multi-region or multi-cloud architecture |
| Telecom | ISP, VPN provider | What if connectivity is lost? | Redundant ISP, cellular backup |
| Utility | Power company | What if power fails? | UPS + generator + fuel contract |
| Vendor | Payment processor, SaaS | What if they have an outage? | Failover processor, manual process |
RPO looks backward (how much data can we lose?). RTO looks forward (how fast must we recover?). MTD is the deadline (when does the business fail?). The relationship is always: RTO < MTD. If your RTO equals your MTD, you have zero margin for error.
A fire destroys your primary data center at 2 AM. The DR plan activates. But the CEO has different priorities than the BIA.
The Data Center Fire
Financial services · 500 employees · primary DC destroyedThe BIA exists to prevent emotional decision-making during a disaster. Recovery priorities are determined when stakeholders are calm and thinking clearly — not at 2 AM with the building on fire. If the CEO wants to change priorities, they should challenge the BIA during annual review, not during an incident.
In practice, executives often override the BIA during real incidents. The security professional’s job is to push back with data: “The BIA you approved says X. Changing priorities now creates risk Y.” Document the override decision and who made it.
On the exam: BIA priorities always win over executive preferences during an incident. The answer that follows the pre-approved BIA is correct. The answer that defers to the highest-ranking person in the room is wrong.
A hurricane damages your primary data center. You can activate the hot site (full recovery, $50K/day) or the warm site (partial recovery, $15K/day). The CFO says use the warm site to save money. But the BIA shows 3 critical systems need hot-site-level recovery to meet their RTOs.
Activate the warm site
Saves $35K/day. Partial recovery covers most functions. Critical systems will take longer but will eventually come online.
Activate the hot site
Expensive, but meets BIA-defined RTOs for all critical systems. The BIA determined these requirements before the disaster.
Option B is correct — the BIA determined recovery requirements before the disaster
Option B: The BIA was created, reviewed, and approved specifically to answer this question in advance. The hot site cost was accepted when the BIA was approved. Post-disaster is not the time to renegotiate recovery requirements — the CFO should have challenged the BIA during planning if the cost was unacceptable.
Option A’s kernel of truth: Cost matters, and “eventually come online” might sound reasonable. But “eventually” means missing RTOs, which means breaching SLAs, regulatory penalties, and potentially exceeding MTD for critical functions. The warm site saves $35K/day but could cost millions in SLA breaches.
On the exam: BIA-defined requirements are treated as pre-approved decisions. Overriding them during an incident is always the wrong answer unless the question explicitly states the BIA is outdated.
When you see BIA or BCP questions: the answer is always business-driven. “The business unit determines criticality” beats “IT determines criticality.” “Follow the BIA” beats “defer to the executive in the room.” And remember the metric relationships: RPO drives backup frequency, RTO drives recovery infrastructure, MTD is always greater than RTO.
- A RPO
- B MTTR
- C MTD
- D RTO
Correct: D. The CFO is defining the maximum acceptable downtime — that’s the RTO (Recovery Time Objective). RPO (A) would be about data loss (“we can’t lose more than 1 hour of transactions”). MTTR (B) is mean time to repair — an operational metric, not a business requirement. MTD (C) is the absolute failure point, which would be longer than 4 hours (“after 12 hours, we lose our merchant processing license”).