An SAP segregation of duties audit asks which single identity can perform both halves of a business cycle, and the RedRays Security Platform answers it by computing that from authorisation data, because SAP stores no table holding the answer.
The question arrives in one sentence. Show me everybody who can create a supplier and also release a payment to it. Who can raise a purchase order and receive the goods against it. Who can maintain an employee record and run that employee's payroll. Who can create a user account and grant it a role.
Each is a question about two capabilities held by one person. The finding, when it lands, is rarely that somebody committed fraud. It is that the organisation cannot demonstrate the separation it says it operates.
Because the evidence is spread across half a dozen places and none of them is the answer. Producing it means joining every authorisation value written into every role against every account, through direct role assignments and their validity dates, composite role membership, profiles assigned straight to an account, and reference user inheritance. On a real production client that is hundreds of thousands of authorisation rows against thousands of roles.
Retrieval is only the beginning. Four things separate a correct answer from a plausible one, and all four are invisible in a spreadsheet.
An authorisation instance is one generated authorisation within a role, carrying its own set of field values. A role can hold two instances for the same authorisation object: one granting create in one purchasing organisation, another granting change in a different one. A requirement of "change, in the first purchasing organisation" is not met by that role. No single instance grants both, and SAP would refuse the transaction at runtime.
Group the role's rows by role name and the requirement looks satisfied, because the role holds the activity somewhere and the organisational value somewhere else. This is the single most expensive kind of false positive an SoD product can produce, and it is one careless grouping away. The customer goes looking for an access grant that does not exist, finds nothing, and stops trusting every other row on the report.
Because they mean opposite things and some SAP screens render both as "no restriction".
| Value in the authorisation | What SAP means by it | Effect on a conflict |
|---|---|---|
| Wildcard | Every value of the field is granted | A rule asking for one specific value is genuinely satisfied |
| Empty | The field is present and grants nothing through it | Nothing is satisfied, and nothing should be reported |
A matcher that treats the empty case as a wildcard reports a conflict against every user holding an unmaintained field, which on most landscapes is a large share of the population.
Five paths carry access to an account, and two of them defeat the usual review.
| Path | Why it is or is not visible in a normal review |
|---|---|
| Direct role assignment | Visible. This is what most reviews look at. |
| Composite role | Visible if the reviewer expands the composite. |
| Derived role | Visible, though the organisational values differ from the parent. |
| Reference user | There is no assignment row against the person at all. A report built from role assignments shows the account holding nothing. |
| Directly assigned profile | Carries no role name. An unrestricted profile inside a role is at least visible to a role-based certification; the same profile assigned directly is not, and the certification confirms the user as clean. |
Because holding both sides of a rule is not enough if the two sides cannot meet on the same document. Someone who orders for one plant and can only receive into another cannot complete the cycle alone.
Organisational values, such as company code, plant, purchasing organisation and sales organisation, are read per role and compared side against side. Where they cannot intersect, the conflict is recorded with its evidence and held back rather than reported, and the reason is named on the row. The asymmetry is deliberate: where a role's organisational value is a range or a prefix rather than a single value, the role is treated as unrestricted and the conflict is reported. Under-suppressing is the safe direction, because nobody ever finds a finding that was never printed.
Segregation of duties analysis answers what an account is authorised to do. It does not answer what the person did, whether a manual control caught it, or whether the two duties were ever exercised on the same document. Usage evidence lives in the Security Audit Log and in the document trail, neither of which this analysis reads. A conflict is an exposure, not proof of an incident.
No standard report joins two duties across all grant paths and organisational values. SAP ships tools that show what a user has, which is the input to the question rather than the answer to it.
No. It says one identity could complete both halves of a cycle without a second party. That is an exposure and an audit finding in its own right, and it is what an auditor asks the organisation to demonstrate it has removed or mitigated.
Yes. The evidence behind each finding lists every path, so a conflict carried entirely by one role is visible as such. That distinction matters, because a two-role conflict can be fixed by withdrawing an assignment and a one-role conflict cannot.