Separation of Duties in IAM: how to enforce SoD across SaaS

This guide is for IT and security leads at companies of 50 to 500 people who have just been asked, by an auditor or by an enterprise customer, to prove that no single person can both request an access and approve it. If you are looking for separation of duties in accounts payable or in the purchasing cycle, this is not the page you need.

Separation of duties in IAM is the control that stops one person from holding a combination of permissions that lets them complete a sensitive process alone, such as creating a vendor and approving its payment, or requesting an access and granting it. In a mid-market SaaS environment the conflict is rarely inside one application: it is spread across the HR system, the finance tool, the code repository and the identity provider, which is why manual review misses it. Enforcing it means writing down which permission pairs are forbidden, detecting who currently holds them across every connected and unconnected app, and proving to an auditor that you found and fixed them. Role-based access control and scheduled access reviews are how that gets done in practice.

What is separation of duties in IAM, and is it the same as segregation of duties?

Yes, they are the same control, and the naming splits by standards family rather than by meaning. The NIST Computer Security Resource Center glossary lists SoD as an abbreviation of separation of duty and defines it, citing NIST SP 800-192, as the principle that no user should be given enough privileges to misuse the system on their own. ISO/IEC 27001:2022 names the same idea segregation of duties in Annex A control 5.3. COSO, the accounting framework, also says segregation. Nothing turns on the choice of word, and any page that sells you a distinction between the two is selling you a distinction the standards bodies do not make.

What does turn on something is the difference between the accounting version of the control and the IAM version. They share a principle and share almost nothing else in execution.

NIST also gives you the two enforcement modes you will be asked about. Static enforcement defines conflicting roles that cannot be executed by the same user, so the conflict is impossible by construction. Dynamic enforcement applies the control at access time, and its best known form is the two-person rule, where the second approver can be any authorized user other than the first. Most mid-market stacks end up with a mix: static where the identity provider can express it, dynamic where only the application can.

Why separation of duties breaks in a mid-market SaaS stack

The classic SoD literature was written for a world with one financial system. A conflict was contained: the same ERP that created the permission could also report on it. That world is gone for a company running 80 to 300 SaaS applications, and the control breaks in three specific ways.

First, the conflict is now distributed. Nobody grants one person the right to both create and pay a vendor inside a single tool. What happens instead is that someone is a finance admin in one product and a payment approver in another, and no console on either side can see the pair. Second, part of the estate is not federated. Applications bought on a card by a team lead never touch the identity provider, so they are invisible to any review driven from the IdP. Third, the permissions move constantly, because people change teams. A conflict created by an internal transfer in March will still be there in December if nothing revokes the old entitlements.

The competitor literature has not caught up with any of this. We scraped the eight editorial pages ranking in the top 20 for this term in August 2026 and counted term occurrences by script. SCIM appears zero times across all eight. So do joiner-mover-leaver, offboarding and SaaS sprawl. Shadow IT appears once, in one page. The guides that currently define this topic on Google describe a control surface that most of their readers no longer have.

There is a second signal worth reporting, because it changes who you should imagine reading this. In Corma's own Search Console data for the twelve months to 15 August 2026, the query separation of duties returned six impressions at an average position of 54. The single strongest query in the entire segregation-of-duties field was not a keyword at all. It was a sixty-word prompt written in the first person by a compliance director describing a bank that needed to eliminate manual access reviews, stay continuously compliant, and enforce segregation of duties across hybrid systems. That one prompt returned 38 impressions at an average position of 2.7. People with a real SoD problem are no longer typing the term. They are describing their situation to an assistant in full sentences.

Answering that reader means starting from the stack, not from the definition. That starts with knowing what is actually in the estate, which is where SaaS discovery across your stack comes in: you cannot write a conflict rule for an application you do not know you have.

What does an SoD conflict look like in a SaaS stack?

An SoD conflict, often called a toxic combination, is a pair of permissions that lets one identity complete a sensitive process end to end without a second pair of eyes. Three of the pages currently ranking tell you to build a matrix of these pairs. None of them shows one for software applications. The only matrix published anywhere in the top 20 maps purchase requisitions and purchase orders, which is useful if you run procurement and useless if you run IT.

Here is the version we could not find anywhere, expressed in the applications a mid-market company actually runs. Treat it as a starting set to adapt, not a standard.

Read the last column again, because it is the point of the whole table. Every one of these conflicts is invisible from inside either application. That is not a discipline problem or a policy problem. It is a data problem, and it is the reason the control fails in practice long before anyone gets lazy about it.

It is also worth naming what the risk has actually become. The classic SoD literature is built around financial fraud, and two of the pairs above are still exactly that: the fake vendor and the diverted salary. The other five are not. They are privilege escalation, unlogged change and ghost identities, which are security failures rather than accounting ones. That shift matters organisationally, because an SoD programme owned entirely by finance will catch the two conflicts finance already understands and miss the five that live in IT.

How do you enforce SoD with a two-person IT team?

This is the question the ranking guides avoid, and it is the one actually being asked. On r/sysadmin, an administrator running a two-person team for around 160 users asks how to structure accounts to satisfy separation of duties at all. On another thread, a small vendor going through a SOC 2 Type II audit reports that the customer's SoD expectations are close to impossible to meet at their size. Neither thread gets a clean answer, and the eight pages we measured never use the words mid-market, SME or small and medium even once.

The honest answer is that you cannot separate every duty, and the standards already know that. The 2017 Trust Services Criteria behind SOC 2 carry a point of focus under the control activities criterion that says management segregates incompatible duties and, where such segregation is not practical, management selects and develops alternative control activities. The framework itself gives you the escape hatch. The audit question is therefore not whether you separated everything. It is whether you identified what you could not separate, documented that decision, and put a detective control behind it.

In practice that means four moves. Write down the conflicts you accept and why, naming the constraint rather than hiding it. Replace prevention with detection where you have no second person, for example a monthly review of every action taken with an admin account rather than a rule that stops it. Push approval outside IT wherever the business owner exists, so the finance lead approves finance entitlements instead of the sysadmin approving their own. And make the residual risk visible upward, because an accepted risk that the board has never seen is not an accepted risk.

The reorganisation cost is real, and it lands on onboarding and offboarding first. Adrien Guichard, CEO of Citel, a 400-person manufacturer, describes the outcome his team was after in the IT governance at CITEL Guichard case study: streamlining onboarding and offboarding while enhancing security through fine-grained access controls, from a single unified system. Fine-grained is the operative word. You cannot enforce a permission pair with a role that grants forty things at once.

How to enforce SoD with RBAC, access requests and access reviews

Enforcement is a sequence, and skipping a step is why most SoD programmes stall at the policy document. Here is the order that works.

1. Inventory the estate, including what is not federated. Any application outside the identity provider is outside the control. Discovery has to cover what was adopted in the browser and on the machine, not just what has an SSO connector.
2. Write the conflict rules before the roles. Take the matrix above, cut what does not apply, add what does. Ten well-chosen pairs beat a hundred inherited from an ERP template.
3. Express what you can as static enforcement in roles. This is where role-based access control earns its keep: if two entitlements can never coexist, they must never sit in the same role. Define roles narrowly enough that a conflict is expressible.
4. Route the rest through approval at request time. Dynamic enforcement means the request goes to someone who is not the requester. Automated access request workflows are what stop the informal Slack message from becoming the approval trail.
5. Detect the conflicts you could not prevent, on a schedule. This is the access review, and it is the only step that catches conflicts created by internal transfers, by an unfederated app, or by a rule you wrote after the entitlement was granted.
6. Close the loop with revocation and evidence. A review that identifies a conflict and does not revoke anything produces an audit finding rather than preventing one.

Step five is where the manual approach collapses, and the people doing the work say so plainly. Alex Reintjes, IT Support Engineer at Robovision, describes the gain from automation in terms of time on manual tasks like access reviews rather than in terms of security posture. That is the honest framing: the control is not hard to understand, it is hard to run on a schedule with a small team. Moving it onto automated and compliant access reviews is what turns an annual scramble into a control that actually operates.

What SOX, ISO 27001, SOC 2 and NIS2 actually require on SoD

Almost every guide on this topic states that SoD is required by SOX, ISO 27001, SOC 2 and, in at least one case we checked, the GDPR. That last claim is false. The GDPR requires appropriate technical and organisational measures under Article 32 and does not contain the words segregation of duties or separation of duties anywhere. The rest are true but not in the way the sentence implies, and the difference matters when an auditor asks you to point at the requirement.

Read down the first column with your own company in mind. If you are a European company of 50 to 500 people, SOX almost certainly does not apply to you and ISO/IEC 27001, SOC 2 and NIS2 probably do. That is close to the opposite of the emphasis you will find in most guides on this topic, which lead with SOX because the literature was written for US public companies. For a fuller picture of how the governance layer fits together, our review of IGA solutions for mid-market companies covers the platform side of the same question, and the how security teams stay compliant across SaaS page covers the operating side.

Producing SoD evidence your auditor will accept

Auditors do not assess your intentions, they assess artefacts. Four of them carry an SoD control, and each one has a failure mode worth knowing about.

• The conflict register. Your named list of forbidden permission pairs, with an owner and a date. Failure mode: it exists as a slide and not as a maintained document.
• The accepted-conflict log. Conflicts you cannot separate, each with the constraint, the compensating control and the approver. Failure mode: silence, which reads as an undetected gap rather than an accepted risk.
• Review records with outcomes. Who reviewed which entitlements, when, and what was revoked as a result. Failure mode: a review with a hundred percent approval rate, which auditors read as rubber-stamping.
• The audit trail of changes. Every grant, change and revocation, timestamped, ideally not editable by the person who made the change. Failure mode: logs held in the application whose admin is the subject of the review.

Note that three of the four are records of the control operating over time, not descriptions of the control. This is the single most common reason a first SOC 2 or ISO 27001 audit goes badly on access: the policy is fine and there is nothing to show that anyone ran it.

How Corma helps you enforce separation of duties

Corma is a European SaaS management and identity governance platform for companies of 50 to 500 people, built so that the access control layer and the application inventory sit in the same system. That matters for SoD specifically, because the conflicts in the matrix above only become visible when both halves of the pair are in the same view.

Concretely, Corma builds a continuously updated inventory of applications, identities and entitlements that covers federated, unfederated and shadow IT applications, so conflict rules can reach applications that never touch the identity provider. It routes access requests to an approver other than the requester, which is the dynamic enforcement half of the control. It guides requests toward least-privilege access and enforces role-based access control, which is the static half. It automates joiner-mover-leaver changes, which is what stops an internal transfer from silently creating a conflict. And it runs scheduled access reviews with the entitlement context reviewers need, producing the review records and audit trail an assessor will ask for. Corma is ISO/IEC 27001:2022 certified and hosted in the European Union, which is the same evidence question one level up.

You can see how the pieces fit on the identity governance and administration platform page, and the short definition of the control lives in our SoD definition in the IT glossary. If you want to see your own conflicts rather than a matrix of generic ones, request a demo and we will walk your stack.

Frequently asked questions

What is the difference between segregation of duties and separation of duties?

There is no difference in meaning. NIST publications use separation of duties, while ISO/IEC 27001 and the accounting frameworks use segregation of duties. Both name the control that prevents one person from holding enough privileges to complete a sensitive process alone.

What are the key principles of separation of duties?

No single identity holds a conflicting permission pair. Conflicts are defined in advance rather than discovered during an audit. Prevention is applied where the systems can express it, and detection is applied where they cannot. Every conflict that cannot be separated is documented and given a compensating control.

Can a small company implement separation of duties?

Yes, but not completely, and the standards allow for that. The Trust Services Criteria state that where segregation is not practical, management selects and develops alternative control activities. A small team satisfies an audit by documenting which duties cannot be separated and monitoring those activities, not by pretending they were separated.

Does ISO 27001 require segregation of duties?

Yes. ISO/IEC 27001:2022 includes segregation of duties as Annex A control 5.3, with implementation guidance in ISO/IEC 27002 under the same number. Whether it applies to you depends on your Statement of Applicability, and excluding it requires a documented justification.

What role does separation of duties play in privileged access management?

Privileged access management is where SoD matters most, because privileged accounts are the ones that can both perform an action and alter the record of it. The usual controls are splitting administration from log and audit configuration, and requiring a second approver for high-risk privileged operations, which is the two-person rule NIST describes as dynamic enforcement.

How do you enforce SoD across many SaaS applications?

By analysing entitlements across the whole estate rather than application by application, because the conflicting permissions usually sit in two different products. That requires an inventory that includes unfederated and shadow IT applications, conflict rules expressed at the entitlement level, and scheduled reviews that produce revocation records.