IT Change Request Template: The Fields CAB Actually Needs
CAB meetings have a predictable rhythm. Someone presents a change request. Someone else asks where the back-out plan is. The requester says there isn't one, or it's in a different document, or it's "basically just reverting the config." The CR gets sent back for revision. Thirty minutes of the meeting are gone.
This happens because most IT change request templates were written once, never audited for completeness, and then became the permanent standard by default. The fields that make a CAB review fast and confident are exactly the ones that get left out or marked optional.
This article covers the complete template structure for a normal change request — the type that requires full CAB review — along with the three fields that consistently go missing and what happens when they do.
Why CRs Get Sent Back from CAB
Before going through the template, it helps to understand the specific failure modes.
No back-out plan. The most common reason for rejection. "We'll just revert it" is not a back-out plan. A back-out plan names who executes the rollback, describes the exact steps, estimates how long rollback takes, and defines what the confirmed restored state looks like.
Affected systems listed incompletely. The primary system is named but the downstream dependencies are not. A firewall rule change that affects three application servers gets documented as a firewall change. The app server owners aren't notified. CAB approves based on partial information.
No testing sign-off. The testing plan says "dev environment tested." There's no named person who signed off on those test results, no date, and no record of what was tested against what criteria. CAB can't assess how much confidence to put in the test results.
Risk classification missing or wrong. Marking a major infrastructure change as "low risk" because the requester wants to avoid extra scrutiny. CAB members catch this, and it damages trust in the requester's other CRs.
Implementation schedule too vague. "Weekend of the 14th" is not an implementation schedule. Is that Saturday or Sunday? What time? Who's on call? What's the maintenance window length?
Each of these sends the CR back for revision, which delays the change, burns CAB time, and creates friction that eventually leads teams to find workarounds — like routing changes as work orders to avoid the process entirely.
The Complete Template: Section by Section
What follows is the full structure for a normal change request. Standard changes (pre-approved, repetitive, low-risk) can use a shorter version. Emergency changes need an abbreviated form with retrospective review. This is the full normal-change template.
Section 1: Summary
| Field | Description |
|---|---|
| CR Title | Short, specific description of the change. "Upgrade PostgreSQL from 14.3 to 15.1 on prod-db-01" not "Database upgrade." |
| CR Number | Auto-assigned by your system. |
| Date Submitted | Date the CR was filed, not the date of the planned change. |
| Requester Name | The person filing the CR. |
| Requester Team | Department or team responsible for the change. |
| Change Owner | The person accountable for successful implementation. May differ from the requester. |
| Change Type | Standard / Normal / Emergency. |
| Priority | Low / Medium / High / Critical. |
The CR title matters more than most teams realise. A vague title means CAB members read the full document before knowing if they're even responsible for reviewing it. A specific title lets the right people engage immediately.
Section 2: Business Justification
| Field | Description |
|---|---|
| Reason for Change | Why this change is being made. Security patch, performance issue, new feature requirement, vendor end-of-life. Be specific. |
| Business Impact if Not Done | What happens if this change is deferred or rejected? Quantify where possible: "Vendor support ends June 30. Running unsupported software creates SOC2 audit exposure." |
| Expected Benefits | What does a successful change deliver? Measurable outcomes preferred. |
This section is where requests often get sloppy. "Upgrade to latest version" is not a justification. "PostgreSQL 14.3 reaches end-of-life on November 12, 2026, and our SOC2 Type II audit requires supported software versions on all production databases" is a justification.
Section 3: Affected Systems and Assets
| Field | Description |
|---|---|
| Primary System/Asset | The specific system, server, application, or device being changed. Include asset ID if your organisation uses an asset register. |
| Affected Downstream Services | List every service, application, or user group that depends on the primary system. This is one of the three most commonly missed fields. |
| Client/Tenant Impact | For MSPs and multi-tenant environments: which clients are affected and are they aware? |
| Affected Users | Estimate of users impacted during the change window. |
| Change Environment | Production / Staging / Development. Changes to production require full review. |
The downstream services field is where incomplete documentation causes the most post-change incidents. A database upgrade affects every application that queries that database. If those application owners weren't notified, they find out when their monitoring alerts fire.
Section 4: Change Details
| Field | Description |
|---|---|
| Current State | What exists today. Current software version, current configuration, current infrastructure state. |
| Target State | What will exist after the change. |
| Implementation Steps | Numbered, sequential steps for executing the change. Enough detail that someone other than the requester could follow them. |
| Estimated Implementation Duration | How long the implementation takes from start to finish. |
| Implementation Window | Specific date, start time, end time. Include timezone. |
| On-Call Contact During Implementation | Name and contact details for the person who can be reached if something goes wrong during the window. |
The implementation steps field separates a real change request from a placeholder. Steps should be specific enough to execute: "1. Take snapshot of prod-db-01. 2. Stop application services on app-01, app-02, app-03. 3. Begin PostgreSQL upgrade..." rather than "1. Backup. 2. Upgrade. 3. Test."
Section 5: Risk Assessment
| Field | Description |
|---|---|
| Risk Level | Low / Medium / High / Critical. Use your organisation's defined criteria, not subjective assessment. |
| Risk Rationale | Why this risk level was assigned. What factors were considered. |
| Potential Failure Modes | What could go wrong during implementation. List specific failure scenarios, not generic "things could break." |
| Mitigation Actions | What's being done to reduce the likelihood or impact of each failure mode. |
If your CR template has a risk field with no rationale field next to it, teams will assign whatever rating gets the CR through fastest. The rationale field forces the thought process.
Section 6: Testing Plan
| Field | Description |
|---|---|
| Pre-Change Testing Completed | What testing was done before submitting the CR. Environment tested in, test cases run, results. |
| Testing Sign-Off Name | The named person who reviewed and signed off on test results. This is one of the three most commonly missed fields. |
| Testing Sign-Off Date | When testing sign-off occurred. |
| Post-Change Verification Steps | Specific checks to perform immediately after implementation to confirm success. |
| Verification Owner | Who performs and confirms post-change verification. |
"Tested in dev" tells CAB very little. "Ran 47 regression test cases against a production-parity staging environment on May 3. All tests passed. Sign-off: Sarah Chen, 2026-05-03" gives CAB a basis for confidence. Without a named sign-off and a date, there's no accountability for the test results.
Section 7: Back-Out Plan
| Field | Description |
|---|---|
| Back-Out Trigger Conditions | Under what specific conditions will the back-out be initiated? Time elapsed, error rate exceeded, service unavailable. |
| Back-Out Steps | Numbered steps to roll back to the pre-change state. |
| Back-Out Duration | How long rollback takes. |
| Back-Out Owner | The named person responsible for executing the rollback. This is the third most commonly missed field. |
| Confirmed Restored State | How the team will confirm the rollback was successful. |
The back-out owner field is almost always missing. Teams document rollback steps, but leave them ownerless. When something breaks at 2am and three engineers are on a call trying to decide who's executing the rollback, the absence of a named owner creates a real delay. One name. Write it in.
Section 8: CAB Approval Chain
| Field | Description |
|---|---|
| Required Approvers | Named individuals and their roles. Defined by change type and risk level. |
| Approver 1 | Name, role, approval status, date/time approved or rejected. |
| Approver 2 | Same structure. |
| CAB Chair Decision | Final CAB decision with date and any conditions attached. |
| Approval Notes | Any conditions, caveats, or required modifications noted by approvers. |
Approval by silence is not approval. The system should require an explicit approve or reject action from each named approver before the CR can advance. CAB meeting minutes alone are not sufficient documentation that named individuals approved specific CRs.
Section 9: Post-Implementation Review
| Field | Description |
|---|---|
| Actual Implementation Date/Time | When the change was actually executed. |
| Implementation Outcome | Successful / Partially successful / Back-out executed. |
| Issues Encountered | Any problems that occurred during implementation. |
| Deviations from Plan | Where the actual execution differed from the documented steps. |
| PIR Sign-Off | Named person who confirmed the post-implementation review is complete. |
| PIR Date | Date the review was completed (must be after a defined monitoring window, typically 24-72 hours). |
Post-implementation reviews are the mechanism for organisational learning. If teams skip them, the same failure modes appear in future CRs. If the software doesn't enforce PIR completion before closing a CR, most teams will skip it.
The Three Fields Teams Always Forget
To make this concrete: the three fields that appear blank most often in real-world CAB reviews are:
- Rollback owner (Section 7). Teams document what to do but not who does it.
- Testing sign-off (Section 6). Tests happen informally, but nobody officially certifies the results.
- Affected downstream services (Section 3). The primary asset is named, the dependencies are assumed.
All three of these fields exist to prevent a specific failure mode:
- No rollback owner: coordination failure when a back-out is needed
- No testing sign-off: no accountability for test quality
- No downstream services list: incomplete impact assessment leads to unnotified stakeholders
If you're building or auditing a CR template, start with these three.
Standard vs Normal vs Emergency Templates
Not every change gets the full template above. A practical CR system uses three template variants:
Standard change template. For pre-approved, repetitive, low-risk changes that match defined criteria. Examples: routine monthly patch cycle, adding a user to an existing group, restarting a known-stable service. These have a shorter form because the risk profile is already defined. Sections 2, 5, and 8 are abbreviated or pre-populated.
Normal change template. The full template above. Requires CAB review. For any change that doesn't qualify as standard and isn't an emergency.
Emergency change template. Abbreviated form for changes that need to happen immediately in response to an incident. Captures the minimum: what's being changed, who authorised it, what the back-out steps are. Full documentation is completed retrospectively within 24-48 hours, and the emergency CR is reviewed at the next CAB meeting.
The distinction matters because applying full CAB process to a routine patch wastes time, and using the emergency template for a planned major change skips safeguards.
When Manual Templates Break Down
A well-structured template solves the single-CR problem. It doesn't solve the scale problem.
When a team processes 20 CRs per month, a shared template document with copy-paste works. When they process 80, the template document gets corrupted, people start using outdated versions, required fields start being marked optional by convention, and the approval chain becomes informal.
At that point, what you need is:
- Templates auto-generated by change type, so every CR starts from the right structure
- Required fields enforced at the form level, not by honour system
- Approval workflows that route to the right people automatically based on risk level and change type
- An audit trail that captures every action, not just the final approval
That's what purpose-built CR management software does. AssetOS generates CR templates automatically based on the change type selected, enforces required fields including back-out plan and testing sign-off, and routes to the configured CAB approval chain. The template structure above is built into the platform so teams don't maintain it manually.
Manual templates are a good starting point. They stop working when volume goes up and when team composition changes. Investing in a system that enforces the template removes the dependency on everyone knowing the right process.
For a broader overview of what to look for when buying CR management software, see Change Request Management Software: What to Look For in 2026.
Shane Price
Writing about maintenance management, CMMS implementation, and the real challenges operations teams face.