Business Impact Analyse (BIA)
A systematic analysis of the impact of critical business process failures on the company. The BIA determines the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each process—serving as the basis for business continuity plans and backup strategies.
Business Impact Analysis (BIA) is the systematic assessment of the consequences of business interruptions. It answers the question: "What happens if System X goes down for 1 hour / 1 day / 1 week?"—and forms the basis for all BCM (Business Continuity Management) measures.
Key Metrics of BIA
RTO (Recovery Time Objective):
- What is the maximum allowable downtime for a process/system?
- Example: ERP system: RTO = 4 hours
- Anything beyond that = financial/reputational damage
RPO (Recovery Point Objective):
- How much data loss is tolerable?
- Determines backup frequency
- Example: Customer database: RPO = 1 hour
- Backup interval must be ≤ RPO!
RTO and RPO per Process (Examples)
| Process | RTO | RPO |
|---|---|---|
| Payment processing | 1h | 15 min |
| 4h | 1h | |
| ERP system | 8h | 4h |
| Website (Marketing) | 24h | 24h |
| Archive data | 72h | 24h |
| Development Environment | 5 days | 1 day |
Conducting a BIA - Step by Step
Step 1: Identify Critical Business Processes
Method: Workshops with process owners
Typical critical processes:
- Production/Manufacturing: Production control, quality assurance
- Sales: CRM, quote generation, order processing
- Finance: Accounting, payment runs, monthly closing
- HR: Payroll (especially before payday!)
- Communication: Email, phone, video conferencing
- IT Infrastructure: Active Directory, DNS, DHCP
- External Communication: Website, Customer Portal
- Regulatory: Data Protection Processes, Compliance Reporting
Step 2: Quantify the Impact
Financial
- Loss of revenue per hour/day (directly measurable)
- Contractual penalties for SLA violations
- Recovery costs (IT + personnel)
- Example: E-commerce with €50,000 daily revenue = €2,083/hour of downtime
Reputational
- Loss of customers following an outage
- Media coverage
- Social media backlash
- Harder to quantify, but real
Regulatory
- GDPR: Availability of personal data
- NIS2: Mandatory reporting of significant security incidents
- Fines (Art. 83 GDPR: up to 4% of annual turnover)
Operational
- Manual emergency operation efforts
- Loss of employee productivity
- Delivery delays
BIA Assessment Matrix
| Impact 1h | Impact 8h | Impact 24h | RTO |
|---|---|---|---|
| Negligible | Minor | Significant | 24h |
| Minor | Significant | Critical | 8h |
| Significant | Critical | Critical | 4h |
| Critical | Catastrophic | Catastrophic | 1h |
Step 3: Map dependencies
Process → Dependent systems → Critical paths:
Example: Payment processing requires:
- ERP system (SAP)
- Database server
- Storage
- Database server
- Payment service provider API (external)
- Network connection (Internet)
- Authentication (Active Directory)
Critical dependency: > AD failure → ERP login impossible → Payment processing impossible. The RTO of AD must therefore be ≤ the RTO of the most critical dependent processes!
Identify Single Points of Failure (SPOF):
- Which systems lack redundancy?
- Which failure would halt multiple critical processes?
- SPOF = Priority for redundancy/high availability
From BIA to Solution
BIA Result → Backup Strategy
| RPO | Solution | Cost |
|---|---|---|
| 15 minutes | Continuous Data Protection (CDP), real-time database replication | high |
| 1 hour | Hourly incremental backups, snapshot-based backup | medium |
| 24 hours | Daily full backups, standard backup solution | low |
RTO → High-Availability Architecture
| RTO | Architecture |
|---|---|
| 1h | Active-passive cluster (automatic failover) |
| 4h | Warm standby (prepared backup system) |
| 24h | Cold standby (restore from backup) |
| 72h | Backup-restore (classic) |
3-2-1-1-0 Backup Rule
- 3: Three copies of the data
- 2: On two different media types
- 1: One copy offsite (geographically separate)
- 1: One copy offline/air-gapped (immutable!)
- 0: Zero recovery failures (test backups regularly!)
BIA and ISO 27001
ISO 27001:2022 implicitly requires BIA through:
- Control A.5.29: Information security during disruption
- Control A.5.30: ICT readiness for business continuity
- Control A.8.13: Information backup (RPO-based!)
- Chapter 8: Planning based on risk assessment
BCM Standards:
| Standard | Description |
|---|---|
| ISO 22301 | Business Continuity Management (dedicated standard) |
| BSI 200-4 | BSI standard for Business Continuity Management |
| NIST SP 800-34 | Contingency Planning Guide for Federal Systems |
For ISO 27001 certification:
- BIA does not have to formally comply with ISO 22301
- However: BCM plans must be based on risk assessment
- RTO/RPO must be defined and covered by a backup strategy
Backup Testing – The Often-Overlooked Step
> A backup without testing is worthless!
What to Test:
- Restore Test: Can I restore data?
- RTO Test: How long will it take to be back up and running?
- Completeness: Is all critical data backed up?
- Consistency: Is the data intact (not corrupted)?
Test Plan:
| Frequency | Test |
|---|---|
| Quarterly | Restore individual files/database tables |
| Semi-annually | Server restore to staging environment |
| Annually | Full DR test (entire infrastructure built from backup) |
| Event-based | After every infrastructure change |
Test Log (ISO 27001 Evidence):
Date: 2026-01-15
Tested: Backup from 2026-01-14 22:00
Result: 450 GB restored in 3:42h (RTO 4h ✓)
Data integrity: SHA256 checksums match ✓
Tester: Max Muster, IT Manager
Next test: 2026-04-15
