Configurable impact matrix per tenant. Impact over five timeframes. RTO, RPO and MTPD calculated from real data, not picked from a list. The BIA module that turns process inventory into the spine every other module reads from.
Tenants configure impact categories, severity scale (typically 5 levels), and per-cell qualitative descriptions. The wizard walks process owners through self-assessment using the calibration that matches the industry.
ISO 22301 §8.2 expects impact assessment over multiple time horizons. The same process can have low impact at hour-1 and catastrophic impact at day-3 — regulatory deadlines, customer SLAs, contractual penalties.
Recovery Time / Point / Maximum Tolerable Period — calculated from impact-over-time + resource constraints. Defensible numbers, not picked-from-a-list.
Five dependency types per process: applications, vendors, locations, staff roles, upstream/downstream processes. Together they form a directed graph the dependency-mapping UI renders.
Critical / high / medium / low classification derived from the impact matrix. Removes analyst bias. Tenant-configurable thresholds let banks weight regulatory differently from retail.
bia_assessments stores immutable snapshots. Each approval creates a new assessment record with the full state. Auditors can diff assessments across years.
The actual schema backing the BIA module.
public.bia_processes| Column | Type | Clause | Note |
|---|---|---|---|
| name | varchar(255) | Process name (e.g., Cardholder transaction processing) | |
| process_owner_id | uuid | FK users — accountable owner | |
| department_id | uuid | FK departments — owning unit | |
| criticality | varchar(20) | §8.2 | critical · high · medium · low — auto-classified from impact matrix |
| rto_hours | decimal(8,2) | §8.2 | Calculated from impact-over-time + resource constraints |
| rpo_hours | decimal(8,2) | §8.2 | Maximum tolerable data loss in hours |
| mtpd_hours | decimal(8,2) | §8.2 | Maximum tolerable period of disruption |
| process_volume | decimal(12,2) | Daily/monthly throughput for context |
public.bia_impact_over_time| Column | Type | Clause | Note |
|---|---|---|---|
| category_id | uuid | §8.2 | FK bia_impact_categories — financial, regulatory, etc |
| timeframe_id | uuid | §8.2 | FK bia_timeframes — 1h, 4h, 1d, 3d, 1w |
| severity | int | §8.2 | 1-5 with per-cell qualitative description |
| rationale | text | Why this severity at this timeframe — defensible justification |
| Clause | What it asks for | BCMStack surface |
|---|---|---|
| §8.2.1 | BIA process inventory | bia_processes — one row per business process |
| §8.2.2 | Impact assessment with multiple categories | Configurable bia_impact_categories per tenant |
| §8.2.3 | Impact over time | bia_impact_over_time × bia_timeframes (5 horizons) |
| §8.2.4 | RTO / RPO / MTPD per process | Calculated columns on bia_processes |
| §8.2.5 | Resource and dependency analysis | 5-table dependency model (apps / vendors / locations / staff / process) |
| §8.6 | Periodic BIA review | next_review_date + last_reviewed_at |
| §8.4.1 | BIA outputs feed BCP authoring | bcp_process_scope joins critical processes to plans |
How the BIA module compares to peer platforms
Different industries weight impact dimensions differently. A bank cares about regulatory + customer impact heavily; a SaaS cares about customer + reputation; a hospital cares about staff safety + customer (patients). BCMStack lets each tenant configure: impact categories (financial / regulatory / reputation / customer / staff), severity scale (typically 5 levels), per-cell qualitative descriptions. The wizard then walks process owners through self-assessment using the customer's calibration.
ISO 22301 §8.2 expects impact assessment over multiple time horizons — 1 hour, 4 hours, 1 day, 3 days, 1 week. The same process can have low impact at hour-1 and catastrophic impact at day-3 (regulatory deadlines pass, customer SLAs breach, contractual penalties trigger). bia_impact_over_time stores severity per category × per timeframe so the impact curve is captured properly.
Recovery Time Objective (RTO), Recovery Point Objective (RPO), and Maximum Tolerable Period of Disruption (MTPD) are calculated per process. The wizard derives them from: the process's impact-over-time curve, the resource_timeframes for required resources (apps, vendors, locations, staff), and the customer's calibrated severity threshold. The result is defensible, not aspirational.
Five dependency types: (1) bia_process_applications — apps the process consumes, (2) bia_vendors — third-parties (BPO, SaaS, infra), (3) bia_process_locations — physical sites required, (4) bia_resources — staff roles + headcounts + special skills, (5) bia_process_dependencies — other processes that feed in or out. Together they form a directed graph the dependency-mapping UI renders.
Yes — bia_assessments stores immutable snapshots. Each approval creates a new assessment record with the full state at that moment. Auditors can diff assessments across years. The active assessment is the most-recently-approved one; older ones remain as audit evidence.
We'll walk you through process inventory, the configurable impact matrix, dependency mapping, and the RTO/RPO/MTPD calculation against a representative SAMA dataset.
Book a 20-minute demoSee the full BCM lifecycle — explore BIA, BCP, Exercises, Crisis, Risk and Reporting.