¶ SAP User Access Reviews
An SAP user access review in the RedRays Security Platform is a population of access lines frozen against one sealed segregation of duties scan and worked through by named reviewers, so the sign-off states exactly which measurement it was taken over.
A recertification is evidence or it is paperwork, and the difference is whether anybody can say later what was on the list when it was signed. That is why a review is opened from a scan and stays on it.
¶ What is a user access review?
A periodic exercise in which the people who own a business area confirm, line by line, that the access their people hold is access those people should have. In SAP it is usually run quarterly or twice a year, and it is one of the controls an external audit asks to see operating.
The review here is scoped: it covers the access the active segregation of duties ruleset can reason about. It is not a full inventory of every role every user holds, and it is labelled as an SoD-relevant access review for that reason. Claiming a complete role listing would be overpromising, because the evidence records the roles that granted a duty a rule named and nothing else.
¶ Why is the population frozen against a scan?
Because a recertification whose population moved under the reviewers is not evidence of anything. If access changes while the review is open, a line somebody approved in week one may describe something that no longer exists in week six, and a line nobody ever saw may have appeared in between.
A review is opened from a sealed scan and measured against it for its whole life. Later scans keep happening on the same system and do not disturb the frozen list. When the review is closed, the record says which scan it was taken over, what the state of the system was on that date, and who decided what.
The register of reviews is deliberately not filtered by the system selector on the rest of the module. Filtering it would hide last quarter's unfinished review the moment somebody looked at a different landscape.
Each review stays tied to the sealed scan its population was frozen against, and its counters describe how far it actually got.
¶ What is one line of a review?
One role or profile in the frozen population that the active ruleset can reason about. It is not one person: a person with several roles in scope appears as several lines, because the decision is taken per grant and not per human being.
Each line offers three outcomes.
| Decision | What it records |
|---|---|
| Keep | The reviewer confirms the access. Recorded on the press, with the reviewer and the date. |
| Remove | A removal is requested. The line is tracked from there until the access is confirmed gone. |
| Mitigate | The line stays and is tied to a named mitigating control, with the same rules as any other mitigation. |
Both Remove and Mitigate ask for confirmation before they are recorded, because both are decisions somebody will be asked about later.
¶ How does a review reach the people who should do it?
Through the owner on each line. The counter that decides whether a review will ever finish is not how many lines are outstanding but how many lines nobody has been made responsible for, and that is shown as its own figure rather than folded into a progress bar.
This depends on data that the SAP extract may not carry. Names and departments live in separate SAP tables from the authorisation data, and an extract that does not read them produces a population where every account falls into a single unassigned bucket. A review signed off over that bucket records that somebody clicked, not that a manager who knows the person looked. Where that is the case the scan says so as a named gap, and it appears on the review rather than being papered over. See what SoD analysis reads from SAP.
¶ What happens to a removal after it is requested?
It is tracked, and the outcome is one of five answers rather than a completion percentage.
| Outcome | What it means |
|---|---|
| Removed | A later scan of the same system confirms the access is gone |
| Still there | A later scan still finds it |
| Nothing has looked yet | No scan has run on that system since the removal was requested |
| Gone but not removed | The access is absent for another reason, for example the account was deleted or locked |
| Not tracked | The line cannot be followed, and the review says so instead of counting it as done |
A single percentage would merge the third row into the first, which is exactly the misstatement worth avoiding: "we asked" and "we checked and it is gone" are different claims about a landscape.
¶ Limits
- The review does not remove anything from SAP. It records decisions and tracks whether the removal happened, and the change itself is made by the customer's administrators in their own change process.
- It covers SoD-relevant access, not every role a user holds.
- Line ownership is only as good as the identity data the scan was given. Without names and departments, distribution is manual.
- The review is a point in time by construction. Access granted after the freeze is not in it, and appears in the next scan and the next review.
¶ Frequently asked questions
¶ How often should a review be run?
Most organisations run one quarterly or semi-annually, and align it with the reporting period the auditor tests. What matters more than the interval is that each review names the scan it was taken over, so two consecutive reviews can be compared.
¶ Can a review be reopened after it is closed?
A closed review is a record of what was decided and by whom, and it keeps its frozen population. New questions belong to the next review over the next scan, which is what keeps the audit trail readable.
¶ Does the review show the conflicts as well as the access?
The review works over the access the ruleset can reason about, and the conflicts that access produced are in the scan behind it. Reviewing an account and reading its findings are two views of the same sealed measurement.
¶ What if a reviewer keeps a line that is in a conflict?
That is a decision, recorded with the reviewer's name, and the conflict stays open in the case file. Keeping access does not close a finding, which is why decisions on findings and decisions on review lines are held separately.