What is SAP access management all about?
Well, in order for people to use your SAP system, you need to give them a user ID to log on to the system. That’s the easy part.
But next, you need to assign access rights to the user-ID so that people can use the functionalities they need for their job. That sounds easy, but in practice this is the difficult part!
SAP access management is about how access into your SAP system is controlled and managed. This includes access into the system itself (e.g. through user-IDs) and the rights that the access gives once the user has entered the system (i.e. what functionalities the user can perform).
Why is it so difficult to figure out what access people need in SAP?
Firstly, in many organisations, the tasks that people are supposed to do in SAP constantly change. People join, leave and move in the organisation all the time. Just when you thought you had it all figured out, the tasks have changed again!
Secondly, translating business tasks into the appropriate SAP authorisations can be a complicated and time-consuming job. Not only does this require someone who understands business processes well, a deep understanding of technical SAP authorisations is also crucial. To have someone who can speak both business and technical languages is rare – in fact, communication (or the lack of) between business and IT is often a source of frustration and mistakes in many IT projects, including access-related ones.
Finally, adding to the complexity: There is a very thin line between giving too much access and not enough access. People typically will only voice complaints when they don’t have enough access, as it stops them from doing their work. On the other hand, we don’t often hear from people when they have too much access. We can only hope that the excessive access is not used.
SAP users usually have ‘too much’ access
As a result of the difficulties mentioned above, many organisations using SAP tend to accept that people inevitably will be given more access than they need.
Can this be avoided? Not really.
You can only do that if you are willing to employ one SAP access administrator for every 10-20 SAP users in order to continuously and diligently fine-tune each user’s access rights to precisely the activities that the user is supposed to do in SAP. That is impossible.
Then, how do we deal with the risk of too much access?
Well, three words: Segregation of duties (SoD). Segregation of duties means that certain task combinations should not be performed by one and the same person, in order to prevent error or fraud. An example of tasks that should be segregatedare posting invoice and changing vendor master data.
Therefore, while we may end up giving users too much access in SAP, it is generally okay as long as the access does not have any SoD risks, i.e. they have no access to perform conflicting tasks.
Another type of access risk that should be managed is critical access risk. When both segregation of duties and critical access risks are managed well in an organisation, we can consider access management in the organisation’s SAP system to be well-governed.
What is a critical access risk?
A critical access risk exists for access rights which, if improperly used, can easily lead to error or fraud. Some examples are: Access to open/close accounting periods and access to change SAP tables in production. Critical access rights should be restricted to users who need them as part of their day-to-day tasks and their usage should be monitored.
Critical access risks and SoD risks both form what is often referred to as access risks. SoD risks tend to receive more attention, perhaps because (1) It is more intuitive to understand that critical tasks need to be monitored, and (2) SoD risks are more difficult to define, detect and monitor.
Is there a common list of SoD and critical access risks for the SAP system?
Every audit, consultancy or software vendor operating in the SAP authorisations area. Maintains such ‘common best practice’ reference list, but there is no one accepted, certified list of all access risks which is universally used.
The examples mentioned above (SoD example: post invoice vs. change vendor master data, critical access example: open/close accounting period) were taken from XS Control’s specific list of common best practice access risks. We usually refer to this list as the access risk rulebook. Every risk is rated in terms of its severity.
You are encouraged to use any such list as a reference point to decide upon the list that is applicable and relevant to your SAP system and risk appetite. The list should also be further tailored to your business and technical requirements.
How do we then identify users having access risks?
These are usually referred to as users with access risk violations. The access risk is said to have been violated
Each access risk is essentially made of one or more tasks: Critical access risks comprise of one task only; SoD risks can have two or more conflicting tasks.
A set of SAP authorisations is required to perform each task. For example, to open or close accounting periods, a number of authorisation objects with relevant fields and values have to be assigned in order for a user to be able to perform the task. Therefore, in order to identify who has access to open or close accounting periods, we need to find users who have been assigned all of these authorisation objects with the relevant field values.
Going back to the question, how do we identify users with access risk violations?
- Each task is translated into SAP authorisations.
- For critical access risks: Identify users who have been assigned SAP authorisations required to perform the relevant task. For SoD risks, identify users who have been assigned SAP authorisations to perform all the conflicting tasks.
Is it fair to exclude system support users from access analytics?
Every SAP system will require user-IDs to be used for interfaces, batch processing and system support activities. These are examples of support user-IDs.
Support users are required to ensure that the system is available and well-maintained, in order to be able to support business operations effectively. Typically, the access rights assigned to these user-IDs are very broad, sometimes even unlimited. This means that a misuse of these user IDs can lead to access risk violations with a higher impact to the system and to the business itself, to the point where business continuity could be affected.
Support user-IDs are not usually included in access analytics. This is because, despite their broad access, the risks they post to access risks are known and accepted. Therefore, they are managed differently, often by the use of temporary user-IDs.
Within SAP GRC terminology, such temporary user-ID’s are referred to as Firefighter user-IDs. A separate set of controls exist to manage Firefighter user-IDs. Similar controls can also be performed outside SAP GRC software.
Is it easy in practice to identify users with access risk violations?
Supplementary tools such as SAP GRC Access Control or other specific third-party tools have built-in features to report on users with access risk violations. Therefore, if you use such a tool then the answer would be yes: those users are easy to spot.
These tools can usually also identify roles with access risk violations just as easily. This is useful because it lets us know that users with these roles will by default carry the same underlying access risk violations. We will talk about tooling more later.
However, for organisations using SAP ECC or S/4 HANA in its standard installation (i.e. without SAP GRC), there is no easy way to spot users with violations. It would simply be too time-consuming to do such an exercise manually without a tool.
In theory, it is possible to identify users with violations by examining the roles assigned to them, but this would only be true where the roles have been built and maintained following stringent best-practice role building procedures and where each role is free from access risk violations itself. These conditions might seem straightforward and achievable; however, in practice it is rare that we find clients with roles which have been built and maintained up to such rigorous standards.
On top of concerns around security compliance, inadequate role building practices can also lead to maintenance and other technical issues. Simply put, weakly-designed roles require more time and effort to maintain and are difficult to use. Find out how XS Control can help assess and design your roles.
It sounds like installing additional software is unavoidable – is this true?
A complete and accurate insight of access risks in your SAP system requires indeed additional software. But it does not mean that you necessarily need to purchase and install such additional software yourself – it depends on how often you want to perform a check on access risks.
Some organisations want it once a year, others monthly or quarterly and some organisations want it permanently. A permanent check basically means that every change in user access rights will be subject to an access compliance control. The latter case certainly demands that additional software is available at all times. This can be realised with on-premise software installation or alternatively with a subscription to a cloud-based software.
If you just need an infrequent, periodic check of access risks, then you may opt to have it delivered to you as an all-in service. Such a service can be provided by your SAP implementation partner, independent auditor or specialist vendor. The vendor will use their own chosen additional software to analyse the access rights in your SAP system and produce relevant reports for you. You just need to provide the data to be analysed.
Find out how XS Control can help you with these services here.
Is a permanent check on access risks required?
It is all about the risk that you are willing to take. Let’s say you’ve looked at the Q3 report of access risks and all reported violations have been addressed. Between the Q3 and Q4 reports, new users may require access to SAP or access of existing users may require to be changed. If there is no requirement or there are only few requirements for new or updated user access, then a permanent check on access risks does not add much value.
In principle, every request for new or changed user access to be processed between the Q3 and Q4 report, should be checked for compliance. Compliance means that access rights belonging to a user does not carry any SoD or critical access risks, unless the critical access risk has been approved/signed off.
Without additional software, such check can only be done as a cursory check based on the user vs. role list (assuming the ideal practice is above is followed). If your role-naming is comprehensive, such check can still be quite meaningful. But there is always the risk that a user is unintentionally granted access rights which result in risk violations, which is not spotted until flagged by the Q4 report.
Is it best to implement SAP GRC in addition to SAP ECC or S/4 HANA?
As mentioned in the previous paragraphs: A complete and accurate insight of access risks in your SAP system requires specific software in addition to standard SAP ECC or S/4 HANA. First, you need to decide whether you want to run your own additional software solution or to have the compliance checks delivered to you as a service. If you go for the first option, then it is useful to know that you can choose from a range of supplementary software solutions from SAP itself or from third-party vendors.
These solutions each have their specific strengths and weaknesses and it really depends on common software selection criteria (such as functional requirements, data volumes, budget, integration with existing technical and functional system landscape, etc.) to determine which solution is best for your organisation.
Generally, SAP GRC is at the high-end of the implementation price and effort range. If you don’t want to spend this kind of price and effort, then SAP GRC is perhaps not the most suitable for you. However, it is certainly a reliable choice and it comes with the peace of mind of having SAP as your one-stop, long-term partner for everything relating to your SAP system.
If your budget is limited and you are pressed to resolve your SoD issues urgently, it may be wise to evaluate some of the third-party vendor solutions. There is a good chance that your short-term requirements can be fulfilled sooner and more efficiently at a lower implementation cost with less effort.
To find out more about MARC, XS Control’s preferred software solution, please click here.
How can outsourcing of compliance checks work at all?
Outsourcing of access compliance checks may be suitable for organisations that lack the expertise, additional software and manpower to conduct a periodic or permanent compliance check on access rights. A service provider like XS Control can be engaged to perform such compliance checks and provide you with the ready-to-interpret reports.
XS Control uses MARC as subject matter software to deliver such service. MARC runs in the cloud and works with customer data in either an offline or online mode.
Offline mode means that no connection will be made to the customer’s SAP system. The customer extracts required data from their system using a data extraction tool provided by XS Control; XS Control then processes the data and produces the relevant reports. The customer can choose to have access to the MARC environment for their specific organisation (stored in the cloud and accessed on a webpage), where they can explore and download the results in various formats. Alternatively, the reports can be provided to the customer in an Excel format.
For more frequent or even permanent compliance checks, an online RFC (Remote Function Call) connection between MARC and the customer’s SAP system will be preferred. In this case, XS Control will manage the data extraction, data processing and reporting, while the customer can still have access to the cloud-based MARC environment and all the reports.
Over time, if the customer wants to move from outsourced compliance checking to in-house compliance checking, then the MARC configuration can be smoothly handed over to the customer without any re-installation or re-configuration.
To find out more about MARC, XS Control’s preferred software solution, please click here.
What if an SoD risk is reported but the user really needs the access rights?
It is not uncommon that the additional compliance software flags a user for having conflicting tasks which are actually required to perform the user’s job responsibilities. Hence, it is not an option to take access to these tasks away from the user.
We can respond to this challenge in one of two ways: To ‘fine-tune’ the SoD configuration in the software or to ‘mitigate’ the SoD risk.
- Fine-tuning the SoD configuration is recommended as a first step in any such situations. Fine-tuning is typically done by adding an additional authorisation component to each task. By fine-tuning the reported risk specifically to your organisation, you may discover that the user does not really have access to both/all of the conflicting tasks. In that case, there is no real risk involved, hence the reported violation is a so-called ‘false positive’.
- If the risk violation is indeed true and access to both/all tasks are confirmed to be required by the user, then the solution is to mitigate the risk through reliance on mitigating controls. Mitigating controls are other controls which are in place (or can be put in place) to prevent or detect any impact of the conflicting access rights being performed inappropriately (for example, to prevent or detect any errors or fraudulent actions).
Find out how XS Control can help you fine-tune your rulebook and manage your access violations.
How do I know if a reported risk violation is ‘false’?
We discussed earlier that the rulebook should be tailored specifically to your organisation’s specific needs and risk appetite, by only selecting relevant access risks. Assuming this has been done, the reported access risk violations should appear to be valid at first sight. Even so, it may transpire that the users who are reported as having violations in reality cannot use the reported access rights. The only effective way to find out is to perform a test in the (test) system.
The cause of such false reporting is that SoD compliance software performs its analysis/processing using an ‘out-of-the-box’ rulebook configuration. Occurrences of such ‘false’ reporting can be minimized by ensuring that the access risk configuration in the rulebook follows the configuration settings of your SAP system – this is achieved through the fine-tuning activities mentioned in the previous section.
How can I mitigate access risks? Is there a common best practice list of mitigating controls?
As mentioned before, there are various common best practice reference lists available for access risks to avoid in the system. In principle, each access risk on the list can be tagged to a preferred mitigating control, but the chosen of the mitigating control is highly dependent on the way your business processes are configured in SAP and would be highly individualised for each organisation. That is most likely the reason why no subject matter vendor would publish a common best practice list of preferred mitigating controls.
Hence, you will need to leverage the expertise of your consulting partner or subject matter specialists in your organisation (e.g. Internal Audit) to define the mitigating controls best suited to your situation and SAP system.
Just to be sure: Is it safe to mitigate all reported violations?
Basically, by mitigating reported violations, you are saying: ‘No worries – access can still be given. We will cover the risks in a different way’.
Where there is a large number of reported violations (whether true violations or false positives), there will be a tendency to mitigate them as an easy way out. It saves time and effort from SAP administration and configuration perspectives, but it shifts the workload to the business (non-IT) part of the organisation. This is because usually, mitigating controls are managed and executed outside the system and are under the responsibility of the business.
If all mitigating controls are properly defined and diligently executed, then any executed violations should be prevented or detected, which means that the corresponding risks are properly addressed. Again, this is a big ‘if’. It is very common, especially where there is a high volume of reported violations, that mitigating controls are not properly defined or regularly executed. A mitigating control which has not been properly defined may not fully/appropriately address the access risk and may create a false sense of assurance.
Additionally, mitigating controls are usually designed to detect conflicting/critical tasks rather than to prevent them. If these tasks are really damaging for the organisation, detection is usually ‘too little too late’.
What exactly is the worry surrounding a reported access risk violation?
In reality, whether an access risk has been violated or not is less important than the impact of its violation. A reported access risk violation means that the potential for impact is now present in the system. Whether or not the impact is realised depends on whether the task(s) defined in the access risk have been executed or not.
An example of impact which would be worrying to the business is theft of cash. There are also other impacts outside the financial scope which affect the organisation (such as HR disciplining policy, etc.). This would likely fall outside the scope of most SAP-related projects.
For our purposes, we only cover system-based impact. Essentially, such impact takes the form of unauthorised data changes in the system. By data, we mean any transactions, configurations and master records in the system.
Can the supplementary software show also the impact of the reported access violations?
Unfortunately, most of the access control compliance software can analyse only the potential, not actual, access risk violations, by analysing the so-called transaction usage data. Transaction usage data does not show whether any impact of reported access violation has occurred. It only gives an indication of whether the users have used the assigned access rights within a certain time interval.
The reason is because transaction usage data is based on SAP’s statistics data which provides a minimal level of detail. At most, it shows which user at what date and time has pressed the menu button to start an SAP transaction code. If this transaction code is defined for an access risk, the usage will be reported. Starting a transaction code does not mean that the related transaction is effectively completed, nor does it reveal whether which data (if any) were updated.
Identifying actual data changes requires specific data analytics exercises to be done on the various SAP business data tables. The relevant tables vary between access risks, as they depend on the actual business process and transactions affected.
Additional software products such as Access Violation Monitor by SAP, SAP GRC Process Control or MARC Internal Control Monitor (ICM) would be capable of performing such analytics.
Isn’t it more efficient to just check impact of violations instead of just reporting violations?
Understandably, there is a drive towards checking the compliance of data rather than checking the compliance of access rights (which are used to update said data). This is the argument between preventive controls (via compliance of access rights) versus detective controls (through identification of inappropriate data changes).
The reason is that compliance check of user access rights requires a good amount of time and effort. You need to first define a rulebook, fine-tune it, then analyse the data to identify any access risk violations. Even then, the results which are reported in terms of ‘risk violations’ still do not tell you whether anything bad has actually happened.
Nonetheless, ignoring the access risks and instead only checking the data itself is not to be underestimated in terms of efforts and complexity. Even with today’s ‘big data analytics’ technology, you will still be required to define the configuration parameters on the basis of which actual violations can be detected. For example, MARC ICM (Internal Control Monitor) module has the capability of detecting vendor payments processed to bank accounts which are different from the bank account in the vendor’s master record. The output, however, will still require further analysis to determine if there are any false positives and, if so, fine-tuning of the analysis configuration will be required in order to filter out other potential false positives from future runs.
Also, such data analytics will inherently always look backwards: Detecting violations that have actually occurred. It does not give any assurance on whether such violations can happen in the future. For that, you will still need to evaluate access rights of the users.
Get our newsletter delivered to your inbox monthly
Blog posts, webinars, tips and more! Make sure you don’t miss out by signing up for our newsletter.