Segregation of Duties (SoD) in IAM: How to Detect and Prevent Conflicting Access

Sep 29

9 min read

A common question in access management is straightforward: “Who can access which system?” But this question reveals only part of the picture. The real risk often lies not in any single answer, but in how those answers combine. When a user’s permissions are reviewed individually, they may appear entirely appropriate. The problem can arise when those permissions are brought together under the same identity.

It is a normal part of a system administrator’s role to create a new user account. Likewise, another administrator may legitimately assign privileged access to that account. However, if the same person can both create the account and grant themselves or the newly created account administrative privileges over critical systems, the independent control mechanism is effectively removed.

SoD prevents or controls situations in which permissions that are legitimate on their own accumulate under the same person and form risky combinations.

Segregation of Duties (SoD)

Segregation of Duties is a fundamental governance principle designed to prevent excessive authority from being concentrated in a single individual. It aims to distribute critical steps—such as initiating, modifying, approving, and reviewing a transaction—across different people.

Long established as a classic internal control principle in financial processes, SoD now applies far more broadly. In today’s enterprise environments, where users may receive access through multiple applications, groups, roles, or direct assignments, the same question arises across IT operations, Human Resources, procurement, privileged access, and beyond:

When a user’s access rights are evaluated together, do responsibilities that should normally remain independent converge under the same individual?

Answering this question accurately requires more than looking at role names. Organizations need to understand what the user can actually access, how that access was obtained, and what it enables within the underlying business process.

Why Is SoD an Integral Part of Identity Governance?

A single user may have access to a large number of systems. The same employee may hold a directly assigned role in one application while gaining access to another system through an Active Directory group. Add project-based temporary access, manually assigned roles, and permissions inherited from the organizational structure, and even one user’s access landscape can become a complex puzzle.

A user may be authorized to create new accounts in one system and assign privileged access in another. Viewed separately, both permissions may appear entirely legitimate. Yet when the systems are evaluated together, it becomes clear that the same person can both create an account and grant critical privileges to it. From an SoD perspective, the risk does not arise from either permission in isolation, but from the combination of those permissions under the same individual.

This is precisely where Identity Governance becomes essential. It asks not only whether access exists, but why it was granted, where it came from, how long it should remain in place, who owns it, and what risk it introduces.

For this reason, reducing SoD to the question “Which two roles should not coexist?” is insufficient. More meaningful questions include:

What business responsibilities do these access rights represent?
Why and how did the user obtain this access?
What control risk do they create when combined?
When a violation is identified, is it clear which access should be changed?

Where Do SoD Conflicts Arise in Enterprise Environments?

SoD rules vary from one organization to another. The combinations considered risky depend on the industry, the organization, and its operating model. However, certain types of conflicts recur across sectors.

Finance is one of the most established areas of SoD practice. Most financial processes inherently involve multiple control points. Combining duties such as creating and approving invoices, creating vendor records and executing payments, or posting accounting entries and performing the final review under the same person weakens process controls. The ability to approve a payment or create a vendor is not inherently risky on its own. The risk emerges when both capabilities are concentrated in the same individual.

In Information Technology, segregation of duties is often relevant to privileged access and role changes. Creating a new user account or assigning an administrator role may be a legitimate responsibility of a system administrator. If the same person can both create the account and grant it elevated privileges, however, the control is bypassed. The same principle applies when a developer can move their own code into production without independent review, or when a person performing critical operations can alter their own audit records.

In Human Resources, creating employee records, changing salary or bank information, managing payroll, and updating employment status are control points that should be separated. The risk is not limited to the HR application itself: if the HR system serves as the authoritative source for IAM, a change in an employee’s position or status may automatically trigger new access across other systems. In other words, access design on the HR side can influence the entire identity lifecycle.

In procurement processes, concentrating activities such as raising requests, selecting vendors, approving purchase orders, verifying delivery, and authorizing payment under one user weakens the control structure. Depending on the organization’s control model, allowing an employee to both create a vendor and approve a purchase may constitute a direct SoD violation.

Examples of SoD Conflicts by Department

Department	Primary Permission	Conflicting Permission
Finance	Create vendor	Approve payment
Finance	Create invoice	Approve invoice
IT	Create user	Assign privileged role
IT	Modify system	Deploy to production
HR	Create employee	Modify salary/bank details
HR	Change employee status	Approve payroll
Procurement	Create vendor	Approve purchase
Procurement	Create request	Approve purchase order

This table should not be interpreted as a ready-made policy set. An effective SoD model should be built around each organization’s own business processes and control framework.

Why Is Detecting SoD Violations More Difficult Than It Sounds?

In theory, SoD appears simple: define two conflicting permissions and prevent them from being assigned to the same user. In practice, access rarely follows such a straightforward path.

A user may receive a permission directly, but the same permission may also be inherited through a business role, group membership, role hierarchy, or even a relationship in an entirely different application. This is why looking only at a user’s roles is not enough.

A sound SoD analysis requires three layers to be evaluated together:

What can the user access? A snapshot of current access.
How did the user obtain this access? The source of access.
What can this access enable when combined with other permissions? The point at which technical access translates into real business risk.

If these three layers are not evaluated together, SoD analysis is bound to remain superficial.

Why Does the Source of Access Matter?

Identifying that a user holds a risky permission is important, but what matters most is understanding the business need and rationale behind how that permission was granted.

Suppose a user’s payment approval permission needs to be removed. If the permission was assigned directly, the solution is relatively straightforward. But if the access comes from a finance role, the issue may not be limited to that user. Other users assigned to the same role may carry the same risk. In that case, removing one user’s permission addresses only the visible symptom and may leave the root cause unresolved.

Access visibility should therefore go beyond answering “Does the user have this access?” It should also explain “Through which role, group, or relationship was this access obtained?” This distinction is essential to selecting the right remediation action when resolving an SoD violation.

Which Identity Governance Capabilities Make SoD Truly Manageable?

SoD is not a problem that can be solved by a rule engine alone. An Identity Governance solution should combine preventive and detective SoD controls with cross-application access analysis, identity and account correlation, access reviews, and workflows that support remediation actions:

SoD policy and rule management — defining risky access combinations
Identity and account correlation — linking accounts across different systems to the same identity
Access visibility — understanding the source of access
Access Request and Access Review — evaluating access during request and review stages

Preventive SoD: Identifying Risk Before Access Is Granted

From an SoD perspective, the most valuable point of control is before access is granted. When a user requests a new role, the system should ask not only “Should this access be approved?” but also whether combining it with the user’s existing access would create a new risk. This approach is known as Preventive SoD. For example, if a user who already has permission to create vendors requests payment approval access, the potential conflict can be identified before the new access is granted.

Automatically rejecting every conflict is not always appropriate; in some cases, the access may be genuinely required for business reasons. The system can instead route the request for additional approval, require sign-off from the risk owner, make approval conditional on removing an existing conflicting permission, or grant a controlled, time-bound exception. The goal is to ensure that a risky combination becomes a conscious, documented decision rather than an unnoticed condition.

Detective SoD: Making Existing Risk Visible

Preventive SoD reduces the creation of new risks, but it is not sufficient on its own. Users change responsibilities, new roles are added, managers grant access manually, and legacy access is not always removed on time. Access that was appropriate when first granted may evolve into an SoD violation over time. Detective SoD regularly compares existing user, role, group, and entitlement data against defined policies to identify risks already present in the environment.

SoD Stage	Objective	Possible Action
Prevention	Identify conflicting permissions before they are granted to the user	Block the request, route it for additional approval, or require removal of existing access
Detection	Identify SoD violations within the user’s existing access	Compare role, group, and entitlement data against defined SoD policies
Remediation	Eliminate the source of the identified conflict	Remove access, change role or group membership, or apply a controlled exception

What Should You Look for When Selecting an SoD Solution?

Simply stating that a solution “supports SoD” does not say much on its own. What matters is how deeply that support is embedded across the different stages of the access lifecycle.

Assessment Area	Key Question
Cross-Application Analysis	Can access across different systems be evaluated together?
Identity Correlation	Can multiple accounts belonging to the same user be correlated?
Preventive SoD	Can a conflict be identified before access is granted?
Detective SoD	Can violations in the current environment be detected?
Access Visibility	Can the path through which access was granted to the user be identified?
Access Review	Can SoD risk be incorporated into access review decisions?
Exception Management	Can business-required exceptions be managed in a controlled manner?
Audit Trail	Can decisions and changes be tracked?

Managing SoD with Securify Identity

Securify Identity helps prevent SoD risks during access requests, detect conflicts within existing access, and determine the appropriate remediation action based on the source of the violation. SoD controls are not treated as an isolated checkpoint, but as an integral part of Identity Governance processes such as access requests, access reviews, and access visibility.

This allows teams not only to see that a violation exists, but also to analyze which access relationship caused it and where remediation should begin. If the risk comes from a direct user assignment, a single change may be sufficient. If the same issue originates from a role or group structure, however, the solution may require a much broader revision of the role design.

Conclusion

The objective of Segregation of Duties is to prevent critical control points within a business process from being unnecessarily concentrated in a single person.

To achieve this, organizations must look beyond roles and examine users’ actual access, how that access was obtained, and how different permissions interact. A mature SoD approach combines three stages:

· Prevent: Stop risky combinations before access is granted.

· Detect: Identify existing or newly developed violations.

· Remediate: Understand the source of the violation and change the appropriate access, role, or process.

This is where the true value of SoD within Identity Governance becomes clear. A strong governance approach does not simply ask, “Who has access to what?” The more important question is: When these access rights are combined, what do they actually enable the user to do?

Frequently Asked Questions

What is SoD?

Segregation of Duties is a governance principle designed to prevent critical responsibilities that should provide checks and balances within a business process from being combined under a single user without appropriate control.

What is an SoD violation?

An SoD violation occurs when a user simultaneously holds two or more permissions that the organization’s policy defines as a risky combination.

Is SoD used only in financial processes?

No. Although finance is one of the most common areas of application, SoD is also used across IT, Human Resources, procurement, privileged access, change management, and many other functions.

Can SoD violations be prevented before access is granted?

Yes. Preventive SoD evaluates a user’s existing access together with newly requested access to identify potential conflicts before the access is granted.

How are existing SoD violations identified?

Detective SoD controls compare current identity and access data against defined policies to identify risky combinations already present in the environment.

What is the relationship between Access Review and SoD?

Access Review evaluates whether existing access is still required, while SoD information shows the decision-maker the risk created when that access is combined with other permissions.

Should every SoD violation be removed automatically?

No. Some access may be required for legitimate business reasons. In such cases, additional approval, a time-bound exception, or compensating controls may be applied. The key is for the exception to remain controlled, documented, and subject to periodic review.

How does Securify Identity help prevent and manage SoD violations?