Patching systems you cannot reboot: rings, windows, and exceptions

Reference article · 6 min read

Most patch management policies are written as if every server can be rebooted on a schedule. They set a deadline measured in days after release, apply it uniformly across the environment, and leave the hard cases to be worked out informally. The hard cases are exactly the ones auditors ask about: the computer-aided dispatch server that supports a 24/7 communications center, the jail management system tied to housing and release workflows, the SCADA historian on a water treatment network, the clinical system in a county health facility. Those systems get skipped quietly, cycle after cycle, until someone asks why a production server is three versions behind.

A patch program that holds up under review does not promise to patch everything on the same clock. It sorts systems into rings with different timelines, commits to maintenance windows that operations will actually honor, and documents the remaining gaps as formal exceptions with named owners, compensating controls, and expiry dates. That combination gives an IT director something to show an auditor or an insurer other than an apology.

Deployment rings

A ring is a group of systems that receives a patch at the same stage of a release sequence. Patches move outward only after the previous ring has run clean for a defined soak period.

• Ring 0, pilot. IT staff workstations, lab instances, and a small group of volunteers who know to report oddities. Short soak, high tolerance for rollback.
• Ring 1, general staff. Office endpoints and back-office servers. This ring proves the patch against your actual image, agents, and group policy, not against the vendor's clean lab.
• Ring 2, business systems. Permitting, finance, ERP, records, and public-facing web. Interruptible with notice, usually on a weekend or overnight window.
• Ring 3, critical and continuous. Dispatch, jail, industrial control and operational technology, traffic systems, clinical applications. Scheduled windows, vendor certification required, failover tested first, rollback plan written before the window opens.

Write down the promotion criteria between rings: how long the soak lasts, what counts as a blocking defect, and who approves the move. Without that, rings become labels rather than a control.

Maintenance windows that operations will honor

Windows for continuous systems have to be negotiated with the people who run the operation, then protected once they exist.

• Dispatch and public safety communications. Pick the recurring low-volume hours identified from your own call data, mid-week rather than weekend nights. Confirm the center's documented downtime procedures are current, notify allied agencies and any shared regional partners, and patch clustered nodes one at a time so the system never goes fully dark.
• Jail and detention. Avoid shift change, count, meal service, and court transport. Treat anything touching door control or life safety as a separate change with the facility's own approval, not as routine patching.
• SCADA and operational technology. Windows are seasonal as much as hourly. Align them to process conditions, avoid peak demand and storm season, and expect vendor validation to limit you to a quarterly or semiannual cadence on the control layer while the business network patches monthly.
• Clinical systems. Work around clinic hours and interface dependencies to pharmacy, lab, and billing. Verify downtime procedures and paper fallback before the window, not during it.

Publish a rolling annual window calendar, get the operational owner to sign it, and resist canceling windows for convenience. A window canceled three times in a row becomes an exception whether or not anyone writes it down.

When the vendor's certified level lags the operating system

Many public safety, detention, and control system applications are certified against specific operating system, database, and browser versions. Applying an update the vendor has not certified can put you outside supported configuration at the worst possible moment.

Manage the gap deliberately. Track, per vendor, how long it takes them to certify each cumulative update and each major release, and keep that history. Where the gap is long, reduce exposure instead of pretending it is closed: segment the system, restrict inbound and outbound paths, tighten administrative access and monitoring, and use network-level mitigations for the specific vulnerability where they exist. Where the operating system vendor offers extended support for an older release, price it and decide consciously rather than drifting past end of support. Bring the certification history to contract renewal, where it carries more weight than a support ticket.

Exceptions with compensating controls and expiry

An exception is a written decision, not a gap. Each record should contain the system and business owner, the specific patch or version being deferred, the reason, an assessment of exposure that accounts for whether the vulnerability is known to be exploited, the compensating controls in place, an expiry date, and the name of the person with authority to accept the risk. Keep them in one register with aging reported to leadership on a regular cycle.

Two rules keep the register honest. Exceptions expire and must be re-justified, never silently renewed. And every exception names a path out: a vendor certification date, an upgrade project, or a replacement.

Answering the auditor or the insurer

Auditors and carriers rarely demand that nothing be behind. They ask whether the deferral was decided, documented, and mitigated. Have ready: the policy with its ring definitions and timelines, the window calendar with operational sign-off, deployment evidence from your patching tools, and the exception register.

Frameworks including the CIS Controls and NIST guidance on patch management planning and flaw remediation describe this risk-based approach, and the federal catalog of known exploited vulnerabilities is a useful prioritization input even for agencies not bound by federal directives. Criminal justice, health, and utility data carry their own requirements. These documents are revised periodically, so confirm current versions with the issuing source or your counsel before citing a specific control to an auditor.

What to ask vendors and put in the contract

• Certification commitment. A stated maximum interval between an operating system vendor's release and the vendor's certified support, in the contract rather than in a sales conversation.
• Support posture. Whether applying uncertified security updates voids support, and what the emergency path is for a vulnerability under active exploitation.
• Notification. Advance notice of security fixes to their own product, with severity and required downtime.
• Non-production instance. Licensing and support for a test environment, without which ring promotion is guesswork.
• Window support. Vendor staff on call during your maintenance windows, with rollback commitments and defined restoration times.
• Component visibility. A software bill of materials or component list where the vendor can provide one, so you can answer questions about third-party libraries.

How to start

Inventory what is in scope and assign every system to a ring with a named operational owner. Publish the window calendar and get it signed. Run one full cycle through the rings and record what broke. Then open the exception register and move every informal skip into it, with a control and a date. The first register will be uncomfortably long. That is the point.

HQT works with state and local agencies on systems engineering and cybersecurity practices, including patch and vulnerability management for continuously operating systems.

Frequently asked questions