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 due to a lack of knowledge among the teams responsible for configuring processes or performing migrations. Failures arise because no one knows exactly who is responsible for decisions being made and what their consequences are. When responsibilities aren't clearly defined, projects accumulate gray areas where the Customer, SAP, and Partner assume someone else is handling approvals, incident response, upgrades, testing, or change management. The result is predictable: delayed decision-making, repeated handoffs, surprises on release day, and operational issues that persist long after the system goes live.

RISE with SAP is designed to reduce ambiguity by bundling software, infrastructure, and managed services into a single commercial model. At the same time, it changes the balance of control: SAP takes ownership of key platform and managed service responsibilities, while the Customer’s IT team shifts its focus from day-to-day infrastructure execution to governing business outcomes, adoption, and process ownership. This shift creates a different risk: teams may continue to apply on-premises assumptions about who owns decisions and escalations, even though the boundaries have shifted.

In this article, we offer a practical solution: a RACI matrix adapted for SAP S/4HANA implementation within the RISE with SAP model. By identifying Responsible, Accountable, Consulted, and Informed individuals throughout the project lifecycle, the matrix helps all parties align early on, avoid duplication of effort, and eliminate blind spots, particularly in areas most prone to conflict, such as decision-making, incident escalation, update management, and organizational change.

We can speak to this topic because we see these responsibility splits play out in real programs. As an implementation partner, we’re positioned between the business and SAP’s managed service boundaries, translating business requirements into configurations and extensions, coordinating migrations and testing, and supporting the Customer through readiness and adoption, while aligning every decision with what SAP owns and operates under RISE. That vantage point makes responsibility gaps very visible, and it also makes them solvable with the right governance tool.

This article will benefit IT executives and project managers who need a clear operating model before and after go-live: CIOs and IT directors defining accountability, PMOs running multi-party delivery, SAP CoE leads building governance, and program owners choosing between RISE Public Cloud and RISE Private Cloud. You’ll receive a phase-based RACI matrix for the Customer (process owner), SAP (platform owner), and Partner (implementation owner), along with an explanation of where RISE shifts accountability and why the cloud deployment choice fundamentally alters the RACI dynamic.

By the end, you’ll have a structured way to define ownership, reduce friction, and set expectations that hold up not only during implementation, but also in day-to-day operations afterward.

Key parties (adjusted roles)

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.

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.

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 managed service boundaries.
• The Partner executes implementation within that framework.
• The Customer owns the business outcome and the organizational change that makes the solution work.

Detailed Analysis: RACI in RISE Public vs. RISE Private

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 public cloud, SAP is Accountable for compliance of 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.

Conclusion

RISE with SAP can simplify SAP S/4HANA ownership, but only if responsibilities are made explicit instead of assumed. The biggest risks in S/4HANA programs are rarely technical in nature. They show up when decision rights, incident paths, upgrade readiness, and change management fall into “gray zones” between the Customer, SAP, and the implementation Partner. A phase-based RACI matrix clarifies ownership in those gray zones, enabling teams to move faster during delivery and maintain stability in production.

The most significant shift to recognize is the change in operating model: under RISE, SAP becomes Accountable for infrastructure (IaaS) and platform management (PaaS), while the Customer remains Accountable for the business outcome — process decisions, adoption, readiness, and value realization. The Partner’s role is to execute implementation within SAP’s managed service boundaries, translating requirements into configuration and extensions, and coordinating migration and testing. When this triad is aligned early, escalation becomes predictable, upgrades become manageable, and accountability stops bouncing between teams.

Your cloud choice under RISE should be treated as a governance decision, not just a technical preference. Public Cloud strengthens standardization and SAP-led accountability, but reduces control over upgrade timing and the depth of customization. Private Cloud increases flexibility and control, but requires the Customer and Partner to carry more responsibility for compatibility planning, controlled administration, and ongoing governance. Either way, the practical path to success is the same: document the RACI, resolve gray zones before go-live, and operationalize it through a clear support model, an upgrade readiness plan, and regular governance routines.

If you align these responsibilities upfront, you don’t just reduce conflicts — you protect delivery velocity, post–go-live stability, and the long-term ability to evolve your S/4HANA landscape under RISE with SAP.