Change details
- Change ID
- e.g. CHG-2026-0884
- Title
- e.g. Upgrade load balancer firmware to 9.4.2
- Requested by
IT Change Request Form
Change control earns its reputation for bureaucracy when every change gets the same paperwork. This form routes by risk: standard changes are pre-approved and need almost nothing, while the genuinely risky ones get the scrutiny that would otherwise be spread thinly across everything.
What you get
- A risk score derived from impact, reversibility, and blast radius, not a self-assessed guess
- Approval routing driven by that score, so low-risk work is not queued behind a board
- A backout plan section that will not accept the word 'rollback' as an answer
- A post-implementation review block, including the question most PIRs omit
How to use this template
- 1
Score the change rather than letting the requester label it. Everyone marks their own change low risk. Score it from three facts instead: how many users are affected, whether it can be reversed in minutes, and whether it touches data. The score then selects the approval path, which removes the negotiation entirely.
- 2
Build a standard change catalogue and stop reviewing routine work. Changes you have done many times with a consistent outcome (adding a firewall rule from an approved pattern, a certificate renewal, a routine patch ring) should be pre-approved once as a category. If your CAB spends its time on these, it has no attention left for the change that will actually cause an outage.
- 3
Require a backout plan that someone else could execute. "Roll back the deployment" is not a plan. The test is whether a different engineer, at 02:00, could follow the steps without calling the author. If a forward-only database migration makes rollback impossible, say so explicitly. That is critical information, not an admission of failure.
- 4
Record what the change actually did, beyond the fact that it closed. The post-implementation review needs one uncomfortable question: did anything break that you did not predict? Answering it builds the pattern library that makes future risk scoring accurate. Closing changes as successful by default makes the whole process ceremonial.
What's inside
Here's a preview. Unlock the free download to get all 8 sections (7 more below).
Related templates
More free templates IT teams use alongside this one.
Security Operations
Get templatePatch Schedule Template
Patching breaks things, which is why teams delay it, which is why they get breached through something with a patch available for six months. This schedule is built around deployment rings, so a bad patch hits a pilot group of twenty people rather than the whole company.
Incident Response
Get templateIncident Postmortem Template
Most postmortems produce a document nobody reads and actions nobody owns. This one forces the three things that actually reduce repeat incidents: a timeline built from timestamps rather than memory, contributing factors stated without naming a person, and action items with an owner and a date.
DevOps & SRE
Get templateRunbook Template
A runbook is read by a tired person at 03:00 who did not write it and does not know this service. That single constraint rules out most of what people put in runbooks: architecture background, rationale, and anything written in prose when it could have been a command.
Frequently asked questions
What should an IT change request form include?
+
The change details and services affected, a risk score derived from impact and reversibility, the approval path that score selects, numbered implementation steps with verifications, a tested backout plan with a point of no return, and a post-implementation review.
What is the difference between a standard, normal, and emergency change?
+
A standard change is pre-approved as a category because it is routine and well understood, so it is logged rather than reviewed. A normal change follows the risk-based approval path. An emergency change bypasses the normal lead time and is reviewed retrospectively, usually within 48 hours.
Who should approve a change request?
+
Let the risk score decide. Low-risk changes need a team lead. Medium needs the service owner plus a peer reviewer. High and critical changes warrant a change manager and full CAB review. Routing by score removes the argument about which path a change belongs on.
What makes a good backout plan?
+
Numbered steps a different engineer could execute alone, a stated point of no return, a specific trigger for invoking it, an estimated time to complete, and an honest note on whether it has been tested. If the change cannot be reversed (a forward-only migration, for instance), state that explicitly.