A single admin account can create a change, approve it, and erase the log that would have caught the mistake. IT Segregation of Duties exists to make sure no one account can do all three.
Most people picture Segregation of Duties as a finance control: separate who creates a purchase order from who approves it. IT has the same underlying problem, but it shows up differently.
In this guide, we'll cover how SoD conflicts form in IT specifically, the role splits that matter most, real examples across common systems, and how to detect these conflicts at the scale a modern SaaS-heavy environment actually operates at.
Why IT Segregation of Duties is a distinct problem
Finance SoD conflicts tend to be transactional. Someone creates a transaction, someone else approves it, and the risk is bounded by the size of that one transaction.
IT conflicts don't work that way. A single administrator account frequently has access that spans an entire system, sometimes an entire environment, and when that account also holds the ability to approve its own changes, or to modify the logs that would reveal what it did, the exposure isn't one transaction. It's everything that account can reach.
This is compounded by how IT access gets provisioned in practice. Broad admin rights are often granted by default, because it's faster than scoping access precisely, and because the person granting access frequently doesn't fully understand what the requester actually needs. The result is that IT environments tend to accumulate excess privilege faster than finance systems do, a version of access creep that's especially pronounced in IT. For a full breakdown of what this kind of unchecked access actually costs once discovered, see our guide to Segregation of Duties risks.
For the broader principles behind SoD, see our Segregation of Duties guide.
The core IT role conflicts
A handful of role pairings show up again and again as the highest-risk IT conflicts. Most map to a familiar pattern: one identity that can both take an action and independently verify or approve it.
Database administrator vs. application developer. A developer who also holds DBA rights on production can push code changes and directly modify the data those changes touch, with no independent review of either action. This is one of the most commonly cited SoD violations in SOX IT general controls testing.
System administrator vs. security administrator. Sysadmins manage day-to-day infrastructure; security admins manage the controls that govern and audit that infrastructure. When one person holds both, they can make a change and then adjust the security logging that would flag it as unusual.
Network engineer vs. firewall/access control owner. The person who configures network infrastructure generally shouldn't also be the sole approver of firewall rule changes or access control list updates.
Change requester vs. change approver. This mirrors the classic finance conflict almost exactly. Someone who submits an infrastructure or configuration change ticket shouldn't also be the one who approves it for production deployment.
Audit log owner vs. everyone else. Whoever can modify or delete audit logs holds outsized power, because that access effectively controls what's provable after the fact.
These IT-specific pairings mirror the same underlying pattern that shows up across other departments: someone who can both act and independently verify that action. For worked examples of this pattern in finance, HR, and procurement, see Segregation of Duties policy examples.
Where these conflicts actually live
Understanding the role pairings above is one thing. Knowing where to look for them in a real environment is another, and it's usually less obvious than the finance examples.
Cloud infrastructure. AWS, Azure, and GCP all make it easy to grant broad IAM roles quickly, and easy to forget to scope them down later. A single engineer with both infrastructure-provisioning rights and billing-approval rights can spin up resources and approve the spend without any second party involved.
Identity providers. Someone with both user-provisioning rights in the IdP and approval rights over access requests can grant themselves access to anything routed through that system, then approve their own request.
CI/CD pipelines. A developer who can both merge code and deploy it to production without a required review step has, functionally, the same unchecked authority as someone who can create and approve a financial transaction.
SaaS admin consoles. Individual SaaS tools like CRM, HRIS, and finance software often have their own admin roles with the power to both configure the tool and audit its usage logs. These are easy to overlook because they don't feel like "IT systems," but the same conflict logic applies.
This is also where cross-application conflicts become the norm rather than the exception. An engineer might have reasonable, individually justified access in three different tools that, combined, add up to a toxic combination no single tool's admin console would ever flag on its own.
IT Segregation of Duties and compliance frameworks
SOX IT general controls (ITGC) testing puts direct weight on IT SoD, specifically around change management, access provisioning, and the ability to alter financial-system data outside of an approved process. Auditors typically test for exactly the DBA/developer and change-requester/change-approver conflicts described above.
ISO 27001's Annex A.5.3 names segregation of duties directly, and in practice, IT access is where assessors spend the most time verifying it, since IT holds the technical keys to nearly everything else in scope. SOC 2's logical access criteria expect similar evidence: that privileged access isn't concentrated in a single unreviewed identity.
None of these frameworks care whether the conflict lives in finance or in a cloud console. The underlying question is the same: can one identity complete a sensitive action and also control the evidence of having done it? For how SoD sits within the broader internal controls picture these frameworks test against, see Separation of Duties and internal controls.
This is also why IT-specific SoD often gets its own dedicated review process rather than being folded entirely into general ITGC testing. The conflicts are real, but they don't always surface the same way a standard change-management audit would catch them.
Building an IT-specific conflict matrix
The general logic of an SoD matrix, map functions against each other, flag which combinations conflict, rate the risk, assign an owner, applies directly to IT. Only the vocabulary changes.
Instead of "create purchase order" and "approve purchase order," IT matrix rows look more like "modify production database" against "approve database change requests," or "provision cloud IAM roles" against "approve IAM policy changes." We cover the full logic of building and maintaining a matrix, including a worked example table, in our Segregation of Duties matrix template. Once the matrix exists, it still needs a documented policy and procedure behind it, covered in Segregation of Duties policy and procedure.
Common mistakes in IT SoD programs
Treating admin access as binary. Many teams think in terms of "has admin" or "doesn't have admin," rather than which specific admin capabilities a person holds. Two people can both be "admins" on a system while holding meaningfully different, and differently risky, sets of permissions.
Assuming smaller IT teams are exempt. Small IT teams often can't fully separate every function, similar to small finance teams. The difference is that IT teams sometimes skip the compensating control step entirely, reasoning that "everyone trusts each other" is enough. It isn't, for audit purposes or for actual risk reduction.
Forgetting service accounts and automation. Non-human identities, service accounts, API keys, automation bots, can hold the same kind of conflicting access a human admin can, and they're frequently excluded from SoD reviews entirely because the process was designed with only human employees in mind. A service account with both data-write access and log-modification access is exactly as risky as a person with the same combination, arguably more so, because nobody's watching it day to day.
Not revisiting access after a role change. An engineer who moves from a DevOps role into a security role often keeps their old deployment access alongside their new audit responsibilities, creating exactly the sysadmin/security-admin conflict described earlier.
A worked example: the conflict most audits catch
It helps to see the DBA/developer conflict play out concretely, since it's the one that shows up most often in real findings.
An engineer joins as a backend developer and is granted standard application-level access to push code to a staging environment. A year later, they're asked to help with a database migration project, and rather than provisioning temporary, scoped access for that one project, someone grants them full production database administrator rights, reasoning it's faster than working out exactly what the migration needs.
The migration finishes. The DBA rights don't get revoked, because nobody owns that follow-up step. Eighteen months later, this same engineer can push application code changes and directly modify the production data those changes touch, with no second reviewer required for either action.
This is precisely the scenario a SOX ITGC auditor tests for, and it's precisely the kind of access-creep pattern that a point-in-time review misses, because the DBA grant looked justified when the project started. Catching it requires either a scheduled re-certification of access, or continuous automated detection that flags the conflict the moment both permissions exist on the same identity.
Nobody in this scenario acted maliciously. That's exactly the point: the risk formed through ordinary, well-intentioned decisions, which is why relying on individual judgment to catch it doesn't work at scale.
Detecting IT SoD conflicts at scale
Everything above assumes you can actually see, in one place, everyone's access across every system that matters. In practice, IT access is scattered across cloud consoles, identity providers, CI/CD tools, and dozens of individual SaaS admin panels, each with its own permission model.
Manually cross-referencing all of that isn't realistic once an organization runs more than a handful of connected systems. This is precisely the gap automated SoD detection tools are built to close: instead of a human reconciling access by hand, the tool ingests entitlement data from each connected application and checks every identity against defined conflict rules continuously.
Zluri, an identity security platform, handles this through its IGA product's Segregation of Duties capability, which detects conflicting entitlements across your SaaS and cloud stack, even when the two sides of a conflict live in entirely different applications, and routes violations for remediation automatically. If you're evaluating tools built specifically for this kind of cross-application detection, our guide to SoD software covers the buying criteria and compares the leading platforms.
Want to see automated IT SoD detection running across your actual cloud and SaaS stack? Book a demo with Zluri.
Frequently Asked Questions
What is the most common Segregation of Duties conflict in IT? The database administrator and application developer conflict is one of the most frequently cited in audits, since it combines the ability to change code with the ability to directly modify the production data that code touches.
Does IT Segregation of Duties apply to cloud environments? Yes, and it's arguably more important there than in traditional on-premises systems, since cloud IAM roles are easy to grant broadly and easy to forget to scope down.
Should service accounts be included in IT SoD reviews? Yes. Service accounts and other non-human identities can hold conflicting access just like a human admin can, and they're often excluded from reviews simply because the process was built around human employees only.
How is IT Segregation of Duties different from least privilege? Least privilege limits how much access any single identity has. SoD is concerned with what happens when two individually justified pieces of access end up combined in the same identity.
Can small IT teams implement Segregation of Duties? Yes, though full separation isn't always possible with limited headcount. Compensating controls, like requiring a second reviewer for high-risk production changes, help offset the risk until the team grows.
How do you detect IT SoD violations across multiple cloud and SaaS tools? Manually, by cross-referencing access across every connected system, which becomes unmanageable past a small number of tools. Most organizations past that point use an automated SoD detection platform instead.
.svg)
