Continuity planning works when recovery objectives are clear and measured. This guide explains RPO and RTO in plain English, how to choose practical targets for a UK Small or Medium Enterprise (SME), how often to test, and how to define a minimum viable continuity baseline that protects essential functions without unnecessary cost. We align with ISO 22301 terminology and testing practices (BIA, exercising, continual improvement).
Definitions (no jargon)
- RTO — Recovery Time Objective
The maximum acceptable time to restore a service after disruption (e.g., “email back within 4 hours”, “accounts system within 24 hours”). RTO is set from the Business Impact Analysis (BIA) and drives the design of recovery solutions and exercises. [learn.microsoft.com] - RPO — Recovery Point Objective
The maximum acceptable data loss, measured as time (e.g., “≤ 4 hours of email”, “≤ 1 hour of ERP changes”). It reflects how frequently you take recoverable backups/replicas and what the business can tolerate. - MTPD — Maximum Tolerable Period of Disruption
The outer limit after which the organisation’s viability is at risk; used in ISO 22301 to frame strategy and prioritise resources. RTO must be less than the MTPD. [learn.microsoft.com]
(If you’ve seen “ROT”, it’s usually a typo for RTO. We’ll stick to ISO 22301 terms.)
Step 1 — Decide what really matters (and for whom)
Map essential functions first: revenue operations, regulatory deadlines, customer communication. For each, list the supporting systems (apps, databases, file shares, identity), then set provisional RTO/RPO per service. Use short workshops with finance, sales, operations to avoid IT‑only targets. ISO 22301 encourages cross‑functional scoping and top‑management involvement. [iso.org]
Step 2 — Choose realistic targets (by SME size)
- Micro (<10 users)
- Email/comm: RTO ≤ 4–8 h; RPO ≤ 4 h.
- Accounting: RTO ≤ 24 h; RPO ≤ 24 h (daily export or backup).
- Files: RTO ≤ 24 h; RPO ≤ 8–24 h.
Bias towards simple backups + one offsite/immutable copy.
- Small (10–50 users)
- Core apps/VMs: RTO ≤ 8–12 h; RPO ≤ 4–8 h (hourly or near‑hourly jobs).
- Shared files: RTO ≤ 8–12 h; RPO ≤ 4–8 h.
- SaaS: independent backup/export cadence (not just recycle bins).
- Medium (50–250+)
- Tiered services (customer‑facing vs internal):
- Front‑line services: RTO ≤ 4–8 h; RPO ≤ 1–4 h (replication + immutability).
- Back‑office: RTO ≤ 24 h; RPO ≤ 8–24 h.
- Formal MTPD set per process; exercise plans and maintain evidence packs.
- Tiered services (customer‑facing vs internal):
(Targets are exemplars—your BIA sets the final values.)
Step 3 — The trade‑offs (cost, risk, complexity)
- Shorter RTO ⇒ more pre‑built capacity and orchestration (standby VMs, hot replicas, runbooks) and more frequent exercising.
- Shorter RPO ⇒ higher backup/replication frequency, tighter windows, and stronger immutability/offline controls to prevent deletion during attacks.
- Higher complexity (multi‑site, mixed cloud/on‑prem) ⇒ more dependencies to test; keep designs modular; apply least‑privilege across backup credentials.
ISO 22301 expects documented strategies, resource allocation, and regular testing to validate assumptions.
Step 4 — Minimum Viable Continuity (MVC)
Your MVC is the smallest, defensible set of controls and exercises that meets agreed RTO/RPO for critical services:
- Defined targets: RTO/RPO per service, below each process’s MTPD.
- Recoverable backups: at least one offsite or immutable copy at all times.
- Documented runbooks: who does what, in what order (identity, DNS, apps).
- Evidence of testing: restore logs, timings, screenshots—kept current.
- Review cadence: quarterly mini‑tests, annual scenario exercise (table‑top or technical).
These practices are consistent with UK resilience guidance (design for continuity, segmentation, incident management). [gov.uk]
Test frequency (keep it light but regular)
- Quarterly mini‑tests: one workload per quarter (file share / small DB / single VM) → measure actual RTO/RPO, capture evidence.
- Annual scenario: end‑to‑end drill for a priority service (identity + app + data).
- Change‑triggered tests: after major upgrades, topology changes, or new SaaS.
ISO 22301 highlights exercising and continual improvement; testing proves controls and reveals gaps early.
Evidence that matters
A one‑page “continuity evidence” pack per service: current RTO/RPO, last test date, results, issues, owners, and next actions. BSI and ISO guidance emphasise regular evaluation and top‑management oversight to keep continuity plans real.
How we help (engagement outline)
- Short continuity discovery (BIA‑lite) to agree targets per service.
- A sanity‑test session to measure real RTO/RPO on a representative workload.
- A 90‑day improvement plan: testing cadence, quick wins, runbook gaps — neutral tooling, multi‑vendor examples as needed.