Business Impact Analysis Template: What Every BIA Record Needs

A BIA template is not a form you fill in once and file. It is the data model your entire BCM programme runs on. Get the template right and every downstream artefact — BCPs, exercises, recovery investments — has clean inputs. Get it wrong and every BCP inherits the same ambiguity. This article walks through the fields a working BIA template needs, with notes on the choices that matter.

The parent topic is our BIA pillar guide.

The template, field by field

1. Process metadata

• Process name — specific, recognisable to the business. "Card authorisation," not "payments."
• Process owner — named role, with deputy. The accountable party for the BIA record's accuracy.
• Department / business line
• Criticality tier — Tier 1 / 2 / 3, derived from the impact ratings below (not assigned by the owner directly).
• In-scope / out-of-scope flag — explicit, so reviewers can see at a glance what the BIA covers.

2. Process description

A short paragraph describing what the process does, the customer outcome it produces, and where it sits in the value chain. Useful context for anyone reading the BIA in six months.

3. Impact ratings — over time

The substantive content of the BIA. For each impact dimension, capture a rating at each time horizon:

The ratings are drawn from the impact matrix — a programme-level artefact that defines what counts as Low, Medium, High and Critical for each dimension. Without a consistent matrix, the BIA cannot be aggregated.

The horizon at which any dimension first crosses Critical is the MTPD. In the table above, customer impact crosses Critical at 24 hours, so MTPD = 24 hours.

4. Recovery objectives

• MTPD — Maximum Tolerable Period of Disruption. Derived from the impact-over-time table.
• RTO — Recovery Time Objective. The plan's commitment; must be less than MTPD.
• RPO — Recovery Point Objective. The maximum acceptable data loss in time.
• MBCO — Minimum Business Continuity Objective. The minimum service level acceptable during recovery, if any.

Each objective should have an evidence pointer — where the supporting calculation or infrastructure capability is documented. RTOs declared but unevidenced are a recurring audit finding.

5. Dependency map

For each process, capture the dependencies it relies on:

• Applications — software systems used. Reference your application inventory.
• Vendors / third parties — external providers (cloud, SaaS, payment processors, telcos).
• Locations — physical sites required (data centre, branch, call centre).
• People roles — skills and authorities (named roles, not named individuals).
• Data feeds — inbound and outbound dataflows.
• Infrastructure — networks, identity, security services that everything else assumes.

Capture each dependency with a criticality flag (single-point-of-failure vs. redundant). This is the input to scenario design for the exercise programme.

6. Peak periods

Windows of elevated criticality — month-end, regulatory reporting deadlines, retail seasonality. Some processes have MTPDs that vary by calendar position; a 24-hour MTPD outside month-end might be 4 hours during month-end close. Capture this explicitly.

7. Workarounds

Documented degraded-mode operating procedures, if any. For each, capture:

• The workaround procedure
• The capacity sustainable in workaround mode (vs. full mode)
• The duration the workaround is sustainable
• The trigger to invoke the workaround vs. invoke the BCP

8. Strategy decision

The continuity-strategy choice for the process:

• Recover — invest in recovery capability
• Mitigate — reduce the likelihood or impact through pre-emptive action
• Transfer — insurance, contractual liability transfer, vendor SLA
• Accept — explicit acceptance of the disruption risk

The decision should have a rationale linked back to the impact rating and a decision owner at the appropriate level (typically BCM committee for Tier 1 processes).

9. Review metadata

• Date completed
• Date last reviewed
• Next review due
• Reviewer
• Approval status — draft, in review, approved
• Approver (when approved)
• Linked BCPs — which plans depend on this BIA record

The review metadata is what keeps the BIA alive. Without it, BIAs drift quickly out of date.

The impact matrix — the foundation

The BIA template is only as good as the impact matrix that backs it. The matrix should specify, for each dimension and each rating (Low / Medium / High / Critical), explicit, organisation-anchored thresholds.

Example for the Financial dimension:

• Low — direct loss < $50k OR recovery cost < $50k
• Medium — direct loss $50k-$500k OR recovery cost $50k-$500k
• High — direct loss $500k-$5m OR recovery cost $500k-$5m OR contractual penalty triggered
• Critical — direct loss > $5m OR regulatory fine OR material adverse customer impact

Repeat for Regulatory, Reputational, Customer and Operational. The thresholds should be calibrated to your organisation's size and risk appetite.

What to avoid

Avoid free-text impact ratings. "Financial impact is bad" tells no one anything. The matrix-driven approach forces specificity.

Avoid optimistic RTOs. The process owner often declares the RTO they wish were true. Cross-check against infrastructure capability.

Avoid hidden assumptions. Workarounds that assume "the call centre will pick up the load" are only credible if the call centre BIA confirms the capacity exists.

Avoid stale dependency maps. Cross-check against the application inventory and vendor register at every refresh. Things move.

The BCP handshake

The BIA record is one half of a handshake. The other half is the BCP. The BCP inherits the RTO and RPO from the BIA, and its activation criteria are validated against the dependency map (which dependency failures should trigger this plan?). See our §8.4.4 article for the BCP side.

For the broader BIA methodology, return to the BIA pillar guide. For the platform surface that ships this template as a structured workflow, see the BCMStack BIA module.