Segregation of duties fails between systems, not inside them. Every finance platform can stop one person creating and approving a payment within its own walls. None can see that the same person administers the bank connection. Or that they can grant themselves the approver role upstream and hand it back an hour later.
So a company can pass every in-app SoD control it has and still have somebody who could run a payment end to end. The conflict isn't in any single system's report, because no single system holds both halves.
What a real conflict looks like
Three shapes, and only the first is the one most tools check.
Inside one app. Create a vendor and approve a payment to it, both in the same ERP. Real, and largely solved: the app can see both permissions and refuse the combination.
Across two apps. Raise the purchase order in your procurement tool and approve the payment in your accounting system. Two systems, two clean reports, one person who can do both. This is where most genuine exposure sits, and nothing that lives inside either app will find it.
Through the access layer itself. Somebody who can grant themselves a role, use it and remove it. This defeats every rule you wrote, because at the moment of the transaction the access looked legitimate. The only evidence is in the grant log, and the only way to catch it is to treat self-grant as a conflict in its own right.
Rank those by how much money could move and the middle one wins. Inconveniently, it's also the one that needs a view across systems most companies don't have.
What it takes
Four things, and the first is where programmes die.
1. A small rule set, written as transactions. Five to ten rules, each phrased as a pair of things one person shouldn't both be able to do. Not entitlements, transactions. "Can create a vendor and can approve a payment" is a rule. "Has NetSuite admin" is not.
2. Entitlement data from every system in the rule. A cross-app rule needs both halves at the same time, at the grain the rule names. This is the plumbing, and it's why SoD is usually the last thing a governance programme gets to.
3. A named owner for what the conflicts are. Finance or internal audit, not IT. A rule set written by IT alone drifts toward describing permissions, because that's what IT can see, and permissions aren't where fraud happens.
4. A route for the unavoidable conflict. In a small finance team some conflicts genuinely can't be split. That has to end in a documented compensating control rather than an exception with no expiry, because the second one is what an auditor finds.
Findings as an inbox. Categories and counts on the left, the queue on the right, and two categories already at zero. Angelina was offboarded three days ago and still holds six apps.
Two of the categories on the left there are SoD checks sitting at zero. That's the state worth aiming at: not zero because nobody looked, zero because the rule ran and found nothing.
Patterns that break it
- Starting with 200 rules. A vendor library produces thousands of findings in week one, nobody triages them, and the programme is dead by week three. Five real rules beat 200 imported ones.
- Rules written as entitlements. "Has admin in the ERP" flags half the finance team and tells you nothing about what they could actually do.
- Checking inside apps only. Passes the easy third of the problem and misses the expensive third.
- Ignoring self-grant. An administrator who can grant, act and revoke has beaten your rule set, and this is the conflict least likely to be in the rule set.
- Treating every conflict as a removal. Some can't be removed. A conflict with a documented compensating control is a passing finding; the same conflict undocumented is a failing one, and the difference is paperwork rather than access.
- Running it annually. Reorganisations create SoD violations faster than hiring does, and a yearly check means living with them for up to a year.
Doing this without a tool
Feasible for a small rule set, and the rule-writing half is free and useful regardless.
- Write 5 rules with finance, in transaction language. An hour in a room. This is the artefact that matters and it survives whatever you decide about tooling.
- For each rule, name the two systems and the exact entitlement in each that confers the capability. This is where a rule that sounded clear turns out to be ambiguous.
- Export entitlements from those systems at that grain. Not group membership. The specific role or permission the rule names.
- Join by person and look for anyone holding both halves. A spreadsheet handles 5 rules across 6 systems without complaint.
- Triage every hit into three buckets: remove, compensating control, or false positive because the rule was wrong. The third bucket is large on the first run and that's fine.
- Record the decision per hit, with a date. This record is what the auditor tests, more than the detection is.
Budget a day for the first run and half a day per quarter after. The unglamorous truth is that step 5's third bucket is most of the first run, and the rules only become useful once you've been through it once.
What still needs a person
The rule set. What constitutes a toxic combination in your business is a judgment about your business, and no library knows your org chart.
The compensating control. Deciding a conflict stays and gets monitored instead of split is a risk decision. It belongs to whoever carries the risk, not whoever found it.
And the reorganisation review. When responsibilities get re-cut, somebody who understands the new shape has to re-read the rules against it. This is the moment SoD breaks most often and it never announces itself.
Where Iden fits
Steps 3 and 4 above, without the export and the join.
Entitlements from every connected system sit in one place at the grain the rule names, so a cross-app rule is a query rather than a project. That's the whole difference: the reason most companies check SoD inside apps only is that checking across them required assembling data nobody had assembled.
Detected conflicts arrive as findings with a state. A compensating control is recorded against the conflict, not in a separate document somebody finds 18 months later. And because self-grant runs through the same access layer, the grant-use-revoke pattern is visible as a sequence rather than as three unrelated log lines.