Itgc and System Change: a Brief Overview

Information Technology (IT) has become prevalent in organizations and is embedded in business processes across all functional areas, replacing cumbersome and aging analog procedures. Large scale IT infrastructure has helped create meaningful cost savings and improved operational efficiency, while IT applications have helped spur innovation and help generate competitive advantages.

The advent of IT has led to our time being branded as the “Information Age”, and every organization has had to adopt IT or risk becoming uncompetitive and irrelevant. While there are numerous benefits to be realized from the use of IT within an organization, it has also given rise to new and complex risks and has significant implications for the audit profession, such that it led to the creation of a new type of audit role altogether, i. e. , the IT Auditor. New IT related risks include, but are not limited to, three domains, security concerns, regulatory compliance requirements, and effective governance. These risks are mitigated by the use of Information Technology General Controls (ITGCs). ITGCs play a crucial role in ensuring process function according to their purpose.

Specific ITGC benefits include financial measures such as completeness, accuracy, and validity. Non-financial objectives include confidentiality, integrity, and availability as well as the effectiveness and efficiency of processes (Amasaki, 2015). The use of effective ITGCs yields many benefits, the most prominent of them being that users can rely on their IT systems to a reasonable degree, auditors will attest to the quality of controls readily available, and investors can reasonably rely on the information they are given (Miron, 2008). Additionally, effective ITGCs will ensure there are fewer regulatory problems faced, therefore the organization’s reputation is enhanced, and it can meet its business objectives (GTAG 1). Ineffective ITGCs will have the opposite effect. Critically, the organization will fail to achieve its objectives and they will fail to work towards achieving their mission and vision in the long run. ITGCs are closely related to the “business” the organization carries out. As IT is embedded in practically every process and function, IT related risks are also embedded in them.

The use of ITGCs in these processes can reduce or even eliminate said risks, directly impacting the output of these processes and therefore affecting the performance of the organization. ITGCs can also play a vital role in Sarbanes Oxley (SOX) audits. Section 404 of SOX specifically requires IT related risks and controls to be considered in the overall evaluation of internal controls over financial reporting (Protiviti, 2012). Essentially, ITGCs must support an environment where the integrity of data can be maintained. A key part of this is making sure controls are in place that help prevent unauthorized or malicious users from compromising the integrity of data.

Risks Associated with System Change ITGCs

As IT is continuously evolving, capabilities need to be upgraded to maintain competitive advantage. Business needs evolve, and systems need to evolve to meet these changing needs. In some cases, a smaller change known as a “patch” is needed to fix/upgrade minor issues with the system. Making changes to the system can give rise to risks which need to be carefully managed to ensure the change is successful. A major risk that can derail the change is the absence of a structured change management process (Miron, 2008). Just as a robust project management methodology improves the quality of a project and helps on time deliverance, a change management process improves the success rate of the change and helps the organization stay in control of the process.

The absence of such a process leads to increased downtime of key systems and mounting costs, among a host of other issues. Another key risk is the inadequate testing of changes before they are implemented (Miron, 2008). This opens the door to poor integration of the change if integration testing is not carried out, a high failure rate if it is tested inadequately and in the wrong environment, and poor user acceptance of the change if user acceptance testing is not a part of the testing phase. Tests are crucial to mitigating these issues. Unauthorized and poorly logged changes are also risks that arise during the system changes (GTAG 2). Both these risks result from IT personnel circumventing the change management process. Changes need to fit in with the overall philosophy of the system change and the purpose of the system in general. Unauthorized changes risk creating a lower quality deliverable as they have not been vetted through the formalized procedures that authorize changes and verify their quality. Poor logging of changes creates problems when changes have to be audited, new personnel need to be trained, or additional changes need to be made. It is crucial for every change to have some reference material, not having enough does not bode well. These risks can cause the purpose of the change to deviate from what was originally planned and lead to uncertainty - something that must be minimized during system changes. Close attention must be paid to the segregation of duties during changes as well, as this establishes a framework for accountability (GTAG 2). System changes can be complex undertakings that demand effective coordination and constant communication. Segregation of duties help with this, they establish clear reporting lines, supervisory roles, and specify domains of accountability. This helps reduce errors and fraud during the process as reasonable oversight over the process is assured. Personnel in supervisory capacities rectify errors and verify that policy and stipulated procedures are followed. A key example of segregation of duties involves separating personnel who design changes from those who test them (GTAG 2), as design teams will be hesitant to report the inadequacies and errors in their work, i. e. , a conflict of interest. All the risk mentioned above can be mitigated by putting effective ITGCs in place and continuously improving them.

Examples of Control Objectives Surrounding System Change

In order to reduce the level of business risk that comes with maintaining IT systems, it is critical to have appropriate change controls in place. Having proper controls in place to prevent unauthorized changes will result in reduced service disruption. In order for system change controls to be effective in an organization, management needs to create and enforce a culture of change management across the organization. This could mean having it be mandatory that service impacting changes go through manager or product/service owners’ approval before implementation. By requiring admin-only rights, the chances of unauthorized personnel making changes to critical IT systems can be greatly reduced. Proper testing policies/procedures such as testing an application in a sandbox environment before launching into production should be in place to prevent service disruptions. Enforcing policies related to frequent system back-ups are another crucial piece of system change.

In the event that a production change fails and impacts a critical business application, an organization must have the ability to revert back to the previous working version of the application. Having automated software that tracks and logs system changes at all times is another important control to have in place. This would give an organization the ability to back-track and identify root-causes of any error that is found within the system. In order for control objectives to be effective across an entire enterprise, management needs to emphasize, enforce, and follow all control objectives that they put in place. A centralized decision-making approach and active communication between different departments within an organization is extremely important to avoid the creation of silos across the enterprise (GTAG 2).

Examples of Controls for ITGC

ITGCs are controls including operating systems, applications, supporting IT infrastructure and databases (Li et al. 180). These controls are classified into two groups. The first group is based on the nature of implementation. Under this group, controls are classified as automated, manual, and partially automated controls (Mirza et al. 46). The second group is based on the nature of the use of the controls. Controls under this group include preventive, detective, and corrective controls. Preventive controls, as the name suggests, are designed to prevent irregularities or errors from occurring. These controls are proactive, and their role is to ensure that departmental objectives are being achieved (Mirza et al. 46). Examples of these controls include segregation of duties that are divided among different people with the aim of reducing the risk of errors or inappropriate actions (Li et al. 182). Responsibilities that are distributed include accounting, approval, and custody. Another example is the security of assets where there is restricted access to inventories, equipment, cash, and other types of assets. Assets are periodically inspected, and the results are compared to the control records to determine if there is any error (Mirza et al. 46). Detective controls are controls that find irregularities or errors after they have already occurred. Examples of detective controls include reconciliation where employees exchange different sets of data among themselves, search and investigate for errors and, when necessary, take corrective actions. Another example is auditing to determine mistakes and reviewing performance (Mirza et al. 46). Corrective controls are controls that help in mitigating the damage once an error has occurred (Mirza et al. 46). Examples of corrective controls include addressing the current problem to obtain the correct processes. Another example is insurance programs that compensate the losses and returning the insured back to original financial position (Li et al. 197). Control Tests PerformedAny unplanned disruption or degradation of service is defined as an incident.

A considerable amount of these incidents can be caused due to changes. Some of these are inadequate documentation, failure to follow work instruction, human error, improper change windows allotted, etc. Reasonable assurance can be provided by following the appropriate change protocols and ensuring that changes are not prone to any risks mentioned above.

For example, testing a change in a lower environment prior to deployment in the live production is a key element that can add to reasonable assurance. Most deficiencies in a change are usually identified during these test runs. Following successful test runs, the change instruction document, change window, potential downtime to products/services should go through a peer review process to ensure the change review process is successful. Once the change has been reviewed, the change management team will review the entire change and seek approvals from relevant management. If some products or services are prone to downtime during this change window, it is imperative to seek approval from the respective product and service owners.

Once the tests are completed and approvals are obtained, pre and post checks would be performed during a dry run, i. e. , ensuring services are running as designed before start and after change implementation. In an event where the change fails or causes a service incident, a well written robust change rollback procedure should be in place, i. e. , reverse the entire change and bring service back up quickly. If a change fails, it would be reviewed by governance, development, operations, and management. A root cause as to why this change failed would be identified by problem management and fed into development who would then rewrite the change which would then go through the change management process. These factors, if tested and implemented as designed, would provide reasonable assurance.