Data sovereignty risk in RISE.

Data sovereignty inside a RISE with SAP deployment is a question with three faces. The first is the contractual face, which lives inside the order form and the schedules that govern processing, residency, and access. The second is the regulatory face, which lives inside the jurisdictions that the buyer's data crosses through SAP and its hyperscaler partners. The third is the operational face, which lives inside the daily handling of data by SAP staff, sub processors, and managed service personnel. A RISE buyer that addresses one face and ignores the others holds a sovereignty position that the seven year term is built to erode. The work of this article is to look at all three faces together so the buyer can build a position that holds across the contract.

The contractual surface that defines sovereignty in RISE

The RISE order form references a stack of standard schedules. The Data Processing Agreement governs personal data processing. The Cloud Service Description governs operational scope. The Service Level Agreement governs uptime and incident response. The hyperscaler schedule governs the underlying infrastructure layer. Each schedule contains language on data residency, transfer, sub processor engagement, and access control that the buyer needs to read together rather than separately. The buyer that signs the order form without reading the schedules signs to language that the SAP standard position favours.

The contractual surface contains four levers that a buyer can move at signature. The first is the named hyperscaler region, which can be locked into the order form so SAP cannot shift the workload to a different region without buyer consent. The second is the data export language, which can be tightened to prohibit transfer outside the named region for any purpose, including support, monitoring, or analytics. The third is the sub processor list, which can be required as an annex so the buyer can review the named entities before signature and at each renewal. The fourth is the audit right, which can be expanded to include sovereignty specific testing on residency claims rather than only operational SOC reports.

Each of the four levers requires a redline in the contract. The standard order form does not contain the buyer side position on any of them. A buyer that does not redline accepts the SAP standard, which is calibrated for global operational efficiency rather than for the buyer's sovereignty profile.

The regulatory perimeter the data crosses inside RISE

Inside RISE, the buyer's data sits in the named hyperscaler region. Around that region, a regulatory perimeter applies. Inside the European Union, the perimeter is shaped by GDPR, the Digital Operational Resilience Act for financial services entities, the EU Data Act, and national supervision of cloud arrangements. Inside the United States, the perimeter is shaped by federal sector regulation, state level privacy laws, and the Cloud Act, which exposes data stored in the United States to lawful access requests regardless of the data subject's location. Inside the United Kingdom, the UK GDPR mirrors the EU position with national supervision. Inside Asia Pacific, the regulatory pattern varies by country, with Australia, Japan, Singapore, and India each operating a distinct framework.

The perimeter has two effects the buyer needs to model. The first is the static effect at signature. The hyperscaler region selected at signature places the data inside a specific regulatory frame. The second is the dynamic effect across the term. The regulatory frame in each jurisdiction is itself moving. EU rules on third country transfers have shifted twice in the last decade. US state privacy laws have multiplied. UK divergence from EU rules is widening. A buyer that models the regulatory perimeter only at signature carries a risk that the perimeter at year four or year seven of the contract differs in material ways from the perimeter at signature.

The hyperscaler layer and what it controls

The hyperscaler partner inside RISE introduces an additional sovereignty layer that the SAP layer does not control. The hyperscaler operates the physical data centre, the underlying compute and storage, the network ingress and egress, and the regional management plane. Each layer carries its own residency commitment, its own access control, and its own incident response.

The buyer side question for the hyperscaler layer is what data stays inside the named region under all operational conditions. Hyperscalers operate global support functions, global monitoring, and global incident response that can, under the standard terms, access data outside the named region for operational purposes. The hyperscaler sovereign cloud offerings, including AWS European Sovereign Cloud, Azure Sovereign Cloud, and Google Sovereign Cloud, are designed to constrain that access pattern. Whether RISE supports a sovereign cloud configuration depends on the named region and the SAP roadmap, which is itself moving.

The buyer side discipline is to ask the hyperscaler question explicitly inside the RISE negotiation, to document the answer inside the schedules, and to test the answer against the operating reality before signature. An answer that lives only inside marketing material is not an answer.

The sub processor risk across the term

RISE is delivered through a network of sub processors. SAP itself operates as the prime processor. The hyperscaler operates the infrastructure layer. Managed service providers operate the application administration. SAP partner organisations operate the implementation and the ongoing support. Third party software inside the BTP layer operates additional processing. Each sub processor sits inside its own jurisdiction, with its own access pattern, and with its own commercial relationship with SAP.

The sub processor list is rarely visible at signature. The standard SAP language reserves the right to add or change sub processors with notice. A buyer that does not redline the sub processor language accepts a sub processor surface that can expand across the term without buyer approval. The buyer side counter is to require the sub processor list as an annex at signature, to require buyer approval for material additions, and to require a defined notice period and objection right for any change.

The sub processor work is concentrated at signature and at renewal. Between those points, the buyer monitors the sub processor list through the audit right rather than through ongoing approval. The audit right has to be specific enough to test sub processor compliance with the named obligations. A general SOC report does not deliver that test.

The operational handling that turns contract language into reality

The contractual language and the regulatory perimeter are necessary but not sufficient. The sovereignty position holds only when the operational handling of data inside RISE matches the contractual language. Operational handling fails in four observable patterns.

The first pattern is the support escalation that crosses the region. A support ticket logged by a buyer side user is routed to a follow the sun support function that includes staff outside the named region. The staff access the data to investigate the ticket. The contract permits this if the language was not tightened. The buyer was not aware of the crossing because the operational pattern was not surfaced.

The second pattern is the development environment that holds production data. A development environment is provisioned in a different region for cost or capacity reasons. Production data is copied into the development environment for testing. The data has now crossed a regional boundary that the production contract did not anticipate.

The third pattern is the analytics overlay that aggregates data outside the named region. SAP product telemetry, BTP analytics, or operational monitoring aggregates data across the SAP global estate. The aggregation occurs inside SAP infrastructure that may sit outside the named region. The contract permits this in many cases. The buyer can constrain it through a specific redline at signature.

The fourth pattern is the backup and disaster recovery configuration that uses a paired region. The paired region may be inside or outside the regulatory perimeter, depending on the hyperscaler choice and the RISE region. A pairing across the perimeter creates a residency crossing that the buyer needs to inspect explicitly.

The protections that hold across the seven year term

Across the engagements documented at the firm, four protections hold sovereignty across the term. The first is the named region lock, with no change permitted without buyer consent. The second is the sub processor annex, with approval rights for material change. The third is the audit right with sovereignty specific scope, including residency testing rather than only operational compliance. The fourth is the renewal review of the sovereignty position at the midpoint of the term, with the right to require remediation if the regulatory perimeter or the operational handling has shifted in material ways.

Each protection is a redline at signature. The standard order form does not contain any of them in the form the buyer requires. The redline work is concentrated in the ninety days before signature, with named counsel on each side, and with the buyer's compliance and risk function in the room.

Conclusion: sovereignty is a structural commitment, not a clause

Data sovereignty inside RISE is a structural commitment that the buyer makes at signature and tests across the term. The commitment sits across the contract, the regulatory perimeter, the hyperscaler layer, the sub processor network, and the operational handling. A buyer that secures all five layers at signature carries a sovereignty position that holds through the term. A buyer that secures only the contract, or only the residency clause, carries a sovereignty position that the operational pattern is built to erode. The work is structural, the work is at signature, and the work is rarely revisited cleanly mid term. Do it once. Do it now.