CBCA common mistakes
CBCA · Understand the traps and how to avoid them.
Accepting an engagement to audit a continuity program the candidate previously designed, built, or currently advises, and never documenting or disclosing the self-review threat.
CBCA candidates usually come from the BC practitioner and consulting side, where 'I built this program, so I am the obvious person to audit it' is treated as a credential rather than an independence problem. Objectivity safeguards are rarely taught in BC operations training, so the conflict is invisible to the candidate until it is raised in an exam scenario or a challenge to the report.
What to do instead
Before fieldwork, complete a documented independence and objectivity check: list any prior design, implementation, testing, or advisory role on the subject program over the past 2-3 years, state the threat (self-review, familiarity, advocacy), and record the safeguard applied (different reviewer, restricted scope, withdrawal from that area, disclosure to the audit client in the engagement letter). In scenario questions, the correct answer is almost always 'disclose and manage or decline', never 'proceed because you know the program best'.
Drifting into consulting during fieldwork: telling the auditee how to fix a gap, agreeing a remediation approach, and then continuing to audit the same area and rating it.
BC auditors are conditioned to be helpful, and auditees ask 'so what should we do?' constantly. Answering feels efficient and relationship-preserving, and candidates do not see that they have now created a criterion of their own making that they will later audit against.
What to do instead
Hold a fixed line between evidence gathering and advice. In the opening meeting and the engagement letter, state that recommendations will be delivered only in the report (or in a separate advisory engagement). If the auditee asks for a fix mid-interview, respond with 'that is outside this audit's scope; it will be addressed in the report or a separate engagement', and record the exchange in the workpapers. If advice is given, escalate it as an objectivity threat and reassign the area.
Writing the audit scope by lifting the continuity program's own scope statement verbatim (for example, 'all business functions, all hazards, enterprise-wide'), so the engagement has no boundaries, no stated criteria, and no limitations.
Candidates copy from the BC plan or the ISO 22301 scope statement they already have to hand, and those documents deliberately describe an ambitious, aspirational coverage. The audit scope must instead describe what will actually be examined, against what, in what period, and what is excluded - a different document with a different purpose.
What to do instead
Write the scope in five explicit parts: (1) entities, sites, and processes in and out of scope; (2) the audit criteria and their version; (3) the period covered; (4) the audit objectives and the type of audit (conformity, performance, readiness); (5) stated limitations (no site visits, no live exercise observation). Test it by asking whether a different auditor could repeat the audit from that paragraph alone.
Building the audit program as a clause-by-clause checklist with roughly equal time per clause, and no documented rationale for which areas, processes, or samples were chosen.
It is the fastest way to look thorough and it mirrors how candidates studied the standard. Clause-by-clause coverage feels defensible, but it ignores that the same clause carries wildly different risk across organizations, and it leaves no record of why a high-risk supplier, site, or recovery dependency was or was not tested.
What to do instead
Before writing the checklist, do a short risk assessment of the auditable area (criticality of processes from the BIA, recent incidents, prior findings, exercise results, third-party dependency, change since last audit) and use it to set time allocation, depth, and sampling. Record the rationale in the audit plan: what is high risk and therefore tested in depth, what is sampled, what is excluded and why. A defensible audit plan answers 'why did you look there?' not just 'what did you ask?'.
Concluding that controls are effective on the strength of document review alone - reading the BCP, the BIA, and the exercise plan - without examining exercise after-action reports, incident records, observation, or test evidence of what actually happens.
Document review is comfortable, fast, and confirmable, and continuity documentation is voluminous enough to fill the fieldwork days. Candidates also confuse 'the plan says the call tree is tested twice a year' with 'the call tree is tested twice a year', and the first is far easier to obtain than the second.
What to do instead
For each control, plan at least two independent evidence types (document, interview, observation, system record, or exercise output) and record which you used. Where only documentation exists, report the control as 'designed, implementation not verified' rather than 'effective', and state that limitation in the report. Never sign off operational effectiveness on a document set alone.
Running the whole audit through a single point of contact - typically the BC coordinator or resilience manager - and treating that person's account as the organization's position.
The BC coordinator is the person who arranges the audit, knows the standard, and is easiest to schedule. Candidates under time pressure collapse the interview plan into repeated sessions with the same person, and that person's version of events, by construction, will be the most favourable and the least operational.
What to do instead
Build the interview sample deliberately across levels: top management (governance, resources, management review), process and business unit owners (BIA inputs, plan usability), recovery and IT teams (RTOs, dependencies, backup restoration), and facilities or supplier management where relevant. State in the report how many interviews were held and at what levels, and corroborate any single-source assertion against another source before relying on it.
Recording conclusions in workpapers without the evidence trail: no document identifier or version, no date, no interviewee name and role, no sample size, no location of the record.
Candidates write workpapers as a summary of what they concluded, treating them as notes to self, rather than as the record that allows another auditor - or the auditee in a dispute - to retrace the finding to its source. The habit comes from producing management summaries, not audit files.
What to do instead
Use a standard evidence record for every test: criterion, evidence examined (title, version, date), who provided or was interviewed, sample selected and how, result, and conclusion. Reference the evidence record number in every finding. Before closing fieldwork, do a self-check: could a reviewer who was not present reproduce each finding from the file alone?
Writing findings as judgements rather than structured conditions - for example 'BC planning is immature' or 'management does not take continuity seriously' - with no criterion, no evidence reference, and no statement of effect.
Candidates write the way they would speak to a colleague, and a conclusion feels like the useful part of the sentence while the criterion feels bureaucratic. The result is a finding the auditee cannot accept or rebut on the merits, which turns the closing meeting into an argument about opinion.
What to do instead
Write each finding in four parts: criterion (the requirement or agreed expected state, cited with its source), condition (what was actually found, with evidence references and sample results), cause (why it happened), and effect or risk (what continuity outcome it exposes, in business terms). If a part is missing, the finding is not finished. Opinion words ('weak', 'poor', 'immature') are replaced by observable facts.
Closing corrective actions when the auditee submits an action plan, or when a revised document is produced, without verifying that the action was implemented and that it actually removed the cause.
Follow-up is scheduled late, the auditee sends a plan with dates and owners, and closing the item feels like an administrative step that clears the audit log. Candidates also accept 'the BCP has been updated' as evidence of a fixed root cause when the cause was that nobody reads the BCP.
What to do instead
Define closure criteria at the reporting stage, in writing: what evidence of implementation will be accepted and what evidence of effectiveness will be accepted. Do not close on a plan; close on verified implementation plus verification that the condition no longer exists (re-test, re-sample, or re-interview). If only implementation can be verified, record the item as implemented but effectiveness not yet verified, and keep it open.
Auditing against criteria held in memory or mixed from several frameworks: citing a clause number not in the agreed criteria, treating good-practice guidance as a 'shall', or grading an NFPA 1600-based program against ISO 22301 requirements without agreeing the change of criteria.
Experienced candidates have absorbed several frameworks and standards across a career, and under exam or fieldwork pressure they recite the requirement they remember rather than the one in the agreed criteria document. Requirements and guidance are also visually similar in many publications, and the distinction is easily lost.
What to do instead
Pin the criteria in the engagement scope, including the exact standard and version, and cite each criterion from the actual document - clause number and wording paraphrased accurately - not from memory. Before writing any finding, classify the source requirement as 'shall/requirement' versus 'should/guidance' and label it as such in the finding. If the organization's chosen framework differs from your habitual one, map the criteria explicitly in the audit plan before fieldwork starts.