How do we run a reliable monthly patch cycle with a small IT team?

Start

We need patching to happen every month without heroics

The cycle works because nobody decides each month when to start: the same steps run on the same days, counted from the vendor's release day. Put the year's dates in the shared calendar now, with system owners invited to their windows, and name a deputy who has run the cycle once. The pack counts from the second Tuesday; a date on a public holiday moves to the working day before.

• Then: Five days before: pilot list, windows, supplier dates, stragglers

Step

Five days before: pilot list, windows, supplier dates, stragglers

Check the pilot ring still covers every hardware model and business application. Book the month's windows with each system owner. Ask suppliers who must certify patches for their date, and if it falls after the window, plan an earlier window inside the deadline or start a deferral now. Clear last month's stragglers, and chase devices that have not reported to the management tool in 14 days.

• Then: Review every release within 1 working day, system by system

Step

Review every release within 1 working day, system by system

Collect every release that applies to an in-scope system, including those made between cycles. For each fix, record whether it is exploited, whether the system is internet-facing, its severity and the system's criticality, taking the last two from the inventory, never memory. Rate each system, not the release: one update can carry two priorities and two deadlines. Where exposure or criticality is not known, the more urgent value applies. Unknown exploitation counts as not known exploited, and is checked again at the next weekly triage.

• Then: Is the fix Priority 1 on any system?

Decision

Is the fix Priority 1 on any system?

Priority 1 is an exploited flaw on an internet-facing or Critical system. It never waits for the cycle. Tell the Head of Information Security at once and start the emergency procedure within 4 hours of the advisory, for those systems. The same release can stay in the cycle for the others.

• Yes: Take it out of the cycle: the emergency route
• No: Would the cycle verify it only after the system's deadline?

Outcome

Take it out of the cycle: the emergency route

In the pack's defaults a Priority 1 patch is mitigated within 72 hours of first detection and installed within 7 days, under an emergency change that the person deploying it never approves. The emergency procedure sets the steps and their target times.

Decision

Would the cycle verify it only after the system's deadline?

Compare the date the cycle would have the patch installed and verified on that system, its window plus 1 working day, with the system's deadline. The decision is mechanical: nobody chooses the cycle for a patch the cycle would verify late. A server pair split across two windows is verified only after the second one, so check pairs here, not in the window.

• Yes, or not known: Expedite it: the next window inside its deadline, or an extra one
• No: Approve the month's standard change and start the pilot

Outcome

Expedite it: the next window inside its deadline, or an extra one

The expedited route uses an earlier window this cycle, another system's window the owner can share, or an extra window, as a normal change the Head of IT approves within 1 working day. A Priority 2 fix released in the week before a release day will almost always go this way.

Step

Approve the month's standard change and start the pilot

The cycle is a standard change approved once a year; each month the Head of IT approves that month's list of patches, rings, windows and rollback criteria. Take patches only from the vendor or its update service and check their integrity. Snapshot the test servers and confirm each patch can be rolled back. Then deploy to the pilot ring and test servers, and tell pilot users how to report a fault.

• Then: After 2 working days, is any rollback criterion met?

Decision

After 2 working days, is any rollback criterion met?

The pack's criteria: a pilot device fails to start, connect or sign in; a business application on the test list fails; more than 2% of a ring's devices fail to install after two attempts; a server's service check fails 30 minutes after restart and cannot be fixed in the window; or the vendor withdraws the patch or publishes a known issue that affects you. Any one is a no-go.

• Yes: no-go: Stop, roll back, and tell security the same day
• No: go: Early ring, then the broad ring and Window A

Step

Stop, roll back, and tell security the same day

Stop the next ring or group at once; nothing further goes out until the cause is known. Uninstall the patch or restore the snapshot taken before it. Tell the Head of Information Security the same day, because the vulnerability is open again. Then re-plan the patch inside its deadline with the vendor's fix or workaround.

• Then: Can it still be installed and verified before its deadline?

Step

Early ring, then the broad ring and Window A

The early ring goes out through device management; more than 2% failing after two attempts stops the broad ring. When it passes, release to the broad ring, with users able to postpone the restart only until the forced restart date. The same day, Window A patches the first server group and its appliance pairs, one member at a time, with a service check within 30 minutes of each restart. With fewer than 50 end-user devices, the pack allows two rings: the full pilot, then every other device.

• Then: Window B, then the forced restart

Step

Window B, then the forced restart

Window B patches the second server group, the other member of every server pair, and systems with a Sunday change window. Where a supplier has not certified the patch, do not install it: move it to the next window inside its deadline, or a deferral should already have been requested. On the forced restart date, device management restarts every device still waiting; those that do not restart start the straggler list.

• Then: Verify: installed, restarted, service checked, rescanned

Step

Verify: installed, restarted, service checked, rescanned

A patch waiting for a restart is not installed. A deployment is complete only when the management tool reports the patch, no restart is pending, the system owner or a health check confirms the service, and a targeted rescan no longer finds the flaw. Ask for rescans the working day after each window, so each patch is verified within 1 working day, then tell the vulnerability triage so the findings close.

• Then: Is any asset still missing the patch?

Decision

Is any asset still missing the patch?

List every asset still missing a patch by name, with the reason and its deadline: offline, failed to install or not restarted. Laptops of staff on leave are typical. Each keeps its own deadline, which may be later than the servers'.

• Yes: Can it still be installed and verified before its deadline?
• No: Report exceptions, not activity, to the leadership team

Decision

Can it still be installed and verified before its deadline?

Moving a patch to a later window still inside its deadline is not a deferral and needs no form: reschedule it by name with a date, chase it to a clean rescan, and carry it into next month's preparation. Only a date after the deadline needs a deferral. If you cannot tell whether a window will make it in time, treat the answer as no and decide now, while a deferral can still be requested.

• Yes: reschedule it: Report exceptions, not activity, to the leadership team
• No, or not known: Is there an accepted reason to defer it?

Decision

Is there an accepted reason to defer it?

The pack accepts five reasons: the patch failed a test with a confirmed fault or the vendor withdrew it; the supplier has not certified it; the system cannot restart inside the deadline without stopping a critical service and nothing else works in time; no patch exists; or the system is being retired before the next window. A busy team, no test system and a missed window are never reasons.

• Yes: System owner requests a deferral before the deadline
• No: No deferral: install it, or report it overdue

Outcome

System owner requests a deferral before the deadline

The system owner requests it on the deferral form before the deadline passes, with a tested compensating control and a date the patch will go in. It is decided as an exception under your exception standard and recorded in its one register.

Outcome

No deferral: install it, or report it overdue

Without an accepted reason, install it by the deadline. If it misses, it is reported as overdue and escalated as your vulnerability standard sets: in the pack's defaults, to the asset owner's manager the day after the deadline, and to the standard's approver if still open 14 days after that. A team that is short of people is escalated to the Head of IT for the people, not deferred.

Step

Report exceptions, not activity, to the leadership team

Each month the security and IT leadership team sees coverage, latency against deadline, deadline adherence, systems past support and expired deferrals. Write by name what missed or will miss its deadline, and why; everything that went to plan is one line. A measure outside tolerance goes to the next executive committee with its plan.

• Then: The month's patches are in, proved by a scan, and reported

Outcome

The month's patches are in, proved by a scan, and reported

Keep the calendar, the release review record, the pilot go or no-go and the rescans: the pack names them as what an auditor asks for. In the pack's worked example the cycle met every deadline it controlled; the misses came from a supplier's certification date and a team short of staff. Ask suppliers for their dates at preparation, and start any deferral then.