A recovery plan must speak business before technology
The disaster recovery plan (DRP) and the business continuity plan (BCP) are often seen as complex documents. Yet the starting discussion is very simple: what happens if the business loses its server, its internet access, its email, its line-of-business software or its files for a day?
A useful plan does not start with a technology. It starts with the business consequences: orders blocked, production stopped, invoicing impossible, customers not served, regulatory obligations not met.
DRP and BCP: two answers not to be confused
The two terms are often used together, but they do not cover the same thing. The business continuity plan aims to keep the business running during the incident, by switching to a degraded mode that lets people carry on working, even at a slower pace. The disaster recovery plan organises the return to normal after an outage: how to restore systems and data to get going again. One seeks never to stop, the other to restart cleanly.
A small business rarely needs both at the same level of sophistication. Most start with a solid recovery plan, able to ensure a reliable restart after an incident, before considering the heavier investment that genuine uninterrupted continuity requires. Knowing which of the two you are aiming for, and for which services, avoids oversizing the arrangements.
Why this can no longer wait
The cost of business interruption is now precisely documented, and it far exceeds the investment needed to guard against it: a major incident costs on average 1.7 million dollars in business interruption, not counting reputational damage. For a small business, on a much more modest scale, a ransomware attack easily runs into tens or even hundreds of thousands of euros, business interruption included.
One finding deserves particular attention: a significant share of ransomware victims had backups but could not restore them in full, often because they had never been tested or had themselves been compromised. A recovery plan that does not include a real restore test therefore remains a theoretical document, not effective protection.
RTO and RPO: two essential markers
The RTO (Recovery Time Objective) is the maximum acceptable time before a service is restored. If email can be unavailable for four hours but the ERP for only one, the priorities are not the same.
The RPO (Recovery Point Objective) is the amount of data the business accepts to lose. A daily backup may be enough for some files, but not for an order database updated throughout the day.
These two figures must be approved by management, not just by IT, because they commit budget and operational trade-offs that go beyond the technical scope.
Business impact analysis in practice
Before setting a single RTO or RPO figure, the most reliable method is to carry out a simplified business impact analysis (BIA). For each service or application, three questions structure the discussion with management:
What is the direct financial impact of one hour, one day, then one week of unavailability (lost orders, contractual penalties, stopped production)?
What is the impact on customer relationships (broken promises, damaged image, risk of losing a contract)?
Which legal or contractual obligations depend on this service (invoicing, regulatory filings, service commitments to customers)?
Carried out service by service rather than globally, this analysis often reveals surprising gaps: a tool that IT sees as secondary may turn out to be critical for invoicing, while an application users consider essential may tolerate several days of downtime with no real impact on the business.
The steps of a realistic plan
Identify the critical activities.
List the applications and dependencies they need.
Define an RTO and an RPO for each service.
Check backups and restores, in particular their isolation from a compromised administrator account, a weak point frequently exploited by attackers.
Plan the scenarios: ransomware, server failure, fire, internet outage, human error.
Document the roles: who decides, who restores, who communicates.
Test regularly on a limited scope.
What to avoid
A document that has never been tested gives false reassurance. The recovery plan must be confronted with reality: restore time, access to passwords, availability of hardware, external dependencies, supplier contacts. Every test reveals details no spreadsheet shows, which explains why nearly 4 organisations in 10 discover in a real situation that they cannot fully restore their data despite a written plan.
You should also avoid aiming for an unrealistic recovery level. A fifteen-minute RTO is expensive. If the business does not need it, it is better to invest in more useful measures: robust backups, monitoring, documentation and crisis procedures.
A simplified RTO/RPO matrix
For a typical small business, a first matrix might look like this:
Email and collaboration tools: RTO 4 hours, RPO 24 hours.
Line-of-business software or ERP: RTO 1 hour, RPO 4 hours.
Shared file server: RTO 24 hours, RPO 24 hours.
Brochure website: RTO 48 hours, RPO 24 hours.
These values are only a starting point: they must be adjusted service by service according to the real impact on the business, not a generic estimate.
The right starting point
For a small business, a scoping workshop is often enough to clarify the priorities: which services are vital, how long the business can hold out, which data is critical, and which measures already exist. The plan is then built step by step.
A matter for management, not just IT
The most widespread mistake is to hand the recovery plan entirely to IT, without business validation. The result is almost always the same: RTOs and RPOs set according to what is technically feasible, not according to what the business really needs. Yet these two figures commit budget trade-offs and priorities that are not technical matters: it is for management to say which services are vital and how much the business can afford to lose.
The right division of roles is clear. Management keeps the decisions on priorities and budget; an external provider can carry the technical implementation and the regular tests, particularly in a small business without an in-house IT department. What matters is that the plan reflects real business stakes, not just infrastructure constraints.
A plan is worth its tests, not its thickness
A recovery plan is not a document you write once to feel reassured. Its only real measure is the test: at least once a year for the whole plan, more often for the most critical services. It is by confronting it with reality, stopwatch in hand, that you discover the passwords nobody can find, the unavailable hardware or the forgotten dependency, details no spreadsheet reveals. It is better to start modestly, with the two or three most critical services, and extend from there, than to aim for completeness from day one.
To go further, read our guides on the IT audit and on the 3-2-1-1-0 backup rule.
Sources: CrowdStrike, 2025 Ransomware Report · NIST SP 800-34 Rev. 1, Contingency Planning Guide · ANSSI, IT hygiene guide
