You bought the tool, sat through the polished demo, and eighteen months later your business impact analysis still lives in a spreadsheet on a shared drive. The platform tested well. It just couldn't carry the work your team is actually accountable for.
That gap between demo and delivery is what this checklist is built to close. The rest of this guide gives you the scoring criteria that separate a platform you'll adopt from one you'll abandon: six core capability categories, the non-functional factors that decide adoption, the questions that expose weak vendors, and how to turn all of it into a matrix procurement can defend.
Why tools get bought and programs stay in spreadsheets
Most feature checklists are written like Christmas lists. Every capability sounds essential, none is tied to a specific job, and the vendor with the slickest demo wins the box-ticking exercise. Then the program that was supposed to leave spreadsheets behind quietly moves back into them, because the tool couldn't do the collection, the mapping, or the reporting the team relies on.
The fix is a change of frame. Score whether the platform replaces manual work, not whether it has a feature. If you're already seeing the warning signs, the piece on when a spreadsheet-based program has hit its ceiling is worth reading before you write a line of the RFP.
The Shelfware Trap
Shelfware happens when the platform demos against a scrubbed tenant and then meets your actual data model. A wish-list checklist scores features in isolation. An RFP checklist scores whether each feature carries the work you're on the hook for. Those are different exercises, and they produce different shortlists.
Frame every requirement around an outcome you're accountable for: a completed BIA cycle, a mapped business service, a board-ready status view, and the specific work the capability has to absorb. That framing is also the connective tissue between this checklist and the broader BCM software buyer's guide, which sets the wider evaluation context.
What is a business continuity platform?
A business continuity platform is software that operationalizes the business continuity management (BCM) lifecycle end to end: business impact analysis, dependency mapping, plan authoring, exercising, incident response, and reporting. It replaces the spreadsheets, shared drives, and email chases a program otherwise runs on, holding data in one connected model rather than scattered files.
Business continuity is a holistic process. It begins with a Business Impact Analysis (BIA), informs the Business Continuity Plans (BCPs) and recovery strategies that follow, and helps an organization keep critical operations running during and after disruption. A platform should support that whole chain, and support the wider resilience work around it, without ever retiring the foundational BIA. The ISO 22301:2019 management-system standard, across clauses 4 to 10 and §8.4 on business continuity plans, is the anchor most enterprise programs map their requirements against.
How to use this checklist
Treat every capability below as a scoring row, not a feature to tick. Before you sit through a single demo, decide which rows are must-have and which are nice-to-have. Deciding this after a vendor has anchored your expectations is how requirements drift toward whatever the tool happens to do well.
Attach a probing question to each row: the specific thing you'll ask the vendor to demonstrate live. The question is what exposes the gap between a capability that exists in the marketing deck and one that works in production.
Core capability checklist by category
This is the working checklist. Six categories, each with the must-have criteria and the question that separates real capability from demo theater. Cyber threats sit at the top of practitioner risk rankings for both the coming year and the next decade, per the BCI Horizon Scan Report 2025, so test each category against how it behaves when a real disruption hits, not just how it looks on a clean tenant.
BIA and data collection
The BIA is where most programs generate their worst data, usually because collection is a manual slog for people who fill in a form once a year. A platform has to make that easier, not just digitize the form.
Must-haves: a structured BIA workflow, configurable capture of recovery time objective (RTO), recovery point objective (RPO), and maximum tolerable period of disruption (MTPD), and automated chasing for infrequent contributors. The NIST SP 800-34 Rev. 1 contingency-planning guide's seven-step BIA methodology is a useful reference point for what a complete workflow covers.
Probing question: show me how a non-BCM department head completes a BIA with no training. Test data-model flexibility too. The criteria should map to your services, not force your program into the vendor's template.
Dependency and resource mapping
Mapping is where a platform either earns its price or reveals itself as a document store. You need to trace processes to the applications, suppliers, people, and facilities they depend on, with visual dependency chains you can follow upstream.
Must-haves: process-to-resource mapping across all four dependency types and the ability to trace an important business service to its third-party dependencies. UK regulators formalised this expectation in PRA SS1/21, §4.1 to 4.12 on mapping.
A single vendor dependency can cascade across an entire sector. In February 2024, the BlackCat/ALPHV group breached Change Healthcare through a Citrix portal without multi-factor authentication and detonated ransomware across payment and claims systems. The American Hospital Association reported that 74% of hospitals saw direct patient-care impact and 94% reported financial impact, because so many providers depended on one clearing house. If your mapping can't surface that kind of concentration, you'll learn about it during the incident. The cost of poor dependency visibility makes the case in full.
Plan authoring and maintenance
A plan nobody can navigate in the opening minutes of an incident is a liability wearing a document's clothing. Authoring has to be fast, and maintenance has to be automatic, because stale plans are the default state of any program that relies on manual review cycles.
Must-haves: templated authoring, version control, and drift alerts when underlying dependencies change. ISO 22301:2019 §8.4 sets the baseline for what a plan must contain. Nice-to-have: AI-assisted drift detection that flags gaps before an exercise or an examiner does.
Probing question: show me how a plan updates when its underlying BIA data changes. Does it flag, re-route, or silently go stale?
Exercising and simulation
An exercise program that measures activity instead of readiness produces a clean audit trail and flat capability. The platform should tie exercises to plan improvement, not just log that they happened.
Must-haves: scheduling, scenario libraries, and automatic capture of findings into corrective actions. For financial firms, the Digital Operational Resilience Act Articles 24 to 27 set testing expectations that go well beyond an annual tick-box. Test the platform's exercise and simulation capability that actually drives resilience capabilities against those, not against a calendar.
Probing question: run a tabletop scenario and show me how the findings flow back into a plan update without anyone re-keying them.
Incident and crisis management
The incident is the moment the platform is either useful or invisible. If it needs a VPN and a stable connection to work, it fails at exactly the point core systems are down.
Must-haves: incident activation, task assignment, timeline logging, and mass-notification integration. On 19 July 2024, a faulty Channel File 291 update to CrowdStrike's Falcon sensor pushed Windows endpoints into boot loops across roughly 8.5 million machines, per Harvard Business Review, with recovery requiring machine-by-machine manual intervention. CISA's alert documented the remediation steps. When the endpoints running your continuity tool are the ones bricked, mobile and offline access stops being a nice-to-have.
Probing question: show me an activation on mobile, with no VPN and degraded connectivity.
See Fortiv incident management module
Reporting and executive dashboards
This is the category that most often drags teams back into spreadsheets. The program does the work in the platform, then someone exports raw data and rebuilds it by hand into a board slide the night before the committee meets.
Must-haves: real-time program status, readiness metrics, and board-ready export with no manual re-keying. Test this one hardest, because a demo dashboard built on seeded data tells you nothing about how it behaves against your half-finished BIA cycle.
Probing question: build a board slide from live platform data, in front of me, using our data model.
Non-functional and program-fit criteria
Features fail in production when the platform is unusable for the people who touch it twice a year, or when it drowns your two-person team in configuration work. Score these alongside the feature grid, because they decide whether the program stays maintained after go-live.
Usability, admin burden, and data flexibility
Usability for infrequent contributors drives adoption more than any single headline feature. If a department head needs a training session to submit a BIA, your response rate collapses and you're back to chasing by email.
Admin overhead is the quieter killer. A platform that needs a dedicated administrator or a vendor professional-services engagement for every configuration change will slide out of date the moment budget tightens. Data-model flexibility decides the rest: does the tool bend to your program, or does your program contort to fit its template?
Integrations and regulatory support
Must-have integrations: IT service management and configuration data (ServiceNow, Jira), HR systems for contact and org data, and mass-notification tooling. A platform that can't ingest your CMDB will hold a dependency map that's wrong the day after you build it.
Multi-jurisdictional regulatory support is where enterprise programs get stuck. A platform should handle European DORA third-party requirements under Article 30, UK operational resilience, and APRA CPS 230 business continuity obligations under §27 to 35 at the same time, not as sequential projects. Financial-services buyers should test evidence trails and audit exports against specific clauses, not a generic "compliance-ready" claim. Manufacturers evaluating supplier concentration and energy firms mapping critical-infrastructure dependencies will weight this section differently, but every regulated buyer needs the audit export to survive an examiner's follow-up question.
Red-flag questions that expose demo theater
The demo is engineered to hide weaknesses. These questions force the vendor off the scripted path and surface the failure modes before you sign, not after.
The BCM-as-bolt-on test
The most common red flag: continuity is the weakest module of a broader governance, risk, and compliance suite, sitting on a base platform like Salesforce and dependent on a configuration someone has to maintain. The demo looks integrated because the vendor spent weeks staging it. The reality is a layer that breaks when your data model doesn't match the sample.
Ask three things. Is continuity native, or a configured layer on a general-purpose platform? Who maintains that configuration when you need a change, your team or a paid services engagement? And can you see a real customer's live tenant, not a scrubbed demo environment? A vendor confident in the answers will show you. One that deflects has told you what you needed to know.
Turning the BCM software checklist into a weighted scoring matrix
A checklist you can defend to procurement and leadership is a weighted matrix, not a yes/no grid. The weighting is where you encode your program's actual accountabilities, so the tool that scores highest is the one that does your work best, not the one with the longest feature list.
Building and weighting the matrix
Follow these steps:
- List every capability from the six categories as a scoring row.
- Tag each row must-have or nice-to-have; a missed must-have caps the vendor's total regardless of other scores.
- Weight each category by your program's accountability. A heavily regulated firm weights reporting and regulatory support higher than a light-touch manufacturer.
- Attach the probing question and score against demonstrated evidence, not the vendor's assertion.
- Document the rationale for each score so the selection survives procurement and leadership challenge.
A single row in the matrix looks like this:
| Capability | Must-have / Nice-to-have | Probing question | Weighted score |
|---|---|---|---|
| Board-ready reporting from live data | Must-have | Build a board slide from our live data, no re-keying | 4/5 × weight 0.20 = 0.80 |
| AI-assisted plan drift detection | Nice-to-have | Show a plan flagged stale when its BIA changes | 3/5 × weight 0.05 = 0.15 |
| Offline incident activation | Must-have | Activate on mobile, no VPN, degraded connectivity | 2/5 × weight 0.15 = 0.30 |
Score against what the vendor demonstrates on your data, and the matrix becomes the paper trail that justifies the decision.
Reporting is where most programs discover whether they bought a working platform or a spreadsheet with a login.
