Free Practice Questions for BCI CBCI Exam

In CBCI 7.0 (aligned with BCI GPG 7.0), PP1 – Establishing a BCMS includes defining the scope of the BCMS as a foundational activity. Scoping decisions must be rational, risk-informed, and aligned to what the organization must protect to survive disruption—especially the delivery of its products and services and achievement of organizational objectives.

Among the answer options, financial value is a legitimate scoping consideration because it directly relates to business objectives (income, margin, cashflow, contractual value, and critical revenue streams). A product/service that generates significant revenue or underpins strategic outcomes typically warrants inclusion, because disruption would quickly create unacceptable impacts and threaten viability.

By contrast, consultation with staff is an important method for gathering inputs, but it is not, by itself, a primary criterion for deciding scope. “Ease of incorporation” is not good-practice justification for inclusion (scope is set by business need, not convenience). Competitor approaches may be interesting context, but scope should be determined by the organization’s own objectives, obligations, and dependency landscape, not benchmarking alone.

A BC policy is a leadership-approved, high-level statement that sets direction for the BCMS and guides how business continuity will be approached across the organization. For it to be effective, it must be understood by the people who will implement it—leaders, plan owners, responders, and those supporting recovery. Writing the policy in a concise, easy-to-read way helps ensure it is communicated, absorbed, and acted upon, rather than being treated as a dense compliance document that few people read. In the GPG 7.0 approach, success depends on collaboration and enabling the organization to implement continuity practices in a way that fits how it operates; clarity supports engagement and consistent application.

Option A is incorrect because conciseness is not about restricting information; it is about improving understanding. Option B is the opposite of good practice—policies should avoid unnecessary jargon so they remain accessible. Option D describes a secondary benefit (a policy can be a useful summary), but the primary reason for conciseness is to make the policy straightforward and engaging for the people who must use it.

Good practice is to agree what the BCMS covers before building the rest of the system. Determining the scope defines the boundaries (products/services, locations, functions, and interfaces) and ensures subsequent work—policy, objectives, roles, analysis, and solutions—targets the right parts of the organization. BCI’s GPG 7.0 focus on PP1 includes developing both scope and policy, and wider BC guidance reinforces that it is important to agree the scope before progressing through later lifecycle stages such as analysis, design, implementation, and validation.

That makes option C the correct “first” activity. Option B (risk assessment) is part of the Analysis practice and should be performed once scope is set. Option D (policy) is foundational and should follow quickly, but it must align to the defined scope. Option A (governance) is also established early, yet governance design is driven by and must support the scoped BCMS; the scope decision is the logical starting point that anchors everything else.

A response structure exists to ensure the organization has a documented mechanism for responding to an incident regardless of cause, with clear command, control, escalation, and communications. A “critical requirement” for such a structure is having clearly understood procedures for activation and control—i.e., how teams are stood up, who has authority, how decisions are made, and how the response is coordinated once activated. This is explicitly called out as a key requirement for an effective response structure.

Option B (monitoring/early recognition) is also important, but it is one component. The question asks for a critical requirement when creating the structure; activation and control procedures are foundational because without them, even a well-designed structure cannot be reliably mobilised or governed during disruption.

Option A (BIA summary) informs priorities, but it is not a defining requirement of the response structure mechanism itself. Option D relates to analysis/review after an incident, which supports improvement, but it is not the core requirement needed to operate the response structure during an incident. Therefore, C is the best answer.

Defining the initial scope of a BCMS requires a comprehensive understanding of organizational context, risks, and priorities. The CBCI 7.0 course recommends consulting with stakeholders, leveraging internal expertise (e.g., risk management, audit), performing cost-benefit analyses, and horizon scanning to capture potential future threats and opportunities. These methods ensure that the scope is appropriately focused and realistic, considering business objectives, resource availability, and external environment. This thorough approach lays the foundation for a relevant and effective BCMS.

In the CBCI 7.0 body of knowledge (aligned to the BCI Good Practice Guidelines), the Analysis stage (PP3) uses BIA to determine recovery priorities and the resources and dependencies needed to deliver those priorities. Within BIA approaches, an Activity BIA is the one that drills down to the tasks/activities that must be performed to deliver urgent products and services. It identifies which activities are most time-critical, then documents what is needed to perform them (people, premises, technology, information, suppliers) and the internal/external interdependencies that support delivery. This is exactly what the question describes: prioritising urgent delivery tasks and determining the resources and dependencies required to complete them.

A Product & Service BIA is typically higher-level (what must be delivered), while a Process BIA tends to map and assess disruption impacts at process level rather than at the detailed “do-the-work” activity/task level. “Priority BIA” is not the standard BCI naming for a BIA type. The BCI guidance explicitly links activity-level BIA work to understanding required resources and interdependencies for prioritised activities.

When an organization is doing its first BIA, it is common (and practical) to start at a high level—typically with products and services—so leadership can confirm what matters most, validate boundaries, and use that prioritisation to guide deeper analysis. This approach helps the organization clarify BCMS scope and avoid spending time creating detailed activity/process BIAs for areas that turn out not to be priority or even in-scope. This aligns with PP3 Analysis thinking: BIA outputs are used to set priorities and requirements that then drive later stages and deeper work.

Option D (structural changes since the previous BIA) would likely trigger a review and update, but the “high level then drill down to clarify scope” pattern is most strongly associated with an initial BIA where the organization is still establishing understanding and scoping boundaries. Rapid growth (A) can trigger refresh, but it doesn’t inherently imply the “start high-level then build detailed BIAs” sequence. Lack of top management support (C) is a governance/culture issue, not a BIA sequencing rationale. Therefore, B is the best match.

Surveys are a practical and efficient way to collect feedback from participants who may be geographically dispersed or involved in staggered exercise sessions. The CBCI 7.0 course emphasizes that surveys enable broad participation and timely input collection, which can be crucial when participants cannot all meet in person or at the same time. Hot debriefs are typically immediate post-exercise discussions, not extended over a month. One-on-one interviews and limiting input to senior personnel restrict breadth and may delay feedback.

Participant safety is paramount during all exercises. The CBCI 7.0 course mandates that facilitators use pre-determined code words or signals to immediately and discreetly communicate the suspension of an exercise if a real threat to safety emerges. This protocol ensures that all participants receive a clear, consistent message to halt activities without causing panic or confusion. Gathering more details or calling a break delays decisive action and risks exposure. Continuing the exercise despite threats is unacceptable and breaches duty of care. Pre-established emergency communication protocols allow swift, safe responses that prioritize participant well-being above all else.

Counting training hours is a participation/engagement metric. It tells you whether people are showing up and investing time in BC learning and awareness activities, which is one indicator (among many) of the organization’s BC culture—i.e., whether BC is being taken seriously and embedded into normal organizational behaviour. GPG 7.0’s shift toward Embracing Business Continuity highlights improving culture through awareness and engagement across the organization, rather than relying only on compliance enforcement.

Importantly, training hours do not directly measure learning outcomes (B). Someone can spend hours in training without gaining (or retaining) the required understanding; you would need assessments, exercises, observation of behaviour, or performance evidence to confirm learning. Similarly, training hours do not prove risk reduction (D); reduced risk is typically evidenced through improved controls, fewer single points of failure, better recovery performance, and validated capability.

Therefore, the best interpretation is that training hours are a proxy measure supporting evaluation of BC culture/engagement, making A the correct answer.