Objective This document contains the policy for making changes to the information technology environment. The Change Management Policy has the following objectives: To protect the information technology environment from uncontrolled changes. To maintain a knowledge base of the current environment, including a full document of all changes made. To restrict service disruptions caused by necessary changes; to define low-use hours. To minimize unintended effects during the implementation of necessary changes. This policy applies to any employee, contractor, or consultant of Timex Group B.V. and its subsidiaries who provide information technology development or support. Policy Change control Change control regulates the practices used to modify the application or its environment to ensure appropriate authorization, testing, and successful production implementation of a change. Change management Change management coordinates the application of changes to the environment to ensure no conflicting changes and communicates awareness of changes, typically through a panel or review board process. The Change Management Policy applies to: Anything requiring a restart to either a production server or application service. Upgrades, including software and operating system patches. Compute and storage hardware replacements or other parts. Addition or removal of hardware or software infrastructure Changing access to any of the production servers Rollouts of production applications changes Modification of a production information technology asset The Change Management Policy does not apply to: Changes to a “sandbox” or “test bed” environments. The following constitutes the minimal requirements for change control: Separating duties between the change submitter and change implementer (administrator or application support analyst) to reduce the risk of unauthorized changes. Security over production environments as restricted as possible, with only authorized change implementers having access. All assets impacted by the change must be attached to the request. Retention of documentation (electronic) showing compliance with unit change control procedures and commensurate with the risk and magnitude of the change. Validation of change success, once implemented, by the change requestor. Be initiated with a Freshservice change request ticket with appropriate documentation. Normal changes must be reviewed and approved by the agent group Manager. Be communicated to the impacted business / IT users before the change is executed. Each unit manager/director must follow appropriate change control procedures before approving a change. There are (3) components to change management: (1) Standard Changes, (2) Minor/Major (Normal) Changes, and (3) Emergency Changes. Standard Changes Standard changes, sometimes called routine changes, are pre-authorized changes with little to no risk. They are relatively common occurrences that follow specific guidelines and procedures. Standard changes are often implemented with repeatable steps that seldom require modifications. The Change Advisory Board (CAB) does not review each case of a Standard change but establishes the protocol and oversees the guidelines for enacting Standard changes. Minor/Major (Normal) Changes Minor and Major changes are normal changes, not Emergency or Standard changes. Normal changes are not pre-authorized like Standard changes. Normal changes go through the Change Advisory Board (CAB) approval process for each change. This allows oversight of the changes and enables the CAB to assess whether this Normal change occurs with enough frequency to be given repeatable guidelines, which could convert it into a Standard change. Each Normal change is processed as a Request for Change (RFC), approved or denied by the Change Manager, and then fed to the CAB for review, approval, and scheduling. Normal changes are common but typically require somewhat unique or novel approaches, unlike Standard changes, which can generally be accomplished through step-by-step guides or some basic outlines. Normal changes undergo self-review, where the team analyzes the change within the scope of the assignment and assesses its viability before they push it through to the CAB. The CAB then reviews the proposed change and ensures it meets compliance with all security protocols before approval. These changes must be evaluated, authorized, and scheduled according to a standardized process. They are anticipated and planned, and appropriate standardized change management controls may be devised accordingly. However, Normal Changes are implemented only after receiving formal authorization and approval. Low-risk changes are considered Minor changes, while high-risk changes are considered Major changes. All activities within the change management process controls are practiced for Normal Changes. Emergency Changes These changes typically represent a crisis or an opportunity that must be addressed without undue risk. Therefore, an acceptable level of risk is expected, and specific procedures are followed as a risk mitigation strategy. Specific approvals and authorization are also required before implementing an Emergency Change. Emergency Changes are not thoroughly tested, and appropriate decisions are made as a balanced tradeoff between risk and reward. It follows a change management process flow like Normal Changes but at an accelerated timescale. Successful handling of an Emergency Change determines the stability of the IT services provided to end-users. Therefore, the impact of an Emergency Change should be documented and evaluated for future improvements in the change management process. Emergency changes are brought to the immediate attention of a Change Manager and then sent to the Emergency CAB (ECAB) for further analysis. The ECAB is duty-bound to assess the risk of the proposed Emergency changes and weigh the danger the underlying issue poses to the organization and its services. Emergency Change Advisory Board Members Mark Anthony Caballo Randall Clark Brian Frye Jonathan Isidro Ashok Kumar Vijay Kundu Gaurav Mittal Krishna Mohan Antonio Sandoval Scott Sutfin Jon Vandergrift All emergency changes should have a high-priority incident attached. Change Process Flows Standard Change Process Create a change and select the standard change type. Fill out the change form fields. Select the Originating team and the Implementation team. After submitting the change, the status will change to Pending Implementation and the change will be assigned to the implementation team. The implementation team will receive a notification and the change should be assigned to an agent in the implementation team. The implementation agent will deploy the change and change the status to Pending Review. The ticket will prompt for an implementation note before moving to Pending Review. At this point, the implementation agent may create a task to have the requesting team review the changes if necessary. After review, the implementation agent may change the status to Closed. The agent will be prompted to select a reason for closure. (Change Implemented, Implementation failed, or Cancelled). Normal Change (Major/Minor) Create a change and select the Minor or Major change type. Fill out the change form fields. A Minor change should be “Low” or “Medium” risk. A Major change should be “High” or “Very High” risk. Select the Originating team and the Implementation team. After submitting the change, the status will change to Planning and the change will be assigned to the Change Team for the originating team. For example, if Enterprise Services is the originating team, the change will be assigned to the “Change Team – Enterprise Services”. The change team will receive a notification that a change has been assigned for planning. One of the change team members will now review the change details and they can set to the status to Awaiting Approval to send the change to the CAB or set the status to Open to send the change back to the requestor for modification. After CAB review and the change is presented at the weekly CAB meeting, the CAB will approve the change and the status will be set to Pending Implementation. The change will then be assigned to the Implementation Team selected by the requestor. The implementation team will receive a notification that the change should be assigned to an agent in the implementation team. A note will be added to the change with a link to the ITS Advisory: Planned Outage Notice request which can be filled out and submitted for the Service Desk to send the notification of an outage if necessary. The implementation agent will deploy the change and change the status to Pending Review. The ticket will prompt for an implementation note before moving to Pending Review. At this point the implementation agent may create a task to have the requesting team review the changes if necessary. This step is highly recommended for Major changes. A note will be added to the change with a link to the ITS Advisory: Service Restoration Notice request which can be filled out and submitted for the Service Desk to send the notification of service restoration if necessary. After review, the implementation agent may change the status to Closed. The agent will be prompted to select a reason for closure. (Change Implemented, Implementation Failed, or Cancelled). Emergency Change Create a change and select the Emergency change type. Fill out the change form fields. Select the Originating team and the Implementation team. Associate the incident initiating the emergency change. This is required for emergency changes. After submitting the change, the status will change to Open. Review the change details, associations, attached assets, and if everything is correct, set the status to ECAB Approval. The change will be assigned to the Change Team for the originating team. For example, if Enterprise Services is the originating team, the change will be assigned to the “Change Team – Enterprise Services”. The change team and the ECAB members will receive an approval notification. The ECAB member will now review the change details and approve. Once one of the ECAB members approves the change, the change will move to Pending Implementation. The change will then be assigned to the Implementation Team selected by the requestor. The implementation team will receive a notification that the change should be assigned to an agent in the implementation team. A note will be added to the change with a link to the ITS Advisory: Planned Outage Notice request which can be filled out and submitted for the Service Desk to send the notification of an outage if necessary. The implementation agent will deploy the change and change the status to Pending Review. The ticket will prompt for an implementation note before moving to Pending Review. At this point the implementation agent may create a task to have the requesting team review the changes if necessary. A note will be added to the change with a link to the ITS Advisory: Service Restoration Notice request which can be filled out and submitted for the Service Desk to send the notification of service restoration if necessary. After review, the implementation agent may change the status to Closed. The agent will be prompted to select a reason for closure. (Change Implemented, Implementation Failed, or Cancelled). References Freshservice Problem, Change, and Release Management Process Flow What is ITIL Release Management?: Everything You Need To Know ITIL Change Management: Definition, benefits, and types Document Version Control Version Date Modified by Comments 2.1 2/3/2025 Scott Sutfin Policy and process revision for Freshservice Implementation Document Approvals Name Title Signature Date Scott Sutfin Director, IT Infrastructure Click or tap to enter a date. Vijay Kundu Director, IT Enterprise Systems Click or tap to enter a date. Krishna Mohan Director, IT Supply Chain Services Click or tap to enter a date. David Payne SVP, General Counsel Click or tap to enter a date. Annica Forsberg SVP, CFO Click or tap to enter a date.