Change Management for Service Organizations: Process, Controls, Audits

What is Change Management?

Change management is a standardized process by which all changes, including application code and infrastructure changes, are introduced into a production IT environment in a controlled and repeatable manner that ensures only authorized changes are being deployed. Example changes include bug fixes, new features, system upgrades, and patching.

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

---

---

What is the Difference Between Change Control & Change Management?

Change control refers to the assessment of the change request to the system and determination of whether the change is a valid change to be made. On the other hand, change management refers to the entire methodical process of managing and tracking changes from the change request to closing the change ticket.

What are Change Management Objectives?

The objective of 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 into 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 other non-financial system objectives to meet service commitments and system requirements.

What are the Steps in the Change Management Process?

The steps in the change management process, from creation of the change ticket for a given change request to closure of the ticket, encompass the process 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 are for illustrative purposes.  Following a standardized process workflow aids in the discipline to treat the change request in a thoughtful manner that reduces negative impact to services and customers.

• Change Request Creation – Change request is made and ticket is initiated.
• Evaluation – Change request is assessed for risk, priority, and impact to customers.
• Authorization – Work on the change is authorized to begin.
• Planning – Planning for the change is documented such as implementation strategy and test plan, etc.
• Peer Review – Code changes are reviewed by a peer for functionality.
• Testing – Manual and 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 a change 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.
• Closure – Upon completion of all change documentation, the change ticket is closed.

 

What are Examples of Change Management Risks?

Common risks to the 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 service commitments and system requirements or other potential system impacts appropriately.
• Identified breaches, incidents, and other system impairments are not considered in the change management life cycle.
• Change does not function as intended or creates unintended consequences.
• 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.
• 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 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 logged.
• Access to make changes into 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 Change Management Controls?

Change management controls will typically utilize a mix of preventative 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.

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 change management controls may include the following:

• Management has established a defined Change Management Policy and Procedure that is reviewed for required updates at least annually.
• The change management process has defined roles and responsibilities for proper segregation of duties.
• Project management tools are used to support the 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 the 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 into the production environment.
• Separate environments exist for development, test, staging, and production.
• Changes are logged to maintain version control that identifies who made the change to production.
• The code repository tool maintains rules that require all changes to be reviewed before merging the change to the code base.
• 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 change management 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 and the log is reviewed to ensure there are no unauthorized changes.
• Code scanning 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 into production.
• Post-implementation reviews are performed to validate that the change functions as intended.

While not all of these controls are required for the change management process, because one size does not fit all, controls need to be tailored to fit each individual service organization’s change management environment.

Change management controls need to be sufficiently designed to adequately achieve the stated change management objective 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. As you can see, change management controls are specific to each organization. It is the combination of the controls unique to the service organization that help to achieve the change management objectives.

For service organizations, complementary user entity controls also must be taken into consideration for the whole system of controls needed to meet the control objective. 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 commitments and system requirements of the service organization.

 

Where Do Auditors Focus?

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

The auditor will likely want to obtain the service organization’s 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 into 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 of the control, application, or performance.
• Inspection of the supporting documentation evidencing the performance of the control.
• Reperformance of the control.

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

Where testing beyond a walk-through 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.

Should a deficiency be identified during the walk-through 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 the other controls in place to meet the 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.

There are two types of deficiencies, (1) design deficiency and (2) operating 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 change management objective, 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. 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 change management controls are poorly executed.

A change management audit is an independent appraisal that provides feedback to management regarding the design and operational effectiveness of the 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 organization’s objectives.

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 audit reports (f. SAS 70 / SSAE 16), and SOC 2 audit reports 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 objectives.

This article was originally published on 1/2/2019 and was updated on 12/1/2021.