Patch Management Pack — Guide
- Version 1.2
- Updated
- 8 documents
- Word, Excel
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.
| Priority (vulnerability pack) | Typical case | Deadline | Route |
|---|---|---|---|
| Priority 1 | Exploited, on an internet-facing or Critical system; or public exploit code for a High or Critical flaw on an internet-facing system | Mitigate within 72 hours; fix within 7 days | Emergency |
| Priority 2 | Exploited on an internal system; Critical or High severity on an internet-facing system | 14 days | Monthly cycle, or expedited if the cycle would be late |
| Priority 3 | Critical or High severity on an internal system; Medium severity on an internet-facing system | 30 days | Monthly cycle |
| Priority 4 | Medium severity internally; Low anywhere | 90 days | Monthly cycle |
Deadlines run in calendar days from the clock start: the earlier of the day the scanner first finds the flaw and the day the vendor released the fix. A patch released on the release day is due from that day, and the days before a scan finds the gap are not given back. 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 vendors’ release day. Microsoft publishes on the second Tuesday of the month and the cycle is built on that day; count from another day if your main vendors release then. Releases are reviewed that day, and the next day the patches go to a pilot ring. The pilot is sized first to include every hardware model and business application in use, and then to about 5% of devices, so in a small estate it may be larger. After two working days without a rollback, an early ring of about 25% follows, then everyone else. Those two days are short: NIST SP 800-40 Rev 4 describes a first round that lasts a few days and a second of early adopters that tries updates for a few weeks. The pack compresses them because a Priority 2 patch is due 14 days after release. Servers go in two windows, with the halves of each redundant pair in different ones. Restarts are forced thirteen 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 two days after the 22 September deadline. The day 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. Of the 12 Priority 1 and 2 findings closed, 8 were in time: 2 of 2 at Priority 1 and 6 of 10 at Priority 2. The 18 devices still missing September’s update are chased by name before their 8 October deadline.
Start with these three
- Patch Management Standard: the nineteen rules, the deadlines, the rings and who may approve a deferral.
- Monthly Patch Cycle Operating Procedure: each step, on a fixed day after release.
- Emergency Out-of-Band Patching Procedure: what to do in the first hours after an exploited flaw is announced.
Your first month
| When | What to do | You’re done when |
|---|---|---|
| Week 1 | Give every system a patch owner, an asset class and a ring or server group. | No system in the inventory is left without one. |
| Week 2 | Choose the pilot ring and agree a monthly window with each system owner. | Every server and appliance has a window inside a Priority 2 deadline. |
| Week 3 | List every system within twelve months of the end of vendor support, or past it. | Each one has an owner, an end date and a plan. |
| Week 4 | Run the first cycle and verify it with a scan. | The straggler list names every device still missing the update. |
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 (a Priority 1 or 2 ring is done only when every device is verified);
- deadline adherence, as the vulnerability pack counts it, for Priority 1 and Priority 2 on their own, with the findings still open and those under a deferral beside it;
- systems past vendor support, counted whether or not each has an exception, with whether it has an exception and a retirement date;
- patch deferrals past their expiry.
Everything in the pack
- Word
Patch Management Standard
The rules: deadlines, testing, rings, windows and deferrals
- Word
Monthly Patch Cycle Operating Procedure
The cycle from release review to report
- Excel
Patch Deployment Ring & Maintenance Window Plan
Rings, server groups, windows and rollback criteria
- Word
Emergency Out-of-Band Patching Procedure
Exploited flaws: mitigate, test, deploy, verify
- Excel
Patch Deployment Verification Checklist
Installed, restarted, service checked, confirmed by scan
- Excel
End-of-Life Software & Unsupported System Register
Systems past or near the end of support, and the plan for each
- Excel
Patch Compliance Dashboard
The monthly measures, with trend and status
- Word
Patch Deferral Request Form
The request that feeds the exception register
No document matches those words.
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).
- Cyber Resilience Act: Article 14, for manufacturers of products with digital elements (applies from 11 September 2026).