Freitagabend: Der Datenbankserver mit den Auftragsdaten fällt aus. Der IT-Leiter startet die Wiederherstellung aus dem Backup — und stellt fest, dass die letzte erfolgreiche Sicherung 72 Stunden alt ist. Drei Tage Aufträge sind verloren. Das Backup-Monitoring hatte seit Wochen Fehler gemeldet, die niemand bearbeitet hat. A.5.30 fordert, dass die IKT-Infrastruktur auf definierte Wiederherstellungsziele vorbereitet und regelmäßig getestet wird.
Was verlangt die Norm?
- BIA durchführen. Die Organisation identifiziert kritische Geschäftsprozesse und die unterstützenden IKT-Dienste, um RTO und RPO festzulegen.
- Kontinuitätspläne erstellen. Für jeden kritischen IKT-Dienst existiert ein dokumentierter Plan, der beschreibt, wie die Wiederherstellung innerhalb der definierten Ziele erfolgt.
- Redundanz und Backup sicherstellen. Die technische Infrastruktur (Backup-Systeme, redundante Komponenten, Ausweichstandorte) unterstützt die Wiederherstellungsziele.
- Regelmäßig testen. Kontinuitätspläne werden durch Tests validiert — von einfachen Backup-Restore-Tests bis zu vollständigen Failover-Übungen.
In der Praxis
RTO/RPO pro System definieren. Basierend auf der BIA: Für jedes kritische System werden RTO und RPO festgelegt und von der Geschäftsführung genehmigt. Die Ziele bestimmen die technische Lösung: RPO 0 erfordert synchrone Replikation, RPO 24h reicht mit täglichem Backup.
Backup-Strategie an RPO anpassen. 3-2-1-Regel als Minimum: 3 Kopien, 2 verschiedene Medien, 1 Kopie offsite. Für kritische Systeme: automatisiertes Backup-Monitoring, verschlüsselte Speicherung, regelmäßige Restore-Tests.
Disaster-Recovery-Plan pro System erstellen. Jeder Plan beschreibt: Wiederherstellungsreihenfolge, benötigte Ressourcen, verantwortliche Personen, Schritt-für-Schritt-Anleitung, Kommunikation. Der Plan muss auch ohne das betroffene System zugänglich sein (Offline-Kopie).
Jährliche DR-Tests durchführen. Teste die tatsächliche Wiederherstellung: Restore aus Backup, Failover auf Ausweichsystem, Validierung der Datenintegrität. Messe die reale Wiederherstellungszeit und vergleiche sie mit dem RTO. Abweichungen lösen Verbesserungsmaßnahmen aus.
Typische Audit-Nachweise
Auditoren erwarten bei A.5.30 typischerweise diese Nachweise:
- Business Impact Analysis — Bewertung der kritischen Prozesse und IT-Dienste (→ BIA im Starter Kit)
- RTO/RPO-Definitionen — genehmigte Wiederherstellungsziele pro System
- Disaster-Recovery-Pläne — Wiederherstellungsverfahren für kritische Systeme (→ DR-Register im Starter Kit)
- DR-Testprotokolle — Ergebnisse der Wiederherstellungstests mit Soll-Ist-Vergleich
- Backup-Monitoring — Nachweis der laufenden Backup-Überwachung
KPI
% der kritischen IKT-Systeme mit dokumentierten und getesteten Kontinuitätsplänen
Gemessen an der BIA: Wie viele der als kritisch identifizierten Systeme haben einen dokumentierten DR-Plan, der im letzten Jahr erfolgreich getestet wurde? Ziel: 100%. Systeme ohne Plan oder ohne Test senken den Wert.
Ergänzende KPIs:
- Anteil der DR-Tests, bei denen RTO eingehalten wurde
- Anteil der DR-Tests, bei denen RPO eingehalten wurde
- Anzahl der fehlgeschlagenen Backup-Jobs im letzten Monat
BSI IT-Grundschutz
A.5.30 mappt auf die BSI-Anforderungen zum Notfallmanagement:
- DER.4 (Notfallmanagement) — fordert Notfallvorsorge für IT-Systeme, einschließlich Redundanz, Backup und Wiederherstellungspläne.
- BSI-Standard 200-4 (Business Continuity Management) — detaillierte Methodik mit BIA, Notfallstrategie und Übungsplanung.
Verwandte Kontrollen
A.5.30 ist die technische Grundlage für Geschäftskontinuität:
- A.5.29 — IS während einer Störung: Die Sicherheitsperspektive der Kontinuität.
- A.5.24 — Planung des Vorfallmanagements: Vorfallmanagement als Voraussetzung für die Aktivierung des DR-Plans.
- A.5.9 — Inventar von Informationswerten: Das Asset-Inventar bildet die Basis für die BIA.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.5.30 — IKT-Bereitschaft für Geschäftskontinuität
- ISO/IEC 27002:2022 Abschnitt 5.30 — Umsetzungshinweise
- BSI IT-Grundschutz, DER.4 — Notfallmanagement