¶ SAP Segregation of Duties Analysis
Segregation of duties analysis in the RedRays Security Platform reports which SAP accounts can perform two business activities that no single person should be able to perform, computed from the authorisations SAP actually generated.
- Reads only, never writes to SAP
- Computed from authorisations, not role names
- Every figure belongs to one sealed scan
Segregation of duties (SoD) is a control most organisations claim to operate and that SAP does not enforce anywhere. SAP stores the ingredients: user master records, role assignments with validity dates, composite role membership, directly assigned profiles, reference user inheritance, and authorisation values object by object and field by field. Nowhere in the system is there a table that says who holds both halves of anything. The answer has to be computed, and computing it without inventing conflicts is most of the work.
Every conflict figure here belongs to one sealed scan, and the counters that outlive a scan, such as open cases and waivers, say so on the tile.
¶ What is segregation of duties in SAP?
Segregation of duties in SAP means two conflicting business activities are held by two different people, enforced through the authorisations attached to their roles. A conflict exists when one account satisfies both sides of a defined pair: maintaining vendor master data and releasing an outgoing payment, raising a purchase order and confirming the goods receipt against it, creating a user account and granting it roles.
The conflict is a property of the account, not of a role. It can arrive from one role that carries both duties, from two roles that each carry one, or from a grant that no role carries at all.
¶ Why can SAP not answer this question itself?
Because nothing in SAP joins the two halves together. An auditor's one-sentence question becomes a join across hundreds of thousands of authorisation rows, thousands of role definitions, every user-to-role assignment and its validity dates, composite role links, profiles assigned straight to an account, and reference-user inheritance.
Retrieval is the easy part. Four things separate a correct answer from a plausible one, and all four are invisible in a spreadsheet: whether the required fields came from a single authorisation instance, whether a value is a wildcard or an unmaintained blank, which grant path the access travelled, and whether the two duties can meet on the same document at all. What an SoD audit is actually asking works through each one.
¶ How is an SoD conflict detected?
An account is tested against a rule, and a rule is written in authorisation terms. A rule pairs two duties, names one duty nobody should hold, or matches an unrestricted profile assigned straight to an account. A duty is a set of authorisation conditions over objects, fields and values, and it is satisfied only when a single authorisation instance carries every field the condition requires. Two grants that each supply half of a requirement do not satisfy it, because SAP itself would refuse the transaction at runtime.
That is why the analysis works from authorisations rather than from the transaction codes listed in a role menu. Duties, functions and SoD rules sets out the model.
¶ What does one finding contain?
One finding is one person, one rule, one system, one sealed scan. Opening it shows both duties, every path by which the access reaches that account, the role or profile behind each path, and the authorisation values that matched. However many paths there are, it stays one finding, because the number a customer reports is a number of conflicts and not a number of roles.
Alongside the engine's verdict there is a separate decision owned by a person: open, in remediation, mitigated, accepted, false positive, closed. The two are never merged into one status word. See what one SoD finding says.
The engine's verdict and the decision owned by a person are two separate things, and they are never merged into one status word.
¶ Which page answers which question?
¶ What this analysis does not do
Stated plainly, because each one is something a buyer may assume is included.
| Not built | What exists instead |
|---|---|
| Access request or provisioning workflow | Analysis and remediation tracking. Nothing is written back to SAP. |
| Emergency or firefighter access management | A proposed grant can be modelled with the dates it would be valid between, but the grant itself is made in SAP by the customer. |
| Cross-application segregation of duties | Rules are written against SAP authorisations. |
| Evidence that the access was used | There is no Security Audit Log reader. The only usage-adjacent fact held is the last logon date recorded on the account. |
| A full list of every role a user holds | Evidence records the roles that granted a duty named by the active ruleset, which is why the review screen is scoped to SoD-relevant access. |
| Real-time or continuous monitoring | Scheduled scans, each with a stated last-read date. No screen says "live". |
| Importing a third-party GRC ruleset | Every condition has to resolve against the authorisation dictionary, so a first import is bespoke work. |
| Demo mode or sample data | No mock figures and no placeholder deltas. In a compliance product one invented number devalues every real one beside it. |
There is no Security Audit Log reader, so nothing here is evidence that the access was used. The only usage-adjacent fact held is the last logon date recorded on the account.
¶ Frequently asked questions
¶ Does the analysis change anything in SAP?
No. The connection reads user master data, role definitions and authorisation values. There is no write path to SAP in this module, and remediation is carried out by the customer's own administrators through their own change process.
¶ Can this run without a live connection to the SAP system?
Yes. An offline extract can be uploaded and produces a full scan, badged permanently as an imported extract, with a per-rule statement of what the bundle could and could not answer. See analysing an air-gapped SAP landscape.
¶ Where does the product run, and does our data leave the network?
The platform is installed on the customer's own infrastructure, and SoD scan data stays there. Deployment and where data goes covers the one exception, which belongs to ABAP code analysis and not to this module.
¶ How many conflicts should we expect to find?
That is a property of a landscape, not of the product, and any number quoted in advance is a guess. What can be stated is that the total is broken into what was reported, what was suppressed and why, and what the scan was never told, rather than presented as a single figure. See what a finding does and does not claim.
¶ Does a rule survive a role being renamed?
Yes. Both sides of a rule are named as duties defined by authorisations, not as roles, so renaming or rebuilding a role changes which paths appear in the evidence and does not change whether the rule fires.