Building an Authorization Concept That Won't Get You Audited

Authorization design is the area of SAP administration most commonly treated as an afterthought — and the area that most commonly triggers audit findings, compliance failures, and in serious cases, fraud. A well-designed authorization concept is not complex, but it requires deliberate design upfront rather than organic accumulation of access over time.

The Authorization Object Model

SAP's authorization model is built around authorization objects. An authorization object defines what can be controlled (e.g., which transaction codes, which company codes, which document types). It contains fields that specify the permitted values for each dimension of access.

When a user executes a transaction, the ABAP runtime performs authorization checks against the user's assigned authorizations using the AUTHORITY-CHECK statement. If the user's authorizations do not include the required object with the required field values, access is denied and SU53 records the failed check.

Understanding the underlying object model — not just the PFCG role maintenance interface — is what separates a robust authorization concept from one that accretes access until it collapses under audit.

Roles vs Profiles vs Composites

The terminology is a source of ongoing confusion.

An authorization profile is the technical artefact that contains authorization objects and their field values. Profiles are generated by PFCG from role definitions and should not be manually maintained — manually maintained profiles bypass the profile generator's change tracking.

A single role is a named collection of menu entries, transaction codes, and associated authorization data. PFCG generates one profile per single role. Single roles should map to a defined business function — not a person, not a department, and never "everything this person needs."

A composite role contains other single roles. It is an assignment convenience — a composite role is assigned to users, not the individual single roles that compose it. This allows a set of single roles representing a job function to be assigned in one step and maintained centrally.

Assign users to composite roles. Do not assign individual single roles directly to users in a large landscape — you will lose the ability to understand what any given user can actually do.

The Profile Generator (PFCG)

PFCG is the authoritative tool for role maintenance. Everything about a role — menu, transactions, and authorization data — should be defined and maintained here. The workflow is: create role, define menu and transactions, generate the authorization proposal, adjust field values as needed, generate the profile, assign to users or composite roles.

The authorization proposal is generated from SAP's USOBT_C table, which maps transaction codes to the authorization checks they perform. After any system upgrade or support package application, run SU25 to update this table. Roles with outdated proposals may grant too much or too little access without any visible indication.

Never use SE16 to directly modify authorization tables. Never maintain profiles directly in SU02. Both approaches bypass the profile generator's tracking and create configuration that cannot be reliably maintained or audited.

Segregation of Duties

Segregation of duties (SoD) is the requirement that no single user can perform both sides of a sensitive business transaction without a second approval step. The classic example is a user who can both create a vendor and release a payment to that vendor — this combination enables fraud without external participation.

The authorizations that create SoD conflicts in SAP are well-documented. The most common critical combinations involve: vendor master maintenance and payment release, purchase order creation and goods receipt, customer master maintenance and credit limit approval, and general ledger posting and bank account management.

When designing roles, identify SoD-sensitive transaction combinations and ensure they are in separate roles that cannot be assigned to the same user simultaneously. If your landscape uses SAP GRC Access Control, the SoD ruleset will catch conflicts at request time. If it does not, you need a manual review process at role assignment time.

SAP_ALL and SAP_NEW: Never in Production

SAP_ALL grants access to everything in the system. SAP_NEW grants access to all new authorization objects added in recent SAP releases. Both exist as emergency tools and as artefacts of legacy systems.

Neither should exist in production assigned to any user other than the emergency access user (if you use one). If you inherit a system where SAP_ALL is assigned to named business users, treat this as a P1 issue regardless of how long it has been that way. The access debt does not become safer with age — it becomes a larger liability.

Use SU10 to identify all users with SAP_ALL or SAP_NEW assigned. Use the authorization trace and USOBT analysis to understand what they actually need, and replace the broad profile with scoped roles.

The Authorization Trace

When users report missing access, the correct diagnostic tool is SU53 (last failed authorization check for the current user session) or ST01 (full authorization trace). Do not ask the user what they were doing and guess — trace the actual check that failed.

ST01 with authorization trace enabled will log every AUTHORITY-CHECK call during a user session. Run this with the affected user reproducing the problem, then review the trace to find the exact authorization object and field values required. Add only those specific values to the appropriate role. Do not add entire objects with wildcard field values to resolve a single missing access — this is how authorization concepts deteriorate over years.

Building for Auditability

An auditable authorization concept has four properties. First, every role has a documented purpose — who it is for and what business function it enables. Second, every user's role assignment is traceable to a formal access request. Third, SoD conflicts are either prevented by design or mitigated with compensating controls documented in the risk register. Fourth, access is reviewed on a scheduled basis, typically quarterly for sensitive roles and annually for standard roles.

Build these properties in from the start. Retrofitting them into a mature system that was built without them is an expensive and disruptive project. The time to build an auditable authorization concept is before the system goes live, not after the external audit finding.

> Editorial note: Authorization requirements vary by industry, regulatory framework, and system configuration. This guide reflects general best practices. Specific SoD requirements for SOX, GDPR, and other frameworks may impose additional constraints. Validate your authorization concept with your compliance team before go-live.