Auditing SAP S/4HANA Cloud, Public Edition: A Practitioner’s Guide

The audit paradigm has shifted, not weakened

The transition from SAP on-premise to SAP S/4HANA Cloud, Public Edition, represents one of the most significant evolutions in the enterprise audit landscape of the past decade. 

For experienced audit and security professionals, this is not a matter of relearning and is a matter of recalibrating it. The underlying control objectives, namely the integrity of financial data, least-privilege access, segregation of duties, accountability, and traceability, remain unchanged. 

What has changed is the set of mechanisms through which those objectives are achieved and the evidence base through which they are demonstrated.

Auditing SAP Public Cloud is therefore not a lighter version of auditing SAP on-premise or RISE with SAP, Private Edition. It is a distinct discipline, governed by a different responsibility model, evidenced through a different control set, and tested through a different toolkit. An audit programme that delivered assurance over an ECC or on-premise S/4HANA system will, if applied without adaptation, leave material risks unexamined while duplicating work that SAP’s own independent auditors have already performed under globally recognised attestation standards.

This article sets out a structured approach to auditing SAP S/4HANA Cloud, Public Edition, clarifying what the customer should test directly, where reliance on SAP’s attestation reports is appropriate, and where the residual risk genuinely sits.

Begin with the Shared Responsibility Model

Every Public Cloud audit must begin with a written acknowledgement of the shared responsibility model. In S/4HANA Cloud Public Edition, SAP operates the underlying infrastructure, the database, the application servers, the kernel, the patching cycle, the network, the encryption at rest and in transit, and the underlying authorization framework. The customer is responsible, almost exclusively, for who gets access to which business function and which data, for the configuration choices exposed through Central Business Configuration (CBC), and for the integrity of integrations entering and leaving the tenant.

 In practical terms, the auditor should formally exclude from scope any control objective that is wholly SAP’s responsibility, provided that SAP’s attestation reports cover it. Conversely, every control that touches business roles, restrictions, business users, communication arrangements, key user extensibility, output management, or master data governance is squarely a customer control and must be tested directly.

A defensible way to document this is a Responsibility Allocation Matrix, signed off jointly by the customer’s CIO or CISO function and the audit team, with each line item mapped either to “SAP-attested” (referencing the relevant report) or to “customer-tested.”

Place appropriate reliance on SAP’s independent attestations

SAP publishes a substantial body of independent attestation reports through the SAP Trust Center [1]. As a baseline, the auditor should obtain, read, and reference the following reports under the customer’s existing non-disclosure agreement with SAP:

• SOC 1 Type 2, which is directly relevant for financial statement audits and covers IT general controls over the cloud services in scope.
• SOC 2 Type 2, covering the AICPA Trust Services Criteria of Security, Availability, Confidentiality, and where applicable Processing Integrity and Privacy. From the 2025 H1 reporting cycle onwards, SAP has consolidated several of these reports under the “SAP Central Cloud Services” report family [2].
• ISAE 3000 Reasonable Assurance Report on the SAP S/4HANA Cloud Public Edition Authorization Role Concept [3]. This is the single most important report for a Public Cloud audit and the one most frequently overlooked. It provides independent assurance that the SAP-delivered business catalogs, which are the smallest authorization building block in Public Cloud, are free of inherent segregation-of-duties conflicts, that SAP’s role change process is controlled, and that the catalogs deployed to customer tenants correspond to those tested.
• ISO/IEC 27001, 27017, and 27018 certifications, which together cover information security management, cloud-specific controls, and the protection of personally identifiable information in the cloud [4].
• BSI C5 (2020) Type 2 attestation, which is particularly relevant for customers in Germany and the wider European Union [5].
• TISAX, PCI-DSS, HIPAA, and FedRAMP attestations where applicable to the customer’s industry and geography.

Two practical considerations deserve emphasis:

First, the Complementary User Entity Controls (CUECs) sections of each report must be read carefully. CUECs are the controls SAP’s auditors have assumed the customer has implemented in order for SAP’s controls to operate effectively. Each CUEC is implicitly an audit test that the customer must pass. 

Second, the auditor should compare the report period with the customer’s financial year. Gaps between SAP’s reporting periods and the customer’s audit period are routinely raised by external auditors and should be bridged through a bridge-letter request to SAP, which is a standard service.

Re-baseline your understanding of the authorization model

This is the area where audit teams most often misdirect their effort. In SAP S/4HANA Cloud, Public Edition, there is no PFCG, no classic SU01, no SAP_ALL profile, no debug-and-replace authorization, no direct table maintenance, and no customer-created authorization objects [6]. The authorization model is constructed as follows:

• Business Users are created through the Maintain Business Users application, with authentication delegated to SAP Cloud Identity Services (IAS).
• Business Roles are containers of Business Catalogs, optionally combined with Restrictions at three levels (read, value help, and write or unrestricted access).
• Business Catalogs are SAP-delivered and immutable from the customer’s perspective. They are the lowest-level authorization construct that the customer can assign.
• SAP delivers Business Role Templates that, in accordance with SAP’s own guidance [7], must be used only in the Starter and Quality systems for fit-to-standard activities. In Production, the customer is expected to build custom business roles derived from these templates.

For the auditor, this fundamentally changes the testing approach. The exercise is no longer one of evaluating thousands of authorization object and field combinations per user. Instead, the auditor should test the following:

1. Whether custom business roles in Production were derived using a documented design methodology grounded in workplace analysis and the principle of least privilege.
2. Whether SAP-delivered template roles, particularly those prefixed SAP_BR_*, have been removed from Production business users.
3. Whether restrictions have been actively maintained. An unrestricted business role in Public Cloud is functionally equivalent to granting company-code-wide and master-data-wide access.
4. Whether user-to-business-role assignments reflect approved job functions and the principle of least privilege.
5. Whether Segregation of Duties has been analysed at the customer’s actual combination of catalogs across roles. SAP’s ISAE 3000 report assures that catalogs are SoD-free internally. It does not assure the customer’s role design.

The audit toolkit inside the tenant

The auditor must become familiar with the Public Cloud equivalents of the classic transaction codes. The following inventory aligns the most common audit objectives with the Fiori applications available to the customer:

Two points are worth emphasising. First, the Security Audit Log is enabled by default and cannot be disabled by the customer [6], which is a substantive improvement over the on-premise model where the configuration of SAL is itself an audit issue. Second, table-level logging for sensitive tables is also enabled by default and is administered by SAP, not the customer.

What the customer can and must configure, and what the auditor must therefore test, is Read Access Logging (RAL) [9]. RAL is the principal mechanism through which the customer can demonstrate compliance with Article 30 of the EU General Data Protection Regulation and equivalent regulations elsewhere, by recording read access to personal data displayed in Fiori applications. RAL is not configured out of the box for every data element, and the customer must define the relevant purposes and channels. The absence of an active RAL configuration covering financially or personally sensitive fields is a defensible and frequently observed audit finding.

Audit trails, change documents, and CDS view change logging

Audit trail coverage in S/4HANA Cloud, Public Edition, is one of the areas auditors most consistently misunderstand, and one where the gap between the platform’s documentation and the auditor’s reality is widest. The mechanisms exist, but they are layered, named inconsistently, and not uniformly available across business areas. A defensible Public Cloud audit must treat the audit trail not as a single capability but as a stack of four distinct layers, each serving a different evidence purpose.

The four layers, from the platform inward, are the following:

• Layer 1: System Audit Log (platform). At the BTP and tenant infrastructure level, SAP operates the Audit Log Service (ALS) [11], which records platform-level system events including authentication attempts, support user access, configuration changes at the tenant level, and integration events. ALS is operated by SAP and exposed to the customer through defined Fiori applications and downloadable extracts. ALS is the layer the customer relies on for forensic reconstruction of platform-level activity.
• Layer 2: Security Audit Log (application). Inside the S/4HANA Cloud application, the Security Audit Log (SAL) continues to do the work it has always done in on-premise SAP, recording security-relevant application events: logon attempts, authorisation failures, user master changes, RFC and OData calls. As noted in the previous section, SAL is enabled by default in Public Cloud and cannot be disabled. The auditor reviews SAL through the Display Security Audit Log Fiori app, with reference to SAP Note 2903873 [8] for the supported event categories.
• Layer 3: Change documents (business object). At the business object level, SAP continues to use the change document mechanism inherited from ECC and on-premise S/4HANA. Change documents capture, for a given business object instance, every modification with prior value, new value, user, timestamp, and (where configured) a reason code. In Public Cloud, change documents are surfaced through object-specific Display Change Logs Fiori applications and, where released, through corresponding OData services. Examples include Display Change Logs - Sales Documents (Fiori App F7356, backed by OData service C_SLSDOCCHANGEDOCUMENTITEM_SD), the equivalent applications for Purchase Orders, Projects, Production Orders, and Material Master, and the cross-cutting Display Changes to User Master Records app used for access reviews.
• Layer 4: Released CDS views for change document data. This is the layer that matters most for modern auditors, and the layer most poorly understood. For change document data to be consumable in custom reports, analytics, KPIs, or external SIEM integration, the underlying change document tables must be exposed through released CDS views. SAP releases CDS views progressively, by business area, on a defined cadence. The released set is uneven. Purchase Orders, for example, expose change document data through I_PURCHASEORDERCHANGEDOCUMENT and related views, which the customer can consume in custom analytics. Sales Documents, by contrast, have no released CDS view exposing change log data at the time of writing, even though the Display Change Logs Fiori app exists and works [12].

Why the CDS view coverage gap matters for the audit

A practical example explains the audit implication. Suppose a financial auditor wants to test, across the audit period, every change made to the net price field on sales orders above a materiality threshold, along with the user who made the change. In on-premise SAP, the auditor would query CDHDR and CDPOS directly. In S/4HANA Cloud, Public Edition, that direct access does not exist. The auditor must therefore either (a) review changes one sales order at a time through the Fiori app, which is unworkable for sampling, (b) ask the customer to extract the data through an unreleased internal CDS view, which the customer cannot do without breaking the support boundary, or (c) accept that the analytic test cannot be performed for that field in that business area.

This is not a hypothetical limitation. The SAP Community contains active discussions of exactly this gap, with auditors and customers raising the issue with SAP through the Customer Influence portal and SAP responding that an enhancement request is the appropriate channel [12, 13]. For the auditor, the implications are concrete:

• Before fieldwork, confirm with the customer which business areas in scope have released CDS views for change document data and which do not. The View Browser Fiori app is the authoritative source.
• For business areas without released CDS views, accept that the audit test will be performed at the individual document level through the Fiori app, with sampling rather than population testing.
• Where the customer requires population-level testing for compliance or financial audit reasons, document the limitation and consider raising it through the SAP Customer Influence portal as a control gap to be closed in a future release.
• Avoid the temptation to ask the customer to build a custom CDS view on top of unreleased internal change document views. Unreleased views can change without notice between releases, breaking the audit trail and the custom report at the same time.

Areas where change document coverage is genuinely absent

Beyond the CDS view exposure question, there are business areas in S/4HANA Cloud, Public Edition, where change document logging is not implemented at all. The most cited example at the time of writing is Estimate to Complete (ETC) and plan value changes in the customer project lifecycle, where adjustments to forecast values can materially affect revenue recognition and percentage-of-completion calculations, but the system does not maintain a change history accessible to either the application or any released CDS view [13]. For an audit of project-based revenue, this is a structural gap in the audit trail and must be addressed through process controls and detective controls at the operational level rather than through reliance on the system audit trail.

The auditor’s practical response is to map the audit trail capability per business area early in scoping. Treat audit trail availability as a control attribute in the Responsibility Allocation Matrix and document, for each in-scope business area, whether (a) change documents are captured, (b) they are visible through a Fiori app, (c) they are exposed through a released CDS view, and (d) they cover all financially significant fields. The four-way classification surfaces the gaps that matter before they become audit findings.

The integrated audit trail picture

Taken together, the four layers give the auditor an audit trail that is, in most respects, richer than what was available in classic on-premise SAP, but only when used in combination. ALS provides the platform reconstruction. SAL provides the application security reconstruction. Change documents provide the business object reconstruction. Released CDS views provide the data layer on which population-level testing and continuous control monitoring can be built. The gap is in the unevenness of layer 4, which is improving release by release but is not yet complete. The auditor who understands the stack, tests each layer for its intended purpose, and documents the gaps where they exist, delivers a defensible audit. The auditor who treats the audit trail as a single capability and assumes uniform coverage does not.

Non-human identities: the new high-risk frontier

In the Public Cloud model, the conversation about privileged access has shifted from “who holds SAP_ALL” to “what does each Communication Arrangement do, who approved it, and which Communication User authenticates it” [10]. Every integration, whether to a third-party tax engine, a payment provider, a middleware tenant, or a partner system, operates through a Communication Arrangement bound to a Communication User and a Communication Scenario.

Communication Users are technical identities with potentially very broad API access, often covering entire modules of OData services. In practice they are frequently:

• Created during implementation and never reviewed afterwards.
• Authenticated with long-lived basic-authentication credentials rather than X.509 client certificates or OAuth 2.0.
• Excluded from the customer’s identity governance framework because they are considered technical rather than human users.

A modern Public Cloud audit must therefore include a complete inventory of Communication Arrangements, classified by inbound or outbound direction, with the scopes granted, the authentication method used, evidence of credential rotation, and a sample-based walkthrough of the business rationale for each. This is also one of the most common gaps observed against the CUECs in SAP’s SOC 2 and C5 reports, which assume that the customer governs these objects.

Change management in a continuously delivered cloud

SAP S/4HANA Cloud, Public Edition, is upgraded on a defined release cadence (for example, releases 2502 and 2508). The customer does not control the timing of these upgrades. Each release potentially introduces new business catalogs, deprecates existing ones, adds Fiori applications, and changes application behaviour. From an audit perspective, the following testing approach is appropriate:

• Test the customer’s release impact assessment process. There should be a documented review of the SAP “What’s New” content, together with evidence that newly delivered catalogs were evaluated for SoD impact before being assigned to Production business roles.
• Test the regression testing approach in the Quality system, also referred to as the Test tenant. Public Cloud customers typically operate a two-tenant or three-tenant landscape (Starter, Quality, and Production), and evidence of test execution in Quality prior to each upgrade is a reasonable audit request.
• Test the governance of custom logic and extensibility. Every key-user extension, whether a custom field, custom CDS view, custom business object, or custom logic exit, should have a transport record from the Development or Test tenant, documented business approval, and a designated owner.

The classic IT general control objective that “changes to production are tested and approved” therefore reframes as “extensions and configuration are tested and approved,” because SAP itself is the change agent for the application code.

Logical access and identity federation

Authentication is delegated in the Public Cloud model. The S/4HANA Cloud tenant does not hold passwords directly. Identity is supplied by SAP Cloud Identity Services (IAS), which is either federated to the customer’s enterprise Identity Provider, such as Microsoft Entra ID, Okta, or Ping, or operated as a standalone tenant. The audit approach should follow these dependencies:

• Where IAS is federated to the customer’s enterprise IdP, the password policy, multi-factor authentication, and conditional access controls are inherited from that IdP, and the audit pivots accordingly.
• Where IAS is operated standalone, the IAS password policy, risk-based authentication, and MFA enforcement become the customer-side authentication controls and must be tested directly in the IAS administration console.
• The user lifecycle for joiners, movers, and leavers should be integrated through SAP Cloud Identity Provisioning Service (IPS) or via SCIM from the enterprise IdP. A manual user lifecycle, in which deprovisioning depends on human action, is a recurring source of findings.

The auditor should select a sample of joiners, movers, and leavers and walk each case end-to-end from the IdP, through IAS, to the S/4HANA Cloud business user record, with corresponding dates, approvals, and effective access.

Data protection, privacy, and key management

Data at rest and in transit is encrypted by SAP as a baseline control. For customers requiring additional control, typically in regulated industries, SAP offers Customer-Controlled Encryption Keys (CCEK) for certain scenarios [14]. The auditor should determine which option applies and obtain the corresponding evidence, including the key inventory, the rotation policy, and any bring-your-own-key governance arrangements.

For privacy, the relevant control artefacts are the End of Purpose (EoP) check configuration and execution evidence for personal data, the Information Retrieval Tool (IRT) and Information Lifecycle Management (ILM) rules, the RAL configuration discussed above, and the usage history of the Customer Data Browser, which is itself a privileged function and should be sampled.

A defensible audit programme for SAP Public Cloud

A pragmatic and defensible audit programme for SAP S/4HANA Cloud, Public Edition, rests on six pillars:

1. Governance and shared responsibility, evidenced through a Responsibility Allocation Matrix, appropriate reliance on SAP attestation reports, and treatment of CUECs.
2. Identity and access, covering IdP federation, IAS, business user lifecycle, business role design, restrictions, and periodic recertification.
3. Authorization design and SoD, evidenced through the custom role build process, the removal of templates from Production, and a customer-side SoD ruleset applied to the actual role-to-catalog mapping.
4. Non-human identities, covering Communication Arrangements, Communication Users, OAuth and certificate hygiene, and scope minimisation.
5. Configuration, extensibility, and change, including CBC governance, key-user extensibility approval, release impact assessment, and regression test evidence.
6. Logging, monitoring, and audit trail, including review of the Audit Log Service and Security Audit Log, RAL configuration and review, change document coverage by business area, released CDS views for population-level testing, EoP and ILM execution, and Customer Data Browser usage.

Each pillar should be evidenced through a combination of tenant-side testing (Fiori application screenshots, exports, and walkthroughs) and appropriate reliance on SAP’s third-party attestation reports for the underlying platform controls.

Closing thought

The greatest value an auditor brings to a Public Cloud engagement is not in re-performing the work already covered by SAP’s own attestations. SAP’s SOC 1, SOC 2, ISAE 3000, and C5 reports are issued by reputable independent firms, refreshed on a predictable cadence, and accepted by regulators and external auditors worldwide. Appropriate reliance on these reports is a hallmark of a mature audit approach and allows the engagement to focus where it matters most.

That focus lies in the layer that only the customer can govern: the design of business roles and restrictions, the segregation-of-duties analysis applied to the customer’s specific catalog combinations, the governance of communication arrangements and non-human identities, the discipline around key-user extensibility, the integrity of the user lifecycle through the IdP and IAS, and the alignment with the Complementary User Entity Controls that SAP’s auditors have assumed are in place.

Approached this way, an SAP S/4HANA Cloud Public Edition audit is leaner, more focused, and more defensible than its on-premise predecessor, and it gives the organisation the assurance it needs over the controls that genuinely remain in its hands.

References

[1] SAP SE, SAP Trust Center: Certifications and Compliance. Available at: https://www.sap.com/about/trust-center/certification-compliance.html

[2] SAP SE, SAP Central Cloud Services SOC 2 Audit Report 2025 H1. Available at: https://www.sap.com/about/trust-center/certification-compliance/sap-central-cloud-services-soc-2-audit-report-2025-h1.html

[3] SAP Community, ISAE 3000 for SAP S/4HANA Cloud Public Edition: Evaluation of the Authorization Role Concept. Available at: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/isae-3000-for-sap-s-4hana-cloud-public-edition-evaluation-of-the/ba-p/13672124

[4] International Organization for Standardization, ISO/IEC 27001, 27017, and 27018. Available at: https://www.iso.org

[5] Bundesamt fur Sicherheit in der Informationstechnik (BSI), Cloud Computing Compliance Criteria Catalogue (C5:2020). Available at: https://www.bsi.bund.de

[6] SAP Community, SAP S/4HANA Cloud, Public Edition: Secure by Default. Available at: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-cloud-public-edition-secure-by-default-part-2/ba-p/13551008

[7] SAP SE, Maintaining Business Roles in SAP S/4HANA, Public Cloud, SAP Learning. Available at: https://learning.sap.com/courses/exploring-the-fundamentals-of-sap-system-security/maintaining-business-roles-in-sap-s-4hana-public-cloud

[8] SAP SE, SAP Note 2903873: FAQ Fiori App “Display Security Audit Log”. 

[9] SAP SE, Read Access Logging in SAP S/4HANA Cloud, SAP Help Portal.

[10] SAP SE, SAP S/4HANA Cloud Public Edition 2502 Feature Scope Description, document version 5.0, 18 June 2025. Available at: https://help.sap.com/doc/7c9e0bbbd1664c2581b2038a1c7ae4b3/2502.500/en-US/FSD_CE2502.pdf

[11] SAP SE, Audit Log Service in SAP BTP and SAP S/4HANA Cloud, SAP Help Portal. Available at: https://help.sap.com/docs/btp/sap-business-technology-platform/audit-log-service

[12] SAP Community, CDS View Availability for App “Display Change Logs - Sales Documents”, October 2025. Available at: https://community.sap.com/t5/enterprise-resource-planning-q-a/cds-view-availability-for-app-display-change-logs-sales-documents/qaq-p/14102464

[13] SAP Community, How to Track ETC and Plan Changes for Audit Trail in SAP S/4HANA Cloud Public Edition Project System, January 2026. Available at: https://community.sap.com/t5/enterprise-resource-planning-q-a/how-to-track-etc-and-plan-changes-for-audit-trail-in-sap-s-4hana-cloud/qaq-p/14314372

[14] SAP SE, Data Protection and Privacy in SAP S/4HANA Cloud, Public Edition, SAP Help Portal. 

[15] American Institute of Certified Public Accountants (AICPA), Trust Services Criteria. Available at: https://www.aicpa.org

[16] International Auditing and Assurance Standards Board (IAASB), ISAE 3000 Revised. Available at: https://www.iaasb.org

Simplify Your SAP S/4HANA Cloud Audit

Download the SAP S/4HANA Cloud, Public Edition Responsibility Allocation Matrix (RAM). This practical reference is designed for SAP security professionals, IT auditors, compliance teams, and cloud administrators. It helps you clearly identify SAP-managed controls, customer-managed controls, and shared responsibilities, enabling more effective audit planning and risk assessment.

What's included?

• Responsibility Allocation Matrix (RAM)
• Mapping of SAP-managed and customer-managed controls
• Shared responsibility model
• Key audit focus areas
• Practical guidance for SAP Public Cloud security and compliance reviews