Segregation of Duties: A Guide to Automated SoD

Picture this: a finance employee at a mid-sized company ends up with two roles in their ERP system: creating new vendors and approving payments. Both access grants were intentional, assigned through the right processes. But they happened years apart as responsibilities changed, so no segregation of duties (SoD) policy caught the overlaps, and no one stopped to ask whether having one person hold both permissions was an issue.

This combination — create vendor + approve payment — is a classic fraud risk in enterprise finance. It gives one person the power to invent a fake vendor and send them money. The ACFE's 2024 Report to the Nations found that weak internal controls drove 32% of occupational fraud cases, with poor segregation of duties a common thread in many incidents.

The idea behind SoD is straightforward: no one person should control every step of a critical transaction. But organizations struggle in writing SoD policies that match how access is actually used day to day.

This article explains why traditional SoD approaches create compliance theater instead of real security, what usage-aware SoD detection looks like, and how modern identity platforms are making automated SoD practical.

What is segregation of duties? (SoD)

Segregation of duties is the principle that critical business processes should be divided across multiple people so that no single individual can complete a high-risk transaction — or conceal a fraudulent one — without the involvement of at least one other person.

The concept originates in accounting and finance, where double-entry bookkeeping and separation of record-keeping from cash handling were early implementations. Today, SoD applies across every major business function.

Common SoD conflicts include:

• Finance: Creating a vendor and approving payment to that vendor
• HR: Hiring an employee and setting their compensation
• IT/Security: Creating a user account and granting admin privileges to it
• Development: Writing application code and deploying it to production

Each of these is a combination of permissions that, if held by one person, creates both the opportunity and the means to commit fraud, make unchecked errors, or bypass security controls.

SoD matters for three reasons:

1. Fraud prevention: it removes the single-actor scenario that makes unauthorized transactions easy to execute and hard to detect. 
2. Compliance: SOX Section 404, PCI DSS Requirement 7, and ISO 27001 all require demonstrable separation of incompatible duties.
3. Operational risk: checks and balances reduce the likelihood that errors go uncaught.

Scale is the real challenge. A mid-size enterprise with a dozen SaaS apps, cloud platforms, and legacy systems can face thousands of possible SoD conflicts. Many of these cross system boundaries — the 'create' action might be in one platform, the 'approve' action in another. Static policy rules can’t catch what they do not see.

Why traditional SoD approaches fall short

Most organizations have SoD policies. Most also have IGA platforms that enforce them — at least in theory. The problem is the gap between what those tools check and what matters.

As we've noted in our overview of identity governance and administration, IGA's core function is making access auditable and policy-compliant. Traditional IGA does that by checking whether users have conflicting permissions — not whether they use them. That distinction is where the entire model breaks down.

• Policy gaps:  SoD rules are defined upfront, often at implementation time, and updated infrequently. Business processes evolve. New applications get added. Roles accumulate entitlements that did not exist when the original policy was written. Cross-application conflicts — where the two halves of a dangerous combination live in different systems — are almost impossible to map through manual policy definition.
• Static detection: Traditional SoD checks happen at provisioning time and during periodic certification cycles. That means the window for detecting a violation can be 6-12months. In that time, a user can accumulate conflicting access gradually — a permission added here, a role expanded there — and no alert fires between review cycles. Role creep is the norm.
• No usage context: The most expensive problem with legacy SoD detection is the false positive rate. A policy-based tool flags any user holding conflicting entitlements, regardless of whether those entitlements are ever exercised together. A user who is provisioned with both "Create Purchase Order" and "Approve Purchase Order" roles is flagged. Investigation reveals they've never once used the approval function. The conflict exists on paper but not in practice. That investigation cost hours. Multiply it across hundreds of flagged conflicts per quarter and you have a compliance program that burns through analyst time without reducing actual risk.
• Manual remediation: Every flagged conflict requires a human to investigate, gather evidence, determine whether the conflict is real, and coordinate a fix. With no usage data to triage, every flag looks equally urgent. Teams learn to process the queue instead of prioritizing it.

Once again, the core failure at the heart of all of these issues is that traditional tools tell you what access people have. They do not tell you what access people use. Those two things are not the same, and treating them as equivalent is why SoD programs consistently produce noise instead of signal.

The vision for automated, usage-aware SoD detection

Modern identity security platforms take a fundamentally different approach. Instead of asking "does this user hold conflicting permissions?", they ask "does this user exercise conflicting permissions?" That shift, from entitlement-based to usage-based detection, changes the accuracy, scope, and speed of everything that follows.

As we discuss in our piece on identity security versus IAM versus IGA, the difference between governance and true identity security is exactly this: governance makes access auditable; identity security makes it accurate. Usage-aware SoD is the clearest application of that distinction.

Usage-based intelligence 

An automated SoD platform monitors actual activity across connected systems, not just entitlement records. When a user holds conflicting permissions, the platform tracks whether both are actively used across three dimensions: frequency, recency, and context. A user who has never touched the "Approve" function is not an active SoD risk. A user who exercised both conflicting permissions within the same 48-hour window is a priority investigation.

Continuous monitoring

Periodic audit cycles get replaced by real-time detection. New violations are flagged as they emerge — when a conflicting permission is added and subsequently used — rather than discovered months later during a certification campaign. This is especially important for temporary access grants that quietly become permanent, as well as for the gradual accumulation of permissions that characterizes role creep.

Cross-system visibility

Many of the most dangerous SoD conflicts span applications. A user might initiate a transaction in one SaaS platform and authorize it in another. A graph-based identity architecture that maps entitlements and activity across SaaS, cloud, on-premises, and custom applications can surface conflicts that policy-based tools, scoped to individual systems, will never see. This is where legacy IGA has the largest blind spots.

Intelligent prioritization

Usage data enables risk scoring. A conflict where both permissions are used weekly by the same user, for transactions above a certain threshold, scores differently than a conflict where one permission has not been touched in eight months. Teams see the most dangerous situations first instead of just a flat list sorted by role name.

Automated remediation

With usage data in hand, the platform can go beyond flagging a problem to actually recommend action. Unused conflicting permissions are candidates for automatic revocation. Active conflicts get routed for human review with full evidence: what was accessed, when, how often, and what business process it was part of.

How it all works in practice:

1. Discovery: The platform ingests identity data from all connected systems, mapping permissions, roles, and entitlements into a unified view.
2. Analysis: AI analyzes usage patterns to distinguish theoretical SoD risk from actual SoD risk, considering frequency, recency, and access context.
3. Detection: Users who actively exercise conflicting permissions are flagged with evidence: what they accessed, when, and how often.
4. Remediation: The platform recommends removing unused conflicting permissions and surfaces active conflicts for the security team review, tracking resolution over time.

The shift in output is significant. Traditional approach: "User X has conflicting roles A and B." Modern approach: "User X used both conflicting permissions to perform actions Y and Z on these dates, with this frequency." One starts a long investigation. The other is actionable.

Real-world impact

The operational effects of usage-aware SoD detection are measurable across the teams that deal with SoD compliance daily.

• Security Teams: The most immediate benefit is the reduction in false positives. When detection is grounded in actual usage rather than entitlement assignments, the percentage of flagged conflicts that represent genuine risk increases substantially, and the analyst hours spent chasing non-issues drops proportionally. Time to detect an active SoD violation compresses from months to minutes.
• Compliance Teams: Continuous monitoring changes what audit evidence looks like. Instead of certifications attesting to access at a specific moment, you have an ongoing record of what was accessed, by whom, and whether conflicting permissions were used together. SOX, PCI DSS, and similar frameworks require demonstrable controls. Usage data makes that demonstration concrete rather than procedural.
• Business Operations: The top practical concern with SoD enforcement is productivity impact. Removing access that employees need creates helpdesk tickets and friction. Usage-based remediation eliminates that concern: permissions never used can be removed without impact. This also advances the identity lifecycle management goal of keeping access right-sized as people move through the organization.

Implementing automated SoD in your organization

Getting from legacy SoD enforcement to usage-aware automation does not require a complete infrastructure replacement. It requires visibility first — then intelligence, and then action.

1. Assess your current state. Document existing SoD policies and identify which are driven by regulatory requirements (SOX, PCI DSS, ISO 27001) versus internal risk decisions. Map the critical business processes — finance, HR, privileged access, application deployment — where a single-actor failure would have the highest impact. Identify where your current tooling has blind spots, particularly across application boundaries.

2. Gain unified visibility. Connect all identity sources: HR systems, IdPs, SaaS applications, cloud platforms, and on-premises directories. You cannot detect cross-system SoD conflicts without a unified picture of who has what access, across everything. This is also when existing violations surface, typically more than teams expect.

3. Define risk thresholds. Not all SoD conflicts carry equal weight. Prioritize scenarios where a violation could enable fraud, regulatory exposure, or privilege escalation. Establish what remediation looks like: who is notified, what evidence they receive, and the expected resolution time.

4. Enable continuous monitoring. The goal is to retire the periodic audit cycle as the primary detection mechanism. Real-time alerts close the gap between violation creation and detection, moving it from months to hours.

5. Automate remediation where the data supports it. Unused conflicting permissions, those untouched for 60 or 90 days, are strong candidates for automatic revocation. Active conflicts get human review, but with usage evidence already assembled. Teams spend their time on decisions, not discovery.

Best practices: 

• Start with finance and admin access, where SoD violations carry the highest fraud and compliance risk. 
• Use usage data to validate whether existing policies are catching real conflicts or generating noise. 
• Review and update SoD rules as business processes evolve. 
• Involve business stakeholders in defining what separation is meaningful operationally, not just technically possible.

The future of SoD Is usage-aware

Traditional SoD programs solve a documentation problem, not a security problem. They can prove that policies exist. They cannot prove that violations are not happening between audits, because they are not looking.

Usage-aware SoD detection addresses the actual question: Is anyone exploiting conflicting access right now? That question must be answerable continuously, not just quarterly. The signal-to-noise ratio improves because the platform knows the difference between holding a permission and using it. Remediation becomes targeted instead of merely reactive.

The organizations getting ahead of this problem aren't running more certification campaigns. They're building identity security programs where SoD enforcement is continuous, evidence-based, and tied to actual behavior. That's the difference between compliance as a snapshot and compliance as a practice.

Oleria delivers the visibility and usage context that makes usage-aware SoD possible — because effective SoD starts with understanding how access is actually used across your entire environment. Explore the Oleria platform to learn more.