---
title: "Business Impact Analysis (BIA): Definition"
description: "Learn how to conduct a business impact analysis that satisfies ISO 27001, SOC 2, NIS2, and DORA requirements. Covers BIA methodology, RTO/RPO determination, critical process identification, and compliance evidence."
canonical: https://www.orbiqhq.com/glossary/business-impact-analysis
html: https://www.orbiqhq.com/glossary/business-impact-analysis
publisher: Orbiq GmbH
language: en
---
# Business Impact Analysis (BIA): Definition

Learn how to conduct a business impact analysis that satisfies ISO 27001, SOC 2, NIS2, and DORA requirements. Covers BIA methodology, RTO/RPO determination, critical process identification, and compliance evidence.


## What Is a Business Impact Analysis?

A business impact analysis (BIA) is a systematic process that identifies critical business processes, determines the impact of disruptions to those processes, and establishes recovery priorities and objectives. The BIA answers the fundamental question: if this process stops, what happens to the business and how quickly must it be restored?

For compliance-driven organisations, the BIA is a mandatory requirement under ISO 27001, SOC 2, NIS2, and DORA, forming the foundation for business continuity and disaster recovery planning.

## BIA Components

| Component | Description | Output |
| --- | --- | --- |
| **Process identification** | Catalogue all business processes and their owners | Process inventory with criticality ratings |
| **Impact assessment** | Determine financial, operational, and regulatory impact of disruption | Impact scores by process and timeframe |
| **Recovery objectives** | Define RTO and RPO for each critical process | Documented RTO/RPO targets |
| **Dependency mapping** | Identify systems, data, personnel, and supplier dependencies | Dependency matrix |
| **Resource requirements** | Determine resources needed for recovery | Recovery resource plan |
| **Minimum business continuity** | Define minimum acceptable service levels during disruption | Minimum operating requirements |

## Recovery Objectives

| Metric | Definition | Determines |
| --- | --- | --- |
| **RTO** | Maximum acceptable downtime before recovery | Recovery speed, infrastructure design |
| **RPO** | Maximum acceptable data loss | Backup frequency, replication strategy |
| **MTD/MTPD** | Maximum tolerable downtime before irreversible damage | Absolute recovery deadline |
| **WRT** | Work Recovery Time — time to verify and restore data after systems return | Total recovery timeline |
| **MBCO** | Minimum Business Continuity Objective — minimum acceptable service level | Degraded mode operations |

## Impact Categories

| Category | Measurement | Examples |
| --- | --- | --- |
| **Financial** | Revenue loss, penalties, recovery costs | €50,000/hour revenue loss, SLA penalties |
| **Operational** | Process disruption, productivity loss | 200 employees unable to work |
| **Regulatory** | Compliance violations, fines | NIS2 notification failure, GDPR breach |
| **Reputational** | Customer trust, brand damage | Media coverage, customer churn |
| **Contractual** | SLA breaches, partner obligations | Missed delivery commitments |
| **Legal** | Litigation, liability exposure | Negligence claims, regulatory action |

## BIA Methodology

| Phase | Activities | Deliverables |
| --- | --- | --- |
| **Planning** | Define scope, identify stakeholders, prepare questionnaires | BIA project plan, questionnaire templates |
| **Data gathering** | Interview process owners, review documentation, map processes | Completed questionnaires, process maps |
| **Analysis** | Assess impact over time, determine criticality, set RTO/RPO | Impact analysis report, criticality matrix |
| **Validation** | Review findings with stakeholders, verify dependencies | Validated BIA results |
| **Reporting** | Document findings, recommendations, and recovery priorities | BIA report with executive summary |
| **Maintenance** | Annual review, change-triggered updates | Updated BIA documentation |

## Criticality Classification

| Level | Description | RTO Target | RPO Target | Example |
| --- | --- | --- | --- | --- |
| **Critical** | Business-threatening if disrupted | < 4 hours | < 1 hour | Payment processing, customer-facing platform |
| **High** | Significant impact within hours | 4-24 hours | 1-4 hours | Email, CRM, ERP systems |
| **Medium** | Noticeable impact within days | 1-3 days | 24 hours | Internal reporting, HR systems |
| **Low** | Minimal short-term impact | 3-7 days | 24-48 hours | Training systems, archives |
| **Non-critical** | No immediate business impact | 7+ days | Weekly | Development environments |

## Compliance Requirements

### Framework Mapping

| Requirement | ISO 27001 | SOC 2 | NIS2 | DORA |
| --- | --- | --- | --- | --- |
| Business impact analysis | A.5.29 | A1.2 | Art. 21(2)(c) | Art. 11(5) |
| Recovery objectives (RTO/RPO) | A.5.30 | A1.2 | Art. 21(2)(c) | Art. 11(6) |
| Dependency mapping | A.5.29 | A1.2 | Art. 21(2)(d) | Art. 11(5) |
| Testing against objectives | A.5.30 | A1.3 | Art. 21(2)(c) | Art. 11(7) |
| Regular review | A.5.29 | A1.2 | Art. 21(2)(c) | Art. 11(5) |

### Audit Evidence

| Evidence Type | Description | Framework |
| --- | --- | --- |
| BIA report | Documented analysis of all critical processes | All frameworks |
| RTO/RPO register | Defined recovery objectives for all critical processes | All frameworks |
| Dependency matrix | Documented inter-process and system dependencies | All frameworks |
| Impact calculations | Quantified financial and operational impact per process | All frameworks |
| Stakeholder sign-off | Management approval of BIA findings and priorities | All frameworks |
| Test results | Evidence that recovery meets BIA objectives | ISO 27001, DORA |
| Review records | Evidence of annual BIA review and updates | All frameworks |

## Common Mistakes

| Mistake | Risk | Fix |
| --- | --- | --- |
| IT-only BIA | Misses business process dependencies and impact | Include business process owners and finance |
| Static BIA never updated | Recovery plans based on outdated business requirements | Annual review plus change-triggered updates |
| Unrealistic RTOs | Cannot achieve stated recovery objectives in practice | Validate RTOs through testing, align with actual capability |
| Missing dependencies | Recovery fails due to unknown upstream or downstream dependencies | Map all system, data, personnel, and supplier dependencies |
| No financial quantification | Cannot prioritise recovery investment | Calculate revenue loss, productivity loss, and penalties per hour |
| Ignoring supply chain | Third-party failures cause unplanned business disruption | Include critical suppliers and cloud services in BIA scope |

## How Orbiq Supports BIA Compliance

Orbiq helps you demonstrate business impact analysis controls:

- **Evidence collection** — Centralise BIA reports, RTO/RPO registers, and test results
- **Continuous monitoring** — Track recovery capability against BIA objectives
- **Trust Center** — Share your business continuity posture via your [Trust Center](/glossary/trust-center)
- **Compliance mapping** — Map BIA controls to ISO 27001, SOC 2, NIS2, and DORA
- **Audit readiness** — Pre-built evidence packages for auditor review

## Further Reading

- [Business Continuity Planning](/glossary/business-continuity-planning) — Building plans based on BIA findings
- [Disaster Recovery](/glossary/disaster-recovery) — Technical recovery to meet BIA objectives
- [Risk Management Frameworks](/glossary/risk-management-frameworks) — Risk assessment complementing BIA
- [Incident Response](/glossary/incident-response) — Responding to disruptions identified by BIA
- [Third-Party Risk Management](/glossary/third-party-risk-management) — Managing supplier dependencies from BIA