Treat SAP authorisation as a layered model, not a set of ad hoc permissions. Define authorization objects for business functions, use fields to narrow what actions are allowed, group those permissions into profiles, and assign profiles through roles matched to job functions. Then constrain access further with organizational levels so users only reach the data and processes their duties require.
Why SAP authorisation should be layered, not flat
access sprawl usually starts when teams grant broad transaction access to keep work moving, then keep adding exceptions as new cases appear. A layered SAP authorisation model reduces that drift by separating what a user can do, where they can do it, and under what business context. The result is tighter control without forcing every request through bespoke manual approvals.
The most important design choice is to make business function the first filter, then narrow access with field restrictions and organisational levels. That keeps the model aligned to work patterns, so users get enough access to complete daily tasks while avoiding the common failure mode of “one role fits everyone in the department.”
When organisations skip layering, they often compensate with oversized roles, shared approvals, or emergency access that never gets removed. That is operationally convenient in the short term, but it turns SAP authorisation into a catalogue of exceptions. A layered structure is what lets security teams reduce that exception count without turning every small variation into a new role.
For practitioners, the practical test is whether a user can complete the job with the minimum combination of authorisation object, field values, profile, role, and organisational scope. If the answer is yes, the model is doing its job. If the answer requires broadening one layer just to satisfy an edge case, the role design is probably too coarse.
How the SAP layers work together in practice
At the bottom layer, authorisation objects define the actions that are possible in a business process. Fields within those objects narrow the scope, such as document type, plant, company code, or activity. Profiles then package the resulting permissions, while roles assign those profiles to people based on job function. Organisational levels add the final boundary so access is limited to the relevant business unit or data domain.
This structure matters because each layer solves a different problem. Objects answer “what can be done,” fields answer “under which conditions,” roles answer “who should receive it,” and organisational levels answer “where it applies.” If teams collapse those decisions into one broad role, they usually compensate by granting too much access, which increases review effort and makes later cleanup harder.
Good SAP authorisation design also depends on stable role naming and clear ownership. If business roles are built around actual tasks, teams can re-use them across users rather than creating near-duplicates for each manager’s preference. That is the main control against access sprawl: reuse the smallest sensible building blocks instead of minting a new role for every exception.
One useful benchmark is whether the role model still makes sense after a transfer, promotion, or temporary project assignment. If every move requires a fresh manual build, the structure is too brittle. If most changes are handled by role substitution or a small number of scoped adjustments, the model is probably flexible enough for daily work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Restrict access by business need and role-based assignment. |
| Recommendation — Define access by job function and remove unnecessary permissions from SAP roles. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Management | Permissions should be managed according to least privilege and business need. |
| Recommendation — Map SAP roles to least-privilege business functions and review scope regularly. | ||
| NIST Zero Trust (SP 800-207) | 5 — Policy Decision and Enforcement | SAP authorisation layers mirror policy-driven, context-aware enforcement. |
| Recommendation — Enforce authorisation decisions through layered policy and context rather than broad standing access. | ||
| ISO/IEC 42001:2023 | 5.2 — AI policy | No material alignment |
| NIST SP 800-63 | 3 — Authenticator Assurance Level 3 | No material alignment |
Practitioner Guidance
What to prioritise: Start by rationalising the highest-volume business functions, not the rarest exceptions. The fastest way to reduce sprawl is to eliminate duplicate roles and overly broad composite access where a smaller task-based role would do the same job.
What to verify: Check that field restrictions and organisational levels are actually doing the narrowing work. A role that looks precise on paper can still be over-permissive if one of those layers is left generic or copied across teams without review.
Common mistake: Security teams often focus on reducing the number of roles while leaving each role too wide. Fewer roles are not automatically safer if each one still contains broad transaction access, weak field values, or cross-unit reach.
Practitioner takeaway: The best SAP authorisation model is the one that absorbs routine variation through structure, not through exceptions, so daily work stays smooth while access remains explainable and bounded.
Related resources from NHI Mgmt Group
- How should security teams reduce OT remote access risk without blocking maintenance work?
- How should security teams structure a marketplace for identity, secrets, and workflow integrations without creating admin sprawl?
- How should teams reduce AWS access sprawl without slowing engineering work?
- How should security teams reduce hidden SAP access and change risks without relying on manual controls?
