5 IT Change Management

Purpose and principles

IT change management is the controlled process of modifying technology services, systems, configurations, or related procedures. Its purpose is to deliver useful changes while limiting disruption, security exposure, and operational risk.

A reliable process records proposed changes, assesses their effects, obtains appropriate authorization, implements and verifies approved work, and retains a record of the outcome. The amount of review should be proportionate to the change’s risk and impact.

Classify and assess changes

Classify each proposed change according to organizational policy. The category determines the applicable assessment, authorization, and documentation process.

• Standard change: A routine, low-risk change covered by a documented, preapproved procedure. Record and perform each instance according to that procedure.

• Normal change: A change requiring case-by-case assessment and approval before implementation.

• Emergency change: An urgent change needed to address an active outage, security threat, or similarly time-critical risk. Use the organization’s emergency authorization process, then complete required documentation and review afterward.

Assess the change’s purpose, affected systems and users, dependencies, timing, and potential effects on availability, security, privacy, safety, and compliance. Estimate the likelihood and impact of failure, identify mitigations, and review the assessment if the scope or conditions change.

Request and authorize the work

A change request should give reviewers enough information to understand and control the work. Include:

• The reason for the change and its intended result.

• The systems, services, configurations, and people affected.

• The risk assessment, dependencies, and test results or test plan.

• Implementation steps, the responsible owner, the schedule, and a maintenance window if needed.

• Validation criteria, monitoring arrangements, and a rollback or recovery plan.

• Required communications and supporting records, such as configuration or procedure updates.

For a normal change, obtain approval before implementation from people authorized by organizational policy, such as a service owner, security specialist, or change advisory group. Approval should reflect the assessed risks and business impact. Record the decision and its rationale, and do not treat approval as permission to exceed the approved scope.

Communicate and implement

Tell affected users, support teams, service owners, and other stakeholders what is changing, why and when it is changing, what effects or actions to expect, and where to get help. Give notice early enough for people to prepare while protecting sensitive operational details. Coordinate with incident or service-desk teams when appropriate.

Before implementation, confirm authorization, scope, timing, access, dependencies, backups or saved configurations, and readiness to roll back. Follow approved procedures and use the intended change window. When practical, test in a nonproduction environment or use a limited pilot.

During the work, maintain an accurate activity record and monitor relevant alerts and service indicators. Pause or roll back if results fail the agreed criteria or create unacceptable risk. Controlled deployments and rollback mechanisms help limit the effects of unsuccessful changes.

Verify, document, and review

After implementation, check that the change achieved its intended result and that affected services remain secure and operational. Confirm that monitoring, access, integrations, and user workflows behave as expected. If validation fails, follow the rollback plan or escalate through incident procedures.

Close the change record only after documenting what was done and when, who performed and approved it, validation results, unexpected effects, and any rollback or follow-up work. Update configuration records, diagrams, inventories, and operating procedures as needed. Review significant or unsuccessful changes to identify lessons and improve future planning.

Change-control practice includes documenting decisions, implementing approved changes, retaining records, and monitoring and reviewing change-control activities.

Example: changing a firewall rule

An administrator proposes changing a firewall rule so an application can reach a new service. The request records the business need, affected systems and users, security implications, test evidence, implementation window, and a saved prior configuration for rollback.

An authorized reviewer approves the specific rule and schedule. The administrator notifies relevant teams, applies only the approved change, verifies connectivity and security logs, and records the result. If the test fails, the administrator restores the previous rule and documents the failure for review.