Sub processor obligations under RISE.

The sub processor list inside a RISE with SAP contract is longer than most buyers realise. The buyer sees SAP on the order form and assumes that SAP operates the service. SAP does operate the service. SAP also relies on a layered chain of sub processors that includes the hyperscaler under which the workload runs, the regional infrastructure operators inside that hyperscaler, the network and content delivery providers, the security operations partners, the support and helpdesk providers, the analytics and observability vendors, and an evolving list of specialist sub processors for specific RISE components. The chain matters because every sub processor handles the buyer data under the legal frame the buyer has accepted in the master agreement and the data processing addendum. A buyer that does not map the chain, does not negotiate notification rights, and does not secure audit access ends up with a data processing exposure that exceeds what was scoped in the original risk assessment.

What the standard data processing addendum says

The standard SAP data processing addendum provides for a published sub processor list that the buyer can review at any time. The addendum grants SAP the right to engage new sub processors during the term, with notification to the buyer. The buyer is granted the right to object to a new sub processor on reasonable data protection grounds within a notification window, typically thirty days. If the buyer objects and the parties cannot agree, the addendum provides for a termination right limited to the affected service, with refund or credit for prepaid amounts.

The standard language sounds protective. It includes named sub processors, notification, objection, and termination as a remedy. The practical operation of the standard language is weaker than the text suggests. The notification mechanism in many engagements is a passive update to a public web page, with no proactive notification to the buyer commercial counterpart. The thirty day objection window does not align with the procurement and legal review cycles of large enterprises. The termination remedy applies only to the affected service, but the affected service is often the entire RISE workload, making the termination remedy in practice an exit from RISE rather than an objection to a specific sub processor.

The addendum also has gaps in scope. The published sub processor list typically names the principal sub processors but does not always name the deeper chain, including the contractors and the third party tooling vendors that the principal sub processors themselves use. The depth of the chain that the addendum does not disclose can be significant in regulated industries.

The structure of the sub processor chain

The sub processor chain in a RISE deployment typically operates at four layers. The first layer is the hyperscaler under which the RISE workload runs. The hyperscaler is the principal sub processor with the largest data handling footprint. Whether the workload runs on AWS, on Microsoft Azure, on Google Cloud, or on a regional hyperscaler in specific jurisdictions, the choice has direct implications for data residency, for the security control framework, and for the regulatory regime that applies to the data.

The second layer is the regional infrastructure operations team inside SAP that operates the RISE workload on top of the hyperscaler. The regional operations team is structured by SAP geography and by service line. The team that operates the European RISE workloads differs from the team that operates the North American RISE workloads, which differs from the team that operates the Asia Pacific workloads. Each regional team may include contracted operations personnel as well as direct SAP employees, with the contracted personnel often working through specialist services partners.

The third layer is the network of specialist sub processors that support specific RISE components. Identity and access management, security event monitoring, backup and disaster recovery, performance monitoring, application performance management, log aggregation, and the analytics tooling that SAP itself uses to monitor the RISE platform each often involve a separate sub processor or third party vendor. The list of specialist sub processors is the layer that changes most frequently across the contract life.

The fourth layer is the support and customer service chain. The first line and second line support for RISE incidents may be staffed by SAP regional support centres, by contracted support partners, or by a combination. The support staff have privileged access to the buyer data when handling incidents, and the geographic location of the support staff has data residency implications.

The buyer side mapping of the chain

The buyer side mapping of the sub processor chain is the precondition for negotiating useful protections. The mapping should be conducted before the contract is signed, using the published sub processor list as the starting point, the SAP trust centre documentation as the second source, and the SAP customer engagement team as the third source. Where the published list and the trust centre documentation leave gaps, the buyer should request named disclosure through the contracting team.

The mapping should document, for each named sub processor, the role inside the RISE service, the geographic location of the operations, the data categories that the sub processor handles, the security certifications the sub processor holds, the regulatory regime that applies, and the SAP internal owner of the sub processor relationship. The documentation should be maintained as a living artifact rather than as a one off exercise, with named owners on the buyer side responsible for reviewing the SAP published updates and reflecting them in the buyer inventory.

The mapping should also identify, for each sub processor category, the residual risk that the standard SAP addendum does not address. The residual risk might be a sub processor located in a jurisdiction with adequacy concerns, a sub processor without a certification the buyer relies on for its own compliance, or a sub processor whose operational model exposes the buyer data to a broader set of personnel than the buyer assumed.

Negotiating notification and audit rights

The notification rights that the buyer should negotiate go beyond the standard published list mechanism. The buyer side position includes proactive notification to a named buyer contact for any new sub processor addition, with the notification period extended from thirty to sixty days to align with enterprise procurement cycles. The notification should include the sub processor category, the role, the data handling scope, and the location, sufficient for the buyer to conduct a meaningful risk review.

The buyer should also negotiate the right to a transition period if the buyer reasonably objects to a sub processor change. The transition period gives the buyer time to migrate off the RISE service or to negotiate a workaround, rather than triggering an immediate termination. The transition period is rarely conceded in full but is achievable at the regional general counsel level for major customers in regulated industries.

The audit rights inside the standard addendum are limited. The standard position grants the buyer access to SAP audit reports rather than a right to conduct an independent audit of SAP or its sub processors. The buyer side position should require, at minimum, the right to receive the audit reports of named sub processors when those reports are available, the right to a meeting with the SAP and sub processor audit teams to discuss the audit findings, and the right to a remediation report when the audit identifies findings relevant to the buyer data.

For buyers in highly regulated industries, the audit rights should extend to a direct audit right with reasonable scope and frequency limitations. The direct audit right is rarely available for routine RISE deployments but is available for buyers whose regulatory regime mandates it, with the audit cost typically borne by the buyer.

What to escalate and what to accept

The buyer should escalate on the notification mechanism, on the named disclosure of the deep chain in regulated industries, and on the audit access for buyers under specific regulatory regimes. These items are achievable at the regional general counsel level and are reasonable departures from the standard position.

The buyer should usually accept the published sub processor list as the contractual reference, the standard data processing addendum as the legal framework, and the standard SOC and ISO certifications as the audit substitute for routine deployments. Pushing for departures beyond these items typically does not produce concessions proportional to the negotiation effort, and the buyer is better served by allocating the negotiation bandwidth to commercial structure, term length, and exit clauses.

Conclusion: the chain is the risk surface

The sub processor chain inside a RISE with SAP contract is the risk surface that the buyer commits to when the order form is signed. The chain is not visible from the marketing materials, is partially visible from the published sub processor list, and is fully visible only when the buyer asks the right questions to the right people. A buyer that maps the chain, negotiates proactive notification, secures meaningful audit access in proportion to its regulatory profile, and maintains the inventory across the contract life manages the residual risk inside the operating model. A buyer that accepts the standard data processing addendum without the mapping work carries a residual exposure that often surfaces in regulator examinations, customer audits, or incident reviews. The chain is the contract. The contract is only meaningful when the chain it covers is mapped.