The Business Impact Analysis (BIA) is the foundation of any business continuity program. Without a properly conducted BIA, your continuity plan is just a collection of generic procedures disconnected from your actual business stakes. This guide details the step-by-step methodology, with a template you can use immediately in your organization.
What is a BIA?
The BIA is the process that:
- Identifies the organization's critical activities (business processes, IT services, support functions)
- Measures the impact of an interruption of each of these activities over time
- Calibrates recovery objectives: RTO (Recovery Time Objective), RPO (Recovery Point Objective), MTPD (Maximum Tolerable Period of Disruption)
- Maps dependencies: human resources, information systems, suppliers, facilities
- Defines recovery priorities in case of a major incident
The BIA is mandatory under ISO 22301 (clause 8.2.2), DORA (article 11.6), and implicit in NIS2 (article 21.2.c). It is also the methodological backbone for building consistent BCP, DRP, and CMP plans.
BIA vs Risk Analysis: don't confuse them
BIA and risk analysis are complementary but distinct:
| Aspect | BIA | Risk Analysis |
|---|---|---|
| Question | What do we lose if this activity stops? | What threats are on this activity? |
| Focus | Impact (consequences) | Probability × impact |
| Timing | Evolution of impact over time (1h, 4h, 1d, 1wk) | Snapshot at defined horizon |
| Output | RTO, RPO, MTPD, MBCO | Risk register, treatment |
| Methodological order | Done first | Informed by BIA |
Both feed each other: a BIA identifies critical activities; risk analysis determines which threats to address in priority for these activities.
The 7 steps to a successful BIA
Step 1 — Define the scope
Before analyzing anything, set:
- Organizational scope: a subsidiary? the entire company? a geographic site?
- Functional scope: IT only? all business processes?
- Granularity: macro-process level (accounting) or unit activities (payroll issuance, supplier payment)?
- Strategic objective: ISO 22301 certification? NIS2 response? internal resilience optimization?
A too-wide BIA becomes unmanageable; a too-narrow BIA misses cross-cutting dependencies. Aim for 50 to 200 activities depending on organization size.
Step 2 — Identify activities
Two complementary approaches:
Top-down: start from the organizational chart or process map. List level-1 processes then break them down into level-2 activities.
Bottom-up: interview team leads to inventory the concrete activities they manage day-to-day.
For each activity, document:
- Clear short name (verb + object: "Issue customer invoices")
- Owner (name + role)
- Description in 2-3 sentences
- Department / business unit
- Presumed criticality (to be validated later)
Step 3 — Assess impacts
For each activity, estimate the impact of an interruption at different time horizons. The standard BIA impact dimensions:
- Financial — revenue loss, contractual penalties, additional costs
- Operational — inability to deliver products/services
- Reputational — brand image, negative media coverage
- Legal / regulatory — non-compliance, sanctions
- Human — people's safety, employee well-being
- Environmental — ecological impact, pollution
Suggested horizontal matrix:
| Activity | 1h impact | 4h impact | 1d impact | 1wk impact | 1mo impact |
|---|---|---|---|---|---|
| Issue customer invoices | Low | Low | Moderate | Critical | Catastrophic |
| Process web orders | Moderate | Critical | Catastrophic | — | — |
| Manage HR / payroll | Low | Low | Low | Moderate | Critical |
Use a qualitative scale (Low / Moderate / High / Critical / Catastrophic) or quantitative (€ amount) depending on organizational maturity.
Step 4 — Define RTO / RPO / MTPD
From time-based impacts, for each activity:
- MTPD (Maximum Tolerable Period of Disruption): duration of disruption beyond which consequences become unacceptable. It's an absolute ceiling, decided by leadership.
- RTO (Recovery Time Objective): target duration within which the activity must be restored. Strictly less than MTPD (safety margin).
- RPO (Recovery Point Objective): maximum acceptable data loss. Expressed in time (e.g., "1 hour of data lost maximum").
- MBCO (Minimum Business Continuity Objective): acceptable degraded service level in continuity mode. Example: "process 30% of usual order volume."
For deeper reading on these concepts, see our dedicated article RTO vs RPO: understanding and calibrating.
Step 5 — Map dependencies
A critical activity always depends on 4 categories of resources:
- Human — key people, skills, roles
- Information systems — applications, infrastructure, networks, data
- Facilities — offices, factories, physical equipment
- Suppliers & partners — critical third parties, supply chain
For each activity, list dependencies specifying the criticality of each. An IS that fails can block 40 distinct activities: documenting these couplings is the main value-add of the BIA.
Step 6 — Calibrate with leadership
RTOs/RPOs extracted from BIA must be formally validated by leadership. It's not a formality: these objectives engage significant investments (redundancy, fallback sites, backups, contracts).
Present to leadership a summary table:
- Top 20 critical activities
- Proposed RTOs
- Estimated cost of compliance with each RTO
- Options (accept a longer RTO vs invest more)
Step 7 — Annual update
A BIA is never final. Activities, dependencies, and impacts evolve. ISO 22301 recommends at least annual updating, plus any significant change: acquisition, reorganization, product launch, major IS change.
BIA Template — Free Excel / Sheets template
Here are the columns to integrate into your BIA template:
| Column | Description | Example |
|---|---|---|
| ID | Unique identifier | ACT-042 |
| Activity | Short name | Issue customer invoices |
| Owner | Name + role | J. Smith, Finance Manager |
| Description | 2-3 sentences | Daily B2B billing… |
| Volume | Activity measure | 1,200 invoices/day |
| 1h financial impact | € | €5,000 |
| 4h financial impact | € | €25,000 |
| 1d financial impact | € | €150,000 |
| 1wk financial impact | € | €800,000 |
| Regulatory impact | Qualitative | Payment delay penalties |
| Reputational impact | Qualitative | Supplier disputes |
| MTPD | Duration | 5 days |
| RTO | Duration | 4 hours |
| RPO | Duration | 1 hour |
| MBCO | Degraded service | Manual billing 30% |
| IS dependencies | List | SAP FI, BusinessObjects |
| Human dependencies | List | Accounts Payable (2) |
| Facility dependencies | List | Paris HQ |
| Supplier dependencies | List | SAP vendor, Printer |
| Assessment date | Date | 2026-03-15 |
| Assessor | Name | M. Martin, Risk Manager |
ResiPlan natively includes a BIA module with this template, automatic integration to BCP/DRP plans, and cross-referenced dashboards (RTO vs current capability).
The 8 most common BIA mistakes
Mistake 1 — Confusing BIA and risk analysis
BIA is about impacts (consequences); risk analysis is about threats and their probability. Treating both in the same questionnaire creates methodological confusion.
Mistake 2 — Inappropriate granularity
Too fine: every sub-task becomes an activity, you drown in information. Too coarse: "manage sales" allows no concrete action. Target 50 to 200 activities for an organization of 200-2000 employees.
Mistake 3 — Not involving the business
A BIA built only by IT or the risk manager without business interviews is unusable. Impacts cannot be decreed from the CISO's desk; they must be validated by those who live the activity day-to-day.
Mistake 4 — Forgetting human resources
The simultaneous absence of 3 key people can block an activity even if all systems work. Mapping critical skills and human backups is often neglected.
Mistake 5 — Unrealistic RTOs
A 1-hour RTO decreed by leadership without technical feasibility verification (DRP, redundancy, recovery capabilities) creates false commitments. The BIA must confront business requirements with the reality of IT capabilities.
Mistake 6 — Underestimated cross-dependencies
Activity A depends on application X; activity B too; activity C too. If X fails, 3 activities stop simultaneously. These cascade effects must be visible in the BIA.
Mistake 7 — Not refreshing regularly
A 2023 BIA is obsolete in 2026. New products, new tools, new supplier contracts: without updates, the BIA becomes a dead document in a folder.
Mistake 8 — Not operationalizing
The BIA must feed BCP/DRP/IRP plans. An orphan BIA not used to design plans is wasted effort. ResiPlan automates this link: BIA RTO/RPO automatically become the objectives of associated plans.
BIA and regulations — who requires what
| Framework | BIA requirement | Reference |
|---|---|---|
| ISO 22301 | Explicit obligation | Clause 8.2.2 |
| DORA | Critical function impact analysis | Article 11.6 |
| NIS2 | Implicit (continuity measures Art. 21.2.c) | Art. 21 |
| NIST CSF 2.0 | "Identify" + "Recover" function | ID.BE, RC.RP |
| ISO 27001 (informational) | Implicit (clause 8.1) | Annex A.17 |
For organizations subject to multiple frameworks, a single BIA can satisfy all requirements if its methodology is rigorous.
How ResiPlan accelerates your BIA
Our BCMS platform includes:
- BIA module with pre-filled template + customizable business questionnaires
- Automatic RTO/RPO calculation based on impact responses
- Dependency mapping with network visualization (people, IS, places, suppliers)
- Sync with plans — BIA RTOs propagate to BCP/DRP
- BIA maturity dashboards by department, % coverage, last review date
- Leadership approval workflow integrated
Start a 14-day free trial to see the BIA module in action.
Conclusion
A rigorous BIA is the sine qua non condition of a robust continuity program. It is also an explicit obligation of ISO 22301, DORA, and implicit of NIS2. Investing 2-4 months in a complete initial BIA is widely recouped on the first incident avoided or contained.
The approach is methodological — top-down + bottom-up, 7 steps, structured template — but above all collaborative. The BIA is built with the business, not for it.
For deeper reading: