COMMENTARY: SAP powers the core business processes of organizations worldwide. Over five decades, SAP’s ERP platform has evolved from predominantly customer-managed, on-premises systems to cloud-based offerings, RISE with SAP, a managed cloud offering that combines SAP S/4HANA Cloud, infrastructure, and technical operations under a single subscription. While this reduces operational overhead, customers retain responsibility for many critical security, governance, and compliance controls.
For many organizations, migrating to RISE marks the end of a years-long transformation. SAP assumes responsibility for much of the underlying infrastructure, allowing IT teams to move away from managing servers, operating systems, databases, and routine maintenance. However, the move also introduces a shared responsibility model for security.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
The challenge is that cloud adoption changes who performs security activities, not who is accountable for them. Responsibility is distributed across SAP and its infrastructure providers, implementation and managed-service partners, and the customer’s own IT, security, risk, and business teams. Without clearly defined ownership, critical security controls can easily fall into the gaps between these parties, creating the false assumption that someone else is responsible.
These ownership gaps are not theoretical. They can leave organizations exposed to audit findings, delayed incident response, governance failures, and unnecessary cyber risk. SAP’s Roles and Responsibilities document explains how responsibilities are divided between SAP and the customer, including which services are provided as standard and which require additional or optional agreements, but several areas continue to be widely misunderstood. The following are five of the most significant security and governance responsibilities that organizations should validate before assuming they have been transferred to SAP for the Private Cloud offering.
1. Resilience
One of the most common misconceptions in SAP RISE is equating backups with business resilience. While SAP performs backups as part of its managed service, backups alone do not ensure that business operations can recover from a ransomware attack, regional outage, or other disruptive event.
Related reading:
The SAP Shared Responsibility Model identifies Disaster Recovery (DR) as an optional service that must be explicitly included in the SAP RISE contract. Organizations should verify that DR has been contracted, confirm that Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) meet business requirements, and regularly participate in disaster recovery testing. Even when SAP provides the underlying recovery infrastructure, customers remain responsible for validating business processes, interfaces, integrations, and application functionality before production operations resume.
2. Network segmentation
Moving SAP to the cloud does not eliminate the need for network segmentation. SAP recommends adopting Zero Trust principles in which SAP workloads are isolated into separate network security zones to reduce the blast radius of attacks and limit lateral movement. While SAP secures the underlying cloud infrastructure, customers remain responsible for designing their enterprise network architecture, connectivity model, and network security requirements.
Organizations that require network segmentation should work with SAP to provision separate subnets for production, non-production, SAP Cloud Connector, and other security-sensitive components as appropriate for their environment. Traffic between these network zones should be restricted using controls supported and managed by SAP, such as SAP Firewall as a Service (FWaaS). Because FWaaS is an optional managed service rather than a standard RISE capability, customers should verify that the required subnets, firewall policies, and traffic inspection controls are included in their RISE deployment, periodically reviewed, and integrated with their overall security monitoring architecture.
3. Monitoring
Monitoring is another area where expectations often differ from reality. SAP monitors the health, availability, and operational status of the managed infrastructure and reviews infrastructure logs to support platform operations and incident response. However, monitoring the platform is fundamentally different from monitoring for security threats within SAP applications.
Organizations remain responsible for reviewing SAP application and audit logs, detecting privileged access abuse, identifying unauthorized configuration changes, monitoring anomalous user behavior, and integrating relevant security events into their Security Information and Event Management (SIEM) platform or Security Operations Center (SOC). Customers requiring access to SAP managed infrastructure logs within their own SIEM must subscribe to the optional LogServ service, while those seeking SAP-managed application monitoring can purchase Packaged services. Organizations should understand which monitoring capabilities are included in their contract and which require additional services.
4. Compliance
Migrating SAP to the cloud does not transfer regulatory accountability. Although SAP operates a secure and compliant cloud platform, organizations remain responsible for demonstrating that their internal controls satisfy regulatory and audit requirements such as SOX, GDPR, HIPAA, and FDA 21 CFR Part 11.
Auditors assess the organization's control environment not SAP's. Activities including privileged access reviews, Segregation of Duties (SoD) management, emergency access governance, business approval workflows, and the collection of audit evidence remain the customer's responsibility regardless of where SAP is hosted.
5. Governance
Governance remains one of the most critical responsibilities retained by the customer. While SAP manages much of the underlying infrastructure and technical operations, organizations still own identity and access governance, including role design, user provisioning, privileged access management, periodic access reviews, and Segregation of Duties controls. They also remain accountable for defining security policies, assigning control ownership, managing cyber risk, and demonstrating compliance.
Cloud adoption changes the operating model, but it does not reduce governance responsibilities. Organizations should regularly review the SAP Shared Responsibility Model to distinguish between services included by default and those requiring additional contractual agreements. They should also maintain a documented responsibility matrix that clearly assigns ownership for every critical security control across SAP, hyperscale cloud providers, managed service providers, implementation partners, and internal teams.
Organizations that successfully adopt SAP RISE are not simply those that migrate their ERP systems to the cloud. They are the ones that clearly understand where SAP's responsibilities end, where their own begin, and who is accountable for every security control before a security incident or audit reveals otherwise.
