IT Change Management Checklist

A change management checklist for small IT teams: risk-rate each change request, get approval, plan rollback and keep evidence for SOC 2 or ISO 27001.

Typical schedule per change
The checklist 4 sections, 20 items
Variables {{change_id}} {{system}}
Start from CI

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Use this checklist for changes to production systems that are not covered by a routine, automated deployment: firewall changes, database upgrades, DNS moves, new integrations, permission model changes and infrastructure migrations. It brings the core of ITIL-style change control to a small team without a weekly change advisory board (CAB) meeting.

Who owns it

The change owner, usually the engineer doing the work, starts the run and fills in the plan. An approver who is not the implementer signs off before the work starts. For high-risk changes, the approver can be a small group acting as the CAB. Adapt this to your jurisdiction and audit scope; it is a practical checklist, not legal advice.

Common pitfalls

One process for every change. If a typo fix needs the same approval as a database migration, people route around the process. Define standard, normal and emergency changes.
Approval after the fact. An approval recorded after the work is done is not change control, and auditors notice the timestamps.
Rollback plans that were never tested. "Restore from backup" is not a plan unless you know how long the restore takes.
Emergency changes with no review. Fixing fast is right during an incident. Reviewing the change within a day or two is what keeps the exception honest.

Start the run from your ticketing system or pipeline through POST /api/v1/runs, so every approved change gets a timestamped record of who approved, implemented and verified it.

The checklist: Change {{change_id}} on {{system}}

Describe the change

Describe what changes on {{system}}, why, and the expected result
Classify the change as standard, normal or emergency
Standard changes are pre-approved, low-risk and repeatable. Emergency changes fix an active incident.
Rate the risk and impact, including which users and services are affected
List dependencies and other teams that need to know

Plan and approve

Write the implementation steps in order, with the commands or settings to apply
Write the rollback steps and the condition that triggers a rollback
Confirm a recent backup or snapshot of {{system}} exists optional
Required for data or schema changes, not for stateless configuration.
Test the change in a non-production environment, or record why that is not possible
Schedule the change window and check for conflicts with other changes or busy periods
Get approval from someone other than the implementer before starting
For high-risk changes, get approval from the CAB or the system owner.
Notify affected users or customers ahead of time if there is visible impact optional

Implement

Announce the start of change {{change_id}} in the team channel
Apply the change following the written steps
Record any deviation from the plan as it happens

Verify and close

Verify that {{system}} works as expected with a functional test
Check monitoring and logs for errors after the change
Roll back if verification fails, and record the reason
Update documentation, diagrams or the configuration inventory
Announce completion and close the change ticket with the outcome
Hold a post-implementation review for emergency or failed changes optional

Checklist as Markdown

# Change {{change_id}} on {{system}}

## Describe the change
- [ ] Describe what changes on {{system}}, why, and the expected result
- [ ] Classify the change as standard, normal or emergency
  Standard changes are pre-approved, low-risk and repeatable. Emergency changes fix an active incident.
- [ ] Rate the risk and impact, including which users and services are affected
- [ ] List dependencies and other teams that need to know

## Plan and approve
- [ ] Write the implementation steps in order, with the commands or settings to apply
- [ ] Write the rollback steps and the condition that triggers a rollback
- [ ] Confirm a recent backup or snapshot of {{system}} exists (optional)
  Required for data or schema changes, not for stateless configuration.
- [ ] Test the change in a non-production environment, or record why that is not possible
- [ ] Schedule the change window and check for conflicts with other changes or busy periods
- [ ] Get approval from someone other than the implementer before starting
  For high-risk changes, get approval from the CAB or the system owner.
- [ ] Notify affected users or customers ahead of time if there is visible impact (optional)

## Implement
- [ ] Announce the start of change {{change_id}} in the team channel
- [ ] Apply the change following the written steps
- [ ] Record any deviation from the plan as it happens

## Verify and close
- [ ] Verify that {{system}} works as expected with a functional test
- [ ] Check monitoring and logs for errors after the change
- [ ] Roll back if verification fails, and record the reason
- [ ] Update documentation, diagrams or the configuration inventory
- [ ] Announce completion and close the change ticket with the outcome
- [ ] Hold a post-implementation review for emergency or failed changes (optional)

Start this checklist from your pipeline

When a change ticket moves to approved, POST /api/v1/runs with template "Change {{change_id}} on {{system}}" and the ticket ID as change_id.

curl -X POST https://runbook.metastic.ch/api/v1/runs \
  -H "Authorization: Bearer $RUNBOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "Change {{change_id}} on {{system}}", "variables": {"change_id": "…", "system": "…"}}'

See the API and the GitHub Action

Frequently asked questions

What is the difference between standard, normal and emergency changes?

Standard changes are low-risk, repeatable and pre-approved, such as a routine certificate renewal. Normal changes need assessment and approval each time. Emergency changes fix an active problem and are approved quickly, with a fuller review afterwards.

Do small teams need a change advisory board?

Not a formal weekly meeting. What matters is that someone other than the implementer reviews and approves risky changes before they happen. A named approver per system, plus a group review for the highest-risk changes, covers the intent of a CAB for most small teams.

What change management evidence do SOC 2 and ISO 27001 auditors look for?

Auditors usually sample changes and check that each was documented, tested, approved before implementation by someone other than the author, and verified afterwards. A run per change, with timestamps and names on each step, gives them that trail directly.

Updated 2026-11-04