Understanding the Shared Responsibility Model: What SAP Owns vs. What You Must Govern

Security concerns are the most common reason organizations delay SAP cloud migration. The concern is real but frequently based on a misunderstanding of how security actually works in SAP’s model. SAP S/4HANA Public Cloud deals with your core business data, and SAP is committed to the highest security and quality standards across every layer of the technical landscape.

The Shared Responsibility Model

SAP S/4HANA Public Cloud security operates on a Shared Responsibility Model. SAP owns security of the cloud: infrastructure, platform, and application layers. You own security in the cloud: identity management, access control, data governance, and integration security. Understanding this delineation is the prerequisite for every security planning conversation.

SAP’s Security Responsibilities

SAP maintains a multi-layer security posture across all Public Cloud environments. Physical infrastructure security is governed by the hyperscaler provider. SAP adds network-level security (DDoS mitigation, network segmentation, firewall rules), application security (vulnerability scanning, penetration testing, security patching), and data security (AES-256 encryption at rest, TLS 1.2+ in transit). SAP’s Security Operations Center monitors environments 24/7.

Customer’s Security Responsibilities

While SAP secures the platform, the customer owns the identity and access layer. This is where most post-go-live security gaps are found.

SAP Identity Authentication Service (IAS) is the cloud identity provider for all SAP cloud products. It supports SAML 2.0 and OIDC federation with your corporate IdP (Microsoft Entra ID, Okta), enforces multi-factor authentication, and applies risk-based authentication policies. Configuration of IAS including MFA enforcement, conditional access rules, and corporate SSO federation — is the customer’s responsibility from day one.

SAP Identity Provisioning Service (IPS) automates user lifecycle management across all connected SAP cloud services. When an employee is onboarded or offboarded in HR, IPS provisions and deprovisions SAP access automatically. Without IPS, manual user management creates orphaned accounts, the most common finding in SAP security audits.

Beyond identity, customers are responsible for business role design aligned to SAP Best Practices with proper Segregation of Duties (SoD), integration security design using OAuth 2.0 and API Management, audit log monitoring via SAP Audit Log Service connected to the enterprise SIEM, and data classification policies governing how sensitive business data is handled within and outside the system. Custom role variants can be created via business role templates without modifying standard roles.

Security in SAP S/4HANA Public Cloud is not a binary; it is a shared discipline. SAP delivers and maintains one of the most rigorously certified cloud ERP environments available. Your organization’s security posture depends on how well you configure and govern your half: identity, access, integrations, and audit monitoring. Organizations that invest in correct IAS/IPS setup, integration security design, and ongoing audit log governance consistently maintain cleaner security postures and pass audits with fewer findings than those that treat security as a go-live deliverable rather than an operational discipline.