Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Business continuity management software is the system an organisation uses to run its BCM programme end to end — business impact analysis, recovery strategy, continuity and recovery plans, crisis management, exercising, and the reporting that proves all of it to a regulator. The distinction that matters when you buy BCM software is simple: most of it is built to author plans. Very little of it is built to be invoked when systems are actually down.
This guide covers what BCM software has to do against ISO 22301, what SAMA expects from regulated entities in Saudi Arabia, and how to evaluate platforms without ending up with a very expensive document library.
The authored-versus-invoked problem
Walk into most BCM programmes and you will find beautifully formatted plans that nobody has opened since the last audit. They were written to satisfy a clause, not to be followed at 03:00 during a ransomware incident. The tell is usually format: a 90-page PDF with narrative prose is an artefact for an auditor, not a runbook for a recovery team.
ISO 22301 is quite specific about this. Clause 8.4.4 requires business continuity plans to contain defined roles and responsibilities, activation procedures, and the specific steps for continuity and recovery — not a description of the approach. Clause 8.5 requires the organisation to exercise and test, and to retain evidence of the results. A platform that stores documents cannot satisfy either clause on its own; it just holds the file where the answer should be.
The practical test when you evaluate BCM software: can a recovery lead open this at 03:00, on a phone, and know what to do in the first ten minutes? If the answer requires reading prose, the plan will not be used.
What BCM software has to cover
Business impact analysis
The BIA is the foundation and the place most programmes go wrong. It should establish process criticality, recovery time objectives and recovery point objectives, dependency mapping (systems, people, suppliers, facilities), and maximum tolerable period of disruption. Critically, RTOs set in the BIA must flow into the recovery plans rather than being restated independently — if the two can drift apart in your tooling, they will. Our post on business impact assessment in business continuity management covers the methodology.
Risk assessment
Disruption scenarios, likelihood and impact, and treatment — connected to the same asset and process inventory the BIA uses. BCM risk that sits in a separate register from IT risk produces two versions of the truth. See our IT risk management framework guide for how the two should connect.
Continuity and recovery plans
Structured, step-level plans with named roles, activation triggers, phased recovery sequencing and dependencies made explicit. Phasing matters: bringing everything back at once is not a plan, it is a wish. The plan should say what comes up first, what it depends on, and who decides.
Crisis management and activation
Who declares an incident, on what authority, and what happens the moment they do. The activation log is the piece almost everyone omits and auditors always ask for: a timestamped record of every invocation, decision and escalation. Without it you cannot evidence that the plan was used, only that it existed.
Exercising
ISO 22398 sets out how exercises should be designed, run and evaluated. A programme needs a schedule, defined objectives per exercise, participant tracking, findings, and remediation carried through to closure — not a tabletop once a year with no follow-up. Our guide to tabletop exercises for incident response covers running them properly, and scenario development covers designing the scenarios.
Reporting
Board and regulator reporting on programme coverage, plan currency, exercise completion and open findings — generated from live data, not assembled by hand the week before the committee.
The SAMA dimension for Saudi entities
For banks, insurers and fintechs regulated by the Saudi Central Bank, business continuity is not a best-effort exercise. SAMA expects a documented BCM programme with tested recovery capability, defined RTOs for critical services, and evidence that exercises actually happen and produce corrective action. Operational resilience expectations have tightened across the sector, and “we have a plan” no longer answers the question — the question is whether the plan has been invoked, tested and improved.
Related reading on the Saudi regulatory picture: SAMA IT Governance Framework compliance and cyber resilience and business continuity management.
An evaluation checklist
- BIA with RTO/RPO that flow directly into recovery plans, not restated separately
- Dependency mapping across systems, people, suppliers and sites
- Step-level plans with named roles and explicit activation triggers
- Phased recovery sequencing rather than a flat task list
- Native ISO 22301 clause 8.4.4 plan structure
- Activation log capturing every invocation, decision and escalation (clause 8.5)
- Exercise programme aligned to ISO 22398, with findings tracked to closure
- Usable during an outage — mobile, and not dependent on the systems being recovered
- Audit-ready output a regulator will accept without rework
- Board reporting generated from live programme data
BCMStack
Disclosure: BCMStack is our own BCM software. The criteria above are written to be useful whether or not you choose it.
BCMStack is an operational resilience and business continuity management platform built for SAMA-regulated banks, insurers and fintechs in Saudi Arabia, and designed around the authored-versus-invoked distinction above.
It covers risk management, BIA, BCP, crisis management, exercises and reporting, with native ISO 22301 §8.4.4 plan structure, phased recovery, and a §8.5 activation log that captures every invocation. Output is audit-ready, aligned to SAMA, ISO 22301 and ISO 22398.
More detail at bcmstack.com.
