Segregation of duties (SoD) prevents one person, or one identity, from being able to complete a sensitive process end to end on their own. The person who creates a supplier should not also approve payments to it; the developer who writes code should not deploy it to production unreviewed. SoD is a core control for fraud prevention and financial reporting, and auditors test it closely. It is also becoming relevant to automation: service accounts, bots and AI agents that can both initiate and approve actions break SoD just as surely as a person with too many roles. This guide explains how to define, detect, prevent and manage SoD conflicts across people and non-human identities.
Key takeaways
- Start from business risks (what could go wrong in a process), then map them to conflicting permissions in each system.
- Use preventive checks (at access request and role design) and detective checks (periodic analysis) together.
- Where conflicts cannot be removed, document mitigating controls and review them.
- Extend SoD to service accounts, RPA bots and AI agents. An agent that can both raise and approve a payment is a conflict.
Building an SoD ruleset
- Identify sensitive processes: procure-to-pay, order-to-cash, payroll, financial close, user administration, code to production.
- Define conflicting functions: for example, "create or modify vendor" conflicts with "approve payment"; "develop code" conflicts with "deploy to production".
- Map functions to permissions in each application: transactions, roles, API scopes and admin rights.
- Rate each conflict by risk, considering financial impact and fraud potential.
- Agree ownership of the ruleset with finance, internal audit and application owners.
Example conflicts
| Process | Function A | Conflicts with function B |
|---|---|---|
| Procure-to-pay | Create or change vendor bank details | Approve or release payments |
| Payroll | Maintain employee pay data | Run and approve payroll |
| Financial close | Post journal entries | Approve journal entries |
| Identity administration | Request access | Approve or provision the same access |
| Software delivery | Commit code | Approve own pull request and deploy to production |
| Cloud administration | Create IAM roles and policies | Assume those roles in production without review |
Preventive controls
- Design roles that do not contain conflicts. See the Role Mining and Role Design Guide.
- Check access requests against the ruleset before approval; block or require extra approval for conflicts.
- Build SoD into workflows: require a different person to approve, enforced by the application.
- Use just-in-time elevation for sensitive functions, so conflicting rights are not held at the same time.
Detective controls
- Analyse current access periodically for conflicts across and within applications.
- Review transaction logs for cases where one identity performed conflicting actions.
- Include SoD conflicts in access reviews with clear explanations. See the Access Reviews Guide.
Mitigating controls
Small teams sometimes cannot avoid conflicts. Where a conflict is accepted:
- Document the business reason and risk owner.
- Apply compensating controls, such as independent review of transactions, reconciliations or monitoring reports.
- Set an expiry and review regularly.
SoD for non-human identities and AI agents
- Service accounts and integrations often hold broad rights across a process, for example an integration user that can both create vendors and post payments. Split them into separate identities per function.
- RPA bots should follow the same SoD rules as the people whose work they automate.
- Shared admin accounts used by several people make SoD impossible to verify; replace them with individual accountable access.
- AI agents that can prepare and execute actions must not approve their own work. Require a separate human or policy approval for high-impact actions. See the AI Agent Authorisation Guide.
- CI/CD pipelines should enforce review by someone other than the author before deployment. See the CI/CD Pipeline Identity Security Guide.
Common failure patterns
- Rulesets defined only for ERP, ignoring cloud, SaaS and identity administration.
- Conflicts detected but mitigations never documented or tested.
- Firefighter or emergency access used routinely, bypassing SoD.
- Integration users with every permission in a finance system.
Practitioner checklist
- Build an SoD ruleset from business risks, mapped to permissions in each application.
- Prevent conflicts in role design and access requests.
- Detect conflicts in current access and in transactions.
- Document, apply and review mitigating controls for accepted conflicts.
- Apply SoD rules to service accounts, RPA bots, AI agents and pipelines.
- Control and review emergency access use.
Standards and references
- COSO Internal Control – Integrated Framework
- PCAOB AS 2201: Audit of Internal Control over Financial Reporting
- NIST SP 800-53 Rev. 5 (AC-5 Separation of Duties)
- ISO/IEC 27001:2022 (segregation of duties)
Related NHI Mgmt Group resources: IAM and IGA Basics · IGA Buyer's Guide · Privileged Access Management Guide · Authorisation Models Guide
