---
title: [BCM] [CardX] [E1] [C5] Determining BCM Assumptions for CardX
description: "How to define, validate and maintain BCM assumptions for CardX: categories, scenarios, resources, constraints, registers and review under ISO 22301."
image: https://blog.bcm-institute.org/hubfs/Generic%20Morepost%20for%20Companies/Updated%20Generic%20BCM%20eBook%20Morepost/BCM%20GEN%20E1/%5BBCM%5D%20%5BGEN%5D%20%5BE1%5D%20%5BC5%5D%20Determining%20BC%20Assumptions.png
---
.
[](http://www.bcm-institute.org/)
- [Home](https://www.bcm-institute.org/)
- [About Us](https://www.bcm-institute.org/about-us-3/)
- [A President’s Perspective](https://www.bcm-institute.org/about-us/a-presidents-perspective/)
- [Our History](https://www.bcm-institute.org/about-us/our-history/)
- [Our Advisory Council](https://www.bcm-institute.org/about-us/our-advisory-council/)
- [Customers’ Testimonials](https://www.bcm-institute.org/about-us/customers-testimonials/)
- [Credential Verification](https://www.bcm-institute.org/about-us/credential-verification/)
- [Courses](https://blog.bcm-institute.org/blog/course-fees-for-blended-learning-courses-master-catalog)
- [ISO 22301 Business Continuity Management System Audit](https://blog.bcm-institute.org/audit/business-continuity-management-audit-courses)
- [ISO 22301 Business Continuity Management](https://blog.bcm-institute.org/bcm/business-continuity-management-courses)
- [Crisis Communication](https://blog.bcm-institute.org/crisis-communication/crisis-communication-courses)
- [Crisis Management](https://blog.bcm-institute.org/en/crisis-management/courses)
- [IT Disaster Recovery](https://blog.bcm-institute.org/it-disaster-recovery/courses)
- [Operational Resilience](https://blog.bcm-institute.org/operational-resilience/courses)
- [Operational Resilience Audit](https://blog.bcm-institute.org/operational-resilience-audit/courses)
- [Certification](https://blog.bcm-institute.org/certification/types-of-certifications-offered)
- [ISO 22301 BCMS Audit Certification](https://blog.bcm-institute.org/certification/business-continuity-management-audit-certification)
- [ISO22301 Business Continuity Management Certification](https://blog.bcm-institute.org/bcm/business-continuity-management-certification)
- [Crisis Communication Certification](https://blog.bcm-institute.org/crisis-communication/crisis-communication-certification)
- [Crisis Management Certification](https://blog.bcm-institute.org/en/crisis-management/crisis-management-certification)
- [IT Disaster Recovery Planning Certification](https://blog.bcm-institute.org/it-disaster-recovery/it-disaster-recovery-certification)
- [Operational Resilience Certification](https://blog.bcm-institute.org/operational-resilience/operational-resilience-certification)
- [Operational Resilience Audit Certification](https://blog.bcm-institute.org/operational-resilience-audit)
- [Seminars](https://blog.bcm-institute.org/meet-the-expert/mte-webinar-mainpage)
- [Store](https://www.bcm-institute.org/store-2/)
- [Contact Us](http://www.bcm-institute.org/about-us/contact-us/)
-
-
##### Planning for Resilience: A Methodology for Implementing BCM in CardX
# \[BCM\] \[CardX\] \[E1\] \[C5\] Determining BCM Assumptions for CardX
Every continuity plan rests on beliefs about what a disruption will look like and what will still be available when it happens.
If those beliefs go unstated, each team fills the gap with its own guess, and the resulting plans cannot be compared, tested, or trusted.
Chapter 1 introduced BCM assumptions briefly. This chapter turns that introduction into a working discipline for CardX.
It shows how to categorise assumptions, where to source them, how to document and validate them, who should own them, and how to keep them current.
The chapter builds directly on earlier work. The organisational profile from Chapter 2 tells us which products, sites, systems and suppliers matter.
Chapter 3's goals, resilience priorities, and provisional disruption tolerance tell us how much disruption is acceptable.
Chapter 4's SMART objectives tell us what the BCM programme must achieve. Assumptions translate all of this into a shared set of planning conditions.
For a financial services organisation operating under Bank of Thailand (BOT) oversight, this is more than good practice.
Regulators of financial institutions generally expect continuity planning to be based on severe but plausible scenarios, to account for third-party and technology dependencies, and to be tested and reviewed.
[Dr Goh Moh Heng](https://blog.bcm-institute.org/ebook/author/dr-goh-moh-heng) Oct 18, 2026
###### Business Continuity Management Certified Planner-Specialist-Expert
*Understanding Your Organisation for CardX* · eBook 1 of *Planning for Resilience: A Methodology for Implementing BCM in CardX*
### [](https://cta-redirect.hubspot.com/cta/redirect/3893111/c338a09a-7f6f-47e5-a008-c9d4d3aa9653)Determining BCM Assumptions for CardX
#### Introduction
[](https://cta-redirect.hubspot.com/cta/redirect/3893111/2cdb04ed-52f3-4f6d-8ae9-fdc438c5b45e)[![eBook Cover \[BCM\] \[CardX\] \[E1\] Understanding Your Organisation](https://no-cache.hubspot.com/cta/default/3893111/ff317031-b993-499e-af86-e4be8c103df2.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/ff317031-b993-499e-af86-e4be8c103df2)Every continuity plan rests on beliefs about what a disruption will look like and what will still be available when it happens.
If those beliefs go unstated, each team fills the gap with its own guess, and the resulting plans cannot be compared, tested, or trusted.
Chapter 1 introduced BCM assumptions briefly. This chapter turns that introduction into a working discipline for CardX.
It shows how to categorise assumptions, where to source them, how to document and validate them, who should own them, and how to keep them current.
The chapter builds directly on earlier work. The organisational profile from Chapter 2 tells us which products, sites, systems and suppliers matter.
Chapter 3's goals, resilience priorities, and provisional disruption tolerance tell us how much disruption is acceptable.
Chapter 4's SMART objectives tell us what the BCM programme must achieve. Assumptions translate all of this into a shared set of planning conditions.
For a financial services organisation operating under Bank of Thailand (BOT) oversight, this is more than good practice.
Regulators of financial institutions generally expect continuity planning to be based on severe but plausible scenarios, to account for third-party and technology dependencies, and to be tested and reviewed.
Clear, approved assumptions are one of the most direct ways to show that planning meets those expectations.
By the end of this chapter, CardX will have a defined process and a set of registers that provide a consistent planning basis for every subsequent BCM activity.
#### Understanding BCM Assumptions
A BCM assumption is a documented condition, circumstance or expectation that CardX agrees to treat as true for the purpose of planning for disruption. You accept it without complete proof because the future event it describes has not yet happened.
Assumptions are useful precisely because they are explicit. Once written down, you can challenge, test, and change them. Unwritten assumptions do the same work in a plan but cannot be examined.
Assumptions are easily confused with four related concepts. Keeping them distinct avoids muddled plans:
- **Verified facts** are things CardX knows are true now, such as the number of approved staff on a team or the location of a data centre. The organisational profile records facts; assumptions describe what will be true during a disruption.
- **Organisational constraints** are known limits that CardX must work within, such as a contractual clause, a budget ceiling or a regulatory obligation. Constraints are not assumed; they are given.
- **Recovery objectives** are targets CardX sets, such as a service's recovery time objective. Objectives state what CardX intends to achieve; assumptions state the conditions under which it will try.
- **Risk assessments** estimate the likelihood and impact of threats. Assumptions draw on risk assessments to select credible planning conditions, but they don't score risks.
A useful test is: "Could this turn out to be wrong when a disruption occurs?" If yes, and CardX is relying on it anyway, it is an assumption and belongs in the register.
Good assumptions are specific, bounded and owned. "Staff will be available" is too vague to plan against. "At least a stated proportion of a critical team will be available within a stated time" can be tested and resourced.
> **Illustrative example:** CardX's card operations team holds a verified fact that it has a defined headcount \[CardX to confirm\]. Its planning assumption is that, during a pandemic-type event, at least 60% *(placeholder)* of that team remains able to work remotely within 24 hours *(placeholder)*. Its recovery objective is to restore card authorisation support within a target time. Its constraint is that certain approvals require dual control under internal policy. Each of these sits in a different register, but all four are needed to write a workable plan.
#### Purpose of Establishing BCM Assumptions
Assumptions give CardX a planning baseline when future disruption details are unknown.
Without them, the BIA, strategy, and plans each rest on different, unspoken expectations.
Assumptions serve five practical purposes:
- **Consistent planning.** Every business function plans against the same conditions. The collections team and the card operations team assume the same office outage duration, so they can compare and combine their plans.
- **Scenario development.** Assumptions define the shape of credible scenarios, such as how long a site is unavailable or how many staff are absent. This turns vague threats into scenarios that can be planned for and exercised.
- **Resource estimation.** Knowing what will and will not be available lets CardX calculate what it must provide: seats, laptops, licences, funding, or third-party capacity.
- **Recovery strategy selection.** Strategies are only as good as the conditions they assume. A work-from-home strategy assumes that home connectivity and remote access remain available. Writing that down shows whether you need a second option.
- **Decision-making under uncertainty.** During an incident, the crisis team can compare actual conditions with planned assumptions. If reality is worse, they immediately know which parts of the plan are at risk.
Assumptions also support governance. Management can see in one place how much disruption CardX is prepared for. Approving the assumptions is, in effect, approving the organisation's level of preparedness.
This links directly to the management commitment and accountability expected under ISO 22301 and, more broadly, by financial-sector regulators.
Finally, assumptions make gaps visible. If the assumption is that a key supplier recovers within a set period, but the contract does not commit to that, the gap is now a documented issue rather than a hidden one.
> **Illustrative example:** CardX's Business Continuity Steering Committee \[CardX to confirm: committee name and membership\] approves a single assumption that primary office premises may be inaccessible for up to 10 working days *(placeholder)*. Card operations, customer service and finance all size their alternative workplace needs against that same figure. When the figures are consolidated, the committee sees for the first time that combined demand exceeds the alternative site's capacity, and commissions a review.
#### Identifying Key Categories of BCM Assumptions
CardX should organise its assumptions into ten standard categories, so nothing important is missed and each category has a natural owner.
The table below sets out the categories, the question each answers and a likely owner.
| **Category** | **Question the assumption answers** | **Likely owner** |
| --- | --- | --- |
| **Disruption severity and duration** | **How bad, how wide and how long is the disruption we plan for?** | **BCM Manager with Risk Management** |
| **Personnel availability** | **What proportion of staff, and which key roles, will be available?** | **Human Resources** |
| **Premises accessibility** | **Which sites can be used, and for how long might they be lost?** | **Facilities** |
| **ICT systems** | **Which systems, data and networks are available, and how quickly can they be restored?** | **ICT / IT Risk** |
| **Communications** | **Which internal and external communication channels will work?** | **Corporate Communications with ICT** |
| **Utilities** | **Will power, water and connectivity be available, and for how long can backups sustain operations?** | **Facilities** |
| **Suppliers** | **Which third parties will continue service, and at what level?** | **Procurement / Vendor Management** |
| **Essential records** | **Which records are accessible, in what form and how current?** | **Records owners with Compliance** |
| **Financial resources** | **What emergency funding and liquidity can be accessed, and how fast?** | **Finance** |
| **External emergency support** | **What can be expected from emergency services, authorities and group entities?** | **BCM Manager** |
Each category should hold a small number of high-value assumptions, not an exhaustive list. A few precise statements are easier to test and maintain than many loose ones.
Sources for assumptions include the Chapter 2 profile, the provisional disruption tolerances from Chapter 3, previous incident records, supplier contracts and service level agreements, ICT recovery documentation, local hazard information and regulatory expectations.
Where no evidence exists, record the assumption as provisional and flag it for validation.
Financial services require particular care in two areas. ICT assumptions should reflect dependence on card networks, payment processing and cloud or outsourced platforms. Supplier assumptions should reflect regulators' general expectation that institutions remain accountable for outsourced services. \[CardX to confirm: critical third-party and outsourced services.\]
> **Illustrative example:** In a first workshop, CardX records an essential records assumption that customer account data needed for dispute handling remains accessible from backup systems with no more than four hours *(placeholder)* of data loss. The ICT owner flags that this has not been confirmed against current backup schedules, so the assumption is marked "provisional" pending validation in Section 5.9.
#### Establishing Disruption Scenario Assumptions
Scenario assumptions describe the credible planning conditions CardX will prepare for. They should be severe enough to stretch arrangements, yet plausible enough that management accepts them as worth funding.
CardX should base its scenarios on the loss of resources, not the cause. A flood, a fire and a police cordon all produce the same planning problem: the building cannot be used. This keeps the number of scenarios manageable. Five core scenario families are recommended:
- **Partial or complete loss of facilities:** one floor, one building or a whole site unavailable for a defined period.
- **Workforce shortages:** a defined proportion of staff, or a specific key team, unavailable because of illness, transport disruption or industrial action.
- **Technology outages:** loss of a core application, a data centre, a cloud region, network connectivity or a cyber incident affecting data integrity.
- **Supply chain interruptions:** failure of a critical supplier, such as a card processor, a contact-centre provider or a card manufacturer.
- **Simultaneous disruptions:** two or more of the above at once, such as a regional flood that closes offices and affects staff, utilities and a supplier together.
For each scenario, record the assumed scope, onset (sudden or gradual), duration, and which business functions are affected. Durations should test the provisional disruption tolerances set in Chapter 3. A scenario that never exceeds any tolerance tells management little.
Financial-sector regulators generally expect institutions to consider severe but plausible scenarios, including cyber attacks and third-party failure.
CardX should describe how its scenario set meets the BOT's expectations once it confirms them. Scenarios should not be copied from regulatory text without checking that they fit CardX's own operations.
The output is a Disruption Scenario Register, which later chapters will use for the BIA, strategy and exercises.
> **Illustrative example:** CardX defines a compound scenario: heavy seasonal flooding in Bangkok *(placeholder location)* closes the head office for seven working days *(placeholder)*, reduces staff availability to 50% *(placeholder)* for the first three days, and disrupts power at a local data facility for 12 hours *(placeholder)*. \[CardX to confirm: actual site locations and hazard exposure.\] Card authorisation, fraud monitoring and customer service are all assessed against this one scenario.
#### Determining Recovery Resource Assumptions
Recovery resource assumptions state what CardX expects to have available to recover once a disruption has occurred. Where scenario assumptions describe what is lost, resource assumptions describe what remains or can be brought in.
CardX should document assumptions for eight resource types:
- **Minimum staffing:** the smallest team, by role and skill, needed to run each prioritised activity at an acceptable level.
- **Alternative workplaces:** remote working, a second CardX site, a group-company site or a commercial recovery centre, with assumed capacity and time to activate.
- **Recovery equipment:** laptops, tokens, headsets, printers and secure devices, including whether they are pre-positioned or must be sourced.
- **Backup technology:** standby systems, replicated data, and the expected switchover time.
- **Essential supplies:** card stock, secure stationery and other consumables needed to keep services running.
- **Transport arrangements:** how staff reach an alternative site, and whether transport may itself be disrupted.
- **Funding:** emergency spending authority and the time needed to release funds.
- **Third-party support:** assumed response from recovery vendors, outsourcers and group entities, and whether that support is contractually committed.
Each resource assumption should state a quantity, a time and a condition. "Twenty *(placeholder)* recovery seats available within four hours *(placeholder)* provided the recovery provider is not serving other clients in the same event" is far more useful than "recovery seats available".
The condition matters most. Many recovery arrangements are shared; for example, a recovery centre may serve several clients on a first-come basis. If a regional event affects them all at once, the assumption fails. Recording the condition makes that risk visible and testable.
Check resource assumptions against the minimum resource needs the BIA will identify. Until the BIA is complete, CardX should treat them as provisional.
> **Illustrative example:** CardX assumes that 80% *(placeholder)* of customer service agents can work from home within one day *(placeholder)*, using company laptops already issued. \[CardX to confirm: laptop issue and remote-access licence numbers.\] The assumption also records a dependency: the remote-access platform must support the additional concurrent sessions. The ICT owner is asked to confirm licence and capacity limits before the assumption is approved.
#### Considering Organisational Constraints and Dependencies
Assumptions must respect the limits CardX actually operates within. An assumption that ignores a known constraint will produce an unexecutable plan.
CardX should examine six types of constraints and dependencies:
- **Available resources:** budget, headcount and equipment that cannot be expanded quickly.
- **Operational capacity:** the throughput a reduced team or a backup system can actually deliver.
- **Regulatory obligations:** requirements to maintain certain services, protect customer data, keep records and notify the regulator of significant incidents. These are described in general terms here and must be confirmed against current BOT requirements.
- **Contractual restrictions:** terms that limit where work can be done, who can do it, or what a supplier must provide in a disruption.
- **Shared dependencies:** resources used by many functions at once, such as a single identity platform, a shared network link or a group-level service.
- **Single points of failure:** any person, system, site or supplier whose loss would stop a prioritised activity with no ready alternative.
Shared dependencies and single points of failure deserve particular attention. They can quietly invalidate several assumptions at once. If every team assumes it can work remotely, but all remote access runs through one gateway, a single fault defeats every plan.
Constraints and dependencies are recorded in an Operational Constraints and Dependencies Register, and each relevant assumption should reference them. The small example register below shows how this looks in practice.
**Illustrative Example: Extract from a CardX Qssumptions Register** *(all values are placeholders)*
| **ID** | **Assumption** | **Linked constraint or dependency** | **Owner** | **Status** |
| --- | --- | --- | --- | --- |
| **A-PER-01** | **At least 60% of fraud monitoring analysts are available within 24 hours of a pandemic-type event** | **Analysts require specialist access rights; only a limited number are provisioned for remote use** | **Head of Fraud** | **Provisional** |
| **A-ICT-03** | **The card management system can be switched to a secondary environment within 4 hours** | **Switch-over depends on an outsourced hosting provider; contract terms to be confirmed** | **Head of IT Infrastructure** | **Under validation** |
| **A-SUP-02** | **The primary card processor maintains authorisation services, or restores them within 2 hours** | **Single point of failure if no alternative processing route exists** | **Head of Vendor Management** | **Provisional** |
\[CardX to confirm: actual system names, providers, owners and contract terms.\] Note that A-SUP-02 exposes a possible single point of failure. That finding is not a failure of the assumption process; it is exactly what the process is meant to reveal.
#### Establishing the BCM Assumption Identification Process
CardX should develop assumptions through a defined, repeatable process so it can explain the results to management, auditors, and the regulator.
The seven steps below move from context to approved, monitored assumptions.
| **Step** | **Activity** | **Expected output** |
| --- | --- | --- |
| **1** | **Review organisational context, BCM goals and objectives** | **Planning Requirements** |
| **2** | **Identify credible disruption scenarios** | **Disruption Scenario Register** |
| **3** | **Determine operational conditions and constraints** | **Preliminary BCM Assumptions** |
| **4** | **Identify resource availability and dependencies** | **Resource and Dependency Assumptions** |
| **5** | **Evaluate assumptions for realism and consistency** | **Validated BCM Assumptions** |
| **6** | **Assign owners and obtain management approval** | **Approved BCM Assumptions Register** |
| **7** | **Establish review and update requirements** | **Assumption Monitoring and Review Plan** |
**Steps 1 and 2** draw on the work of Chapters 2 to 4. The planning requirements summarise what the assumptions must support: prioritised services, provisional disruption tolerances and BCM objectives. Scenarios are then selected as described in Section 5.5.
**Steps 3 and 4** are best run as facilitated workshops, one per category group. Function owners, ICT, facilities, HR, risk and procurement describe what they expect to be true under each scenario. The facilitator records each statement in a standard format: ID, category, statement, scenario, evidence, owner, status and review date.
**Step 5** checks the draft set as a whole. Do assumptions contradict each other? Do they rely on the same shared resource? Section 5.9 covers this in detail.
**Step 6** assigns each assumption a single named owner and submits the register to the appropriate governance body for approval. Approval matters because it signals management's acceptance of the level of preparedness the assumptions imply.
**Step 7** sets review triggers and frequency, covered in Section 5.12.
> **Illustrative example:** CardX runs Steps 3 and 4 over two half-day workshops *(placeholder schedule)*. The first covers people, premises and records; the second covers ICT, communications, utilities and suppliers. Around 30 draft assumptions *(placeholder)* emerge. In Step 5, the BCM Manager merges duplicates and returns six for further evidence, leaving a smaller, cleaner set for Step 6 approval by the Business Continuity Steering Committee \[CardX to confirm: approving body\].
#### Validating BCM Assumptions
Validation confirms that each assumption is realistic, supported by evidence and consistent with what CardX can actually do. It happens before approval and is repeated whenever evidence changes.
CardX should test every assumption against four criteria:
- **Realism:** would an experienced practitioner accept this as a credible condition, neither optimistic nor alarmist?
- **Evidence:** is it supported by data, contracts, test results or incident history, rather than opinion alone?
- **Consistency:** does it agree with related assumptions? Two assumptions should not rely on the same shared resource in incompatible ways.
- **Capability alignment:** can CardX deliver what the assumption implies with its current people, technology and suppliers?
Validation is a consultative exercise. The BCM Manager should consult business function owners, risk management, ICT, facilities, human resources and relevant external service providers. Each group sees a different part of the picture. HR can comment on realistic absence levels; ICT can confirm recovery times; procurement can confirm what contracts actually commit suppliers to.
The results are captured in a BCM Assumptions Validation Matrix. Each row records the assumption, the evidence reviewed, the consultees, a rating against each criterion, and an outcome: accepted, accepted with conditions, revised, or rejected.
If evidence is weak but the assumption is still needed, you may accept it as provisional, with a date for further validation. Provisional status should be visible in the register, so that plans relying on it are treated with appropriate caution.
Optimism bias is the most common weakness. Teams naturally assume that systems will fail over as designed, suppliers will honour contracts, and staff will be available. Validation should deliberately ask, "What evidence do we have that this works under pressure?"
> **Illustrative example:** CardX's draft assumption A-ICT-03 states a four-hour *(placeholder)* switch-over for the card management system. In validation, ICT reports that the last full switch-over test took longer than this \[CardX to confirm: actual test results\]. The matrix records the outcome as "revised", the assumption is updated to the demonstrated time, and the gap against the provisional disruption tolerance is referred to the BIA.
#### Integrating BCM Assumptions with BCM Planning
Approved assumptions feed into every later stage of the BCM lifecycle. Each stage should cite the assumptions it relies on by ID, so that a change to one assumption can be traced through to every affected document.
| **BCM stage** | **How approved assumptions are used** |
| --- | --- |
| **Risk Analysis and Review (RAR)** | **Scenario assumptions frame which threats are assessed; dependency assumptions highlight concentration and third-party risk.** |
| **Business Impact Analysis (BIA)** | **Duration and severity assumptions set the timeframes over which impacts are assessed; resource assumptions inform minimum resource requirements.** |
| **Business Continuity Strategy (BCS)** | **Select strategies to work under the assumed conditions; where an assumption shows a gap, a strategy option must close it.** |
| **Plan Development (PD)** | **Plans state the assumptions they are built on, so responders know the conditions the plan expects and when it no longer applies.** |
| **Testing and Exercising (TE)** | **Exercises are designed around assumed scenarios and deliberately test the most critical assumptions.** |
| **Programme Management (PgM)** | **The assumptions register is maintained, reviewed and reported to management as part of the BCM programme.** |
Integration works in both directions. Assumptions shape the BIA, but the BIA may in turn reveal that an assumption is too optimistic or too severe. Findings from strategy work, exercises and incidents should feed back into the register.
This traceability also supports assurance. Internal audit, management review and the regulator may ask why a plan is designed as it is. The answer "because of approved assumption A-PRE-01" is clear, auditable and defensible.
In ISO 22301 terms, assumptions inform the BIA and risk assessment (clause 8.2), the selection of strategies and solutions (clause 8.3), business continuity plans (clause 8.4) and the exercise programme (clause 8.5). They also form part of the documented information the standard requires CardX to control.
> **Illustrative example:** CardX's plan for the collections function opens with a short "planning basis" box that lists the four assumptions it depends on, by ID *(illustrative format)*. When the premises assumption is later extended from 10 to 15 working days *(placeholders)*, the BCM Manager can immediately identify the collections plan, and three others, as needing revision.
#### Testing the Validity of BCM Assumptions
Validation checks assumptions on paper; testing checks them in practice. CardX should treat its assumptions as hypotheses that exercises and real events either confirm or disprove.
Four sources of evidence are available:
- **Scenario exercises:** tabletop and simulation exercises that play out an assumed scenario and ask participants whether the assumed conditions match what they would actually face.
- **Recovery tests:** technical tests such as data restoration, system failover, or alternative site activation that produce measured times and capacities.
- **Incident experience:** real disruptions, including minor ones, which show how people, systems and suppliers actually behave. Post-incident reviews should always compare actual conditions with assumptions.
- **Dependency reviews:** periodic checks of supplier contracts, supplier continuity evidence, and shared infrastructure that test assumptions about third parties.
Not every assumption carries equal weight. CardX should identify its **critical assumptions**: those that, if proven wrong, would cause recovery arrangements to fail or exceed disruption tolerance. A simple way to find them is to ask, for each assumption, "If this is wrong, what breaks?"
Test critical assumptions first and most often. Typical candidates in a card business include failover times for authorisation and card management systems, availability of the primary card processor, remote-access capacity, and the availability of small specialist teams such as fraud analysts.
Record test results against the assumption ID. If a test disproves an assumption, update the register, identify the affected plans through traceability (Section 5.10), and raise corrective actions through the BCM programme.
A failed test is useful evidence. It is far better to discover an incorrect assumption in an exercise than during a real incident.
> **Illustrative example:** During a tabletop exercise based on the compound flood scenario, CardX's customer service lead points out that the assumed home-working rate *(placeholder)* ignores staff whose own homes are flooded. The assumption A-PER-04 *(illustrative ID)* is flagged as critical, a reduced figure is proposed, and a live test of remote-working capacity is added to the following year's exercise programme.
#### Monitoring and Reviewing BCM Assumptions
Assumptions age quickly. A statement accurate when approved can become wrong after a system migration, an office move, or a new outsourcing contract. CardX should therefore review assumptions on a fixed cycle and whenever a significant change occurs.
**Periodic review.** The full register should be reviewed at least annually *(placeholder frequency)*, ahead of the BIA refresh and the management review. Critical assumptions may warrant more frequent review.
**Event-driven review.** A review of the affected assumptions should be triggered by changes in:
- **Operations:** new products, channels or service levels.
- **Facilities:** office moves, new sites or changes to alternative workplaces.
- **Workforce:** restructuring, significant turnover, or changes to the working model.
- **Technology:** new core systems, cloud migrations or changes in hosting.
- **Suppliers:** new critical suppliers, contract renewals or supplier incidents.
- **Regulatory obligations:** new or revised BOT requirements or expectations.
- **Disruption risks:** a changed threat landscape, such as a rise in sector cyber attacks or new hazard information.
Results from exercises and incidents, described in Section 5.11, are also triggers.
Record each review: what was reviewed, who took part, what changed and why, and who approved the change.
These Assumption Monitoring and Review Records form part of CardX's controlled documented information and provide evidence for internal audit and management review.
Ownership keeps the process alive. Each owner should notice changes in their area and raise them with the BCM Manager.
The BCM Manager maintains the register, tracks review dates and reports overdue or disproven assumptions to the governance body.
A simple monitoring KPI, linked to the Chapter 4 objectives, is the percentage of assumptions reviewed within their scheduled date *(illustrative KPI)*.
> **Illustrative example:** CardX plans to migrate a customer-facing application to a cloud platform \[CardX to confirm: any actual migration plans\]. The change management process automatically notifies the BCM Manager, who triggers a review of the three ICT assumptions linked to that application. Two are updated with new recovery times, and the change is approved and logged before the migration goes live.
#### Key Deliverables
This chapter produces seven deliverables. Together they form a controlled set of documented information that later chapters and eBooks will draw on.
| **Deliverable** | **Content** | **Produced in** | **Suggested owner** |
| --- | --- | --- | --- |
| **BCM Planning Assumptions Framework** | **Categories, standard assumption format, roles, approval route and review rules** | **5.4, 5.8** | **BCM Manager** |
| **Disruption Scenario Assumptions Register** | **Credible scenarios with scope, onset, duration and affected functions** | **5.5** | **BCM Manager with Risk Management** |
| **Operational Constraints and Dependencies Register** | **Resource, capacity, regulatory and contractual constraints; shared dependencies; single points of failure** | **5.7** | **BCM Manager with function owners** |
| **Recovery Resource Availability Assumptions** | **Assumed staffing, workplaces, equipment, technology, supplies, transport, funding and third-party support** | **5.6** | **Function owners, ICT, Facilities, HR, Finance** |
| **BCM Assumptions Validation Matrix** | **Evidence, consultees, criteria ratings and outcome for each assumption** | **5.9** | **BCM Manager** |
| **Approved BCM Assumptions Register** | **Final assumptions with IDs, owners, status and review dates, approved by management** | **5.8** | **BCM Manager; approved by governance body** |
| **Assumption Monitoring and Review Records** | **Review triggers, schedule, test results and change history** | **5.11, 5.12** | **BCM Manager and assumption owners** |
CardX should keep these deliverables under document control, with version numbers, approval records and a clear location. \[CardX to confirm: document management system and approving body.\]
#### [![Banner \[Summary\] \[BCM\] \[E1\] \[C5\] Determining BC Assumptions](https://no-cache.hubspot.com/cta/default/3893111/87c25f72-9147-4348-97ea-6398766e5a72.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/87c25f72-9147-4348-97ea-6398766e5a72)
Clearly defined, realistic and management-approved assumptions give CardX one consistent foundation for continuity planning.
They replace scattered, unspoken guesses with a shared and testable statement of the conditions CardX prepares for.
The chapter has shown how to build that foundation: organise assumptions into standard categories, ground them in credible scenarios and real resource limits, expose constraints and single points of failure, validate them with the people who know, and approve them through governance.
Once approved, assumptions are traced into the RAR, BIA, strategies, plans and exercises, and kept current through periodic and event-driven review.
The benefits are practical. Recovery strategies are more reliable because they are designed for known conditions. Gaps are exposed early, when they are cheapest to close. Responders know when reality has moved beyond the plan.
Management, auditors, and the regulator can see exactly how much disruption CardX is prepared for, and why.
The next chapter can now build on a stable planning basis, confident that every team is working from the same assumptions.
Table 5.1: Determining BCM Assumptions for CardX
| **Section** | **Key point** | **Output for CardX** |
| --- | --- | --- |
| **5.1 Introduction** | **Assumptions give all planning a consistent basis** | **Shared understanding of the chapter's purpose** |
| **5.2 Understanding BCM Assumptions** | **Assumptions differ from facts, constraints, objectives and risk assessments** | **Clear definitions for registers** |
| **5.3 Purpose** | **Assumptions support consistency, scenarios, resourcing, strategy and decisions** | **Management rationale for approval** |
| **5.4 Key Categories** | **Ten standard categories, each with an owner** | **BCM Planning Assumptions Framework (categories)** |
| **5.5 Scenario Assumptions** | **Plan for loss of resources, including compound events** | **Disruption Scenario Assumptions Register** |
| **5.6 Recovery Resources** | **State quantity, time and condition for each resource** | **Recovery Resource Availability Assumptions** |
| **5.7 Constraints and Dependencies** | **Shared dependencies and single points of failure can defeat many plans** | **Operational Constraints and Dependencies Register** |
| **5.8 Identification Process** | **Seven repeatable steps from context to monitored assumptions** | **Approved BCM Assumptions Register** |
| **5.9 Validation** | **Test realism, evidence, consistency and capability; guard against optimism** | **BCM Assumptions Validation Matrix** |
| **5.10 Integration** | **Cite assumption IDs in every later BCM stage** | **Traceability from assumptions to plans** |
| **5.11 Testing** | **Prioritise critical assumptions; treat failed tests as evidence** | **Test results logged against assumption IDs** |
| **5.12 Monitoring and Review** | **Periodic and event-driven reviews keep assumptions current** | **Assumption Monitoring and Review Records** |
| **5.13 Key Deliverables** | **Seven controlled deliverables** | **Document-controlled deliverable set** |
| **5.14 Conclusion** | **Approved assumptions reduce uncertainty and strengthen recovery** | **Stable basis for later chapters** |
#### **Comments**
### More Posts
[](https://cta-redirect.hubspot.com/cta/redirect/3893111/839787f4-a4fd-456f-accf-54c947026558)
All rights reserved. Copyright 2026
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Dr Goh Moh Heng",
"url" : "https://blog.bcm-institute.org/ebook/author/dr-goh-moh-heng"
},
"dateModified" : "2026-10-18T08:24:17.366Z",
"datePublished" : "2026-10-18T08:22:56.000Z",
"headline" : "[BCM] [CardX] [E1] [C5] Determining BCM Assumptions for CardX",
"mainEntityOfPage" : {
"@id" : "https://blog.bcm-institute.org/ebook/cardx-chapter-5-determining-bcm-assumptions",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"url" : "https://blog.bcm-institute.org/hubfs/BCMI%20Logo.png"
},
"name" : "BCMI Pte Ltd"
}
}
```