Disaster recovery plan (DRP): the checklist

Backup is not recovery

First confusion to clear: a backup copies your data, a recovery plan organizes the complete restart of your business. Having backups is not enough if you do not know in what order to restart systems, how long it will take, or who does what.

The DRP answers these questions in advance. It turns a panic situation into a known, rehearsed, timed procedure. The difference is measured in hours or weeks of downtime, and sometimes in business survival.

Thinking recovery rather than only backup shifts the perspective: you no longer ask only "do I have a copy?", but "am I able to restart, and how fast?". It is this second question that truly matters on the day.

Define RTO and RPO

Two indicators structure the whole plan. The RTO (Recovery Time Objective) is the maximum tolerable downtime: how long can you operate without this system before the consequences become serious? The RPO (Recovery Point Objective) is the acceptable data loss: how far back can you go without harm?

A critical application targets a short RTO (a few hours) and an RPO near zero (a few minutes of data lost at most). A secondary application tolerates looser targets. The art lies in setting these targets system by system.

These two figures determine architecture and budget: the more demanding they are, the more redundancy and backup frequency cost. Setting them clearly avoids both dangerous under-investment and useless over-engineering.

Tested backups, not just scheduled

A backup never restored is a hypothesis, not a guarantee. Too many businesses discover at the worst moment that their backups were corrupted, incomplete, or impossible to restore in an acceptable time. Scheduling is not enough; only restoration proves anything.

Adopt a 3-2-1 strategy and, above all, test restores regularly. A quarterly test on a representative sample reveals problems while they are still fixable, not in the middle of a crisis.

Use these tests to measure the real restore time. It is this, not the theoretical promise, that determines your actual downtime. Many businesses find that restoring several terabytes takes far longer than imagined.

Protect against ransomware with immutability

Modern ransomware actively seeks to encrypt your backups too, because it knows that is your safety net. An immutable backup, one that cannot be modified or deleted for a defined period, guarantees that a clean copy will always remain to restore, without giving in to extortion.

Combined with an offline or off-site copy, immutability is now a standard, not a luxury. It turns a potentially fatal attack into a manageable incident: you restore, you resume, you paid nothing.

Our cybersecurity and compliance page integrates this protection into a broader defence. Backup immutability is one of the best cost-to-benefit investments against today's dominant threat.

Redundancy and failover procedure

For critical systems, plan a standby environment able to take over. Failover, switching production to that standby, must be documented step by step and not improvised on the day of the incident, when stress causes mistakes.

Our managed hosting can integrate this high availability, sized to criticality. Not every application needs it; the point is to protect first what would cost the most if it stopped.

Also specify the return-to-normal procedure: once the incident is resolved, how do you switch back to the main environment without causing a new interruption? This step is frequently forgotten and causes a second outage, sometimes worse than the first.

Roles, contacts and priority order

In a crisis, improvisation is costly. Document who decides, who executes, and in what order services must be restored. Some systems must come back before others, for example authentication before the applications that depend on it.

List key contacts with up-to-date details: suppliers, host, insurer, internal resources. Keep this list accessible even if your network is down, for example printed or offline, because a DRP stored only on the failed system is useless.

Law 25 also requires an incident response plan: your DRP is its natural extension and covers a broader scope than just the personal information aspect, as our compliance page explains.

Insurance and the recovery plan

Cyber insurance increasingly intersects with disaster recovery. Insurers now expect tested backups, a documented response plan and basic security controls before granting coverage, and they may ask for proof after an incident. A solid DRP is therefore not only operational protection but also a condition of insurability.

That said, insurance never replaces the plan. A payout helps absorb costs afterwards, but it does not restart your systems, recover your data or reassure your clients in the critical hours. Only a rehearsed recovery plan does that, which is why the two are complements, not alternatives.

Align the two deliberately: make sure your DRP satisfies your policy's requirements, and that your coverage matches the real downtime cost the plan is designed to limit. Reviewed together, they form a coherent safety net rather than two disconnected reassurances.

Communicate during the crisis

An IT disaster is not just a technical problem, it is also a communication challenge. Your clients, employees and sometimes authorities expect clear information. A lack of communication fuels anxiety and damages trust even more than the outage itself.

Prepare message templates in advance and identify who communicates, to whom and through which channel. Where personal information is affected, Law 25 also requires informing the individuals concerned in certain situations, within set deadlines.

Controlled, honest and prompt communication limits reputational damage. It shows the business has the situation in hand, which reassures far more than an awkward silence followed by late explanations.

The mistakes that ruin a recovery plan

The classic trap is the plan written once and then forgotten in a drawer. Environments evolve: a plan that is not updated quickly becomes inaccurate, and therefore useless at the critical moment. Regular review is not optional.

Another common mistake is storing the plan and contacts only on the systems likely to fail. If your recovery plan is accessible only on the downed server, it is worthless. Keep an offline copy.

Finally, many neglect to test a full restore, settling for checking that backups run. Yet only an end-to-end test reveals the real recovery time and the forgotten dependencies. Without a test, you have a hope, not a plan.

Adapt the plan to your size

A recovery plan need not be a tome of procedures worthy of a multinational. For an SMB, the point is to have a short, clear, up-to-date document covering the genuinely likely scenarios rather than an exhaustive list of improbable disasters. Two realistic, tested pages beat a hundred-page manual no one will ever open.

Focus on your vital systems: those whose stoppage halts the business or billing. For these, define precisely the RTO, the RPO, the restart order and the responsible people. The rest can follow a lighter treatment, which keeps the plan manageable and therefore actually used.

Support from a managed IT provider helps calibrate this effort. An experienced partner distinguishes the essential from the reassuring-but-superfluous, and tailors the setup to your means without selling you an overengineered machine you do not need.

Test the plan, or it does not exist

A DRP on paper is only worth something once tested. A yearly exercise at minimum simulates a realistic scenario and reveals blind spots: a forgotten password, an ignored dependency, a step far longer than expected, an unusable backup.

Each test improves the plan and trains the team. On the day of a real disaster, it is these rehearsed reflexes that make the difference between controlled recovery and disorderly catastrophe. You do not improvise calm under pressure; you prepare for it.

Ideally, vary the scenarios tested: loss of a server, a ransomware attack, datacenter unavailability. Each type of disaster calls for different responses, and a robust plan has anticipated them all at least once.

FAQ