Disaster Recovery Register

When a server fails, a data centre goes offline, or ransomware strikes, every minute counts. A.5.30 requires your organisation to plan, implement, and test ICT readiness for business continuity. The disaster recovery register documents how each critical service is restored — before the emergency happens.

What does it contain?

The template captures the information needed during a recovery event for each critical service:

• System / service — what is being restored? (e.g. ERP system, email server, database)
• Criticality — how business-critical is the service? (result of the business impact analysis)
• RTO (Recovery Time Objective) — how quickly must the service be restored?
• RPO (Recovery Point Objective) — how much data loss is acceptable at most?
• Recovery procedure — brief instructions or reference to the detailed runbook
• Backup location — where are the backups stored? (data centre, cloud region, offline medium)
• Responsible person — who performs the recovery?
• Last test — date and result of the last DR test
• Next test — planned date

How to use the template

1. Identify critical services. Start with the asset register and the business impact analysis. Every system with high criticality gets an entry in the DR register. Remember dependencies: if the ERP system depends on a specific database, the database needs its own entry.

2. Set RTO and RPO. For each service: what does executive management say? In practice, this often sparks discussion — the IT team considers 4 hours realistic, management expects 30 minutes. The register makes this gap visible.

3. Document recovery procedures. Each entry needs at least a reference to its runbook. In an emergency nobody reads a 40-page document — a checklist with the first ten steps is more valuable.

4. Test and document. A DR plan that has never been tested is a hypothesis. Schedule at least one annual test for every critical service. Record the date, scenario, result, and any deviations from the expected RTO/RPO.

5. Update after every test. If the test shows that recovery takes 6 hours instead of the planned 4, that belongs in the register — along with the measures to close the gap.

Register Template

Disaster Recovery Register

DEEN

.csv · EN.csv · DE

ID	System	Criticality	RTO	RPO	Backup Method	Backup Frequency	Backup Location	Runbook	Last Restore Test	Last Test Result	Next Test	Owner
DR-001	AST-001 Customer database	Critical	4h	15 min	Veeam snapshot + WAL shipping	Continuous	Primary DC + offsite	RB-DB-001	2026-02-15	Passed (restored in 2h50)	2026-05-15	IT Operations Lead
DR-002	AST-002 Logistics portal (SaaS)	Critical	4h	1h	Vendor-managed + exported data daily	Daily	Vendor + internal S3	RB-SAAS-002	2026-03-10	Passed	2026-06-10	Head of Ops
DR-003	AST-005 Domain controllers	Critical	2h	1h	System state backup	Daily	Primary DC + offsite	RB-AD-001	2026-01-20	Passed (1h30)	2026-04-20	IT Operations Lead
DR-004	AST-007 ERP (SAP B1)	High	8h	4h	Full backup + trans log	Every 4h	Primary DC + offsite	RB-ERP-001	2026-01-12	Passed (7h)	2026-04-12	CFO
DR-005	AST-008 Veeam	High	8h	1 day	Config export	Daily	Offsite	RB-BKP-001	2026-02-01	Passed	2026-05-01	IT Operations Lead
DR-006	AST-013 GitLab	High	8h	4h	Gitaly backup	Every 4h	Primary DC + S3	RB-GIT-001	2025-12-05	Passed (5h)	2026-06-05	Head of Engineering
DR-007	AST-009 SIEM	Medium	24h	24h	Index backup	Daily	Primary DC	RB-SIEM-001	2025-11-20	Passed	2026-05-20	ISO
DR-008	AST-003 M365 tenant	High	24h	24h	Third-party backup (Veeam for M365)	Daily	AWS S3	RB-M365-001	2026-03-01	Passed	2026-06-01	IT Operations Lead
DR-009	AST-015 HR database (Personio)	High	24h	24h	Vendor-managed + CSV export	Daily	Vendor + internal	RB-HR-001	2026-02-20	Passed	2026-05-20	HR Lead
DR-010	AST-017 Payroll	Critical	24h	24h	Vendor + encrypted archive	Monthly + on change	Vendor + internal vault	RB-PAY-001	2026-01-25	Passed	2026-07-25	CFO

Show full text

Sources

• ISO/IEC 27001:2022 A.5.30 — ICT readiness for business continuity
• BSI Standard 200-4 — Business Continuity Management