Most harm in organizations does not come from clever outsiders. It comes from ordinary mistakes and occasional bad choices by people with too much unchecked power.

Every business process has steps where something valuable can go wrong: money moves, records change, access is granted, code goes live. If one person controls every step of such a process, nothing stands between a mistake or a bad intention and its result. Segregation of duties puts a second pair of eyes into the process by design. It does not assume that people are dishonest. It assumes that people are human, that mistakes happen, and that temptation is real.

Three kinds of harm it prevents

• Fraud: a person creates a fake supplier and pays it, or approves their own expenses.
• Error: a person makes an honest slip, such as a wrong amount, and nobody reviews it before it takes effect.
• Concealment: a person changes something and also controls the record of the change, so the trail disappears.

Why software makes it harder to see

In a shop, you can see who stands at the till. In software, powers are hidden inside roles and permissions spread across many systems. A person may hold “create vendor” in one system and “release payment” in another. Neither system sees the problem, because each one only knows about its own permissions. Only a view across systems reveals the risky pair. That cross-system view is exactly what an identity platform can provide.

Why auditors care

Financial reporting rules, security standards, and many industry regulations expect companies to show that dangerous powers are separated, or that when they cannot be, extra checks are in place. Failing to show this is a common audit finding. It is often easy to fix once discovered, but painful to discover at the last minute.

Why it also helps security

An attacker who steals one account gets only the powers of that account. If that account holds a dangerous pair, the attacker can complete a whole harmful process alone. If powers are separated, the attacker needs two accounts, which is harder and noisier. Segregation of duties is therefore a security control as well as a financial one.

A small set of words appears again and again in this topic. Learn them once and the rest reads easily.

Duty and permission

A duty is a responsibility in a business process, such as “approve payments”. A permission is the technical right in a system that lets someone carry out the duty. SoD is stated in terms of duties, but enforced through permissions.

Conflict

A conflict is a pair or group of duties that should not be held by one person. The standard example is creating and approving the same kind of payment. A conflict is a statement about danger, not about any particular person.

Toxic combination

A toxic combination is the same idea seen from the person’s side: a particular set of permissions that, held together, create a serious risk. Some teams use this phrase for conflicts of the highest severity.

Violation

A violation happens when a specific person actually holds the conflicting set. A conflict rule is the definition. A violation is a real person who breaks it.

Preventive and detective controls

A preventive control stops a violation from forming, such as blocking a request that would create it. A detective control finds violations that already exist, such as a regular report. Strong programs use both, because access can also change inside applications without going through the front door.

Maker-checker

Maker-checker, also called the four-eyes principle, means one person prepares or makes a change and a different person checks and approves it. The maker cannot be the checker.

Dual control

Dual control means an action needs two people acting together, like the two-key vault. It is a stronger form of maker-checker for the highest-risk acts.

Compensating control

Sometimes a conflict cannot be removed, for example in a small team with too few people. A compensating control is an extra safeguard that reduces the risk, such as a manager reviewing every transaction the person makes, or enhanced monitoring with alerts.

Exception and mitigation

An exception is a recorded, approved decision to allow a violation for a limited time and reason. Mitigation is the set of extra safeguards applied while the exception lasts. Exceptions without mitigation, or without an end date, are just violations with paperwork.

Inherent and residual risk

Inherent risk is the danger before any safeguards. Residual risk is what remains after safeguards. Good SoD work lowers residual risk to a level the business accepts on purpose.

SoD in an Okta environment shows up in three different places. Mixing them up is the most common source of confusion, so it helps to separate them early.

Place one: business permissions inside applications

This is the classic case. Applications such as finance, procurement, human resources, and customer systems have permissions that map to business duties. Conflicts here are between those permissions, for example creating and approving payments. Okta’s governance features aim to describe these permissions, learn who holds them, and help check for conflicts. This is where most audit attention goes.

Place two: administrative power over Okta itself

Okta has its own administrators, who can create users, change policies, assign applications, and reset sign-in factors. Some of these powers should not be combined. For example, a person who can edit sign-in policies and also reset anyone’s authentication factors could weaken the rules and then walk through them. Okta offers a range of administrator roles, and in many releases the ability to build custom roles and limit them to chosen sets of resources. Using these to split administrative powers is SoD applied to the identity platform itself.

Place three: the governance process

The process that grants access can itself be abused. A person must not approve their own access request, review their own access, or be the only person able to change the rules that decide who gets what. Applying SoD to requesting, approving, reviewing, and rule changes protects the control system from being bypassed.

flowchart TD
    SOD["Segregation of duties"] --> BIZ["Business permissions
inside applications"]
    SOD --> ADM["Administrative power
over Okta itself"]
    SOD --> PRC["Governance process
request, approve, review, change rules"]
    BIZ --> E1["Example: create vs approve payment"]
    ADM --> E2["Example: edit policy vs reset factors"]
    PRC --> E3["Example: requester is not the approver"]
    

Not all conflicts look alike. Knowing the shapes helps you spot them and choose the right control.

Conflicts inside one application

The simplest kind. One application offers two permissions that conflict, such as “create purchase order” and “approve purchase order”. The application may even warn about it. Still, because administrators often grant roles carelessly, these conflicts occur regularly.

Conflicts across applications

The harder and more dangerous kind. A person holds “create vendor” in a procurement system and “release payment” in a finance system. No single application sees the pair. Only a cross-system view can. This is where an identity platform adds the most value.

Conflicts through groups and roles

A person may hold a conflict without anyone choosing it directly. Being in two groups, each of which includes one of the conflicting permissions, creates the pair indirectly. Detection must look at what a person effectively holds, not only at what was explicitly requested.

Conflicts over time

A person may hold one power now and be granted the second months later, when nobody remembers the first. Or they may use one power in the morning and be handed the other temporarily in the afternoon. Good controls consider the whole history and the duration of temporary grants.

Conflicts in process roles

Requesting, approving, and reviewing roles can overlap. A manager who requests access for a team member and also approves it, or an owner who reviews their own permission, breaks the idea of independent checking.

Conflicts in administration

An administrator who can both change the rules and grant themselves exemptions from them holds a conflict in the control system itself.

Conflicts that involve non-human accounts

Service accounts and automation also hold powers. A single automated account that can both create and approve transactions is a conflict, even though no human sits at a keyboard. Owners of such accounts deserve the same attention.

flowchart LR
    P["One person"] --> A1["Procurement app
create vendor"]
    P --> A2["Finance app
release payment"]
    A1 -.->|"No single app sees both"| X["Hidden conflict"]
    A2 -.-> X
    X --> ID["Identity platform
cross-system view finds it"]
    

Before software can check anything, people must decide what counts as a conflict. The tool for that is the conflict matrix.

What a matrix is

A conflict matrix is a grid. Down the side and across the top you list duties or permissions. In each cell you note whether the pair is allowed, forbidden, or allowed only with extra safeguards. It is a plain table that makes the company’s decisions visible in one place.

How to build one

• Start from processes, not permissions. Walk through important business processes such as buying, paying, hiring, and releasing software. Mark the steps where value moves or records change.
• Name the duties. Give each step a clear duty name, such as “create supplier”, “approve invoice”, or “release payment”.
• Pair the dangerous ones. Ask for each pair: if one person held both, what is the worst that could happen, and how would we notice?
• Rank them. Mark each pair high, medium, or low severity.
• Map duties to permissions. For each application, list which permissions give each duty. This step is detailed and needs application owners.
• Agree with the business. Have process owners, risk, and audit confirm the matrix.

Keep it small at first

A matrix with hundreds of cells is impossible to maintain and fills reports with noise. Start with the handful of highest-severity pairs. A short list that is enforced beats a long one that is ignored. Expand gradually as you learn.

Decide the response for each pair

Each pair should have an agreed response: block entirely, allow with an exception and safeguards, or allow with monitoring. Writing this down now saves arguments later.

flowchart TD
    PR["Map business processes"] --> DU["Name the duties"]
    DU --> PA["Pair duties that are dangerous together"]
    PA --> RK["Rank by severity"]
    RK --> MP["Map duties to application permissions"]
    MP --> AG["Agree with process owners, risk, and audit"]
    AG --> LIB["Publish as the conflict library"]
    

SoD is often confused with its neighbours. Each answers a different question, and they work best together.

Least privilege

Least privilege says each person should hold only the powers needed for their job. It limits how much any one person can do. SoD limits which powers can meet in one person. A person could hold few powers (good least privilege) and still hold a dangerous pair (poor SoD), or hold many powers that are all safe together.

Role-based access

Role-based access groups permissions into roles that match jobs. It makes access easier to manage, but a badly designed role can itself contain a conflict. SoD checks should therefore be applied when roles are designed, not only to individuals.

Attribute-based access

Attribute-based access decides using facts such as department, location, or time. It can express rules like “only managers in this region”. It does not by itself notice that a person holds two conflicting powers across systems.

Approval workflows

Approval steps add a human decision to granting access. They help, but an approver may not notice a conflict unless the system points it out. Approvals should be supported by automatic conflict checks.

Reviews and certifications

Periodic reviews catch drift, but a reviewer looking at one permission at a time may not see a conflict that involves another. Reviews should show conflict flags.

flowchart LR
    LP["Least privilege
hold only what you need"] --> SAFE["Safer access"]
    SOD["Segregation of duties
no dangerous pairs"] --> SAFE
    RBAC["Roles and bundles
organized access"] --> SAFE
    REV["Reviews
catch drift"] --> SAFE
    APP["Approvals
human judgment"] --> SAFE
    

The cheapest conflict is the one that never forms. Checking at the moment of a request stops most problems at the door.

The idea

When a person asks for a permission or bundle, the system looks at what they already hold, adds what they are asking for, and compares the result with the conflict library. If a forbidden pair would appear, the request is stopped or flagged before an approver is even bothered. The person is told plainly why, and what they might do instead.

What the check must consider

• Direct holdings: permissions the person holds explicitly.
• Indirect holdings: permissions that come through groups, roles, and bundles.
• Pending requests: requests already in progress, so two requests cannot together slip past the check.
• Temporary grants: access that is time-limited but still active.
• Bundles: a bundle may contain several permissions, and the whole set must be checked.

Clear messages

A block that says only “request denied” frustrates people. A good message says which two duties conflict, why it matters in business language, and who to talk to if there is a real need. Clear messages reduce support calls and teach people the rules.

Soft and hard stops

A hard stop blocks the request completely. Use it for the highest-severity pairs. A soft stop warns the requester and the approvers, and perhaps requires an extra approval, but does not forbid the request. Use it for medium-severity pairs where there are legitimate reasons. Choose the type for each pair on purpose, and write it in the matrix.

Closing the side doors

Prevention at request time works only for access that passes through the request process. Other routes include access granted directly by application administrators, access created through group rules, and access added by automation. Each side door needs its own control, or the front-door check is easy to bypass.

sequenceDiagram
    participant P as Person
    participant O as Okta request process
    participant L as Conflict library
    participant A as Approver
    P->>O: Ask for "Release payment"
    O->>O: Gather current and pending access
    O->>L: Would this create a conflict?
    L-->>O: Yes, high severity with "Create supplier"
    O-->>P: Blocked, with a plain explanation
    P->>O: Ask for "View payment reports" instead
    O->>L: Check again
    L-->>O: No conflict
    O->>A: Send for normal approval
    

Prevention is never complete. Detection finds what slipped through, and what existed before the rules did.

Why violations exist

Old access predates your rules. Application administrators grant access directly. Roles change content over time. People move jobs and keep earlier powers. A system that checks only new requests will never find any of these.

The detection loop

Detection has four steps. First, collect what each person actually holds in each application. This depends on how well the application is connected, and may involve importing the current state. Second, compare the collected access with the conflict library. Third, produce a list of violations, ranked by severity. Fourth, send each violation to someone who can resolve it.

Frequency

Run detection often enough that a new violation does not live long. For high-severity pairs, daily or event-driven checks are reasonable. For medium pairs, weekly or monthly may be enough. Also run detection before every access review, so reviewers see the flags.

Reading the results

A raw list of violations can be overwhelming. Group them by pair, by application, by department, and by age. Patterns appear: one badly designed role may cause hundreds of violations. Fixing that one role is far more effective than chasing each person.

Resolving a violation

For each violation, choose one of three paths. Remove one of the powers. Reassign the duty to a different person. Or record an exception with safeguards. Never leave a violation unassigned and unexplained.

Tracking progress

Count open violations by severity and watch the trend. A steady decline shows the control is working. A sudden rise points to a new cause, such as a role change or a faulty import.

flowchart TD
    COL["Collect actual access from applications"] --> CMP["Compare with the conflict library"]
    CMP --> LST["List violations ranked by severity"]
    LST --> GRP["Group by pair, application, role, age"]
    GRP --> ASG["Assign each violation to an owner"]
    ASG --> RES{"Resolution"}
    RES -->|"Remove a power"| R1["Access removed"]
    RES -->|"Move the duty"| R2["Duty reassigned"]
    RES -->|"Accept with safeguards"| R3["Exception recorded"]
    R1 --> TRK["Track open count and trend"]
    R2 --> TRK
    R3 --> TRK
    

Real organizations sometimes cannot separate every duty. The honest answer is a managed exception, not a hidden violation.

When exceptions are reasonable

A small branch office may have only two staff. A temporary absence may leave one person covering both roles. A system migration may need a short period of wide access. These are real situations. Pretending they do not exist pushes people to share passwords or use unofficial workarounds.

What a good exception contains

• The pair: which conflict is being accepted.
• The person: who holds it.
• The reason: why separation is not possible now.
• The approver: a senior person who accepts the risk, not the person’s own manager alone.
• The safeguards: what extra checks apply while the exception lasts.
• The end date: when it expires or must be renewed.

Examples of compensating controls

• A second person reviews every transaction the individual performs, within a set time.
• Transaction limits cap the amount the person can move alone.
• Alerts notify a manager when the person uses both powers in the same period.
• Regular sampling by internal audit checks the person’s work.
• Extra logging records every action in detail and keeps it safe from editing.

Reviewing exceptions

Exceptions must be visible and reviewed. Report on how many exist, how old they are, and whether their safeguards are actually working. An exception that nobody reviews has quietly become permanent.

Ending exceptions

When the end date arrives, the exception either ends or is renewed with a fresh decision. Renewal should require a new reason. If the same exception is renewed for years, the underlying problem is organizational, and should be fixed by hiring, restructuring, or redesigning the process.

stateDiagram-v2
    [*] --> Detected
    Detected --> Removed : "Power removed"
    Detected --> Proposed : "Exception requested"
    Proposed --> Approved : "Senior approver accepts risk"
    Proposed --> Rejected : "Not accepted"
    Rejected --> Removed
    Approved --> Monitored : "Safeguards active"
    Monitored --> Renewed : "Fresh decision"
    Monitored --> Expired : "End date reached"
    Renewed --> Monitored
    Expired --> Removed
    Removed --> [*]
    

A review that looks at one permission at a time cannot see pairs. SoD-aware reviews show the whole picture.

The weakness of plain reviews

A reviewer sees a line saying “Release payments” for a person and asks, does this person need it? The honest answer may be yes. What the reviewer does not see is that the same person also holds “Create supplier” in another system. Without this knowledge, the reviewer approves a dangerous combination one innocent line at a time.

Flagging conflicts in the review

The review screen should flag any line that is part of a conflict, state the other half of the pair, and show its severity. Reviewers can then keep one and remove the other, or request an exception. Making the flag visible at the point of decision is the most effective improvement you can make to a review.

Who reviews

Managers know what their people do. Owners of each permission know what it allows. A conflict often needs both: the manager chooses which duty the person truly needs, and the owner confirms the permission. Nobody should review their own access or the access of the person who approves their work.

Keeping reviews honest

Measure how reviewers handle flagged items. If flagged lines are approved without comment in seconds, the control is not working. Provide short guidance on what a good decision looks like, and follow up on repeated rubber-stamping.

Closing the loop

When a reviewer removes a power because of a conflict, the removal must reach the application, and the result should be checked. Records of the flag, the decision, and the confirmation form the evidence auditors look for.

flowchart TD
    CAM["Review campaign starts"] --> DET["Run conflict detection first"]
    DET --> SCR["Reviewer sees items with conflict flags"]
    SCR --> DEC{"Decision on flagged item"}
    DEC -->|"Remove one power"| REM["Okta removes access in the application"]
    DEC -->|"Keep with exception"| EXC["Exception request with safeguards"]
    DEC -->|"No decision by deadline"| ESC["Escalate to backup reviewer"]
    REM --> VER["Verify by importing current access"]
    EXC --> VER
    ESC --> SCR
    

The people who run Okta hold some of the most powerful access in the company. SoD applies to them too.

Why administrator power is special

An Okta administrator can create users, assign applications, change policies, reset sign-in factors, and read logs. Misused, these powers could let someone create a ghost account, weaken the rules, sign in as someone else, and cover their tracks. Because this power reaches every connected application, it deserves the strongest controls.

Use the roles Okta provides

Okta offers a range of administrator roles with different scopes, from a full super administrator down to narrower roles for help desk, application management, or reporting. In many releases you can also build custom roles from chosen permissions and limit them to selected sets of resources, such as particular groups or applications. Check your release for what is available. The aim is simple: give each administrator only the powers their job needs.

Keep super administrators few

Super administrator is the all-powerful role. Keep the number very small, use it rarely, and protect those accounts with the strongest sign-in. Day-to-day work should be done with narrower roles.

Pairs to keep apart

• Edit sign-in policies and reset factors for any user: together they can weaken a rule and then bypass the stronger version.
• Assign administrator roles and review administrator access: together they can make themselves powerful and approve it.
• Change governance rules and receive access through those rules: together they can grant themselves access.
• Manage integrations to applications and administer the log or reports: together they can change data and hide the evidence.

Scope matters as much as role

A help desk role limited to one department’s users is far safer than the same role over everyone. Where supported, restrict by resource, not only by role.

Emergency access

Keep a small number of emergency accounts for when normal administration fails. Store their credentials safely, protect them strongly, alert on any use, and review every use afterwards.

flowchart TD
    SA["Super administrator
very few, rarely used"] --> NR["Narrow roles for daily work"]
    NR --> PE["Policy editors"]
    NR --> HD["Help desk, limited scope"]
    NR --> AO["Application owners, own apps only"]
    NR --> GV["Governance team"]
    NR --> RO["Read-only audit and reporting"]
    PE -.->|"Must not also hold"| HD
    GV -.->|"Must not approve own access"| AO
    

A control system that one person can alter alone is only as strong as that person. Apply SoD to the governance process too.

Requester is not approver

No one should approve their own request. The system should enforce this automatically, including cases where someone is both the manager and the owner. When it happens, the approval should pass to someone else.

Approver is not reviewer of their own approval

If a manager approved an access grant, the later review of that access should go to someone else, such as the owner or the manager’s manager. Otherwise the same judgment is simply repeated.

Rule changes need a second person

Changes to conflict libraries, bundles, rules, and workflows alter who can get what. They should follow maker-checker: one person prepares the change, another approves it, and both are recorded. For the most sensitive rules, require approval from a risk or security representative.

Exemptions are decisions, not settings

Marking a person as exempt from a rule is an act of power. It should require approval from someone other than the person asking, and be recorded with a reason and an expiry.

Log protection

Those who can change access should not be able to alter the record of those changes. Keep logs in a protected place with read-only access for most people.

Covering absences safely

Delegation lets someone act for an absent approver. Delegates must not be the requester, and delegation should have an end date. Escalation should go to a person at the right level, never back to the requester.

sequenceDiagram
    participant M as Maker administrator
    participant S as Governance system
    participant C as Checker
    participant L as Protected log
    M->>S: Propose change to a conflict rule
    S->>S: Is the maker also the checker?
    S->>C: Ask for review with impact summary
    C-->>S: Approve
    S->>S: Apply change
    S->>L: Record maker, checker, time, reason
    

An SoD control is a small system of cooperating parts. Seeing each part makes the whole easy to reason about.

The people source

The human resources system and the Okta directory tell the control who exists, what job they hold, and who manages them. This fact base is needed to find owners, to route approvals, and to notice movers.

The permission catalog

The catalog lists the permissions of each connected application, with plain-language names, owners, and sensitivity. Without it, nobody can say what a line in a report means.

The duty map

The duty map connects permissions to business duties. Several permissions in different applications may all mean “release payment”. The map lets the control think in duties, which is how the business thinks.

The conflict library

The library holds the agreed pairs and groups of duties that conflict, with severity, the type of response (block, warn, or monitor), and the owner of each rule. It is the heart of the control.

The access picture

This is the current record of who holds what, gathered from Okta assignments and from applications. It must include indirect access through groups and bundles, and temporary grants.

The checking engine

The engine compares the access picture with the conflict library. It runs at request time to prevent conflicts, and on a schedule to detect them. It produces either a decision (allow, warn, block) or a list of violations.

The workflow engine

The workflow engine handles approvals, exceptions, reviews, reminders, and escalations. It makes sure each violation reaches a person who can resolve it.

The evidence store and reports

Everything that happens is recorded in a protected store, and reports turn the record into views for executives, owners, and auditors.

flowchart TD
    HR["People source
HR and directory"] --> PIC["Access picture
who holds what, direct and indirect"]
    APPS["Applications
current permissions"] --> PIC
    CAT["Permission catalog"] --> DUT["Duty map"]
    DUT --> LIB["Conflict library"]
    PIC --> ENG["Checking engine"]
    LIB --> ENG
    ENG -->|"Request time: allow, warn, block"| WF["Workflow engine"]
    ENG -->|"Scheduled: list of violations"| WF
    WF --> EVI["Evidence store and reports"]
    

The hardest and most valuable work in an SoD program is translating application permissions into business duties.

Why this step is hard

Applications name permissions in their own ways, often with codes. One application may have a role called “AP Clerk Level 2” that quietly includes five different abilities. Understanding what it truly allows requires talking to application owners and sometimes reading vendor documentation.

The process

• List the permissions. For each in-scope application, list every role, permission, and group that matters.
• Describe in plain words. Write what each lets a person do. If the owner cannot say, investigate.
• Assign duties. Tag each permission with one or more duty names from your shared vocabulary.
• Confirm with owners. The owner of each permission signs off on the tags.
• Maintain. Re-check when applications release updates, because permissions change meaning.

Beware of hidden power

Some permissions are broader than their names suggest. An “administrator” role in a finance tool might include everything. A “support” role may allow editing records. Always read the details, and assume names understate power.

Shared vocabulary

Agree a short, consistent list of duty names across the company, such as create vendor, approve invoice, release payment, change employee pay, and deploy code. A shared vocabulary lets conflicts be defined once and applied across all applications.

Start narrow

Map only the applications and permissions that take part in your highest-severity conflicts first. Expanding later is easy. Mapping everything at once is exhausting and rarely finishes.

flowchart LR
    P1["Procurement: Supplier Admin"] --> D1["Duty: Create vendor"]
    P2["Finance: AP Clerk Level 2"] --> D2["Duty: Create invoice"]
    P3["Finance: AP Approver"] --> D3["Duty: Approve invoice"]
    P4["Banking: Releaser"] --> D4["Duty: Release payment"]
    D1 -.->|"Conflict"| D4
    D2 -.->|"Conflict"| D3
    

Not every conflict deserves the same urgency. Ranking tells you where to spend limited time first.

Factors that raise risk

• Impact: how large the harm could be, in money, data, or reputation.
• Likelihood: how easy it would be to misuse the pair without being noticed.
• Visibility: whether other controls such as limits or reviews would catch the misuse.
• Number of people: how many hold the pair.
• Seniority and reach: whether the person can override other controls.
• Age: how long the conflict has existed.

A simple scale

Use a small scale, such as low, medium, high, and critical, with clear descriptions of each. Too many levels invite endless debate. A shared simple scale lets teams agree quickly and treat similar cases alike.

Using scores

Scores decide the response: critical pairs are blocked, high pairs need senior approval and monitoring, medium pairs need a manager’s acknowledgement and review, and low pairs are only noted. Scores also decide the order of cleanup, so the most dangerous violations are fixed first.

Revisiting scores

Risk changes. New systems are added, limits are changed, and processes evolve. Review the scale and the ranking of important pairs at least once a year with risk and audit.

flowchart TD
    V["Violation found"] --> I{"Impact if misused?"}
    I -->|"Major"| L{"Other controls catch it?"}
    I -->|"Moderate or small"| M["Medium or low"]
    L -->|"No"| C["Critical: block and remove"]
    L -->|"Partly"| H["High: senior exception and monitoring"]
    M --> N["Manager acknowledgement or record only"]
    

The best time to deal with a conflict is when a role is designed. A role that is conflict-free by design never creates the problem.

Check at design time

Before publishing a role or bundle, run the conflict library against its contents. If the role itself contains a forbidden pair, everyone who receives it becomes a violation. Fixing one role is far cheaper than fixing hundreds of people.

Split roles along duty lines

Design roles around one side of a process. Instead of one “Accounts Payable” role that can enter and approve, create “Accounts Payable Preparer” and “Accounts Payable Approver”. People then hold one or the other, and the system can stop anyone requesting both.

Keep powerful duties separate

Do not bury a dangerous duty in a large role. Keep releasing payments, changing pay, and administering rules as their own small items, so they are visible and can be reviewed and time-limited.

Test combinations of roles

Roles that are safe alone may conflict together. Test likely combinations, such as the role a person is likely to hold with the extras they often request.

Review roles as they change

Roles grow as applications add features. Re-run the conflict check on every change, and on a regular schedule. Roles that were safe last year may not be safe now.

flowchart TD
    OLD["Old role: Accounts Payable
enter and approve invoices"] --> SPL{"Split along duty lines"}
    SPL --> PREP["Role: AP Preparer
create invoice"]
    SPL --> APR["Role: AP Approver
approve invoice"]
    PREP -.->|"Request both is blocked"| APR
    

Conflicts often arise during change. People who move between jobs are the usual carriers.

Joiners

New staff receive access from baseline and role bundles. Because these were checked at design time, they should be conflict-free. Extra requests should pass the request-time check.

Movers

A person who moves from accounts payable to procurement may keep their invoice approval and gain the right to create suppliers. Neither was wrong on its own; together they are a classic conflict. Movers need a deliberate step: remove the old role’s access, then check the remaining access against the new role. Pay special attention to access that was requested rather than assigned by rule, as it will not disappear by itself.

Leavers

Leavers lose all access, which ends their conflicts. But also consider the duties they performed. If a leaver was the only approver of something, the duty needs a new home, and a hasty reassignment can itself create a new conflict.

Temporary cover

Holiday and sickness cover is a major source of temporary conflicts. A cover grant should check conflicts like any other, have an end date, and be removed automatically. Where a conflict cannot be avoided, use a recorded exception with safeguards.

Contractors and partners

Contractors may hold powerful access for short projects. Apply the same checks, name a sponsor who vouches for them, and end access on the contract end date.

Reorganizations

When teams merge or split, many people move at once. Plan a conflict scan before and after, and expect a spike in violations that needs clearing.

sequenceDiagram
    participant HR as HR system
    participant O as Okta
    participant M as New manager
    participant E as Conflict engine
    HR->>O: Person moves from payables to procurement
    O->>O: Withdraw rule-based access of old role
    O->>M: Re-confirm requested access
    M-->>O: Keep invoice approval? No, remove
    O->>O: Assign procurement role bundle
    O->>E: Scan combined access
    E-->>O: No conflicts found
    

SoD projects stall when they try to fix everything at once. A phased path builds trust and results.

Phase 1: Agree on the problem

Gather risk, audit, finance, and application owners. Choose the processes that matter most, such as paying suppliers and running payroll. Agree on goals, scope, and how success will be measured.

Phase 2: Build the matrix

Create a small conflict matrix for the chosen processes. Rank the pairs. Decide the response for each: block, warn, or monitor.

Phase 3: Map and connect

Map the relevant permissions to duties for the first applications. Connect them to Okta so that current access can be imported.

Phase 4: Measure the baseline

Run a first detection scan, with no enforcement. Count violations by severity and application. Share the results. The baseline shows the size of the problem and the value of fixing it.

Phase 5: Clean and prevent

Fix badly designed roles, remove unneeded powers, and record exceptions. Then turn on request-time checks for the highest-severity pairs.

Phase 6: Embed in reviews and change

Add conflict flags to reviews, add checks to mover and cover processes, and apply maker-checker to governance changes and administrator roles.

Phase 7: Expand and improve

Add more applications and more pairs. Track metrics. Retire rules that no longer apply. Review the matrix yearly.

flowchart LR
    S1["Agree"] --> S2["Matrix"]
    S2 --> S3["Map and connect"]
    S3 --> S4["Baseline scan"]
    S4 --> S5["Clean and prevent"]
    S5 --> S6["Embed in processes"]
    S6 --> S7["Expand"]
    S7 -.->|"Yearly review"| S2
    

Examples make ideas stick. Each one below follows a situation step by step.

Example 1: The supplier and the payment

Meera works in procurement and holds the permission to create and edit suppliers. One day she asks for the permission to release payments in the banking portal, because her colleague who normally does it is on leave. Okta gathers what she holds, notices the supplier permission, and compares the pair with the conflict library. The pair “create vendor” and “release payment” is marked critical with a hard block. The request is stopped before any approver sees it. Meera sees a plain message that explains the reason: one person could set up a fake supplier and then pay it.

Her manager reads the same message, then asks a different colleague in finance to cover the releasing duty for the week. No conflict is created, and the work still gets done.

Example 2: The old role that hid a pair

A detection scan finds that two hundred people hold both “enter invoices” and “approve invoices” in the finance application. Nobody asked for both. The cause is a single old role called “Accounts Payable” that includes both abilities. The team splits it into a preparer role and an approver role, reassigns people to the one they truly need, and records three small exceptions for a tiny branch office with safeguards. Two hundred violations are cleared by fixing one role.

Example 3: The administrator who edits policy and resets factors

During an administrator review, a security engineer is found to hold both the right to edit sign-in policies and the right to reset factors for any user. This pair is rated high. The team splits the roles: policy editing stays with the security engineering team, and factor reset moves to a help desk role that is limited to certain groups. The engineer keeps policy editing. Changes to policies now require a second person to approve.

Example 4: The mover

Rahul moves from accounts payable to procurement. Rule-based access for his old role is withdrawn automatically. He still holds “approve invoices”, which he once requested for a special project. Okta asks his new manager to re-confirm it. The manager sees a flag showing that invoice approval conflicts with supplier creation, which Rahul has just received in his new role. The manager removes the approval. A conflict that would have lasted for years is prevented in a minute.

Example 5: A fair exception

A two-person branch in a remote town needs one person to both prepare and approve small local payments. The risk team agrees to an exception for six months. Safeguards are set: a limit on the amount, a weekly review of all payments by the regional manager, and an alert if any payment is near the limit. At the end of six months, the exception is reviewed. A new part-time clerk has joined, so the duties can be separated and the exception ends.

sequenceDiagram
    participant R as Rahul
    participant O as Okta
    participant M as New manager
    participant E as Conflict engine
    O->>O: Rahul moves, old role access withdrawn
    O->>M: Re-confirm invoice approval requested earlier
    M->>E: Is it safe with supplier creation?
    E-->>M: Conflict, critical
    M-->>O: Remove invoice approval
    O->>R: Notify of the change with reason
    

A control that decides who may hold which power is itself a target. Attackers and insiders will look for ways around it.

Protect the conflict library

If someone can quietly delete a conflict rule, they can quietly make a violation legal. Limit who can edit the library, require a second approver for every change, and alert on any change to high-severity rules.

Protect the duty map

A permission tagged with the wrong duty, or with no duty, hides conflicts. Treat edits to the duty map as sensitive. Review changes, and compare the map with application releases.

Protect the data feeding the control

The control relies on accurate access data. If an import is incomplete, the control believes people hold less than they do. Monitor the health of imports, and alert when a connection fails or returns suspiciously little data.

Watch for splitting tricks

A person who wants both powers may try to obtain them in small steps through different routes, or through two accounts. Look at combined access per person, not per request, and consider linking multiple accounts that belong to one human.

Watch for collusion

SoD stops one person from acting alone. It does not stop two people who agree to cheat together. Collusion is reduced by rotating duties, by sampling transactions, and by watching for patterns such as the same pair always approving each other’s work.

Secure non-human accounts

Service accounts and automation hold powers too. Give each an owner, check them against the conflict library, and avoid giving one account both sides of a process.

Protect evidence

Records of requests, exceptions, and decisions must resist alteration. Store them where the people they describe cannot edit them, and keep them for as long as your rules require.

flowchart TD
    A["Change to a rule, map, or exception"] --> B["Strong authentication of the actor"]
    B --> C["Authorization: may this person edit?"]
    C --> D["Second person approves"]
    D --> E["Change applied"]
    E --> F["Protected audit record"]
    F --> G["Alert on high-severity changes"]
    

You cannot manage what you cannot see. A few good measurements tell you whether the control works.

What to log

Record each request check and its result, each detected violation, each decision about it, each exception and its safeguards, each change to the library or the duty map, and each use of emergency or highly privileged access. Include who, when, and why.

Metrics that matter

• Open violations by severity, application, and age.
• New violations per week and their causes.
• Blocked requests, which show prevention working.
• Active exceptions, their age, and how many have expired without renewal.
• Time to resolve a violation after detection.
• Review quality: the share of flagged items removed, and the speed of decisions.
• Coverage: the share of in-scope applications and permissions that are mapped and connected.
• Import health: how fresh and complete the access data is.
• Administrator conflicts: number of administrators holding conflicting powers.

Alerts

Alert on new critical violations, on any change to a high-severity rule, on exceptions near expiry, on failed or empty imports, and on use of emergency access. Send alerts to people who can act, not to a mailbox nobody reads.

Reports for different readers

Executives want a few lines that trend: fewer violations, faster resolution. Process owners want lists for their own areas. Auditors want evidence for samples. Provide a view for each.

flowchart LR
    EV["Events and checks"] --> LOG["Protected log"]
    LOG --> MET["Metrics"]
    MET --> DASH["Dashboards by audience"]
    MET --> ALR["Alerts to action owners"]
    DASH --> EX["Executives: trends"]
    DASH --> PO["Process owners: their lists"]
    DASH --> AU["Auditors: evidence"]
    

Many organizations start SoD programs because auditors have asked hard questions. Good design turns those questions into routine reports.

What auditors typically ask

They ask which pairs of duties you consider conflicting and why, how you prevent them, how you detect existing ones, how many exist today, how exceptions are approved and monitored, and how you know the data is complete. They may select a sample of people and ask for proof of everything they hold and every approval.

Evidence by design

Produce evidence as a by-product of normal work. The conflict library with approvals, the duty map with owner sign-offs, scan results with dates, exception records with safeguards, and review decisions with timestamps together form a complete story. When the audit arrives, you export; you do not reconstruct.

Different frameworks, similar asks

Financial reporting rules, security standards, and privacy laws differ in detail, but they all expect separation of conflicting duties or compensating controls, controlled access to sensitive functions, periodic review, and evidence. Map your control once to each framework, then reuse the evidence. Your own audit and compliance teams will tell you which frameworks apply.

Testing the control yourself

Do not wait for auditors. Periodically test your own control. Try to request a conflicting pair in a test environment and confirm it is blocked. Create a known violation and confirm the scan finds it. Approve your own request and confirm the system refuses. These small tests catch gaps early.

Privacy

Access data is personal data. Limit who can see reports, keep what you need, and follow retention rules.

Technology is the easy half. Deciding who is responsible for what makes the control last.

Who does what

• Risk and compliance: own the conflict library, severity scale, and policy on exceptions.
• Process owners: understand the business processes and confirm which duties conflict.
• Application owners: describe permissions, sign off the duty map, and fix badly designed roles.
• Identity platform team: builds connections, runs checks and scans, maintains workflows.
• Managers: resolve violations for their people and approve exceptions at the right level.
• Internal audit: independently tests the control.
• Employees: request what they need and tell the truth about their duties.

Keep the library alive

Processes change, and so do conflicts. Schedule a yearly review of the matrix with process owners and audit. Retire rules that no longer apply and add new ones for new processes.

Service levels

Set targets that people can meet: critical violations resolved within days, high within weeks, exceptions reviewed before they expire. Report against the targets.

Training and communication

Explain to employees why some requests are blocked, and give them a path when the block is wrong. Explain to managers and owners how to resolve a violation and what a good exception looks like. An organization that understands the reason follows the rule willingly.

Avoid a culture of workarounds

If the control is slow or confusing, people will find ways around it, such as sharing passwords or asking colleagues to act for them. Keep the process quick, give clear messages, and offer reasonable alternatives.

flowchart TD
    RISK["Risk and compliance
library and policy"] --> PLAT["Identity platform team
checks, scans, workflows"]
    PROC["Process owners
confirm duties"] --> RISK
    APPO["Application owners
permissions and roles"] --> PLAT
    PLAT --> MGR["Managers
resolve and approve"]
    MGR --> EMP["Employees"]
    AUD["Internal audit
independent testing"] -.-> RISK
    AUD -.-> PLAT
    

SoD gives real protection, and it has real costs. A fair picture helps you decide how far to go.

Key trade-offs

flowchart TD
    N["A conflicting pair is found"] --> S{"Severity"}
    S -->|"Critical"| A1["Block and remove"]
    S -->|"High"| A2["Senior exception with safeguards"]
    S -->|"Medium"| A3["Manager acknowledgement and review"]
    S -->|"Low"| A4["Record and observe"]
    

A pattern is a proven answer to a problem that keeps coming back. These patterns keep SoD simple and effective.

Pattern: Start with processes, not permissions

Begin from business processes and the duties inside them. Permissions come later. This keeps the control focused on real risk instead of on a pile of technical names.

Pattern: Small library, strongly enforced

Start with the few most dangerous pairs and enforce them firmly. Add more as you learn.

Pattern: Prevent, detect, review

Use three layers: block at request time, scan on a schedule, and flag conflicts in reviews. Each covers gaps in the others.

Pattern: Split roles along duty lines

Design roles around one side of a process, such as preparer and approver, so that conflicts cannot form from a single role.

Pattern: Fix the cause

When many people share a violation, find the single role, group, or rule that created it and fix that.

Pattern: Bounded exceptions

Every exception has a reason, a senior approver, safeguards, and an end date. Renewal requires a fresh decision.

Pattern: Maker-checker everywhere that matters

Apply the four-eyes rule to rule changes, exemptions, administrator roles, and high-risk approvals.

Pattern: Check at every change

Run conflict checks on requests, movers, temporary cover, and reorganizations. Change is where conflicts are born.

Pattern: Guard the guards

Review administrator and governance access more often than any other access.

flowchart TD
    DES["Design: roles split along duty lines"] --> REQ["Request: conflict check at the door"]
    REQ --> MOV["Change: check movers and cover"]
    MOV --> SCN["Detect: scheduled scans"]
    SCN --> REV["Review: conflict flags shown"]
    REV --> EXC{"Cannot separate?"}
    EXC -->|"Yes"| BND["Bounded exception with safeguards"]
    EXC -->|"No"| FIX["Remove or reassign the power"]
    BND --> MON["Monitor and report"]
    FIX --> MON
    

An anti-pattern is a habit that seems sensible but causes trouble later. Each card below shows one, why it hurts, and a better way.

This chapter gathers the habits that separate calm programs from chaotic ones.

Best practices

Common mistakes

These short stories use made-up companies to show how the ideas appear in daily work. They are teaching examples, not descriptions of any real organization.

What the scenarios share

Each story was solved with the same habits: plain conflict rules, a duty map, a baseline scan, role fixes, bounded exceptions, maker-checker on governance, and checks at every change. None needed anything exotic. They needed discipline and a willingness to look.

Short answers to common questions. Where details depend on your license or release, confirm them in your own console and the official documentation.

Here is the whole story in a few lines you can carry with you.

Segregation of duties is the simple idea that dangerous powers should not meet in one person, and that important acts should need a second pair of eyes. In an Okta environment it applies in three places: the business permissions inside applications, the administrative power over Okta itself, and the governance process that grants access. Because Okta sees access across many systems, it can reveal combinations that no single application can see.

The craft lies in a few steady habits: start from business processes, keep a small and ranked conflict library, map permissions to shared duties, prevent at request time, detect with regular scans, show conflicts in reviews, split roles along duty lines, bound every exception with safeguards and an end date, apply maker-checker to governance and administrators, and check every change. With these, the control stays understandable, auditors get evidence they can trust, and honest people are protected from mistakes and from each other’s temptations.