RPO and RTO with the business

Recovery targets turn vague comfort into numbers. NIST's contingency planning guide (SP 800-34 Rev. 1) defines the recovery point objective (RPO) as the point in time to which data must be recovered after an outage, in practice the maximum tolerable data loss, and the recovery time objective (RTO) as the overall length of time a system's components can be in the recovery phase before the business is negatively affected. Both are business requirements. IT designs to meet them, and testing proves whether it does.

Setting targets with owners

Ask the business, not the infrastructure team, how much data and time it can lose. Ask per process, because the answers differ. For Contoso, Maria says order-to-cash can survive a few hours without the system using phone orders, but losing confirmed orders would be expensive to reconstruct. Dan says finance can tolerate a day of downtime outside the month-end close, but not during it. Those answers lead to targets, and the targets lead to design and cost.

Two checks keep the numbers honest. First, compare them with the contract: under RISE, the achievable values depend on the HA and DR options and service levels Contoso bought, so the targets must fit what SAP has committed to, or the contract must change. Second, break the RTO into its parts: detection, decision, technical takeover, application restart, connection switches, interface recovery and validation. Technical takeover may take minutes while decision and validation take hours.

Remember the non-production systems too. CMQ holds the regression suite and test data that the program needs after any disaster; if it takes three weeks to rebuild, the first post-disaster transport cannot be tested. Most companies accept backup-based recovery for development and quality systems, but they should decide that deliberately and write the expected recovery time down, so nobody assumes the test landscape comes back as quickly as production.