A guided questionnaire any process owner can complete. Impact scored across six time bands, criticality and recovery priority derived from the answers, and a recommended RTO and RPO kept inside the MTPD. The BIA module that turns process inventory into the spine every other module reads from.
No consultant and no 50-row matrix. The owner answers a short set of plain-language questions, and the engine turns the answers into criticality, recovery priority and recommended recovery targets.
Plain-language questions: “What happens if this process stops?”, “What is the maximum acceptable data loss?”, “What does this process depend on?” Impact answers are labelled five-point options with a one-line description, so nobody needs to know how scoring works.
Derived from the answers: the answers produce the impact score, criticality and recovery priority, plus a recommended RTO and RPO kept inside the MTPD the owner sets. If the owner chooses a different RTO or RPO, the justification stays on the record.
Resumable: step one creates the process record and the assessment gets its own URL, so a half-finished BIA can be picked up tomorrow or handed to a colleague.
Auditable by design: the questionnaire is the audit trail. Every number is reproducible from the stored answers and the weights, with no hidden model and no spreadsheet to reconcile.
Expert layer optional: the configurable impact matrix stays available as a refinement on top. It is never required to get started.
Eight impact categories out of the box: financial, operational, customer, regulatory, legal, reputational, health and safety, and staff welfare. Each carries its own intolerable threshold, so the organisation's risk appetite decides when an impact becomes unacceptable.
The same process can have low impact in the first hours and catastrophic impact after a day, once regulatory deadlines pass, customer SLAs breach and contractual penalties trigger. Every category is scored in every time band.
The owner sets the MTPD. The engine recommends an RTO from criticality and any regulatory deadline, kept inside the MTPD, and an RPO from how critical the data is. A different choice needs a justification.
Five dependency types per process: applications, vendors, locations, people and other resources, and upstream processes. The dependency view renders them as a graph and shows each one's recovery time beside the one the process needs.
In the guided assessment, criticality comes from a weighted score across six impact areas. Floors stop an average hiding a severe impact: any severe area lifts the process to at least high, and a severe health and safety impact makes it critical.
Every approval freezes a numbered snapshot of the process, its impact matrix, its dependencies and the answers behind them. Snapshots are append-only, and reviewers see what changed since the last approved version.
Defensible BIA needs the right detail at the right grain. Here's what BCMStack records — and why each piece matters when an auditor asks.
Code, name, a single accountable owner, the owning department and the primary location, for routing and reporting.
Critical · High · Medium · Low, with a P1–P4 recovery priority. In the guided assessment both come from a weighted score across six impact areas, reproducible from the stored answers.
Recommended from criticality and any regulatory reporting deadline, and kept inside the MTPD. The owner sets the final value; if it differs, the justification is stored with it.
Maximum tolerable data loss in hours, recommended from how critical the process's data is, with the same override justification.
The point where disruption becomes intolerable, stated by the owner and cross-checked against the impact matrix. Governs whether continuity strategies are viable.
Peak periods, data classification, revenue per day and downtime cost per hour, so reviewers see scale at a glance.
Example
Cardholder transaction processing
Eight out of the box: financial, operational, customer, regulatory, legal, reputational, health and safety, and staff welfare. Each has its own intolerable threshold, set to the organisation's risk appetite.
Six bands by default: 0–3h, 3–6h, 6–12h, 12–24h, 1–3 days and 3 days+. Builds the impact curve a flat assessment can't.
From no impact to catastrophic, colour-coded on the heat-map. In the guided assessment every level comes with a plain-language description.
An optional narrative on any cell, and a loss amount on financial cells: the justification auditors ask for, recorded where the score is.
Example
Regulatory impact at 12–24 hours
How the BIA module compares to peer platforms
BCMStack ships eight impact categories: financial, operational and service delivery, customer experience, regulatory and compliance, legal and contractual, reputational, health and safety, and staff welfare. Each category has its own intolerable threshold on the 0–5 severity scale, so the organisation's risk appetite decides when an impact becomes unacceptable. Process owners don't have to work the matrix cell by cell: the guided questionnaire fills it from plain-language answers, and an expert can refine any cell afterwards.
Impact is scored for every category in six time bands: 0–3 hours, 3–6 hours, 6–12 hours, 12–24 hours, 1–3 days and 3 days+. The same process can have low impact in the first hours and catastrophic impact after a day, once regulatory deadlines pass, customer SLAs breach and contractual penalties trigger. The earliest band in which a category crosses its threshold shows when the disruption becomes intolerable.
The process owner states when a disruption becomes intolerable, which sets the MTPD. The engine then recommends an RTO from the process's criticality and any regulatory reporting deadline, always kept inside the MTPD, and an RPO from how critical the process's data is. The owner sets the final RTO and RPO; if either differs from the recommendation, the justification is stored with it. A rule engine flags an RTO or RPO beyond the MTPD, and an MTPD later than the impact matrix says is tolerable. Every recommendation is reproducible from the stored answers; there is no AI in the scoring.
Five dependency types: the applications the process runs on, the vendors it relies on (BPO, SaaS, infrastructure), the locations it needs, people and other resources with normal and minimum quantities, and the upstream processes that must be running first. The dependency view renders them as a graph, and shows each dependency's own recovery time beside the one the process needs so gaps stand out.
Yes. Every approval freezes a numbered snapshot of the process, its impact matrix, its dependencies and the questionnaire answers behind them. Snapshots are append-only, so a later re-answer can't rewrite what the approver signed. Reviewers see what changed since the last approved version before they approve the next one.
We'll walk you through the guided questionnaire, the impact matrix, dependency mapping, and how RTO, RPO and MTPD are set, against a representative SAMA dataset.
Book a 20-minute demoSee the full BCM lifecycle — explore BIA, BCP, Exercises, Crisis, Risk and Reporting.