IT change management: approvals, maintenance windows, and freeze periods

Reference article · 5 min read

Change management, in the operations sense, is how an agency decides when a running system may be modified and who agrees first. It covers the patch, the configuration edit, the firewall rule, the schema update, and the vendor release that lands in production whether or not anyone was watching. It is a separate matter from a contract change order.

Agencies get into trouble at both ends. With no gates, outages have no explanation and auditors find changes with no record. With too many gates, staff route around the process, so changes still happen but stop being documented. A process sized correctly clears routine work in hours and gives risky work a second reviewer.

Sort changes into three types

ITIL and the configuration management controls in NIST Special Publication 800-53 describe roughly the same three categories.

Standard. Repeatable and low risk, with a written procedure and a known way back: account provisioning, routine patching, replacing a failed drive. Approved once as a type, logged every time it runs.
Normal. Reviewed before it happens: a firmware upgrade, an interface change, a new firewall rule, a vendor release promoted to production. Submitted with a plan and scheduled into a window.
Emergency. Cannot wait, usually to restore a down service or close a vulnerability being exploited. Approved by a named on-call authority, then documented afterward.

Growing the standard list is the highest-value maintenance task: each type you move out of normal removes a queue without removing a record.

Match the approver to the blast radius

Approval should scale with what breaks if the change fails, not with who is asking.

Standard. No separate approval. The implementer follows the procedure and records the work in the ticket system.
Normal, contained. System owner or supervisor, plus one technical reviewer who did not write the plan.
Normal, public facing or cross-department. The review board, plus the department that owns the service. Add a security or privacy reviewer when the change touches regulated data such as criminal justice, health, or student records; those requirements change, so confirm current expectations with the governing agency or your counsel.
Emergency. A named duty manager, with that authority written down in advance so nobody guesses at two in the morning. Review it retroactively, and treat a pattern of emergencies as misclassification.

Meet often enough that nobody routes around the board

A board that meets monthly will be bypassed. Weekly is a reasonable floor, and a short standing call beats a long meeting. Membership: infrastructure, applications, network, security, the service desk, and a rotating representative from the departments with items on the agenda. Three habits keep it short:

A submission cutoff, with late items going to the next cycle unless expedited.
Review of the plan, the risk, and the window, not a redesign of the work.
A written out-of-cycle path, usually ticket approval by two named people, so a time-sensitive normal change is not relabeled an emergency to move faster.

Choose maintenance windows around public service hours

Round-the-clock services. Dispatch, jail management, and utility control systems have no quiet hour. Coordinate the window with the operating department and staff the backup procedures during the work.
Business-hour services. Permitting, licensing, and payment portals tolerate nights and weekends, but avoid month end, billing and court filing deadlines, and the night before a council meeting.
Downstream dependencies. A change that finishes at four in the morning but blocks a five o'clock file transfer to a state system is still an outage.
Support coverage. Confirm the vendor's support hours in their time zone. A window with nobody reachable is a longer outage waiting to happen.

Plan the rollback, then verify after the change

Write the way back first. Record what triggers a reversal and the latest clock time you can still reverse and finish before service resumes.
Test the restore. A snapshot nobody has ever restored is not a rollback plan.
Verify with people who use the system. A service that responds is not a service that works. Have a named user complete a real transaction: file a permit, run a query, print a report.
Watch after you close. Name who declares success and writes the closing entry.

Freeze periods, and the exceptions to them

Publish a freeze calendar early in the year. Common freezes cover election periods, fiscal year close, tax and utility billing runs, open enrollment, severe weather season, and the weeks around a major go-live. Election systems carry certification and testing constraints of their own, so confirm with your state elections office first.

A freeze suspends normal changes, not emergency ones. Say plainly who can grant an exception, what qualifies, and that patches for actively exploited vulnerabilities stay available through the emergency path.

What to ask vendors, and how to start

Ask during procurement and again before each renewal:

How much notice comes before a release, and do release notes arrive beforehand?
Can we defer or schedule an update, or does the platform move all customers at once?
Is there a non-production environment that matches ours, refreshed on request?
How are emergency security patches handled, and who notifies us?

Put the notice period, the test environment, your freeze windows, and rollback obligations in the contract rather than leaving them to the vendor's release habits.

To start, write one page listing the three change types, the approver for each, the board's standing meeting, and the freeze calendar. Log changes in the ticket system you already have, and let the failures you record tell you where the gates belong.

HQT works in software development, cloud and enterprise IT, and technology advisory and systems engineering for state and local government agencies, including the release and change practices around production systems.

Frequently asked questions

What is the difference between a standard, normal, and emergency change?

A standard change is pre-approved as a type because it is repeatable, low risk, and has a written procedure and a known rollback, so the implementer proceeds and logs the work. A normal change is reviewed and scheduled before it happens, such as a firmware upgrade, an interface change, or a vendor release moving to production. An emergency change cannot wait for the next review cycle, usually because a service is down or a vulnerability is being actively exploited, and it is approved by a named on-call authority and documented afterward.

How often should a change advisory board meet?

Often enough that nobody has a reason to bypass it, which for most agencies means at least weekly. A short standing call with a submission cutoff works better than a long monthly meeting, because a long wait pushes staff to reclassify normal changes as emergencies. Pair the meeting with a written out-of-cycle approval path, usually sign-off by two named people, for changes that genuinely cannot wait for the next session.

Who should be on a change advisory board in a local government agency?

Keep it small: infrastructure, applications, network, security, and the service desk, plus a representative from whichever department owns the systems on that week's agenda. Invite the vendor or managed service provider when their release is being reviewed. The board's job is to review the plan, the risk, and the timing, not to redesign the technical work.

When should an agency schedule a freeze period for IT changes?

Typical freezes cover election periods, fiscal year close, tax and utility billing runs, benefits open enrollment, severe weather season, and the weeks surrounding a major system go-live. Publish the calendar early in the year so departments and vendors can plan around it. Election systems also carry their own certification and testing constraints, and those rules vary by state and change over time, so confirm what is permitted with your state elections office before scheduling any work on them.

Can we stop a SaaS vendor from pushing updates during our freeze?

Sometimes, but not always, because many multi-tenant platforms update all customers at once and cannot hold a single agency back. Ask during procurement whether releases can be deferred or scheduled, how much advance notice and release notes you receive, and whether a matching non-production environment is available for testing. Where deferral is not possible, negotiate notice periods, testing time, and support coverage during your critical periods into the contract rather than relying on the vendor's usual release practice.