Enterprise Resource Planning (ERP) applications support businesses’ most critical processes and workflows. As such, it carries many inherent risks—the main ones being internal fraud and human error.
And statutory auditors, internal controllers, and auditors, are only too well aware of this; they’ve been increasing pressure for several years now to bring these risks under control and ensure compliance with the relevant regulations.
ERP permission-related risks that need to be brought under control
What’s needed is to take a serious look at the topic of “permissions ” (which are also called rights, authorizations, roles, or access profiles). In fact, the permissions granted to users on a company’s ERP enable them to carry out a large part of their activities—legitimate or otherwise. By ensuring you provide only the right people with the right permissions at the right time, you can significantly reduce the risks mentioned above.
Over two articles, we present our vision for this area, and share proven good practices that can bring the risks associated with ERP permissions under control.
Companies show little rigor when it comes to ERP permissions
ERP ecosystems are complex, and companies typically spend a great deal of time and energy setting their ERPs up. Yet a minimalist approach is often taken to the “identity and access management” aspect of ERPs. Over time, this results in a deterioration in levels of control and security:
- Obsolete, generic, and shared accounts accumulate.
- The number of roles explodes.
- The principle of least privilege is not properly applied.
- Toxic combinations of rights (infractions of the segregation of duties principle) occur, etc.
All of these factors tend to increase the risks mentioned above.
Key Success Factors for an ERP permissions risk-remediation project
As a result, few companies can claim to have complete mastery of the identities and permissions aspects of their ERPs. To illustrate this, consider the indicative questions below to assess your understanding of the subject:
- How many accounts can’t actually be associated with a single individual (generic accounts, accounts not reconciled with an HR repository or Active Directory, etc.)?
- How many users can change the access rights of other users?
- How many users have profiles with high levels of privilege (such as “SAP_ALL” and “SAP_NEW” in SAP ECC)? Of these, how many are really legitimate?
- How many users can change the suppliers master data?
- On average, how many roles are assigned to users? Is it typically two or three roles per user, or do numbers of roles often reach double digits?
- How many IT roles are assigned to business-function users and vice versa?
- How many roles give more rights in reality than they should theoretically provide (roles that should be read-only but have write permissions too; roles whose applicability is broader than it should be; etc.)?
How can you address the issue?
Now that the problem has been defined, what can be done about it? It’s important not to feel overwhelmed or discouraged by the apparently huge task that the issue suggests! It is possible to improve the situation and bring risks related to ERP permissions under control. In addition to the obvious point of providing sufficient resources to do it, there are a number of key success factors that must be met; and these that are the subject matter of our two articles.
1. Steering things carefully
When embarking on such a project, you clearly can’t address everything straight away. It’s more a case of strategically targeting defined scopes which will yield significant results within a reasonable amount of time. For example, it might be a key application or a central ERP module, a process that’s been highlighted in a recent audit, or a series of risks already identified as critical in the corporate risk register. The analysis of real data extracted from ERP systems can be a great help in knowing what to prioritize, and in justifying the priorities chosen.
In terms of approach, there are three areas that the project must cover:
- The analysis and control of permission-related risks—the core work of such a project.
- Implementing a technical solution that supports the chosen methodology.
- Steering and change management—both essential for the success of such a project.
It’s important to pace the project by incorporating regular milestones for each of the three areas—and for each project phase:
- The preparation phase, which includes the detailed framing of the project, putting in place the tools, and completing the prerequisites.
- The deployment phase—known as Get-Clean—aims to control the current risks, by demonstrating the approach at pilot scale, rolling it out more widely, and adjusting the tools according to user feedback.
The ongoing operating mode—known as Stay-Clean—can take the project to the next stage, but the groundwork for it must be done during the initial phase, if the risks are to be controlled over the long term.
A model approach to an ERP permissions risk-remediation project
It’s imperative to closely monitor the actions taken by the various people and decision makers involved, and, more generally, to check that the commitments made at each step are being successfully achieved. These commitments can be represented by results that are both quantitative (a reduction of X% in the number of critical risks; no more than 5 risks per user, etc.) and qualitative (the development of processes or compensatory controls). There will also be a need to measure and demonstrate the value of these results to the project’s sponsors and representatives from the business functions.
2. Preparing the ground
Technical and business-function-related questions are closely linked in projects that address permissions, something especially true in the case of ERPs. As a result, you need to put in place the right sponsors from the start: from both the security and IT sides, and the business-function and Internal Control sides.
There may also be a need to involve numerous other players: access rights officers, security managers, representatives from the business functions, process managers, team managers, internal controllers, etc. Coordination is essential throughout the project, and future contributors, as well as those affected by the changes, need to be brought on board and engaged from the start—in terms of sharing the challenges, objectives, and approach. The approach must be framed positively: it must not be about stigmatizing states of affairs or behaviors, or comparing one part of the business with another; rather, it should be about moving the company and its employees forward in the management of risks.
The preparation phase first involves gathering the various inputs needed for the project, and especially those that will enable an initial analysis of the data: organizational information about users (department, function, etc.), permissions, access logs, control repositories, segregation of duties matrices, etc. For this last item, in particular, workshops are a must if the matrices are to be completed and “translated” into technical permissions that can become automated controls within a tool.
There is also a need to define the indicators, dashboards, and reports that will be used both during the project phase and also in the long term by those in charge of continuous monitoring.
Another important activity during this preparatory phase is to improve data quality. This prerequisite becomes all the more indispensable when a company’s maturity level, in identity and access management terms, is low. Improving quality isn’t just about user accounts though, it’s also—and especially—about the ERP authorization model. If the roles or access profiles themselves carry risks (in particular, in terms of the segregation of duties), this must be remedied before tackling the individual risks introduced by users.
Examples of prerequisites for an ERP permissions risk-remediation project
We’ve now discussed the first two key success factors in an ERP permissions risk-remediation project: close steering and preparing the ground. Three other key success factors will be discussed in a second article, to follow.
