Segregation of Duties

The segregation of duties requirement means you must prevent one person (or one system identity) from controlling an entire high-risk transaction end-to-end, and if you cannot separate roles, you must implement compensating controls that reduce fraud and error risk. Operationalize it by mapping “incompatible duties” per process, enforcing role-based access and approvals, and retaining audit-ready evidence of who can do what and why. ¹

Key takeaways:

• Define incompatible duty pairs per process (initiate, approve, execute, record, reconcile, administer access) and block combinations by design.
• Where separation is impractical, document the exception and implement compensating controls (independent review, logging, monitoring, post-transaction testing).
• Evidence wins exams: keep role matrices, access reviews, exception registers, approval logs, and control test results. ¹

Segregation of duties (SoD) is one of the fastest ways to reduce fraud opportunity and improve error detection because it breaks “single-person control” over critical workflows. COSO frames this as a management obligation: segregate incompatible duties, and when you cannot, select and develop alternative control activities. ¹ For a Compliance Officer, CCO, or GRC lead, the practical challenge is rarely understanding the concept. It’s translating it into enforceable access rules, approvals, and monitoring across finance, procurement, IT administration, third-party payments, and data changes.

This page is written to help you implement SoD quickly in a real operating environment: lean teams, shared service centers, system constraints, and urgent business demands. You’ll get a plain-English interpretation, who it applies to, a step-by-step build plan, the evidence package auditors expect, and a pragmatic execution plan. The emphasis is operational: you should be able to walk away with a role matrix structure, an exception process, and a control testing approach that stands up to internal audit and external assurance. ¹

Regulatory text

Requirement (COSO Principle 10 – Point of Focus): “Management segregates incompatible duties, and where segregation is not practical, management selects and develops alternative control activities.” ¹

What the operator must do

1. Identify “incompatible duties” within each material process (for example, payments, journal entries, third-party onboarding, refunds, revenue adjustments, master data changes). ¹
2. Design controls that prevent incompatible combinations through org structure, workflow approvals, and system permissions. ¹
3. When prevention is not feasible, implement compensating controls that provide equivalent risk reduction (independent review, monitoring, reconciliations, heightened logging, post-transaction testing). ¹
4. Maintain documented evidence that SoD exists, is enforced, and is monitored. ¹

Plain-English interpretation

SoD means no single person should be able to both create and complete a high-risk action without someone else’s involvement or an effective detective control catching issues quickly. Think in “transaction lifecycle” terms:

• Initiate (request a vendor, create a purchase order, set up a payee)
• Approve (authorize the vendor, approve the purchase, approve the payment)
• Execute (release the payment, post the journal entry)
• Record (update accounting records)
• Reconcile/Review (match bank statements, review exception reports)
• Administer (grant access, change workflows, modify master data)

If one identity can do too many of these for the same transaction type, your fraud and error exposure spikes. COSO allows exceptions, but only if you replace separation with alternative control activities that are credible and provable. ¹

Who it applies to

Entities: Any organization adopting or assessed against COSO internal control expectations, including public and private companies, nonprofits, and regulated entities that map their control environment to COSO. ¹

Operational contexts where SoD is examined heavily:

• Finance & accounting: AP/AR, journal entries, close, bank recs, credit notes/refunds.
• Procurement & third-party management: third-party onboarding, contracting, PO issuance, goods receipt, invoice approval, payment release.
• IT and security administration: identity and access management (IAM), privileged access, ERP configuration, audit log administration.
• Operations with cash-like value: gift cards, credits, refunds, rebates, commission adjustments.
• Small teams / startups: SoD is still expected; you just rely more on compensating controls and tight evidence. ¹

What you actually need to do (step-by-step)

Step 1: Set SoD scope and “material processes”

Create a scoped list of processes where a failure would cause material misstatement, significant loss, regulatory exposure, or reputational harm. Use your risk assessment and financial statement line items as inputs. ¹

Deliverable: SoD scope memo + process inventory.

Step 2: Define incompatible duty pairs (the “conflict rules”)

Build a conflict rule set that is easy to enforce. Start with these common incompatibilities:

Process area	Incompatible duties you should separate	Why it matters
AP / disbursements	Create/modify vendor AND approve vendor	Prevents fake vendor setup
AP / disbursements	Enter invoice AND approve invoice	Prevents self-approval
Payments	Approve payment AND release/run payment	Prevents unauthorized disbursement
GL	Create journal entry AND approve/post journal entry	Prevents concealment via entries
Master data	Change bank details AND approve change	Prevents diversion of funds
IAM	Provision access AND approve access	Prevents unauthorized privilege gain
Reconciliation	Prepare reconciliation AND approve/review reconciliation	Prevents falsified recs

Deliverable: SoD rulebook (conflict matrix) tied to each in-scope process. ¹

Step 3: Translate rules into roles and system permissions

SoD fails most often at translation: the policy says “separate,” but the ERP and ticketing system allow it.

• Define standard roles (AP Processor, AP Approver, Payment Release, Vendor Master Admin, GL Preparer, GL Approver, IAM Provisioner, IAM Approver).
• Map roles to each application that can execute the duty (ERP, banking portal, procurement suite, HRIS, IAM, ticketing).
• Use RBAC to prevent conflicts where possible; reserve “break-glass” access for emergencies with strict logging and time-bound approvals.

Deliverables: Role catalog, application permission mapping, and an SoD access control matrix. ¹

Step 4: Implement a documented SoD exception process (because exceptions will happen)

COSO explicitly anticipates situations where segregation is not practical. Your job is to make exceptions controlled, visible, and reviewed. ¹

Minimum exception workflow:

1. Requestor documents the business reason SoD cannot be met.
2. Compliance/Finance Control Owner assesses risk and required compensating controls.
3. Independent approver (not in the reporting line of the requestor) approves the exception.
4. Exception is time-bound and reviewed for renewal.
5. All activity under the exception is subject to enhanced monitoring.

Deliverables: SoD exception register + approvals + compensating control design. ¹

Step 5: Build compensating controls that auditors will accept

Compensating controls should be independent, timely, and evidenced. Examples:

• Independent daily/weekly review of payment runs by someone outside AP processing.
• Automated change reports for vendor bank details with review sign-off.
• Post-transaction sampling of journal entries created and posted by the same user (if system constraints exist).
• Centralized log retention and alerting for privileged actions (role changes, workflow overrides).
• Dual control for high-risk changes (two-person approval in the ticketing workflow).

Deliverables: Control narratives + evidence templates (review checklists, report extracts, sign-off records). ¹

Step 6: Operationalize monitoring and testing

SoD is not “set and forget.” You need:

• A recurring access review focused on SoD conflicts (especially privileged and finance roles).
• Exception register review and closure evidence.
• Control testing that validates both design and operation (tickets, approvals, logs, reconciliations). ¹

Practical tip: If you can’t automate conflict detection, start with a short list of “crown jewel” conflicts (payments release + vendor bank change + invoice approval) and monitor those first.

Required evidence and artifacts to retain

Auditors and examiners typically want to see that SoD is designed, implemented, and operating. Build an evidence binder that includes:

• SoD policy/standard (definition of incompatible duties, scope, responsibilities). ¹
• Process narratives / flowcharts identifying where SoD is enforced in workflow. ¹
• SoD conflict matrix (duty pairs and prohibited combinations). ¹
• Role catalog and application access matrix (roles to permissions to systems). ¹
• User access listings (export from ERP/IAM/banking portal) supporting periodic review.
• Access review evidence (review sign-off, identified conflicts, remediation tickets).
• Exception register with approvals, expiration, and compensating controls. ¹
• Compensating control evidence (review checklists, exception report sign-offs, log review artifacts).
• Remediation tracking (tickets, change approvals, before/after access snapshots).

Common exam/audit questions and hangups

Expect these, and pre-answer them in your documentation:

1. “Show me the incompatible duty definition for this process.” If you only have generic language, auditors will push for specificity. ¹
2. “Prove the system enforces the separation.” Screenshots help, but exports of role assignments plus workflow configuration evidence is stronger.
3. “Who reviewed conflicts, and what changed afterward?” Auditors want closure, not just detection.
4. “Why is this exception acceptable?” You need the rationale and the compensating control, plus evidence it ran.
5. “Are privileged administrators subject to SoD?” Yes. SoD failures in admin roles can bypass every other control. ¹

Frequent implementation mistakes and how to avoid them

• Mistake: SoD exists only in a policy. Fix: translate policy into application roles, workflows, and monitoring reports. ¹
• Mistake: “Approvals” are not independent. Fix: define independence (separate reporting line or separate function) for each key approval.
• Mistake: Exceptions never expire. Fix: require expiration and renewal approvals; track in an exception register. ¹
• Mistake: Shared accounts and generic logins. Fix: prohibit them for in-scope processes; require named accounts to support traceability.
• Mistake: Over-reliance on manual controls without evidence. Fix: standardize review templates and require retention in a controlled repository.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not cite specific actions. Practically, SoD gaps raise risk in three predictable ways: (1) increased fraud opportunity, (2) higher likelihood of undetected error, and (3) weakened auditability because accountability is blurred. COSO’s framing makes SoD a baseline expectation, so recurring SoD conflicts without compensating controls often become control deficiencies in internal and external assessments. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Identify in-scope processes and systems (ERP, banking portals, procurement, IAM).
• Draft SoD conflict rules for each process and validate with process owners.
• Pull current access lists for high-risk roles and identify obvious conflicts.
• Stand up an SoD exception register and interim approval workflow. ¹

Days 31–60 (implement and evidence)

• Implement RBAC changes for the top conflicts (payment release, vendor master changes, JE approval).
• Configure workflows to enforce approvals and restrict overrides.
• Define compensating controls for unavoidable exceptions and run the first review cycle.
• Create an audit-ready evidence folder structure and retention checklist. ¹

Days 61–90 (operationalize and test)

• Launch recurring SoD access reviews (focus on privileged and finance roles).
• Test control operation with samples: approvals, tickets, change reports, reconciliations.
• Remediate systemic issues (role design flaws, break-glass misuse, incomplete logs).
• Report SoD KPIs qualitatively to leadership: conflicts identified, conflicts remediated, exceptions active, and overdue reviews. ¹

Where Daydream fits naturally: Daydream helps teams centralize SoD evidence (matrices, access reviews, exception registers, and compensating-control proof) so you can answer audit requests quickly and show consistent operation over time. Keep the control in your systems; keep the proof and workflow discipline in one place.

Frequently Asked Questions

What counts as “incompatible duties” for segregation of duties?

Duties are incompatible when one person can initiate and complete a transaction without independent approval or review, or can both create and conceal an error. Define incompatibilities per process, then enforce them through roles and workflows. ¹

We’re a small team. Is SoD still required?

Yes, but COSO allows alternatives when segregation is not practical. Document the constraint, add compensating controls (independent review, monitoring, reconciliations), and retain evidence that those controls ran. ¹

Are system administrators in scope for SoD?

Yes. Privileged access can bypass business controls, so you need separation between granting access, approving access, and reviewing privileged activity where feasible, or compensating controls when it is not. ¹

What evidence is most persuasive in an audit?

A clear SoD matrix tied to systems and processes, exports of actual access, documented reviews with remediation actions, and an exception register with compensating-control evidence. Auditors want proof of operation, not only design. ¹

How do we handle emergency access (“break-glass”) without failing SoD?

Require time-bound access, documented approval, strong logging, and after-the-fact independent review of actions taken under break-glass. Record each event in the exception register with closure evidence. ¹

What’s the fastest way to find SoD conflicts across multiple tools?

Start with your highest-risk processes and pull role/user exports from each system, then compare against a short list of critical conflicts. If correlation is hard, prioritize privileged roles and payment capabilities first. ¹

Footnotes

1. COSO IC-IF (2013)