Change Management Checklist

Create the change record in ServiceNow, Jira Service Management, or Freshservice. Link the originating ticket, problem record, or vendor advisory (CVE, KB article) so the business reason is auditable. Avoid free-text RFCs in email — they don't survive a SOX or SOC 2 audit trail.

Standard changes are pre-approved low-risk repeatables (e.g., approved patch deployment via SCCM). Normal changes go through CAB. Emergency changes follow the ECAB path with abbreviated review. Misclassifying an emergency to skip CAB is the most common ITGC audit finding.

List affected CIs from the CMDB — hostnames, VLANs, AD OUs, SaaS tenants. Note dependencies the change touches (DNS, AD, identity provider). Vague scope is what causes Friday-afternoon GPO incidents.

The change owner is accountable; the implementer executes during the window. Segregation of duties matters — for SOX-scope systems the approver cannot be the implementer.

Use the standard 5x5 matrix. Flag the change as high-risk if it touches identity (Entra ID / AD), production databases, the firewall, or backup infrastructure. High-risk changes require CAB review regardless of size.

Step-by-step commands, expected output, validation checks, and timing per step. Anyone on the on-call rotation should be able to execute it. Reference the gold image, GPO name, or Terraform module by exact identifier.

Specify the rollback trigger condition, who decides, and the exact steps. For schema changes include the snapshot or transaction-log restore point. "Restore from backup" is not a rollback plan — name the backup job, the RPO, and the restore time estimate.

Check year-end freeze, retail Black Friday blackout, payroll-run windows, and client-specific MSAs. A change scheduled during a contractual freeze gets rejected at CAB even if it's otherwise low-risk.

For OS / application patches use three rings: test (IT lab, day 0), pilot (5-10% of fleet, day 3-7), production (remainder, day 7-14). Skipping the pilot ring is what turns Patch Tuesday into a P1 incident.

Most CABs require submission 48-72 hours before the meeting. Late submissions roll to the next CAB unless the change owner requests an emergency exception with justification.

Walk through scope, risk score, runbook summary, rollback, and validation criteria. CAB attendees include the change manager, security, network, and application owners. Be ready for questions on dependencies and the comms plan.

Update the runbook, rollback, or comms plan based on CAB feedback. Re-attach the revised artifacts to the RFC and tag the change manager for sign-off before the implementation window opens.

Send the maintenance notice 5-7 business days ahead via the standard channel (email DL, Teams announcement, status page). For MSP work, notify the client primary plus their listed escalation contacts.

VM snapshot via vCenter / Hyper-V, database backup, GPO export, or config save ("copy run start" on Cisco). Confirm the backup completed and is restorable — not just that the job kicked off. This is the rollback insurance.

Teams or Zoom bridge with the implementer, change manager, and SME for each affected stack. Post status every 15 minutes. PagerDuty / Opsgenie on standby for adjacent service owners.

Follow the approved runbook verbatim. If output deviates from expected, pause and consult the change manager before proceeding. Going off-script during the window is a documented audit finding.

Smoke-test the affected service: login flow, transaction path, monitoring agent reporting green, replication lag within RPO. Capture screenshots or command output as evidence.

Restore from snapshot, revert the GPO link, or redeploy the prior package. Confirm the affected service returns to the pre-change baseline before declaring rollback complete. File a P2 ticket if rollback exceeds the documented RTO.

Watch PRTG, Datadog, or Sentinel dashboards for anomalies — error rate, latency, login failure rate. Many changes pass validation but surface problems on the next business-hours load cycle.

Pull tickets opened in the 48 hours after the window. Filter by affected CI to catch tickets users didn't link to the change. A spike in password-reset tickets after an Entra ID change is a signal you missed something.

Compare actuals against the plan: timing, scope, deviations, incidents. Identify whether this should become a standard pre-approved change going forward, or whether the runbook needs revision.

Update CI versions, IP allocations, GPO inventory, and IT Glue / Hudu runbook pages. Stale documentation is the second-most-common reason the next change goes sideways (after missing rollback plans).

Attach validation screenshots, monitoring graphs, CAB approval, and PIR summary to the change record. Auditors sample closed changes — missing evidence on a sampled record is a finding regardless of whether the change itself succeeded.