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.