How to Build a Disaster Recovery Plan: RTO/RPO Guide for SMEs

You have backups. But if a server dies or ransomware locks the systems, how many hours until the business is running again? If you can’t give a number, you have a backup but no plan — and those are not the same thing.

A backup is a copy of the data. A disaster recovery plan (DRP) is the document that says how, in what order, and under whose responsibility that copy gets the business working again. The longest outages I see in the field aren’t at companies without backups; they’re at companies that have backups but try to restore them for the first time during the crisis. The restore takes six hours, nobody knows which server should come back first, and people argue about where the last clean copy is. That chaos comes from the absence of a plan.

It starts with two numbers: RTO and RPO

Before you write anything, two targets need to be clear.

RTO (Recovery Time Objective) — how many hours, at most, a system may stay down before it has to be running again. Saying “the accounting server can be down for at most 4 hours” means setting RTO to 4 hours.

RPO (Recovery Point Objective) — the maximum data loss you can accept. If you back up once a day, overnight, your RPO is 24 hours: you can lose everything between the crash and the previous night. For e-commerce orders that 24 hours is unacceptable; for a monthly archive it may be fine.

You can’t build a plan without setting these per critical system. Your ERP’s RTO can’t equal your internal wiki’s RTO; equate them and you either overspend or fail to protect what actually matters fast enough.

System	Example RTO	Example RPO	Note
ERP / accounting	2-4 hours	1 hour	If it stops, billing and production stop
Email	4 hours	1 hour	Customer communication is critical
File server	8 hours	24 hours	Tolerable for most SMEs
Marketing / blog	48 hours	24 hours	Doesn’t directly stop revenue

Treat this as a starting point, not a template. Your RTO/RPO are set by your sector and your customers’ expectations.

Business impact analysis: what do you recover first?

You don’t pull RTO/RPO out of thin air. Behind them sits a business impact analysis (BIA): working out, system by system, how much money and reputation the business loses when each process stops. This analysis is at the heart of the ISO 22301 business continuity standard — an organisation sets each critical process’s RTO based on its result.

At SME scale there’s no need to overcomplicate the BIA. In a half-day workshop, answer three questions:

• Which system, if it goes down, starts costing us money today?
• How many hours can we cope without it?
• What does restoring it depend on (database first, network first)?

The answers give you your recovery order. Instead of debating “what do we bring up first” during the crisis, you open the list and work through it.

A plan only works if it leaves the paper: drills are mandatory

A plan that’s written but never tested isn’t a plan; it’s good intentions. This is the most common mistake I see: a 30-page DRP sitting in a folder, with the last restore test more than a year old.

Run a real restore drill at least once a year. Restore one critical server into an isolated environment and measure “does it boot, is the data consistent, how long did it take.” The time you measure is usually longer than your target RTO — better to learn that in a drill than in a crisis.

In the drill, note three things: actual recovery time, missing steps, and wrong or stale information in the plan (changed IPs, departed staff, retired services). Then update the plan. A disaster recovery plan is a living document; it changes as the infrastructure changes.

What every plan must contain

• Communication chain — who calls whom, with phone numbers inside the plan (you may not have email access)
• System priority list — drawn from the BIA, ordered by RTO
• Restore steps — concrete, screenshot-level, for each critical system
• Backup locations and access — which backup is where, who holds the password, at least one copy offline/immutable
• Vendor and support numbers — ISP, hardware, IT partner

Frequently asked questions

My backup is in the cloud — do I still need a DR plan? Yes. A cloud backup improves your RPO but doesn’t answer “who restores it, in what order, in how many hours.” The plan fills that gap.

What RTO should an SME aim for? There’s no single right number. For critical systems most SMEs land between 2 and 8 hours. What matters is not picking a number arbitrarily but grounding it in the BIA and proving with drills that your infrastructure can actually hit it.

How often should the plan be updated? At least after the annual drill, plus after major infrastructure changes (new server, relocation, ERP migration).

A disaster recovery plan isn’t a product you buy; it’s a discipline someone who knows your business builds with you. To set up backup, RTO/RPO definition, and regular drills around your operation, get in touch.

Türkiye-specific note: ISO 22301 is the international standard adopted in Türkiye as TS EN ISO 22301; the methodology here is vendor-neutral and applies regardless of jurisdiction.

---

Sources

• TSE — TS EN ISO 22301 Business Continuity Management System: tse.org.tr
• ISO 22301 Business Continuity and BIA — KPMG Akademi: kpmgakademi.com