Role Concept and RBAC
A role concept (Rollenkonzept) defines the structured assignment of access privileges to ERP users. Modern ERPs use Role-Based Access Control (RBAC): privileges are bundled into roles (e.g., AP Clerk, Production Planner, Sales Manager), roles are assigned to users based on their job function. The role concept underpins compliance (segregation of duties, GoBD audit-trail completeness), security (least-privilege access) and operational efficiency (consistent access patterns per function).
Core RBAC principles
Three foundational principles. (1) Least privilege: users have only the access needed for their specific role — no more. Reduces exposure from compromised accounts or insider threats. (2) Separation of duties (SoD): specific combinations of privileges (e.g., creating supplier plus authorising payment) are forbidden to prevent fraud. SoD rules encode known fraud patterns. (3) Need-to-know: sensitive data (salary, customer financials, personal information) restricted to those with legitimate need. The principles work together: roles bundle permitted privileges; SoD rules forbid problematic combinations; data-level access controls limit visibility within permitted functions.
ERP-side implementation
Major ERPs implement RBAC differently but with shared concepts. SAP S/4HANA: authorisation objects, profiles, roles, composite roles, with PFCG transaction managing role design. Microsoft Dynamics 365 F&O: security roles, duties, privileges with hierarchical composition. Oracle Cloud ERP: job roles, abstract roles, data security policies. NetSuite: standard roles plus custom roles with granular permissions per record type. Mid-market (Sage X3, Business Central, abas, proALPHA, weclapp): role-based access through function bundles. Most ERPs ship with reference roles matching common job functions; customisation refines these for organisation-specific structures.
SoD conflict examples
Classic SoD-conflict examples to enforce in ERP. Supplier master plus payment: the same user should not be able to create a supplier (including bank details) and authorise payments to that supplier. Customer master plus credit memo: prevents fake-credit-memo fraud. Purchase requisition plus PO approval: self-approval of purchases. Goods receipt plus invoice approval: enables fictitious-delivery fraud. Order entry plus pricing exception: enables unauthorised discounting. Major ERPs provide SoD-conflict identification tools; specialist platforms (SAP GRC Access Control, Pathlock, Onapsis, SailPoint, Saviynt) provide deeper SoD analysis especially for multi-system landscapes where conflicts span ERPs.
Practical considerations
Three patterns. (1) Home with standard roles: most ERP vendors ship with reference roles matching common functions. Customise from there rather than designing from scratch. Saves implementation effort and aligns with vendor best-practice. (2) Document role assignments: every role should have a documented purpose, included privileges, excluded SoD-conflicting privileges, and approval-authority chain. Without documentation, role design drifts over time and re-certification becomes guesswork. (3) Periodic re-certification: users change roles; some accumulate excess privileges over time. Annual re-certification confirms each user's current role set still matches their actual job. SOX-listed organisations are obliged to re-certify; non-listed organisations should follow the same discipline. Mature operations automate the re-certification workflow with structured manager review.
Related Topics
Frequently Asked Questions
How granular should roles be?
The right balance: granular enough to enforce least-privilege and SoD; not so granular that role count explodes (hundreds of roles for a 100-employee company is a smell). Typical mid-market: 30-80 active roles. Composite roles (combining sub-roles) help manage complexity by reusing components.
Do we need specialist GRC tools?
For SOX-listed organisations, yes — specialist GRC platforms (SAP GRC, Pathlock, Onapsis, SailPoint, Saviynt) provide the SoD-conflict analysis and re-certification automation needed. For mid-market non-listed organisations, ERP-native tools plus periodic manual SoD reviews often suffice. Threshold for specialist tools: above 50 active roles or multi-ERP landscape.
How does role concept interact with SSO and MFA?
Authentication (proving who you are, via SSO and MFA) and authorisation (what you can do, via roles) are separate concerns. SSO authenticates the user; MFA strengthens authentication; role assignment determines authorisation. The three combine for end-to-end access control. Modern ERPs delegate authentication to central IdPs (Microsoft Entra ID, Okta, Keycloak) while managing authorisation internally.