Confidentiality and data protection in RISE.

The confidentiality and data protection provisions inside a RISE with SAP contract are usually drafted by SAP using a standard data processing addendum and accepted by the buyer with minor edits. The result is a contract that looks adequate on paper and falls short under operational pressure. Personal data flows across the SAP managed boundary. Confidential business data, including pricing, customer lists, supplier terms, and product roadmaps, sits inside a system operated by a third party. The standard contract gives SAP processing rights that are broader than most buyers intend and confidentiality protections that are narrower than most buyers assume. This article walks through the provisions that matter, the gaps that need to be closed, and the negotiation positions that produce a defensible contract.

The processing scope is broader than it appears

The standard RISE data processing addendum typically permits SAP to process personal data for the purposes of providing the service, for compliance with applicable law, and for the legitimate interests of SAP, including service improvement and aggregated analytics. The legitimate interests clause is the one that catches buyers. It can be read to permit SAP to use buyer data, in aggregated form, for product development, benchmarking, and other commercial purposes that the buyer did not consent to.

The buyer should narrow the processing scope. Service improvement should be limited to maintenance and security. Aggregated analytics should be limited to the purposes that benefit the buyer, with clear opt out for any commercial purpose that does not. The buyer should also confirm that the SAP AI offerings, the embedded Joule capabilities, and any future AI extensions do not consume buyer data for training without specific consent. The default consent is broader than most buyers realise, and the cost of withdrawing consent later is meaningful.

Sub processor commitments need teeth

The standard RISE data processing addendum lists SAP sub processors and reserves the right for SAP to add new sub processors with notice. The notice period is typically thirty days, and the buyer's right to object is limited to a termination right that few buyers will exercise. The mechanism gives SAP broad operational flexibility and limits the buyer's effective influence over the sub processor list.

The buyer should negotiate stronger sub processor commitments. The notice period should be longer, with at least sixty days for material additions. The buyer's right to object should include a continuation right that allows the buyer to remain on the existing sub processor configuration if the buyer rejects the addition. The flow down obligations should be specific, with SAP committing to ensure that each sub processor meets the same data protection standards as SAP and that SAP remains accountable for sub processor performance.

Transfer mechanisms have to address jurisdictions in scope

For buyers with operations across multiple jurisdictions, the cross border transfer mechanisms inside the RISE contract are central. The buyer needs to know how personal data moves from one jurisdiction to another, what legal basis applies to each transfer, and what protections SAP commits to. The standard contract typically uses standard contractual clauses, the EU US Data Privacy Framework where applicable, and supplementary measures as described by SAP.

The buyer should confirm that the transfer mechanisms cover every jurisdiction in scope, including the destination and the source. The buyer should also negotiate change rights. If a transfer mechanism becomes invalid during the term, for example through a court ruling that invalidates a framework, SAP should be obligated to implement an alternative mechanism at no additional cost. The provision protects the buyer against regulatory change that the contract did not anticipate.

Breach notification obligations require specificity

The standard breach notification clause typically requires SAP to notify the buyer of a personal data breach without undue delay. The language is consistent with regulatory expectations but vague enough to permit several days of delay in practice. For buyers with regulator obligations to notify within seventy two hours, the SAP delay can consume the entire window.

The buyer should negotiate a specific notification timeline. Twenty four hours from SAP awareness for any breach with potential regulator reporting implications. Forty eight hours for any other breach. The notification should include the information the buyer needs to file with regulators, with subsequent updates as the investigation progresses. The provision aligns SAP behaviour with the buyer's downstream obligations and removes the ambiguity that allows delay.

Confidentiality scope and survival

The standard confidentiality clause typically covers information marked as confidential or that would reasonably be understood as confidential. The scope is sufficient for most purposes. The survival period is usually three to five years after termination, which is shorter than many buyer obligations require, particularly for trade secrets, customer data, and pricing information that retain value beyond the survival period.

The buyer should negotiate confidentiality survival that aligns with the data being protected. Trade secrets should remain confidential indefinitely while they retain trade secret status. Customer data should remain confidential while applicable law requires. Pricing and commercial terms should remain confidential for a longer period than the standard. The provision should also extend to SAP personnel and SAP sub processors with appropriate flow down language.

Return and deletion at termination

The standard contract typically requires SAP to return or delete buyer data at termination, at the buyer's option, within a defined period. The provision sounds adequate. The operational reality is more complex. The buyer needs the data in a format the buyer can use. The deletion needs to be verifiable. The period needs to be long enough to allow the buyer to extract and validate the data before deletion is final.

The buyer should negotiate specific data return formats, with SAP committing to provide data in industry standard formats that the buyer or a successor system can consume. The deletion verification should include written certification from SAP that data has been deleted across all systems and sub processors, with the certification available for audit. The retention period should give the buyer at least ninety days from termination to extract data, with extension rights if validation requires more time.

Conclusion

The confidentiality and data protection provisions inside the RISE contract deserve detailed attention. The standard language is drafted to protect SAP first and to provide adequate coverage second. For buyers in regulated industries, for buyers with sensitive customer data, for buyers with trade secret information, the standard coverage is not enough. The negotiation should narrow the processing scope, strengthen the sub processor commitments, address the transfer mechanisms, specify the breach notification timeline, extend the confidentiality survival, and define the return and deletion mechanics. Each provision protects the buyer when something goes wrong. Each provision is more expensive to add after signature than to negotiate before. The data protection clause is not boilerplate. It is the contract that determines what happens to the most sensitive assets the business has when they sit inside a system run by someone else.