SAP Security Audit Checklist:
Complete Guide for Compliance, Risk And
Access Reviews (2026–27)

Segregation of Duties (SoD) is a control principle that ensures no single user can complete a high-risk business process end-to-end without a second person's involvement. In SAP, the most common SoD conflict is a user who can both create and approve a purchase order - because that combination allows them to purchase anything without independent oversight. SOX Section 404 requires management to assess and report on the effectiveness of Internal Controls over Financial Reporting (ICFR). Since SAP is the financial system for most public companies, any unmitigated SoD conflict in SAP is a direct gap in ICFR. An unmitigated SoD conflict that is discovered by external auditors is typically classified as a Significant Deficiency or Material Weakness - either of which must be disclosed to investors in the annual report, potentially affecting the company's stock price and triggering SEC attention.

Manual SoD analysis involves extracting authorization data from SAP (using SUIM or SE16N on AGR_1251 and USR_AGR tables), loading it into Excel, and cross-referencing it against a SoD conflict matrix - a process that is time-consuming, error-prone, and only provides a point-in-time snapshot. SAP GRC Access Control automates this process: it maintains a living SoD ruleset (functions and risks), connects to all managed SAP systems in real time, and can flag a violation the moment a role assignment is requested - before it goes live. GRC also manages the full lifecycle: it documents mitigating controls, tracks compensating control reviews, manages access requests with approval workflows, handles emergency access via Firefighter IDs, and runs periodic user access review campaigns. For a SOX-regulated company, GRC is the standard because it produces defensible, auditor-ready evidence automatically rather than requiring manual reconstruction.

A Firefighter ID (also called an Emergency Access ID) is a superuser account in SAP GRC's Emergency Access Management module that gives a named user temporary elevated privileges to perform emergency tasks - like fixing a month-end close issue that requires access outside their normal role. For it to be SOX-compliant, five controls must be in place: First, the ID must be checked out for a specific reason with a business justification recorded in GRC before use. Second, GRC must log every transaction and program executed during the session in the Firefighter log. Third, a designated controller (typically a manager or the security team) must review the log within 24 hours of the session and approve or escalate any unusual activity. Fourth, the approval chain - who requested access, who approved it, what was done, and who reviewed it - must be documented and retained. Fifth, Firefighter IDs must not be shared and must have their own separate audit trail independent of the user's normal ID. Without all five controls operating with evidence, the emergency access process is not a control - it is an SoD bypass.

GDPR Article 32 requires organisations to implement appropriate technical measures to protect personal data - and SAP stores a vast amount of it: HR personal records (PA02, PA0002, PA0008), customer contact data (KNA1, ADRC), vendor contacts (LFA1), and sales data linked to individuals. The specific SAP features that address GDPR are: (1) SAP Information Lifecycle Management (ILM) for data retention rules and blocking/deletion of personal data at end of retention period; (2) SAP RTPB (Read Access Logging / Transparent Access Logging) which logs every display of personal data fields for accountability under GDPR's right of access; (3) Data Privacy Governance in SAP S/4HANA which provides a purpose-based data access model; (4) SAP Identity Management for controlling who can access personal data and for how long; (5) Field-level encryption in HCM for highly sensitive data like national ID numbers and bank accounts. For an audit, you must verify that personal data is only accessible to users with a legitimate business need, that access is logged, that data is deleted at end of retention, and that a Data Processing Impact Assessment (DPIA) exists for high-risk SAP processes.

The most critical parameters, verified in RZ11, are: login/min_password_lng (minimum 12 characters - weak passwords are a root cause of account takeover); login/fails_to_user_lock (5 or fewer - unlimited attempts enable brute force); login/no_automatic_user_sapstar = 1 (prevents the hardcoded SAP* fallback login which bypasses all authorizations); rsau/enable = 1 (Security Audit Log must be on - if it is off, you have no forensic trail); auth/rfc_authority_check = 1 (without this, RFC callers bypass all authorization checks - a massive security hole); gw/reg_no_conn_info and the gateway security files (prevent unauthorized external programs from registering with the gateway); rdisp/gui_auto_logout = 900 (15 minutes - unattended sessions allow physical access attacks). These seven parameters, if misconfigured, represent the most commonly exploited technical vulnerabilities in SAP security incident forensics.

A SOX-compliant User Access Review (UAR) involves five stages with documented evidence at each step. Stage 1 - Scope: Extract all active users and their role assignments for each in-scope SAP system. In GRC, this is the UAR campaign scope. Stage 2 - Manager Review: Send each line manager a report of their direct reports' SAP access, asking them to certify each access as appropriate, modify it, or revoke it. The manager's sign-off (electronic in GRC, or email/form) is the primary audit evidence. Stage 3 - Orphan Accounts: Identify accounts with no manager match (ex-employees) and revoke immediately. Stage 4 - Remediation Tracking: Track all requested changes (revocations, modifications) to confirmed completion, with before-and-after screenshots of role assignments as evidence. Stage 5 - Completion Report: Document the campaign completion rate (SOX requires 100% of in-scope users reviewed) and the control owner's sign-off. The auditor needs: the campaign scope, manager certification records, evidence of changes made, and sign-off from the control owner. In GRC, the GRAC_UAR transaction generates this evidence package automatically.

A Single Role in SAP (PFCG) is a collection of authorization objects and field values that grants specific access - for example, a role that allows reading purchase orders in company code 1000. A Composite Role is a container that bundles multiple single roles together and is assigned to users. The security implications are significant. From a design perspective, composite roles make role management scalable: a "Procurement Manager" composite role might include single roles for PO display, goods receipt, and vendor master display. From an SoD perspective, the SoD conflict usually lives within the composite role - because it combines single roles that individually look safe but together create an SoD conflict (e.g., PO create in one single role and PO release in another, both in the same composite). This is why SoD analysis must be done at the composite role and user level, not just at the single role level. For auditing, the key checks are: does each composite role assignment create any SoD violation, and is the assignment governance (who can assign the composite role) properly controlled?

The SAP Security Audit Log is SAP's built-in forensic event logging system, configured via SM19 (or RSAU_CONFIG in newer systems) and reviewed via SM20. It records security-relevant events including: successful and failed logins, authorization failures, user master data changes, report starts, and direct table access. Its compliance criticality comes from two dimensions. First, it is the evidence trail that proves controls were operating - without it, you cannot prove that a segregation of duties control actually worked, because you cannot show what actions were taken. Second, it is required by every major compliance framework: SOX IT General Controls require logging of privileged activity; GDPR Article 30 requires records of processing activities; ISO 27001 Annex A.12.4 requires event logging. For an audit, a disabled or incomplete Security Audit Log is an immediate critical finding because it means the organisation cannot demonstrate what happened in the system during the audit period, which invalidates all other controls that depend on audit trail evidence.

RFC (Remote Function Call) connections are a frequently overlooked but high-risk area. The audit has three dimensions. First, in SM59, identify all RFC connections and check: (1) Are any dialog user IDs storing passwords? Dialog users with stored passwords in SM59 bypass the password policy and cannot be locked if the user leaves. Only Service or System user types should have stored credentials. (2) Are there trusted RFC connections (SMT1) to systems that should not be trusted? Trusted connections bypass the normal login check, meaning any user on the trusted system can call function modules on the trusting system with the trusted system's authority. (3) Are there connections to unknown or decommissioned systems that should be cleaned up? Second, check the authorization object S_RFC - users with wildcard access on all RFC function groups can call any function module remotely, including ones that read or modify data. Third, verify that SNC encryption is configured for all RFC connections that traverse untrusted networks, to prevent credentials or data from being intercepted. The auth/rfc_authority_check = 1 profile parameter must also be confirmed active.

SAP_ALL is a special profile that grants unrestricted access to every single authorization object, field value, and transaction in the SAP system - it is literally all permissions combined into one. Any user with SAP_ALL can read any data, change any configuration, create any user, post any transaction, delete any record, and bypass every control in the system. In a production SAP system it should never exist because: it represents a total SoD violation (one person can do everything), it makes it impossible to enforce least-privilege principles, it bypasses all change management controls (a user with SAP_ALL can change directly in production without transport), it violates every compliance framework that requires access limitation, and in a forensic investigation of fraud, a user with SAP_ALL has no transactions outside their capability - every action is equally plausible. The only legitimate use case is a fully documented, time-limited, GRC Firefighter ID used for emergency break-glass scenarios with full session logging and immediate post-use review. If SAP_ALL is found on any regular user in production, that is a critical audit finding requiring immediate remediation.

A Board-level SAP security audit report should have four sections. Section 1 - Executive Summary: A one-page summary with a red/amber/green dashboard showing the overall risk rating, number of critical and high findings, year-on-year trend, and the top 3 risks requiring immediate board attention. Section 2 - Critical Findings: For each critical finding, state the finding name, the risk it creates in business terms (not technical), which compliance framework it affects (SOX/GDPR/ISO 27001), the recommended action, the accountable owner, and the target remediation date. Section 3 - Compliance Status: A compliance heatmap showing which regulatory obligations are met, partially met, or not met, with the current year's UAR completion rate, SoD remediation rate, and patch compliance rate. Section 4 - Remediation Roadmap: A 6-12 month remediation plan with milestones, resource requirements, and the expected risk reduction from each remediation. What boards want is risk translated into business impact - potential fraud loss, regulatory fine exposure, and reputational risk - not technical details about profile parameters.

A compensating control is an alternative control that mitigates the risk of an SoD conflict when the SoD violation cannot be remediated (because role re-design would impair business operations). For it to be accepted by auditors, it must be: Detective in nature (it catches the problem if it occurs, even if it does not prevent it); Independent (performed by someone with no involvement in the conflicting activities); Evidence-based (produces a documented record that can be reviewed); Timely (reviewed frequently enough to catch issues before material damage occurs - monthly for financial transactions, quarterly minimum for lower-risk areas); and Monitored (has an owner who is accountable for performing the review). An example: a user has both purchase order creation and PO approval capability. The compensating control is a monthly management report of all POs where the creator and approver are the same person, reviewed and signed by the CFO. What makes it effective: it is actually performed (not just documented), the reviewer has no financial interest in the transactions reviewed, and exceptions are investigated and documented. What makes it weak - and a SOX finding - is if the review is done but there is no evidence (no signed report), or if it is done but exceptions are never investigated.

SAP transport management is a key SOX IT General Control (ITGC) because it controls how code and configuration changes reach the production system. The audit has four dimensions. First, verify the transport route configuration in STMS - changes must flow DEV to QAS to PRD, and the production client's SCC4 settings must prevent direct changes. Second, check for any emergency transports (corrections) imported directly to production bypassing QAS. Every such transport must have a documented emergency change ticket and post-import testing evidence. Third, review who has transport release authority (S_TRANSPRT, SE09/SE10) in production. Only a designated change manager should be able to release and import transports to production. Developers should not be able to import their own changes to production. Fourth, sample-test a selection of transports imported in the audit period and verify each has: a change ticket reference, test evidence from QAS, a business approval, and a deployment sign-off. Any transport without a complete approval chain is a SOX change management finding.

DORA - the Digital Operational Resilience Act - became effective for EU financial sector firms from January 2025. For organisations using SAP as their core ERP for banking, insurance, or investment management, DORA introduces four direct obligations. First, ICT Risk Management: firms must maintain a comprehensive ICT risk management framework that includes SAP in its scope - meaning SAP must have documented threat models, risk assessments, and control frameworks updated annually. Second, ICT Incident Reporting: any cybersecurity incident affecting SAP (data breach, ransomware, unauthorised access) that has operational impact must be reported to the regulator within defined timeframes (typically 4 hours for major incidents). Third, Digital Operational Resilience Testing: firms must conduct annual penetration testing of their critical ICT systems - SAP is typically in scope as a critical system. From 2025, Threat-Led Penetration Testing (TLPT) is required for the most significant firms. Fourth, Third-Party ICT Risk: SAP itself (as a software provider) and any SAP managed service provider must be subject to the firm's third-party ICT risk management programme - including contractual requirements for security standards and audit rights. The practical audit check is: does the organisation's ICT risk register include SAP, and do all four DORA requirements have documented evidence of compliance?

Prioritisation uses a risk-based framework across three dimensions. First, Likelihood × Impact: rate the likelihood that the vulnerability will be exploited (considering who has the access, how often they use it, and whether there are detective controls) and the potential impact (financial loss from fraud, regulatory fine, data breach cost). Critical × High impact findings get immediate remediation deadlines - typically 30 days for critical, 90 days for high. Second, Regulatory Impact: any finding that is likely to be a SOX material weakness, a GDPR breach notification trigger, or a DORA major incident criterion automatically gets the highest priority regardless of the internal risk score - because the regulatory consequence is externally imposed. Third, Control Dependency: some findings are foundational - for example, if the Security Audit Log is disabled, all downstream audit trail controls are ineffective. Foundational failures get priority over symptoms. In practice, the remediation order for a typical SAP audit would be: (1) Disable unused SAP* and DDIC accounts - 24 hours; (2) Remediate unmitigated critical SoD conflicts - 30 days; (3) Lock inactive user accounts - 30 days; (4) Enable and configure Security Audit Log - 30 days; (5) Apply critical security notes - 60 days; (6) Design and implement compensating controls for remaining SoD violations - 90 days; (7) Role redesign and restructuring - 6 months.