Segregation of duties (SoD) is supposed to catch those conflicts before they become fraud, error, or an audit finding. But most teams still gather SoD rules the old way: spreadsheets, interviews, endless email threads with application owners. It's slow. It's inconsistent. And conflicts usually surface during an audit, not before one.
This guide covers what SoD means in IAM, why regulators care, real-world examples, and how better requirements gathering closes the gaps that manual processes leave behind.
Key Takeaways
- SoD stops any single identity, human or machine, from holding conflicting access that enables fraud or error
- SOX, HIPAA, GDPR, and ISO 27001 all require demonstrable SoD controls
- Effective SoD combines preventive (request-time) and detective (ongoing monitoring) controls
- Incomplete SoD documentation is a recurring driver of audit findings
- Automated requirements gathering catches conflicts that interviews and spreadsheets miss
What Is Segregation of Duties in Identity and Access Management?
Segregation of duties (SoD) is a control that splits authorization, custody, reconciliation, and recordkeeping across different people or roles. NIST defines the principle simply: no single user should hold enough privilege to misuse a system alone.
In IAM, this goes far beyond finance. It applies to:
- IT administration — account creation, privilege granting, and audit log access
- DevOps pipelines — code deployment versus change approval
- Cloud entitlements — who can provision resources versus who can approve spend
Static vs. Dynamic Enforcement
Two enforcement models show up in practice:
- Static enforcement — blocks conflicting role combinations at the role-definition level
- Dynamic enforcement — flags a request in real time when it would create a conflict and routes it for independent review
SoD vs. Least Privilege
These get confused constantly. Least privilege limits how much access someone has. SoD limits which combinations of access one identity can hold, regardless of how minimal each individual grant looks.
A user can be fully compliant with least privilege and still hold a dangerous SoD conflict if two low-risk permissions combine into a high-risk one.
Access-related risk is already high without SoD gaps compounding it. Verizon's 2025 Data Breach Investigations Report found compromised credentials served as the initial access vector in 22% of breaches reviewed — a reminder that access controls, SoD included, carry real weight.
Why SoD Compliance Is Critical for Regulated Industries
Regulators don't always use the words "segregation of duties" explicitly, but the expectation runs through nearly every major compliance framework.
- SOX (Section 404): Management must assess internal controls over financial reporting. PCAOB AS 2201 treats access controls as part of that IT environment and allows compensating controls when full separation isn't feasible.
- HIPAA: 45 CFR 164.308 requires workforce access authorization and supervision; 164.312 requires unique user IDs and least-privilege access. Together they support SoD-style design without mandating a two-person rule.
- GDPR: Article 25 requires data protection by design and default minimization; Article 32 requires technical measures matched to risk. Segregated access is often the proportionate way to meet both.
- ISO/IEC 27001:2022: Annex A control 5.3 addresses segregation of duties directly as an organizational control.
Those same expectations create different failure modes by industry.
Industry-Specific Risk Areas
- Healthcare: Clinical access versus billing access — a coding employee who can also alter clinical records creates fraud exposure
- Financial services: Transaction initiation versus approval: the same person who creates and clears a payment can move funds undetected
- Federal: Classified tiers versus standard operational access: mixed privileges expand insider-threat and data-spill risk
Non-compliance consequences are concrete. HHS OCR's 2025 resolution with a Syracuse ambulatory surgery center required a $250,000 payment tied to access-control and risk-analysis failures. Regulators do act on weak access governance, even when SoD isn't the headline finding.
Common Examples and Principles of SoD in IAM
ISACA's SoD framework breaks duties into four categories: custody, authorization, recordkeeping, and reconciliation. No single identity should hold two incompatible categories over the same asset.
Classic conflict examples:
- Vendor creation vs. payment approval: the person who adds a vendor shouldn't be able to release payment to that vendor
- Account creation vs. privilege granting vs. audit access: IT admins who provision access shouldn't also control the logs that would catch misuse
- Code deployment vs. change approval: developers pushing to production shouldn't approve their own changes
The Non-Human Identity Problem
Service accounts, RPA bots, and AI agents now perform tasks that used to require human sign-off, and they increasingly handle both the initiating and approving actions. ISACA's 2025 guidance on non-human identities flags this risk: one identity used for both manual and automated tasks, with no separation.
Who Owns SoD?
Nobody owns it alone:
- Compliance officers define the regulatory scope
- IAM/IGA teams build and enforce the technical rules
- Application owners know the actual business-process conflicts
- Auditors validate the evidence
Shared ownership is why SoD requirements get lost. Everyone assumes someone else has the full picture.
Best Practices for Implementing and Maintaining SoD Controls
Strong SoD design only holds if you roll controls out in the right order and keep them current. Use the practices below to implement separation rules and maintain them as roles, systems, and identities change.
- Map high-risk systems first. Prioritize financial applications, PII repositories, and domain controllers before lower-risk systems.
- Build a documented conflict matrix. Use ISACA's n-by-n activity matrix method, marking incompatible combinations across financial, operational, and administrative controls.
- Combine preventive and detective controls. Block conflicts at request time, and run periodic access certifications to catch drift.
- Automate through IGA tooling. Use entitlement correlation, policy management, risk scoring, and automated certification workflows. Manual spreadsheet cross-referencing does not scale across large application estates.
- Extend rules to non-human identities. Service accounts and bots need the same conflict checks as human users, with clear ownership assigned to each one.
- Document exceptions with compensating controls. When strict separation isn't feasible, capture the business justification, an independent approver, a time limit, and enhanced monitoring.
CISA and NSA's joint IAM guidance adds one more layer: tie SoD reviews to lifecycle events. Role changes are a leading cause of leftover, obsolete entitlements that quietly recreate conflicts nobody approved.
Why Accurate Requirements Gathering Is the Foundation of SoD Compliance
Most SoD failures start with incomplete requirements gathered before any tooling is configured—not with weak tools.
Traditional discovery (interviews, workshops, spreadsheets passed between stakeholders) introduces predictable gaps:
- Finance and HR define "contractor" differently, creating inconsistent SoD treatment
- Security and IT disagree on who approves privileged access
- Role hierarchies end up incomplete because nobody owned the full picture
- Conflicting role combinations, exception rules, and risk levels get documented inconsistently — or not at all
Identity CoAnalyst closes that gap. Instead of scheduled interviews, it uses guided, practitioner-built questionnaires with over 500 questions across 11 IAM, IGA, and PAM domains to capture SoD requirements directly from stakeholders, asynchronously.
The platform's Access Certifications domain (roughly 50 questions) covers SoD policy, conflicting role combinations, exception handling, and risk levels with conditional branching.
When an answer implies a potential conflict, follow-up questions adapt automatically rather than following a rigid checklist. Cross-stakeholder contradiction detection flags disagreements (such as finance and HR defining "contractor" differently) before they become documentation gaps.
Generated requirements go beyond a simple rule list. They capture:
- Regulatory drivers (for example, SOX Section 404)
- Conflicting roles and enforcement methods
- Exception approvers and duration limits
- Audit-trail details such as retention periods
Auditors get documentation built to be audit-ready from day one, not a spreadsheet they have to interpret.
Traditional SoD discovery commonly runs 12+ weeks of meetings and email threads. Identity CoAnalyst's structured approach compresses that same discovery into under 10 days, and audit preparation can shrink from 4–6 weeks to as little as 3 days.
Frequently Asked Questions
What is segregation of duties in identity and access management?
SoD in IAM is a control that splits conflicting access or responsibilities across different identities to prevent fraud and error. It ensures no single user or account can both perform and conceal a sensitive action.
What are some examples of segregation of duties in identity and access management?
Common examples include vendor creation versus payment approval, access provisioning versus approval, and code deployment versus change approval. Each pairs an initiating action with an independent check.
Who is responsible for segregation of duties in identity and access management?
Responsibility is shared. Compliance officers set regulatory scope, IAM/IGA teams build enforcement rules, application owners know process-level conflicts, and auditors validate the evidence.
What are the principles of segregation of duties in identity and access management?
The core principles are separating authorization, custody, reconciliation, and recordkeeping. No single identity should hold two incompatible duties over the same asset.
How is SoD different from least privilege?
Least privilege limits how much access one identity has. SoD limits which combinations of access that identity can hold, even if each individual permission looks minimal on its own.
Can SoD controls be automated?
Yes. IGA and IAM platforms can automate SoD detection through conflict matrices, prevention through request-time blocking, and remediation through periodic access certifications and monitoring.
