Disaster recovery commitments in RISE.

Disaster recovery is one of the operational commitments most often signed at the SAP default and most often regretted when it is tested. The standard RISE with SAP contract specifies a recovery point objective and a recovery time objective at levels that work for many buyers and fall short for buyers with specific regulatory, operational, or competitive sensitivity. The defaults look reasonable in a contract review and look inadequate when an actual incident requires invocation. This article walks through the disaster recovery commitments inside a standard RISE contract, the gap between the standard and what regulated industries typically require, and the negotiation positions that close the gap before signature rather than during an incident.

Understanding what the SAP standard delivers

The standard RISE disaster recovery offering, often packaged as part of the high availability or premium tier, typically commits to a recovery point objective of fifteen minutes to one hour and a recovery time objective of four to eight hours, depending on the tier the buyer purchases. The figures cover the SAP managed components. The buyer's adjacent systems, integration layer, and end user infrastructure are out of scope for the SAP commitment.

The buyer should understand what the figures mean operationally. A one hour RPO means up to one hour of data loss is contractually acceptable. A four hour RTO means the buyer business can be without the SAP system for up to four hours, contractually. For some businesses, the figures are adequate. For a global retailer at peak, for a financial services firm with intraday processing, for a manufacturer running shift critical workloads, the figures are not adequate and the cost of a longer outage may exceed the cost of negotiating tighter commitments.

Mapping the buyer's actual recovery requirement

The negotiation should be informed by the buyer's actual recovery requirement, mapped at the workload level. Some workloads can tolerate the standard RPO and RTO. Others cannot. The mapping should identify which business processes run on the SAP system, what the impact of an outage is per hour for each, and what the regulatory or contractual obligations on each process require. The mapping produces the requirement that the contract has to meet.

The buyer should not request the tightest possible RPO and RTO uniformly. The cost rises sharply at the tighter end, and most workloads do not require it. The buyer should differentiate, request enhanced commitments where required, and accept the standard where adequate. A differentiated request is more credible at the negotiating table than a blanket demand.

The hyperscaler architecture determines what is possible

The disaster recovery commitments SAP can offer are bounded by the hyperscaler architecture under the RISE service. AWS, Azure, and Google Cloud all offer multi region and multi zone configurations. The buyer should understand the architecture that supports the disaster recovery commitment. A single region with multiple availability zones is one architecture. Multi region active passive is another. Multi region active active is a third. Each architecture has different RPO, RTO, and cost characteristics.

The buyer should negotiate not just the RPO and RTO figures but the underlying architecture that delivers them. The buyer should also confirm that the failover process has been tested at the architecture scale that the buyer requires. SAP commitments that assume a smaller scale failover may not deliver when invoked at the buyer's scale.

Testing rights and cadence

A disaster recovery commitment is only credible if it is tested. The standard RISE contract sometimes does not specify testing cadence, sometimes assigns testing to SAP at SAP's discretion, and sometimes allows joint testing at a cost. The buyer should negotiate a testing programme into the contract.

The buyer should require at least one full failover test per year, with the right to validate the RPO and RTO against the contractual commitment during the test. The buyer should have the right to observe the test, to participate in the planning, and to receive a test report that documents the results. Where the test reveals that the commitment cannot be met, SAP should be obligated to remediate without additional charge and to re test until the commitment is met.

Remedies when the commitment fails

The standard remedy for a missed RPO or RTO is typically a service credit, calculated as a percentage of the monthly subscription fee. The remedy looks reasonable on paper and is rarely meaningful in practice. A service credit of five percent of the monthly fee does not compensate the buyer for the impact of a missed RTO in an actual incident.

The buyer should negotiate enhanced remedies for missed disaster recovery commitments. The credit should be larger, scaled to the duration of the breach, and uncapped through a defined ceiling. The buyer should also retain the right to terminate without penalty if disaster recovery commitments are missed in a pattern that suggests systemic failure. The remedy structure should make SAP financially uncomfortable when commitments are missed, not just nominally credited.

Documentation and regulator reporting

A disaster recovery incident often triggers regulator reporting obligations. The buyer needs documentation from SAP that supports the buyer's downstream reporting. The standard contract sometimes does not specify the documentation SAP will provide, leaving it to be negotiated under pressure during an incident. The buyer should negotiate documentation rights into the contract.

SAP should commit to providing an incident report within a defined period after invocation, with the information the buyer needs for regulator reporting. The report should include the root cause analysis, the timeline of the incident, the recovery actions taken, the actual RPO and RTO achieved, and the remediation plan. The provision aligns SAP with the buyer's reporting obligations and removes the friction that otherwise impedes the buyer's regulator engagement.

Conclusion

The disaster recovery commitments inside the RISE contract deserve more attention than they typically receive. The standard offering works for many buyers and falls short for those with specific operational, regulatory, or competitive sensitivity. The negotiation should map the buyer's actual recovery requirement at the workload level, understand the underlying hyperscaler architecture, specify the testing cadence, enhance the remedies, and define the documentation that supports regulator reporting. The work is detailed and unglamorous. It pays off the day the disaster occurs and the contract is the difference between a controlled response and an uncontrolled one. A buyer who signed without negotiating disaster recovery commitments discovers the gap when it is too late to fix it. A buyer who negotiated before signature has the protection that the operational risk requires.