RTO and RPO are two numbers that a business sets for each system. The recovery time objective is the longest delay the business accepts between an interruption and the service coming back. The recovery point objective is the longest stretch of recent data the business accepts losing. However, a recovery can run past both. This article shows where the extra time and the older data come from.
Last reviewed 2026-11-02 by Manish Sharma.
This guide is for an IT manager or IT head. It also suits a continuity owner. The firm has roughly 250 to 2,000 people in India or the GCC. An auditor, a customer contract or a plan may have handed you these two numbers. The definitions follow AWS wording. The article also reasons about delay and does no calculation. Three other Signisys articles cover the next questions. They explain how to calculate and improve the numbers, how to score targets, and how backup and replication shape what you can reach.
RTO and RPO in Short: Two Numbers, Two Questions
The two targets answer different questions. Each one covers one kind of event on one system.
The AWS Well-Architected Framework defines the recovery time objective as the maximum acceptable delay between the interruption of service and restoration of service. It defines the recovery point objective as the maximum acceptable time after the last data recovery point. Next, the table turns each definition into a question and a span of time.
| Term | Question it answers | Counted from and to |
|---|---|---|
| RTO | How long can the service stay down? | From the interruption to restoration of service. |
| RPO | How much recent data can the business lose? | Back from the incident to the last data recovery point. |
The business sets both numbers as targets for a system. Also, a target is a business decision about a system, not a measure of the technology. However, neither number says what a recovery will take. Neither says how old the restored data will be.
What RTO and RPO Set, and What They Do Not Measure
A target is a decision, not a forecast. AWS bases the numbers on technical points and business impact. It also asks the business stakeholders and technical teams responsible for each workload to be involved in setting the numbers and in deciding whether they should be adjusted. In Signisys’ view, one named business owner should sign off each number. The technical team then confirms what it can deliver.
AWS asks for a recovery time and a recovery point for each workload, not one pair for the whole firm. A workload is the system or service that a target applies to. For example, payroll is one workload. A separate Signisys article on calculation shows how to work the numbers out. It covers links between systems and differences by incident type.
A target of zero needs a second look. AWS lists zero time to recover and zero data loss among unrealistic recovery objectives that may not be achievable for a workload. The Disaster Recovery of Workloads on AWS whitepaper makes a related point in its text on failover for an active/passive set-up such as pilot light. It says that even using the best practices it discusses, recovery time and recovery point will be greater than zero.
A recovery time objective of a few hours means little until someone names the system and the incident. To see how a plan scores its targets, also read a checklist for scoring a data recovery plan.
Key Takeaway A target is a decision about a system, not a forecast of what recovery will take.
Where the Recovery Clock Runs: Six Stages After an Outage
The six stages below are Signisys’ working model, not a standard. The clock the business feels runs from the outage until users work again. However, a plan may count only the restore. Then the stages around it go unplanned. Each stage is a place where time can slip without anyone noticing. A plan that lists only the restore leaves the other five to chance. This article gives no duration for any stage, since no source read here supplies one.
Stages 1 to 3: Notice, Declare, Get Access
The clock runs while the team notices the outage, decides to recover and gets into the systems it needs.
| Stage | What the clock waits for | Question to put to the team |
|---|---|---|
| 1. Notice | An alert or a user report reaching a person. | How would the team learn of an outage at night? |
| 2. Declare | A person deciding to start recovery. | Who may declare a recovery, and who covers when that person is away? |
| 3. Get access | The people, accounts and sites that the restore needs. | Which accounts and sites does the restore need, and who holds them? |
Meanwhile, the clock keeps running while a person decides, and while a restore waits for an account that nobody can reach.
Stages 4 to 6: Restore, Check, Hand Back
The last three stages decide whether users can work again.
| Stage | What the clock waits for | Question to put to the team |
|---|---|---|
| 4. Restore | Data, infrastructure, configuration and application code returning in the recovery location. | Can the team redeploy the system from code, or does it rebuild by hand? |
| 5. Check | A person confirming that the system works. | Who checks that the system works before users hear about it? |
| 6. Hand back | Users told, and working again. | Who tells users, and what counts as back? |
In its backup and restore strategy, the AWS whitepaper says that without infrastructure as code, restoring workloads in the recovery Region may be complex. It adds that this will lead to increased recovery times and possibly exceed the RTO. Stage 4 is where a plan without that code can miss its target. For the timed test that measures these stages, read a guide to running the timed restore.
Why the Data You Restore Can Be Older Than the RPO Says
Remember that the recovery point is the last usable copy, not the last scheduled copy.
If the newest good copy is older than the plan assumed, the data loss runs longer than the recovery point objective. For example, a recovery point objective of 30 minutes assumes a usable copy no older than 30 minutes.
The whitepaper says that how often you run a backup sets the recovery point you can reach. That point should align with the RPO. A schedule shows when copies should be taken, so check the newest copy that exists. When a job reports success but the newest recovery point is old, read why a green status can hide a bad copy.
Corruption changes the picture. First, the whitepaper says that for a data disaster involving corruption, deletion or obfuscation, the recovery point will always be at some point before the disaster was discovered. Second, it calls backup and restore a suitable approach for mitigating data loss or corruption. For example, a copy taken after the damage began may contain the damage.
How old is the newest copy you could restore today? Does it hold the data the business needs? Could the damage already sit inside it?
If you are unsure which copy to restore from, read about the difference between a backup and a snapshot.
One Term, Several Wordings: Which Definition a Plan Should Quote
Sources word the recovery time objective in different ways. So a plan should say which wording it uses. Microsoft’s Azure SQL Database business continuity overview words both terms for one database service. The table then sets that wording beside the AWS one.
| Source | Wording of the recovery time objective (paraphrase) | Question for your plan |
|---|---|---|
| AWS REL13-BP01 | The maximum acceptable delay between the interruption of service and restoration of service. | Does your plan start the clock at the interruption, at detection or at declaration? |
| Microsoft Learn, Azure SQL Database | The time an application needs to fully recover after an unplanned disruptive event. | Does your plan stop the clock at restored service or at full recovery? |
Both are published wordings, but a contract should name where the clock starts and stops, because the same recovery can meet one wording and miss another. The two sources also read differently on the stop point. While AWS speaks of restoration of service, Microsoft speaks of full recovery.
A recovery time or recovery point objective with no named start and stop can be read two ways.
Limits of RTO and RPO as Numbers, and When to Ask for Help
The recovery time objective and the recovery point objective say what the business wants. They do not say what the systems deliver. So finding a gap between the two is a useful first result of a review. A timed restore shows what the systems deliver. For a plan that broke because nobody tested it, read what goes wrong in untested recovery plans. For the line between keeping a service up and recovering it, read how high availability differs from recovery.
Also, this article names no Indian or GCC rule and gives no legal advice. Your auditor or your contract sets any requirement. Three more Signisys articles cover calculation, scoring and backup versus replication.
When to ask for help. First, two systems depend on each other, their numbers disagree and nobody owns the conflict. Second, a restore beat the target while users still report missing data. Third, a contract quotes a target nobody has measured on the real system.
Signisys provides business continuity and disaster recovery solutions, as well as consulting and managed cloud services. Read this as a description of a Signisys service, not neutral advice. Our page on meeting recovery targets sets out the approach.
Key Takeaway Only a timed restore shows what a system delivers.
RTO and RPO FAQ
Is the recovery time objective the same as how long recovery takes?
Can the recovery point objective be zero?
Where does the clock start and stop for RTO and RPO?
Why not give every system the tightest RTO and RPO?
Does meeting the RTO mean users are back at work?
What does a restore need besides the data?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.