A disaster recovery plan (DRP) is the IT part of staying in business: it says exactly how your systems and data are restored after a ransomware attack, server failure, fire or cloud outage, in what order, by whom and how fast. This page gives you a template you can use today, a runbook layout and a testing checklist. ERS IT Solutions has run backup and disaster recovery for Irish businesses from Blanchardstown, Dublin 15 since 1983. Our fastest disaster recovery return to operations is 45 minutes.
What is a disaster recovery plan?
A disaster recovery plan is a written, tested procedure for restoring IT systems, applications and data after a serious outage. It covers servers, Microsoft 365, line-of-business software, network and internet, phones and the website. It sets recovery targets for each system and lists the technical steps to meet them.
The importance of a disaster recovery plan is simple: without one, recovery depends on whoever happens to be on shift remembering how everything was built. Ireland's NCSC tells organisations to "have a plan" for a ransomware attack and to "test the plan" (NCSC Ransomware Quick Guide).
The benefits of a disaster recovery plan are practical: shorter outages, less data lost, no guesswork under pressure, evidence for insurers and auditors, and a clear budget conversation, because each recovery target has a cost attached. A DRP is also the standard procedure document (some firms call it a disaster recovery SOP) that new IT staff or a new provider can pick up.
Disaster recovery vs business continuity: what is the difference?
By definition, business continuity is about keeping the whole business running: people, premises, suppliers, customers and IT. Disaster recovery is the IT chapter inside it: getting systems and data back.
| Business continuity plan | Disaster recovery plan | |
|---|---|---|
| Question it answers | How do we keep serving customers? | How do we get IT back? |
| Covers | Staff, premises, suppliers, communication, IT | Servers, cloud, data, network, applications |
| Owner | Director | IT lead or IT provider |
| Key measure | Maximum tolerable downtime per business function | RTO and RPO per system |
A disaster recovery and business continuity plan work together. The business continuity plan decides which functions matter most; the disaster recovery plan restores the systems behind them in that order. Our business continuity plan template covers the wider plan.
Business resilience vs disaster recovery
Business resilience, or operational resilience, is the broad ability to absorb disruption and keep going. Disaster recovery is one tool for it. A resilient business also has cloud systems staff can reach from anywhere, more than one internet connection and procedures that do not depend on one person.
Disaster recovery vs high availability
High availability keeps a system running through a single failure, for example two servers in a cluster or a cloud service spread across availability zones. Disaster recovery restores systems after something bigger: ransomware, a site loss or corrupted data. High availability does not protect against ransomware, because encrypted data replicates to the second server instantly. You need both, and offline backups underneath.
Disaster recovery plan steps
Building a DR plan takes seven steps:
- Inventory. List every system, where it runs, who supports it and what depends on it.
- Set RTO and RPO. Agree with the business how quickly each system must be back (RTO) and how much data you can afford to lose (RPO).
- Assess risks. Ransomware, hardware failure, cloud account compromise, site loss, supplier failure.
- Design recovery. Backups that meet the RPO, at least one copy offline, and a recovery method that meets the RTO.
- Write the runbook. Step-by-step restore instructions for each system.
- Test. Restore real systems and time it.
- Review. After every test, change and incident.
IT disaster recovery plan template
Copy this structure. Keep it in two places: your document system and a printed or offline copy, because the plan must be readable when the servers are down.
1. Plan control
- Version, date, owner, approver, next review date
- Distribution list and where copies are stored
2. Scope and recovery objectives
| System | Business owner | Hosted where | RTO | RPO | Backup method | Restore priority |
|---|---|---|---|---|---|---|
| Microsoft 365 (email, Teams, SharePoint) | Operations | Microsoft cloud | 4 hours | 24 hours | Third-party or Microsoft 365 Backup | 1 |
| Identity (Entra ID, admin accounts) | IT | Microsoft cloud | 2 hours | n/a | Documented config, break-glass accounts | 1 |
| Accounts package | Finance | Server or SaaS | 8 hours | 4 hours | Image backup plus offline copy | 2 |
| File server | All staff | On site | 1 day | 24 hours | Image backup, cloud copy | 3 |
| Website | Marketing | Hosting provider | 2 days | 24 hours | Host backups plus own copy | 4 |
3. Roles and contacts
- DR lead and deputy, with mobiles
- IT provider emergency number
- Key vendors: internet provider, accounts software vendor, Microsoft support route
- Business decision-maker who approves invoking the plan
4. Invocation
- What counts as a disaster (for example, a critical system down beyond half its RTO, or any confirmed ransomware)
- Who declares it and how the team is assembled
- First actions: isolate affected devices, preserve evidence, stop backups overwriting good copies
5. Recovery runbook
For each system, in restore priority order:
- Pre-checks (is the threat contained, is the backup clean)
- Restore steps, with screenshots or commands
- Where credentials are stored (password manager with offline access)
- How to verify it works (log in, open a test file, run a report)
- Who signs off that it is back
6. Communication
- Internal updates every hour during recovery
- Customer and supplier holding statements
- Data Protection Commission notification if personal data is affected
7. Return to normal
- Move back from any temporary systems
- Check data written during the outage is kept
- Post-incident review within two weeks
8. Testing log
Date, test type, systems tested, time to restore, issues found, actions and owners.
What is a disaster recovery runbook?
A runbook is the step-by-step part of the plan for one system: the exact clicks, commands and checks to restore it. Write it so a competent engineer who has never seen your environment could follow it at 3am. A DR playbook usually means the higher-level decision guide (which runbook to use, in what order, for which scenario).
Network and server disaster recovery
A network disaster recovery plan holds the firewall configuration backup, switch configs, the internet provider's fault line, a spare router or 4G failover and a network diagram. Without the firewall config, rebuilding remote access can take a day on its own.
A server disaster recovery plan covers image backups of each server, how to restore to new hardware or to the cloud, licence keys and the boot order (domain controller first, then database, then applications). Excel Industries, an ERS client, moved to replicated backups with standby virtual servers so recovery time became "minutes rather than hours/days" (Excel Industries case study).
Cloud disaster recovery plan
Moving to Microsoft 365 or Azure does not remove the need for a DR plan. Microsoft's shared responsibility model is clear that, whatever the service, "you own your data and identities" (Microsoft Learn). A cloud disaster recovery plan example for a typical Irish SME covers:
- Backup of Microsoft 365 mail, OneDrive and SharePoint beyond the 93-day recycle bin (Microsoft Support)
- Recovery of a compromised admin account, with break-glass accounts stored offline
- Azure virtual machines backed up or replicated to a second region. Azure's North Europe region is in Ireland and is paired with West Europe in the Netherlands (Microsoft Learn)
- A plan for the website and DNS if the hosting company fails
See our guide to cloud backup for business for options and pricing.
Disaster recovery plan for a website
Keep your own copy of the website files and database, not only the host's backups, plus the domain registrar login, DNS records and SSL details. Write down how to point the domain at a new host. If the site takes orders or bookings, give it its own RTO in the plan.
Data centre disaster recovery best practices
If you run servers in a data centre or comms room, the same rules scale up: keep backups in a different location from production, keep one copy offline or immutable, replicate critical systems to a second site or cloud region, document power and network dependencies, and test failover at least once a year. Information systems disaster recovery plans for larger estates add a recovery order for shared services such as identity, DNS and storage before any application.
How to test a disaster recovery plan
Test in increasing order of effort. Each test should produce a short test report.
Disaster recovery testing checklist
- Backups completed successfully every night this month, with alerts checked
- One file and one mailbox restored this quarter
- One full server or virtual machine restored to an isolated network this year, and timed against its RTO
- Offline backup copy confirmed as present and unreachable from the network
- Admin and break-glass credentials work and are stored offline
- Contact list current
- Tabletop exercise held for a ransomware scenario this year
- Actions from the last test closed
Disaster recovery test plan and report template
A disaster recovery test plan states the scenario, systems in scope, success criteria (for example, "accounts package usable within 8 hours with data no older than 4 hours"), who takes part and how the test is isolated from live systems. The test report records start and finish times, what worked, what failed, the actual RTO and RPO achieved and the actions with owners and dates.
How often should a disaster recovery plan be tested?
Restore files and mailboxes every quarter, restore at least one full system every year and run a tabletop exercise at least once a year. Test again after any major change, such as a server replacement or a move to the cloud. GDPR Article 32 asks for "a process for regularly testing, assessing and evaluating the effectiveness" of security measures (GDPR Article 32).
Disaster recovery policy template
A disaster recovery policy is a one-page management statement. A simple IT disaster recovery policy sample:
- The company will maintain a documented IT disaster recovery plan covering all critical systems.
- Each critical system will have an agreed RTO and RPO, approved by its business owner.
- Backups will follow the 3-2-1 rule, with one copy offline.
- Restores will be tested at least quarterly and the full plan at least annually.
- The plan will be reviewed annually and after any significant change or incident.
- The managing director owns this policy; IT (or the IT provider) maintains the plan.
A backup and disaster recovery policy often combines the backup schedule, retention periods and restore testing into the same document.
Disaster recovery requirements: what do you need?
At a minimum: an inventory of systems, agreed RTO and RPO, backups that meet them with one offline copy, documented restore steps, offline access to credentials, a contact list and a test record. If you fall under NIS2, Article 21 lists "business continuity, such as backup management and disaster recovery, and crisis management" among the required measures (NIS2 Article 21).