RTO and RPO: defining and calculating your SME disaster recovery plan
RTO, RPO, DRP, BCP: clear definitions, calculation method, and tables by critical system. A practical guide for IT managers and SME leaders. By ECLAUD IT.
RTO and RPO: how to build your SME’s disaster recovery plan
Three concepts to understand before anything else:
- RTO (Recovery Time Objective): the maximum acceptable duration of downtime after an IT disaster
- RPO (Recovery Point Objective): the maximum amount of data you accept to lose, expressed in hours
- DRP (Disaster Recovery Plan): the plan that translates your RTO/RPO into concrete actions — backups, replication, recovery procedures, regular testing
Your email goes down on a Tuesday morning. Your ERP has been inaccessible for an hour. Your NAS is encrypted by ransomware. In those moments, two questions arise — and they need answers prepared in advance: how long can you operate without this system? How far back can you go to recover your data?
RTO and RPO measure exactly that. This guide gives you the method to calculate them, translate them into a disaster recovery plan, and meet regulatory requirements — notably the EU’s NIS2 directive, whose transposition into French law is expected by October 2026.
What are RTO and RPO in IT?
RTO and RPO are the two fundamental indicators of any IT continuity strategy. They express your tolerance for an incident — not as a feeling, but as numbers defined in advance.
RTO (Recovery Time Objective): definition and concrete example
The RTO measures the maximum time that can elapse between an incident and the complete restoration of a system. If your file server goes down at 9am and your RTO is 4 hours, teams must be able to access their files again by 1pm.
An RTO of 4 hours does not mean the outage will last 4 hours — it means you have designed your architecture to guarantee that deadline. The difference matters: an RTO is a technical commitment, not a hope.
Concrete examples:
- RTO 1h: redundant infrastructure with automatic failover. Solutions such as clustering, Azure Site Recovery, Veeam with Hot Standby.
- RTO 4h: VM replication with manual startup of the standby system.
- RTO 24h: full restore from backup onto new hardware or a cloud VM.
- RTO 72h: rebuild from scratch on replacement hardware.
RPO (Recovery Point Objective): definition and concrete example
The RPO measures the maximum acceptable amount of data loss, expressed as a duration. An RPO of 4 hours means the last usable backup cannot be more than 4 hours old.
Scenario: ransomware encrypts your ERP at 4:30pm. Your last backup was at noon. You lose 4.5 hours of entries, orders, and inventory movements. If your RPO was set at 4 hours, you have exceeded your target — and so have your clients.
The RPO depends directly on your backup frequency. Hourly snapshot = 1-hour RPO. Daily backup at 3am = potential RPO of 23 hours 59 minutes.
DMIA and PDMA: the French equivalents
In French normative documents and ISO audits, you may encounter two equivalent acronyms:
- DMIA (Duree Maximale d’Interruption Admissible) = RTO
- PDMA (Perte de Donnees Maximale Admissible) = RPO
These terms come from the ISO 22301 standard on business continuity management. IT teams almost exclusively use RTO and RPO in daily practice — but if your provider or auditor uses DMIA/PDMA, it is the same thing.
Stat Box — In 2025, the median cost of a ransomware attack for a French company was €1.3 million, including lost revenue, remediation, and reputational impact (CESIN, Cybersecurity Barometer 2025). For an SME, the absence of defined RTO/RPO transforms a manageable incident into an existential crisis.
What is the difference between RTO and RPO?
RTO and RPO measure two distinct dimensions of the same risk. Confusing them leads to inappropriate architectures — and surprises during the first real incident.
RTO / RPO comparison table
| Dimension | RTO | RPO |
|---|---|---|
| What it measures | Tolerable downtime duration | Tolerable data loss volume |
| Unit | Hours / minutes | Hours / minutes |
| Impact if exceeded | Lost revenue, client SLA breach | Data loss, rework, errors |
| Associated technique | Redundancy, failover, replication | Backup frequency, snapshots |
| Who feels it | Blocked users | Business functions (accounting, production, order management) |
| Question asked | ”When can we resume?" | "How far back can we go?” |
Application example: an SME under ransomware attack
It is 4:30pm on a Thursday. An employee opened an infected attachment two hours earlier. The ransomware silently encrypted all network shares. Email is still running (Microsoft 365, cloud), but the ERP, shared files, and NAS are out of service.
With an RPO of 4h and a noon backup: you lose 4.5 hours of data. Limit exceeded. With an RTO of 8h and a restore architecture ready: you restart before midnight. Objective met.
Without these two numbers defined and tested in advance, the decision to pay the ransom or not is made under pressure, in a rush, without reference points.
Are RTO and RPO independent?
No. A short RTO often requires a short RPO as well — and both drive costs upward. An SME can define an RTO of 2 hours for its ERP, but if the last clean backup is 12 hours old, the technical RTO will be met while the RPO will be missed.
Both indicators are sized together, system by system, starting from the Business Impact Analysis.
How to calculate your SME’s RTO and RPO?
Calculating RTO and RPO is not a 20-minute back-of-the-napkin exercise. It is a structured process in four steps, called a Business Impact Analysis (BIA). It is ideally conducted with the business owner, the finance lead, and the key business function representatives.
Step 1 — Business Impact Analysis (BIA): identify your critical systems
List all the IT systems used in your business. For each one, ask a single question: if this system is inaccessible tomorrow morning, when does it really start to hurt?
Recommended classification:
- Critical: downtime blocks commercial or operational activity within 4 hours
- High: downtime creates major disruptions beyond 4 hours
- Medium: downtime is inconvenient but manual workarounds exist
- Low: the business can continue for several days without this system
With our SME clients on Reunion Island, business owners regularly overestimate their tolerance for downtime. They think they can operate 48 hours without their ERP — the actual pain threshold is at 4-6 hours. The BIA exercise moves from gut feeling to figures validated by those who use the tools daily.
Step 2 — Estimate the cost of one hour of downtime per system
For each critical system, estimate the cost of one hour of downtime. Some starting points:
- Hourly revenue: if your annual revenue is €1.2M, one hour of downtime is worth roughly €140 in unrealized revenue. For a high-activity e-commerce site, the direct loss can be much higher.
- Remobilization cost: how many work hours will be needed to catch up on manual entry if the system restarts 8 hours later?
- Contractual penalties: do you have SLAs with your clients? Delivery deadlines to meet?
- Regulatory cost: an accounting system outage during closing period can generate tax penalties.
This figure does not need to be exact to the euro. It serves to prioritize: investing €500/month to protect a system whose downtime costs €5,000/hour is reasonable. For a system whose downtime costs €200/hour, the protection budget is different.
Step 3 — Define tolerable thresholds (target RTO and RPO)
Once the cost of downtime is estimated, the target RTO and RPO follow naturally:
- The target RTO is the delay beyond which the cost of downtime exceeds the cost of the protection solution.
- The target RPO is the data loss window beyond which rework or commercial loss becomes unacceptable.
Example: your ERP costs €800/hour of downtime. A VM replication solution guaranteeing a 4-hour RTO costs €200/month. The ROI is immediate from the first incident.
Step 4 — RTO/RPO summary table by application
The table below shows typical values observed for SMEs with 10 to 100 workstations. Your target values may differ based on your industry and risk tolerance.
| Application | Criticality | Target SME RTO | Target SME RPO | Recommended solution |
|---|---|---|---|---|
| Email (M365) | High | 2-4h | 1h | M365 native redundancy + Veeam/Datto backup |
| ERP / Line-of-business software | Critical | 4-8h | 4h | VM replication + daily snapshot |
| Accounting / Payroll | Critical | 24-48h | 24h | Daily backup + monthly test |
| Shared files (NAS/SharePoint) | High | 4-8h | 4h | 3-2-1 rule + immutable snapshot |
| Website (brochure) | Low | 24-72h | 24h | Host with automatic backup |
| E-commerce site | Critical | 1-2h | 30min | CDN + real-time replication |
| Active Directory | Critical | 2-4h | 1h | Secondary domain controller |
Key Takeaway — A 4-hour RTO for your email is not something you simply declare. It requires a standby architecture (redundant Microsoft 365, replication), documented procedures, and regular testing. Without testing, it is a theoretical objective — not a plan.
RTO and RPO examples for an SME (by system type)
Abstract values take on their full meaning when applied system by system. Here are the specific considerations for the most common applications in SMEs.
Email (Microsoft 365 / Exchange)
Microsoft 365 is natively redundant — Microsoft’s email servers display 99.9% uptime. But this availability does not protect against accidental mailbox deletion, data corruption, or unauthorized access to your emails from a compromised account.
For email, the relevant RPO is not “is my email responding” — it is “can I recover emails deleted 45 days ago.” Microsoft retains deleted items for 30 days by default. Beyond that, without a third-party backup solution, the data is gone.
Recommended RTO: 2-4h. Recommended RPO: 1h. Solution: Veeam Backup for Microsoft 365 or Datto SaaS Protection.
ERP / Line-of-business software (Sage, Cegid…)
The ERP is often the most critical and most complex system to restore. The database is large, dependencies are numerous (SQL server, Active Directory, licenses). A complete restore from backup can take 6 to 12 hours.
To achieve a 4-8 hour RTO, the effective solution is VM replication: a complete image of your ERP server is replicated hourly to a cloud host. In case of failure, the standby VM starts in 15-30 minutes.
Shared files (NAS / SharePoint)
The classic trap: the NAS is backed up to an external hard drive permanently connected. Ransomware encrypts both simultaneously. The 3-2-1 backup strategy addresses this risk — but only if the offsite copy is truly isolated from the network.
For SharePoint/OneDrive, the native recycle bin and versioning in Microsoft 365 allow restoring overwritten files for 30 to 180 days depending on configuration. For a mass restore (ransomware, disaster), a third-party solution remains necessary.
Accounting and payroll
Accounting has a particularity: a 48-hour interruption during a normal period is often manageable. During monthly closing, VAT filing, or payroll processing, the same 48-hour interruption can generate penalties, payment delays, and considerable rework burden.
Define your RTO/RPO taking the tax and payroll calendar into account: acceptable thresholds are not the same at quarter-end as in mid-month.
What is a Disaster Recovery Plan (DRP)?
A DRP is the operational document that translates your RTO and RPO into concrete actions. It is not a theoretical document read once a year — it is a set of procedures that your teams (or your provider) must be able to execute under stress, at 10pm on a Friday night.
DRP vs BCP: what is the difference for an SME?
| DRP | BCP | |
|---|---|---|
| Objective | Restore systems after a disaster | Maintain operations during the disaster |
| Accepted interruption | Yes (limited by the RTO) | None or very short |
| Complexity | Moderate | High |
| Cost | Accessible for SMEs | Often reserved for mid-size/large companies |
| Use case | Ransomware, hardware failure, physical disaster | Trading, medical emergencies, critical infrastructure |
For the vast majority of SMEs, the DRP is the appropriate response. The BCP is reserved for activities that cannot tolerate any interruption — which requires architecture costs multiplied by 3 to 5 compared to a DRP.
Minimum components of an effective DRP
An operational DRP contains at minimum:
- Critical systems inventory with defined RTO/RPO for each
- Backup mapping: where, what, how often, what retention
- Step-by-step recovery procedures: who does what, in what order, with which tool
- Crisis RACI matrix: responsible, accountable, consulted, informed — for each procedure
- Emergency contacts: IT provider, hosting provider, software vendors, cyber insurance
- Crisis communication procedure: what to tell clients, employees, partners
- Post-incident report: lessons learned, RTO/RPO adjustments
The DRP as a contractual commitment with your IT provider
A DRP sitting in a drawer is worthless. A DRP contractualized with measurable SLAs is different. In a managed IT contract, the provider commits to recovery times (RTO) and data loss windows (RPO) that are verifiable.
Verify that your contract explicitly mentions: the guaranteed RTO per system, the frequency of restore tests, penalties for exceeding targets, and the escalation procedure for major incidents.
Expert Quote — ANSSI (France’s national cybersecurity agency, comparable to CISA in the US) emphasizes that cyber crisis management begins before the crisis: “An organization’s resilience to a cyberattack is prepared well before any incident.” Without a formalized and tested plan, the response happens reactively — with costly mistakes. (Source: cyber.gouv.fr)
How to implement a DRP for your SME?
DRP implementation follows a logical progression. Here are the five steps we apply with our managed IT clients on Reunion Island.
Step 1 — Inventory and classification of critical systems
Start by listing all systems — servers, NAS, cloud applications, strategic workstations. For each system, document: type, version, physical or cloud location, dependencies, business owner. A critical systems audit performed by an external provider often reveals forgotten systems (old servers under a desk, uninventoried cloud instances).
Step 2 — Define your RTO and RPO (BIA method)
See the previous section. At this stage, formalize the numbers in a table shared with leadership. RTO and RPO validated by the business owner commits the organization — not just IT.
Step 3 — Choose the technical solutions (backup, replication, cloud)
Technical solutions are chosen based on target RTO/RPO, not the other way around:
- RTO < 1h: clustering, automatic failover, Azure Site Recovery
- RTO 2-4h: VM replication (Veeam, Zerto), immutable snapshot
- RTO 4-24h: local + cloud backup with manual restore
- RPO < 1h: hourly snapshot or near-real-time replication
- RPO 4-24h: daily backup with minimum 30-day retention
The 3-2-1 rule applied to the DRP is the foundation: 3 copies, 2 different media types, 1 copy offsite and isolated from the network.
Step 4 — Write the recovery procedures (RACI)
Each recovery procedure is written as a numbered checklist. The goal: a competent technician unfamiliar with your infrastructure can execute the procedure without ambiguity. Avoid vague formulations (“restart the server”) — prefer precise actions (“connect via RDP to 192.168.1.10, open Services.msc, start the SQL Server service”).
The RACI identifies for each action: who is responsible for executing it, who validates, who must be informed. In an IT maintenance contract, these responsibilities are split between your internal team and your provider.
Step 5 — Test and validate the DRP
An untested DRP is a DRP that will fail in a real situation. Schedule a full test within 30 days of writing, then every 6 months minimum. More details in the next section.
How to test your DRP? (frequency and method)
Among the SMEs we support through managed IT on Reunion Island, fewer than 20% have performed a full restore test in the last 12 months. The tests we run regularly reveal gaps between the theoretical RTO and the actual RTO. The most frequent cause: a procedure written but never updated after an infrastructure change.
Partial test vs full test (disaster simulation)
Partial test: restore an isolated system on a test environment. Verify that data is readable, consistent, and the system starts correctly. Duration: 2 to 4 hours. Frequency: quarterly.
Full test: simulate a major disaster across all critical systems. Measure actual RTOs (stopwatch in hand), verify communication procedures, identify bottlenecks. Duration: 1 full day. Frequency: annual.
Recommended test frequency
| Test type | Minimum frequency | Systems covered |
|---|---|---|
| Partial restore test | Quarterly | Files, email |
| VM restart test | Biannual | ERP, Active Directory |
| Full disaster simulation | Annual | All critical systems |
| Post-major-change test | Immediate | Modified system |
What to do with test results?
Each test produces a report: measured RTO vs target RTO, measured RPO vs target RPO, anomalies detected, corrective actions. If the measured RTO exceeds the target RTO, you must either improve the technical architecture or revise the target upward — both options are valid, but leadership must be informed.
Alert — Untested DRP = inoperative DRP. Based on our field observations, 70% of SMEs that think they have a DRP have never performed an actual restore test. A plan that has never been put to the test will fail when you need it most.
DRP and Reunion Island: island-specific considerations for your RTO/RPO
On Reunion Island, the distance from mainland French datacenters requires rethinking RTO targets for cloud-based solutions. This point is regularly underestimated by SMEs on Reunion Island that rely on cloud solutions hosted in mainland France.
Replication to an OVH datacenter in Roubaix or Strasbourg with limited bandwidth (shared FTTH fiber, or worse, a 4G backup connection) can extend restore time by several hours compared to what the provider quotes under normal conditions. Restoring 500 GB from a mainland datacenter via a 100 Mbps connection takes at least 11 hours under ideal conditions — often much more with submarine cable congestion.
Our recommendations for SMEs on Reunion Island:
- Primary data: host in a local datacenter (Reunion Telecom, or private datacenter in Saint-Denis) or in Mauritius for latency
- Secondary backup: cloud (OVH or Scaleway) in mainland France for geographic resilience
- Adjusted cloud RTO: do not accept the RTOs quoted by mainland hosts without validating them with an actual restore test from Reunion Island
- Offline continuity plan: for critical systems, prepare a degraded operating procedure (Excel files, remote access via 4G) during the restore window
DRP and NIS2: what are the obligations for SMEs in 2026?
The NIS2 directive (Network and Information Security 2) is the most structuring European regulatory framework for corporate cybersecurity. Its transposition into French law is expected by October 2026. NIS2 applies across all EU member states.
Who is covered by NIS2?
NIS2 considerably broadens the scope of NIS1. It covers two categories of entities across 18 critical sectors:
- Essential entities: energy, transport, banking, healthcare, water, digital infrastructure, public administration
- Important entities: postal services, waste management, chemicals, food, manufacturing, digital providers, research
SMEs in these sectors are covered — unlike NIS1, which targeted only large organizations. The inclusion criteria: more than 50 employees or more than €10M in revenue in a covered sector.
Business continuity obligations under NIS2
NIS2 requires covered entities to implement technical and organizational measures for business continuity, including:
- Backup management: formalized policy, regular testing, risk-appropriate retention
- Disaster recovery: documented plan with defined RTO/RPO
- Incident management: detection, response, and notification procedure
- Supply chain security: your IT subcontractors must be compliant — which also affects SMEs not directly subject to NIS2
ANSSI (France’s national cybersecurity agency) is the competent national authority for NIS2 in France. It publishes compliance guides accessible to SMEs.
Deadlines and penalties
The French transposition of NIS2 is expected by October 2026. The planned penalties can reach €10 million or 2% of global revenue for essential entities, and €7 million or 1.4% for important entities.
Beyond the direct regulatory scope: if you are a subcontractor of a large group subject to NIS2, that client may contractually impose equivalent requirements on you. SMEs outside the NIS2 scope are therefore not immune to indirect requirements through their major clients.
Frequently asked questions
What is the difference between RTO and RPO?
The RTO (Recovery Time Objective) measures the maximum acceptable time between a disaster and the restoration of systems. The RPO (Recovery Point Objective) measures the maximum amount of data the business can afford to lose, expressed as a duration. Example: an RTO of 4 hours means systems must be operational within 4 hours of the incident. An RPO of 1 hour means the last usable backup cannot be more than one hour old.
What is the difference between DRP and BCP?
The DRP (Disaster Recovery Plan) defines how to restore IT systems after a major disaster — it accepts a temporary interruption. The BCP (Business Continuity Plan) aims to maintain operations during the disaster, with zero or very short interruption. For most SMEs, the DRP is sufficient and financially accessible. The BCP is reserved for critical activities that cannot tolerate any interruption (trading, medical emergencies, critical infrastructure).
What are DMIA and PDMA in IT?
DMIA (Duree Maximale d’Interruption Admissible) is the French equivalent of RTO. PDMA (Perte de Donnees Maximale Admissible) is the French equivalent of RPO. These terms come from the ISO 22301 standard on business continuity management. In practice, IT professionals more commonly use the English acronyms RTO and RPO — but during an audit or certification process, you will inevitably encounter DMIA and PDMA.
How much does implementing a DRP cost for an SME?
The cost of a DRP for an SME of 10 to 50 workstations ranges from €2,000 to €15,000 depending on system complexity and RTO/RPO targets. This budget covers the initial audit, backup setup, recovery procedure configuration, and testing. In a managed IT context, the DRP is often integrated into the MSP contract as recovery SLAs, with an additional monthly cost of €100 to €500/month depending on the service level. This is significantly less than the median cost of an uncovered incident.
Does the NIS2 directive require SMEs to have a DRP?
The NIS2 directive, whose French transposition is expected by October 2026, requires covered entities (essential and important) to implement continuity measures including backup management and disaster recovery. SMEs in the 18 critical sectors covered by NIS2 must therefore have a formalized DRP. SMEs outside the NIS2 scope are not formally required to — but remain exposed to contractual requirements from their enterprise clients or major accounts subject to NIS2.
Ready to define your RTO and RPO?
A DRP starts with an infrastructure audit. ECLAUD IT works with SMEs on Reunion Island to conduct the Business Impact Analysis, define RTO/RPO per system, and implement protection architectures adapted to your budget.
Check out our managed IT services or contact us directly for a free assessment of your current situation.
See also: SME IT backup — the 3-2-1 rule explained, Managed IT for SMEs — the 5 signs it is time, and SME IT audit — the complete checklist
Sources:
