Effective change management within Voyages Encore Travel Inc.'s ("Encore") assets, environments and resources is important to ensuring that we consistently deliver quality software and services while we also strive to meet various compliance requirements. Introduction of new systems and major changes to existing systems must follow agreed rules and a formal process of documentation, specification, testing, quality control, and managed implementation.
The Policy aims to minimize negative impact to users; increase the value of Information Resources; ensure the confidentiality, integrity, and availability of information; and to establish management direction and high-level objectives for the Change Management process. In addition, this policy guides the implementation of changes to reduce the impact on other tasks/projects as well as to mitigate associated risks such as:
Information being corrupted and/or destroyed.
Adverse impact on other organizational processes.
Computer performance being disrupted and/or degraded.
Productivity losses being incurred.
In the context of this policy, a “change” is the deliberate addition, modification, or removal of approved, supported or baselined software, service, or associated documentation.
This policy applies to all IT systems and applications managed by Encore that store, process or transmit information, including network and computer hardware, software and applications, mobile devices and telecommunication systems. It also applies to all business units operating within Encore’s network environment or utilizing its information resources.
Read, Understand, and Comply with this policy.
Any questions related to this policy can be directed to the Security Compliance Manager.
Enforce compliance with this policy.
Be the change manager for the Zii Platform.
Responsible for overseeing the change throughout the standard development life cycle.
Responsible for approving changes before they are migrated to the Production Environment.
Assess the impact, risks and compliance requirements associated with the changes and make informed decisions regarding their approval.
Approve and enforce compliance with this policy.
Be the change manager for Encore infrastructure.
Responsible for overseeing the change throughout the standard development life cycle.
Responsible for approving changes before they are implemented.
Assess the impact, risks and compliance requirements associated with the changes and make informed decisions regarding their approval.
Manage and review this policy at least annually.
Answer all questions or comments related to this policy.
Ensure this policy is readily available for all employees within the Service Desk.
Changes to information resources are managed and executed according to a formal change control process. The change control process ensures that proposed changes are reviewed, authorized, tested, implemented and released in a controlled manner, with monitoring of the status of each proposed change. To fulfill this policy, the following statements must be adhered to:
Changes are authorized and approved prior to implementation by appropriate individuals depending on the type of change.
The impact of the change on PCI environments must be documented and approved.
Changes made in development environments must follow the Software Development Lifecycle Policy.
Security and privacy concerns are an element of the change management process.
For example, any baseline settings should not be altered unless there is a clear security or privacy reason for doing so.
Upon completion of a significant change, Encore must then reconfirm all applicable PCI DSS requirements to be in place on all new or changed systems.
For all change requests related to the Encore Infrastructure, a ticket must be sent to the Service Desk (servicedesk.encore.ca).
For all change requests related to the Zii Platform, a ticket must be sent to the DevOps ticketing system.
All approvals, scheduling, comments and implementation details shall be recorded as part of the ticket.
The change management processes at Encore will generally adhere to the following steps:
Planning: Plan and assess the change, including implementation design, scheduling, dependencies, and the risks associated with the change.
Communication: Communicate the change to relevant stakeholders.
Testing: Various forms of testing are performed by the appropriate users, depending on the scenario: User acceptance testing, code review, security testing, and/or infrastructure testing such as utilizing pilot groups.
Authorization: Only authorized changes are deployed.
Implementation: Appropriate implementation or deployment of the change.
Documentation: Maintain documentation for the change that captures planning, testing, authorization, implementation, and contingency procedures for each change. Ensure that operating documents or user procedures are updated as necessary.
Post-change review: Review the change with an eye to future improvements. (For the business owner to review)
Changes will be categorized and appropriate controls shall be applied to each category of change.
Type | Description | Process |
|---|---|---|
Vendor Initiated Change | A change proposed by a vendor to apply patches, service packs, and other updates. | All elements of change management to be followed, with necessary steps documented. Code reviews, where appropriate, are performed. Automated or manual testing is completed. Successful code review paired with completed testing can be used as approval for the change to be deployed. Deployment is documented. Change is verified in the production environment. Stakeholders are notified both before and after changes have been made. |
Emergency Change | A change that if not implemented immediately would leave the company open to significant risk or application downtime. Approvals must be obtained for such changes through discussion with the relevant System Owner and the IT Department. Retrospective assessments and formal approvals are performed for emergency changes. | Testing and peer review may not necessarily come prior to implementation. Stakeholders are kept informed of change status and other affected parties are notified as necessary when the changes are complete and available in production environments. Emergency changes must be approved within 48 hours of the implementation by the CTO (for Zii Platform) or the Director of IT (for Encore Infrastructure). |
HotFix | A significant or urgent change to fix a customer facing workflow feature, blocking error or unexpected result that affects a class of customer. These changes cannot wait for the next release and if not implemented soon would have a significant negative impact to a customer. | All elements of change management required to be documented (testing, code review, approval to migrate, etc). Code reviews, where appropriate, are performed. Automated or manual testing is completed. Explicit approval is granted from an authorized party. Deployment is documented, and stability of affected systems is monitored after release. Change is verified in the production environment. Users are notified when live. |
Routine Change / Patching | A medium to high change to critical services, with less predictable outcomes (having more than one code dependency), and/or is a change that is not regularly made during the course of business. Generally associated with a change to underlying code and captured in a Build ID number. These changes, such as applying security patches, are already pre-approved by IT Management, and therefore, they can be executed by creating a ticket without following the Change Management approval workflow. | All elements of change management required to be documented (testing, code review, approval to migrate, etc). Code reviews, where appropriate, are performed. Automated or manual testing is conducted. Successful code review paired with completed testing can be used as approval for the change to be deployed. Deployment is documented. Change is verified in the production environment. Users are notified when live. |
Minor Change | A relatively low-risk change with well-understood outcomes (impacting isolated code components) that is regularly made during the course of business. May occur multiple times during the day (ex: minor text changes, images, styling, appending a table, adding an index, updating a query). Rollback impacts are minor or non-existent. | All elements of change management required to be documented (testing, code review, approval to migrate, etc.). Code review is performed by a knowledgeable individual other than the person requesting the change. Code review implies approval for the change to be deployed. Tech Team communicates change out to the affected stakeholders. |
All changes, both scheduled and unscheduled, are documented, classified and tracked based on their impact level:
High impact: affects more than 5% individuals.
Medium impact: affects between 1% and 5% of individuals.
Low impact: affects less than 1% of individuals.
IT Management and/or the System Owner may deny a scheduled or unscheduled change for reasons including, but not limited to:
Inadequate change planning or unit testing.
Lack of stakeholder acceptance (where applicable).
System integration or interoperability concerns.
Missing or deficient roll-back plans.
Security implications and risks.
Timing of the change negatively impacting key business processes.
Timeframes not aligning with resource scheduling (e.g., late-night, weekends, holidays or special events).
Any exceptions or deviations to Change Management must be approved by the CTO (for the Zii Platform), or the Director of IT (for Encore Infrastructure). The approval must be based on a thorough review of the risks, impact and mitigation measures associated with the proposed exception.
Documentation of approved exceptions is maintained, including the rationale for granting the exception, the duration of the exception and any additional controls or safeguards implemented to mitigate the associated risks.
A Post Implementation Review is conducted to evaluate whether the desired result has been achieved. In the event that a change does not perform as expected or causes issues in the Production Environment, the attendees of the change meeting must determine if the change should be rolled-back and the Production Environment returned to its prior stable state.
This policy is subject to management review processes: document development, revision, management approval, communication, publication, acknowledgement, and annual review.
A change-detection mechanism is deployed to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files or content files and configured to perform critical file comparisons at least weekly. Examples of files that should be monitored:
System executables.
Application executables.
Configuration and parameter files.
Centrally stored, historical or archived, log and audit files.
Additional critical files determined by Encore.
Failure to comply may result in disciplinary actions up to and including termination of employment for employees, or termination of contracts for third parties.
“Business Owner” – also known as the Subject Matter Expert (SME), means the individual who provides the knowledge and expertise in a specific subject, business area, or technical area for a project/program.
“Cardholder Data Environment” (CDE) – means a computer system or networked group of IT systems that processes, stores and/or transmits cardholder data or sensitive payment authentication data. A CDE also includes any component that directly connects to or supports this network.
“Common Vulnerability Scoring System” (CVSS) – means a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat.
“Customer” – means a person, or corporate entity, who purchases or receives products or services from Encore.
“Employee” – means all salaried and hourly paid Employees including the Steering Committee, Contractors, Consultants, Temporaries, Interns, Agents and other workers at Encore, including all personnel affiliated with third parties. Can be referred to by the pronoun ‘their’, ‘they’ or ‘them’.
“Interoperability” – means the a characteristic of a product or system to work with other products or systems.
“IT Management” – for the purposes of this Policy, means the Chief Technology Officer; and Head of Data, Security and Technology.
“Non-Production Environment” – means an environment where the main purpose is to provide a real scenario (similar to Production) where developers can test applications and mitigate the risk of deploying them to Production while keeping features that can assist developers with debugging.
“Payment Card Industry Data Security Standard” (PCI DSS) – means an information security standard used to handle credit cards from major card brands. The standard is administered by the Payment Card Industry Security Standards Council, and its use is mandated by the card brands. Companies, such as Encore, who accept credit cards as a method of payment strive to comply with these standards.
“Personally Identifiable Information” (PII) – means information that, when used alone or with other relevant data, can identify an individual.
“Primary Account Number” (PAN) – means the unique payment card number that identifies the issuer and the cardholder account.
“Production Environment” – means a real-time setting where the latest versions of software, products, or updates are pushed into live, usable operation for the intended end users.
“Resource Scheduling” – means the process of identifying when project resources are needed and allocating them based on factors such as capacity planning or resource availability. The main purpose of resource scheduling is to guarantee that there's no over or under-allocation of resources at any point of the project.
“Risk Assessment” – means the identification of hazards that could negatively impact an organization's ability to conduct business.
“Roll-Back Plan” – means a plan that allows IT to get back to an exact state (of a Production Environment) that was developed before this version was created.
“Steering Committee” – means the Chief Executive Officer; Chief Technology Officer; Head of Data, Security and Technology; Head of Human Resources; Head of Product; Head of Commercial Strategy; Head of Operations and Technology; and Financial Controller.
“Service Outage” – means a period when a service or an application is not available or when equipment is not operational for various reasons.
“Their”, “They” or “Them” – means the person or entity previously referred to.