IT Change Management for Service Organizations: Process, Risks, Controls, Audits

What is IT Change Management?

IT change management is a standardized end-to-end process that enables changes, including application, infrastructure, and configuration changes, to be deployed to a production IT environment in a controlled and consistently repeatable manner. IT change management provides the mechanism or workflow that makes sure only authorized changes are made to production. Example IT changes include bug fixes, new features, enhancements, system upgrades, configuration changes, and patching.

For service organizations, the IT change management process is a part of their IT general controls. The service organization’s IT change management controls will be reviewed as part of the control objectives for SOC 1 reports and as part of the common criteria for SOC 2 reports as required.

---

---

What is the Difference Between Change Control & IT Change Management?

Change control is a component of IT change management and refers to the assessment of the change request to the system and the determination of whether the change is a valid change to be made that is necessary or enhances the system in some way and should move forward. On the other hand, IT change management refers to the entire methodical end-to-end process of managing and tracking changes from the change request to closing the change ticket.

What is the Goal of IT Change Management?

The goal of IT change management is to ensure that all changes to software applications, database systems, and associated infrastructure assets are properly authorized, documented, tested, approved, and implemented in the production environment. This helps to achieve complete, accurate, and timely processing and reporting of transactions and balances relevant to the user entity’s internal control over financial reporting or to meet the service organization’s service commitments and system requirements to its users.

 

What Are the Steps in the IT Change Management Process?

The steps in the IT change management process, from creation of the change ticket for a given change request to closure of the ticket, encompass the IT change management process flow from beginning to end. The steps in the process noted below may not all be necessary if the change is an emergency change or if the change is an infrastructure or configuration change and is for illustrative purposes only.  Following a standardized process workflow aids in the discipline of treating the change request in a thoughtful manner that reduces the risk of business disruption and negative impact on services and users.

• Change Request – Change request is made, change ticket is initiated, and change is thoroughly documented. The change request could come from internal or external stakeholders.
• Evaluation – Change request is assessed for risk, priority, and impact on users.
• Authorization – Work on the change is authorized to begin by management or the change advisory board. In some cases, the change request could be rejected or deferred. Changes are assigned to an engineer and to a sprint and/or release.
• Planning – Planning for the change is documented such as requirements, implementation strategy, test plan, etc.
• Peer Review – Code changes are reviewed and approved by a peer for design and functionality.
• Testing – Manual and/or automated tests are performed to validate change functions as designed or if not feasible, a rollback plan is documented.
• Approval for Deployment – Final approval is granted to deploy changes to production.
• Implementation – Change is deployed to the production environment.
• Post-implementation – A post-implementation review is performed to validate the change functions in production as expected.
• Communication – Communication about the change is given to impacted internal and external stakeholders. Release notes are documented and shared.
• Closure – Upon completion of all change documentation, the change ticket is closed.

 

What are the Risks in IT Change Management?

Common risks to the IT change management process for software applications, database systems, and associated infrastructure assets include the following:

• Change is not authorized prior to work commencing on the requested change or development.
• Change is not tracked and/or appropriately documented through its life cycle.
• Change specifications do not meet management’s needs or expectations.
• Change does not address objectives, service commitments, system requirements, or other potential system impacts appropriately.
• Identified breaches, incidents, and other system impairments are not considered in the IT change management life cycle.
• Change does not function as intended or creates unintended consequences, such as security vulnerabilities.
• Unauthorized change is deployed into production.
• Change, including configuration changes, is not properly approved.
• Authorized configuration change is not entered accurately.
• Unit, integration, or regression testing is not sufficient to detect issues prior to deployment of the change.
• Deployment of change is not performed timely or interferes with other scheduled deployments.
• IT change management duties are not appropriately segregated.
• Change introduces malicious code or new vulnerabilities that go undetected.
• Change to address known vulnerabilities is not deployed in a timely manner.
• Change fails to meet objectives, service commitments, and system requirements.
• Emergency changes are not properly approved or appropriate.
• Unauthorized changes are not detected.
• Separate non-production and production environments do not exist.
• Change implemented into production is not documented or logged.
• Access to make changes to production is not appropriately restricted.
• Change cannot be traced to the individual who made the change.
• Version control is not appropriately maintained.

 

What are Examples of IT Change Management Controls?

IT change management controls will typically utilize a mix of preventative controls and detective controls and other control types such as approval, peer review, manual and automated testing, system access, segregation of duties, exception reporting, and/or reconciliation, etc., to mitigate the aforementioned risks. The sample controls noted below encompass some IT change management best practices for consideration.

It is important to understand that controls only provide reasonable assurance that stated control objectives will be achieved. Controls generally do not provide absolute assurance because doing so would be cost-prohibitive in most cases.

Some examples of IT change management controls include the following:

• Management has established a defined IT change management policy and procedure that is reviewed for required updates at least annually.
• The IT change management process has defined roles and responsibilities for proper segregation of duties.
• IT change management tools are used to support the IT change management process including a ticketing system, a code repository tool for version control, and testing tools.
• Change requests based upon identified needs are evaluated, documented, and authorized by the business owner and IT management prior to commencing development of the bug fix or new feature, etc.
• Test plans and test data are created and used in system and regression testing.
• Change is reviewed, tested, and approved for intended functionality and specifications by a peer programmer or an independent IT quality assurance team member. Issues identified are returned to the developer for re-work.
• Change is tested and accepted by the users ensuring the change functions as intended and the risk of unintended consequences is minimized. Issues identified are returned to the developer for re-work.
• Upon testing approval, the change advisory board (CAB) approves and schedules the change for deployment in the production environment.
• Management approves change prior to deployment to the production environment.
• All changes are approved prior to deployment to the production environment.
• Separate environments exist for development, testing, staging, and production.
• Changes are logged to maintain version control that identifies who made the change to production.
• The code repository tool maintains branch protection rules that require all changes to be reviewed before merging the change to the main branch.
• Auto-notifications are generated when a change has been merged to the code base to prevent changes from occurring that go undetected.
• Access to the production environment and the code repository software is restricted to only authorized personnel.
• Developers do not have access to make changes directly to the production environment without appropriate oversight.
• All changes are logged for an audit trail and the change log is reviewed to ensure there are no unauthorized changes.
• Code scanning analysis tools are utilized on each release candidate to identify and remediate any software vulnerabilities prior to the release being deployed to production.
• Emergency changes are approved after the fact in a timely manner to ensure appropriateness.
• A rollback plan is documented for changes that can not be tested prior to implementation to production.
• Post-implementation reviews are performed to validate that the change functions as intended in production.

How Controls Are Tailored to Meet IT Change Management Objectives

Not all of these controls are required for the IT change management process, because one size does not fit all. Controls need to be tailored to fit each individual service organization’s IT change management framework and workflow to make sure changes are made in a controlled systematic and structured manner so that no unauthorized changes are deployed to production.

IT change management controls need to be sufficiently designed to adequately achieve the stated IT change management objectives and the controls need to be operating effectively. For example, perhaps a service organization does not have a separate development and test environment, however, they have a separate non-production and production environment. Some changes may not be feasible to test; however, the organization ensures a rollback plan has been documented for these types of changes.

A developer may have access to the production environment to deploy changes, however, the service organization requires an independent peer developer to review, test, and approve all changes prior to deployment of the change. IT change management controls are specific to each organization. It is the combination of the controls unique to the service organization that helps to achieve IT change management objectives and support its service commitments and system requirements.

For service organizations, complementary user entity controls also must be taken into consideration for the system of internal controls needed to meet the control objectives, service commitments, and system requirements. For example, if the user entity requested the change to customize their software features, a complementary user entity control would be for the user entity to test, accept, and approve the change prior to deployment of the change into the user entity production environment. This complementary user entity control helps to ensure that the change functions as intended in the user entity’s production environment and helps to achieve the service organization’s service commitments and system requirements.

 

Where Do Auditors Focus?

An audit of the IT change management process focuses on the design and operational effectiveness of the controls to meet the IT change management objective to determine whether controls provide reasonable assurance that changes to existing production infrastructure, data, or software are authorized, documented, tested, approved, and implemented.

The auditor will likely want to obtain the service organization’s IT change management policy and procedures, understand how a change is authorized prior to work on the change commencing, inspect the change documentation for the life cycle of the change, validate that testing occurred for the change prior to deployment, determine approval of the change for deployment to production occurred, and inspect evidence that the change was implemented by an authorized individual.

The nature of the tests performed by the auditor include the following:

• Inquiry of knowledgeable and competent personnel and corroboration with management.
• Observation of the existence, application, or performance of the control.
• Inspection of the supporting documentation evidencing the performance of the control.
• Reperformance of the control.

An auditor will walk through the design of the controls that are in place to ensure changes to production infrastructure, data, and software are authorized, documented, tested, approved, and implemented. The auditor judgmentally evaluates the design to determine if the controls satisfactorily address the service organization’s identified risks.

Where testing beyond a walkthrough is required to assess the operational effectiveness of the control, the total population of transactions executed by the control will be needed from the service organization in order to determine the population needed for testing. A sample of transactions will be tested to determine if the control is operating effectively in a consistent manner.

How Are IT Change Management Deficiencies Handled?

Should a deficiency be identified during the walkthrough of the control design or the testing of the control for operational effectiveness, it will need to be assessed for significance and evaluated in conjunction with other controls in place to meet the IT change management objectives. A single deficiency does not necessarily mean that the objective fails to be met. It depends upon several factors that need to be evaluated together.

There are two types of deficiencies:

1. Design deficiency
2. Operational effectiveness deficiency

A design deficiency is simply when a control necessary to meet the control objective is missing or not suitably designed so that even if the control operated effectively, it would not achieve the objective.

An operational effectiveness deficiency is when a control is designed appropriately but is not executed effectively to meet the objective. If a control is not operating effectively even though it is designed appropriately to meet the IT change management objectives, training of individuals responsible for the execution of the control may be necessary, additional management review may be imposed, or automated system controls may be configured so that the control may be performed as intended.

Summary

There is only one thing that is constant and that is change. IT system changes are inevitable and constantly occurring for continuous improvements to be realized. IT change management controls protect the service organization in managing system changes, either planned or unplanned, and help to minimize disruption, system issues, and production outages if IT change management controls are poorly executed.

An IT change management audit is an independent appraisal that provides feedback to management regarding the design and operational effectiveness of the IT change management controls in place and helps to identify if any control design or operational weaknesses exist. The performance of an audit is a key component of the service organization’s overall internal control environment in that an audit helps an organization monitor its internal controls to determine that controls are operating as per management expectations to meet the service organization’s goals.

If you are seeking a SOC report or if you would like more information, please contact us at Linford & Company. We have a team of IT audit professionals that complete Type I and Type II, SOC 1 audits (f. SAS 70 / SSAE 16), and SOC 2 audits on behalf of service organizations all over the world. Our team is available to answer any questions you may have to effectively address your audit needs and assist you in achieving your goals.

This article was originally published on 1/2/2019 and was updated on 10/18/2023.