RISE with SAP RACI and SLA Guide: What SAP Is Actually Responsible For (and What It Isn't)

RISE with SAP's central promise is simplification: one vendor, one contract, one responsibility. The reality is a multi-layered shared responsibility model that distributes accountability between SAP, the hyperscaler, and the customer in ways that are far from transparent — and that systematically shift risk onto the customer when things go wrong. Understanding the RISE RACI isn't an academic exercise. It's the difference between knowing who to hold accountable for a service failure and discovering, mid-incident, that SAP considers the problem yours.

SAP's RISE advisory documentation describes the model in general terms. What it doesn't do is tell you where the handoffs break down in practice, which exclusions protect SAP from SLA claims, or how the three-party structure (SAP, hyperscaler, customer) creates accountability voids that enterprise service desks regularly fall into. This guide covers all of that.

The RISE Shared Responsibility Model

RISE with SAP operates across three distinct layers, each with its own accountability owner. Understanding this structure is essential before analysing where responsibilities sit and where gaps emerge.

Layer 1: Infrastructure. The underlying compute, storage, and network infrastructure is operated by one of the three hyperscalers (AWS, Microsoft Azure, or Google Cloud Platform), depending on your RISE contract and region. SAP does not own or operate this infrastructure directly — it procures managed infrastructure from the hyperscaler as part of the RISE bundle. This means that infrastructure incidents ultimately trace to the hyperscaler's SLA with SAP, not directly to SAP's SLA with you.

Layer 2: Managed Services. SAP is responsible for operating the S/4HANA system — including basis administration, system updates, patching, backups, and disaster recovery — within the infrastructure provided by the hyperscaler. This is the "managed cloud" element of RISE. SAP's responsibilities here are substantial but bounded: they extend to the SAP application layer and the infrastructure configuration SAP controls, but stop at the infrastructure layer itself.

Layer 3: Application and Business Processes. The customer is responsible for the application configuration, business process design, user management, data quality, and all custom developments or extensions built on BTP or as ABAP code within the managed S/4HANA system. The boundary between SAP's managed layer and the customer's application layer is one of the most contested areas in RISE incidents.

What SAP Actually Owns in RISE

Based on the standard RISE with SAP Service Description and the accompanying SLA documentation, SAP's formal responsibilities encompass the following areas:

• Infrastructure provisioning and management — provisioning, operating, and maintaining the cloud infrastructure per the agreed configuration
• S/4HANA basis operations — OS patching, database management (SAP HANA), backup and recovery, system monitoring, and performance management at the system layer
• SAP application updates — applying SAP-released patches, support packages, and legal change packages within the agreed maintenance windows
• System availability — maintaining the production system to the contracted SLA availability target (typically 99.5% measured monthly, with specific exclusions)
• Disaster recovery — maintaining the recovery point objective (RPO) and recovery time objective (RTO) commitments in the RISE SLA
• Security baseline — operating the infrastructure and SAP application layer to SAP's defined security baseline, including vulnerability patching within defined timelines
• Network connectivity — maintaining connectivity between the SAP-managed environment and the customer's network per the agreed integration architecture

What the Customer Owns

The customer's responsibilities in RISE are broader than most enterprises appreciate at the point of signature. They include:

• Application configuration — all SAP configuration settings, including IMG configuration, user roles, authorisation objects, and organisational structure
• Custom developments — all ABAP code, BTP extensions, APIs, and custom Fiori apps are customer responsibility. SAP is explicitly not responsible for defects in customer code, even if those defects arise from SAP patches or updates
• Data quality and migration — all data loaded into the system, including the quality and accuracy of migrated legacy data
• User access management — provisioning, maintaining, and auditing user access. SAP Identity and Access Management is a separate service and is not automatically included in all RISE tiers
• Business process design and testing — SAP is not responsible for ensuring that the system meets your business requirements; they deliver a functioning S/4HANA platform, not a configured business solution
• Interface and integration management — while SAP Integration Suite may be bundled in RISE, the design, development, and operation of specific integrations between SAP and third-party systems is the customer's responsibility
• Regulatory and compliance configuration — country-specific legal configurations, GDPR controls, and audit-trail configurations are the customer's responsibility to implement within the provided system

The Accountability Gaps SAP Doesn't Advertise

The formal RACI looks clean on paper. The operational reality contains several recurring accountability gaps that enterprises only discover during incidents.

The Hyperscaler Pass-Through Problem

When infrastructure incidents occur — hardware failures, availability zone disruptions, network outages — SAP's incident response process routes the investigation to the relevant hyperscaler. SAP does not have direct operational control over the hyperscaler's infrastructure; it has an SLA with the hyperscaler that governs remediation timelines. For the enterprise customer, the practical effect is that major infrastructure incidents can take 2–4 times longer to resolve under RISE than under a traditional co-location or on-premise model, because the resolution chain passes through SAP and then to the hyperscaler before reaching the engineers who can actually fix the problem.

SAP's SLA with you does not directly inherit the hyperscaler's SLA with SAP. SAP may have contractual protections against hyperscaler failures — but your protection is limited to SAP's SLA obligations, not the hyperscaler's. And many hyperscaler-related incidents fall within SAP's SLA exclusions.

The "Customer Code" Deflection

In application-layer incidents, SAP's first line of defence is to determine whether the problem is in SAP standard code or customer custom code. If the incident can be attributed to custom code — including custom code that was working before SAP applied a patch — it is classified as a customer responsibility and removed from SAP's SLA obligation. This classification is made by SAP and is frequently contested.

The practical implication: if you have significant custom developments in your RISE system (which most enterprises do), you are exposed to an incident classification risk that effectively transfers SLA breach liability from SAP to you, regardless of whether SAP's update triggered the custom code failure.

The BTP Boundary

SAP BTP is included in RISE but operates under a separate service description. The integration points between S/4HANA and BTP — which are often critical business process paths — sit at the boundary between two different service models. Incidents that arise at or across this boundary frequently trigger disputes about which side of the boundary caused the failure, delaying resolution and often leaving the customer carrying the accountability.

RISE SLA Mechanics: Reading the Small Print

The RISE SLA commits SAP to a system availability target, typically expressed as 99.5% monthly uptime for the production system. This sounds robust — it allows roughly 3.6 hours of downtime per month. But the operative word is "measured," and the SLA's measurement methodology is designed to minimise SAP's apparent downtime exposure.

The standard RISE SLA table below illustrates the formal accountability framework. Note the prevalence of "shared" and "customer" responsibilities in the application layer — this is where most real-world incidents actually occur.

SLA Exclusions That Protect SAP, Not You

The RISE SLA's exclusion list is extensive. Common exclusions that prevent customers from claiming SLA credits despite experiencing genuine downtime include: planned maintenance windows (typically 12–20 hours per month, often scheduled without adequate notice); hyperscaler-caused outages classified as force majeure; performance degradation caused by customer-driven workload spikes that exceed provisioned capacity; incidents triggered by customer configuration changes or custom code deployments; and failures in third-party integrations that are customer-managed.

In practice, these exclusions mean that the effective SLA coverage is materially lower than the headline 99.5% figure. Enterprises have reported measured availability of 98–99% while SAP's formal SLA reporting shows full compliance — because the gap is explained by exclusions rather than actual SLA breaches.

How to Actually Enforce Your RISE SLA

SLA enforcement requires proactive instrumentation, documentation, and escalation discipline. The practical steps that generate results are: establishing independent availability monitoring (not relying solely on SAP's SAP Cloud ALM metrics); documenting every incident with timestamps, business impact quantification, and SAP ticket numbers from the moment of occurrence; formally challenging SAP's incident classification within the contractual dispute window (typically 30 days); and escalating to the named SAP account executive when disputes are unresolved after two escalation cycles.

Service credits — the financial remedy for SLA breaches — are rarely pro-actively offered by SAP. They must be formally claimed, within the prescribed window, with documented evidence. Enterprises that don't actively track and claim credits leave money on the table and, more importantly, allow SAP to avoid accountability for systemic service failures.

What to Demand to Improve the RACI

The standard RISE RACI can be improved at signature or renewal through negotiation. Key contractual improvements worth pursuing include: explicit joint incident management procedures with defined response times for cross-boundary incidents; elimination or narrowing of the hyperscaler pass-through exclusion; defined escalation paths with named SAP executives for P1 incidents lasting more than two hours; independent availability calculation methodology that captures customer-experienced downtime rather than SAP's platform-reported uptime; and financial service credits worth at least 5% of monthly subscription value for availability failures below 99.0%. For a complete review of what's achievable in RISE contract negotiations, see our RISE renewal negotiation guide and our broader SAP contract negotiation service.