Segregation of duties policy and procedure in IAM governance

At a glance

What this is: This is an overview of segregation of duties policy and procedure, showing how task separation and access review reduce fraud, misuse, and compliance risk.

Why it matters: It matters because IAM teams need SoD to work across human access, privileged workflows, and non-human accounts without creating blind spots or biased review loops.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Zluri's overview of segregation of duties policy and procedure

Context

Segregation of duties, or SoD, is the control principle that prevents one identity from both executing and validating a sensitive process. In IAM terms, it is meant to stop the same person, role, or account from concentrating enough authority to create fraud, hide errors, or bypass oversight.

That matters for identity governance because the control only works when access assignment, approval, and review are separated in practice, not just written into policy. The article frames SoD as an access management problem, which places it squarely alongside joiner-mover-leaver governance, privileged access management, and access certification design.

For non-human identities, the same logic becomes more brittle because service accounts and API keys often sit outside human review cycles. The governance question is not whether SoD sounds right, but whether your operating model can still enforce it when access is machine owned, delegated, or embedded in workflow.

Key questions

Q: How should security teams enforce segregation of duties in IAM workflows?

A: Start by separating who can request, grant, modify, and certify access. Then map those responsibilities into workflow and role design so the same person or team cannot both perform a sensitive action and approve it. SoD is effective only when independence is built into the process, not added as an afterthought.

Q: Why do SoD controls fail when access review sits with the same team that provisions access?

A: Because the review is no longer independent. If the same team can create the entitlement and later attest that it is appropriate, the control becomes a confirmation loop rather than a challenge function. That weakens fraud prevention, auditability, and the credibility of the access governance programme.

Q: What do IAM teams get wrong about SoD for service accounts and shared accounts?

A: They often design SoD around named employees and forget that non-human accounts can carry the most sensitive privileges. Service accounts, shared accounts, and orphaned accounts need ownership, conditions, and review logic of their own. If they are excluded, SoD coverage stops where machine access begins.

Q: Who should approve SoD exceptions and temporary access overrides?

A: Approval should come from someone outside the operational path that requested or granted the access. The exception should be time-bound, documented, and separately reviewable so it does not become a permanent bypass. Independence matters more than speed when the control is meant to prevent conflicted authority.

Technical breakdown

SoD policy versus SoD procedure

A policy states the rule, while a procedure defines the operational steps that make the rule enforceable. In SoD, policy says which combinations of duties must never sit with the same identity, and procedure defines how roles, approvals, and exceptions are checked in real workflows. If the policy is broad but the procedure is manual or inconsistent, the control becomes advisory instead of preventive. In identity governance, that gap is where conflicts of interest survive even though the policy exists on paper.

Practical implication: align policy language with enforceable workflows so access decisions and review paths are actually separated.

Access review and privileged access controls

The article correctly separates granting, modifying, and revoking access from reviewing that access. That distinction matters because SoD fails when the same team or workflow both changes entitlements and certifies them, creating a closed loop with no independent challenge. In practice, this is where privileged access governance, approval chains, and certification attestation intersect. If the reviewer can influence the original access decision, the review is no longer independent and the control loses integrity.

Practical implication: assign access review to an independent control owner who cannot approve or provision the same entitlement.

Unmapped accounts and conditional enforcement

The article notes that SoD checks should apply to unmapped accounts as well as named users. That is an important identity detail because machine accounts, shared accounts, and orphaned entitlements often evade person-centric governance assumptions. Conditional enforcement lets teams test permissions against role and location criteria, but those conditions must be complete enough to catch accounts with no obvious human owner. Otherwise, SoD coverage stops at the directory boundary and misses the identities most likely to accumulate hidden privilege.

Practical implication: include unmapped and orphaned accounts in SoD logic so machine access cannot bypass review by lacking a user record.

NHI Mgmt Group analysis

SoD breaks fastest when access assignment and access review are allowed to converge. The article describes the classic control failure correctly: the same operational path that grants or modifies access must not be the one that certifies it. When that separation collapses, the organisation no longer has a meaningful second line of challenge, only a procedural echo of the first decision. Practitioners should treat independent review as the control boundary, not the tooling label.

SoD is not just a finance control once identity sprawl crosses SaaS and machine access. The article's examples begin in business process control, but the same failure pattern appears in SaaS administration, privileged access, and service account governance. When entitlements are spread across multiple applications and the access model is not centralised, SoD becomes difficult to prove even if it exists in policy. The practitioner takeaway is that SoD maturity depends on cross-application identity visibility, not departmental intent.

Unmapped accounts are where SoD assumptions become weakest. A policy designed around named users assumes every important privilege can be traced to a person and a role. That assumption fails when the identity is a service account, shared account, or orphaned account with no obvious owner. The implication is that SoD programmes must treat ownership traceability as part of the control design, because accountability disappears when the account record does.

Role-based provisioning is only SoD-safe when role design and approval logic are kept separate. The article encourages automated role assignment, but role automation can also hard-code bad separation if the same role bundle carries incompatible duties. The control problem is not automation itself, but whether the role model preserves segregation at the entitlement layer. Practitioners should review role engineering as part of SoD governance, not as a separate IAM exercise.

Centralised access visibility turns SoD from a policy statement into an auditable control. The article's emphasis on a unified dashboard is directionally right because SoD enforcement depends on seeing who can do what across systems, not within one application at a time. Without that cross-system view, violations can persist in shadow entitlements and undocumented exceptions. The field lesson is that SoD evidence is only as strong as identity visibility across the full application estate.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That is why teams should pair NHI Lifecycle Management Guide with access review design when SoD must cover machine identities.

What this signals

SoD programmes will be judged less by policy wording and more by whether they can prove independent review across every identity type. The moment service accounts, shared accounts, and privileged admins all feed the same approval loop, the control loses credibility. With 97% of NHIs carrying excessive privileges according to Ultimate Guide to NHIs, the practical risk is not abstract noncompliance but hidden authority that no reviewer fully sees.

Role engineering is becoming a governance discipline, not just an access administration task. If roles bundle incompatible duties, automation simply reproduces the violation faster. Teams that want durable SoD need to link access models, certification design, and exception handling through a single governance standard, with the NIST Cybersecurity Framework 2.0 providing a useful control vocabulary for ownership and review.

Identity visibility is the hinge point for SoD in SaaS-heavy estates. The article assumes centralised access insight can support segregation, and that is directionally correct. In practice, teams should use that lens to surface orphaned entitlements, review gaps, and machine-owned privileges before the next certification cycle exposes them as control failures.

For practitioners

• Separate access grant and access review ownership Assign provisioning, modification, and revocation to one team or workflow and certification to a different owner. Document the separation in the control narrative and verify it during every review cycle, especially where SaaS admins or PAM operators can influence the same entitlement they later attest.
• Extend SoD rules to unmapped and shared accounts Include service accounts, shared accounts, and orphaned accounts in SoD conditions so non-person identities cannot bypass governance because they lack a clear user record. Require ownership mapping, even when the account is not tied to a named employee.
• Centralise entitlement evidence before certification Use a unified view of access across applications so reviewers can see role memberships, privileged assignments, and exceptions in one place. That reduces the chance that a reviewer certifies access they cannot fully observe.
• Design role bundles to preserve duty separation Review role engineering for conflicts before automating provisioning. If one role bundle combines incompatible duties, the automation only scales the violation. Rework the access model so separation exists at the role layer, not just in policy text.
• Create exception handling that preserves independence When a SoD exception is unavoidable, route approval outside the operational team and time-limit the exception with explicit review criteria. Keep the exception record separate from the original request so the control remains independently challengeable.

Key takeaways

• Segregation of duties fails when the same identity can both exercise and certify sensitive access.
• The scale of the problem is visible in non-human identities, where excessive privilege and weak lifecycle controls remain common.
• SoD becomes credible only when role design, review independence, and account ownership are enforced together.

Key terms

• Segregation Of Duties: A control principle that splits sensitive tasks across different people or roles so no single identity can both perform and approve a critical action. In identity governance, it reduces fraud, hidden errors, and conflicted authority across access requests, privileged workflows, and certification processes.
• Access Certification: A formal review in which access is checked against business need, role design, and risk before it is approved to continue. In strong identity governance, certification is independent from provisioning and revocation so the reviewer is not validating their own access decision.
• 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.
• Role Engineering: The design and maintenance of access roles so they reflect job function while preventing incompatible duties from being bundled together. In SoD programmes, role engineering is a control design activity, because poor role construction can automate violations at scale.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Zluri: Security & Compliance Segregation of Duties Policy and Procedure: An Overview. Read the original.