Capabilities

Six capabilities, one access model

Segregation of duties is one use of the model, not the whole of it. The same resolved view of access answers who can do what, through which grant, within which organisational scope.

01 · Fine-grained SoD

Down to the privilege

Analysis at the SAP authorization object, field and value, the Oracle Fusion privilege and the EBS form function — rather than at the role name an administrator happened to assign.

02 · Cross-application SoD

Conflicts that span systems

Toxic combinations across ERP, cloud, directory and enterprise applications, evaluated as one rule because each platform's access is normalised to the same model first.

03 · Effective access analysis

What a user can really reach

Role inheritance and nested permissions resolved to effective access, with the full path from user to privilege. Where access arrives through several routes, every route is shown.

04 · Data-level access context

Scope inside the rule

SAP company code and plant, Oracle business unit and ledger, EBS operating unit. A conflict counts only when both sides land in scopes the user could act on together.

05 · Preventive risk analysis

Simulate before you provision

Model a new role, an access request or a new hire before anything is granted, and see the projected conflicts and the change in risk before it becomes a finding.

06 · Remediation & controls

Evidence-backed remediation

Mitigating controls with owners, test frequency and expiry; role redesign informed by the roles generating the most conflicts; and remediation lists backed by privilege-level evidence.

Rules people can read

Stated in plain language, scored and scoped

Create Payments lives in the ERP. Finance file-share administration lives in the directory. Each was approved by a different team. One rule spans both — and says so in a sentence a business owner can review.

Rule builder defining a cross-application toxic combination between an ERP payment function and directory file-share administration, with severity, risk score and scope — Rule definition — toxic combination across an ERP and a directory

Fine-grained evidence

Both sides, down to the privilege

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

Side A of a rule: an ERP payment function and the payment manager role that grants it — Side A — ERP function and its privileges

Side B of a rule: directory finance file-share administration and the two roles that grant it — Side B — directory grants and their privileges

Data-level context

How each platform actually grants access

Rules evaluate the effective permission after inheritance and nesting are resolved, together with the organisational dimension each platform uses to restrict it.

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

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.

At scale

A rule library, not a blank page

Content spans Financials, Human Capital, Procurement and Order-to-Cash, so a first meaningful risk picture arrives in days. Your own matrix loads from a spreadsheet, and any ruleset exports for review.