A modern SAP Cloud ERP landscape is no longer defined by a single product boundary. It is typically composed of multiple cloud services, including SAP S/4HANA, SAP BTP, and other SAP SaaS applications. Each service has its own security model, administration approach, identity and authorization concepts, and operational responsibilities. As a result, security controls in one layer do not automatically extend to another. For example, SAP S/4HANA authorizations do not govern SuccessFactors roles, and application access controls do not automatically determine how data is processed once it is shared with an AI service.

To stay secure, customers need a two-way strategy. First, use a vertical view to protect each layer from the application down to the infrastructure. Second, use a horizontal view for controls that cut across every service — consistent rules for identity, logging, and privacy. By looking both ways, the gaps between services are bridged and the entire cloud estate remains protected.

The six layers below describe the typical scope of a modern SAP Cloud ERP estate and the main security question that each layer must answer.

The intelligence layer includes SAP Business AI capabilities such as Joule, embedded AI in SAP applications, SAP AI Foundation (including the generative AI hub and Joule Studio), and customer-created AI use cases on SAP BTP.

This layer is important because it introduces a new class of data flow: prompts, responses, retrieval context, model routing, and AI-assisted actions. AI interaction should therefore be treated as a governed data flow, not merely as a user-interface feature.

From a security perspective, the most important question is not only where the model is hosted. The deeper question is whether the AI use case respects the same business authorization, identity, data minimization, auditability, privacy, and contractual controls that apply to the underlying application data.

Main risks to design against

• Prompt injection — malicious or untrusted content attempts to influence the AI response or tool invocation.
• Over-broad grounding — retrieval pulls more business data into the model context than the user is authorized to see, or than the task requires.
• Shadow AI — a customer-built extension calls an external LLM directly, bypassing SAP BTP governance, approved destinations, or enterprise review.
• Output misuse — generated content is treated as authoritative without human validation, auditability, or business-rule checks.

Controls and design principles

• Keep authorization decisions at the business-application layer. AI should not become a shortcut around existing role-based access, field-level restrictions, or business approvals.
• Use approved SAP BTP services and destinations for customer-built AI workloads, instead of direct unmanaged API calls from custom code. Adhere to SAP API Policy
• Classify the data used for prompts and retrieval. Apply minimization — send only what is necessary for the task.
• Customers should validate the approved foundation model, provider, region or processing location, retention, logging, training, sub processor, and contractual commitments before approving an AI use case. For SAP Generative AI Hub, SAP Note 3437766 – Availability of Generative AI Models is a key reference for available models, and should be read together with SAP service documentation, SAP Trust Center materials, the SAP Data Processing Agreement, sub processors list, and the applicable customer contract.
• Log administrative actions, configuration changes, and relevant application events using the available SAP and customer logging mechanisms.

The SaaS application layer may include SAP SuccessFactors, SAP Ariba, SAP Concur, SAP Fieldglass, SAP Customer Experience, SAP industry cloud services, and other subscribed SAP cloud applications.

These are SAP-operated cloud services, but each service has its own tenant architecture, configuration model, data residency position, integration pattern, audit capability, data-protection documentation, and administrative responsibility model.

The most important point for customers is simple: central authentication does not automatically mean central authorization.

Practical control approach

• SAP Cloud Identity Services can provide a common identity front door. However, role design, field-level permissions, business approvals, workflow controls, and configuration governance remain service-specific.
• A customer may use a common corporate identity provider and still have inconsistent business roles, excessive OAuth scopes, inactive privileged users, or weak segregation-of-duties controls inside individual SaaS applications.
• A good control posture starts with controlled authentication. SAP Cloud Identity Services, or the customer’s enterprise identity provider, should be used as the authentication front door. Multi-factor authentication and conditional access should be enforced according to the customer’s enterprise policy.
• User lifecycle controls are equally important. Joiner, mover, and leaver provisioning should be automated where supported. Privileged users should be reviewed and reconciled regularly.
• Application-specific roles and permissions should be reviewed within each SaaS service. This is especially important for sensitive business areas such as payroll, supplier banking, procurement approvals, travel expenses, and customer data.
• Technical access should not be overlooked. OAuth clients, API integrations, technical users, certificates, and administrator delegations should be included in periodic access governance.
• Customers should also confirm each subscribed service’s data residency, sub processors, audit reports, and data-processing terms through SAP Trust Center (trust.sap.com) and the applicable service documentation.

Integration is where data moves between SAP and non-SAP systems. SAP Integration Suite sits between the SaaS layer and the SAP Cloud ERP Private and BTP layers because it often connects systems that have different owners, different security models, and different compliance obligations.

This layer is critical because integrations can silently expand the data exposure of an otherwise well-controlled application. Credentials, certificates, endpoints, mappings, message payloads, and event subscriptions all need governance.

Practical control approach

• Use approved APIs and documented integration patterns rather than unsupported technical access.
• Protect destinations, secrets, certificates, and integration credentials with strong lifecycle management, including rotation and least-privilege scopes.
• Apply OAuth 2.0, mutual TLS, allow-listing, rate limiting, and threat-protection policies in API Management where appropriate.
• Log and monitor integration flows, especially those carrying personal data, financial data, supplier data, or regulated records.
• Review payload minimization so that integrations transmit only what is required for the business process.
• Review SAP Cloud Connector configuration and exposed resources carefully. Connectivity is a control boundary, not a convenience setting.

SAP Cloud ERP Private (formerly RISE with SAP S/4HANA Cloud, private edition) is commonly used to transition the ERP core to a cloud operating model. It is operated by SAP under the Enterprise Cloud Services (ECS) model. This layer contains the highest concentration of business-critical data, including finance, procurement, logistics, manufacturing, master data, and regulated transactional records.

The managed-service model changes who operates the technical layers; it does not eliminate customer responsibility. SAP ECS typically operates the subscribed technical environment according to the relevant service description and roles-and-responsibilities documentation. The customer remains responsible for business roles, user access, approval design, data classification, custom code decisions, transport governance, and compliance interpretation.

Clean Core as a security principle

Clean Core is usually discussed as an upgrade and extensibility principle. It is also a security principle. The more custom code and modification in the core, the larger the attack surface for authorization bypass, insecure RFC calls, hard-coded credentials, transport misuse, and inconsistent patch impact analysis. Side-by-side extension on SAP BTP can reduce this risk when it is implemented with approved APIs, secure destinations, proper identity propagation, and a secure SDLC.

In 2025, SAP introduced the Clean Core extensibility level concept that classifies extensions into four levels (A through D) based on architectural integrity, upgrade safety, and alignment with Clean Core principles. Extension classification is validated against the SAP Cloudification Repository Viewer and enforced through ABAP Test Cockpit (ATC) checks. This provides a more practical way to assess whether extensions are clean, governed, upgrade-safe, or technically risky.

A defensible statement is that SAP cloud services apply encryption controls for data in transit and data at rest according to the service-specific documentation. For SAP S/4HANA and SAP HANA-based landscapes, controls may include TLS and SNC for secure communication, SAP HANA encryption capabilities, secure stores for sensitive technical material (SSFS), LSS, BYOK/HYOK, backup encryption, and managed operational controls.

Change control as a security control

Transport governance, segregation of duties, emergency access, and code review remain high-value controls. Use ABAP Test Cockpit (ATC), Code Vulnerability Analyzer (CVA) where available, secure coding standards, peer review, and production transport approval controls. A transport into production is not only a release event — it is also a potential security event.

SAP BTP is powerful because it is where customers integrate, extend, automate, analyze, and build AI-enabled applications. It is also where misconfiguration can create risk quickly. Subaccounts, destinations, service instances, API policies, keys, certificates, and custom applications all require governance.

SAP provides platform services and security capabilities. The customer and implementation partner are responsible for how custom extensions, integration flows, APIs, secrets, and deployment pipelines are designed and operated. The most common misunderstanding is that because the runtime is SAP-provided, every application built on it is automatically secure. SAP secures the platform; the customer remains accountable for the security of custom applications, code, libraries, data flows, secrets, and business logic that they design and deploy.

Practical control approach

• Segment subaccounts by environment and purpose. Production and non-production should have separate controls — and no unnecessary production data in lower environments.
• Apply secure software development practices, dependency scanning, secret management, and code review for custom applications.
• Avoid long-lived shared credentials. Use service bindings, certificates, secret stores, and rotation processes aligned to enterprise policy.
• Use SAP BTP audit logging and integrate the relevant logs into the customer monitoring or SIEM processes where required.
• Govern SAP Datasphere, SAP Analytics Cloud, and data federation carefully so that analytics access does not exceed the source-system authorization intent. Data classification and access reviews must follow the data — not just the source system.
• Define ownership for each BTP service clearly between the customer, SAP, and the implementation partner.

Transformation services such as readiness checks, migration services, SAP Activate, guided configuration, test automation, learning content, SAP Enterprise Support, SAP LeanIX, and SAP Signavio support the move to and ongoing operation of the cloud landscape. These services are not just project tools. They influence the security posture because they shape design decisions, migration scope, process documentation, and operational readiness.

SAP Cloud ALM can contribute operational visibility for supported services. However, security monitoring, SIEM integration, threat detection, and investigation requirements should be assessed separately based on the relevant SAP service and available log sources.

Practical control approach

• Include security and privacy requirements early in readiness assessments and design workshops.
• Validate data migration scope, data cleansing, retention decisions, and test-data handling — production data should not be reused in lower environments without controls.
• Use process documentation to identify sensitive data flows and control points before go-live.
• Ensure that operational runbooks, escalation contacts, incident notification paths, and evidence sources are agreed before production cutover.

The infrastructure layer includes SAP data centres, hyperscaler environments, network foundations, backup and recovery, monitoring, operations, and compliance evidence. This is the layer where customers usually have the least direct operational control, but it remains important for audit, procurement, risk management, and regulatory assurance.

SAP, the infrastructure provider, and the customer each have defined responsibilities, as documented in the order form, service description, data processing terms, and applicable roles-and-responsibilities materials. For Cloud ERP and other SAP cloud services, the responsibility split depends on the contracted service model, selected region, hosting model, hyperscaler or SAP data center, and any applicable supplemental terms.

Customer governance focus areas

• Confirm the contracted region for each in-scope service and understand data residency, support access, and cross-border access implications.
• Review SAP Trust Center and My Trust Center evidence for the relevant services — including ISO, SOC, regional certifications, bridge letters, and service-specific documents. SAP Trust Center (trust.sap.com) and My Trust Center are the authoritative source for service-specific certifications, audit reports, and sub processor information.
• Confirm backup, restore, disaster recovery, RTO, RPO, maintenance windows, vulnerability management, and incident notification expectations in the contractual service scope.
• For regulated customers, map the service evidence to the applicable regulatory framework rather than relying on certification names alone

Cybersecurity and data privacy address related but distinct questions. Cybersecurity focuses on whether unauthorized access, misuse, or compromise can occur. Data privacy focuses on whether the organization is permitted to collect, process, retain, disclose, transfer, and delete personal data in the first place. In SAP landscapes, both disciplines are essential and must be addressed together.

A strong privacy architecture follows the full data lifecycle: collection, classification, processing, storage, access, sharing, retention, blocking, deletion, and evidence. Encryption is an important confidentiality control, but it does not answer every privacy requirement. Topics such as purpose limitation, data minimization, retention periods, cross-border transfers, consent where applicable, and data subject rights require clear business ownership, documented processes, and alignment with applicable legal and contractual obligations.

Practical control questions per lifecycle stage

Classification and retention are often the weakest stages. Data can move from SAP S/4HANA into an integration flow, then to SAP Datasphere, then to SAP Analytics Cloud, and then to a customer-built application on BTP. Each copy must have a clear purpose, owner, access model, and retention expectation.

Preventive controls are essential because they reduce the likelihood of security events. At the same time, a mature SAP security architecture also plans for effective monitoring, detection, and response. This means recognizing that real-world risks such as compromised credentials, excessive privileges, vulnerable custom code, or misconfigured integrations need to be identified quickly, investigated properly, and addressed through defined operational processes.

The practical objective is not to assume that a single SAP product provides complete visibility across the entire landscape. Instead, the objective is to identify the relevant monitoring and log sources for each service, clarify which party can access them, determine which customer-accessible logs can be forwarded to the customer SIEM where supported, and establish an incident response process aligned with the applicable contract, service documentation, and the customer’s regulatory obligations.

For SAP-managed log aggregation, log delivery, and threat detection scenarios, customers may evaluate services such as SAP Enterprise Threat Detection, SAP LogServ for ECS log delivery, and SAP Data Custodian KMS where applicable. The applicability, scope, available log sources, access model, and contractual coverage of each service should be validated against the specific SAP cloud services in scope and the customer’s agreement.

Per-layer log sources to consider

• For SAP S/4HANA, consider Security Audit Log (SAL), change documents, business logs, SAP HANA audit logs, privileged-access activity, and transport activity.
• For SAP BTP, consider audit logs, application logs, destination changes, service-key changes, API events, and platform-administration events.
• For SaaS services, review service-specific audit-log availability and export options (for example, SAP SuccessFactors Read and Change Audit).
• For incident response, define notification contacts, severity thresholds, evidence handling, regulator-notification obligations, and customer or SAP responsibilities — before an incident occurs.

The strongest SAP cloud security architecture is not built from isolated controls. It is built by connecting controls across layers. Identity, authorization, encryption, logging, monitoring, data protection, incident response, and contractual governance need to work together.

The shared-responsibility model is the practical way to avoid misunderstanding. SAP is responsible for operating and securing the cloud services according to the applicable service descriptions and contracts. The customer is responsible for business decisions, identity governance, configuration choices, data classification, user access, integrations, custom code, and the compliance obligations that sit within their control. System integrators and partners may also have responsibilities during design, build, migration, and support.

The table below summarizes the typical threats at each layer, the controls SAP provides or operates, and the responsibilities that remain with the customer and the implementation partner. The exact allocation for a given customer is defined in the relevant service description and roles-and-responsibilities documentation.

Security and privacy in SAP Cloud ERP Private estate are not delivered by a single product or a single contract clause. They emerge from architectural decisions made layer by layer: which services are subscribed, where data is hosted, how users authenticate, how roles are designed, how extensions are built, how integrations are governed, how logs are collected, and how evidence is maintained.

This modular architecture allows customers to adopt best-in-class SAP cloud services while maintaining a secure and governed enterprise landscape. Each service is designed with security and privacy principles embedded into its application architecture, operated under secure-by-default and secure-by-design practices, and supported by service-specific controls, documentation, and applicable supplemental contractual terms. As a result, security and privacy are not treated as afterthoughts, but as foundational design principles maintained across each service layer.

Disclaimer

© 2026 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.