We keep walking into cloud environments where the recovery point objective on paper is one hour and the architecture delivers three months. Managed services impose a capture floor that no policy setting can lower, and many teams never look it up.
Coverage decays as accounts and clouds multiply. Add ransomware or a runaway agent to the picture and the newest copy is no longer the copy you can actually use.
What is recovery point objective?
A recovery point objective (RPO) is the age limit you set on your newest recoverable copy of data. An RPO of 15 minutes means that copy can never sit more than 15 minutes behind production. The clock runs backward from the incident to the last usable recovery point.
That number sets your capture frequency. A 15-minute RPO needs a capture point every 15 minutes, from a snapshot schedule, incremental backups, log shipping, or replication.
If you miss the interval, you’ve moved your RPO, whatever the policy document says.
How RPO differs from RTO
RPO measures lost data. Recovery time objective (RTO) measures lost time. One drives how often you copy data; the other drives how fast you can put it back.
RPO and RTO are usually set separately because they have different tradeoffs. An RPO cut from an hour to five minutes costs storage and log-shipping bandwidth. An RTO cut from four hours to 30 minutes costs standby infrastructure and runbook maturity. A payments database usually needs both tight; an analytics warehouse usually needs neither.
The pair also collides in one specific place. After a ransomware incident, your effective RPO stretches back to the last clean copy, which usually widens RTO too because recovery now includes forensics.
The RTO side is worth walking through separately.
Recovery point objective examples across workload types
Here’s where the RPO usually lands across common cloud workloads:
The rebuild path changes what a given number is worth. An analytics warehouse with a 24-hour RPO is fine if the pipeline can replay from the source. The same 24-hour target on the source system itself would be reckless.
RPO governs how recent your newest copy is; retention governs how far back your oldest one reaches. A ransomware incident can push you all the way to that older edge.
RPO floors set by managed cloud services
Managed cloud services impose a floor on your RPO that no policy setting can lower. The floor comes from how often the service durably captures changes, and it is documented for every major database and object store.
Committing to a five-minute RPO on Azure SQL Database sets you up to miss it by design, because the log cadence there runs roughly double that. A sub-minute RPO on any of these services needs something beyond the native capture path, usually application-level replication to a standby.
Cloud SQL Enterprise edition holds transaction logs between one and seven days, while Enterprise Plus reaches 35. A five-minute recovery point does nothing for you if the incident started nine days ago.
Gartner's 2026 Hype Cycle for Backup and Data Protection Technologies places PaaS backup at early mainstream and makes a related point. Cloud providers deliver infrastructure resilience against server, site, and region loss.
That resilience stops short of accidental deletion, corruption, ransomware encryption, and malicious insiders. Under the shared responsibility model, the data inside those services stays yours to protect.
Why the delivered RPO trails the target
The stated RPO is the number in your continuity plan. The delivered RPO is the age of the newest usable copy when you go looking for one. Three things pull them apart, and you can’t find them in a policy review.
Resources with no capture point at all
A resource nobody covered has no recovery point at all. This is the most common failure mode and the hardest to see, because a coverage hole produces no alerts and no job errors.
Eon's 2026 Cloud Data Infrastructure Report revealed 91% of respondents were confident they could identify what data is protected across accounts, regions, and clouds. Yet, 61% only discover unprotected workloads after an incident, an audit, or a restore that came up short.
Manual tagging is what creates the hole. A new database goes live on a Thursday, nobody applies the policy tag, and it sits outside every backup plan for months.
Cloud Backup Posture Management (CBPM) closes that path, classifying resources as they are created and applying policy without a human step.
Backup windows that outrun the capture schedule
A capture job that takes longer than its interval widens your RPO without anyone noticing. Set an hourly snapshot on a dataset that needs 90 minutes to copy and the second job queues behind the first.
Large object storage buckets and multi-petabyte databases hit this first. The job starts, the next one waits, and the interval between usable recovery points stretches well past what the schedule implies. Watch job duration against interval, not job success against schedule.
Policy drift across accounts and clouds
Coverage decays as environments grow. The 2026 report puts the drift rate at 63% of respondents uncovering unprotected workloads caused by policy misconfiguration.
The numbers worsen with every cloud added. Among organizations running three or more platforms, 84% had at least one recovery failure in the past twelve months.
Gartner tracks this problem as recovery posture assessment, an embryonic category it rates as high benefit. Its analysts note that public cloud environments lean on scripted and manual assessment to establish what is protected and which recovery objectives apply.
Recovery point actual and how to measure it
Recovery point actual is the measured age of your newest usable copy. When it diverges from the target across several checks, the target is wrong, the architecture is short, or both.
Each service exposes the figure directly, and reading all four takes a few minutes.
- Managed databases: Call describe-db-instances, read LatestRestorableTime, subtract it from now. That delta is your live recovery point.
- DynamoDB tables: Read LatestRestorableDateTime from the point-in-time recovery description and apply the same subtraction.
- Replicated object storage: Watch ReplicationLatency in CloudWatch, plus the OperationMissedThreshold event emitted past 15 minutes.
- Scheduled snapshot jobs: Compare the newest completed snapshot timestamp against the policy interval, per resource, not per plan.
Run this monthly on tier-one workloads and quarterly everywhere else. Log the delta each time. A drift trend tells you more than any single reading, because it shows the direction your environment is heading before an incident does.
Ransomware and the clean recovery point
RPO in cyber security works differently, because the newest copy is no longer automatically the right one. A ransomware operator who sat in the environment for eleven days has been encrypting data that your backup jobs copied on schedule.
Every one of those jobs succeeded. Every one of those recovery points is poisoned.
Your effective recovery point becomes the age of the last clean copy, not the last copy. A four-hour RPO on paper turns into an eleven-day RPO in practice, and you only learn the real number during the incident.
Managed databases are the hardest place to spot this. File-level scanning has nothing to scan inside RDS, Aurora, Azure SQL, or Cloud SQL, so encryption there passes through undetected.
Detection has to run against the data itself, watching row counts, schema structure, and cardinality patterns for the shape of an attack. That’s how Eon's Ransomware Protection identifies which recovery point is still clean.
Gartner's 2026 Hype Cycle names validating clean recovery points as one of the concrete benefits of AI-augmented backup, alongside faster threat detection and guided recovery steps. Gartner places the category early on the curve, with adoption still in the low single digits.
When AI agents can reach the backups
Coding agents introduced a loss pattern that capture frequency cannot bound. In late April 2026, a Cursor agent running Claude Opus 4.6 deleted PocketOS's production database and all of its volume-level backups in a single API call. The whole thing took nine seconds.
The agent hit a credential mismatch in staging, went looking for a token, and found one in an unrelated file that carried permission for destructive operations.
The infrastructure provider stored volume-level backups inside the volume itself, so one deletion took both. Our post-mortem of the incident put the newest surviving copy at three months old.
Whatever RPO PocketOS had written down, the delivered figure was ninety days. Capture frequency was never the constraint. Reachability was. Any credential that can delete production data and also delete the copies of production data collapses your recovery point to whatever sits outside that reach.
Copies belong in a separate account that production credentials cannot touch, held in a logically air-gapped, immutable vault where a compromised token, a runaway agent, or a replication path cannot reach them.
Best practices for setting a recovery point objective
The failure paths above all land in one measurement: the recovery point actual number. These practices catch them before it drifts.
- Derive the target from a business impact analysis. Start from what an hour of lost writes costs the business in revenue, regulatory exposure, and customer trust. Gartner treats the BIA as the step that produces RPO and RTO for each asset.
- Set the objective per data class, and let new resources inherit it. One blanket target overspends on data nobody would miss and underprotects the data that would stop the business. Define targets by data class, then attach them automatically at resource creation so coverage does not depend on someone remembering a tag.
- Check the target against the service floor before you commit. Look up the documented capture cadence for every service in the workload. A 5-minute RPO on Azure SQL Database is not achievable through native point-in-time restore alone; finding that out mid-incident is expensive.
- Measure recovery point actual on a schedule. Read the live recovery point for tier-one workloads monthly and everything else quarterly. Record the delta against the target every time. Without that record, the objective carries no evidence behind it.
- Keep copies outside the reach of production credentials. Treat any credential that can reach both production and its copies as a single point of loss. Store the copies under a separate account, in a logically air-gapped location the production credential set has no route to.
- Match the unit of recovery to the unit of damage. A tight recovery point is worth little if reaching it means rehydrating an entire environment. Granular restoration returns a single file, object, record, or table without rebuilding what surrounds it.
- Revisit targets when workload criticality moves. Systems get promoted without anyone updating the plan. An internal tool that became customer-facing two quarters ago is still carrying a 24-hour recovery point. Review tiers quarterly, and re-derive the targets when the business impact changes.
Two cases show what that granularity earns in production. SoFi moved off native snapshots and cut recovery across five AWS regions from a full day to minutes. NETGEAR brought a 10TB SQL Server restore from 24 hours to under three.
Where to focus first on your RPO
Pick your three most critical workloads, read the live recovery point for each, and compare it to what the plan claims. That exercise surfaces more risk than a quarter of policy review, because it tests the architecture and not the intention.
From there, close coverage gaps before tightening any target, since an uncovered resource has no recovery point to tighten. Wider recovery planning context lives in our guide to cloud disaster recovery, and snapshot vs backup covers what a snapshot can and cannot give you.
How many of your workloads have a recovery point right now? Book a demo and see how Eon catches unprotected workloads before an incident does.
Frequently asked questions
What does RPO stand for in cyber security?
RPO stands for recovery point objective. In cyber security, the newest copy is not always the right one, since a ransomware operator who dwells for days can encrypt data across several backup cycles. The recovery point you can actually use is the age of the most recent copy that predates the intrusion.
Can a recovery point objective be zero?
A recovery point objective of zero is achievable only with synchronous replication, where every write commits to a second location before it is acknowledged. That adds latency and roughly doubles infrastructure cost, so it suits a small set of financial systems.
How do you measure your actual recovery point?
You measure your actual recovery point by reading the newest restorable timestamp from the live service and subtracting it from the current time. For Amazon RDS, that value is LatestRestorableTime, and for DynamoDB it is LatestRestorableDateTime.
What is the lowest RPO available from native cloud backup?
The lowest RPO available from native cloud backup sits at roughly five minutes for most managed databases. Amazon RDS ships transaction logs every five minutes, Aurora tracks its cluster volume slightly tighter, and Cloud SQL typically delivers five minutes or less. Object storage lands at 15 minutes.
Does a shorter RPO cost more in storage?
A shorter RPO increases storage and transfer cost, though not always proportionally. Continuous log capture stores deltas, not full copies, so log-based recovery often costs less than the frequency difference suggests. Cross-region replication adds egress charges on every write.
Which regulations require a recovery point objective?
DORA requires EU financial entities to set recovery time and recovery point objectives for each business function, and it has been in effect since January 2025. ISO 22301 and NIST SP 800-34 build the same determination into continuity planning. HIPAA, GDPR, and SOC 2 prescribe no values.
