RACI Matrix for RISE with SAP: Who Owns What in an S/4HANA Implementation

Read about a phase-based RACI matrix to define who owns decisions, upgrades, incidents, and changes in RISE with SAP S/4HANA programs.

SAP S/4HANA implementations rarely fail because teams lack technical expertise. More often, problems arise when responsibility for decisions, approvals, incidents, upgrades, testing, and change management is unclear. Under RISE with SAP, SAP takes on key platform and managed service responsibilities, while the Customer remains accountable for business outcomes and process ownership. This shift makes clear governance essential, especially when teams continue to apply on-premises assumptions to a managed cloud environment.

A practical way to address these gaps is a phase-based RACI matrix for the Customer, SAP, and implementation Partner. It clarifies who is Responsible, Accountable, Consulted, and Informed throughout the S/4HANA lifecycle, helping prevent duplicated effort, unclear escalation paths, and ownership gaps.

In this article, we explain how RISE changes accountability across implementation and operations, compare RACI responsibilities in Public and Private Cloud, and provide a practical framework for IT leaders, PMOs, SAP CoEs, and programme owners to establish clear ownership before and after go-live.

At a glance: A clear RACI under RISE with SAP starts with three principles: the Customer owns the business outcome, SAP owns the managed platform within the contracted scope, and the Partner owns implementation execution. From there, responsibilities should be mapped to specific activities, escalation paths, and governance routines - with the exact split validated against the RISE service scope and support agreement.

Need help with your RISE with SAP program?

Get a free consultation with our SAP experts.

Request a Free Consultation

Key parties in a RISE with SAP program

Before applying the RACI matrix across project phases, it’s important to align on the key parties in a RISE with SAP program and what they own. The RISE operating model changes not only who delivers certain services, but also where accountability sits, which can create gaps if teams keep working with on-premises assumptions. The roles below define ownership at a high level and serve as the baseline for the phase-based matrix that follows.

• Customer is the Business and Process Owner and remains Accountable for the final solution and its business outcome. This includes owning process decisions and acceptance criteria and being Responsible for organizational Change Management, such as readiness, adoption, and post–go-live governance.
• SAP (RISE Provider) acts as the Platform and Managed Services Owner and is Accountable for delivering and operating a working, updatable infrastructure and standard software within the RISE scope.
• Partner (System Integrator) is the Implementation and Configuration Owner and is Responsible for translating business requirements into solution design and configuration, executing data migration, and coordinating build and delivery activities across the project lifecycle.

Once these roles are defined, you need a working ownership map. The RACI matrix below assigns responsibility by stage and task, making decision points and escalation routes explicit.

RACI Matrix Structure by Project Phase

To make responsibilities easy to validate and operationalize, this RACI matrix is structured around the three phases that define most SAP S/4HANA programs under RISE with SAP. Each phase includes tasks that most often create gray zones, where delays, rework, or confusion typically emerge.

How to read the matrix:

• A (Accountable) — owns the outcome and final decision
• R (Responsible) — performs the work
• C (Consulted) — provides input; two-way communication
• I (Informed) — kept up to date; one-way communication

As a guiding principle for RISE programs, the Customer remains Accountable for business outcomes and organizational readiness, SAP is Accountable for the platform and managed services, and the Partner is Responsible for implementation execution (design, configuration, migration, and coordination). The tables below translate that principle into concrete ownership per phase.

Phase 1: Design and planning

This phase defines what will be implemented and how it will operate in the target landscape. It also sets the rules for standardization vs. deviation — a key determinant of scope, timeline, and long-term maintainability.

Why the split looks like this:

• The Customer owns business requirements: no external party can be Accountable for what the business truly needs, or for accepting the final process design.
• Fit-to-standard is Partner-led because it requires structured workshops, process mapping to SAP best practices, and decision documentation — with SAP consulted for constraints and service boundaries.
• RISE package activation is SAP-owned, since SAP controls the provisioning and delivery of the RISE-managed environment.

Phase 2: Realization and configuration

This is where the blueprint becomes a working solution: the environment is prepared, configuration and extensions are built, data is migrated, and users are enabled to operate new processes.

How to interpret this phase:

• SAP remains A/R for the environment setup under RISE, because the platform and core services are delivered and operated by SAP.
• The Partner is A/R for configuration and BTP development, because implementation quality depends on solution design, build discipline, and test coordination.
• Data migration under RISE is deliberately split between business ownership and technical execution. The Customer is Responsible for the data content (meaning, completeness, ownership, and readiness). The Partner is Accountable/Consulted for the migration approach and execution mechanics (tools, mapping logic, loads, reconciliation) — but can’t be Accountable for business data quality unless explicitly agreed.
• Training is most effective when the Customer is Accountable (in terms of readiness and adoption), and the Partner is Responsible for facilitating delivery.

Phase 3: Operation and support

After go-live, success depends on clarity in incident handling, updates, and change. Under RISE, the operating model is not simply “Customer runs, SAP supports.” It is a shared model in which SAP owns the managed platform scope. At the same time, application support and business readiness responsibilities are split between the Customer and the Partner, depending on the agreed support setup.

 * Exact support responsibilities depend on the contracted support model.

What this means operationally:

• Change management stays with the Customer because adoption, communications, process governance, and user readiness are business-owned responsibilities.
• Infrastructure management moves to SAP under RISE — this is one of the most significant responsibility pivots compared to on-premises models.
• Update management is led by SAP in the RISE model. However, it still requires Customer and Partner participation for readiness activities such as regression testing, business communications, and sign-off, which is why both are Consulted.
• Incident handling should follow a tiered model aligned with the support contract. In many RISE programs, Level 1 and Level 2 support are executed by the Partner under an application management or managed services agreement, while the Customer remains Responsible for initiating incidents, providing business context, and owning business impact and prioritization.
• Level 3 issues that fall within SAP’s managed scope are escalated to SAP, where SAP is Accountable and Responsible for resolution.

RACI Before and After RISE with SAP

One of the easiest ways to understand the impact of RISE is to compare it with a traditional on-premises model.

The key change is therefore not that SAP takes over the entire SAP environment. Instead, technical and infrastructure responsibilities move into SAP’s managed-service boundary, while business ownership remains with the Customer and implementation responsibilities remain with the Partner.

That distinction should be reflected in project governance from the beginning.

What RISE with SAP Does Not Automatically Own

RISE with SAP can reduce infrastructure and technical management responsibilities for the Customer, but it does not eliminate Customer or Partner responsibilities.

Depending on the contracted scope, organizations may still need to own or separately arrange:

• application management and functional support;
• business process ownership;
• integrations with non-SAP systems;
• BTP extensions and custom applications;
• testing and regression activities;
• change management and user adoption;
• business continuity planning;
• business controls and compliance for how the solution is used;
• continuous process improvement.

SAP’s Private Cloud roles-and-responsibilities documentation explicitly distinguishes standard services from optional services and states that tasks not purchased or provided by SAP remain the Customer’s responsibility.

The practical implication is simple: never infer responsibility from the fact that a capability exists within RISE. Map each activity to the actual service scope and operating agreement.

Where Projects Get Stuck: Two Core RISE Responsibility Shifts

The RACI tables above do more than distribute tasks across three parties. They highlight where RISE with SAP changes the operating model — and where projects most often slip into responsibility “gray zones.” In on-premises programs, many decisions and operational actions naturally default to the Customer’s IT team. Under RISE, those defaults no longer hold, and the fastest way to create friction is to keep working as if they do.

Two shifts need to be explicit from day one.

IaaS/PaaS handover to SAP

Under the RISE with SAP model, SAP becomes Accountable for infrastructure (IaaS) and platform management (PaaS) as the platform and managed services owner. This is a key reason organizations choose RISE: SAP provides and operates an updatable, secure, supported foundation for SAP S/4HANA.

Where the gray zones show up most often:

• Teams treat infrastructure and platform responsibilities as shared by default.
• The Partner is expected to fully own activities that sit inside SAP’s managed scope.
• Escalation paths, access boundaries, and operational runbooks are not aligned with how RISE services are actually delivered.

What it leads to:

• Slower diagnosis during incidents
• Handoffs that “bounce” between teams
• Upgrade-related delays because responsibilities for readiness vs execution are not separated

The Customer’s new role as process owner

Under RISE, the Customer’s IT organization shifts away from day-to-day infrastructure execution and toward owning and controlling business processes, adoption, and organizational readiness. This shift doesn’t reduce accountability but clarifies it. The Customer remains Accountable for the business outcome.

What the Customer is always Accountable for:

• Process design decisions and acceptance criteria
• Readiness to operate after go-live (people, procedures, governance)
• Compliance expectations for how the solution is used in daily operations
• Value realization and process performance

Where the gray zone shows up most often:

• Business readiness is treated as an “implementation deliverable” because SAP and the Partner own large parts of the delivery.
• Process governance, stakeholder alignment, and training effectiveness are not assigned clear ownership.

What this means in practice

To prevent gray zones from turning into delivery delays and post–go-live instability, RISE programs need an explicit, phase-based RACI that reflects the real operating model:

• SAP owns the platform and manages the service boundaries.
• The Partner executes implementation within that framework.
• The Customer owns the business outcome and the organizational change that makes the solution work.

RACI in RISE Public Cloud vs. RISE Private Cloud

The RISE with SAP operating model is consistent in one key principle: SAP owns the platform scope, the Partner owns implementation execution, and the Customer owns the business outcome. What changes significantly, however, is how Accountable and Responsible responsibilities are distributed once you choose between SAP Cloud ERP and SAP Cloud ERP Private. Public Cloud is built for standardization, with an SAP-driven release cadence and limited deep customization in the core. Private Cloud provides more flexibility and control, but that flexibility comes with additional responsibility for planning, compatibility, and controlled administrative activities.

The comparative view

What each shift means for governance

Custom code management

In Public Cloud, deep custom code in the core is effectively excluded, which shifts governance toward standard processes and extensions on BTP rather than ABAP ownership. To avoid a new gray zone here, define who owns the BTP extension backlog and the approval model for extensions (Customer vs. Partner), even if the core remains standardized. In Private Cloud, the Customer and Partner need explicit ownership for ABAP inventory, remediation, and modernization, including who owns the prioritization of the ABAP backlog and who is Responsible for keeping it compatible over time.

System upgrade schedule

Public Cloud implies SAP-driven updates, which reduce scheduling control but increase the need for predictable readiness and regression discipline. In the project charter, define how release communications, regression testing, and business sign-off will work around SAP’s update cadence. In Private Cloud, where the Customer controls the upgrade window, you must define who approves the timing, what gates the decision (readiness criteria), and who owns the upgrade readiness plan, including regression scope and fallback approach.

Access to the OS/DB level

Public cloud keeps OS/DB access closed, which simplifies operations but changes how technical troubleshooting and admin work are handled. In governance terms, define the escalation path to SAP and what evidence is required for efficient resolution. In Private Cloud, limited controlled access enables some admin tasks by the Customer or Partner, but it also requires clear access governance: who has access, what tasks are allowed, and how actions are audited.

Compliance

In the public cloud, SAP is Accountable for compliance with the base package, while the Customer focuses on compliant process execution and internal controls around usage. In the project charter, define responsibility for business controls, access governance, and evidence collection. In Private Cloud, customization expands the compliance surface, so the Customer must explicitly own compliance for the customized landscape, including validation of custom developments, integrations, and changes over time.

Infrastructure selection

Public Cloud provides simplicity and single ownership because SAP selects the hyperscaler Partner within the offering. In the charter, the focus should be on service boundaries, SLAs, and escalation rather than infrastructure choice. In Private Cloud, the Customer has the ability to choose between SAP HEC or hyperscaler IaaS, which requires explicit responsibility for selection criteria, risk assessment, and the operational implications of that choice.

Public Cloud offers convenience and a clearer single accountability from SAP (SAP A/R), but at the cost of reduced control over upgrade timing and deep customization. Private Cloud offers greater control and flexibility, but requires the Customer (and often the Partner) to assume a larger Responsible/Accountable share for ongoing management, compatibility, and governance of the landscape.

Public Cloud vs. Private Cloud: The RACI Implication

The practical distinction can be summarized as follows:

Public Cloud

More standardization
→ More SAP-managed release behavior
→ Less direct technical control
→ Stronger Customer accountability for readiness and business adoption

Private Cloud

More flexibility
→ More Customer influence over the environment
→ More governance around compatibility and administration
→ Greater need for explicit Customer / Partner responsibility boundaries

Public Cloud therefore tends to simplify the RACI around technical operations, while Private Cloud requires more detailed governance around responsibilities that remain customer- or partner-managed.

Connecting RACI to the Operating Model

A RACI matrix should not exist as a standalone project document.

For a RISE program, it should be connected to the operating model that governs the environment after go-live.

A practical model is:

RACI → Support Model → Escalation Paths → Release Management → Governance Cadence

For example, an incident responsibility should not end with “Partner = R.” The operating model should also define:

• what triggers escalation;
• when SAP must be engaged;
• what information accompanies the escalation;
• which SLA applies;
• who communicates business impact;
• who confirms resolution.

The same principle applies to upgrades, integrations, security incidents, data issues, and production changes.

A Practical RISE Governance Checklist

Before go-live, confirm that the program has explicitly defined ownership for:

• business requirements;
• process decisions;
• solution configuration;
• data ownership and migration;
• integrations;
• BTP extensions;
• testing;
• cutover;
• user adoption;
• incidents and escalation;
• upgrades and regression testing;
• security and access;
• compliance controls;
• application support;
• continuous improvement.

For every item, the governance team should be able to answer five questions:

Who is Accountable?
Who is Responsible?
Who must be Consulted?
Who must be Informed?
What happens when something goes wrong?

RISE with LeverX - a Certified SAP Partner

At LeverX, we help companies design and execute SAP S/4HANA transformations using the RISE with SAP model, including programs with complex integrations, business processes, extensions, data, and organizational change.

Our role is not limited to implementation. We help establish the operating model around the transformation so that responsibilities between Customer, SAP, and Partner remain clear throughout the program lifecycle.

Our services can include:

• Consulting: Define transformation strategy, governance, business processes, and solution architecture.
• Implementation: Configure and optimize SAP S/4HANA in line with business requirements and the selected RISE model.
• Integration: Connect SAP with non-SAP applications and establish reliable data and process flows.
• Support: Provide ongoing application and technical support aligned with the agreed operating model.
• Application management: Continuously monitor, optimize, and evolve the SAP landscape after go-live.

When you RISE with LeverX, you are not just implementing SAP software - you are putting a clear operating model around the transformation.

Book a free consultation

Conclusion

RISE with SAP can simplify SAP S/4HANA ownership, but only when responsibilities are clearly defined. A phase-based RACI matrix helps eliminate “gray zones” between the Customer, SAP, and implementation Partner, making decision-making, escalation, upgrades, and support more predictable.

Under RISE, SAP takes responsibility for infrastructure and platform management, while the Customer remains accountable for business outcomes, process decisions, adoption, and value realisation. The Partner bridges the two by delivering configuration, extensions, migration, and testing within SAP’s managed service boundaries.

The choice between Public and Private Cloud also affects governance. Public Cloud provides greater standardisation and SAP-led accountability, while Private Cloud offers more flexibility and control. In either model, success depends on the same fundamentals: define the RACI, resolve ownership gaps before go-live, and embed responsibilities into ongoing support and governance.

Disclaimer: The RACI assignments in this article are provided as a practical framework and are not a substitute for the contractual roles and responsibilities defined in a specific RISE with SAP agreement. Actual ownership may vary depending on the SAP cloud edition, purchased services, support model, system scope, and customer-specific arrangements. Always validate responsibilities against the applicable SAP documentation, service description, and contract before using this matrix for project governance.