Patch Management Pack — Guide

Patch Management

Many breaches use a weakness the vendor fixed months earlier. Patching fails for ordinary reasons: nobody tests, a server cannot be restarted, a supplier has not certified the update, or a laptop never connects. This pack gives a small IT team a fixed monthly routine, a fast route for the patches that cannot wait, and a recorded decision for the ones that must.

Is this for you?

This pack is for you if:

• patching happens when someone remembers, and nobody can say which devices missed last month’s updates;
• a few servers are never patched because “they can’t be rebooted”;
• you found out about an exploited flaw from the news, not from a process;
• some systems run software the vendor stopped supporting years ago.

Who does what

The vulnerability management pack finds weaknesses and decides how urgent each one is. This pack delivers the vendor’s fix. It never sets its own deadline: a patch is due when the vulnerability it fixes is due.

Deadlines run in calendar days from first detection. Updates with no security content have this pack’s own timetable: within 90 days of release.

How the monthly cycle runs

The cycle counts from the vendor’s release day, the second Tuesday of the month for the largest vendors. Releases are reviewed that day, and the next day the patches go to a pilot ring of about 5% of devices covering every hardware model and business application. After two working days without a rollback, an early ring of about 25% follows, then everyone else. Servers go in two windows, with the halves of each redundant pair in different ones. Restarts are forced fourteen days after release, and nothing counts as done until a scan confirms it.

How it runs in practice

Take a distributor with 900 staff, three warehouses and an online ordering service. It approved its patch standard on 3 September 2026, and September was its first cycle under it: 640 devices in three rings, 11 servers in three groups, and a firewall pair.

The warehouse management system’s database runs on one server, and dispatch runs round the clock, so its only window is Sunday at 2am. Its supplier must certify each update first, and certified September’s a day after the 23 September deadline. Two days before the deadline the system owner asked for a deferral, with the vulnerable service already reachable only from the application server and the backup service, tested. The IT Operations Manager runs the patching, so cannot approve it; the Head of Information Security did, to 29 September. The update went in on the 27th and was confirmed by scan the next day.

A fix to the ordering platform’s search component, due on 16 September, went in a week late, with no deferral asked for: that team is two engineers short. Then on 24 September the platform’s vendor released a fix for a flaw being exploited. Within four hours of finding it applied, the hosting provider had a firewall rule blocking it, and the tested patch went in early on Sunday the 27th. Exploit code was published on the 28th; on the 29th the firewall blocked the first attempts against an already patched platform.

The new end-of-life register found a storage appliance out of support since 2024. It now sits on its own network segment, under an approved exception until it is retired on 30 November.

At 30 September, 639 of 657 devices, servers and appliances have every patch due to their ring. Seven of nine deployments met their deadline. The 18 devices still missing September’s update are chased by name before their 9 October deadline.

Start with these three

1. Patch Management Standard: the nineteen rules, the deadlines, the rings and who may approve a deferral.
2. Monthly Patch Cycle Operating Procedure: each step, on a fixed day after release.
3. Emergency Out-of-Band Patching Procedure: what to do in the first hours after an exploited flaw is announced.

Your first month

When a patch cannot go in on time

A deferral is an exception under the exception and waiver pack. It is requested before the deadline passes, needs a tested compensating control and a date the patch will go in, and is scored. A Low or Medium score is approved by the control owner or the Head of Information Security, and a High score by the Head of Information Security with the accountable executive. Each runs for 90 days at most. A Critical score goes to the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management. It runs for 30 days at most. A Priority 1 deferral also needs the 72-hour mitigation in place first, and the approver of the vulnerability standard. Being busy, having no test system or missing the window are never reasons.

What to report

Report these every month to the security and IT leadership team:

• patch coverage, by asset class;
• patch latency, by priority and ring, against each deadline;
• deadline adherence, as the vulnerability pack counts it;
• systems past vendor support, and whether each has an exception and a retirement date;
• patch deferrals past their expiry.

Everything in the pack

Adapting it

• Small team: let device management run the rings and force the restart. Keep people for the servers, the appliances and whatever fails.
• IT run by an outside provider: put the cycle’s dates and the deadlines in the contract, and ask for the management tool’s report and the scan, never just “done”.
• Cloud and software services: the provider patches its platform under the vulnerability clause of the third-party security pack. You patch your side: clients, agents and settings.
• A sign it was used against you: stop and report an incident under the incident management pack. Patching a compromised system does not remove an attacker who is already in.
• Financial entity: DORA’s technical standards ask for patch procedures with emergency procedures, testing, deadlines and escalation when deadlines cannot be met. This pack is written to that level.

Framework references

• ISO/IEC 27001:2022: Annex A 8.8.
• NIST CSF 2.0: PR.PS-02.
• NIS2: Article 21(2)(e).
• DORA: Article 9(4)(f).