D7 — Business Continuity Planning: The BIA Process & Plan Testing

Lesson 7 introduced RTO, RPO, and MTD and used them to select a DR site strategy — but treated those numbers as given. This lesson covers where they actually come from (the Business Impact Analysis process), and closes a gap CISSP treats as critical: a continuity plan that has never been tested provides a false sense of security that can be worse than having no plan and knowing it.

The Business Impact Analysis (BIA) process

RTO, RPO, and MTD aren't set by intuition or a standard industry default — they're the output of a structured analysis:

1. Identify business functions and their dependencies — what does the organization actually do, and what systems, people, and data does each function depend on?
2. Determine criticality — for each function, assess the impact of its disruption over time (financial loss, regulatory/legal exposure, reputational damage, safety impact), typically escalating as outage duration grows.
3. Establish MTD — the point at which disruption impact becomes unacceptable/unrecoverable for that specific function, derived directly from the impact analysis in step 2, not assumed in advance.
4. Derive RTO and RPO — set comfortably inside the MTD boundary (RTO always below MTD, never equal to it, echoing Lesson 7), and RPO set based on how much data loss the function can actually tolerate.
5. Prioritize recovery order — functions with the shortest MTD and highest criticality recover first when resources are constrained during an actual event.

The exam-relevant point: a scenario describing an organization that set its DR site strategy "based on industry best practice" rather than its own BIA is describing a process gap — RTO/RPO targets that weren't derived from this organization's actual impact analysis aren't trustworthy guides for this organization's DR spending decisions, the same cost-justification logic running through this entire roadmap since Lesson 2.

Critical vs non-critical functions

A function is critical if its disruption threatens the organization's survival, safety, legal standing, or core mission within a short timeframe — payment processing for an e-commerce platform, patient monitoring for a hospital, the on-air broadcast pipeline for a media company. A function is non-critical if its disruption is inconvenient but tolerable for an extended period — an internal expense-reporting tool, an employee recognition portal. The BIA process is what actually determines this distinction for this specific organization, rather than it being self-evident or assumed by department.

Plan testing: the five levels, least to most disruptive

A documented BCP that has never been tested is, for CISSP purposes, treated as unverified and unreliable — the plan might reference a recovery site that closed, contact numbers that changed, or dependencies nobody documented, and none of that surfaces without testing:

1. Checklist review — participants individually review the plan document for completeness and accuracy. No live exercise.
2. Structured walkthrough (tabletop exercise) — participants talk through the plan together, step by step, in a meeting setting, identifying gaps in logic or missing steps without executing anything live.
3. Simulation test — a specific disruption scenario is simulated, and the team responds as if it were real, without actually failing over live systems.
4. Parallel test — the recovery site/systems are actually activated and run in parallel with the still-functioning primary systems, validating the recovery capability works without any risk to production.
5. Full interruption test — the primary system is actually shut down and operations genuinely fail over to the recovery site. Highest validation value, highest risk and disruption — reserved for organizations with the maturity and stakes to justify it.

Each level up the list provides progressively stronger evidence the plan actually works, at progressively higher cost and risk of the test itself causing disruption — another instance of this roadmap's recurring cost-versus-assurance trade-off, applied to testing itself rather than to a safeguard.

The CISSP mindset: manager vs technician

A company has a thorough, well-written, 40-page business continuity plan that has never been tested since it was written three years ago. Leadership treats "we have a BCP" as evidence the organization is prepared.

The technician answer: the plan exists, is comprehensive, and covers all the identified critical functions — documentation-wise, the requirement is satisfied.

The manager (CISSP) answer: an untested plan is an unverified claim, not a demonstrated capability — in the three years since it was written, the recovery site's configuration, key personnel's contact information, and even which functions are actually critical may have all changed without the plan being updated to reflect it. The CISSP-correct position treats "we have a documented plan" and "we have a tested, current, functioning capability" as two different claims, and pushes for at least a structured walkthrough or simulation test as the minimum evidence the plan would actually work — the same distinction Lesson 9 drew between a clean vulnerability scan and genuine assurance: a document that has never been exercised against reality is a hypothesis, not a verified control.