Business Impact Analyse (BIA)
Systematische Analyse der Auswirkungen von Ausfällen kritischer Geschäftsprozesse auf das Unternehmen. Die BIA bestimmt Recovery Time Objective (RTO) und Recovery Point Objective (RPO) für jeden Prozess - Grundlage für Business Continuity Pläne und Backup-Strategien.
Business Impact Analyse (BIA) ist die systematische Erfassung der Folgen von Betriebsunterbrechungen. Sie beantwortet: “Was passiert wenn System X für 1 Stunde / 1 Tag / 1 Woche ausfällt?” - und bildet die Grundlage für alle BCM-Maßnahmen (Business Continuity Management).
Kerngrößen der BIA
RTO (Recovery Time Objective):
- Wie lange darf ein Prozess/System maximal ausfallen?
- Beispiel ERP-System: RTO = 4 Stunden
- Alles darüber = finanzieller/reputativer Schaden
RPO (Recovery Point Objective):
- Wie viel Datenverlust ist tolerierbar?
- Bestimmt Backup-Frequenz
- Beispiel Kundendatenbank: RPO = 1 Stunde
- Backup-Intervall muss ≤ RPO sein!
RTO und RPO pro Prozess (Beispiele)
| Prozess | RTO | RPO |
|---|---|---|
| Zahlungsabwicklung | 1h | 15 min |
| 4h | 1h | |
| ERP-System | 8h | 4h |
| Webseite (Marketing) | 24h | 24h |
| Archiv-Daten | 72h | 24h |
| Entwicklungsumgebung | 5 Tage | 1 Tag |
BIA durchführen - Schritt für Schritt
Schritt 1: Kritische Geschäftsprozesse identifizieren
Methode: Workshops mit Prozessverantwortlichen
Typische kritische Prozesse:
- Produktion/Fertigung: Fertigungssteuerung, Qualitätssicherung
- Vertrieb: CRM, Angebotserstellung, Auftragsabwicklung
- Finanzen: Buchhaltung, Zahlungsläufe, Monatsabschluss
- HR: Personalabrechnung (besonders vor Zahltag!)
- Kommunikation: E-Mail, Telefon, Videokonferenz
- IT-Infrastruktur: Active Directory, DNS, DHCP
- Externe Kommunikation: Website, Kundenportal
- Regulatorisch: Datenschutz-Prozesse, Compliance-Reporting
Schritt 2: Auswirkungen quantifizieren
Finanziell
- Umsatzausfall pro Stunde/Tag (direkt messbar)
- Vertragsstrafen bei SLA-Verletzung
- Wiederherstellungskosten (IT + Personal)
- Beispiel: E-Commerce mit €50.000 Tagesumsatz = €2.083/h Ausfall
Reputational
- Kundenverlust nach Ausfall
- Medienberichterstattung
- Social Media Shitstorm
- Schwerer zu quantifizieren, aber real
Regulatorisch
- DSGVO: Verfügbarkeit personenbezogener Daten
- NIS2: Meldepflicht bei erheblichen Sicherheitsvorfällen
- Bußgelder (Art. 83 DSGVO: bis 4% Jahresumsatz)
Operativ
- Manuelle Notbetrieb-Aufwände
- Mitarbeiter-Produktivitätsverlust
- Lieferverzögerungen
BIA-Bewertungsmatrix
| Auswirkung 1h | Auswirkung 8h | Auswirkung 24h | RTO |
|---|---|---|---|
| Vernachlässigbar | Gering | Erheblich | 24h |
| Gering | Erheblich | Kritisch | 8h |
| Erheblich | Kritisch | Kritisch | 4h |
| Kritisch | Katastrophal | Katastrophal | 1h |
Schritt 3: Abhängigkeiten kartieren
Prozess → Abhängige Systeme → Kritische Pfade:
Beispiel Zahlungsabwicklung benötigt:
- ERP-System (SAP)
- Datenbankserver
- Storage
- Datenbankserver
- Zahlungsdienstleister-API (extern)
- Netzwerkverbindung (Internet)
- Authentifizierung (Active Directory)
Kritische Abhängigkeit:
AD-Ausfall → ERP-Login unmöglich → Zahlungsabwicklung unmöglich. Der RTO von AD muss daher ≤ dem RTO der kritischsten abhängigen Prozesse sein!
Single Points of Failure (SPOF) identifizieren:
- Welche Systeme haben keine Redundanz?
- Welcher Ausfall stoppt mehrere kritische Prozesse?
- SPOF = Priorität für Redundanz/Hochverfügbarkeit
Von der BIA zur Lösung
BIA-Ergebnis → Backup-Strategie
| RPO | Lösung | Kosten |
|---|---|---|
| 15 Minuten | Continuous Data Protection (CDP), Datenbank-Replikation in Echtzeit | hoch |
| 1 Stunde | Stündliche Incremental Backups, Snapshot-basierte Sicherung | mittel |
| 24 Stunden | Tägliche Full Backups, Standard-Backup-Lösung | niedrig |
RTO → Hochverfügbarkeits-Architektur
| RTO | Architektur |
|---|---|
| 1h | Aktiv-Passiv Cluster (automatisches Failover) |
| 4h | Warm Standby (vorbereitetes Ersatzsystem) |
| 24h | Cold Standby (Wiederherstellung aus Backup) |
| 72h | Backup-Restore (klassisch) |
3-2-1-1-0 Backup-Regel
- 3: Drei Kopien der Daten
- 2: Auf zwei verschiedenen Medientypen
- 1: Eine Kopie offsite (geographisch getrennt)
- 1: Eine Kopie offline/air-gapped (immutable!)
- 0: Zero Recovery-Fehler (Backups regelmäßig testen!)
BIA und ISO 27001
ISO 27001:2022 fordert BIA implizit durch:
- Control A.5.29: Information security during disruption
- Control A.5.30: ICT readiness for business continuity
- Control A.8.13: Information backup (RPO-basiert!)
- Kapitel 8: Planung basierend auf Risikobeurteilung
BCM-Standards:
| Standard | Beschreibung |
|---|---|
| ISO 22301 | Business Continuity Management (dedizierter Standard) |
| BSI 200-4 | BSI-Standard für Business Continuity Management |
| NIST SP 800-34 | Contingency Planning Guide for Federal Systems |
Für ISO 27001-Zertifizierung:
- BIA muss nicht formell nach ISO 22301 sein
- Aber: BCM-Pläne müssen auf Risikobeurteilung basieren
- RTO/RPO müssen definiert und durch Backup-Strategie abgedeckt sein
Backup-Test - der oft vergessene Schritt
Ein Backup ohne Test ist wertlos!
Was testen:
- Restore-Test: Kann ich Daten wiederherstellen?
- RTO-Test: In welcher Zeit bin ich wieder oben?
- Vollständigkeit: Sind alle kritischen Daten gesichert?
- Konsistenz: Sind die Daten integer (kein Corrupt)?
Testplan:
| Frequenz | Test |
|---|---|
| Quarterly | Einzelne Dateien/Datenbank-Tabellen wiederherstellen |
| Halbjährlich | Server-Restore auf Staging-Umgebung |
| Jährlich | Full DR-Test (gesamte Infrastruktur von Backup aufgebaut) |
| Event-basiert | Nach jeder Infrastruktur-Änderung |
Test-Protokoll (ISO 27001 Nachweis):
Datum: 2026-01-15
Getestet: Backup vom 2026-01-14 22:00
Ergebnis: 450 GB wiederhergestellt in 3:42h (RTO 4h ✓)
Datenintegrität: SHA256 Checksums match ✓
Tester: Max Muster, IT-Leiter
Nächster Test: 2026-04-15
