How does a business manage technology changes: an IT auditor’s perspective

“The only thing constant in life is change.”

This maxim, famously quoted by Heraclitus, refers to change as being the fundamental essence of the universe. Human nature forms a part of that universe and as humans, we continuously strive to better ourselves. We attempt to attain this during our daily work and recreational activities. Similarly, companies constantly hope to improve the products or services they offer. Change is inevitable and essential for the advancement and long-term prospects of a company.

Changes to IT systems do not occur in a vacuum.

Each change implemented impacts business processes and consequent reactions. It is crucial to manage change in a way that minimises any negative consequences. Should they occur, such negative implication can result in financial loss and reputational damage, in the event of a system failure; or regulatory sanctions if breaches had to materialise. Moreover, when organisations lack a proper procedure for change management, they run a significant risk as the likelihood of unauthorised changes introduced into their main production environment is higher. As an IT Auditor, one must ask the same basic but important questions to auditees:

“Do you have a documented policy/procedure on change control?”

Whether it is on account of a regulatory requirement or due to a business need, documented policies and procedures have become more commonplace to ensure that changes are being carried out within a company’s established standard. Management want to ensure that the rules established by the business are followed. The key question here is whether management is keeping the documented procedure updated to reflect the current way of operation. Through reviews of such policies and a proper understanding of the IT and its environment, the IT auditor will be able to identify whether such policies/procedure are protecting the IT investments / assets of the business.

“Are changes being documented, tested and approved prior to going to live?

Here, documentation is key. Keeping documentation of the process flow is crucial to management, where, in the event of an incident, they would be able to analyse what went wrong. For an auditor to confirm completeness, a sample of system changes from the production environment would be selected. From there, one would look for documentation related to each of the selected changes to confirm whether these have been authorised, tested and approved. Key areas to look out for here are ensuring that documentation on the responsible person who performed the task is clearly logged, that any testing performed by Quality Assurance personnel is done so on a machine other than the production environment and that proper approval is given by management prior to release of such changes within such environment.

“Is segregation of duties within the change management process in place?”

The final question is where it gets a little tricky. The development process should be segregated between the development, staging and production environments. This ensures that the development function is separate from those in charge of approving or releasing such change. The issue arises when the developer has access to the production environment. There are a number of reasons why this may happen:

• The IT team is composed of a small team of developers and/or no system administrators.
• Weak governance structure.
• Developers need access to the production environment to test and troubleshoot.

This can create an issue. In such circumstances, there is a risk that would enable unauthorised changes being implemented into the production environment, thereby creating an issue of accountability were the impact of such changes cannot be quantified with respect to the financial or other key information being presented.

Procedures should be in place to ensure that access to such systems is limited. There are a number of ways in which one can perform this. Firstly, access to release changes to the system is restricted through authorised deployment tools. This would ensure that changes are appropriately channelled. Secondly if access is required by developers, it should be on a read only basis ensuring that no unauthorised changes take place. Lastly, if an emergency deployment by the developer is required, access to production should be given prior to deployment and revoked once the process is performed. A log of when such access is given to developers should be kept for completeness purposes.

Peace of mind

Answering these three basic questions should give peace of mind to those charged with governance in ensuring that the management and co-ordination of change implementation is being carried out in accordance with best practices. It therefore remains the responsibility of the directors and management of the company to ensure that checks and balances are in place to monitor technological changes, which if managed appropriately should protect the business and lead to improvements in the day-to-day operations of the organisation.