Segregation of duties policy and procedure in IAM governance

At a glance

What this is: This article explains segregation of duties policy and procedure as an IAM governance control that splits authority, review, and execution to reduce fraud and access misuse.

Why it matters: It matters because IAM teams often create SoD rules but fail to align access workflows, certifications, and privileged access handling, leaving the control weak in practice.

Context

Segregation of duties is an identity governance control that prevents one identity from controlling an entire sensitive workflow. In practice, that means the person or account that grants access, approves a transaction, or reviews entitlement should not be the same one performing the action.

The article frames SoD as both policy and procedure. Policy defines what must be separated, while procedure defines how access is granted, reviewed, and revoked without creating conflicts of interest or leaving revocation gaps across SaaS, data, and systems.

Key questions

Q: What breaks when segregation of duties is the only control in place?

A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access. Users can change roles, projects can end, and temporary access can become permanent without any SoD alert. A programme built only on prevention still accumulates governance debt over time.

Q: Why does segregation of duties reduce fraud and unauthorized activity in access-controlled environments?

A: Segregation of duties reduces risk by preventing one person or team from controlling every step in a sensitive process. When initiation, approval, execution, and review are separated, it becomes harder to conceal mistakes or abuse access. The control also improves accountability, because deviations are easier to detect through documented workflows and access governance checks.

Q: How do security teams know if SoD controls are actually working?

A: SoD controls are working only if live access state matches the approved separation model across systems. Teams should verify that no identity can both initiate and validate the same sensitive transaction, and that exceptions are time-bound and independently reviewed. If certification reports look clean but operational workflows still allow self-approval, the control is failing.

Q: Should organisations include service accounts in segregation of duties checks?

A: Yes. Any account that can perform sensitive actions should be subject to SoD logic, including service or unmapped accounts. If those accounts are excluded, the organisation creates a parallel access path that can bypass the same governance applied to human users.

Technical breakdown

Why SoD fails when policy and procedure are treated separately

Segregation of duties only works when the written policy is translated into enforced workflow. A policy can say that no one should both grant and review access, but the procedure has to encode that rule into approvals, role assignment, and review ownership. If the procedure allows the same operational team to approve and certify, the control exists on paper but not in execution. In IAM terms, SoD is not just a governance statement. It is a constraint on who can act, who can verify, and who can remediate across the access lifecycle.

Practical implication: map every SoD policy rule to a concrete approval, certification, or revocation step.

How access reviews and privileged access create SoD tension

The article highlights a common control conflict: the team that grants, modifies, or revokes access should not also review that access. That separation matters because recertification loses independence when reviewers are also responsible for the underlying entitlement model. Privileged access makes the problem sharper, since elevated access can be temporary, role-based, or time-constrained, and still needs independent oversight. SoD is therefore a governance design problem, not just an access control setting. It has to distinguish provisioning authority from verification authority, especially where privileged access and review cycles overlap.

Practical implication: separate provisioning ownership from access review ownership, especially for privileged accounts.

Why unmapped accounts still need SoD enforcement

The article notes that SoD checks should also apply to unmapped accounts, not only named users. That matters because service or shared accounts can carry permissions without an obvious human owner, which makes exception handling and review more difficult. If an account can initiate sensitive actions but is not tied to the same conditions as a mapped user, the policy leaves a blind spot. From a governance perspective, SoD has to evaluate effective permissions, not only identity labels. Otherwise, the control can be bypassed through accounts that sit outside normal user-centric review logic.

Practical implication: include unmapped and shared accounts in SoD condition testing and recertification.

NHI Mgmt Group analysis

SoD is an independence control, not a documentation exercise: The control fails when policy says duties are separate but the operational workflow still concentrates approval, provisioning, and review in the same team. That is a governance failure, not a tooling failure, because the review is no longer independent. Practitioners should treat SoD as a test of separation in practice, not a statement in a policy binder.

Access review without role separation creates false assurance: If the same function that manages access also certifies it, recertification becomes circular. The article's example of access review illustrates a broader IAM truth: verification only has value when the reviewer is outside the entitlement chain. Teams should re-evaluate who owns certification, not just how often it happens.

Unmapped accounts are where SoD blind spots accumulate: The article correctly extends policy conditions beyond named users to accounts with no obvious owner. That matters because governance breakdown often hides in shared, orphaned, or service-style access paths that do not fit human-centric review assumptions. Practitioners should treat account inventory completeness as a precondition for SoD, not a separate hygiene task.

Identity governance needs one control language across human and non-human access: The same separation principle applies whether the actor is a person, a privileged account, or another non-human identity. If policy, workflow, and review logic differ by actor type without a common governance model, SoD becomes fragmented and inconsistently enforced. Practitioners should align access governance across the whole identity estate, not only employees.

Shared authority is the real risk signal behind SoD violations: The article points to embezzlement, unauthorized transactions, and access misuse, but the deeper issue is concentration of control. When one operational path can both create and validate entitlement, the organisation loses its checks-and-balances model. Practitioners should look for any workflow where the same role can create evidence and approve it.

What this signals

SoD only has value when the reviewer is outside the entitlement chain: Access certification that is owned by the same function that provisions access creates circular assurance. Identity governance programmes should treat reviewer independence as a design requirement, not a reporting preference.

Unmapped accounts are a governance boundary, not an exception class: Once shared or service-style accounts escape the same conditions as named users, the policy loses coverage. That is why SoD has to be tested against account ownership, not just against job titles or business roles.

For practitioners

• Define SoD rules around conflicting duties Write policy conditions that block a single role or account from both initiating and approving sensitive actions, then tie each condition to a specific operational workflow.
• Separate access provisioning from access review Assign access certification to a function that does not create or modify the underlying entitlements, and make that separation explicit for privileged access paths.
• Include unmapped accounts in SoD checks Test shared, service, and orphaned accounts against the same SoD conditions used for named users so non-human access does not bypass review logic.
• Document resolution steps for policy violations Use clear remediation instructions for SoD exceptions so reviewers know whether to revoke access, reassign ownership, or escalate for manual approval.

Key takeaways

• Segregation of duties is meant to prevent the same identity from creating, approving, and reviewing sensitive actions, but it only works when policy and procedure stay aligned.
• The article shows that access review, privileged access, and unmapped accounts all need separate treatment or the control becomes circular and incomplete.
• The practical control question is not whether SoD exists, but whether the organisation can prove independent review, distinct ownership, and full account coverage.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
• Unmapped Account: An account that exists in systems but is not clearly tied to a known person or business role. These accounts are common in machine access environments and create governance risk because they can carry privilege without obvious ownership, making SoD, lifecycle, and audit controls harder to enforce.
• Privileged Access: Privileged access is any elevated entitlement that can change systems, data, or security settings. When privilege is excessive or poorly scoped, a single compromised identity can create outsized blast radius across environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.