³ÉÈË´óƬ

The emergency change process is used when a change needs to be implemented in a compressed timeframe due to the nature of the change. An example of an emergency change is a security patch requiring implementation to prevent a virus outbreak.

An Emergency RFC can be logged for two reasons:

• Required due to a fault to restore a service to users (Break-Fix)
• To prevent a foreseen major impact to a business critical system or service

If an Emergency RFC is required for a Break-Fix scenario, it should be accompanied by either a Priority 1 or 2 incident logged by the Service Desk.

Emergency change process

1. A Information Technology and Digital Services team determines an emergency change is required and logs a Request for Change, making sure to select the type as emergency. The requester is responsible for ensuring that all fields are completed correctly and submits the change for assessment.
2. The Technology Change Management team will assess the quality and accuracy of the information within the RFC and may ask for more information prior to progression.
3. The Technology Change Management team will communicate with all CAB members about the emergency change via email or in a meeting environment. The CAB will be required to review and assess the change.
   • If email approval is sought, all correspondence to the RFC will be visible as a note within the record.
   • If an Emergency CAB meeting is held, approval will be captured by the Change Manager
4. The Technology Change Manager will review the approvals for any CAB concerns and progress the RFC for implementation once all concerns have been alleviated.
5. Once a change has been approved for implementation, the implement change procedure is followed.
6. Upon completion of the ‘Implement Change Procedure’, the Change Management team will conduct a final review. This may require additional information from the implementer and can result in a Post Implementation Review (PIR).

Ìý