When a business commissions a web application, CRM system or customer portal, the conversation about backups usually starts with a simple question: how often will the data be backed up? That question matters, but it only addresses half the problem. The two measures that actually determine how well your business survives a system failure are RPO and RTO.
Recovery Point Objective (RPO) is the maximum amount of data you can afford to lose, measured backwards in time from the moment of failure. If your RPO is one hour, your backup regime must capture data at least every hour. Anything created or changed in the gap between the last backup and the failure is gone. RPO is about data loss, not time to recover.
Recovery Time Objective (RTO) is the maximum amount of time your business can tolerate the system being unavailable after a failure. If your RTO is four hours, the process of restoring data, restarting services and confirming everything works must complete within that window. RTO is about downtime, not data loss.
The distinction matters because the two objectives pull in different directions and carry different costs. A short RPO demands frequent backups, which means more storage, more processing overhead and often more complex database replication. A short RTO demands fast infrastructure, pre-staged recovery environments and well-rehearsed procedures. You can have a one-hour RPO with a 24-hour RTO, or a 24-hour RPO with a one-hour RTO, or any other combination. Neither measure implies the other.
For business owners buying or specifying a web application, the practical point is this: if you do not define both RPO and RTO as part of your requirements, your supplier will make assumptions that may not match what your operations actually need. Those assumptions will be baked into the hosting arrangement, the backup schedule and the support contract, and you may not discover the gap until something goes wrong.
Setting sensible RPO and RTO targets starts from what the system does and what happens when it stops. Different types of business systems carry different consequences of failure, and the targets should reflect that.
| Recovery decision | Business effect | Evidence to test |
|---|---|---|
| Customer-facing portals | If a customer portal goes down, users cannot access their documents, submit applications or track orders. | The RTO for a portal is often driven by contractual service levels or reputational risk. |
| CRM and sales systems | A CRM that loses a day of sales activity creates immediate reconciliation problems. | Notes from calls, pipeline stage changes and new contact records are difficult to reconstruct. |
| Internal admin and workflow tools | Systems that manage approvals, document routing or internal reporting often have more flexibility on RTO because the impact of downtime is contained within the organisation. | However, the RPO can still be critical if the system handles compliance-related records or audit trails. |
| Document management systems | Document stores where files are uploaded but rarely edited can often tolerate a longer RPO, because the original files still exist with the person who uploaded them. | A document management system that also tracks versions, annotations and metadata changes is a different matter: that contextual data is often not stored anywhere else, making the RPO more important than the file storage alone would suggest. |
Customer-facing portals
If a customer portal goes down, users cannot access their documents, submit applications or track orders. The RTO for a portal is often driven by contractual service levels or reputational risk. If your contracts promise availability during business hours, your RTO needs to be shorter than the window in which customers would reasonably expect a response. The RPO depends on how much transactional data flows through the portal. A document-viewing portal with data updated daily may tolerate a 24-hour RPO. A portal handling real-time applications or payments may need an RPO measured in minutes.
CRM and sales systems
A CRM that loses a day of sales activity creates immediate reconciliation problems. Notes from calls, pipeline stage changes and new contact records are difficult to reconstruct. For most CRM deployments, an RPO of a few hours is a practical starting point, though the exact figure depends on call volume and whether the sales team also logs activity elsewhere. The RTO is usually less acute than for a customer portal because CRM users are internal, but a full working day without CRM access has a measurable cost in lost productivity.
Internal admin and workflow tools
Systems that manage approvals, document routing or internal reporting often have more flexibility on RTO because the impact of downtime is contained within the organisation. However, the RPO can still be critical if the system handles compliance-related records or audit trails. Losing a day of approval history may create problems that surface weeks later during an audit.
Document management systems
Document stores where files are uploaded but rarely edited can often tolerate a longer RPO, because the original files still exist with the person who uploaded them. A document management system that also tracks versions, annotations and metadata changes is a different matter: that contextual data is often not stored anywhere else, making the RPO more important than the file storage alone would suggest.
Questions to put to a supplier
- What is the backup frequency, and does that frequency actually meet the RPO we have specified?
- Where are backups stored, and is that location separate from the primary infrastructure?
- What is the documented procedure for restoring from a backup, and who carries it out?
- Does the RTO include only the technical restore, or does it cover full service verification?
- Are there any components of the system that are not covered by the stated RPO and RTO, such as third-party integrations or cached data?
These questions matter because a supplier may quote an RTO that covers database restoration but excludes the time needed to restart application servers, reconfigure connections or verify that integrations are functioning. The RTO you care about is the time until your business can use the system again, not the time until a technical process completes on a server.
Assuming a shorter target is always better
There is a cost curve behind both RPO and RTO. Moving from a 24-hour RPO to a one-hour RPO may require moving from daily file backups to continuous database replication, which changes the infrastructure, the hosting costs and the operational complexity. Moving from an eight-hour RTO to a one-hour RTO may require a standby environment that doubles your infrastructure spend. The correct targets are the ones that balance the cost of achieving them against the cost of not achieving them. For many internal business systems, a few hours of data loss and a working day of downtime are manageable. The mistake is paying for zero-downtime resilience on a system where the business impact of a brief outage is modest.
Confusing backup frequency with RPO
A backup that runs every hour does not guarantee a one-hour RPO. If the backup process itself takes 45 minutes and fails intermittently, the effective RPO may be much longer. If backups are stored on the same disk array as the live data, a hardware failure could destroy both. The RPO is determined by the last successful, verified backup, not the scheduled interval.
Conflicting targets across connected systems
If your CRM has an RTO of two hours but the billing system it integrates with has an RTO of 24 hours, restoring the CRM quickly may not help if the integration is broken. Where systems share data or depend on each other, the RTO of the overall business process is constrained by the slowest component. This is worth mapping explicitly when you have multiple systems that work together.
Not revisiting targets as the business changes
An RPO and RTO set during initial development may become inadequate as the system handles more users, more data or more critical processes. A CRM that was a nice-to-have in year one may be central to operations in year three. The targets should be reviewed when the business context shifts, not left as a line in an original specification that nobody reads again.
Key checks before accepting a supplier's proposal
- Are the RPO and RTO stated as explicit, measurable targets in the contract or service-level agreement, rather than described informally in a covering email?
- Is it clear who is responsible for initiating a recovery, and what the escalation path is if that person is unavailable?
- Does the proposal distinguish between the time to restore data and the time to restore full service, including integrations and user access?
- Are there any caveats that effectively widen the RTO, such as "best effort" language or exclusions for certain failure types?
- Has the supplier explained what happens if the recovery itself fails or takes longer than the stated RTO?
RPO and RTO are not theoretical constructs. They are the two numbers that determine what your business actually loses when something goes wrong, and how long it takes to get back to normal. Defining them clearly, matching them to real operational impact and making sure a supplier has committed to them in writing is a straightforward discipline that prevents a great deal of avoidable damage.