eRMA What Should a Business Continuity Platform Actually Solve?
Six business problems a business continuity platform has to solve, what good practice looks like for each, and three questions to put to any vendor.
Ask eRMA
Budgeting season is when many business continuity teams decide whether to renew, replace or buy a platform. The feature lists vendors send are long and look alike. A better starting point is the opposite question: which business problems should the platform make smaller every year? Across banking, insurance, healthcare, energy and the public sector, in North America and the Gulf, the same six come up again and again.
1. The picture is out of date the day it’s approved
The annual business impact analysis (BIA) is the classic example. Questionnaires go out in spring, the results are approved in autumn, and by then teams have reorganized, applications have moved and vendors have changed. The program produces a document, not a current picture.
What good looks like: ISO/TS 22317 treats the BIA as an activity you keep up, not a one-off project. The people who own the data keep it current, a change triggers a review rather than a date on the calendar, and nobody is asked the same question twice. Where processes share a parent, answers are inherited rather than collected again.
Ask a vendor: how does a single change reach the BIA without starting a new cycle?
2. Nobody can see what depends on what
Dependencies usually live in spreadsheets, one per team. Each is right on its own terms, and together they miss the application, site or vendor that quietly supports three critical services at once. That gap tends to show up during an incident, which is the worst time to find it.
What good looks like: one dependency model that connects processes, applications, services, locations, vendors and people. The model should flag a gap on its own, for example an upstream application whose recovery time is longer than the process that needs it can tolerate.
3. Recovery times are stated, not proven
A recovery time objective (RTO) written in a BIA is a target. Until an exercise shows the organization can meet it, it remains an assumption. Many exercise reports are narratives, which makes it hard to say which RTOs were tested and which were met.
What good looks like: ISO 22301 (clause 8.5) asks for an exercise program that validates continuity arrangements. In practice that means recording results per process, application or service against its RTO, and keeping that evidence where an auditor or regulator can follow it.
4. Plans exist, but not in an order anyone can run
Large programs have dozens of plans. Each may be sound on its own, but on the day, someone has to know which runs first, which waits for another, and how long the whole chain takes. That order often lives in one experienced person’s head.
What good looks like: plans sequenced by their dependencies and recovery times, so the total recovery path is visible and can be checked against the business’s tolerance before an incident, not during one.
5. Risk and continuity live in separate worlds
The risk register sits in one tool, the BIA in another and controls in a third. The same vendor can be rated three different ways, and nobody notices until an audit. Regulators increasingly look at operational risk and resilience together, for example OSFI Guideline E-21 in Canada and the US agencies’ sound practices paper on operational resilience.
What good looks like: risk assessments that use the same processes, applications, locations and vendors as the BIA, so a risk rating and an impact rating describe the same thing.
6. Leaders can’t get a straight answer quickly
Executives receive long reports or dashboards that are green because nothing has been measured. Neither helps a leader decide in the minute they have.
What good looks like: each role sees first what needs its attention. Missing data shows as “Unknown”, never as healthy. Data a viewer may not see shows as “Restricted”, never as zero, so a total is never quietly wrong.
Where eRMA fits
eRMA, the resilience platform from eBRP Solutions, was designed around these six problems. All of the following are available today:
- Business impact analysis with group BIA and inheritance, and live progress for each campaign. The Employee Kiosk lets staff keep their own details current.
- Impact Map and Dependency Designer: one connected model of processes, applications, services, locations, vendors and people, with RTO gaps shown where they occur.
- Exercise: rehearse a scenario and record results for each entity against its RTO, with the evidence kept.
- Plan Sequencer: one bar per plan, chained finish-to-start, so the recovery path can be seen and adjusted.
- Risk Assessment on the same entities as the BIA, with ERM and Compliance (GRC) available as optional add-on modules.
- Role-based workspaces that lead with what needs attention, where “Unknown” is never green and “Restricted” is never zero.
See it: Business impact analysis →
See it: Dependency Designer and Impact Map →
Three questions to ask any vendor
- Show one change, live. Add a new application that supports a critical service, and show how it reaches the BIA, the plans and the dashboard, without slides.
- Show a proven RTO. Where does the platform show that a recovery time was exercised and met, not only stated?
- Show the first ten seconds. What does a senior leader see on opening the platform, and what does it show when data is missing?
A platform earns its budget when these six problems get smaller every year.
Download this as a one-page Brief: What should a business continuity platform solve? (PDF)
