¶ Mitigating Controls for SoD Risk
A mitigating control is a compensating check outside the access itself that makes an SAP segregation of duties conflict tolerable, and the RedRays Security Platform records it against the finding by name so the acceptance can be examined later.
Some conflicts cannot be removed. A three-person finance team cannot separate every duty, an interface account may need both halves by design, and a plant with one storekeeper is a fact about the business. The answer in those cases is a control, and the value of recording it is that the reader of the report can see what the risk was accepted against.
¶ When can a conflict be accepted instead of removed?
When three things are true, and a mitigation that is missing any of them is a note rather than a control.
- Removing the access is genuinely not possible, or costs more than the residual risk. This is a business decision and it belongs to a named owner.
- A control exists that would catch the abuse, not merely one that exists in the same area. A four-eyes review of vendor bank-detail changes catches the vendor-and-pay conflict. A monthly management report does not.
- The control can be shown to have operated. A control nobody has tested is an intention.
¶ What makes a control credible?
| Property | Why it matters |
|---|---|
| Named owner | Somebody has to answer for it at audit time. An unassigned control is nobody's. |
| A description of what it detects | The link between the conflict and the control is what an auditor examines, and a generic description breaks that link. |
| A test schedule | Without one the control cannot become overdue, so it never appears in any exception list. |
| Recorded test results | A recorded test with a date is what turns an intention into evidence. |
| A retirement path | Controls stop being performed. Retiring one has to be an explicit act rather than a silence. |
Controls are registered for the organisation rather than for a single SAP system, because the same manual check usually covers several landscapes.
¶ How is a control tied to a finding?
The decision on a finding is separate from the engine's verdict. Marking a case as mitigated names the control it rests on, takes the case out of the reported count, and records who did it. Accepting the risk instead requires a date the acceptance expires, so an acceptance cannot quietly become permanent.
Two counts follow from that and are the reason the register exists. The first is how many registered controls nobody can vouch for: overdue, never tested, or with no test schedule at all. That is deliberately not a count of controls that failed a test. It is a count of controls nobody can say passed one. The second is what that costs: how many open cases are out of the reported count on the strength of those controls. A case mitigated against an untested control is marked distinctly, because in a list of several hundred rows a sound mitigation and an unproven one must not look the same.
An empty control register is reported as an empty register and not as a measurement of zero risk, and retired controls are excluded from the counts with the number excluded stated beside them.
An empty control register reports itself as empty, never as a measurement of zero risk.
¶ Limits
- The platform does not perform your control, does not read its evidence, and cannot confirm it works. It records that a test was carried out, by whom and when, and shows what rests on it.
- Mitigation is not remediation. The conflict is still in the landscape, still in the evidence, and returns to the reported count the moment the control is retired or the mitigation is withdrawn.
- A control does not suppress a finding. Suppression is the engine's verdict on a fact about the system and is a separate column. See suppressed, waived and reported.
- Registering a control against a conflict that could simply be removed is the most common way an SoD programme stops making progress. The register is there to make that visible, not to make it comfortable.
¶ Frequently asked questions
¶ Is a mitigating control an accepted alternative for auditors?
Compensating controls are a recognised answer to an unavoidable conflict, and auditors ordinarily ask for the control, its owner, and evidence that it operated across the period. Whether a specific control satisfies a specific auditor is between the customer and the auditor.
¶ What happens to a mitigated case at the next scan?
The decision is keyed on the system, the user and the rule, so it carries across scans and is not erased by the next run. If the access is removed, the conflict stops being found and the case can be closed on that basis.
¶ Can a control cover more than one conflict?
Yes. One control can be named on many cases, which is why the register counts cases resting on each control. That number is what tells you how much is riding on a control nobody has tested.