What is Change Control?
Change control is a standardized process by which all changes are introduced into a production environment in a controlled and repeatable manner that ensures only authorized changes are being deployed.
For service organizations, the change control process is considered an IT general control and 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 are Change Control Objectives?
The objective of change controls 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 entities’ internal control over financial reporting or other non-financial system objectives to meet commitments and system requirements.
What are Examples of Change Control Risks?
Common risks to the change control 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 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.
- Deployment of change is not performed timely or interferes with other scheduled deployments.
- Change control duties are not appropriately segregated.
- Change to address known vulnerabilities is not deployed timely.
- Change fails to meet 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 control management will typically utilize a mix of preventative and detective controls and other control types such as approval, management review, system access, 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 Control Policy and Procedure that is reviewed for required updates at least annually.
- The change management process has defined roles and responsibilities.
- Change Requests based upon identified needs are evaluated, documented, and authorized by the business owner and IT management prior to development.
- 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 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 Control Board approves and schedules the change for deployment in the production environment.
- All changes approved for deployment into the production environment are moved to the staging environment and implemented into production.
- Separate environments exist for development, test, staging, and production.
- Changes are logged by the change control software to maintain version control, to identify who made the change and to implement the change into production.
- Access to the production environment and the change control software is restricted to only authorized personnel.
- Developers do not have access to make changes to the production environment.
- All changes are logged and the log is reviewed to ensure there are no unauthorized changes.
- Emergency changes are approved after-the-fact in a timely manner to ensure appropriateness.
- A back-out plan is developed for changes that can not be tested prior to implementation into production.
While not all of these controls are required for the change control process, because one size does not fit all, controls need to be tailored to fit each individual service organization’s change control environment.
The change controls need to be sufficiently designed to adequately achieve the stated change control objective and the change 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 back-out 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 controls are specific to each organization. It is the combination of the controls unique to the service organization that help to achieve the change control 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 production. This complementary user entity control helps to ensure that the change functions as intended in the user entity environment and helps to satisfy the 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 control objective to ensure controls provide reasonable assurance that changes to existing infrastructure, data, and software are authorized, documented, tested, approved and implemented.
The auditor will want to obtain the service organization’s Change Control Policy and Procedure, 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, confirm 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 performance of the control.
- Reperformance of the control.
The auditor will 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. Normally a test sample of 25 transactions or less will be sufficient 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 control 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 it 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 control objective, training of individuals responsible for the execution of the control may be necessary so that the control may be performed as intended.
There is only one thing that is constant and that is change. Change control management protects the service organization in managing change, either planned or unplanned, and helps to minimize disruption and production outages if change controls are poorly executed.
The change management audit is an independent appraisal function that provides feedback to management regarding the design and operational effectiveness of the change controls in place and helps to identify if any control weaknesses exist. An audit is a key component of the service organization’s overall control environment.
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.
Becky McCarty specializes in SOC 1 and SOC 2 examinations for Linford & Co., LLP. She completed her Master’s degree in Information Systems in 1996, started working with KPMG in 1999, and joined Linford & Co., LLP in 2018. She works closely with clients so that the examinations are performed efficiently and with minimal disruption while ensuring performance in accordance with professional guidance. She enjoys helping clients successfully achieve the requirements for their SOC audit reports based on their applicable trust services criteria.