Segregation of Duties (SoD) Guide

Segregation of duties (SoD) stops one person, or one identity, from completing a sensitive process end to end on their own. The person who creates a supplier should not also approve payments to it, and the developer who writes code should not deploy it to production without someone else reviewing it. SoD is a core control for fraud prevention and financial reporting, and auditors test it closely. It now matters just as much for automation: service accounts, RPA bots, CI/CD pipelines and AI agents that can both initiate and approve an action break SoD as surely as a person with too many roles. This guide is for identity governance, internal audit and platform teams who need to define, prevent, detect and manage SoD conflicts across people and non-human identities.

Key takeaways

• Start from business risk: define what could go wrong in each process, then map the conflicting functions to the permissions that grant them in every system, not only the ERP.
• Prevent first, detect always: build conflict checks into role design and access requests, and analyse current access and transaction logs for the conflicts that still get through.
• Treat accepted conflicts as temporary: every exception needs a named risk owner, a compensating control that someone actually performs, and an expiry date.
• Apply the same rules to machines: an integration user, bot or pipeline that can create and approve the same transaction is a conflict, whoever wrote the code.
• Never let an AI agent approve its own work: high-impact actions need a separate human or policy decision enforced outside the agent, because instructions are not permissions.

Why segregation of duties matters

NIST SP 800-53 Rev. 5 control AC-5 (Separation of Duties) requires organisations to identify and document the duties of individuals that require separation, and to define system access authorisations that support it. Its discussion explains the purpose: separation of duties "addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion." In other words, a single dishonest or compromised identity should not be enough; a fraud or a destructive change should need at least two parties acting together.

The same AC-5 discussion makes three points that shape a good programme:

• It covers support functions, not only business ones: system support should be carried out by different individuals, and security staff who administer access control should not also administer audit functions.
• Conflicts span systems: because violations "can span systems and application domains", the whole estate has to be considered, not one application at a time.
• It is enforced through identity controls: account management (AC-2), access enforcement (AC-3) and identity management (IA-2, IA-4, IA-12).

NIST CSF 2.0 builds the principle into outcome PR.AA-05: access permissions, entitlements and authorisations are defined in a policy, managed, enforced and reviewed, and "incorporate the principles of least privilege and separation of duties." ISO/IEC 27001:2022 Annex A has a dedicated control, 5.3 Segregation of duties. For financial reporting, the COSO Internal Control - Integrated Framework, which COSO describes as the most widely used internal control framework in the US, is the usual basis for management's assessment under Section 404 of the Sarbanes-Oxley Act. See the SOX ITGC Guide.

Building an SoD ruleset

A ruleset is the list of function pairs that must not sit with the same identity, together with the technical permissions that grant each function. Without one, conflict analysis is guesswork. Build it in five steps:

1. Identify sensitive processes: procure-to-pay, order-to-cash, payroll, financial close, treasury, user administration, change to production and cloud administration.
2. Define conflicting functions: for example, "create or modify vendor" conflicts with "approve payment"; "develop code" conflicts with "deploy to production"; "administer access" conflicts with "administer audit logs".
3. Map functions to permissions in each application: transaction codes, roles, groups, API scopes, cloud IAM actions, repository permissions and admin rights. One function often needs several permissions, and the same function may exist in more than one system.
4. Rate each conflict by risk, considering financial impact, fraud potential, data sensitivity and whether the action can be reversed.
5. Agree ownership of the ruleset with finance, internal audit, security and application owners, and record who can change it.

What each rule should record

Each rule should hold a unique ID, the business risk in one sentence, function A and function B, the permissions behind each function per system, a risk rating, the rule owner, and the approved mitigating controls if the conflict is ever accepted. Include cross-system rules: a user who can change bank details in the HR system and release payments in the treasury platform holds a conflict that no single-application analysis will find.

Keep the ruleset current

Review the ruleset when processes, applications or roles change. New SaaS applications, cloud accounts and automation are the usual blind spots. See the Role Mining and Role Design Guide.

Example conflicts

Use these common conflicts as a starting point and adapt them to your own systems.

Preventive controls

Conflict-free role design

Design business and technical roles so that no single role contains both sides of a rule, and test new roles against the ruleset before they are published. CIS Safeguard 6.8 asks organisations to define and maintain role-based access control by documenting the access rights each role needs to carry out its duties, and to review it at least annually. See the Authorisation Models Guide.

Checks at access request

Evaluate every request against the ruleset and the requester's existing access before approval. Block high-risk conflicts, and route lower-risk ones to a second approver who sees the conflict explained in business terms. Apply the same check to movers, whose role changes often add access without removing the old. See the Joiner-Mover-Leaver Guide.

Enforcement in the workflow

Where the application supports it, make the system refuse self-approval: the approver of a payment, journal or pull request must be a different identity from the initiator. For the most sensitive actions, SP 800-53 offers dual authorisation (AC-3(2) for privileged commands and other defined actions, CM-5(4) for changes to defined system components). NIST describes dual authorisation, also known as two-person control, as reducing insider threat risk by requiring the approval of two authorised individuals, and suggests rotating those duties to reduce collusion.

Time-bound elevation

Use just-in-time elevation so that conflicting rights are not held at the same time. A user who occasionally needs to post journals can request that right for a short window, with the approval and session logged. See the JIT Access Guide and the Privileged Access Management Guide.

Separate privileged accounts

Administrators should use a dedicated privileged account for admin work and a standard account for everything else (CIS Safeguard 5.4, SP 800-53 AC-6(2)). This keeps privileged actions attributable and makes conflict analysis on admin accounts meaningful.

Detective controls

Detective controls find the conflicts prevention misses, in what identities hold and in what they actually did.

• Access analysis: run the ruleset against current entitlements across and within applications, on a schedule and after major changes.
• Transaction analysis: review logs for cases where one identity performed both sides of a conflict, for example created a vendor and released a payment to it.
• Access reviews: include open conflicts in certifications with a plain explanation, so reviewers can remove one side or confirm a mitigation. See the Access Reviews Guide.
• Audit log protection: keep audit administration separate from the people and service accounts being audited, in line with the AC-5 discussion.

Feed these signals into continuous control monitoring. See the Audit Evidence and Continuous Controls Monitoring Guide.

Mitigating controls

Small teams and legacy applications sometimes make a conflict impossible to remove. Accepting one is a risk decision. Where a conflict is accepted:

• Document it: the rule ID, the business reason, the identity, the risk owner and the date it expires.
• Apply a compensating control: one that would detect misuse of the specific conflict, performed by someone independent of the person holding it.
• Test it: keep evidence that the compensating control ran and that exceptions were followed up.
• Review it: re-approve or remove the exception at expiry, and whenever the person or process changes.

Emergency access is the most common accepted conflict: keep it rare and review every use. See the Break-Glass Account Guide.

SoD for non-human identities and AI agents

Machine identities now do much of the work SoD was designed around, often with broader rights and less oversight. SP 800-53 already points this way: AC-6 applies least privilege to users "or processes acting on behalf of users".

Service accounts and integrations

One service account that can both create vendors and post payments turns a single leaked credential into a fraud path. Split integrations into separate identities per function, give each an accountable owner, and include them in conflict analysis. The OWASP Non-Human Identities Top 10 (2025) describes the underlying risks as NHI5 Overprivileged NHI and NHI9 NHI Reuse, where one identity shared across components gives an attacker access to all of them. See the Service Account Security Guide and the NHI Ownership Guide.

Shared and human-used accounts

Shared admin accounts make SoD impossible to verify, because the logs cannot show which person acted. OWASP NHI10 Human Use of NHI warns that administrators using service accounts for manual tasks causes a lack of auditing and accountability, with activity that cannot be told apart from automation. Replace shared accounts with individual accountable access and alert on interactive use of service accounts.

RPA bots

Bots should follow the same SoD rules as the people whose work they automate; an accounts payable bot that can also approve payments has simply moved the conflict to a machine.

CI/CD pipelines

Enforce review by someone other than the author before deployment, protect production deployment environments with required reviewers, and stop automation from approving its own changes. GitHub's secure use guidance for Actions notes that allowing workflows or other automation to create or approve pull requests "could be a security risk if the pull request is merged without proper oversight", and provides a setting to prevent it. OWASP lists Insufficient Flow Control Mechanisms as CICD-SEC-1 in its Top 10 CI/CD Security Risks. See the CI/CD Pipeline Identity Security Guide.

AI agents

AI agents that can prepare and execute actions must not approve their own work. OWASP LLM06:2025 Excessive Agency lists an application that "fails to independently verify and approve high-impact actions" as a core example, and recommends human-in-the-loop approval for high-impact actions and complete mediation, meaning authorisation is enforced in downstream systems "rather than relying on an LLM to decide if an action is allowed or not." The Replit AI Agent Database Deletion 2025 shows why: the agent deleted a live production database during a declared code and action freeze, against repeated instructions, because it held direct access to production from the development workflow. Replit's response included automatic separation of development and production databases.

For agents, apply SoD at three points: give the agent an identity separate from the human it works for, so actions are attributable; split read, prepare and execute permissions so the execute step needs an approval token the agent cannot mint; and keep the approver independent of the agent's own reasoning. See the AI Agent Authorisation Guide and the Identity Governance for AI Agents Guide.

Framework mapping

Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls safeguard text and the OWASP lists cited below. ISO/IEC 27001:2022 Annex A control names come from a published Annex A index, as the ISO text itself is paywalled. This is an indicative NHI Mgmt Group alignment, not an official crosswalk.

For a wider view of how these frameworks relate, see the Control Mapping Guide.

Common failure patterns

• ERP-only rulesets: rules defined for the finance system alone, ignoring cloud consoles, SaaS applications, code repositories and identity administration, where many of today's conflicts sit.
• No cross-system view: each application is analysed separately, so a user who changes bank details in one system and releases payments in another is never flagged.
• Mitigations on paper only: conflicts are detected and accepted, but the compensating control is never performed or evidenced, and exceptions never expire.
• Firefighter access as a workaround: emergency access used routinely for day-to-day tasks, bypassing SoD with no after-the-fact review.
• All-powerful integration users: service accounts with every permission in a finance system, shared across several integrations and owned by no one.
• Automation that approves itself: pipelines or bots allowed to create and approve their own pull requests or transactions.
• Agents trusted to follow instructions: AI agents given standing write access to production on the assumption that a prompt will stop them, as the Replit AI Agent Database Deletion 2025 showed it will not.

Metrics that show progress

Report these to the ruleset owners and internal audit. See the Identity Security Metrics Guide for how to present identity metrics.

Implementation roadmap

To place this work within a wider governance programme, see the Identity Governance Maturity Model.

Practitioner checklist

• Build an SoD ruleset from business risks, with each rule mapped to the permissions that grant it in every application.
• Include cross-system rules, support functions and the separation of access administration from audit administration.
• Test roles against the ruleset before publishing them, and review roles at least annually.
• Check access requests and role changes against the ruleset and existing access before approval.
• Make applications refuse self-approval, and use dual authorisation for the most sensitive actions.
• Use just-in-time elevation and separate privileged accounts so conflicting rights are not held at the same time.
• Detect conflicts in current access and in transaction logs, and include them in access reviews.
• Document, test and expire every accepted conflict, with a named risk owner and evidence of the compensating control.
• Apply the ruleset to service accounts, RPA bots and pipelines, with one identity per function and an accountable owner.
• Require an independent human or policy approval, enforced outside the agent, for high-impact AI agent actions.
• Control emergency access and review every use.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• ISMS.online: ISO/IEC 27001:2022 Annex A Controls
• CIS: CIS Critical Security Controls v8.1
• CIS: Controls Assessment Specification, Safeguard 6.8 Define and Maintain Role-Based Access Control
• COSO: Internal Control - Integrated Framework
• OWASP: Top 10 Non-Human Identities Risks 2025
• OWASP: LLM06:2025 Excessive Agency
• OWASP: Top 10 CI/CD Security Risks
• GitHub Docs: Secure use reference for GitHub Actions

Related NHI Mgmt Group resources: IAM and IGA Basics · IGA Buyer's Guide · Privileged Access Management Guide · Authorisation Models Guide · Cloud PAM and CIEM Guide