How to Create a Disaster Recovery Plan: A Step-by-Step Guide

A fire in the server room, a file server encrypted by ransomware, or a single faulty update can bring a business to a halt for hours or even days. The document that spells out in advance what gets restored, in what order, and by whom is the disaster recovery plan. A well-prepared DR plan keeps IT teams from improvising in the middle of a crisis and ties recovery time to measurable targets.

This guide covers how to create a disaster recovery plan: its purpose, how RTO and RPO targets are set, the step-by-step preparation process, sample plan sections, and how to test the plan. It also explains the difference between simply taking backups and having real recovery capability, and compares building your own disaster recovery site with using a DRaaS service.

What is a disaster recovery plan and why do you need one?

A disaster recovery plan is a set of written procedures for bringing IT infrastructure back into operation after an unexpected outage, within predefined limits for downtime and data loss. Its focus is technology: servers, databases, network connections, applications, and the order in which they are restored. A business continuity plan is a broader framework that also covers people, the supply chain, communications, and alternate work locations.

The U.S. National Institute of Standards and Technology’s NIST SP 800-34 Rev. 1 Contingency Planning Guide describes contingency planning for information systems as a process that starts with a business impact analysis, continues with preventive controls, and matures through regular testing. In other words, the plan is not a document you write once and shelve. The main types of disruption a plan should address are:

• Cyberattacks: Ransomware, data-wiping attacks, and unauthorized access.
• Hardware and infrastructure failures: Problems with storage arrays, servers, power supplies, or cooling.
• Human error: Accidentally deleted data, misconfigurations, or failed updates.
• Physical events: Fire, flooding, earthquakes, and extended power outages.
• Service provider outages: Loss of internet connectivity or a critical SaaS service becoming unavailable.

In a high-seismic-risk region like Türkiye, the chance that servers and backups kept in a single building are hit by the same event deserves separate attention during planning.

RTO and RPO: the plan’s measurable targets

Every DR plan rests on two core metrics. RTO (Recovery Time Objective) is the maximum time a system can take to return to service after an outage. RPO (Recovery Point Objective) defines the maximum acceptable data loss, measured in time; an RPO of four hours means losing the last four hours of data is tolerable.

RTO and RPO values are not set by IT’s best guess; they come from business units assessing the cost and impact of an outage. Giving every system the same target means either unnecessary cost or inadequate protection for critical systems. The table below shows a sample structure for classifying systems. The values are not binding; each organization should adapt them based on its own business impact analysis.

The lower the RTO and RPO, the greater the infrastructure investment required. That is why tiering is the most practical tool for balancing budget against risk.

How to create a disaster recovery plan: step by step

Regardless of company size, the preparation process goes through similar stages. Steps that a small business can complete in a few weeks may stretch over months in a multi-site organization.

1. Scope and ownership: Define which systems the plan covers, who owns the plan, and who has decision-making authority during a crisis.
2. Asset inventory: List servers, virtual machines, databases, applications, licenses, and the dependencies between them.
3. Business impact analysis (BIA): Assess how each business process would be affected by an outage, including financial and operational impact; RTO and RPO values come out of this analysis.
4. Risk assessment: Identify likely threats and how probable they are.
5. Recovery strategy: Match technical options such as backup, replication, a secondary site, or DRaaS to each system tier.
6. Writing procedures: Document step-by-step recovery instructions, restore order, and validation checks for each system.
7. Communication plan: Define who informs employees, customers, suppliers and, where required, regulators, and through which channels.
8. Testing and maintenance: Validate the plan through exercises and update it after every infrastructure change.

The step most often skipped is dependency analysis. Even if an application server comes back, the system is unusable if the authentication service, DNS, or license server is not ready. The recovery order must be built around these dependencies.

Disaster recovery plan example: what sections should the document include?

No standard template fits every organization exactly, but if you look at a good disaster recovery plan example, certain sections come up again and again. The following sections provide a basic skeleton that keeps the plan readable and actionable:

• Purpose, scope, and assumptions: The scenarios that trigger the plan and the systems it covers.
• Roles and contact list: The recovery team, backup contacts, and supplier and service provider contacts.
• Activation criteria: When a disaster is declared and who makes that call.
• System inventory and tiers: Priority order together with RTO and RPO targets.
• Recovery procedures: Technical steps for each system, where access credentials are stored, and validation checks.
• Failback procedure: How systems are moved back once the primary site is repaired.
• Test schedule and revision history: The date and results of the last exercise and the fixes made.

It also matters to keep a printed or offline copy of the plan. A plan stored on the corporate file server cannot be read when that server is unavailable.

Backups alone or a real DR plan? Common practice vs. the right approach

At many companies, common practice is to assume that nightly backups are enough for disaster recovery. A backup preserves a copy of the data; disaster recovery defines on what infrastructure, how quickly, and in what order that data becomes usable again. Restoring a multi-terabyte backup over a slow link can take days, which is often far beyond the RTO target.

The right approach treats backup as one component of the plan. The key differences between the two models can be summarized as follows:

• Common practice: Backups are kept in the same building and the same domain; restores have never been tried; no target time is defined.
• The right approach: Cloud backup moves copies to a different location, critical systems are replicated, restores are tested regularly, and restore times are compared against the RTO.
• Ransomware resilience: In the right approach, at least one backup copy is kept immutable or isolated from the network.

Backups are one of the first things ransomware attackers go after. A modern plan should include a backup layer that cannot be deleted or altered, such as immutable backup.

Your own disaster recovery site or DRaaS?

If you are targeting an RTO measured in minutes for critical systems, you need ready-to-run infrastructure at a secondary site. There are two ways to get it: build your own disaster recovery site, or consume that infrastructure as a service (DRaaS). An organization that builds its own site takes on a second data center space, hardware, licenses, connectivity, and the staff needed to keep that environment current.

In the DRaaS model, the replication target is cloud infrastructure in the service provider’s data center. As described in the Veeam Backup & Replication user guide, platforms like Veeam keep copies of virtual machines ready in the target environment and allow you to fail over to them when needed. You pay only for the capacity you need and do not carry the burden of hardware refreshes.

The deciding factors are the target RTO, data volume, regulatory requirements, and whether you have in-house expertise to manage such an environment. For many businesses a hybrid model makes sense: critical systems are continuously copied with cloud data replication, while less critical systems are only backed up.

Disaster recovery scenarios and drills: how do you test the plan?

An untested plan is just an assumption. Drills expose gaps in procedures, outdated access credentials, and unrealistic RTO targets before a real crisis does. Every drill should be built around a specific disaster recovery scenario, such as “power outage at the primary data center” or “file server encrypted by ransomware.”

Test methods differ in scope and risk:

• Tabletop exercise: The team walks through the plan’s steps verbally against a scenario; well suited to finding gaps in roles and communication.
• Partial restore test: Selected systems are restored from backup in an isolated environment and the time is measured.
• Failover test: Replicated systems are actually started at the secondary site and application integrity is verified.
• Full-scale exercise: A defined part of the production environment is moved to the secondary site as planned and then brought back.

At the end of each test, measured times should be compared with the targets, deviations recorded, and the plan revised. At least one full test a year, plus partial tests after infrastructure changes, is a good starting cadence.

Common mistakes and the right way

Most problems in plan preparation are procedural rather than technical. The following mistakes are among the most common reasons a plan fails in a crisis:

• Keeping backups in the same location: The right way is to have at least one copy in a geographically separate data center.
• Keeping admin credentials in one place: An attacker who reaches the backup console can delete every copy; use separate credentials and multi-factor authentication.
• Never testing restores: CISA’s #StopRansomware Guide recommends keeping offline, encrypted backups and regularly testing them as part of a recovery scenario.
• Not updating the plan: If new applications and servers are not added, the inventory quickly goes stale.
• Forgetting failback: The switch to the secondary site is planned, but the steps for returning to the primary site are never written down.

The common fix for all of these is a clearly named plan owner and plan reviews tied to a schedule.

Data location in Türkiye, KVKK, and business continuity

For organizations that process personal data, a disaster recovery plan is not just a technical document. KVKK (Türkiye’s Personal Data Protection Law, Law No. 6698) expects data controllers to take appropriate technical and administrative measures to keep personal data secure. Where backups and the replication target are located, who can access them, and whether data is transferred abroad are all part of that assessment.

Backup and replica copies kept in a Türkiye-based data center simplify cross-border transfer assessments and allow faster restores thanks to low latency. For Istanbul-based organizations, a copy kept in a different region or a different data center building adds a separate layer of protection against regional disasters. The information in this section is general in nature and does not constitute legal advice.

Disaster recovery with MAV Cloud: standards, SLA target, and process

When you entrust recovery infrastructure to a service provider, documented processes and independently audited standards are what matter. MAV Cloud holds ISO/IEC 27001, ISO/IEC 27701, ISO 9001, and ISO/IEC 20000 certifications, including ISO 22301, the standard for business continuity management systems. The key elements of the service approach are:

• Infrastructure: A Türkiye-based Equinix data center, VMware virtualization, and Veeam-based backup and replication.
• SLA target: A 99.9% monthly availability target; first-response targets of 15 minutes for critical requests and 1 hour for high-priority requests.
• Support and monitoring: 24/7 expert support and 24/7 system monitoring.
• Process: Inventory and business impact analysis, setting RTO and RPO targets, replication and backup setup, followed by scheduled drills.

The scope and technical details of the service are on the disaster recovery (DRaaS) service page.

Frequently asked questions

What is the difference between a disaster recovery plan and a business continuity plan?

A disaster recovery plan focuses on restoring IT systems and data. A business continuity plan is a broader framework that also covers people, the supply chain, communications, and alternate working arrangements; the DR plan is its technical component.

How do you determine RTO and RPO values?

They are determined through a business impact analysis. Together with business units, you assess how much downtime and data loss each business process can tolerate, then classify systems according to those tolerances.

How often should a disaster recovery plan be tested?

The generally accepted approach is at least one full-scale exercise a year, plus partial tests to validate the plan after major infrastructure changes. Critical systems can be tested more frequently.

Are backups alone enough for disaster recovery?

In most cases, no. A backup preserves a copy of the data, but unless restore time, target infrastructure, and recovery order are defined, you may not meet your RTO target. Critical systems need replication and ready-to-run infrastructure at a secondary site.

What is DRaaS and which businesses is it right for?

DRaaS means consuming disaster recovery infrastructure as a service from a provider. It suits businesses that do not want to build and manage a second data center but still aim for short recovery times for their critical systems.

Should the disaster recovery site be located in Türkiye?

For organizations that process personal data, a location in Türkiye simplifies cross-border transfer assessments and provides lower latency. The exact requirement depends on the sector and the type of data; a separate legal assessment should be carried out.

Is ISO 22301 required for a disaster recovery plan?

ISO 22301 is not a legal requirement; it is an international standard for business continuity management systems. When you choose a service provider, this certification shows that its business continuity processes have been independently audited.

How should a DR plan address a ransomware scenario?

The plan should describe how to identify a clean recovery point, where immutable backups are kept, and the steps for isolating affected systems. Scanning backups for malware before restoring should also be part of the procedure.

For organizations still researching the topic, the first step is to build a system inventory and ask what downtime is acceptable for each system. IT teams unsure which model fits can get a realistic starting point by restoring one of their existing backups in an isolated environment and timing it. Businesses ready to put the plan into action can work out the business impact analysis and DRaaS design with the MAV Cloud team.