ABC CP common mistakes
ABC CP · Understand the traps and how to avoid them.
Treating business continuity as disaster recovery: answering scenario questions by describing IT backup, failover and data restoration as the whole response.
Many candidates come from IT or security backgrounds where continuity is equated with technology recovery, so they default to the tools they know rather than the business-level discipline the exam tests.
What to do instead
For every scenario, first ask what business function, product or service is at risk and who owns it, then place IT recovery as one supporting capability among people, facilities, suppliers and processes. Practise writing answers that start at the business impact level before any technical solution.
Confusing the business impact analysis with a risk assessment, describing likelihood and threat probabilities when asked to determine recovery priorities and tolerances.
Both activities use similar language (impact, likelihood, criticality) and are often performed by the same team, so candidates merge them into a single answer.
What to do instead
Memorise the distinct purpose of each: the BIA establishes impact over time and the maximum tolerable period of disruption for activities, while risk assessment evaluates threats and vulnerabilities against those activities. In practice questions, state explicitly which activity produces which output before answering.
Quoting recovery time objectives without linking them to the maximum tolerable period of disruption or to the resources that can actually deliver them.
RTOs are the most familiar continuity metric, so candidates recite a number as if it were self-justifying, forgetting that an RTO must sit inside the MTPOD and be validated against achievable recovery capability.
What to do instead
Always present the chain: business impact over time, then MTPOD, then the RTO chosen to leave a safety margin, then the recovery strategy and resources that make it credible. If a question asks you to evaluate an RTO, check it against both the tolerance and the delivery capability.
Producing a continuity plan that is a document inventory or a list of contact numbers, without defined roles, invocation criteria, escalation paths or action checklists.
Candidates who have seen plans in the workplace often reproduce a table of contents rather than demonstrating how a plan functions when activated.
What to do instead
Structure answers around the plan's operational elements: purpose and scope, invocation authority and triggers, roles and decision rights, communication and escalation, activity-level recovery actions with time targets, and interdependencies. When asked to improve a plan, name the missing element and say what it enables.
Skipping the validation cycle, or describing a desktop exercise as proof that recovery capability works.
Exercises feel like an optional extra and discussion-based tests are easier to run, so candidates present them as sufficient evidence of readiness.
What to do instead
Distinguish discussion-based from operations-based exercises and state what each can and cannot prove. Show a progressive programme (plan walkthrough, tabletop, simulation, live failover), with objectives, evaluation against them, and a corrective action log that feeds back into plan revision.
Ignoring supply chain and third-party dependencies, or assuming a contract clause or a supplier's certificate transfers continuity responsibility.
Outsourcing feels like risk transfer, and candidates overlook that accountability for delivering the organisation's products remains in-house regardless of who performs the activity.
What to do instead
In dependency questions, map critical suppliers and outsourced activities, assess their continuity arrangements and interdependencies, and state that the organisation retains accountability. Specify contractual requirements, testing evidence and exit or substitution options as part of the strategy.
Describing the continuity management lifecycle as a one-off project with a start and end, rather than an ongoing programme with governance, monitoring and review.
Project language dominates professional experience, so candidates frame continuity as an implementation to be completed rather than a capability to be sustained.
What to do instead
Anchor answers in the continuing cycle: policy and governance, analysis, strategy, plan development, validation, and review with corrective action, repeated as the organisation changes. When asked how to mature a programme, point to ownership, performance monitoring, audit and management review rather than to a project plan.
Submitting experience that lists job titles and years but never shows what the candidate personally did, decided or produced in continuity work.
Candidates assume seniority and duration speak for themselves, and they under-report the analytical and planning tasks they actually performed.
What to do instead
Write experience entries as situation, personal action, output and outcome: which continuity activity you led or contributed to, what artefact or decision resulted, and what changed as a result. Use active first-person verbs and quantify scope such as activities analysed, sites covered or exercises run.
Claiming experience across the full continuity lifecycle when the record only evidences one narrow area, such as plan writing or incident response.
Candidates overstate breadth to look comprehensive, not realising that a claim without supporting detail invites challenge and undermines credibility elsewhere.
What to do instead
Map each claimed area to a specific piece of evidence before submitting, and be candid about gaps. Where experience is partial, describe the boundary honestly and show how adjacent work, training or supervised involvement extends your understanding.
Submitting a referee or sponsor who cannot corroborate the specific continuity work claimed, or failing to brief them on what will be verified.
Referees are often chosen for seniority or line-management convenience rather than direct knowledge of the candidate's continuity contribution.
What to do instead
Select verifiers who directly observed the claimed work, confirm in advance that they can speak to your specific actions and outputs, and give them a factual summary of what you have claimed. Where no such verifier exists, adjust the claim to what can be independently supported.