Mastering IT change management audits: Best practices for success

What is IT change management?

IT change management focuses on how changes to existing IT assets — applications, databases, operating systems, and infrastructure supporting business objectives — are prioritized, approved, tracked, and promoted to production environments in a controlled manner. IT change management encompasses a broader view of IT asset management and involves stakeholders from across the business, IT, and second line of defense functions, such as Internal Controls and Enterprise Security. Such resources often serve on an internal IT Change Advisory Board (CAB), a committee that sets the tone for the overall IT change management process. Meanwhile, while there is overlap, the Software Development Lifecycle (SDLC) process focuses on the development of new software and involves pre-production steps such as vendor due diligence, defining business and technical requirements, functional and technical testing, and a post-implementation hyper care period after the new software is deployed to production. You may find that certain steps of the SDLC process follow the overall IT change management process (for example, the decision to “go-live” with the new software is approved by the CAB, and that access to promote the changes that arise from the hyper care period is appropriately restricted). For purposes of this article, we will focus on IT change management.

Typical IT change management risks and controls

Before developing an audit program, it’s important to understand typical IT change management risks and controls, as this will serve as a baseline for the nature, extent, and timing of internal audit’s design and operating effectiveness testing procedures. In addition, internal audit should partner with business and IT management to understand the organization’s technology risk appetite, governance structures, the use of cloud technologies managed by third parties, and the adoption rate of new technologies designed to promote changes from lower environments to production systems automatically.

IT change management risks

The use of technology is vital in today’s business environment to help achieve business objectives. However, IT change management risks can have serious consequences if not assessed and mitigated appropriately. Several IT change management risks are derived from the acronym “CIA” – confidentiality, integrity, and availability. Risks from a poorly designed IT change management process include service disruption for internal and external customers, data loss or corruption, security breaches, inefficient change prioritization, ineffective testing, and inadequate change control processes.

IT change management controls

According to the Institute of Internal Auditors (IIA), key IT change management controls can be broken down into the following categories.

Preventive controls:

• Sound IT governance practices. An established CAB with representation across the first and second lines of defense sets the tone and formally defines for teams how a change is expected to flow through the change control process. This group designs and implements policies and procedures for risk assessment, prioritization, approval, documentation, testing, scheduling, and post-implementation review requirements. This committee also defines whether businesses can perform configuration changes instead of IT.
• Approval. Establishing and maintaining a matrix of change approvers from the business and IT, along with approval requirements for emergency changes, provides assurance that the change was authorized in accordance with expectations.
• Segregation of duties. This ensures that the change to production is performed by an individual independent from those that are involved with the change (e.g., a change/release manager); and the implementer does not authorize their own changes. This concept applies whether the change is promoted by a human or through automated promotion tools.

Detective controls:

• Monitor key metrics. The CAB and other stakeholders throughout the enterprise can review exception reports to determine if unauthorized changes were made to production systems. Further, dashboard reports that track key metrics of the process, such as the number of emergency changes made to an IT asset, which could be indicative of local IT support teams reacting to “putting out fires”.
• Reviewing SOC reports from third-party vendors. This type of report identifies the complementary user entity controls (CUECs) that the user organization should have to make sure changes produced by the vendor are appropriately documented, tested, and approved by the user organization.

Automation in change management

Automation tools are increasingly used by information technology teams to promote changes to production environments. Manual changes usually require a software developer to “check out” code from a code repository, make the change, and check the code back into the repository. Then, a second “change manager” independent from the change logs on to migrate the updated code to production environments. One key advantage of a manual change process is the ability of management to clearly define and maintain the segregation of duties between the development and change manager functions. However, the process remains contingent on a resource to manually promote the change to production which, if not managed appropriately, could severely slow down or stop the process.

In an automated situation, the software developer makes the change in a code repository. A secondary resource reviews and provides workflow approval in the tool, and the tool then systematically routes the change to the production environment. With automation, the primary advantage is speed. The promotion tool is “always on” and will promote the change to production once the workflow approval is provided. However, the primary risk shifts from the segregation of duties between two job functions to access control points within the tool. Internal audit needs to work with IT personnel to understand how the access control points are managed to prevent unauthorized changes to production environments.

IT change management audit

Now, let’s review the most common objectives of an IT change management audit and how to put “pen to paper” with auditing this process.

What are the objectives of an IT change management audit?

Key objectives of an IT change management audit include evaluating the design of IT governance systems throughout the CAB; whether changes were appropriately authorized, prioritized, scheduled, and documented in accordance with internal standards; and whether access to make changes to production systems are limited to appropriate personnel.

How do you audit IT change management?

Internal audit should partner with IT leadership through frequent formal and informal checkpoints to understand management’s risk appetite, the impact of new technologies, and vendor relationships on the IT change management process. Such checkpoints can include a formal risk assessment document that qualifies and quantifies risk around changes made to IT assets.

Next, determine how frequently IT change management should be audited in accordance with the risk assessment. This process can be audited as part of a broader annual compliance program (e.g., Sarbanes-Oxley) or be included as part of routine operational audits of a business unit.

During engagement planning, consider gaining an understanding of how the business and IT interact to determine accountability for changes made to IT assets used by the business. This could include understanding whether the business is responsible for making changes to end-user computing resources like a SQL query configuration and Microsoft Access database changes. It is also a good idea to understand the roles and responsibilities involved with third-party cloud computing software changes, and who on the team reviews the vendor’s SOC report.

During fieldwork, inquire about IT management to gain an understanding of how changes to IT assets are processed. This includes understanding how changes are identified, justified, approved, documented, scheduled, and promoted to production. If changes are migrated to production manually, a “classic” audit procedure is to inspect an access listing to determine that a resource cannot promote its own change to production. If an automated promotion tool is used, an effective test is to inspect the workflow rules for the approval step, to ensure a secondary resource needs to provide workflow approval and the change does not flow to production until after the change is authorized. Auditors should also inquire about management to understand how emergency changes are handled, along with metrics reviewed by the CAB to determine where potential “hot spots” are with the frequency of changes to a given environment.

Benefits of IT change management audits

IT change management audits can help your organization with proactive risk identification and mitigation, improve IT governance and communication, and help build confidence with overall change management practices. Specifically, these types of audits can help understand whether the organization is poised to maintain the pillars of information for any business – confidentiality, integrity, and availability.