CBCLA common mistakes
CBCLA · Understand the traps and how to avoid them.
Treating the BIA as a risk assessment: ranking threats by likelihood and impact rather than identifying time-critical business functions and their maximum tolerable downtime (MTD/RTO).
Candidates carry over familiar risk-matrix habits, and many study guides blur BIA with risk analysis, so they produce a threat ranking when the question asks for process prioritization and recovery objectives.
What to do instead
Before answering, ask 'is this asking what the business needs and by when, or what could happen to it?' BIA outputs are prioritized processes, dependencies, MTD/RTO/RPO, and financial/operational impact over time. Threats and likelihoods belong to risk assessment.
Using RTO, RPO, and MTD interchangeably, or selecting the largest number as the recovery target.
The terms are related and often presented together; candidates memorize definitions without anchoring each to its direction (MTD is the outer limit, RTO must be shorter, RPO looks backward at data loss).
What to do instead
Anchor each term with a one-line test: MTD = longest outage tolerated before unacceptable harm; RTO = committed time to restore the function (must be less than MTD); RPO = acceptable data loss measured backward from the outage. When a stem gives an MTD and asks for a strategy, the strategy's RTO must fit inside the MTD with margin.
Choosing a recovery strategy on cost or technology appeal alone, without tying it to the BIA-derived RTO/RPO and without stating the residual risk accepted.
Strategy questions often include a cheaper option that looks attractive, and candidates answer on budget intuition rather than matching the strategy to recovery objectives and management-approved risk tolerance.
What to do instead
Evaluate each strategy against three filters in order: does it meet the RTO/RPO, is it feasible with current resources and dependencies, and is the cost justified by impact avoided? Then state the residual risk and who accepts it. If the cheap option misses the RTO, it is wrong regardless of cost.
Designing recovery for primary systems while ignoring single points of failure in dependencies: utilities, telecom, key suppliers, third parties, and vital records.
Candidates focus on the systems named in the stem and forget that a recovered application is useless without power, network, staff, or a supplier that is itself down.
What to do instead
Build a dependency chain for every prioritized process (people, facilities, technology, data, suppliers, utilities) and check each link for a single point of failure. In scenario questions, ask 'what does this recovered component still need to function?' before declaring recovery complete.
Writing plan content that is not actionable: no named roles with alternates, no activation authority or triggers, no step-by-step procedures, and no contact and resource detail.
Candidates summarize concepts instead of producing operational content, and they underestimate how much specificity (who decides, who is called, in what order) a plan needs to be usable under stress.
What to do instead
For each plan section, verify it answers who, what, when, where, and how. Include named primary and alternate role holders (not just titles), explicit activation criteria and authority, sequenced procedures, and resource and contact references. If a reader cannot act from the text alone, it is not plan content.
Confusing the plan with the program: assuming a written document plus distribution equals implementation, without training, awareness, or integration into normal operations.
Deliverables are visible and easy to study; the organizational work of training, embedding, and gaining sponsorship is abstract, so candidates skip it in answers.
What to do instead
Treat implementation as a separate deliverable set: training records, awareness activities, role-specific onboarding, integration with incident management and change control, and executive sponsorship. When a stem describes a plan that exists but was never used, the gap is implementation, not documentation.
Designing exercises that only confirm the plan (tabletop walkthroughs, checklist reviews) and never test the assumptions, dependencies, or recovery capability.
Discussion-based exercises are easier to run and less risky, so candidates default to them and miss that the exam expects a progressive program with varied exercise types and stated objectives.
What to do instead
Tie every exercise to explicit objectives and match the type to the objective: discussion-based for roles and decisions, operations-based (drills, simulations, full-scale) for capability and timing. Include at least one exercise that validates recovery assumptions and one that tests external dependencies.
Running exercises without a structured after-action process: no documented observations, no corrective actions with owners and due dates, and no tracking to closure.
Candidates treat the exercise as the endpoint and answer as if completing the exercise satisfies the requirement, forgetting that the value is in the findings and remediation.
What to do instead
Build the cycle into every answer: objectives, conduct, hot wash, after-action report with findings, corrective action plan with owners and dates, tracking to closure, and verification in a later exercise. If a stem asks what to do after an exercise, the answer starts with capturing and assigning findings.
Treating maintenance as periodic document review only, ignoring triggers such as organizational change, new technology, mergers, supplier changes, and lessons from actual incidents.
Annual review is the most familiar maintenance activity, so candidates equate maintenance with a calendar and miss event-driven review and version control.
What to do instead
State maintenance as both scheduled (review cycle, exercise results) and event-driven (significant change, new dependency, post-incident lessons, regulatory change). Include version control, distribution of updates, and confirmation that changes reached all plan holders.
Assuming a plan is effective because it exists, without auditing, measuring, or independently validating it against standards and management review.
Candidates conflate having documentation with having assurance, and assessment activities (audits, maturity assessments, management review) are less concrete than writing plans.
What to do instead
Separate assurance from production: assessment means checking the program against defined criteria (plan completeness, exercise results, corrective action closure, BIA currency) with independent review and management sign-off. When a stem asks how to know the program works, the answer is evidence-based assessment, not the existence of a plan.