Segregation of Duties is one control within a broader internal controls framework. Learn the difference, the control types involved, and how they connect.
"We have internal controls" and "we have Segregation of Duties" get used almost interchangeably in a lot of compliance conversations, and that loose overlap causes real problems once an actual audit starts. SoD is one control among many. Internal controls is the entire framework governing how an organization prevents, detects, and corrects risk across its financial and operational processes.
This guide untangles the two, walks through the control-type taxonomy auditors actually test against, and shows exactly where SoD sits inside it. For the fundamentals of SoD itself, see our Segregation of Duties guide.
What internal controls actually are
Internal controls are the policies, procedures, and mechanisms an organization puts in place to ensure the reliability of financial reporting, the effectiveness of operations, and compliance with applicable laws and regulations. This is a broad category by design. It covers everything from physical security over inventory to the approval workflow for a wire transfer to the process for reviewing financial statements before they're published.
The COSO framework (Committee of Sponsoring Organizations of the Treadway Commission), the most widely referenced internal controls model, organizes this into five interrelated components: the control environment, risk assessment, control activities, information and communication, and monitoring. SoD lives specifically within control activities, one category among several that make up that component.
The three types of internal controls
Internal controls are commonly classified by when they act relative to a risk event: before it happens, while or after it's happening, or once it's already occurred.
Preventive controls stop an error or a fraudulent act before it happens. Requiring dual approval on payments above a threshold, restricting system access based on role, and enforcing SoD itself are all preventive controls, since their purpose is to make the risky action structurally impossible or require a second party's involvement before it can occur.
Detective controls identify an error or violation after it's occurred, but ideally quickly enough to limit the damage. Bank reconciliations, access reviews, and exception reports (like a report flagging unusually large transactions) are detective controls. They don't stop the event, but they surface it.
Corrective controls fix the underlying issue once a detective control has found it. This includes the remediation steps taken after an SoD violation is discovered, the process for revising a control that repeatedly fails, and disciplinary or process changes following an identified incident.
SoD is unusual in that it can function as more than one type depending on how it's implemented. The rule itself, structured so no single person can complete a conflicting pair of actions, is preventive. The periodic review that checks whether anyone has quietly accumulated conflicting access despite the rule, is detective. And the process for revoking access or applying a compensating control once a violation is found, is corrective. A mature SoD program typically has all three working together rather than relying on the preventive rule alone.
Where Segregation of Duties fits precisely
SoD is a specific preventive control activity: the structural separation of incompatible functions across different people or systems so that no single individual can both perpetrate and conceal an error or fraudulent act. It sits alongside other control activities like authorization controls (approval hierarchies), physical controls (restricted access to assets), and IT general controls (change management, access provisioning).
What makes SoD distinct from these other control activities is that it's fundamentally about combinations, not individual actions. An authorization control asks "was this action approved by someone with the right to approve it." SoD asks a different question: "does the person who took this action also hold the ability to approve, record, or reconcile it."
The same person can pass every individual authorization check and still represent an SoD violation, because the risk lives in the combination of roles they hold, not in any single action being unauthorized.
This is why SoD often gets tested separately from general authorization controls during an audit, even though both fall under the same broader control-activities umbrella. A tester can confirm every transaction had proper sign-off and still find an SoD gap if the same person provided both halves of that sign-off chain. For concrete illustrations of exactly this pattern across different departments, see Segregation of Duties policy examples.
SoD alongside other control activities
It helps to see SoD positioned next to the other control activities it sits alongside, since auditors typically evaluate all of them together rather than SoD in isolation.
Notice that IT general controls and SoD overlap significantly in practice, since IT-specific SoD conflicts (a developer with database administrator rights, for instance) are tested as part of both categories. This overlap is normal and expected. It's also part of why IT-specific SoD gets a dedicated review process in most audit programs rather than being folded entirely into general ITGC testing. See our IT Segregation of Duties guide for the full breakdown of where these conflicts live specifically in IT environments.
Why the distinction matters in practice
Treating SoD and internal controls as synonymous causes two specific, recurring problems.
Underinvesting in detective and corrective controls. An organization that equates "internal controls" with "we separated these roles" often stops there, assuming the preventive structure alone is sufficient. Without a detective layer (periodic reviews, automated monitoring) checking whether that separation has held over time, roles drift back into conflict through ordinary promotions and reorganizations, and nobody notices until an audit or an incident forces the question.
Missing non-SoD control gaps. Conversely, an organization narrowly focused on SoD compliance can miss other control activities that matter just as much: physical security, IT general controls unrelated to role conflicts, or monitoring controls that catch anomalies SoD alone wouldn't structurally prevent. SoD closes one specific category of risk. It isn't a substitute for a complete internal controls program.
Auditors evaluate the full COSO framework, not SoD in isolation, which is exactly why conflating the two creates blind spots on both the audit-readiness side and the actual risk-reduction side.
SoD and internal controls under SOX
SOX Section 404 requires management to assess and report on the effectiveness of internal controls over financial reporting, evaluated against a recognized framework, typically COSO. SoD sits inside that broader assessment as one of the specific control activities auditors test, alongside authorization controls, IT general controls, and monitoring controls.
A SOX auditor testing SoD specifically will typically sample a set of employees, compare their actual system access against a defined conflict matrix, and check whether any documented compensating controls are operating as intended where full separation isn't in place. This is a narrower test than the full internal controls assessment.
It still feeds directly into the broader conclusion about whether the control environment as a whole is effective. For the fuller picture of how SoD gaps specifically show up as audit findings and what they cost to remediate, see our guide to Segregation of Duties risks.
Building SoD as part of a broader controls program
Treating SoD as one component of a larger system, rather than the entire system, changes how it should actually get built and maintained.
Start from the risk, not the control. Rather than beginning with "we need an SoD policy," identify the specific financial reporting and operational risks the organization faces, then determine which combination of preventive, detective, and corrective controls addresses each one. SoD will cover a meaningful share of that risk, particularly around fraud and unauthorized transactions, but rarely all of it.
Pair the preventive rule with a detective check. A documented SoD policy without a periodic review process is a preventive control with no way of confirming it's actually holding. Build the review cadence in from the start rather than treating it as an afterthought once an audit asks for evidence.
Document the corrective path explicitly. When a detective review finds a violation, what happens next needs to be as clearly defined as the rule itself. We cover the full define-implement-maintain arc, including the specific procedure steps from detection through verified remediation, in Segregation of Duties policy and procedure.
Build the underlying conflict matrix with the same rigor as any other control activity. The matrix is what makes SoD testable rather than aspirational, in the same way a documented approval hierarchy makes an authorization control testable. See our Segregation of Duties matrix template for the full structure.
How automation strengthens the detective layer
The preventive half of SoD, defining who shouldn't hold which combinations, is usually the easier part to document. The detective half, actually confirming on an ongoing basis that the separation is holding, is where most manual programs fall short, because it requires continuously checking real access against the policy rather than assuming a decision made once stays accurate indefinitely.
This is where automated SoD detection strengthens the broader internal controls picture specifically. Instead of a periodic manual review that only catches whatever conflict happens to exist on review day, continuous automated detection functions as an always-on detective control, catching violations as they form rather than waiting for the next scheduled check.
Zluri, an identity security platform, addresses this through its IGA product's Segregation of Duties capability. Policies run on a defined schedule rather than a single point-in-time check, every published policy version is preserved as a full configuration snapshot for audit evidence, and violations route automatically for remediation.
This gives the preventive, detective, and corrective layers described throughout this guide a single, continuously operating system behind them. If you're evaluating tools that can strengthen this part of your controls environment specifically, our guide to SoD software covers the evaluation criteria and compares the leading platforms.
Want to see how continuous, automated SoD detection strengthens the detective layer of your controls program? Book a demo with Zluri.
Frequently Asked Questions
Is Segregation of Duties the same as internal controls? No. Segregation of Duties is one specific control activity within a much broader internal controls framework that also includes authorization controls, physical controls, IT general controls, and monitoring controls. Internal controls is the entire system; SoD is one component of it.
What are the three types of internal controls? Preventive controls stop an error or fraud before it happens, detective controls identify it after the fact, and corrective controls fix the underlying issue once found. Segregation of Duties functions primarily as a preventive control, though a mature SoD program includes detective (periodic review) and corrective (remediation) elements as well.
Why do auditors test Segregation of Duties separately from general authorization controls? Because SoD tests for a different kind of risk. An authorization control asks whether an action was approved by someone with the right to approve it. SoD asks whether the same person also holds the ability to approve, record, or reconcile that same action, a combination risk that a standard authorization check wouldn't catch on its own.
Can a company have strong internal controls without formal Segregation of Duties? Unlikely for any organization handling financial transactions or sensitive system access, since SoD addresses a specific, well-documented category of fraud and error risk that other control types generally don't cover on their own. Most internal controls frameworks, including COSO, expect SoD as a standard control activity.
How does Segregation of Duties fit into a SOX 404 assessment? SoD is tested as one control activity within the full internal controls over financial reporting assessment. Auditors typically sample employee access against a defined conflict matrix and evaluate whether documented compensating controls function as intended anywhere full separation isn't in place.
What's the risk of treating Segregation of Duties and internal controls as the same thing? It typically leads to underinvesting in the detective and corrective layers, assuming the preventive separation alone is sufficient, while roles quietly drift back into conflict over time through ordinary promotions and reorganizations that nobody is actively checking for.
.svg)
