What the Business Continuity Module Does
The business continuity module implements a Business Continuity Management System (BCMS) aligned to ISO 22301 — a management system rather than a document repository, because that is what the standard certifies and what an incident actually tests.
It covers business impact analysis, recovery strategy and plans, dependency mapping, exercising, and the evidence trail connecting all of them.
Business Impact Analysis
BIAs run on one documented methodology with consistent scales, so results are comparable across departments — which is the whole point when you are deciding recovery order across the organisation.
For each process the BIA captures impact accumulating over time at defined intervals rather than a single criticality rating. Everyone's process is important; what distinguishes them is where consequence crosses the unacceptable threshold. From that curve the platform derives:
- MTPD — the maximum tolerable period of disruption
- RTO — set below MTPD with margin
- RPO — data-loss tolerance, answered separately from downtime tolerance
- Minimum resources to run at a reduced but acceptable level
Our BIA guide covers the method in detail.
Dependency Mapping and the RTO Chain
This is where spreadsheet-based continuity fails, and it fails silently.
A process with a four-hour RTO that depends on an application with an eight-hour RTO does not have a four-hour RTO. It has an eight-hour one, and the plan is documenting a fiction. The same applies to suppliers: a vendor committing to 72-hour recovery caps every process depending on them at 72 hours, whatever your plan claims.
Because every BIA lives in one structure with dependencies held as data, ActiveERM traverses the chain and computes the achievable RTO, then surfaces the conflicts as a list. Per-department spreadsheets cannot do this — each one only sees its own process.
You can also ask the questions that only exist across BIAs: which processes depend on this supplier, which dependencies support the most critical processes, and where concentration risk sits.
Recovery Plans
Recovery plans and runbooks are versioned and linked to the BIA entries that justify them, so a change in criticality is visible against the plan that assumed the old figure. Recovery order follows RTO, criticality and the dependency graph, documented in advance rather than debated during an incident.
Exercising
Exercises are scheduled, run and recorded — walkthroughs, tabletops, functional tests and full simulations — with findings tracked to verified closure.
The gap list is the output that matters. An exercise whose findings are not closed is evidence of a weakness rather than of resilience, and an auditor reads it exactly that way.
Interested Parties
ISO 22301 requires identifying interested parties and their requirements: contractual recovery commitments to customers, sector regulatory expectations, and supplier obligations flowing the other way.
Holding these against the BIA surfaces the conflicts that matter — a customer contract promising four-hour recovery for a process with an eight-hour achievable RTO is precisely the finding the standard exists to produce, and it is better found now than during an outage.
Incidents
When something happens, the incident log sits in the same platform as the plans and the BIA. You follow one current playbook rather than hunting across shared drives, and afterward the real event updates the assumptions instead of merely being survived.
Continuity as Part of Enterprise Risk
Because the module shares its data model with Risk OS and GRC Cloud, continuity risks are risks in the enterprise register, continuity controls sit in the shared control library, and ISO 22301 requirements overlapping ISO 27001 are tested once rather than twice by two teams.
Who It Suits
Organisations with a regulatory or contractual continuity obligation, those pursuing ISO 22301 certification, and any organisation whose BIAs have outgrown per-department spreadsheets — usually at the point where dependency conflicts start being discovered during exercises.
Related
- Building a dynamic BCP — turning BIA output into tested plans
- BIA guide — critical processes, RTO, RPO and dependencies
- ISO 22301 coverage — what the standard requires
Request a demo to see BIA, dependency roll-up and exercise tracking with your own processes loaded.