Requirements · Backup and recovery
Setting recovery point and recovery time requirements
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Recovery point objective is how much recent data you can afford to lose, and recovery time objective is how long a system can be unavailable. Set them per system by asking the business what an outage costs in operations, obligations and trust, then choose backup and recovery methods that meet them. Tighter objectives demand more cost and operational effort, so rank systems rather than demanding the same target for all.
Who this is for: A manager or IT lead who must decide how quickly each business system must return and how much data loss is tolerable, before buying backup or disaster recovery.
What to evaluate
Business impact per system
Objectives should reflect real consequences, not guesses, and differ widely between systems.
How to check: Interview process owners about what stops, what is lost and what obligations are missed during an outage.
Dependencies between systems
A fast-recovering application is useless if the directory, network or database it relies on returns later.
How to check: Map dependencies and define a recovery order.
Recovery point tolerance
Acceptable data loss depends on how easily work can be re-entered or reconstructed.
How to check: Ask how much recent activity could be recreated manually and at what effort.
Recovery time tolerance
Different functions can wait different lengths of time, and objectives shape the architecture required.
How to check: Identify workarounds, such as manual processes, and how long they can sustain operations.
Regulatory and contractual obligations
Customers and regulators may set expectations for availability and data protection.
How to check: Review contracts and applicable rules for continuity commitments and notification duties.
Capability to actually meet targets
Objectives not backed by tested procedures are wishes.
How to check: Run recovery exercises and compare measured times with the targets.
Comparison
| Tier | Typical tolerance | Usual approach |
|---|---|---|
| Critical, customer-facing or revenue-bearing | Very little downtime and minimal data loss | Replication or clustering plus separate backup, rehearsed failover |
| Important internal operations | Hours of downtime acceptable with modest data loss | Frequent backups with fast restore from local copies |
| Supporting systems | A day or more of downtime acceptable | Daily backups and documented rebuild procedures |
| Archive and reference data | Extended outage acceptable | Periodic backup or archive with slower retrieval |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Business impact per system | |||
| Dependencies between systems | |||
| Recovery point tolerance | |||
| Recovery time tolerance | |||
| Regulatory and contractual obligations | |||
| Capability to actually meet targets | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Which business processes would stop if this system were unavailable?
- How much work from the final hours before failure could we recreate?
- What is the order of recovery and which systems must return first?
- Do customer contracts or rules set recovery commitments?
- How would we operate manually during an outage and for how long?
- Who has authority to declare a disaster and start recovery?
- When did we last measure actual restore time against our targets?
Typical trade-offs
Tight objectives versus cost and complexity
- Upside
- Reduce disruption and data loss for critical processes.
- Downside
- Require redundant infrastructure, tooling and rehearsal effort.
Uniform targets versus tiered targets
- Upside
- One target is simple to communicate.
- Downside
- Over-protects trivial systems while spending heavily, or under-protects crucial ones.
Automation of recovery versus documented manual steps
- Upside
- Automation shortens recovery and reduces human error.
- Downside
- Needs maintenance and testing, and failures can be hard to diagnose under pressure.
Common mistakes
- Setting targets without consulting business owners. Technical teams often guess wrong about impact.
- Ignoring dependencies, then finding the application is ready but the identity service is not.
- Writing a plan and never testing it. Rehearse and measure.
- Treating every system as critical. Tiering focuses investment where it matters.
- Forgetting communications. Plan how staff, customers and regulators will be informed during an incident.
Related questions
What is the difference between RPO and RTO?
Recovery point objective concerns data: the maximum acceptable gap between the last good copy and the moment of failure, which decides backup or replication frequency. Recovery time objective concerns time: how long a service can be down before unacceptable harm occurs, which shapes how you restore. They are set independently. A system might tolerate losing a day of entries yet need to be back within an hour, or the reverse.
How do we get realistic answers from the business?
Ask concrete questions about consequences rather than abstract targets. What happens on the first day of outage, the third day, the second week? Which customers are affected, what contractual commitments are missed, and what manual workarounds exist? Document answers per process, then translate them into system tiers. Review with senior management so trade-offs between cost and tolerance are accepted knowingly.
Should disaster recovery plans cover cyber incidents?
Yes, and with differences. Cyber incidents may involve compromised credentials and infected backups, so recovery must include verifying that restored systems are clean, resetting credentials and possibly rebuilding rather than restoring in place. Plans need a decision path for isolating systems and engaging responders. Align the plan with your incident handling process and rehearse a ransomware scenario using offline or immutable copies.
How often should recovery objectives be revisited?
Revisit them when systems, suppliers or business models change, after incidents and exercises, and on a regular schedule such as annually. Growth often turns formerly minor systems into critical ones without anyone updating the plan. Record the date of each review, who approved the targets and what changed. Compare tested restore times against targets and adjust either the targets or the capability.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1) — National Institute of Standards and Technology, retrieved 27 October 2026
- StopRansomware — Cybersecurity and Infrastructure Security Agency, retrieved 27 October 2026
Related guides
How to choose · Backup and recovery
How to choose a business backup solution
Choose backup by what you must restore and how fast, then test it. Look for protection of every data source including cloud applications, immutable or offline copies that attackers cannot erase, separate credentials from your main environment, encryption, and restore testing you can actually perform. A backup that has never been restored is an assumption, not a control.
Comparison · Backup and recovery
Backup vs replication vs file sync vs snapshots
Backup keeps independent, versioned copies you can roll back to. Replication mirrors data to another site for fast failover but copies mistakes and corruption. File sync keeps files consistent across devices and also propagates deletions. Snapshots capture a point in time on the same storage and are fast but share its fate. Strong protection combines mechanisms rather than treating them as interchangeable.
Problems & fixes · Backup and recovery
Why backups fail when you need them and how to make them ransomware-resilient
Backups fail in predictable ways: attackers delete or encrypt them using stolen administrator access, jobs fail silently, restores are slow or incomplete, and keys or documentation are missing. Resilience comes from isolated or immutable copies, separate credentials, monitored jobs, regular restore tests and a rehearsed rebuild order that includes identity services.
Suitability · Security services and compliance
When a small business needs a security certification or audit
Pursue a formal certification or audit when customers, regulators or contracts require it, or when sales cycles repeatedly stall on security reviews. Earlier on, a practical baseline of good controls, a clear policy set and a completed questionnaire may suffice. Start with a recognised baseline scheme, then move to heavier attestations as the customer base and data sensitivity grow.
How to choose · Endpoint protection
How to choose endpoint protection for a small business
Pick endpoint protection by matching detection capability to the staff you actually have. Without anyone to watch alerts, favour strong automatic prevention, simple policy management and a response option that is either automated or provided by a service. Confirm operating system coverage, central management, tamper resistance and exportable logs before looking at extras.
How to choose · Business operations
How to choose a point-of-sale system for a shop, cafe or restaurant
Match the system to your workflow first: counter service, table service, appointments or online ordering each stress different features. Then weigh hardware, offline behavior, inventory and reporting depth, integrations with accounting and delivery channels, payment lock-in, support responsiveness and how easily you can export your data. Run a trial during a busy period before committing to a contract.
Cost factors · Endpoint protection
What drives the cost of endpoint protection
Endpoint protection cost depends on device count, which capability tier you license, data retention, any managed monitoring, and the staff time required to run it. Quotes that look similar can hide different definitions of a device, different support levels and add-on modules. Compare total operating effort, not only the licence line.