> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/governance/sod-programme.md). # Designing a segregation-of-duties programme Starting a segregation-of-duties programme — which conflicts to encode first, the draft-shadow-enforce progression that keeps it from blocking the business, how thresholds and risk classification actu ## What this is, and when you need it Segregation of duties is the governance capability most often bought and least often operated. The mechanism is not the hard part — OpenIAM will detect a conflict and block a grant. The hard part is that **a policy which blocks is only as good as the organization's ability to remediate what it finds**, and almost every programme discovers a backlog of existing conflicts far larger than anyone expected. This page is about starting one so that the discovery happens before the blocking does. The spine is a progression the product supports directly: a rule set is drafted, run in **shadow** where every conflict is detected and nothing is refused, and only then **enforced**. Everything else on this page is about what to decide at each of those three points. You need it when a sponsor has asked whether OpenIAM does SoD, when an auditor has asked which toxic combinations are controlled, and — most usefully — before anyone activates the shipped rule content to see what it does. ## The decision The first decision is not which conflicts to encode. It is how much you are prepared to block, and when. | Starting position | What it buys | What it costs | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Detect only, indefinitely** | Complete visibility, no operational risk, no arguments | Nothing is prevented. A detective control with no remediation loop is a report, and an auditor will treat it as one | | **Shadow first, then enforce a small critical set** (recommended) | The backlog is known before anything is refused, and the first enforcement covers conflicts the business already agrees are unacceptable | Two phases and a remediation programme between them. The gap between shadow and enforcement is where the real work happens | | **Enforce from the start** | Fast, and defensible on paper | The first thing enforcement does is refuse grants for a population you have not measured — including automated grants that used to succeed. This is how SoD programmes get switched off | | **Enforce everything the shipped content contains** | Breadth, immediately | The shipped rules are written against a specific application's transaction vocabulary. Activated against entitlements that do not match, they create objects nobody owns and detect nothing real | **Shadow before enforce, and enforce narrowly.** The product supports this progression as a first-class mechanic, and using it is the difference between a control that survives its first quarter and one that is disabled after the first blocked hire. ## The progression A rule set — a catalogue of conflict definitions that generate enforceable policies — moves through three states. Take from the diagram that the product allows a direct step from drafting to enforcement, and that the reverse path is not symmetrical. ```mermaid stateDiagram-v2 [*] --> Inactive Inactive --> Shadow: activate in shadow Inactive --> Enforced: activate enforced, not advisable Shadow --> Enforced: enforce Enforced --> Inactive: deactivate Shadow --> Inactive: deactivate ``` Read one thing from that diagram: **the direct edge from inactive to enforced exists.** The product will let you activate straight into enforcement. The reverse is not symmetrical — the enforce transition is accepted only from shadow — so the design should treat the direct edge as a trap rather than an option. What each state means in practice: **Inactive** is the drafting state. The definitions exist and generate nothing. All shipped content arrives here, and a set you author yourself should stay here until the entitlements it references are the ones you meant. **Shadow** is the measurement state, and it is the point of the whole exercise. Activating in shadow creates the policies but forces every one of them to detect-and-report, with exceptions permitted, whatever risk level the underlying rule carries. Conflicts are visible; nothing is refused. **Run it for at least one full detection cycle across the whole population**, because the number you get — how many people already hold each conflict — is the number that decides whether enforcement is a configuration change or a twelve-month remediation programme. **Enforced** derives each policy's behaviour from its risk classification. That derivation is the fact most likely to surprise a designer, and it is covered next. ## Severity is decided by the risk classification, not by a severity setting There are two behaviours a policy can have. A **soft** policy audits the conflict, notifies the responsible group, and lets provisioning continue. A **hard** policy audits, notifies, and **refuses the save** — the provisioning call fails. When a rule set is enforced, the product re-derives every generated policy's behaviour from that policy's risk classification: **critical becomes hard with exceptions turned off; high and medium become soft with exceptions allowed.** Any severity somebody set by hand is overwritten. The design consequence is worth stating plainly, because it inverts what most people assume they are configuring: **the risk classification scheme is the control, and the severity setting is an output.** If you want a conflict to block, it must be classified critical. If you classify broadly at critical, you have designed a programme that blocks broadly, whatever the intention behind the individual settings. This also decides where exemptions are possible. Because enforcement turns exceptions off on exactly the policies that block, **a critical conflict has no per-user escape hatch**. The only ways past it are to remove the conflicting access or to attach a compensating control. That is defensible design — but it has to be known before enforcement, not discovered by the first person it blocks. ## Thresholds: the two numbers that decide what counts as a conflict A policy is a set of named segments, each holding the entitlements that represent one side of a duty. Two thresholds decide when it fires. The **segment threshold** is how many of that segment's entitlements a person must hold for the segment to count. One, for a set of interchangeable permissions where any of them constitutes the duty; higher, where the duty is only really held by someone with several. The **policy threshold** is how many segments must be triggered for the person to be in violation. For a classic two-sided conflict this is two. **The shipped default is one**, which with two segments means that holding either side alone is a violation — which is almost never the intended meaning, and which produces a first detection run that flags most of the organization. If your shadow run returns an implausible number, this is the first thing to check. ## Mitigating controls and exemptions Two mechanisms let a conflict persist deliberately, and they are not interchangeable. A **mitigating control** is a compensating control attached to the policy: a named owner and a named manager, a review frequency, and effective and expiry dates. It says the conflict exists and something else catches its consequences — a dual-approval requirement, an independent reconciliation, a monitored report. It is the right answer where the conflict is structural: a small team where nobody can be separated from anybody. An **exemption** is per person, per policy, recorded with its author and a comment. It says this individual may hold this conflict. It is the right answer for a genuine, time-bounded individual case, and it is available only where the policy permits exceptions — which, after enforcement, means only on the policies that do not block. The design decision is which of the two your programme leans on, and it follows from the risk classification. A programme that classifies broadly at critical must plan on mitigating controls, because exemptions will not be available. A programme that leaves most conflicts detective can use exemptions and should require an expiry and a reason on every one. ## Who owns a violation Detection without ownership produces a growing list and no outcomes. Three roles have to be named in the design, and only one of them is a product setting. **A responsible group per policy** receives the notification when the conflict is detected. This is the one the product asks for, and a policy pointing at a group that does not work violations is the most common way a programme becomes decorative. There is also a choice about whether that group can act on violations or only be told about them; make it deliberately, because "notified but powerless" is a real configuration and a common complaint. **A remediation owner** decides what happens: remove one side of the conflict, exempt the person, or attach a mitigating control. That is a business decision about someone's job, and it belongs to a line manager or a process owner, not to the identity team. **A control owner** answers for the policy itself — why this combination is a conflict, why it is classified as it is, and why the outstanding violations are acceptable. This is the person an auditor talks to, and the role most often unassigned. A violation that is neither remediated, exempted nor mitigated is an open finding, and the programme should report it as one rather than carrying it silently. ## Detection cadence Conflicts are detected in two places, and the difference matters to the design. **Inline, at the moment access is granted**, the product evaluates the entitlement set the operation would result in — what the person already holds, merged with what the change would add — and refuses it if any resulting conflict is hard. This fires on every provisioning path, including approved requests and automated rule-driven grants. That last point is the one to carry into the design: **enforcing a new policy can break automation that used to succeed**, silently, at whatever hour the automation runs. **A sweep across the whole population** re-evaluates everybody and rewrites the violation record. This is what finds the pre-existing backlog, and it is what a shadow run depends on. It is also the expensive one: it pages through every user in the system, which makes it a nightly or weekly job, not an hourly one. One shipped detail belongs in a plan rather than in an operations handover: **scheduled detection is not scheduled out of the box.** No batch task row for the detection digest ships; the schedule and its recipient list are created when somebody configures them. A design that assumes periodic detection is running by default is describing a control that is switched off. A second detail shapes what you can report: the violation record carries no per-violation timestamp. "New since the last run" is derived by comparing against a stored snapshot of the previous run, so the question *when did this conflict first appear* cannot be answered from the current record. If that history matters — and in a regulated estate it usually does — retain the generated reports, because they are the only place it exists. ## The shipped content, and how far it takes you Ten rule sets ship, all inactive, covering five business verticals in a US and a European edition, and together they hold several hundred conflict definitions with control objectives, business-risk narratives and suggested remediations already written. That narrative content is genuinely valuable as a starting vocabulary — it is the language an auditor expects, already drafted. Two constraints decide whether it is usable as content rather than as vocabulary. The rules name entitlements after one major business application's transaction codes, so they only match your estate if your entitlement names do. And activating a set against a managed system where the references do not match **creates** the missing entitlements — which is how a single activation produces a hundred objects that nothing provisions and nobody owns. So: read the shipped content, take its control objectives, and activate it only where the naming genuinely lines up. Elsewhere, author your own conflicts using it as the model. ## What we recommend **Start with a handful of conflicts the business already agrees are unacceptable.** Payment creation with payment release; journal entry with journal approval; administrative access to the system that records the control. Ten well-chosen conflicts that are enforced beat three hundred that are reported and ignored. **Build the conflicts over a converged catalogue, not a raw one.** Every duplicate role is a rule you have to write twice and a gap when you forget. **Always run shadow, and run it long enough to include a full detection sweep and one business cycle.** The backlog number is the single most important output of the whole design phase. **Treat the risk classification as the control.** Decide the classification scheme first, apply it consistently, and expect the severity to follow from it rather than the other way round. **Set the policy threshold explicitly on every policy.** The shipped default will otherwise flag the side rather than the conflict. **Name the responsible group, the remediation owner and the control owner before enforcement**, and give the responsible group the ability to act rather than only to be told. **Plan the remediation programme between shadow and enforcement, with a date.** Enforcement is not a switch; it is the end of a piece of work, and the conflicts still outstanding on that date become operational blocks. **Turn scheduled detection on deliberately**, and confirm that the recipients are people who will work the list. The circumstance that changes this advice is an estate mid-migration, where a second platform still governs part of the population. There, enforce nothing across the boundary: a hard policy evaluating an entitlement set that OpenIAM only partly knows about will both miss real conflicts and block legitimate grants. Run detective SoD over the enterprise view, and enforce only within the applications OpenIAM already writes to. See Part 5, *The enterprise view without duplicate governance*. ## What OpenIAM does not do here * **Scheduled detection is not scheduled by default.** No batch task row ships for the detection digest; until somebody configures a schedule, the only detection that happens is inline at provisioning time. * **Violation records carry no per-violation timestamp.** "When did this conflict first appear" is not answerable from the current record; only the previous run's snapshot supports a delta. * **Enforcement overwrites severity from the risk classification.** A severity set by hand does not survive, and a critical policy has exceptions switched off. * **There is no conflict discovery.** The product will not propose conflicts from observed access, any more than it will propose roles. * **Activation creates missing entitlements.** A rule set activated against a system whose names do not match produces objects rather than an error, except for organizational references, which are silently left out. * **A hard policy blocks every provisioning path, including automation.** There is no exemption for system-driven grants and no dry-run of enforcement beyond shadow. * **The shipped rule sets are read-only.** Adapting them means exporting, editing and importing as your own content. ## Related * [Designing the role model](/solution-architecture/governance/role-model.md) — the converged catalogue that conflicts should be written over. * [Designing a certification programme](/solution-architecture/governance/certification-programme.md) — where a reviewer meets the conflicts attached to an item. * *SoD policies and rule sets* and *SoD detection and violations* in the Administration Guide — the mechanism, configured. * Part 8, *Operating in a regulated environment* — what a detected-and-mitigated conflict does and does not evidence. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/governance/sod-programme.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.