A user who can create a vendor, change its bank details, and approve payment has more than efficient access. They have a control failure waiting to happen. The same principle applies when an administrator can request, approve, and provision privileged access without independent review. To implement segregation of duties effectively, organizations must turn policy intent into enforceable identity controls across business systems, infrastructure, and privileged workflows.
Segregation of duties, often abbreviated as SoD, is not simply an audit requirement or an ERP configuration exercise. It is a practical security control that limits the ability of one person, account, service, or automated process to complete an end-to-end high-risk action alone. Done well, it reduces fraud, prevents costly errors, improves accountability, and gives security and compliance teams evidence that critical access is under control.
Why Segregation of Duties Breaks Down
Most enterprises do not lack SoD policies. They lack a reliable way to apply those policies across a fragmented identity environment. Finance teams may manage conflicts in enterprise applications, while infrastructure teams use separate processes for administrator access. Cloud entitlements, SaaS roles, shared accounts, certificates, machine identities, and AI agents can sit outside the original SoD model entirely.
That fragmentation creates blind spots. A role may look acceptable within one application but become toxic when combined with access in another system. A manager may approve access without understanding the full set of permissions the employee already holds. Emergency access can become permanent because the removal process is manual or poorly monitored.
The challenge is operational, not theoretical. Effective SoD requires a clear model of who has access, what that access enables, which combinations create unacceptable risk, and how exceptions are controlled over time.
Start With Business Risk, Not Role Names
The first step is to identify the business activities that must remain independent. Avoid beginning with a long inventory of application roles. Role names are inconsistent, technical, and often misleading. Start with outcomes instead.
For example, a procurement process may require separation between creating a supplier, modifying supplier payment details, issuing a purchase order, receiving goods, and approving an invoice. In an infrastructure context, separation may be needed between requesting elevated access, approving it, granting it, and reviewing its use. For AI agents, the same logic applies: an agent that can initiate a transaction should not also independently approve, reconcile, and conceal that transaction.
This approach produces a risk-based SoD matrix. Each conflict should document the two or more capabilities that cannot be held together, the systems involved, the potential impact, the risk owner, and the permitted mitigation. Keep the first version focused on material risks. A matrix with thousands of low-value conflicts will overwhelm reviewers and encourage teams to work around the process.
Define What Counts as a Conflict
Not every combination of access is a true SoD violation. Some permissions look similar but cannot be used to execute a meaningful transaction. Others only become dangerous when paired with privileged access, broad data access, or an unmanaged shared account.
Classify conflicts by severity. Critical conflicts should block access automatically unless a documented exception is approved. High-risk conflicts may require compensating controls and frequent review. Lower-risk combinations may be accepted temporarily while roles are redesigned. This tiering lets the organization direct control effort where it matters most.
Build Controls Into the Identity Lifecycle
A spreadsheet can identify conflicts, but it cannot reliably prevent them. To implement segregation of duties at scale, SoD checks need to be embedded in the identity lifecycle: request, approval, provisioning, certification, and removal.
When a user requests access, the access management workflow should evaluate the requested entitlement against current permissions and relevant business attributes. If the request creates a prohibited combination, the system should stop the request or route it to a defined exception process. The requestor, approver, and fulfillment team should see enough context to make an informed decision, rather than receiving a vague warning that a conflict exists.
Approval design matters just as much. A manager may understand job responsibilities but not technical entitlements. An application owner may understand permissions but not the user’s business duties. High-risk access requests often require both perspectives, along with security or compliance approval where appropriate. The goal is not to add approval layers indiscriminately. It is to ensure that the person approving a conflict has the authority and information to accept the risk.
Provisioning must enforce the decision. If identity governance identifies a conflict but downstream administrators can manually assign access outside the governed workflow, the control is incomplete. Integrate authoritative identity data, identity governance, directory services, business applications, cloud platforms, and privileged access controls so the approved policy is reflected in the actual environment.
Treat Privileged Access as a Separate SoD Problem
Privileged access is frequently excluded from business SoD programs, even though it can override nearly every other control. A system administrator who can alter application configurations, reset credentials, disable logs, or access sensitive databases may be able to bypass the controls assigned to business users.
Separate standing administrative rights from temporary task-based elevation. Privileged Access Management can require users to request access for a defined purpose, receive approval when needed, use time-limited credentials, and generate session records for later review. The person approving privileged elevation should not be the same person using it, particularly for sensitive production systems.
Break-glass access is necessary in many environments, but it must be tightly defined. Establish who can invoke it, how long it remains active, what evidence is captured, and who reviews its use afterward. Emergency access that is never reviewed is simply privileged access outside normal governance.
Design Exceptions That Do Not Become Permanent
Some SoD conflicts are unavoidable. A small regional operation may not have enough staff to separate every financial duty. A production incident may require a single engineer to perform actions that are normally divided across teams. A migration may temporarily create overlapping access while systems are consolidated.
The answer is not to ignore the conflict. Use a formal exception process that records the business justification, risk owner, compensating controls, expiration date, and review frequency. Compensating controls could include transaction monitoring, independent reconciliation, session recording, post-action review, or reduced transaction limits.
Every exception needs an owner and an end date. Without both, the exception register becomes a repository for permanent risk. Expiring exceptions force a decision: remove the conflict, renew it with fresh evidence, or redesign the process.
Validate Access With Meaningful Reviews
Access certification is often where well-designed SoD programs lose credibility. Reviewers receive large lists of technical entitlements, approve them quickly, and have little visibility into whether the access creates a real conflict.
Make reviews risk-based and intelligible. Present business-friendly access descriptions, highlight toxic combinations, show the source of access, and identify whether it is permanent, temporary, privileged, or inherited through a group. Prioritize high-risk users, privileged accounts, dormant identities, service accounts, and previously approved exceptions.
Reviews should also test control performance. If recurring certifications reveal the same conflicts quarter after quarter, the issue is not reviewer behavior alone. It may indicate poor role design, inaccurate identity data, weak request controls, or an exception path that is easier than compliance.
Measure the Control, Not Just the Cleanup Work
A mature SoD program measures whether risk is declining and whether controls are operating as intended. Useful metrics include the number of open critical conflicts, average time to remediate a violation, percentage of exceptions past expiration, access requests blocked before provisioning, and the volume of privileged access granted outside standard workflows.
Trend data matters more than a single dashboard. A sudden increase in conflicts after an acquisition, cloud migration, or ERP rollout may be expected, but it should trigger a defined remediation plan. Repeated manual overrides may indicate that the access model no longer reflects business operations.
Strong metrics also help security leaders explain investment decisions. They connect identity governance work to reduced exposure, audit readiness, and fewer emergency interventions rather than presenting SoD as an isolated compliance task.
Make SoD a Continuous Operating Discipline
Segregation of duties changes whenever the organization changes. New applications introduce new roles. Business reorganizations shift approval responsibilities. Cloud platforms add entitlements at a pace that traditional role reviews may not match. AI agents create nonhuman identities that can initiate and execute workflows at machine speed.
That is why SoD must be operated as a continuous identity control. Review the conflict matrix when critical processes change. Reassess role design after major implementations. Monitor privileged and nonhuman access with the same rigor applied to employees. Most importantly, connect governance decisions to enforcement in the systems where work actually happens.
The objective is not to create the most restrictive access model. It is to ensure no single identity can quietly control a high-risk outcome without accountability. When SoD is built into identity operations, security teams gain a control that remains effective long after the audit closes.
