System Change Policy

2025.1

Reviewed: 1/21/2025
Updated: 1/21/2025

Purpose and Scope:

1. This information security policy defines how changes to information systems are planned and implemented
2. This policy applies to the entire information security program at the organization (i.e. to all information and communications technology, as well as related documentation).
3. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work for the organization, or who have been granted to the organization's information and communications technology, must comply with this policy.

Background:

1. This policy defines specific requirements to ensure that changes to systems and applications are properly planned, evaluated,approved, communicated, implemented, documented, and reviewed, thereby ensuring the greatest probability of success. Where changes are not successful, this document provides mechanisms for conducting post-implementation review such that future mistakes and errors can be prevented.

Controls and Procedures

System Changes

1. Any changes to the security architecture or customer data handling of a system must be formally requested in writing to the organization's Director of Infrastructure and Technology (DIT), and approved by the DIT and the Vice President of Product and Technology (VPPT).
2. All change requests must be documented.
3. All change requests must be prioritized in terms of benefits, urgency, effort required, and potential impacts to the organization's operations.
4. All implemented changes must be communicated to relevant users.
5. When new systems are to be implemented, all default vendor security configurations must be removed.
6. Any system management tools must be reviewed and provisioned following the same requirements and configurations as existing systems and to existing policies.
7. Change management must be conducted according to the following procedure:
   a. Planning: plan the change, including the implementation design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan.
   b. Evaluation: evaluate the change, including priority level of the service and risk that the proposed change introduces to the system; determine the change type and the specific step-by-step process to implement the change.
   c. Review: review the change plan amongst the VPPT, DIT, Engineering Lead, and, if applicable, Business Unit Manager.
   d. Approval: the VPPT must approve the change plan.
   e. Communication: communicate the change to all users of the system.
   f. Implementation: test change in non-production environment and implement the change.
   g. Documentation: record the change and any post-implementation issues.
   h. Post-change review: conduct a post-implementation review to determine how the change is impacting the organization, either positively or negatively. Discuss and document any lessons learned.
8. Emergency change management must be conducted according to the following procedure:
   a. Evaluation: evaluate the emergency change as thoroughly as time allows to reduce as much risk as possible b. Review: review the change plan amongst the VPIT, DI, Engineering Lead, and, if applicable, Business Unit Manager. c. Approval: the VPIT must approve the change plan. d. Communication: communicate the change to all users of the system. e. Implementation: test change in non-production environment as thoroughly as time allows to reduce as much risk as possible and implement the change as inobtrusively as the situation allows for. f. Documentation: record the change and any post-implementation issues, next steps for addressing new issues. g. Post-change review: conduct a post-implementation review to identify root cause for the emergency change, identify steps which can be implemented to avoid future situations requiring emergency change, and record and document all information.