Segregation of Duties

The conflict that exists in neither application.

Each application polices itself. The combination that actually enables fraud is assembled from parts that are individually reasonable — and no single system can see it.

The rule

One rule, two systems

Create Payments lives in the ERP. Finance File-Share Admin lives in the directory. Each was approved by a different team, and each is defensible on its own. The rule spans both and states the condition in plain language.

Rule builder: flag any user who can Create Payments and can also Admin Finance File Shares, scored at risk 90 — Rule definition — toxic combination across an ERP and a directory

The evidence

Both sides, down to the privilege

Each side expands to the underlying grants — role, action, permission, authorization object or data-security level — so a reviewer sees exactly what makes the combination toxic.

Side A of the rule: the ERP function Create Payments and its underlying payment manager role — Side A — ERP function and its privileges

Side B of the rule: directory administration of finance file shares and its two underlying roles — Side B — directory grants and their privileges

At scale

A ruleset, not a one-off

Cross-application segregation of duties ruleset listing seven active rules spanning ERP, directory and API systems with severity and risk scores — Cross-application ruleset — ERP × directory × API, each scored and scoped

Scope is evaluated inside the rule, not applied as a report filter afterwards. A same-unit rule fires only when both sides land in one operating unit — so the violation count you hand an auditor is a count the user could actually have acted on.

Coverage

How each platform grants access

Rules evaluate the effective permission after inheritance and nesting are resolved, then normalise it. That normalisation is what makes a cross-application rule possible at all.

Platform	Access is granted by	Resolved to	Data dimension
SAP	Single and composite role	Authorization object, field and value	Company code, plant
Oracle Fusion	Job and abstract role	Duty role, then privilege	Business unit, ledger
Oracle EBS	Responsibility	Menu and form function	Operating unit
SailPoint	Role and entitlement model	Application entitlement	As modelled
Microsoft Entra	Directory role and group	Role assignment and group membership	Administrative unit
CyberArk	Safe and account permission	Vaulted credential access	Safe scope

Prevention

Simulate the grant before you make it

Request time

Preventive control

Model an existing user, a hypothetical new hire, a single role in isolation or two roles in combination — and see the projected violations before anything is provisioned.

Role design

Conflict-free by construction

Toxic-role checks answer whether one role alone carries an intra-role conflict, so new roles ship clean instead of generating a backlog.

Remediation

Surgical, via lineage

Where a privilege arrives through several paths, all of them are shown. Revoking one role often does not clear the violation — lineage names the grants that do.

How many of your conflicts span two systems?

A read-only assessment returns a cross-application SoD picture of your estate.

Book a Demo →Take the Assessment