BCEMP common mistakes
BCEMP · Understand the traps and how to avoid them.
Labelling an activity with the wrong emergency-management lifecycle phase - for example calling a tabletop exercise 'mitigation', or filing a generator-procurement project under 'response'.
Candidates memorise the four phase names as a list rather than as a test applied to a described activity, so they key on the noun (exercise, generator, drill, backup site) instead of the purpose of the activity.
What to do instead
Classify by purpose, not by object: mitigation reduces likelihood or severity before an event on a continuing basis; preparedness builds and validates capability before an event; response protects life, property and operations during the event; recovery restores functions after stabilisation. Write a one-line purpose for each option on scratch paper and match it to the stem before answering.
Answering a continuity question with emergency-management doctrine, or the reverse - invoking incident command structures when the item asks about business impact analysis, or framing a continuity strategy in terms of public protective actions.
The two disciplines share vocabulary (planning, exercises, command, recovery) and many candidates come from one background and unconsciously default to it, especially on scope-type items.
What to do instead
Identify the object being protected before choosing doctrine: emergency management protects people, property and community from hazards; business continuity protects an organisation's prioritised products and services, defined by a BIA. If the stem mentions products, services, RTOs, suppliers or customers, the answer comes from continuity doctrine.
Presenting a hazard inventory as a risk assessment - a list of 'what could happen here' with no likelihood, exposure, vulnerability, capacity or consequence scoring, and no resulting risk ranking.
Hazard-identification worksheets are the most familiar artefact in the field, so candidates stop at the step they have actually done and mistake it for the complete analysis.
What to do instead
Force the full chain into every answer: hazard or threat, plus exposure and vulnerability of the affected assets and processes, plus consequence, modified by existing controls and response capacity, yielding a ranked residual risk with an owner. If the answer lacks likelihood and consequence, it is hazard identification, not risk assessment.
Assessing only hazards at the organisation's own sites and ignoring dependency and cascading risk - utilities, telecoms, transport, cloud providers, single-source suppliers, and key customers' own outages.
Site-based checklists and insurance-style hazard surveys dominate practice, so upstream and downstream failure paths never appear on the candidate's mental list.
What to do instead
Before answering, run a dependency map of each prioritised process: people, facilities, technology, data, suppliers, utilities, and third parties. For each dependency, ask what happens if it fails independently. On exam items, treat an assessment that stops at the fence line as incomplete.
Treating plan approval as the finish line - submitting a polished document as the answer to a preparedness item, with no training, exercise, evaluation or revision cycle attached.
Programmes are often funded as projects with a written deliverable, and templates reward completeness of text rather than demonstrated capability.
What to do instead
Attach the cycle to every planning answer: plan, train, exercise, evaluate, correct, re-issue, with named owners, dates and records. When an item asks how to know a plan works, the only acceptable evidence is observed performance in an exercise or real activation, not the document's existence.
Leaving governance mechanics out of the plan - no activation triggers or thresholds, no delegation of authority, no order of succession with alternates, no defined decision rights or spending authority during an incident.
Plan drafting energy goes into operational procedures and contact lists, while decision authority is assumed to be obvious or handled verbally in the moment.
What to do instead
Build a one-page decision matrix into every plan answer: who declares an incident and at what observable threshold, who may commit funds and to what limit, who assumes authority in what order with named alternates, and who may stand the response down. Items about 'the first thing to happen' are usually testing this matrix.
Collapsing the tactical incident management structure and the corporate crisis or continuity team into one - placing the business continuity coordinator in the incident commander role, or having the executive crisis team direct field operations directly.
Both groups are called 'the response team' in many organisations, and titles overlap, so candidates merge two structures that must be deliberately separated and linked.
What to do instead
Keep two boxes with a defined interface: field or incident command manages the scene, life safety and tactical objectives; the crisis management or continuity team sets business priorities, authorises spend, handles external stakeholders and decides on recovery strategies. Describe the information flow between them - situation reports up, priorities and authorities down.
Confusing RTO, RPO, MTD and workaround time - for example describing RPO as the tolerance for being down, or setting an RTO longer than the MTD.
The acronyms look interchangeable in prose and are often quoted from memory without the arithmetic relationships that constrain them.
What to do instead
Anchor each to a distinct question: MTD is how long the process can be unavailable before the impact becomes unacceptable; RTO is the target time to restore, and must be at or below MTD; RPO is the tolerable amount of data loss measured in time and must be consistent with the recovery design; workaround time is how long an interim manual method takes to stand up. Sketch the timeline on paper before selecting, and check any MTD/RTO pair for plausibility.
Expecting a business impact analysis to rank hazards or set mitigation priorities, or expecting a risk assessment to produce recovery time objectives.
Both are called 'assessments' and both are performed early, so their distinct outputs blur together.
What to do instead
Separate by output: the BIA analyses the consequence of disrupting a prioritised product or service over time and produces MTD, RTO and recovery priorities; risk assessment analyses likelihood and consequence of hazards and produces a ranked risk register with controls and owners. BIA sequences recovery; risk assessment sequences mitigation investment. Match the answer to the output the stem is asking for.
Reporting exercise outcomes as stronger than they were - calling a tabletop 'validated capability', omitting unresolved findings from reports to leadership, or closing corrective actions without evidence of completion.
Sponsors want assurance, presenters fear scrutiny, and a discussion-based exercise genuinely feels like a success, so language inflates from 'discussed' to 'demonstrated'.
What to do instead
Report what was observed: distinguish plan familiarity (seminar and tabletop) from capability demonstrated under stress (drill, functional, full-scale). Publish findings verbatim with corrective action owner, due date and verification method, and report open items to the accountable executive as open. Ethical practice here means accuracy about readiness, not reassurance, and it is the standard the exam applies to 'what should the practitioner do' items.