Can your organization afford to ignore the ERP security problems?
Last week we ran an ERP security audit for a client, and the results revealed that their security was wide open. Out of 2,000 users on their system, more than 200 could access key sensitive programs, change processes, or update supplier data.
But they are not going to do anything about it.
The problem with planning IT projects is that there’s never enough resource, so obtaining buy-in and budget can be a nightmare – especially right now. Different parts of the business compete for a share of the action, and it’s not surprising that projects focusing on increased revenues and/or cost savings are given top priority.
Infrastructure projects, such as ERP security, are less glamorous, but they can also be crucial to an organization’s success. You need to build a compelling business case, but how do you justify the need for an ERP security project in a mid-market manufacturing business? Let me help.
What’s the purpose of an ERP security project business case?
All IT projects of any real scale should have a business case. (That’s just lost the readers on the Systems Integration side of my audience.)
Its purpose is often misunderstood, but it’s not just about securing the funding. It’s also about communicating your project’s value to the business and getting the stakeholders on board. The business case must clearly articulate why the organization needs your project, and the benefits it will yield.
What opportunities will it open up, and/or what problems will it solve? What impact do they have on the success of the business?
The business case also provides a measure of success or failure, by setting targets for cost savings, timescales and improvements. (And there I’ve managed to lose the other side of my audience, IT management worldwide.)
The objective of an ERP security project is usually either to make security and controls more reliable and robust, or to reduce the effort (and therefore cost) of managing them – or both. So cost-savings may be an important part of the business case, but it’s also critical that the CFO fully comprehends the potential cost of NOT undertaking your project.
The thing that often gets forgotten when making the business case is risk.
It’s important to consider the risks and costs of inaction – i.e. what could happen if this ERP security project doesn’t go ahead?
What are the costs and risks of inaction?
In the case of my audit client, the main risk of doing nothing is the company’s vulnerability to fraud. Research shows that up to 50% of companies of this size fall victim to internal fraud every year, with an average loss of $250k.
The ERP Director’s personal risk is that he would then lose his job – but I’m not sure that would play particularly well with the CFO who is going to sign off this business case.
But there are other risks such as the ability to manage security effectively through changes such as acquisitions, disposals and downsizing. Are your existing processes robust, or are they about to break open?
How effective are your internal controls? Is it time to review your Segregation of Duties (SoD) policies and reporting processes? Do you need to strengthen your procedures for approving user access requests and introduce proactive SoD checks? Internal auditors can often help you build your case for improving internal controls. They never have budget, but they do play a very important role in making sure that controls are effective.
Is there a risk that external auditors could identify material weaknesses in the internal controls, and what would be the impact of that? That might interest the CFO.
Having said all that, it’s usually cost savings that most interests the Chair of the steering group, so it’s important to evaluate efficiencies, e.g. in annual audits, in improved controls such as User Provisioning, and in streamlining Periodic Access Reviews.
There’s a lot to think about, but in my experience, there are almost always enough hard and soft cost savings to build a convincing business case to sell your ERP security project to the stakeholders.
What are the risks of getting it wrong? Minimizing ERP security project risks
Finally, it’s crucial to consider the risks of actually carrying out the project.
What would be the impact of time and cost of overrun? How can you ensure that users thoroughly test access? How can you prevent situations where users are accidentally locked out when you go-live?
On this project, failure isn’t an option, so your project plan needs to identify and mitigate risks such as these.
Let me summarize by giving you 5 key drivers to success for an ERP Security project:
- Use specialized tools for Internal Controls. Automating controls wherever possible is the best way to reduce both costs and risk, as well as to ensure that the controls are sustainable.
- To minimize the risk of failure, work with a partner with multiple relevant experiences (e.g. audit skills as well as ERP skills; but note that there are large cost differentials between types of service provider).
- Consider your controls from a holistic viewpoint, as they are often linked. Efficiencies in one area (e.g. automating SoD reporting) can yield savings and improvements in other areas (such as compliant User Provisioning, incorporating proactive SoD checks).
- Be pragmatic. It’s better to start off with 10 SoD Rules which prevent the high-risk access combinations, then add more later, rather than jeopardize your project by attempting to eliminate all risk, which can only result in failure.
- Implement Role-based Access Control. Done well, this can yield enormous savings in security management and compliance costs, so evaluate carefully the different approaches that solution providers take to it.
In reality, there’s no such thing as “one-size-fits-all, Best Practice” roles. Your processes are different from the next company’s. But many common processes will be close, so using a well-designed set of Roles as a starting point makes a lot of sense.
There’s an old English story of a tourist who walks up to a policeman in Leicester Square, in London, and asks “how do I get to Glasgow from here?” The policeman replies “Well, I wouldn’t start from here…”
If you have an ERP security model that you’re afraid to touch, or if you can’t get funding to improve it, you need to know where you’re starting from. Perform an audit. And then your friendly local policeman (or consultant) can guide you forward with a business plan and a map. There are lots of good short cuts.
If you need help with your ERP security challenges, contact us here.