Business continuity management (BCM) software is usually chosen for how well it stores plans, then fails on the day it is needed because it sits on the same network, identity provider and cloud tenant that the incident has just taken down. BCM platforms run the continuity lifecycle: business impact analysis (BIA), dependency mapping, plan authoring, exercising, incident activation and reporting to management and regulators. Products range from document-centric plan libraries to data-driven resilience platforms that model services, tolerances and third parties. This vendor-neutral buyer's guide is for continuity, risk and security teams selecting a BCM platform, with particular attention to cyber scenarios such as ransomware. For the programme itself, read the Business Continuity and Disaster Recovery Guide and the ISO 22301 Business Continuity Guide; this page covers only the software.
Key takeaways
- Buy for the bad day, not the audit. The test of a BCM platform is whether staff can reach current plans and contact lists when email, the corporate network and single sign-on are all unavailable.
- Data model beats document storage. Platforms that link processes, applications, sites, people and suppliers let one change flow through every BIA and plan; document libraries go stale.
- Dependency mapping should reach technology and identity. A service map that stops at "IT" hides the identity provider, backup system and third parties that cyber incidents actually break.
- Regulation shapes the reporting you need. ISO 22301 certification, UK operational resilience rules and the EU Digital Operational Resilience Act (DORA) each ask for different evidence; confirm the platform produces it.
- Exercise it in the proof of concept. Run a ransomware scenario with real users on the platform, offline, before signing.
Define requirements
- Programme scope and standard: whether you run, or plan to certify, a business continuity management system to ISO 22301:2019, whose operational clause covers BIA and risk assessment, strategies and solutions, plans and procedures, and an exercise programme. Note the frameworks your sector adds.
- Regulatory reporting: UK firms in scope of the FCA and PRA operational resilience rules identify important business services, set impact tolerances, map and test them, and were required to be able to remain within tolerance by 31 March 2025. EU financial entities under DORA need ICT business continuity plans and testing evidence. List the exact outputs supervisors expect. See the UK Financial Operational Resilience Guide and the DORA Guide.
- Users and scale: number of plan owners, BIA contributors, crisis team members and staff who need read access during an incident, across which countries and languages.
- Scenarios: loss of site, loss of people, loss of a key supplier, and loss of technology, with ransomware and identity provider outage as named technology cases.
- Integration sources: HR system for people and roles, CMDB for applications and infrastructure, third-party risk register for suppliers, and the incident management or notification tools you already run.
- Hosting and data residency: where plans, contact data and BIA results may be stored, and how personal data of staff is protected.
Capability areas
| Area | What to look for |
|---|---|
| Business impact analysis | Configurable questionnaires, impact categories over time, recovery time objective (RTO), recovery point objective (RPO) and maximum tolerable period of disruption calculated from answers, approval workflow, year-on-year comparison |
| Dependency mapping | Processes linked to applications, data, sites, roles and suppliers; imports from CMDB and HR; visual service maps; gaps flagged where an application RTO is longer than the process needs |
| Impact tolerances and services | Important business service register, tolerance metrics, scenario results against tolerance, remediation tracking |
| Plan management | Structured templates, reusable content blocks, version history, review reminders, owner attestation |
| Exercising | Exercise scheduling, scenario injects, participant records, findings and action tracking to closure |
| Incident activation | Plan activation, task lists, status boards, decision logs, links to mass notification |
| Offline and resilient access | Mobile app with encrypted offline copy of plans and contacts, hosting independent of your own estate, authentication that does not depend solely on your identity provider |
| Reporting | Dashboards for management review, ISO 22301 evidence, operational resilience self-assessment and DORA outputs, exportable audit trails |
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Availability in a cyber crisis | Plans and contacts reachable with no corporate network, email or single sign-on | Disable SSO for test users and work from personal mobiles | [20%] |
| Data model and dependency mapping | One change to an application RTO updates every dependent BIA and plan | Change one CMDB record and trace the effect | [20%] |
| BIA usability | Business owners complete a BIA without training sessions | Have three owners complete a BIA unaided | [15%] |
| Regulatory reporting | Outputs match your supervisor and certification body expectations | Ask your compliance lead to review sample outputs | [15%] |
| Exercising and incident use | Exercises and live incidents run in the same tool, with action tracking | Run the PoC exercise below | [10%] |
| Security of the platform | MFA, role-based access, encryption, admin audit logs, independent assurance report | Review the security pack and admin roles | [10%] |
| Cost and operations | Clear licence metric (named users, plan owners, modules) and implementation effort | Model three-year cost including configuration services | [10%] |
Weights are illustrative: set them before responses arrive.
Decision guidance: a small organisation with a handful of plans may manage with well-structured templates kept offline, such as the Business Continuity Plan Template and Business Impact Analysis Template, plus a notification tool. A dedicated platform pays off once you have dozens of plan owners, several sites, regulatory reporting or a need to show tolerance testing. Regulated financial firms should weight service mapping and reporting more heavily; organisations most exposed to cyber outages should weight resilient access and integration with incident response and out-of-band communications.
Questions to ask vendors
- Where is the platform hosted, and does any part of it depend on our network, identity provider or cloud tenant being available?
- How do users authenticate if our single sign-on is down, and how is that fallback protected?
- What exactly is stored offline on the mobile app, how is it encrypted, and how is it wiped from a lost device?
- How do you import and keep in sync people, applications and suppliers from our HR, CMDB and third-party risk systems?
- How does the BIA calculate RTO and other recovery values, and can we change the method?
- Show the outputs you produce for ISO 22301 audits, UK operational resilience self-assessments and DORA.
- Which independent assurance reports and certifications cover your service, and how do you handle a breach of your own platform?
- What is your availability commitment, and how have you performed against it?
Red flags
- Single sign-on through your identity provider as the only way in, with no tested fallback.
- Plans stored as uploaded documents with no link to the underlying processes and dependencies.
- Dependency mapping that cannot represent identity services, backups or suppliers.
- "Offline mode" that is a cached web page with no encryption or wipe control.
- Regulatory reports shown only as slides, not as working output from demonstration data.
- Implementation estimates that assume your BIA data is already clean.
Proof of concept
- Load one real business unit: its processes, applications, sites, roles and three key suppliers, imported from your HR and CMDB data where possible.
- Have process owners complete BIAs unaided and compare the resulting recovery values with those in your current documents.
- Build the business unit's plan from the BIA and check that dependencies flow into it automatically.
- Run a ransomware exercise: disable test users' SSO and corporate email, and have the crisis team activate the plan, assign tasks and record decisions from personal mobiles.
- Change one application recovery capability and confirm affected BIAs and plans flag the gap.
- Produce the management review and regulatory outputs you need and have your compliance lead assess them.
- Review the vendor's security pack and test removal of a leaver's access and offline data.
Treat the platform's integration accounts to HR and CMDB systems as non-human identities: scope them read-only and rotate their credentials. See the Emergency Identity Operations When the Primary IdP Is Unavailable.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Business Continuity and Disaster Recovery Guide · ISO 22301 Business Continuity Guide · Crisis Management Guide · Disaster Recovery as a Service · Out of Band Communications