A DRP, or disaster recovery plan, describes how to get your IT systems running again after a disaster; a BCP, or business continuity plan, describes how to keep working while they are down. Contrary to popular belief, building a credible recovery plan does not require an enterprise budget: with cloud services, a 3-2-1 backup strategy and written, tested procedures, it is above all a matter of method.
DRP vs BCP: what is the difference in practice?
The BCP answers the question of how you keep serving customers during the crisis: backup telephony, temporary manual procedures, a 4G/5G fallback connection, working from another site. The DRP answers how you get the IT system back on its feet, in what order and how fast: restoring servers, data and access. For most SMBs, the reasonable goal is a solid DRP complemented by a few targeted continuity measures for vital processes — not the full apparatus of a banking operator.
RTO and RPO: the two numbers that drive everything
The RTO (Recovery Time Objective) is the maximum interruption you can accept: an RTO of 4 hours on invoicing means the tool must be restored within 4 hours. The RPO (Recovery Point Objective) is the amount of data you can afford to lose: a nightly backup gives an RPO of 24 hours — anything entered since the last backup may disappear.
In concrete terms: SaaS-hosted email targets an RTO of a few hours and a near-zero RPO; a file server can often tolerate an RTO of 8 hours and an RPO of 24 hours; an online store demands an RTO of one hour and an RPO of a few minutes on orders. Above all, remember that every reduction in RTO or RPO carries an increasing cost: these are economic dials to arbitrate, not technical feats to stack up. Writing these two numbers down for each critical system is the single most clarifying exercise of the whole approach.
A pragmatic five-step approach
1. Inventory what is genuinely critical
List your applications, data, hardware, access credentials and providers, then ask three questions for each: who uses it, which process stops without it, and what RTO and RPO are acceptable. In an SMB, the genuinely critical list rarely exceeds ten items — and that is where the effort should be concentrated.
2. Write down the disaster scenarios
Four or five scenarios cover the essentials: hardware failure of the main server, ransomware, fire or water damage on the premises, failure of a cloud provider, prolonged unavailability of the key person. For each scenario, describe the impact, how it would be detected, and the planned response.
3. Implement 3-2-1 backups
Three copies of your data, on two different media, one of them off-site — and ideally offline or immutable, to survive ransomware that would also encrypt connected backups. Cloud object storage has made this standard affordable: for SMB volumes, expect a few tens of euros per month.
4. Write actionable procedures
A useful DRP is not an 80-page binder: it is a set of quick-reference sheets. Who to call and in what order, where the passwords are (in an encrypted vault accessible even if the IT system is down), how to launch a restore, what to tell customers. Every sheet must be executable at 3 a.m. by someone under stress, possibly without the usual expert.
5. Test regularly
One backup restore tested every quarter, one full scenario exercise every year. Time it, note what went wrong, update the sheets. This cycle is what turns a document into a real capability. Involve a different person each time, so the knowledge does not rest on a single pair of shoulders.
The budget-friendly options that change the game
- The cloud as a fallback site: no need to fund a second server room; ready-to-boot machine images cost almost nothing while they are not running.
- Targeted replication: replicate only the critical data and services identified in step 1, not the entire IT estate.
- Well-chosen SaaS: email and collaboration tools hosted by a serious vendor shift part of the risk to a company whose core business it is — provided you also back up that data, which remains your responsibility.
- Documentation: it only costs time, and it is almost always what is missing on the day of the disaster.
The fatal mistake: the recovery plan that was never tested
An untested DRP is not a plan, it is a hypothesis. The classic surprises discovered on the day: backups silently corrupted or incomplete for months, the vault password known only to the one employee on holiday, a procedure referencing a decommissioned server, a restore that takes 30 hours where the RTO allowed 4. Every one of these problems can be caught in half a day of exercise. Compared with the cost of a multi-day business stoppage, it is probably the cheapest insurance available. A short debrief after each exercise, with dated notes, keeps the plan alive as the system evolves.
The good news is that a first credible recovery plan takes a few days of structured work, not several months. The most effective move is often to get support on the initial inventory and the first restore test: a technical partner who has lived through real recoveries will spot the blind spots you cannot see from the inside.