Answer
Setting RTO and RPO by workload rather than by system is where most organizations get real value. Order entry, EDI, and manufacturing control on Db2 for i often justify an RPO measured in seconds through journaling and near-real-time replication, while internal reporting or archival applications can reasonably tolerate an RPO measured in a day through nightly save operations. Treating every workload the same either overspends on continuity for low-value systems or, more dangerously, leaves a critical application under-protected because it was bundled into a generic backup policy.
Getting these targets documented also forces a conversation that technical teams cannot have on their own: what does an hour of downtime actually cost this specific process, in lost revenue, missed shipments, or compliance exposure. Business owners are the only ones who can answer that, and their answer should be revisited whenever the application's role changes, not just when the software contract comes up for renewal. Buyers evaluating backup, replication, or DR platforms should ask each vendor to show, in concrete terms, what RTO and RPO their product can realistically deliver for a workload of the buyer's actual size and change volume, not a generic marketing figure.