Which frameworks include Segregation of Duties (SoD) in IAM?

How SoD shows up in IAM frameworks

segregation of duties appears in IAM where a framework treats access as a control environment, not just a permission model. The common pattern is preventing a single user from holding conflicting powers across request, approval, provisioning, administration, and review. That is why SoD is often discussed alongside access governance, entitlement review, and privileged access rather than as a standalone IAM feature.

For practitioners, the IAM question is usually not whether a framework mentions SoD once, but whether it requires conflicting duties to be designed out of the process. IAM and Identity Provider Buyer's Guide and IAM and IGA Basics both frame SoD as part of broader identity governance, where role design, access review, and entitlement management are used to keep one person from controlling the full lifecycle of sensitive access.

In IAM programmes, SoD is most visible in workflows that separate requestor, approver, implementer, and reviewer. It also shows up in role engineering, because poorly designed roles can collapse several duties into one entitlement bundle. That creates a hidden control failure even when the IAM tool itself is functioning correctly.

Frameworks that mention SoD usually expect organisations to treat it as a policy decision plus an operating control. The policy defines which combinations are prohibited, while the operational layer checks for exceptions, compels approvals, and records compensating controls when strict separation is impossible.

Which framework families typically include SoD

SoD is most commonly found in governance-heavy frameworks and control catalogues that address fraud prevention, access governance, auditability, and internal control design. The clearest home is in identity governance, but it also appears in cloud and application security standards when entitlement conflicts can create unauthorized change, data exposure, or segregation failure.

Among the supplied sources, CSA Cloud Controls Matrix is a strong external example because it places IAM inside a broader cloud control structure that includes governance and access discipline. On the NHIMG side, SAP Identity and Access Security Guide is a practical example of SoD in enterprise systems where authorisation objects, firefighter access, and access governance must be reconciled.

SoD also appears in frameworks and programmes that focus on privileged access, internal controls, and audit evidence. In those settings, the control is not limited to who can log in, but extends to who can create, approve, execute, and certify sensitive actions. That is why SoD often becomes a requirement in finance, ERP, and regulated environments before it is written into a general IAM policy.

For broader IAM architecture, Identity Security Programme Guide is useful because it places SoD inside the wider operating model, where RACI, governance, and lifecycle controls determine whether the policy can actually be enforced.

What to check before calling a framework SoD-compliant

Do not treat a framework as SoD-capable just because it mentions least privilege or access reviews. SoD needs an explicit conflict model: the organisation must define which duties cannot coexist, how conflicts are detected, what happens when exceptions are approved, and how the exception is time-bound and reviewed. Without that, SoD becomes an aspiration rather than a testable control.

That is also why lifecycle matters. A framework that supports onboarding but not periodic recertification, revocation, or role cleanup will usually fail SoD in practice. NHI Lifecycle Management Guide is a useful reference point for the lifecycle side of the problem, because the same control logic applies when duties are embedded in service accounts, bots, or automation identities.

When evaluating a framework, look for three things: conflict detection, exception handling, and evidence retention. If those are absent, the framework may still support access control, but it does not give you a complete SoD operating model. In mature environments, the best indicator is not the policy document, but whether the organisation can produce a conflict report, an exception register, and a compensating control record.

At scale, the hard part is consistency. Manual SoD checks break down when roles, applications, and privileged pathways multiply. That is where policy-driven checks, entitlement analytics, and workflow enforcement become necessary, especially in shared environments with many admin-like roles.

Risk and Threat Considerations

SoD failures create an integrity risk: the same person can request, approve, and carry out a sensitive action, which removes the independent check the control is meant to provide. In IAM, that can turn a routine access process into a fraud, misuse, or insider-abuse path.

Failure mechanism: Conflicting entitlements, weak role design, or manual exception handling allows one identity to accumulate incompatible powers and bypass review.

Impact: Unauthorized access, hidden privilege escalation, and weak auditability can follow, especially where approvals are treated as a formality rather than an enforced control.

Practitioner Guidance

What to prioritise: Start with the highest-risk duty conflicts, not with every possible role collision. If a single identity can request, approve, and administer sensitive access, that conflict should be treated as immediate control debt.

What to verify: Confirm that your IAM or IGA process can prove three things for each SoD rule: who is conflicted, who approved the exception, and what compensating control was applied. If you cannot show those records, the control is not operationally complete.

Common mistake: Teams often rely on role names instead of effective permissions. SoD should be checked against the actual access path and effective entitlement set, not against the org chart or a nominal job title.

Practitioner takeaway: SoD only works when the framework makes conflicts machine-checkable and exception handling auditable; otherwise it is just policy language wrapped around a shared-access problem.

Related resources from NHI Mgmt Group

• Guide: Segregation of Duties (SoD) Guide
• When should organizations consider updating their IAM frameworks?
• Segregation of Duties (SoD) in IAM
• What is the difference between human IAM controls and NHI governance?
• How can organizations manage the risk of credential leaks in MCP frameworks?