Change Management Policy and Procedure

1. Purpose

This document makes sure that every change to the Organisation's production environment is justified, assessed for security and business impact, authorised by the right person, tested, reversible, carried out in a controlled way and reviewed afterwards. The aim is to deliver change quickly where it is routine and carefully where it is risky, and to avoid unplanned outages and security weaknesses caused by uncontrolled change.

2. Scope

The policy and procedure apply to all changes to information processing facilities and services, whether made by staff, contractors or suppliers, and whether on premises, in the cloud or through a service provider.

• In scope: servers, endpoints in bulk, network and security devices, operating systems, databases, middleware, applications and their configuration, infrastructure as code, identity and access configuration, cloud accounts and services, scheduled jobs, data fixes in production, firewall rules, certificates, backup and monitoring configuration, and the retirement of any of these.
• In scope: changes to documents that define operation of controls, such as the runbook for a critical service.
• Out of scope: changes to a development or test environment that is isolated from production and holds no live data; individual user requests such as a password reset, handled under the User Access Management Procedure; and organisational change such as restructuring, handled by management.

3. Terms and Definitions

4. Roles and Responsibilities

5. Change Management Policy

5.1 Principles

1. No change may be made to a production system without an approved RFC, except a standard change from the approved list or an emergency change handled under the emergency route and recorded afterwards.
2. Production, test and development must be separated, and changes must be tested in a representative non-production environment before being released to production.
3. Nobody may approve their own change. The person who implements a change must not be the sole approver and, for high-risk changes, the reviewer must be independent of the change owner.
4. Every change must have a rollback plan that has been reviewed, and, for medium and high risk, rehearsed or reasoned through with evidence.
5. Every change must be recorded in the change register with its outcome, so that incidents can be traced to changes and changes can be traced to incidents and problems.
6. Security impact is assessed for every change. Changes that alter authentication, network boundaries, encryption, logging, data stores or externally exposed services need review by the information security manager.
7. Changes that touch personal data or move data to a new location or supplier need a review by the data protection officer, and the Data Protection and Privacy Procedure applies.

5.2 Change windows and freezes

• Normal changes are carried out in the agreed change windows: [Tuesday and Thursday, 22:00 to 02:00 local time] for production and by agreement for customer-impacting changes.
• Change freezes are announced by the change manager at least [10 working days] in advance. During a freeze only emergency changes are allowed, and each one needs ECAB approval.
• No high-risk change may be scheduled on a Friday, before a public holiday or when key staff for the service are absent, unless the CAB records why the date is justified.

5.3 Change risk matrix

The change manager scores risk using impact and likelihood. The result sets the approval authority and the amount of testing.

5.4 Approval authority

6. Change Management Procedure

6.1 Raise a request for change

1. Complete the formThe requester completes the change request form (Annexure A) with title, reason, description, systems affected, desired date, benefits, and what happens if the change is not made. Input: need or ticket. Output: RFC. Target: same day as the need is identified.
2. Attach supporting materialAttach design, vendor advisory, vulnerability reference, ticket numbers, or test results. Tag the RFC to any related incident or problem.
3. SubmitSubmit through [the ticketing tool], which allocates the unique RFC number and notifies the change manager.

6.2 Verification of the request

1. Check completenessThe change manager checks within [1 working day] that the form is complete, the requester is authorised, and the change does not duplicate another RFC. Incomplete RFCs go back with a reason.
2. Check authority and fitThe change manager confirms that the change fits the service, architecture and security standards, and that a business owner supports it.
3. LogLog the RFC in the change register with status Verified, requester, owner, date and linked records.

6.3 Impact assessment

1. Identify what is affectedThe change owner lists the systems, data, users, suppliers and customers that the change touches, using the asset register and configuration records.
2. Assess security impactThe information security manager reviews the change for effect on confidentiality, integrity, availability, access, logging and privacy, and records findings and conditions.
3. Assess resource and timing impactEstimate effort, skills, outage time, dependency on other changes, and conflicts with the change calendar or freezes.
4. Record the assessmentRecord the assessed impact and likelihood in the RFC. Target: within [3 working days] for normal changes.

• Questions to answer: Can the service run without this change? Which services depend on the system? What happens to data if the change stops halfway? Who needs to be told? Does it change the Statement of Applicability or the risk register?

6.4 Categorisation of the change

1. Choose the typeThe change manager classifies the RFC as standard, normal or emergency, using the definitions in this document.
2. Set the risk levelApply the change risk matrix and record low, medium or high.
3. RouteStandard changes go straight to scheduling. Low and medium normal changes go to the change manager. High risk changes are put on the next CAB agenda.

6.5 Rollback plan

1. Write the planThe change owner documents the exact steps to restore the previous state, the point after which rollback is no longer possible, the time needed to roll back and who decides to roll back.
2. Prepare the meansTake a backup or snapshot, save the old configuration, keep the previous release available, and make sure data changes can be reversed or restored.
3. Set a triggerState the failure conditions that start the rollback, for example verification fails, error rate above [2%], or the window ends before completion.
4. ValidateThe technical reviewer confirms the plan is feasible. For high-risk changes the rollback is rehearsed in the test environment, and the result attached.

6.6 Rejection or return of an RFC

• The change manager or CAB may reject or return an RFC that is incomplete, unsafe, untested, in conflict with a freeze, or without business support. The decision, the reason and the person who decided are recorded in the RFC within [1 working day].
• The requester is notified and may resubmit with the issues resolved. A rejected RFC is closed; it is not edited and reused, so the history is kept.
• A rejection may be escalated to the Head of IT Operations within [5 working days], whose decision is final.

6.7 Submit the change for approval

1. Complete the packageThe change owner attaches the plan, test evidence, security review, rollback plan, communication plan, window and resource booking.
2. SubmitThe change manager checks the package against the approval table and sends it to the right approver or places it on the CAB agenda. CAB papers go out at least [2 working days] before the meeting.

6.8 Approval of the change

1. ReviewApprovers review the package. CAB meets [weekly] and records attendance, questions and decisions in the minutes (Annexure C).
2. DecideThe outcomes are approved, approved with conditions, deferred, or rejected. Conditions are written into the RFC.
3. ConfirmThe change manager updates the register and the change calendar, and informs the requester and owner within [1 working day].

• Quorum for CAB: the change manager, one representative of IT Operations, the information security manager and the relevant system owner.
• Where an approver is absent, a named delegate may act. Delegations are recorded and renewed [yearly].

6.9 Prioritisation of the change

The change manager sets priority using the urgency stated by the requester and the risk matrix. When two changes conflict, the higher priority goes first; if equal, the change with the lower risk goes first.

6.10 Types of change: normal, emergency and standard

6.10.1 Normal change

Follows every step in this procedure. It is scheduled in a standard change window and reviewed after implementation.

6.10.2 Standard change

• A standard change template must define the trigger, the exact steps, the systems it may touch, the evidence to keep, a risk rating of low and the owner. The Head of IT Operations approves each template and reviews all templates every [6 months].
• Examples: adding a user to a group under an approved request, renewing a certificate with the same key policy, installing a monthly operating system update that has passed the patch test group, adding a firewall rule from a pre-approved catalogue.
• A standard change is logged, either automatically or in a short record, but does not need CAB. If the result differs from the template, it is handled as a normal change.

6.10.3 Emergency change

1. RequestThe service owner or incident manager calls the change manager or Head of IT Operations, who convenes the ECAB by phone or chat. Time target: within [30 minutes].
2. AuthoriseECAB approves the action, a rollback approach and the people allowed to act. A verbal approval is recorded in writing at once.
3. ImplementDo the minimum needed to restore service or remove the exposure. Keep a log of every command or action.
4. Document afterwardsThe RFC is completed within [2 working days] and reviewed at the next CAB. Emergency changes are counted in the monthly report, and a trend of more than [10%] of all changes triggers a review of planning.

6.11 Co-ordination of implementation

1. ScheduleThe change manager places the approved change in the change calendar and checks for clashes with other changes, freezes, backups and business events.
2. PrepareThe change owner confirms resources, access, pre-change backup, runbook and test accounts. Where needed a go/no-go call is held [1 hour] before the window.
3. NotifyStakeholders receive the notice set in the communication section.
4. Hand overFor changes that span teams or suppliers, a single coordinator is named and an escalation contact list is shared.

6.12 Successful change implementation

1. ImplementThe change owner carries out the steps in the runbook, logging time and result for each step.
2. VerifyRun the verification checks defined in the plan: service health, monitoring alerts, security controls, logging, and user acceptance where applicable.
3. DecideIf verification passes within the window, the change is declared successful. If any trigger condition occurs, roll back and record why.
4. Update recordsUpdate configuration records, asset register, diagrams, documentation, and backups. Attach evidence to the RFC within [1 working day].
5. Close or holdA successful change moves to review. A failed change is marked Failed or Backed out and an incident or problem is raised where appropriate.

6.13 Meeting the change objective

1. ReviewThe change manager and requester hold a review after [5 working days] for medium and high risk changes, or when the benefit takes time to appear.
2. CompareCheck whether the stated objective was achieved, whether unexpected effects occurred, and what the actual effort and downtime were against plan.
3. LearnRecord lessons learned and update standard templates, test plans or checklists. Where the objective was not met, raise a follow-up RFC or problem record.
4. CloseClose the RFC with status Successful, Successful with issues, Failed, or Cancelled.

6.14 Communication to stakeholders

Notices are short and use plain wording. A cancelled or overrunning change is announced as quickly as a started one, with the new time or the reason it will not go ahead.

7. Security Review Checklist for Changes

The information security manager, or a delegate, uses these questions for every medium and high-risk change. A no answer needs a recorded condition or an accepted risk.

8. Change Types by Example

9. Compliance and Monitoring

• The change manager reconciles the change register against system logs, deployment records and detected configuration drift each [month] to find changes made without an RFC.
• The information security manager reviews unauthorised changes as incidents. Repeated unauthorised change by one team or person is reported to management.
• Internal audit samples at least [25] changes per [year], covering each type and risk level, and tests that approval, testing, rollback and review evidence exists.

10. Measures

11. Records and Evidence

• Change register, containing every RFC with status, owners, approvals, dates and outcome, kept for [3 years].
• CAB and ECAB minutes, attendance and decisions, kept for [3 years].
• Test evidence, rollback plans, communication notices and post-implementation reviews, attached to the RFC and kept with it.
• Standard change templates with approval and review dates, kept while current and [2 years] after retirement.

Annexure A: Change request form

Annexure B: Change register

Annexure C: CAB meeting record

Annexure D: Post-implementation review

12. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

13. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

14. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Systems Acquisition, Development and Maintenance Policy
• System Development and Maintenance Procedure
• Patch Management Policy
• Secure Configuration Policy
• Backup and Restoration Policy
• Information Security Incident Management Policy
• Change Management Procedure
• Problem Management Policy and Process