Small Changes Can Make a Big Difference: Change Management and Beyond
As part of our ongoing series on General Computing Controls (GCC), this article will focus on change management. As discussed in earlier posts, the objectives of general controls are to ensure:
- the proper development and implementation of applications
- the integrity of program and data files
- the integrity of computer operations.
When testing your GCC controls, auditors will investigate how you manage changes to your ERP system.
Change Management Risks
Any changes to current processes and procedure can introduce risk. For example, if an application is updated or enhanced with new functionality, do you have documented policies in place to manage the introduction of these changes to the live system?
One of the biggest risks is when developers have access to the production environment, or when they have the ability to develop and promote their own projects. How can you be sure that they are not making unauthorized changes, whether accidentally or with malicious intent?
Change Management Controls
The auditors’ emphasis here is to ascertain that you have stable change management processes to make sure that all changes are requested, authorized, tested and approved by appropriate people before they are migrated to the live system.
You should also ensure that these tasks are appropriately segregated. Auditors are likely to look at samples of change management tickets to test these controls.
Companies often struggle with this, particularly where there is a small IT team. If it’s just not possible to segregate the tasks adequately, you must have a robust means of mitigating the risk by making sure that developers’ access is appropriately monitored – and be able to provide evidence. For example if you use procedural controls, the auditor may ask you to prove that they are enforced by appropriate people.
Monitoring tools can help. They allow you to monitor changes to critical data items, such as system configuration data, statuses and application versions in menus and you can configure them to issue automated notifications when unauthorized changes take place.
These tools will also keep a detailed audit trail of all changes to the monitored fields, logging before and after values, the identity of who made the change and the date and time.
Your Change Management policies should make it clear how you control the processes; i.e. whether you use preventive controls such as SoD or detective controls such as monitoring.
Change Management is also important when business users can create their own reports. For example, our consultant auditor came across a situation where an accountant created a trial balance report which was included in audit evidence. But it hadn’t been rigorously tested or subjected to a change management process, and after three years it was found to be inaccurate. As a result of that the company had to restate their financials for those three years.
Other Risks: Operating System Considerations
Some auditors will consider risk and controls at the Operating system level, particularly regarding privileges on some operating systems such as iSeries.
Administrator level privileges should be limited as they could potentially enable users to take over any application on the system.
Service accounts and devices such as printers, fax machines and copiers are easy access points for someone with malicious intent, who could hijack the profile and adopt its authorities even if they can’t login as an interactive user. Ensure that they don’t have elevated privileges and change and expire the passwords on these accounts.
It’s worth noting that in Windows environments, operating system issues such as missing or non-compliant passwords are very unlikely to lead to misstatements. Although it’s good to have controls in place to avoid such errors, and the auditor may wish to test them, any risks found are not going to materially affect the financials.
Risks at the database level, such as SQL injections, need to be considered as they can affect your ERP system.
Manipulating the figures at the database level is very complex due to the many interactions involved – they’d need to update the figures in multiple tables – but someone with the right knowledge and serious intent could commit fraud.
Implement controls around database access, such as restricting who can directly login to the database, as opposed to accessing the database via the applications.
Default passwords on database accounts are often widely known, so make sure that you change them.
ODBC is used by applications, but this kind of access can also be exploited, so control who has access to it.
We hope you’ve found this series of posts helpful. If you need help with assessing and managing the risks in your ERP system, here’s some information about our audit management solutions and services.