Disaster-Recovery-Register

Wenn ein Server ausfällt, ein Rechenzentrum nicht erreichbar ist oder Ransomware zuschlägt, zählt jede Minute. A.5.30 verlangt, dass deine Organisation die IKT-Bereitschaft für die Geschäftskontinuität plant, umsetzt und testet. Das Disaster-Recovery-Register dokumentiert für jeden kritischen Dienst, wie die Wiederherstellung abläuft — bevor der Ernstfall eintritt.

Was enthält das Register?

Die Vorlage erfasst für jeden kritischen Dienst die Informationen, die im Wiederherstellungsfall gebraucht werden:

• System / Dienst — was wird wiederhergestellt? (z.B. ERP-System, E-Mail-Server, Datenbank)
• Kritikalität — wie geschäftskritisch ist der Dienst? (Ergebnis der Business-Impact-Analyse)
• RTO (Recovery Time Objective) — wie schnell muss der Dienst wiederhergestellt sein?
• RPO (Recovery Point Objective) — wie viel Datenverlust ist maximal akzeptabel?
• Wiederherstellungsverfahren — Kurzanleitung oder Verweis auf das detaillierte Runbook
• Backup-Standort — wo liegen die Sicherungen? (Rechenzentrum, Cloud-Region, Offline-Medium)
• Verantwortliche Person — wer führt die Wiederherstellung durch?
• Letzter Test — Datum und Ergebnis des letzten DR-Tests
• Nächster Test — geplantes Datum

So nutzt du die Vorlage

1. Kritische Dienste identifizieren. Beginne mit dem Asset-Register und der Business-Impact-Analyse. Jedes System mit hoher Kritikalität bekommt einen Eintrag im DR-Register. Vergiss Abhängigkeiten nicht: Wenn das ERP-System von einer bestimmten Datenbank abhängt, braucht die Datenbank einen eigenen Eintrag.

2. RTO und RPO festlegen. Für jeden Dienst: Was sagt die Geschäftsleitung? In der Praxis entstehen hier oft Diskussionen — das IT-Team hält 4 Stunden für realistisch, die Geschäftsleitung erwartet 30 Minuten. Das Register macht diese Lücke sichtbar.

3. Wiederherstellungsverfahren dokumentieren. Jeder Eintrag braucht mindestens einen Verweis auf das zugehörige Runbook. Im Notfall liest niemand ein 40-seitiges Dokument — eine Checkliste mit den ersten zehn Schritten ist wertvoller.

4. Testen und dokumentieren. Ein DR-Plan, der nie getestet wurde, ist eine Hypothese. Plane für jeden kritischen Dienst mindestens einen jährlichen Test. Dokumentiere Datum, Szenario, Ergebnis und Abweichungen vom erwarteten RTO/RPO.

5. Nach jedem Test aktualisieren. Wenn der Test zeigt, dass die Wiederherstellung 6 Stunden dauert statt der geplanten 4, gehört das ins Register — zusammen mit den Maßnahmen, um die Lücke zu schließen.

Register-Vorlage

Disaster-Recovery-Register

DEEN

.csv · EN.csv · DE

ID	System	Kritikalität	RTO	RPO	Backup-Methode	Backup-Frequenz	Backup-Standort	Runbook	Letzter Restore-Test	Letztes Testergebnis	Nächster Test	Verantwortlich
DR-001	AST-001 Kundendatenbank	Kritisch	4 h	15 min	Veeam-Snapshot + WAL-Shipping	Fortlaufend	Primäres RZ + Offsite	RB-DB-001	2026-02-15	Bestanden (restauriert in 2 h 50)	2026-05-15	IT-Betriebsleitung
DR-002	AST-002 Logistikportal (SaaS)	Kritisch	4 h	1 h	Anbieterseitig + tägliche Datenexporte	Täglich	Anbieter + intern S3	RB-SAAS-002	2026-03-10	Bestanden	2026-06-10	Operationsleitung
DR-003	AST-005 Domain Controller	Kritisch	2 h	1 h	System State Backup	Täglich	Primäres RZ + Offsite	RB-AD-001	2026-01-20	Bestanden (1 h 30)	2026-04-20	IT-Betriebsleitung
DR-004	AST-007 ERP (SAP B1)	Hoch	8 h	4 h	Vollbackup + Transaktionslog	Alle 4 h	Primäres RZ + Offsite	RB-ERP-001	2026-01-12	Bestanden (7 h)	2026-04-12	CFO
DR-005	AST-008 Veeam	Hoch	8 h	1 Tag	Konfig-Export	Täglich	Offsite	RB-BKP-001	2026-02-01	Bestanden	2026-05-01	IT-Betriebsleitung
DR-006	AST-013 GitLab	Hoch	8 h	4 h	Gitaly-Backup	Alle 4 h	Primäres RZ + S3	RB-GIT-001	2025-12-05	Bestanden (5 h)	2026-06-05	Head of Engineering
DR-007	AST-009 SIEM	Mittel	24 h	24 h	Index-Backup	Täglich	Primäres RZ	RB-SIEM-001	2025-11-20	Bestanden	2026-05-20	ISB
DR-008	AST-003 M365-Tenant	Hoch	24 h	24 h	Drittanbieter-Backup (Veeam for M365)	Täglich	AWS S3	RB-M365-001	2026-03-01	Bestanden	2026-06-01	IT-Betriebsleitung
DR-009	AST-015 HR-Datenbank (Personio)	Hoch	24 h	24 h	Anbieterseitig + CSV-Export	Täglich	Anbieter + intern	RB-HR-001	2026-02-20	Bestanden	2026-05-20	HR-Leitung
DR-010	AST-017 Lohndaten	Kritisch	24 h	24 h	Anbieter + verschlüsseltes Archiv	Monatlich + bei Änderung	Anbieter + interner Tresor	RB-PAY-001	2026-01-25	Bestanden	2026-07-25	CFO

Vollständig anzeigen

Quellen

• ISO/IEC 27001:2022 A.5.30 — IKT-Bereitschaft für die Geschäftskontinuität
• BSI-Standard 200-4 — Business Continuity Management