1. Home
  2. Resources
  3. Segregation of Duties: A Guide for IT and Finance Teams
IT Infrastructure

Segregation of Duties: A Guide for IT and Finance Teams

Roman Burdiuzha
Roman Burdiuzha
Cloud Architecture Expert Co-founder & CTO of Gart
Segregation of Duties a Guide for IT & Finance Teams

Segregation of duties — often shortened to SoD, and sometimes searched as “segregation of duties IT” when the conflict lives in a system rather than a paper approval — is the control principle that no single person should be able to initiate, approve, execute, and record the same transaction end to end. It sounds like an accounting textbook rule until you find it in production: the same engineer who wrote a database migration also has the production credentials to run it unreviewed, or the same finance user who creates a new vendor in the ERP also has the rights to approve that vendor’s first invoice. Gart’s compliance audit team flags a segregation-of-duties gap in almost every IT-and-finance-systems review — not because anyone did anything wrong, but because access accumulated faster than anyone redesigned the controls around it.

This guide is written for the two teams that actually own the problem together: IT and security teams who control system access, and finance and controllership teams who own the transactions that access touches. It covers what segregation of duties means in practice, real examples from both finance and IT, how the major frameworks (SOX, SOC 2, ISO 27001, NIS2) treat it, and how to implement it — including what to do when a small team genuinely can’t segregate everything.

Every segregation-of-duties framework — SOX, COSO, SOC 2, ISO 27001 — reduces to this same triangle: authorization, execution or custody, and recording or reconciliation should sit with different people.

Every segregation-of-duties framework — SOX, COSO, SOC 2, ISO 27001 — reduces to this same triangle: authorization, execution or custody, and recording or reconciliation should sit with different people.

What Is Segregation of Duties?

Segregation of duties (also called separation of duties) is an internal control principle that splits a business-critical process across at least two people so that no one individual can both create and conceal an error or a fraudulent transaction. The classic breakdown, going back to COSO’s Internal Control — Integrated Framework, splits any transaction into three incompatible functions: authorization (approving that something should happen), custody or execution (carrying it out or holding the asset), and recording or reconciliation (logging it and later verifying it happened correctly). COSO treats segregation of duties as one of the core control activities built into well-designed processes — and explicitly notes that where it isn’t practical, management needs to select an alternative, or “compensating,” control instead.

In finance, this triangle is familiar: the person who creates a vendor record shouldn’t be the person who approves that vendor’s payment. In IT, the same triangle applies to systems rather than paper — the person who writes and merges code shouldn’t also be the only person who can push it to production unreviewed, and the person who grants a user’s access shouldn’t be the same person who signs off on that access during an audit. Both are the identical control, applied to a different kind of transaction.

Why Segregation of Duties Matters for IT and Finance Teams

Segregation of duties doesn’t assume anyone on the team is dishonest. It assumes that concentrated, unreviewed control is a risk regardless of intent — a single point of failure that can produce an honest mistake, a hidden error, or, in the worst case, fraud that goes undetected because the person who could catch it is the same person who created it. That risk is not theoretical: the ACFE’s 2024 Report to the Nations found that a lack of internal controls was cited as a contributing weakness in 32% of investigated occupational fraud cases, with a median loss of $145,000 per case and a median detection time of a full year — the exact window an unreviewed, unsegregated process gives an error or a fraudulent transaction to compound before anyone notices.

⚠️ The risk usually isn’t malicious — it’s structural
Most segregation-of-duties gaps we find in audits weren’t created on purpose. A small team member picked up a second responsibility during a hiring gap, an ERP role template was cloned instead of scoped, or a CI/CD pipeline shipped with one broad “admin” role because nobody had time to design three narrower ones. The gap persists not because anyone is exploiting it, but because nobody owns closing it.

For IT specifically, segregation of duties is also a named control family inside NIST SP 800-53’s AC-5 control, which frames it as reducing “the potential for abuse of authorized privileges” and helping prevent malicious activity without requiring collusion between multiple people — a useful reminder that SoD raises the bar even against a single bad actor, since it forces coordination with someone else to override it.

Segregation of Duties in IT: Examples and a Conflict Matrix

A segregation-of-duties matrix is simply a table that lists incompatible role pairings — the combinations that should never sit with one person — so that access reviews and role design have a concrete standard to check against, rather than a vague sense that “this seems like a lot of access.” The table below covers the pairings we see most often on both the finance and the IT segregation of duties side of an engagement:

DomainIncompatible pairingWhy it’s a risk if combined
Finance — procure to payCreating a vendor record + approving that vendor’s invoiceEnables a fictitious vendor to be created and paid without independent review
Finance — journal entriesPreparing a journal entry + posting/approving itRemoves the second set of eyes that catches misclassified or manipulated entries before they hit the ledger
Finance — payrollSetting payroll amounts + releasing the payroll runOne person could set and pay an inflated or fictitious amount with no independent check
IT — software deliveryMerging code + deploying to productionUnreviewed code can reach production without a second engineer verifying the change
IT — identity & accessProvisioning user access + approving that same access in a reviewSelf-approved access removes the independent check that access reviews exist to provide
IT — security administrationAdministering security controls + administering the audit logs that record their useAllows evidence of misuse to be altered or deleted by the same person who could misuse the control
Segregation of Duties in IT: Examples and a Conflict Matrix

The pattern across every row is the same: whoever can create or execute a transaction should not also be the one who can authorize it or verify it after the fact. Gart’s RBAC in CI/CD pipelines guide goes deeper on the IT delivery row specifically — including how to enforce a “four-eyes” production-deployment rule at the platform level rather than relying on convention — if that’s the conflict you’re solving for first.

How Segregation of Duties Maps to SOX, SOC 2, ISO 27001, and NIS2

Segregation of duties shows up, in some form, in nearly every major compliance framework — but none of them hand you a ready-made matrix. Each one expects the organization to define its own incompatible-duty pairs based on its actual processes and systems, then produce evidence that those pairs are enforced or compensated for.

FrameworkHow it treats segregation of duties
SOX Section 404Doesn’t name SoD as a specific rule, but auditors treat inadequate segregation of duties as one of the most common drivers of an internal-control-over-financial-reporting material weakness, especially in smaller finance teams where one person handles multiple stages of a transaction
SOC 2Trust Services Criteria CC5.1-CC6 expect logical access and control activities to be assigned so that incompatible functions — like access provisioning and access approval — aren’t concentrated in one role
ISO/IEC 27001Annex A control 5.3, “Segregation of duties,” requires conflicting duties and areas of responsibility to be separated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets
NIS2 (EU)Doesn’t define SoD directly but requires access control and identity management as baseline cyber-hygiene measures for in-scope entities, typically implemented by mapping to ISO 27001/27002 controls — see Gart’s NIS2 compliance overview for how that mapping usually works in practice
How Segregation of Duties Maps to SOX, SOC 2, ISO 27001, and NIS2

The consistent thread across all four: whatever the specific clause number, an auditor doesn’t want a policy document that says duties are segregated — they want to see the actual role design, the access that enforces it, and, where a gap exists, a documented compensating control. That evidence bar is exactly what Gart’s SOC 2 preparation guide and ISO 27001 overview walk through in more detail for each framework individually.

How to Implement Segregation of Duties Without Slowing Teams Down

The biggest objection to segregation of duties, especially from smaller IT and finance teams, is that it sounds like it doubles the work. In practice, most of the friction comes from bolting SoD onto an existing process as an afterthought rather than designing roles around it from the start:

  1. Inventory the transactions that actually carry risk. Start with the processes where an error or a fraudulent action would matter — vendor payments, payroll, journal entries, production deployments, privileged access grants — rather than trying to segregate every low-stakes task on day one.
  2. Map who currently touches each stage of those transactions. For each risky process, list who can authorize it, who can execute it, and who records or reconciles it. This is where most conflicts surface immediately — usually in ERP role templates and CI/CD permissions that were cloned rather than scoped.
  3. Build a segregation-of-duties matrix for your own systems. Use the table above as a starting structure, then add the specific role names from your ERP, identity provider, and deployment pipeline so the matrix maps to real, checkable permissions instead of abstract functions.
  4. Enforce the split in the system, not just the policy. A written policy that says “the same person shouldn’t approve their own payments” is easy to violate under deadline pressure. Role-based access control, mandatory second approvals, and branch-protection rules that block self-merging enforce the same rule automatically.
  5. Log every override. Emergencies happen — someone occasionally needs to act outside their normal role. The control that matters isn’t preventing every exception; it’s making sure every exception is logged, time-boxed, and reviewed afterward.
  6. Review the matrix against actual access on a recurring cycle. Role design decays as people change jobs and systems change permissions models. A segregation-of-duties matrix is only as good as the last time someone checked it against reality — which is exactly what a recurring access review process is built to catch.

When You Can’t Fully Segregate: Compensating Controls

Small teams run into a real constraint: with three people on finance or two engineers on-call, perfect segregation of duties across every transaction isn’t always physically possible. Frameworks account for this — COSO explicitly allows an alternative control where segregation “is not practical” — but the alternative has to be a genuine, documented control, not silence. Common compensating controls include:

  • Independent post-transaction review. If one person must both create and approve a transaction, a second person — even someone outside the immediate process, like a controller or an engineering lead — reviews a sample of those transactions after the fact.
  • Mandatory dual authorization above a threshold. Full segregation on every transaction may not be feasible, but requiring a second approver above a defined dollar amount or a defined access sensitivity level narrows the exposure to where it matters most.
  • System-enforced logging with independent audit access. If the same person must execute and record a transaction, at minimum the log of that action should be tamper-evident and reviewable by someone who wasn’t involved in creating it.
  • Time-boxed exception access. Temporary elevated access — for an incident, a migration, a small-team gap — should expire automatically and generate a review, rather than becoming permanent standing access nobody revisits.

The goal of a compensating control isn’t to make the gap disappear on paper — it’s to make sure the gap can’t be exploited or overlooked silently, which is the same standard an auditor applies when deciding whether a documented workaround is acceptable or a genuine deficiency.

Common Segregation of Duties Mistakes

Most segregation-of-duties programs don’t fail because the concept is misunderstood — they fail on a handful of predictable execution gaps:

  • Treating it as a one-time project instead of an ongoing control. A segregation-of-duties matrix built for one audit and never revisited drifts out of sync with reality within months, as roles, systems, and org charts change.
  • Designing the matrix around job titles instead of actual system permissions. Two people with the same title can hold very different access in an ERP or cloud console. The matrix has to be checked against real entitlements, not assumed from a title.
  • Only looking at finance systems and missing IT. Segregation of duties in IT security — who can grant access, who can approve it, who can audit it — carries the same risk as a finance conflict, but it’s frequently left out of the review because it’s owned by a different team.
  • No compensating control when segregation genuinely isn’t possible. Silently accepting a gap in a small team, without an independent review or a logged exception process, is the version of the mistake auditors flag as a material weakness rather than an accepted limitation.
IT Audit & Compliance Services

Not sure where your segregation-of-duties gaps actually are?

Gart Solutions audits your finance and IT systems together — ERP roles, identity and access management, and CI/CD permissions — builds a segregation-of-duties matrix mapped to your real access, and designs compensating controls where full segregation isn’t feasible, so your next SOX, SOC 2, ISO 27001, or NIS2 review holds up under scrutiny.

IT Audit Services Compliance Audit Security Audit Infrastructure Audit DevSecOps Consulting Access Governance
Talk to an audit specialist Explore our compliance audit services →

You might also like

Roman Burdiuzha

Roman Burdiuzha

Co-founder & CTO, Gart Solutions · Cloud Architecture Expert

Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.

Roman Burdiuzha
Roman Burdiuzha
Cloud Architecture Expert Co-founder & CTO of Gart

FAQ

What is segregation of duties?

Segregation of duties (SoD) is an internal control principle that splits a transaction across at least two people so that no single individual can authorize, execute, and record the same action end to end. It's built on three incompatible functions — authorization, execution or custody, and recording or reconciliation — that should sit with different people or roles.

Why is segregation of duties important in IT and finance?

It reduces the risk that an error or a fraudulent action goes undetected because the same person who created it also had the ability to hide it. The ACFE's 2024 Report to the Nations found a lack of internal controls was a contributing weakness in 32% of occupational fraud cases, with a median loss of $145,000 and a median detection time of 12 months — the exact gap segregation of duties is designed to close.

What are common examples of segregation of duties violations?

In finance: the same person creating a vendor record and approving that vendor's invoice, or preparing and posting the same journal entry. In IT: the same engineer merging code and deploying it to production, or the same admin provisioning user access and approving that access in a review. In both cases, one person spans two functions that should be independent.

How do you build a segregation of duties matrix?

List the transactions that carry real risk — payments, payroll, journal entries, production deployments, privileged access grants — then map who can authorize, execute, and record each one across your actual ERP, identity provider, and deployment systems. Flag any person or role appearing in more than one function for the same transaction as a conflict, then enforce the split through system permissions rather than policy alone.

Which compliance frameworks require segregation of duties?

SOX Section 404 treats inadequate segregation of duties as a common driver of internal-control material weaknesses. SOC 2's Trust Services Criteria (CC5.1-CC6) expect incompatible functions to be separated. ISO/IEC 27001 Annex A control 5.3 explicitly requires segregation of conflicting duties. NIS2 in the EU requires access control and identity management as baseline measures, typically implemented by mapping to ISO 27001/27002 controls.

What do you do when a small team can't fully segregate duties?

Use a compensating control instead of leaving the gap undocumented: an independent post-transaction review, mandatory dual authorization above a risk threshold, tamper-evident logging reviewed by someone outside the process, or time-boxed exception access that expires and triggers a review. Auditors generally accept a documented compensating control; they flag a silent, unaddressed gap as a deficiency.

How does Gart Solutions help with segregation of duties?

Gart's IT and compliance audit teams review finance systems (ERP, payment approval, journal entry workflows) and IT systems (identity and access management, CI/CD permissions) together, build a segregation-of-duties matrix mapped to real access, and design compensating controls or automated enforcement where full segregation isn't feasible — so the resulting evidence holds up under SOX, SOC 2, ISO 27001, or NIS2 review.
arrow arrow

Thank you
for contacting us!

Please, check your email

arrow arrow

Thank you

You've been subscribed

We use cookies to enhance your browsing experience. By clicking "Accept," you consent to the use of cookies. To learn more, read our Privacy Policy