Introduction
SOC 2 Trust Services Criteria CC5.1 requires that the entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. Segregation of duties is the primary control activity CC5.1 addresses for access governance. The criterion requires that incompatible functions be separated so that no single individual can both initiate and approve a transaction, both create and release a payment, or both provision and certify their own access.
Most organisations have a segregation of duties policy. The policy states that incompatible functions must be separated and lists examples of conflicting role combinations. SOC 2 auditors examine CC5.1 by asking whether SoD is technically enforced, not whether it is policy-described. A policy stating that the accounts payable function must be separated from the payment approval function does not prevent a user from holding both roles if the IAM platform has no mechanism for detecting and preventing conflicting role assignments.
Technical SoD enforcement means that the IAM platform defines conflicting role combinations as rules, detects violations when they occur, prevents them where possible at the provisioning layer, and remediates existing violations through a structured workflow. Evidence of technical enforcement is what CC5.1 auditors expect. Evidence of SoD policy documentation is a prerequisite, not a substitute.
This blog covers what CC5.1 requires for SoD, the difference between policy-stated and technically-enforced SoD, how a SoD rules engine operates, and what evidence the control produces.
What CC5.1 Requires for Segregation of Duties
CC5.1 sits within the COSO Control Activities principle and covers the selection and development of control activities that mitigate risk. For access governance, SoD is the primary risk mitigation control activity that CC5.1 addresses.
The risk SoD addresses
SoD mitigates two categories of risk. Fraud risk: when incompatible functions are combined in a single individual, that individual can execute and conceal fraudulent transactions without requiring a second party. Error risk: when a single individual controls an end-to-end process, errors can occur and persist without detection because no independent party reviews the work.
For capital markets entities, financial services firms, and ITeS companies processing financial transactions, SoD violations in payment processing, financial reporting, and access provisioning create direct fraud exposure. For technology companies processing client data, SoD violations in access provisioning, where the same administrator both provisions access and certifies access reviews, undermine the independence of the review process.
What CC5.1 expects technically
CC5.1 expects that SoD is implemented as a technical control, not only documented as a policy. The control activity must demonstrate operating effectiveness throughout the audit period. A technical SoD control that detects and remediates violations continuously produces continuous operating evidence. A policy document that states SoD is required produces no operating evidence.
The control activity must cover the full population of users across all in-scope systems throughout the audit period. SoD violations that occurred during the audit period and were not detected or remediated are findings against CC5.1 operating effectiveness, regardless of whether the SoD policy existed.
Policy-Stated SoD vs Technically-Enforced SoD
The distinction between policy-stated and technically-enforced SoD is what determines whether CC5.1 is satisfied.
What policy-stated SoD looks like
A policy-stated SoD posture consists of a documented list of conflicting role combinations, a policy statement requiring that users not hold conflicting roles, and a manual review process where an administrator periodically checks whether any users hold combinations on the conflict list. The review is typically conducted quarterly or annually, and violations found are remediated by removing one of the conflicting roles.
The problems with this approach for CC5.1 purposes are multiple. Violations that occur between review cycles are undetected and unremediated for weeks or months. New role assignments that create violations are not blocked at provisioning time. The evidence produced is a periodic review record rather than a continuous detection record. Auditors sampling CC5.1 evidence from across the audit period will find gaps between review cycles where the control was not actively operating.
What technically-enforced SoD looks like
A technically-enforced SoD posture consists of a rules engine that defines conflicting role combinations as machine-readable rules, continuous detection that evaluates every role assignment against the rules in real time, prevention controls that block provisioning of access that would create a violation, and remediation workflows that address detected violations through a structured approval and removal process.
The evidence produced by technical enforcement is continuous: every detection event, every prevention action, and every remediation decision is logged with a timestamp. Auditors examining CC5.1 from any point in the audit period find active detection and remediation evidence rather than gaps between periodic review cycles.
How a SoD Rules Engine Operates
Akku’s IGA SoD rules engine implements technical SoD enforcement through four components: rule definition, continuous detection, provisioning prevention, and remediation workflow.
Rule definition
SoD rules define conflicting role combinations at the IAM platform level. A rule specifies two or more roles that must not be held simultaneously by the same user. Rules can be defined at the role level, for example accounts payable manager and payment approver, or at the permission level, for example create payment and approve payment across different applications.
Rules must cover all in-scope applications and all identified conflict categories. An effective SoD rule set is derived from the organisation’s risk assessment and covers the conflict categories that represent the highest fraud and error risk. For ITeS companies, common conflict categories include access provisioning and access certification, financial transaction initiation and approval, and system change implementation and change approval.
Continuous detection
The rules engine evaluates every user’s current role set against the defined conflict rules continuously. When a role assignment creates a violation, the detection event is logged immediately with the user identity, the conflicting roles, and the detection timestamp. Detection is not periodic: it occurs as role assignments are made and as rules are updated, not at a scheduled review interval.
For existing violations that predate rule definition, the initial rule activation triggers a detection pass across all current user role assignments, surfacing all existing violations for remediation.
Provisioning prevention
Where the rules engine is integrated with the provisioning workflow, a provisioning request that would create a SoD violation can be blocked at the approval stage. The approver receives a notification that the requested access would create a conflict with an existing role, and the request requires explicit override justification or role removal before it can proceed.
Prevention controls are the strongest form of SoD enforcement because they prevent violations from occurring rather than detecting and remediating them after the fact. For the most critical conflict categories, prevention is preferable to detection and remediation.
Remediation workflow
Detected violations that are not prevented at provisioning trigger a remediation workflow. The workflow notifies the user’s manager and the system owner of the violation, requests a decision on which role to retain and which to remove, and captures the decision with approver identity and timestamp. The remediation decision triggers automatic role removal through the same provisioning infrastructure used for standard access changes.
The remediation record, including detection timestamp, notification, decision, and removal confirmation, is the complete evidence chain that CC5.1 auditors examine for each violation detected during the audit period.
What CC5.1 Auditors Examine for SoD
Understanding the CC5.1 audit examination approach helps organisations assess whether their SoD controls will satisfy the criterion.
Evidence of technical enforcement
Auditors examine whether SoD is technically enforced or policy-stated. They request evidence of the rules engine configuration, showing which conflict rules are defined and which systems are in scope. They review detection logs, verifying that violations were detected continuously throughout the audit period rather than only at periodic review points. They examine prevention records for any provisioning requests that were blocked due to SoD conflicts.
Violation and remediation records
Auditors sample violations detected during the audit period and trace each from detection through remediation. They verify that every violation was addressed through a structured remediation process with a documented decision and that access removal followed the remediation decision. Violations detected but not remediated within a reasonable timeframe are evidence of control weakness.
Coverage completeness
Auditors assess whether the SoD rules cover the conflict categories that represent material risk for the entity. An organisation that has defined SoD rules for financial functions but has no SoD controls for access provisioning, where the same administrator both provisions and certifies their own access, has incomplete SoD coverage.
SoD Requirements Across Other Compliance Frameworks
SoD requirements are not unique to SOC 2. Multiple frameworks covered in this series require SoD enforcement, and the same technical control satisfies all of them.
RBI Clause 9(b) requires effective segregation of duties in IT operations and application development environments. SEBI CSCRF Identity and Access Governance guidelines PR.AA.S3 and PR.AA.S5 require that access be provisioned based on formally defined roles with conflict prevention. ISO 27001:2022 A.5.3 requires segregation of duties. DPDPA Clause 8(4) requires appropriate technical measures to ensure processing is limited to authorised purposes, which SoD enforcement implements at the access layer.
The same IGA SoD rules engine that satisfies SOC 2 CC5.1 simultaneously satisfies RBI Clause 9(b), SEBI CSCRF access control requirements, and ISO 27001 A.5.3 from one technical control. Akku’s SOC 2 mapping shows Identity and Access Governance addresses CC5.1, CC6.2, and CC6.3 across three mapping points.
Diagnostic Questions
Does your organisation have a technically-enforced SoD rules engine that detects conflicts continuously, or does SoD management rely on periodic manual reviews of role assignments against a conflict list?
For any SoD violation detected in the last 12 months, is there a complete evidence chain covering detection timestamp, remediation notification, decision record, and access removal confirmation?
Does your SoD rules engine cover all in-scope applications in a single platform, or do conflict rules exist only for some systems while others are outside the SoD enforcement scope?
When a provisioning request would create a SoD violation, is the request flagged or blocked at the approval stage, or does the violation only become apparent after access has been granted?
Has your organisation defined SoD rules for access provisioning functions as well as business process functions, ensuring that administrators cannot both provision and certify their own access?
CTAs
See how Akku’s IGA SoD rules engine addresses SOC 2 CC5.1 requirements through continuous detection, provisioning prevention, and structured remediation workflows.
Book a conversation with the Akku team to assess your current SoD posture against SOC 2 CC5.1 technical enforcement requirements.
FAQs
What is the difference between CC5.1 and CC6.3 for SoD purposes in a SOC 2 engagement?
CC5.1 covers the selection and development of control activities that mitigate risk, including SoD as a risk mitigation activity. It is the criterion that requires SoD to exist as a control. CC6.3 covers the authorisation, modification, and removal of access rights based on the system of record for entitlements. It is the criterion that requires access changes to be governed through a defined process. SoD enforcement under CC5.1 defines which role combinations are prohibited. Access governance under CC6.3 ensures that role changes and access requests follow a governed approval process. Both are required and they address different layers of the access governance framework.
Does SOC 2 CC5.1 require that SoD be technically enforced, or is a policy-stated SoD posture sufficient?
SOC 2 auditors assess CC5.1 as a control activity criterion, meaning they evaluate whether the control operates effectively throughout the audit period. A policy-stated SoD posture produces evidence of policy existence but not of continuous control operation. Auditors examining CC5.1 from across a 12-month audit period will find that a policy document existed but cannot find evidence of active detection and remediation throughout the period. Technical enforcement produces continuous detection and remediation evidence that satisfies the operating effectiveness standard. Policy documentation is a prerequisite for technical enforcement, not a substitute for it.
How should organisations prioritise which SoD conflict rules to define first?
SoD rule prioritisation should be based on risk assessment. The highest-priority conflict rules cover functions where a single individual having both capabilities creates direct fraud or material error risk. For financial services entities, payment initiation and approval is typically the first priority. For technology companies, access provisioning and access certification is a common high-priority conflict. For all entities, system change implementation and change approval creates a quality control risk. The rule set should expand over time to cover lower-priority conflicts as the programme matures.
What remediation timeline is considered acceptable for SoD violations under SOC 2 CC5.1?
SOC 2 does not specify a defined remediation timeline for SoD violations. Auditors assess whether violations were remediated within a reasonable period given the risk they represent. For high-risk conflicts such as payment initiation and approval, same-day or next-day remediation is expected. For lower-risk conflicts, remediation within the current review cycle is typically acceptable. Violations that persist unremediated for weeks or months without documented justification are evidence of control weakness. A compensating control, such as enhanced monitoring of transactions by users with unresolved violations, can partially mitigate the risk while remediation is pending.
Can the same SoD rules engine satisfy both SOC 2 CC5.1 and RBI Clause 9(b) simultaneously?
Yes. SOC 2 CC5.1 and RBI Clause 9(b) both require effective segregation of duties as a technical control. The same IGA SoD rules engine that detects conflicts continuously, prevents conflicting provisioning requests, and generates remediation workflows produces compliance evidence for both frameworks from the same technical control. The evidence record format, detection logs, prevention records, and remediation decision records, satisfies both auditors examining CC5.1 and RBI IS auditors examining Clause 9(b). Organisations subject to both frameworks do not need separate SoD controls, only a single rules engine with rules covering both frameworks’ identified conflict categories.
What is the relationship between SoD enforcement and access reviews, and do they address different risks?
SoD enforcement and access reviews address different categories of access risk and are both required for complete access governance. SoD enforcement addresses the risk that a single user holds two roles that, combined, enable fraud or material error without detection. It focuses on the combination of roles rather than the appropriateness of individual roles. Access reviews address the risk that a user holds roles that were appropriate at some point but are no longer appropriate for their current function. They focus on whether each individual role remains justified. An organisation with strong SoD enforcement but no access reviews will prevent conflicting role combinations but will not detect over-provisioning or entitlement drift. Both controls are required for a complete access governance framework.
