Most business continuity software looks alike in a demo. Every vendor shows a BIA form, a plan template and a dashboard. The differences that matter to a SAMA-regulated institution only appear when you ask the platform to produce evidence an examiner would sample, from your own data, under time pressure.
This guide is for BCM managers, CROs and IT leaders at banks, insurers and other institutions in scope of the SAMA BCM Framework who are choosing a platform. It covers what software can and cannot do for you, the criteria worth scoring, the questions to put to every vendor, and how to run a proof of concept that tells them apart.
Start from the requirement, not the feature list
The SAMA BCM Framework sets 13 requirement areas. Software can hold the evidence for most of them, but not all, and a vendor that claims to cover all 13 is usually counting a document upload field as coverage.
| SAMA area | What software can do | What still needs people |
|---|---|---|
| 2.1 Governance | Hold committee records and track decisions to actions, if the product has them | The board mandate, the committee itself, its charter |
| 2.2 to 2.3 Strategy and policy | Store and version the approved documents | Writing and approving them |
| 2.4 BIA and risk assessment | Structured impact analysis, recovery objectives, dependencies, linked risks | Workshops with process owners |
| 2.5 to 2.8 BCP, IT DRP, cyber, crisis | Structured plans, approval, versioning, activation records | Judgement about strategies |
| 2.9 Testing | Test programmes, results, observations, improvement actions | Running the tests |
| 2.10 Awareness and training | Training records, if the product has them | Delivering the training |
| 2.11 Communication | Call trees, notifications, communication logs | Deciding what to say |
| 2.12 Periodic review | Review dates, reminders, a review history | Doing the review |
| 2.13 Assurance | Read-only auditor access, audit trails, exports | The independent review |
Mark each area as "must be in the platform", "nice to have" or "kept elsewhere" before you see a demo. That list becomes your scoring sheet.
Ten criteria worth scoring
1. BIA depth
A BIA in software should be more than a form. Look for impact over time across categories you configure, recovery objectives that are checked against each other, and dependencies on applications, vendors, locations and other processes.
Ask: Does the platform derive or validate the MTPD from the impact matrix? Does it flag an RTO that exceeds the MTPD, or a process whose RTO is faster than the application it depends on? Can a process owner complete their part without BCM-team help?
2. Plans as structured records
A plan stored as a Word file inside the tool is no better than a shared drive. Activation criteria, activation authority, recovery objectives, teams and recovery steps should be fields you can search, compare across plans and diff between versions.
Ask: Show me every plan whose target RTO is longer than the BIA's RTO for a process it covers. Show me what changed between the last two approved versions of this plan.
3. Testing, including IT disaster recovery
SAMA's testing area covers BCP and DRP tests and the records of tests executed. The platform should hold a test programme, link each test to the plans it exercised, and record observations and the improvement actions that follow. DR tests need numbers: target and achieved RTO and RPO, data integrity, failback.
Ask: Which of our critical plans have not been tested this year? Show me a DR test record with the achieved recovery time against target.
4. Incidents and regulator notification
When an incident is reportable, the deadline matters more than the form. The platform should start a clock when an incident is classified, route the notification through approval, record when and how it was submitted, and stop the incident from closing while a notification is outstanding.
Ask: Are the notification deadlines configurable to what our SAMA circulars and licence require? What happens on screen when one is about to breach? Who is alerted?
5. Crisis management and communications
During a crisis the platform must be faster than a phone call. Look at how a crisis is opened, how decisions and actions are logged, and how staff are reached.
Ask: Which channels do call trees use: email, SMS, voice, a mobile app? How is acknowledgement tracked? Can messages go out in Arabic and English?
6. Governance records
SAMA expects a board-mandated BCM committee with a charter and at least quarterly meetings. Many platforms do not model the committee, its minutes, the policy register or training records at all.
Ask: Where do committee minutes, decisions and their actions live? Can an examiner see the trail from a committee decision to the improvement action it created? If the answer is "upload a PDF", plan to keep governance elsewhere and score accordingly.
7. Evidence and reporting
The evidence pack is the product. The question is whether it comes from one dataset or is assembled by hand.
Ask: Produce the evidence pack for one critical service, from BIA to last test, now. Is there an audit log of every change? Is there a read-only role for internal audit and examiners? What formats can we export?
8. Data residency, isolation and outsourcing
Hosting a BCM platform with a vendor is an outsourcing arrangement. Check it against SAMA's outsourcing rules, your own cloud and data-classification policy, and the NCA's cybersecurity controls where they apply to you.
Ask: Which country and provider hosts our data and backups? How is our data separated from other customers': a separate database, a separate schema, or a tenant ID on shared tables? Which sub-processors are involved? What do the security attestations cover?
9. Language and localisation
Ask: Is the user interface available in Arabic, or only some outputs? Are dates and reports correct for our reporting calendar?
10. Implementation and migration
Ask: How do our existing process, vendor and application lists get in? Who builds the first BIA and plan, and how long until the first test is recorded? What does it cost to leave, and in what format do we get our data back?
Run a proof of concept with your own data
Demos use the vendor's data. A two-week proof of concept with one of your own critical services shows how a platform behaves with real complexity. Give every shortlisted vendor the same script:
- 1
Run the BIA for one critical service
Pick a service with real dependencies, such as card payments or a core banking channel. Record impacts over time, recovery objectives and dependencies, and note what the platform flagged.
- 2
Author and approve its plan
Build the BCP for the same service with activation criteria, teams and recovery steps, and take it through your approval route.
- 3
Run a tabletop and a DR test record
Exercise the plan with a short scenario. Record observations, raise improvement actions, and enter the results of a recent DR test for the systems behind the service.
- 4
Raise and close a test incident
Classify it as reportable, follow the notification through to submission, and try to close the incident before the notification is submitted.
- 5
Produce the evidence pack
Ask the platform for everything an examiner would sample on that service. Time it, and check that each artefact links to the others.
A scoring matrix
Weight the criteria to your own priorities. As a starting point for a bank that already has an operating programme:
| Criterion | Suggested weight |
|---|---|
| BIA depth | 15% |
| Plans as structured records | 15% |
| Testing, including IT DR | 15% |
| Incidents and regulator notification | 10% |
| Evidence and reporting | 15% |
| Data residency, isolation and outsourcing | 10% |
| Crisis management and communications | 10% |
| Governance records | 5% |
| Language and localisation | 2.5% |
| Implementation and migration | 2.5% |
Score each criterion from the proof of concept, not the demo. If data residency is a hard regulatory or contractual requirement for you, treat it as pass or fail before scoring the rest.
Red flags
- Coverage claims without a mapping. "SAMA compliant" with no requirement-by-requirement mapping you can check.
- Plans as attachments. If the plan's key fields are inside an uploaded document, you cannot report across plans.
- No link between tests and plans. A test record that does not reference the plan it tested proves nothing about that plan.
- Hosting answers that change. If the hosting location or sub-processor list is vague in the sales process, it will be vague in the contract.
- A proof of concept refused or run only on vendor data.
Where BCMStack fits
BCMStack is strongest on criteria 1 to 4, 6 and 7. The BIA derives the MTPD from the impact matrix and flags recovery objectives that contradict it or the dependencies behind them. Plans are structured records with approval, versioning and an activation log. Tests link to the plans they exercised, DR tests record achieved RTO and RPO, and SAMA notifications run on a clock that blocks incident closure until they are submitted. Everything sits in one dataset with an audit log and a read-only auditor role. The committee is set up as seats with named deputies, meetings record attendance and quorum, and each decision carries an owner, a due date, links to the records it concerns and, where needed, the improvement action it raised. The policy, charter and methodologies are versioned and approved by someone other than their author, with review dates, and training records show whether everyone named in a plan has been trained or exercised in the last year. A board pack and a governance evidence pack export as PDF.
Where it falls short today:
- Staff acknowledgement of policies isn't tracked yet, and training records are completions you record or import, not an e-learning system.
- Call trees deliver by email only; SMS and voice are not live.
- The interface is in English. Call-tree messages can be sent in Arabic.
- Hosting is in the EU by default, and in-region hosting in Saudi Arabia is not available.
- There is no bulk import of process lists yet; registers export to CSV.
If those gaps rule BCMStack out for you, the criteria above still apply to every other vendor on your list. If they don't, see how it works for banks or book a walkthrough and bring your proof-of-concept script.
Further reading: The SAMA BCM Framework guide · Chartering a SAMA BCM committee · BCMStack vs spreadsheets.