RISE with SAP and the Shared Responsibility Model 

The RISE with SAP Shared Responsibility Model defines who secures what in your transformation. In this model, SAP acts as your single-contact “prime contractor,” managing the hyperscaler (AWS, Azure, or GCP) and infrastructure (IaaS/PaaS) for you. This creates a dangerous “assurance gap,” as customers often assume SAP handles all security for RISE with SAP. In reality, you (the customer) retain 100% responsibility for securing everything inside your application, as outlined in the official SAP Roles & Responsibilities (R&R) document. This includes your data, all user access and roles, all custom code, and all application-level configurations. This article will define the official dividing line, building on the concepts of the foundational SAP Shared Responsibility Model.

Why Is the RISE Model So Confusing? The “Assurance Gap” 

The core of the confusion lies in the “assurance gap.” This is the dangerous difference between what organizations assume SAP is securing and what they are actually responsible for.

Traditional cloud models like IaaS, PaaS, and SaaS have relatively clear “dividing lines” for security. But RISE with SAP is not a simple SaaS product; it’s a “Business Transformation as a Service” (BTaaS). In this model, SAP acts as your prime contractor, bundling all services—including the hyperscaler (AWS, Azure, or GCP), technical managed services, and software—into a single contract.

This “single contract” is the problem. It creates a false sense of security, leading many CIOs and CISOs to believe “SAP handles it all.” In reality, you are still 100% responsible for everything inside your application. This assurance gap is the single biggest risk in a RISE migration, as it leaves critical areas like user access, custom code, and application configurations completely unsecured.

The Definitive Dividing Line: SAP’s Role vs. Your Role 

To avoid the “assurance gap,” you must understand the official dividing line. The simplest way to think about it is: SAP is responsible for the service, but you are responsible for your data and how you use it.

SAP’s Responsibility (Security OF the Cloud) 

In the RISE model, SAP acts as the prime contractor. This means they take responsibility for the foundational elements of the service. This includes:

  • Physical Infrastructure: Securing the physical data centers (via their hyperscaler partners).
  • Hyperscaler Management: Hyperscaler Management: Managing the IaaS/PaaS relationship and SLAs with AWS, Azure, or GCP. The customer has no direct access to this layer.
  • Technical Managed Services: This includes OS-level patching, database administration, and basic system health checks.

Your Responsibility (Security IN the Cloud) 

While SAP manages the infrastructure, you (the customer) retain 100% responsibility for everything inside your application. This is the “security in the cloud” portion of the model, and it’s where most security failures happen. SAP’s own guidance for the private edition makes it clear that a long list of security tasks belongs to the customer.

The table below defines this dividing line based on specific security domains.

RISE with SAP: Who is Responsible for What?

Security DomainSAP’s ResponsibilityCustomer’s Responsibility (Your Role)
Infrastructure (IaaS)Manages the hyperscaler relationship and infrastructure.N/A
OS & DB PatchingApplies technical patches to the OS and standard database.N/A
Application Patching (Security Notes)Applies some critical patches as part of the managed service.Must assess, request, and validate ALL application-level patches.
Application ConfigurationProvides the default, “vanilla” system.100% RESPONSIBLE for all secure configuration and system hardening.
Identity & Access (Roles, SoD)Provides the default user/role tools.100% RESPONSIBLE for all user provisioning, role creation, and SoD management.
Custom Code (ABAP/BTP)N/A100% RESPONSIBLE for the security, compliance, and performance of all custom code.
Integrations (APIs, RFCs)Secures its own platform endpoints.100% RESPONSIBLE for securing all third-party integrations, APIs, and RFC connections.
Data Security & ClassificationN/A100% RESPONSIBLE for classifying and protecting all business and user data.
Application Threat MonitoringMonitors its own infrastructure.100% RESPONSIBLE for monitoring the application layer for suspicious user behavior.
Audit & ComplianceProvides infrastructure-level audit reports (e.g., SOC 2).100% RESPONSIBLE for all application-level audit evidence and SOX/GDPR controls.

The 5 Gaps You Must Secure: An Actionable Checklist 

This table translates directly into an actionable checklist of the five critical security domains that you, the customer, must own. These are the most common areas of the “assurance gap” that organizations overlook, creating what Gartner identifies as a major risk in S/4HANA and cloud roadmaps.

1. Identity & Access Management (IAM) 

  • The Gap: SAP does not manage your user roles, authorizations, or Segregation of Duties (SoD) conflicts. You are fully responsible for “who can do what.”
  • Your Responsibility: You must define, build, and maintain all user roles, manage privileged access, and ensure SoD rules are enforced to prevent fraud. This is a critical area for SAP GRC and compliance.

2. Custom Code Security

  • The Gap: You own 100% of the risk for all custom ABAP code and BTP extensions. SAP will not scan your code for security, compliance, or stability.
  • Your Responsibility: You must scan all custom code before, during, and after the migration to find and fix vulnerabilities, as outlined in SAP’s own custom code adaptation process. This risk must be managed with a SAP DevSecOps strategy.

3. Application & Configuration Hardening 

  • The Gap: SAP delivers a “vanilla” system. You are responsible for securely configuring all application-level settings, such as password policies, secure network settings, and critical configurations.
  • Your Responsibility: This is not a “one and done” task. It requires a continuous SAP vulnerability management process to monitor for configuration “drift” and new vulnerabilities.

4. Application Threat Detection 

  • The Gap: SAP and the hyperscaler monitor their infrastructure for threats, but they do not monitor your application layer for suspicious user behavior (e.g., a user trying to run a sensitive payroll report) or active exploits.
  • Your Responsibility: You need a dedicated solution for SAP threat detection and response that understands SAP-specific attack patterns.

5. Audit & Compliance 

  • The Gap: SAP will not run your SOX controls for you. They will provide infrastructure-level reports (e.g., SOC 2), but you are 100% responsible for proving your application-level controls are working.
  • Your Responsibility: You must be able to provide evidence to your auditors for all application controls. This is why automated SAP compliance is essential to avoid findings.

How Onapsis Closes the RISE “Assurance Gap” 

The 5 Gaps translate into a clear, actionable plan. SAP and the hyperscaler secure the infrastructure, but you are responsible for securing the application. The Onapsis Platform provides the necessary visibility and control to manage your side of the model, effectively closing the “assurance gap.”

1. Secure Your Configurations and Access with Onapsis Assess 

Onapsis Assess directly addresses the critical gaps in Application Hardening and IAM. It provides a “security safety net” by continuously scanning your new RISE environment for misconfigurations, vulnerabilities, and risky user authorizations. It’s the tool that verifies your configurations are secure and your user roles are compliant.

2. Automate Custom Code Security and Compliance with Onapsis Control 

Onapsis Control solves the high-risk Custom Code and Compliance gaps. For custom code, it integrates into your development pipeline to find and fix security flaws before they migrate to production, enabling a true SAP DevSecOps process. For compliance, it automates the internal controls testing and evidence gathering required for SOX, eliminating manual work and proving your controls are effective.

3. Monitor for Application Threats with Onapsis Defend 

Onapsis Defend fills the Application Threat Detection gap. While SAP monitors its infrastructure, Defend monitors the application layer 24/7. It understands SAP-specific attack patterns and detects suspicious user behavior, integration-based attacks, and active exploits, feeding actionable alerts to your SIEM.

Ultimately, the Onapsis Platform unifies these functions. It gives you the single pane of glass you need to see, manage, and prove that your responsibilities in the RISE with SAP model are secure and compliant.

Frequently Asked Questions (FAQ) 

I’m moving to RISE with SAP, so doesn’t SAP handle all the security now? 

No, this is one of the most common and costly misconceptions. RISE operates on a Shared Responsibility Model. While SAP secures the core platform infrastructure, you (the customer) are still 100% responsible for securing your data, managing user access, securing all your custom code, and ensuring your configurations are compliant. You can learn more in our detailed guide on the SAP Shared Responsibility Model.

Who applies SAP Security Notes in RISE? 

This is a key “shared” duty. While SAP’s managed services may apply some critical technical patches, the official Roles & Responsibilities document states that you (the customer) must still assess, request, and validate all application-level Security Notes. You cannot assume all patches are being applied automatically.

How do I get evidence for my SOX audit in a RISE model? 

You are still 100% responsible for all your application-level controls. While SAP will provide infrastructure-level audit reports (like a SOC 2), you must provide the reports for your responsibilities. This includes all user access (IAM), Segregation of Duties (SoD), and change logs. This is why automated SAP compliance is essential to avoid negative findings.

What’s the biggest security gap in a RISE migration? 

The “Assurance Gap.” The biggest risk is assuming SAP is securing your application layer, when the contract says they are not. This gap is where critical tasks like custom code scanning and user role management are left unowned