IT Change Management Policy
1. Background and purpose:
This policy has been established to meet Melbourne Racing Club, its subsidiaries, and related entities (“MRC”) strategies, goals and regulatory requirements relating to controlling the changes made to the MRC information and information processing facilities.
This policy establishes the requirements for change management to restrict unauthorised changes to the MRC information and information systems (“IT Systems”) and applies to all users of MRC information resources, including employees, contractors, vendors, service providers, partners, affiliates, and third parties who are authorised to access the MRC network.
The objectives of Change Management in respect of IT Systems are:
- Manage changes in a controlled manner, thus enabling approved changes to be deployed with minimum service disruption;
- Manage a process that makes a considered approach to assessment of risk and business continuity, change impact, resource requirements and change approval. This considered approach is essential to maintain a proper balance between the need for a change against the impact of the change;
- Ensure that standardised methods and procedures are used for efficient and prompt handling of all changes, in order to minimise the impact of change related incidents upon service quality, and consequently to improve the day to day operations of MRC;
- Deliver a process that has high visibility and open channels of communication in order to promote smooth transitions when changes take place.
2. Scope
This policy applies to the MRC IT Systems and any outsourced IT supplier(s). The primary audiences for this policy are the MRC employees and entities responsible for maintaining MRC information assets including but not limited to: affiliates, subsidiaries, outsourcing vendors, third-party service providers, and joint ventures. This policy also applies to data and databases, whenever changes are applied without using applications designated for maintaining data in databases.
This policy covers:
- All IT Changes including additions, deletions and modifications to IT resources regardless of who initiates it;
- MRC IT Infrastructure including, but not limited to, hardware, software, operating systems, data, voice network and applications;
- Environmental facilities supporting MRC IT Infrastructure, including but not limited to, airconditioning, water, heat, electricity, plumbing and alarms;
- Disaster recovery facilities.
3. Policy Statement
All IT changes applied to MRC operational systems shall be managed and executed according to a formal
IT Change Management process. The IT Change Management process will ensure that changes proposed are reviewed, authorised, tested, implemented, and released in a controlled manner; and that the status of each proposed change is monitored. Each change will need careful assessment and be managed to ensure business operations are not disrupted and any implemented change can be rolled back in a timely and auditable way if required.
The IT change process shall be formally defined and documented. A change control process shall be in place to control changes to all MRC, IT systems and their supporting Configuration Items (Cls) such as computing equipment, applications, hardware, software, infrastructure, buildings and formal process documentation.
These processes must be documented to an appropriate level of detail for the teams that will be using them.
3.1. High Level Process Overview
Table 1: Change Management Process Overview
3.2. Raising and Recording Changes
All IT change request submitted using the MRC RFC (Request for Change) form must be logged and allocated an identification number.
An auditable trail, containing relevant information must be maintained at all times. This should include change request documentation, change authorisation and the outcome of the change.
No single person should be able to progress a change to live (production) information systems without the approval of other authorised personnel.
3.3. Configuration Items
Identifying Configuration items (Cls) affected by the changes and updating change records with details of these Cls is mandatory.
3.4. Risk and Impact Management
A risk and impact assessment should be performed for all IT changes. The impact assessment is to include:
- Potential impact on other information resources;
- Potential cost implications;
- Considerations on compliance with legislative requirements and standards.
3.5. Change Categories
The Change Category is a calculated value that is determined by the Risk and Impact of performing the Change. It determines the expected lead-time and authorisation parties for processing the Change.
- Major Change
- Requires an outage to a critical service;
- May carry a level of risk or failure due to the complexity or scale;
- May involve non-approved or non-tolerated products or services;
- May involve modifications to MRC IT security profile;
- Reviewed and authorised by CFO;
- Minor Change
- Are low risk and have low impact, e.g. outside business hours, low usage, etc;
- Usually involve simple execution steps;
- Service disruption, if any, is limited to out of business hours and less than five (5) minutes;
- Reviewed by the Senior Infrastructure & Security Engineer or General Manager of Technology to determine whether it fulfils the Minor Change criteria.
3.6 Change Authority and Lead Time Matrix
Change Authority
Lead Time
Change Category
Major
Minor
Type
Normal
GM of Technology
5 Business Days
Change Manager
1 Business Day
Expedited /
Emergency
CFO
4 Business Hours minimum
NA
Table 2: Change Authority Lead Time Matrix
3.7 Testing
IT changes should be tested in an isolated, controlled and representative environment (where such an environment is feasible) prior to implementation to minimise the effect on the relevant business process, to assess its impact on operations and security and to verify that only intended and approved changes were made
3.8Version Control
Any software change and/or update, and hardware change where a component is added or replaced, shall document, and reference the versions being implemented or retired. This must be done in accordance with MRC’s Patch Management and Back-up Management policies.
3.9 Authorisation and Approval
All IT changes must be endorsed via authorisation prior to commencing the design, development and testing of a change.
All minor change requests must be authorised by either the Senior Infrastructure & Security Engineer for infrastructure related changes or by the Business Platforms Manager for application related changes. All major changes must be authorised by theGeneral Manager of Technology
All IT changes must be approved prior to implementation. Approval of changes should be based on formal acceptance criteria and workflows for each type of change. The criteria and workflows are to be defined in the agreed IT Change Management process and procedures documentation
A change approver is authorised to reserve the right to reject changes on the grounds that documentation standards and requirements have not been met.
3.10. Communicating Changes
All users, service/system owners, and business units significantly affected or impacted by an IT change, must be notified:
- In advance of the change to inform of potential or actual service outage;
- On completion of the change to advise of the service restoration and availability.
3.11 Implementation
Implementation will only be undertaken after appropriate testing and approvals by stakeholders and IT Steering committee (ITSC) where applicable. The implementation is to strictly follow the approved implementation plan. Any other changes / modifications performed outside of the approved implementation plan are not allowed without prior approval from IT Steering committee (ITSC) where applicable and/or the Senior Infrastructure & Security Engineer or Business Platform Manager or the General Manager of Technology (or by a designated authority)
3.12 Rollback
All changes require documented, (and tested where possible) steps for aborting and recovering from unsuccessful changes.
The Rollback is to ensure IT Services and IT Systems can revert back to their previous state prior to the change.
In the event that the planned change and its subsequent back out plan fail to restore service to its original state, an incident must be raised by the implementer following MRC’s Incident Response Policy
3.13. Document, Standards and Requirements
All IT change related documentation must be complete, accurate and contain the latest up to date information about the change.
Policies and procedures that support the affected software, applications or systems the change was made on, must be updated on completion of each change.
3.14. Unauthorised Changes
Change must be classified as an Unauthorised Change when Change Management procedures are bypassed and/or compromised, and a change is implemented into the production IT environment without following agreed IT Change Management process and procedures.
All changes that are deemed unauthorised will be required to be flagged, reported and will require a full post implementation review.
3.15. Emergency Changes
Emergency changes should be carried out to repair a current breakage and / or a change required to prevent a major disruption or potential disaster, but consideration of the consequences needs to be noted prior to the change being pushed through in the event the change could make a situation worse. Emergency changes will still be approved, however said approval will be applied retrospectively in line with the requirements of 3.6.
3.16. Change Monitoring
All changes will be monitored once they have been rolled-out to the production environment. Deviations from design specifications and test results will be documented and escalated to the solution owner for ratification.
3.17.Change Freeze
A Change Freeze is the suppression of all changes to a system.
It may be necessary at times to impose a Change Freeze across the controlled IT environments for the following reasons (but not limited to):
- To manage the resolution of a Major Incident.
- To manage areas and/or times of limited support e.g. holiday seasons.
- To deploy a new product where Changes and issues need to be isolated if possible.
- To manage any high-impact maintenance of the environments.
All requests for a Change Freeze against any MRC IT System, IT Service or its supporting Configuration Items (Cl’s) must receive approval from the General Manager of Technology prior to the Change Freeze being imposed.
Details for the Change Freeze must be communicated to the impacted departments as well as the impacted service providers.
Once the Freeze is over it should be communicated to the relevant departments.
3.18. Maintenance Windows
Maintenance Windows are to be reserved for routine system maintenance, system or application enhancements and problem resolution. Working online during maintenance windows presents the possibility of data loss or system unavailability as a result of potentially scheduled maintenance work.
For all Maintenance Windows, the window (periods of time) must be agreed with the MRC IT Team, Application Owners, Service Owners and System Owners to table maintenance windows, during which each IT System or IT Service may be made unavailable for repair, maintenance and enhancements. The Agreed maintenance window is required to:
- Allow for efficient scheduling of changes into these windows of already agreed times where there is minimal resistance for approval.
- To minimise the number of potential impacts or outages against each IT Service or System.
- To allow for implementation of Standard pre-approved changes, especially if they would alter the state of an IT Service, IT System or their supporting Cls.
The agreed maintenance windows must be officially recorded, communicated and available to any authorised member seeking to make any changes impacting MRC IT Systems or IT Services.
IT Change Management should promote and coordinate change schedules to coincide with the appropriate maintenance windows where possible. IT Change Management should negotiate with Change Owners to coordinate multiple changes, not impacting each other, into the same maintenance window where applicable to reduce down time.
4. Applicability of Other Policies
- MRC Information Security Policy;
- MRC Patch Management policy;
- MRC Back-up Management policy.
5. Key Legislation, Acts & Standards
- ISO/IEC 27002:2023 standards – Information Technology security techniques – Code of practice for information security controls - https://www.iso.org/standard/75652.html;
- Standards Australia. (2016). Information technology – Security techniques – Information security management systems – Overview and vocabulary (ISO/IEC 2700:2016). Sydney: Author
6. Review[1]
This Policy is recommended to be reviewed biennially.
7. Further assistance
For advice and assistance on policy matters please direct your enquiries to MRC’s IT Department via itsupport@mrc.net.au.
8. Glossary of terms/definitions
Term
Definition
Baseline
A snapshot that is used as a reference point. Many snapshots may be taken and recorded over time but only some will be used as baselines.
Change
The addition, modification, or removal of anything that could have an effect on IT services. The scope includes changes to all architectures, applications, software, hardware, processes, tools, metrics, and documentation, as well as changes to IT services and other configuration items.
IT Steering committee
(ITSC)
A group of people that support the assessment, prioritisation, authorisation and scheduling of changes. A change advisory board is made up of representatives from: all areas within the IT service provider; the business; and third parties such as suppliers.
Change Management
Change Management is the process responsible for controlling the lifecycle of all Changes. The primary objective of Change Management is to enable Changes to be made, with minimum disruption to IT Services.
Change Record (CR)
A record containing the details of a change. Each change record documents the lifecycle of a single change. A change record is created for every request for change that is received, even those that are subsequently rejected. Change records should reference the configuration items that are affected by the change. Change records may be stored in the configuration management system, or elsewhere in the service knowledge management system
Change Request
See Request for Change (RFC)
Change Schedule
A document that lists all authorised changes and their planned implementation dates, as well as the estimated dates of longer-term changes.
A change schedule is sometimes called a forward schedule of change (FSC), even though it also contains information about changes that have already been implemented
Change Window
A regular, agreed time when changes or releases may be implemented with minimal impact on services. Change windows are usually documented in service level agreements.
Configuration Item
(Cl)
Any component or other service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle le by service asset and configuration Management. Configuration items are under the control of change management. They typically include IT services, hardware, software, buildings, people and formal documentation such as process documentation and service level agreements.
Configuration
Management
The process responsible for identifying, controlling and tracing all versions of hardware, software, documentation, processes, procedures and all other components of the IT organisation. The goal of Configuration Management is to ensure that only authorised components (referred to as Configuration Items) are used in the ICT environment and that all changes are recorded and tracked.
Classification
The act of assigning a category to something. Classification is used to ensure consistent management and reporting. Configuration items, incidents, problems, changes etc. are usually classified
Emergency IT
Steering committee
(E/CAB)
A subgroup of the change advisory board that makes decisions about emergency changes. Membership may be decided at the time a meeting is called and depends on the nature of the emergency change.
Forward Schedule of Change (FSC)
See Change Schedule
ICT
Is an abbreviation for Information and Communication Technology and is used as a collective term to describe all systems and services associated with computers, digital networks and telecommunications
Impact
A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.
Incident
Any event that causes, or may cause, an interruption or reduction in the quality of that service (i.e. it worked before but is broken and no longer works).
An unplanned interruption to an IT Service or a reduction in the quality of an IT Service. A failure of a configuration item that has not yet impacted a service is also an Incident.
IT Service
A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes. A customer- facing IT service directly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement. Other IT services, called supporting services, are not directly used by the business but are required by the service provider to deliver customer- facing services.
See also Service.
Known Error
A problem that has a documented root cause and a workaround. Known errors are created and managed throughout their lifecycle by problem management. Known errors may also be identified by development or suppliers.
Post Implementation Review (PIR)
A review that occurs after a change is deployed into production environment for a new or updated service. This review evaluates and measures the success and outcome of the change.
Problem
A cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.
Release
A collection of one or more changes that includes new or changed configuration items that are tested and then introduced into the Production environment.
Release
Management
The Release Management function is responsible for controlling the deployment criteria for all changes into an information technology environment. And for the Process for Managing all Releases.
Release Management t is a peer process in conjunction with Change Management.
Once one or more changes are developed, tested, and packaged into releases for deployment, release management is responsible for introducing these changes and managing their release. Release management also contributes to the efficient introduction of changes by combining them into one release and deploying them together. The goal of the release management process is to ensure that all changes are deployed successfully into the production information technology environment in the least disruptive manner.
Request for Change (RFC)
The formal proposal for a change to be made that includes a description of the proposed change, components affected, business need, cost and risk assessment and may be recorded on paper or electronically. Request for Change (RFC) is raised to fix a Known
Error or to enhance/change an application or infrastructure. The term RFC is often misused to mean a Change Record, or the change itself.
Service
A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. The term 'service' is sometimes used as a synonym for core service, IT service or service package.
[1] Review date is recommended only. Should this Policy have not been reviewed or updated by its review date, this Policy shall still remain in force and does not expire.