Hello!
This article is intended for all the auditees out there, who struggle with SAP authorizations. I’ll try to provide you with a best-practice approach to tackle audit findings related to extensive/critical rights in SAP.
The situation
There is probably not a single SAP-related audit report out there that does not include a finding about extensive SAP authorizations…
Let’s be honest: SAP offers fantastic possibilities and tools to tailor user authorizations and restrict them to a proper minimum – but due to the range of possibilities it is extremely hard and time consuming to get close to roles that follow the need-to-know principle.
In an audit, it is thus likely that there will be at least one or two findings dealing with extensive authorizations… that’s probably the reason you read until here. 😉
The problem
Well… the problem is often that it is unclear how critical rights can be effectively reduced (without long deadlines or additional staff).
Audit findings that deal with SAP authorizations consist of a finding text that describes the “problem” (comprising a risk) and are usually accompanied by an evaluation of the critical rights and segregation of duties conflicts that led to the finding(s). Taking care of such findings can lead to time-consuming activities, as you need to take care of the listed rights (or users assigned to these rights) and additionally make sure that you don’t just slightly tidy up the system, but also solve the core problem of the finding.
A best-practice procedure can help you tackle the cleanup and distribute the individual tasks to the responsible people.
Some basics upfront
A critical right is a single authorization, which can be used to perform extensive actions in the system, such as broad read access or uncontrolled data modifications.
Examples:
- Debug with replace.
- Modification of program code in production.
- Display (or change) authorization for all tables in production.
A segregation of duties (“SoD”) conflict is a combination of at least two authorizations, which can be used by a single person to execute a whole process and which must usually be distributed among several persons.
Examples:
- Maintenance of vendor master data & maintenance of purchase orders.
- Creation & approval of expense reports.
Risk management: there are several ways to deal with a risk: you can…
- Ignore it – the worst choice (if a real choice at all)! The risk might lead to unforeseen damages and the extent is unclear. This usually results in the worst possible audit assessment… quite rightly.
- Accept it – if the risk is either very unlikely and/or has a minor impact, you can choose to accept it. Maybe it’s a strategic risk, which is directly linked to your business model; then you may not be able to manage it without a negative impact on your ability to make profit (which you might consider unacceptable). The most important point when accepting a risk is: think about it and do it intentionally! The person, who decides on this must be in charge of the affected process and in a position to take the decision.
- Avoid it – if a risk has a potentially large impact on your business (and is maybe even likely), an adequate way of risk management may be to completely avoid the risk.
- Transfer it – essentially, you transfer the impact and management of the risk to someone else. You’ll have to pay for this in one way or another. Outsourcing is a common example.
- Mitigate it – means that you reduce the potential impact or likelihood (or both) so that if the event occurs, it is easier to overcome – this means that a residual risk remains. It’s a common technique, as taking risks is inherent to running a business and mitigation provides a good balance between not managing a risk (at little cost) and avoiding or transferring it (at high cost).
A compensating control strives to control a residual risk, e.g. by a regular ex-post check. Personnel restrictions, for example, could prevent an effective segregation of duties between the creation and approval of expense reports. A daily review of the creations and approvals by a responsible manager would enable the detection of fraud cases and is, therefore, a compensatory control.
The proposed procedure
Before you start, you should ensure a common understanding and expectation concerning the remediation; thus:
- Review all critical rights with the auditor to understand their impact/criticality.
- Discuss with audit, which critical rights must be remediated and which may be accepted.
The flowchart below strives to provide you with a structured approach to tackle authorization-related findings.
The basic idea is that you loop through the procedure role by role (or right by right) and continue until every authorization in scope has been checked and either found to be good or cleaned up.
( click here for a PDF version )
Most steps in the flowchart are rather obvious and I will not explain them in detail… the green decisions boxes, on the other hand, are very important and need some explanation:
Assignment of roles to users justified by positions of the employee?
Each user ID should relate to exactly one natural person, which in turn holds a position. To fulfill the tasks associated with that position, specific authorizations are required. The roles assigned to a user should not include more authorizations than needed to fulfill their position.
In case users do not belong to one person but are rather (at least potentially) used by several people, please get in touch with the auditor. Depending on the authorization concept and possibly implemented controls this might or might not be valid.
Does the right fit to the purpose of the role(s)?
In case the user is properly assigned to the role(s), which are associated with his/her position and there are still critical rights listed, the role could contain too many authorizations.
You should check if the role purpose and the contained rights match. Can the critical rights be removed without impacting the user’s work? Keep in mind that some tasks occur only occasionally, e.g. when the annual financial statement is prepared.
Are there users with critical rights left?
After performing the two checks above for all critical right/user assignments, most rights should be either remediated or found to be justified.
Anyway, some questionable critical rights might be left, for which no remediation could be found – either due to special (known) situations or because of small team sizes, which do not allow proper segregation of duties. These remaining cases should be considered very carefully because they represent a risk and thus need to be controlled. To do this, we need to differentiate further…
Is it a (single) critical right or an SoD conflict?
The difference between these two has been described in the chapter “Some basics upfront“…
Single critical right – Define control or accept the risk?
For each remaining critical right, either a control must be implemented or the risk must be accepted by a person, who is accountable for the affected process or function and in a position to do so.
If acceptance is not an option and no efficient compensating control can be defined, the critical right must be remediated. If unsure, discuss the situation with your auditor!
SoD conflict – Does a compensating control for the conflict exist?
The situation is roughly the same for SoD conflicts: they must either be mitigated by a compensating control or cleaned up. It is inadequate to have SoD conflicts without any control. In case the conflict cannot be solved, e.g. due to staff shortages or small team sizes, a compensating control could be applied to reduce the risk to an acceptable level.
Your risk management department can usually provide you with best-practice approaches for such controls.
Can the chosen control be implemented?
In case a compensating control exists for the SoD conflict in question, you should decide with the affected persons if it can be implemented. In case the control is considered too complicated or not favorable at all, the SoD conflict must be cleaned up.
As such controls must be executed accurately, resources are required – and in the end, the conflict might be cleaned up, just because the additional effort for the control is considered too high… It is therefore very important to ensure that compensating controls are not defined without clear communication about the involved effort!
Final words
Hopefully, the above procedure helps you iron out SAP authorization findings!
I would be happy to receive your feedback, questions or suggestions – just send an email to .
Bye! 👋
Thanks for sharing this great article.