Recovery Time Objective (RTO) is the longest time a business can accept a system being unavailable after a failure. Recovery Point Objective (RPO) is the maximum amount of data, measured in time, that it can afford to lose. An RPO of four hours means the business can cope with losing up to four hours of work.
They work as design targets. A short RTO needs fast restore options such as spare hardware, replicated systems or failover to the cloud, while a short RPO needs frequent backups or continuous replication. Both cost more as they get tighter, so each system should be matched to its real importance.
A hospitality group might decide its POS and payments need an RTO of under an hour, since trading stops without them, while the accounting system can wait a day. A retailer's ecommerce store may need a tight RPO so orders are not lost.
Pitfalls include setting targets nobody has discussed with the business, never testing whether they can be met, and assuming a cloud provider covers them automatically. Write them down in the continuity plan and any support agreement, and check them against actual restore tests.
Having numbers turns "we have backups" into a measurable promise that managers and IT providers can both plan against.