IAM-006 Role-Based Access Control and Separation of Duties
Description
Access to systems and data is assigned via defined roles rather than to individuals directly. Roles are designed to enforce separation of duties so that no single individual can both initiate and approve sensitive operations. Conflicting role combinations are documented and prevented.
Rationale
RBAC reduces administrative overhead and makes access reviews tractable. Separation of duties prevents fraud and error by ensuring critical actions require two independent parties.
Framework Mappings (5)
| IAM-04 | Separation of Duties | full |
| IAM-15 | Authorization Mechanisms | partial |
| 5.15 | Access control | partial |
| AC-5 | Separation of Duties | full |
| CC6.3 | Role-Based Access Controls and Least Privilege | partial |
Evidence (2)
RBAC role definitions in the IdP or authorisation platform showing defined roles, the permissions each role includes, and conflict-of-interest (SoD) rules that prevent assignment of conflicting roles to the same user.
Example: Okta group/role export or Azure AD role assignment export listing all defined roles with their permissions, plus any SoD rule configuration from an IGA tool (e.g. SailPoint, Saviynt) showing conflicting role pairs.
Test: Export the full role catalogue and current user-to-role assignments. Verify: (1) access is assigned via roles, not directly to individual users where role-based assignment is possible, (2) conflicting role combinations (e.g. 'payment initiator' and 'payment approver') are documented, (3) query for any user holding both roles in a conflicting pair — expect zero results, (4) any exceptions are documented with compensating controls.
SoD violation report from the most recent access review or IGA tool run, showing any detected conflicts and their remediation status.
Example: SailPoint, Saviynt, or custom IGA report listing SoD conflicts identified in the last review cycle, with a disposition column showing each conflict was remediated, accepted with a documented business justification, or has an open remediation ticket.
Test: Request the most recent SoD conflict report. Verify: (1) the report was generated within the last review period, (2) all conflicts are in one of three states: remediated, accepted with documented compensating controls, or have an open time-bound remediation ticket, (3) the total number of open unmitigated conflicts is zero.
Questions (2)
Is access to systems and data assigned through defined roles rather than granted directly to individual users?
Role-based assignment must be the default. Direct individual-level grants should be exceptions with documented justification, not the norm.
Are separation-of-duties (SoD) conflicts — where a single user could both initiate and approve a sensitive operation — formally identified and prevented?
Technical prevention (e.g. an IGA tool blocking conflicting role assignments) is stronger than procedural controls alone. Any unmitigated SoD conflict in a sensitive function should be documented with a compensating control.