Mar 28, 2024  
DMACC Policies and Procedures 
    
DMACC Policies and Procedures
Add to Portfolio (opens a new window)

IS7065 - Change Management


Procedure

Section: INFORMATION SOLUTIONS PROCEDURES

SubSection: Information Security

Master List Section: Information Solutions

Purpose

A change is defined as any alteration to software, hardware, or other aspect of the data processing environment and its attached networks. The purpose of this procedure is to ensure that all the changes made to any of the DMACC systems are properly prioritized and scheduled, authorized, and tested before implementation.

Scope

This procedure applies to:

  • All changes, upgrades or modifications made to the IT environment. This covers any change to the hardware, software, application, database, and network system
  • All DMACC employees whether directly or indirectly who require access to and responsible for introducing any changes in the system

Change Initiation

Changes to the DMACC IT systems arise from many circumstances, such as:

  • New business requirements
  • Periodic maintenance
  • User requests
  • Hardware and software upgrades
  • Acquisition of new hardware and/ or software
  • Changes or modifications to the IT infrastructure
  • Environmental changes
  • Operations schedule changes
  • Changes in hours of availability
  • Required resolution of an Incident or Problem ticket
  • Unforeseen events

The above list is not all-inclusive. Therefore, if a change is not related to the above list, it should be referred to the head of the specific DMACC IT area for clarification on whether to submit it to the change management process or not.

The change management process begins with raising a change request with the necessary DMACC IT team change requestor. The change requestor could be either the business user or any personnel from DMACC IT team.

Assess & Authorize

The change request shall be assessed to determine the change priority, risk, impact, cost, and benefits of implementing the change. The following business and technical issues must be considered:

  • Obsolescence
  • Compatibility with existing systems
  • Security
  • Demands on existing staff or expertise required
  • Training and hiring requirements
  • Future growth needs and flexibility
  • Impact on systems and network performance
Planning & Scheduling

All approved changes shall be scheduled at a time where the impact to business is at a minimum.

The changes shall be scheduled during the non-business hours to avoid any disruptions to the business. The change window during which the changes must be scheduled are:

The scheduling should also consider the workloads assigned to the identified resources.

Change Testing

Changes to the infrastructure should be implemented after proper testing in the test environment wherever possible.

For changes, where testing in the test environment is possible, care should be taken to build the test environment like the live environment.

Testing environments should be used to assure the functionality, performance, and business acceptance of changes prior to deployment.

Only testing team personnel should have access to the test environment.

The building and testing of changes shall be executed by the relevant technical teams.

In the case of emergency changes, it may not be possible to test the change prior to implementation.

The testing shall be conducted as per a test plan which should consider, at a minimum, the following:

Testing to ensure that the change can be implemented as desired

Testing the roll back procedures

Testing the functionality of the final system

Change Deployment & Closure

The changes shall be deployed into the production environment only after the approval from the IT team lead.

Production environments are used to support the business’s requirement. Access to the production environment at the application level should be limited to personnel authorized to use the production system.

Change Documentation & Reporting

The change process should ensure that whenever changes are implemented, the associated documentation and procedures are updated accordingly.

Each activity performed through the change management process shall be updated in the change ticket as a record for audit trail.

Emergency Changes

Emergency change requests shall be handled to allow for expedited resolution.

Emergency change requests shall be raised because of:

  • A response to a critical incident in case of failures in the systems.
  • A response to a critical incident in case of failures in the core systems, which affects the internal DMACC users
  • Severe degradation of IT service needing immediate action
  • A system/ application/ component not operating normally, and such failure can have a negative security or overall impact on the Group
  • Response to a natural disaster
  • A response to an emergency business need

Emergency change requirement after normal business hours, on the weekend or holidays, should be handled immediately and reported to the Executive Director, Information Solutions.

A completed change request must be submitted through the regular reporting process on the first working day, immediately after the change was made.



Add to Portfolio (opens a new window)