We have cited five key success factors needed to deliver an ERP permissions risk-remediation project:

The key success factors for an ERP permissions risk-remediation project

The first two key success factors were discussed in the previous article; and the other three are covered in this one.

3. Preparing for large-scale deployment

Services, business lines, geographical or legal entities… the remediation of permission-related risks means reviewing user accounts across varied—and often numerous—functional areas. To be able to keep to schedules, limit workloads, and reassure those involved in the project locally, it’s best to deploy things at as larger scale as possible. Doing this means:

• Defining and communicating the risk analysis and remediation methodology;
• Putting in place a steering plan;
• Introducing analytical tools, automated as far as possible, to cope with volumes;
• Formally preparing materials for workshops and consolidation sessions;
• The documentation for the methodology and the tool in order to be able to train users.

These documents will form the deployment kit to be used in the different areas of work of the project phase; this can also continue to be used when the project phase is complete.

The deployment kit for an ERP permissions risk-remediation project

The deployment methodology will need to cover the following activities, and will need to be recreated for each area of work:

• Risk assessments and the definition of KPIs.
• Remediation workshops for user-related risks.
• Validation and execution of remediation plans.
• Training and support for upskilling.

Obviously, the methodology must be adapted to the company’s organizational structure and the resources available to it: the workforce, local variations in business processes, the degree of maturity in risk and permissions management, etc.

In particular, this will involve engaging local experts both on the technical aspects of permissions (access rights officers, application owners, security officers), and on the business-function aspects of processes (business-function representatives, process owners, internal controllers, team managers, etc.). The contribution that will be expected from them, and the effort they will need to put in, should be clear from the start and must remain “reasonable”. Local managers should therefore be involved, to ensure that those who need to take part do so, and to help in decision-making.

During remediation workshops, participants will, in particular, analyze user-related risks, but they will also have to consider various remediation strategies, such as the ones described below:

Strategies to consider in an ERP permissions risk-remediation project

It’s always preferable to validate the methodology using a pilot project that is small enough to limit work volumes, but large enough to be representative of the company. In some cases, a better strategic choice may be to select a work area that’s likely to be more fruitful for the project; or, conversely, one that’s expected to require more support. The lessons learned at the pilot stage will allow the methodology and tools to be adjusted before they are deployed more widely.

4. Selecting the right tools

The tools put in place must aid success during the project phase, but also—and more importantly—provide long-term support for the chosen approach; both these phases must be complementary.

Being well equipped is about being clear on the initial controls to be applied (at the point when new permissions are requested) as well as on the ongoing controls (those applied once permissions have been granted). Having more initial controls will help reduce risks, but operational efficiency may also suffer (delays, difficulties in processing requests, etc.); a balance needs to be found.

From a functional point of view, it’s a question of putting in place the families of controls typically found in such projects, namely:

• Data quality controls: completeness and coherence of data; respect for nomenclature, etc.
• IT security-rule controls: orphan, dormant, and administrator accounts; temporary and residual permissions; IT accounts with business-function permissions and vice versa, etc.
• Business-functions rules/compliance controls: discrepancies between jobs and the associated permissions; discrepancies in permissions between members of the same team; breaches of rules on the segregation of duties; users having access to areas that are beyond the scope of their responsibility, etc.
• Usages and behavior control: excessive or unusual uses, suspicious behavior, typical fraud scenarios, etc.

Families of typical controls for an ERP permissions risk-remediation project

Being well equipped is also about prioritizing and automating the controls that are worth putting in place. The return on investment must be assessed in terms of each control’s relevance to the company’s situation (does the control cost more than dealing with the consequences of the risk it’s designed to cover?), and the potential benefits of automation (how much will be saved compared with a manual process?).

The volumes and complexities associated with ERP authorization models means turning to tools specifically designed for the task: for example, it’s not unusual to see SAP systems with several thousand roles and over a hundred thousand fine-grained permissions (transactions and authorization objects).

These needs fall at the intersection of several different segments of the software market; these are currently highly dynamic and far from mutually exclusive: “Identity and Access Management”, “Continuous Control”, “Specialized Governance-Risk-Compliance tools on a given ERP”, and so on. Given this, the approach taken, degree of maturity, functional coverage, and mode of delivery (on site or cloud/SaaS), can vary substantially from one product to another.

When selecting a tool, it’s a question of considering the following elements carefully:

• Ergonomics and ease of use: once the project is finished, the tool’s users will be mostly from business functions—not from IT.
• Customization options: such that the tool really can be used to support the methodology taken (vocabulary and screens, rules and controls, dashboards and reports customized to company needs, etc.).
• A package of preconfigured controls: usually based on good practice, for the company ERP.
• The ability to put in place controls on other applications, and between applications: over the medium-term.
• Analysis and decision support functionality: to highlight anomalies, simulate changes in permissions, conduct in-depth analyses, suggest remediation measures, etc.

Although the tools are generally not intrusive, in terms of their effect on applications, there’s still a need to automate the transfer of data, in a reliable way—from the ERP and other potential repositories. Involvement of the relevant IT teams will thus be needed too.

5. Getting things right for the long term

Projects of this type only make good sense if permission-related risks can be controlled effectively over the long-term. Doing so avoids the problem of risks that have been brought under control during the project appearing again—some time later.

To encourage long-term buy-in to the approach and tools put in place, it’s essential to invest in change management from the start—and throughout the project—by means of meetings and regular newsletters, training and coaching sessions, documentation and tutorials, etc. It’s best to use a diversity of channels and communication supports to reach the maximum number of people without giving the impression of over-marketing.

It’s also important to help those responsible for permission-related risks to apply new controls to their recurring activities. In fact, the frequencies of advanced controls, the objectives to be achieved, and the levels of risk that must not be exceeded, can be explicitly defined. These objectives must be realistic and progressive: “What’s needed is to envision a long road—but with short milestones.”

There must be an emphasis on community too: it’s important to encourage interactions between managers from different functions, which will enable them to share experiences and good practice. There may even be a value in introducing a degree of healthy competition between different business functions; perhaps even organizing some low-key challenges. However, you should ensure that the fact of making progress is valued more highly than achieving any specific numerical objective, because the various work areas will have to progress from very different starting points.

Finally, an “ongoing” mode needs to be implemented—to ensure that permission-related risks remain under control once the project is completed. This should include:

• Choosing a designated contact for the methodology and tools put in place;
• Upskilling the technical teams to ensure in-service support for tools, and that reports and controls can be developed when necessary;
• Documenting and capitalizing on the knowledge acquired during the project phase.

This must give consideration to developing a roadmap for other future activities that will address new processes, risks, applications, or populations.

Long-term control of the risks related to ERP permissions

In conclusion: it can be done!

As we’ve seen in the two articles on this topic, controlling the risks related to ERP permissions means pursuing a number of key workstreams—from putting in place the right tools, through holding workshops for the business functions, to training and change management.

But with a good methodology and committed participants from IT and the business functions on board, anything is possible! Tangible results can be achieved—and corporate momentum built—within a reasonable timeframe, to regain control of permissions across the IS. And, lastly, the key success factors presented here are broadly applicable to applications other than ERPs.

Cet article ERPs: How to control permission-related risks (PART 2) est apparu en premier sur RiskInsight.

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.

Cet article ERPs: how to control permission-related risks (Part 1) est apparu en premier sur RiskInsight.