GOV-009 Segregation of Duties
Description
Conflicting duties and responsibilities that could enable fraud or error are identified and separated across different individuals or automated controls. Roles are designed so that no single individual can both initiate and approve a sensitive operation; conflicting role combinations are recorded in a conflict matrix and their assignment to one account is prevented or detected. Where full separation is not feasible because of organisational size, compensating controls are documented.
Rationale
Segregation of duties is a fundamental internal control preventing any single individual from having end-to-end control over a critical business process, reducing the risk of both fraud and undetected errors.
Applicability (9 profiles)
Framework Mappings (7)
| IAM-04 | Separation of Duties | full |
| IAM-17 | Output Modification and Special Authorization | informative |
| IAM-04 | Separation of Duties | full |
| 5.3 | Segregation of duties | full |
| NIS2-CIR-1.2 | Roles, Responsibilities and Authorities | informative |
| AC-5 | Separation of Duties | full |
| CC6.3 | Role-Based Access Controls and Least Privilege | partial |
Evidence (3)
Segregation of duties matrix or documented SoD policy identifying conflicting roles and the required separations or compensating controls.
Example: Segregation of Duties Policy and conflict matrix (Confluence / GRC platform), identifying roles that must not be combined (e.g. code deploy and production access approval), with compensating controls documented for any exceptions due to organisational size.
Test: Request the SoD policy and conflict matrix. Verify: (1) conflicting role combinations are explicitly listed, (2) each conflict has either a required separation or a documented compensating control, (3) the policy has been approved by management within the last 12 months.
System access configuration records showing that conflicting roles are not simultaneously assigned to the same user accounts.
Example: Access control export from IAM system (Okta, Azure AD, AWS IAM) or ticketing system showing user-to-role assignments, confirming no user account holds both sides of a defined SoD conflict.
Test: Export user-role assignments from the IAM system. Cross-reference against the SoD conflict matrix. Verify: (1) no active user account is assigned both roles in any identified conflict pair, (2) for any exceptions, a documented compensating control record exists with a named approver.
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 (3)
Has your organisation recorded the conflicting role combinations that must not be held by one account?
A segregation of duties (SoD) matrix or conflict register should list role pairs that must not be combined, with compensating controls for any necessary exceptions.
How does your organisation verify that SoD conflicts are not present in the live IAM environment?
An IAM export cross-referenced against the SoD conflict matrix, showing no user holds both sides of a conflict, is the expected evidence.
Where full separation of a conflicting pair is not feasible, is a compensating control documented for it?
Answer yes only where each conflict left in place carries a named compensating control and the person who accepted it. A small organisation will have such pairs; what fails the control is leaving them unrecorded.