06. Healthsafe Change Management Policy










CHANGE MANAGEMENT POLICY



Document Identification 

HSNZ/POL/06

Document Name

Change Management Policy

Master Copy

CISO

Version Number

1.3

Date Of Release 

15 Aug 2023

Prepared By

Eparama Tuibenau

CISO

Approved by

Kevin McAfee

Managing Director



 

 


VERSION HISTORY


Sl No

Version No.

Prepared by

Approved by

Description of Version

Date

Reason for Version Change

From

To

1

1.0

-

CISO

MD

First Release

14 Apr 2020 

No changes made

1

1.0

1.1

CISO

MD

Updated

21 Jun 2021 

Modifications due to changes in HealthSafe

1

1.1

1.2

CISO

MD

Reviewed

27 Jul 2022 

Annual review

1

1.2

1.3

CISO

MD

Reviewed

15 Aug 2023

Annual review


DOCUMENT STATUS


Date

Document Status

14 Apr 2020

Modified

21 Jun 2021

Reviewed

27 Jul 2022

Reviewed

15 Aug 2023

Current


Table of Contents

1 Purpose


2 Scope


3 Input


4 Output


5 Interacting Process


6 Abbreviations, Acronyms and Definitions


7 Procedure


8 Monitoring the Process


9 Records








1 PURPOSE


The purpose of this procedure is to provide a tool to implement changes to supported information technology in a way that minimises risk and impact to HealthSafe NZ.


For the purposes of this procedure, a change is defined as anything that transforms, alters, or modifies the operating environment or standard operating procedures that have potential to affect the stability and reliability of supported information technology infrastructure and affects the business process of HealthSafe NZ. 


This document provides a baseline for the change management procedures for the three major change categories, Planned Major Changes; Maintenance and Minor Updates; and Emergencies and Unplanned Outages. 


2 SCOPE


These procedures are applicable for the changes in IT supported systems (hardware, software, applications, and network environment) and processes upon which any functional unit of HealthSafe relies in order to perform its normal business activities. Examples of these systems include, but are not limited to: Hardware, Application Software, Database, Email, Servers, Employee’s Laptop Computer, Allocation of IP addresses, Updates to company 0800 number, Domain DNS changes and others.  


3 INPUT


Change Management


4 OUTPUT


Change Approval


5 INTERACTING PROCESS


Department Head, Finance, IT & CISO


6 ABBREVIATIONS, ACRONYMS AND DEFINITIONS


Abbreviation

Description

Admin.

Administration

AE

Administrative Executive

TL

Team Lead

CISO

Chief Information Security Officer




7 PROCEDURE


Planned Major Changes  


Examples of this type of change are: 


  • Change that results in business interruption during regular business hours   
  • Change that results in business or operational practice change     
  • Changes in any system that affect disaster recovery or business continuity 
  • Introduction or discontinuance of a new information technology or service

Change management Procedure:  


  1. Change request items are reviewed by various team members and tabled at the quarterly planning session as a candidate to be planned into the coming quarter. 
  2. Elements to consider before a change request is to become a candidate task for the following QPS are: 
    • description of the change; at least one or two sentences with supporting screenshots if required,  
    • a preferred date and time, that the change is scheduled to be implemented if inline with a client/project requirement
    • the main contact; others should contact this person on questions/clarification, issues responsible management contact
    • risk and its impact of change analysed by the TL
    • roll back plan suggested by the TL
    • approval remarks by the CISO or key stakeholders
    • task is assigned to an individual
    • implementation compliance remarks and communication are to be logged by the relevant employee in JIRA comments section with activity logs of the particular change
  3. CISO/CEO/GM may choose to approve or reject the change or request additional information. If the change is rejected or additional information is needed, additional information is acquired prior to the task being logged in JIRA.
  4. TL verifies the schedule/re-schedules for the implementation and assigns the task to the respective IT Technical staff
  5. Changes that impact all of HealthSafe NZ will be communicated through emails or a product showcase to the respective members or by a selected member by CISO
  6. The assigned IT Technical staff implements the change
  7. After the change is implemented, the change is submitted to a QA staff to assess the change and logged accordingly
  8. QA verifies the changes and sends the confirmation to the respective persons
  9.  The completed change will be logged in JIRA with related historic logs and comments

Maintenance and Minor Updates  


Examples of these types of changes are: 


  • Application-based security patches
  • Changes on application software
  • Operating system patches (critical, hot-fixes)  
  • Regularly scheduled maintenance changes that are not likely to cause a service outage 

Emergencies and Unplanned Outages


Examples of this type of changes are: 


  • Lack of services in our data centre
  • A severe degradation of service needing immediate action 
  • A system/application/component failure causing a negative impact on business operations
  • A response to a natural disaster 
  • A response to an emergency business need 
  • System outage where no users can continue with business operation

Emergency and Unplanned Change Procedures:


  1. Emergencies are to be resolved as quickly as possible 
  2. As soon as possible, the employee who notices the incident will report to an TL or LT or directly to the CISO
  3. The employee will notify the impact to the CISO if not reported directly
  4. The TL (in consultation with CISO) authorises for the changes and all HealthSafe NZ employees will be notified if impacted
  5. The TL will send an email or Slack message to every relevant internal staff about the changes and resolution
  6. The JIRA ticket will log the communication and serve as a record of the issue and its resolution in JIRA
  7. This communication should provide sufficient details, cause and resolution in JIRA
  8. It should also indicate whether additional steps need to be taken to minimise re-occurrence of the emergency




8 MONITORING THE PROCESS


  • All the data is entered in JIRA
  • Necessary request forms are approved by the concerned person

9 RECORDS


  • JIRA tickets/tasks