Monthly Patch Cycle Operating Procedure
Runs the monthly cycle from release review through testing, deployment, verification and reporting.
Available soon
- Format
- Word
- Size
- 71 KB
- Length
- 23 pages
- Version
- 1.1
- Updated
What's inside
What changed
- 1.1
Unknown exploitation evidence counts as not known exploited and is checked again at the next weekly triage, as the P01 model says; only exposure, severity and criticality default to the more urgent value.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure runs the monthly patch cycle: the same steps, on the same days, every month, from the review of the vendors' releases to the report to the leadership team. It is the working routine behind the Patch Management Standard: the standard states the rules (PM-01 to PM-19); this procedure says who does what, in which order and on which day.
Its aim is that a patch released on the release day reaches every in-scope system and is proved by a scan before its deadline, with the least effort from a small team. The routine that takes each month's releases from review through testing, deployment in rings and windows, and verification, on fixed days counted from the release day.
Scope
This procedure applies to:
- every security patch and every update with no security content that takes the monthly cycle route (RT-C);
- every asset class the organisation patches itself: end-user devices, servers, network and security appliances and business applications;
- the checks the organisation makes of services a provider patches (AC-5), each month;
- everyone in the roles below, including providers who deploy for us.
It does not cover patches that cannot wait for the cycle. A Priority 1 patch, and any patch the cycle would not have installed and verified by its deadline, leaves the cycle at the release review and goes to the Emergency Out-of-Band Patching Procedure. Nor does it cover how deferrals are decided: the Patch Deferral Request Form and the exception standard do that. This procedure says when to start one.
Roles
Role | What they do in this procedure |
|---|---|
IT Operations Manager [[e.g. IT Operations Manager]] | Runs every step; chairs the release review; decides go or no-go; keeps the straggler list; writes the monthly report. |
Head of IT [[e.g. Head of IT]] | Approves the month's standard change (CY-03) and any extra window; receives escalations; presents the report with the coordinator. |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Rates exploited flaws with the coordinator at the release review; is told of every Priority 1 and every rollback the same day; decides deferrals as the exception standard sets. |
System owner [[the business owner of each system or service]] | Agrees the windows; checks the service after each window; requests a deferral for their system when a patch will miss its deadline. |
Application team [[e.g. the ordering platform team]] | Tests and patches their applications and components in the application's own window, on the same deadlines. |
Service provider [[e.g. managed IT provider]] | Deploys where the contract says so, on the cycle's dates, and sends the management tool's report and the scan. |
Pilot users [[2]] people from each department and site | Use the pilot devices for their normal work and report anything that stops working, the same day. |
Guidance — delete before approval
Name a deputy for the IT Operations Manager who has run the cycle at least once (ST-5). The cycle's dates do not move for a holiday: the deputy runs it.
Triggers and inputs
When the cycle runs
Every month, counted from the release day. The day a vendor publishes its regular patches. For the largest operating system and office software vendors it is the second Tuesday of the month; other vendors release monthly, quarterly or whenever a fix is ready. If your main vendors release on another day, count from that day instead and keep the offsets.
The offsets are chosen so that a Priority 2 patch released on the release day can be installed and verified before its deadline (PM-07). It is first detected about 1 day after release and due 14 days later, 15 days after the release day. Window B, the cycle's last window, is 12 days after the release day, and verification takes 1 working day more.
The cycle calendar
The dates the default offsets give, to the next review of this template. Move a date that falls on a public holiday to the working day before, never after.
Month | Release day | Pilot go or no-go | Broad ring and Window A | Window B | Forced restart | Verify and chase |
|---|---|---|---|---|---|---|
October 2026 | 13 Oct 2026 | 16 Oct 2026 | 21 Oct 2026 | 25 Oct 2026 | 27 Oct 2026 | 28 Oct 2026 |
November 2026 | 10 Nov 2026 | 13 Nov 2026 | 18 Nov 2026 | 22 Nov 2026 | 24 Nov 2026 | 25 Nov 2026 |
December 2026 | 8 Dec 2026 | 11 Dec 2026 | 16 Dec 2026 | 20 Dec 2026 | 22 Dec 2026 | 23 Dec 2026 |
January 2027 | 12 Jan 2027 | 15 Jan 2027 | 20 Jan 2027 | 24 Jan 2027 | 26 Jan 2027 | 27 Jan 2027 |
February 2027 | 9 Feb 2027 | 12 Feb 2027 | 17 Feb 2027 | 21 Feb 2027 | 23 Feb 2027 | 24 Feb 2027 |
March 2027 | 9 Mar 2027 | 12 Mar 2027 | 17 Mar 2027 | 21 Mar 2027 | 23 Mar 2027 | 24 Mar 2027 |
April 2027 | 13 Apr 2027 | 16 Apr 2027 | 21 Apr 2027 | 25 Apr 2027 | 27 Apr 2027 | 28 Apr 2027 |
May 2027 | 11 May 2027 | 14 May 2027 | 19 May 2027 | 23 May 2027 | 25 May 2027 | 26 May 2027 |
June 2027 | 8 Jun 2027 | 11 Jun 2027 | 16 Jun 2027 | 20 Jun 2027 | 22 Jun 2027 | 23 Jun 2027 |
July 2027 | 13 Jul 2027 | 16 Jul 2027 | 21 Jul 2027 | 25 Jul 2027 | 27 Jul 2027 | 28 Jul 2027 |
August 2027 | 10 Aug 2027 | 13 Aug 2027 | 18 Aug 2027 | 22 Aug 2027 | 24 Aug 2027 | 25 Aug 2027 |
September 2027 | 14 Sep 2027 | 17 Sep 2027 | 22 Sep 2027 | 26 Sep 2027 | 28 Sep 2027 | 29 Sep 2027 |
Inputs
Input | Where it comes from | Used at |
|---|---|---|
Asset inventory with patch owner, asset class, ring or group and window (PM-01) | [[Asset inventory / device management tool]] | CY-01, CY-02 |
The ring and window plan, with each system owner's agreement | Patch Deployment Ring & Maintenance Window Plan | CY-01, CY-03 to CY-07 |
Vendors' advisories and release notes | [[Vendor security notification pages and mailing lists]] | CY-02 |
Lists of vulnerabilities known to be exploited | [[e.g. CISA Known Exploited Vulnerabilities catalogue; your threat intelligence source]] | CY-02 |
Open findings, with priority, first detection and deadline | [[Vulnerability remediation tracker]] | CY-02, CY-09 |
Suppliers' certification dates for systems they support | [[Supplier notices; the contract's certification clause]] | CY-01, CY-07 |
Last month's straggler list and open deferrals | [[Change record; exception register]] | CY-01 |
The end-of-life register | End-of-Life Software & Unsupported System Register | CY-02 (a release for a product near the end of support) |
The cycle at a glance
Each step's day is counted in calendar days from the release day. A day before the release day is preparation.
Step | Day | What happens | Who |
|---|---|---|---|
CY-01 Prepare | 5 days before release | Confirm the pilot list, book the windows with the system owners, ask suppliers who certify patches for their dates, and clear last month's stragglers. | IT Operations Manager |
CY-02 Review the releases | Release day | Read each vendor's advisory, rate each fix with the P01 model (exploited? internet-facing? severity? criticality?), and route it: monthly cycle, expedited or emergency (PM-03). | IT Operations Manager, with the Head of Information Security |
CY-03 Approve and start the pilot | Release day + 1 | Approve the month's pre-approved standard change, check the patches' integrity, and deploy to the pilot ring and the test servers (PM-04, PM-05). | Head of IT approves; IT operations deploy |
CY-04 Pilot go or no-go | Release day + 3 | After [[2]] working days, check the rollback criteria with the pilot users; go, or roll back and re-plan (PM-08). | IT Operations Manager |
CY-05 Early ring | Release day + 6 | Deploy to the early ring. | IT operations |
CY-06 Broad ring and Window A | Release day + 8 | Release to the broad ring, with users able to postpone the restart until the forced restart date; patch server group A and its appliance pairs in Window A. | IT operations; system owners check their services |
CY-07 Window B | Release day + 12 | Patch server group B, its appliances, and the systems with a Sunday change window whose supplier has certified the patch. | IT operations; suppliers where they must attend |
CY-08 Forced restart | Release day + 14 | Devices still waiting for a restart are restarted (PM-09). | Device management |
CY-09 Verify and chase | Release day + 15 | Confirm installation, restarts and service checks; ask for the targeted rescans (P01 VM-13); list every asset still missing a patch, reschedule it inside its deadline or request a deferral before the deadline passes (PM-10, PM-14). | IT Operations Manager |
CY-10 Report | After the cycle | The month's measures go to the security and IT leadership team in the monthly reporting cycle (PM-19, P11 RL-1). | IT Operations Manager |
Guidance — delete before approval
Put the whole year's dates in the shared calendar now, with the system owners invited to their windows. A cycle that has to be scheduled each month is the first thing to slip when the team is busy (ST-1).
Procedure steps
Each step below lists its actions in order, who does each, and what it produces. The output is the evidence that the step happened.
CY-01 Prepare: 5 days before the release day
Five days before the release day, the IT Operations Manager gets the month ready, so that nothing waits on a booking once the patches arrive.
Action | What to do | Who | Output |
|---|---|---|---|
1.1 | Check the pilot ring still covers every hardware model and every business application in use. Replace pilot users who have left or changed role. | IT Operations Manager | Pilot list, dated |
1.2 | Book this month's windows with each system owner, and put them in the change calendar. Confirm the dates of Window A and Window B from the release day. | IT Operations Manager; system owners | Windows booked |
1.3 | Ask each supplier who must certify patches (GR-6) for the date it will certify this month's updates. Where that date falls after the system's window, plan the next window inside the deadline now, or start a deferral request (PM-14). | IT Operations Manager | Certification dates; any early deferral request |
1.4 | Clear last month's stragglers: every asset on last month's straggler list is either patched and verified, or covered by an approved deferral. | IT Operations Manager | Straggler list closed or carried forward |
1.5 | Check the management tool reaches every in-scope device: devices that have not reported in [[14]] days are listed and chased now, not after the release. | IT operations | Not-reporting list |
CY-02 Review the releases: the release day
Every vendor release that applies to an in-scope system must be reviewed within [[1]] working day of its release: each fix rated with the P01 model and routed to the monthly cycle, the expedited route or the emergency route (PM-03). The review is the one decision point that changes a patch's route; every later step follows from it.
Action | What to do | Who | Output |
|---|---|---|---|
2.1 | Collect every vendor release since the last review that applies to an in-scope system, including releases made between cycles. | IT Operations Manager | List of releases |
2.2 | For each fix, record the four P01 inputs per system type: exploited, internet-facing, severity, criticality. Use the inventory for the last two, never memory. | IT Operations Manager | Release review record, inputs |
2.3 | Rate each system with the P01 model and work out its deadline from first detection. Where exposure, severity 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 (P01-A04). | IT Operations Manager, with the Head of Information Security | Priority and deadline per system |
2.4 | Route each fix (PM-03): Priority 1 to the emergency route now; a patch the cycle would not have installed and verified by its deadline to the expedited route; everything else to this cycle. | IT Operations Manager | Route per fix |
2.5 | Tell the Head of Information Security of every Priority 1 at once, and start the Emergency Out-of-Band Patching Procedure within [[4]] hours of the advisory. | IT Operations Manager | Emergency started |
2.6 | Note known issues the vendor lists, and any patch a supplier must certify. Finish the review within [[1]] working day of the release. | IT Operations Manager | Release review record, complete |
Record each fix and system type in the release review record, on the month's change:
Field | What to record |
|---|---|
Release | Vendor, product and the vendor's reference |
Released | The vendor's release date |
Applies to | The systems in the inventory running the affected product and version, by name or by ring |
Severity | The vendor's rating, or the CVSS base score where the vendor gives none |
Exploited? | Yes if the vendor, a known-exploited list or credible threat information reports attacks |
Internet-facing? Criticality? | From the inventory, per system |
P01 priority | The model's answer, per system |
First detected | The date the scanner first found it on each system, or the expected date |
Deadline | First detection plus the priority's days (P01 VM-08) |
Cycle verified date | The ring's or the group's window this month, plus [[1]] working day to verify it (PM-10) |
Route | RT-C, RT-X or RT-E: RT-X where the cycle verified date falls after the deadline |
Notes | Known issues the vendor lists; supplier certification needed; restart needed |
Guidance — delete before approval
Rate each system, not the release. The same monthly update was Priority 3 on most of the distributor's devices and Priority 2 on its domain controllers and web servers, so it had two deadlines. The cycle meets the earlier one, and the verification step checks each system against its own.
CY-03 Approve and start the pilot: release day + 1
Patches must come only from the vendor or the vendor's own update service, be checked for integrity before they are deployed, and be deployed with the organisation's management tools wherever the product allows (PM-04). Every patch must be installed on the pilot ring, or on a test server or test copy for servers and applications, and observed for [[2]] working days before it goes wider. An emergency patch is tested for [[2]] hours on one system (PM-05).
Action | What to do | Who | Output |
|---|---|---|---|
3.1 | Approve the month's pre-approved standard change: the list of patches, the rings, the windows and the rollback criteria. Anything outside the standard change, such as an extra window, needs a normal change. | Head of IT | Standard change for the month |
3.2 | Download the patches from the vendor or its update service only, and check their integrity: the management tool's signature check, or the vendor's published checksums (PM-04). | IT operations | Integrity checked |
3.3 | Take snapshots or backups of the test servers, and confirm the rollback for each patch (some cumulative updates cannot be uninstalled). | IT operations | Rollback ready |
3.4 | Deploy to the pilot ring and the test servers. Tell the pilot users what was deployed and how to report a problem. | IT operations | Pilot deployed; pilot users told |
CY-04 Pilot go or no-go: release day + 3
Every ring and server group must have rollback criteria agreed before deployment. A rollback stops the next ring until the cause is known, and the patch is re-planned inside its deadline or deferred under PM-14 (PM-08). Any one criterion below stops the cycle for that patch.
Action | What to do | Who | Output |
|---|---|---|---|
4.1 | Collect the pilot users' reports and the management tool's failure list, and check each rollback criterion (RB-1 to RB-5). | IT Operations Manager | Rollback criteria checked |
4.2 | Check that the test servers' services start and do their main task, and that the business applications on the pilot test list work. | IT operations; application teams | Test results |
4.3 | Decide: go, if no criterion is met; or roll back the affected devices, stop the cycle for that patch, and re-plan it inside its deadline (PM-08). | IT Operations Manager | Go or no-go, recorded with the reason |
Criterion | What triggers it |
|---|---|
RB-1 | Any pilot device fails to start, loses its network connection or cannot sign in after the patch. |
RB-2 | A business application on the pilot test list fails to start or to do its main task. |
RB-3 | More than [[2]]% of a ring's devices fail to install the patch after two attempts. |
RB-4 | A server's service check fails [[30]] minutes after the restart and cannot be fixed inside the window. |
RB-5 | The vendor withdraws or replaces the patch, or publishes a known issue that affects a system or application in use. |
CY-05 Early ring: release day + 6
End-user devices must be patched in three rings, pilot, early and broad, each starting only when the one before has passed its rollback criteria. Servers are patched by group, and the two members of a redundant server pair never in the same window. The two members of a high-availability appliance pair are patched in the same window, one at a time (GR-4) (PM-06).
Action | What to do | Who | Output |
|---|---|---|---|
5.1 | Release the patches to the early ring through device management. | IT operations | Early ring deployed |
5.2 | Watch the failure rate: more than [[2]]% of the ring failing after two attempts stops the broad ring (RB-3). | IT operations | Failure rate |
CY-06 Broad ring and Window A: release day + 8
The broad ring and the first window start on the same day: the Wednesday of the week after the release day, [[20:00 to 23:00]].
Action | What to do | Who | Output |
|---|---|---|---|
6.1 | If the early ring has passed its rollback criteria, release to the broad ring. Users may postpone the restart until the forced restart date and no later (PM-09). | IT operations | Broad ring deployed |
6.2 | In Window A: take snapshots, patch server group A and its appliance pairs (both members, one at a time, GR-4), restart, and run each service check within [[30]] minutes of the restart (RB-4). | IT operations; system owners | Window A complete, service checks recorded |
6.3 | Ask the system owner of each service in the window to confirm it works. A failed check that cannot be fixed inside the window is rolled back. | System owners | Owners' confirmations |
CY-07 Window B: release day + 12
Window B is the Sunday after Window A, [[02:00 to 06:00]]. It holds server group B, with the other member of every server pair, the appliances whose group uses it, and the systems with a Sunday change window.
Action | What to do | Who | Output |
|---|---|---|---|
7.1 | In Window B: patch server group B, its appliances, and the systems with a Sunday change window whose supplier has certified the patch. One member of each redundant server pair is always running, because the other was patched in Window A (GR-2). | IT operations; suppliers where they must attend | Window B complete |
7.2 | Where a supplier has not certified the patch, do not install it. Move it to the next window inside its deadline; if there is none, a deferral must already have been requested (PM-14). | IT Operations Manager; system owner | Moved, or deferral reference |
7.3 | Run and record the service checks, as in Window A. | IT operations; system owners | Service checks recorded |
Guidance — delete before approval
A server pair is split across the two windows (GR-2), so its second member is verified only after Window B. Where a release's deadline falls before that, the patch is expedited (PM-12). An appliance pair is never split: both members go in their group's window, one at a time (GR-4), as the distributor's firewalls did in Window A in September. Check this at the release review, not in the window.
CY-08 Forced restart: release day + 14
A patch that needs a restart is installed only once the system has restarted. Users may postpone a restart until the cycle's forced restart date, [[14]] days after the release day, and no later (PM-09).
Action | What to do | Who | Output |
|---|---|---|---|
8.1 | Device management restarts every device still waiting for a restart, [[14]] days after the release day. | Device management | Restart report |
8.2 | List devices that did not restart, or have not connected since the patch was released. They are the start of the straggler list. | IT operations | Not-restarted list |
CY-09 Verify and chase: release day + 15
A deployment is complete only when the patch is confirmed installed, the system has restarted, its owner has checked the service, and a scan confirms the vulnerability is gone (P01 VM-13). Every asset still missing the patch is listed and rescheduled inside its deadline, or deferred (PM-10).
Action | What to do | Who | Output |
|---|---|---|---|
9.1 | Run the verification checks VF-01 to VF-04 on every ring and group: installed, restarted, service checked, and a targeted rescan (PM-10). Ask for the rescans the working day after each window, so each patch is verified within [[1]] working day of deployment. | IT Operations Manager | Verification record |
9.2 | Build the straggler list (VF-05): every asset still missing a patch, by name, with the reason and its deadline. | IT Operations Manager | Straggler list |
9.3 | For each straggler, reschedule it inside its deadline, or, if it cannot be installed by then, have its system owner request a deferral before the deadline passes (PM-14, Patch Deferral Request Form). | IT Operations Manager; system owners | Each straggler rescheduled or deferral requested |
9.4 | Tell the vulnerability triage that the patched findings are verified, so P01 closes them on the scan (VM-13). | IT Operations Manager | Findings closed in P01 |
Check | How | Evidence | |
|---|---|---|---|
VF-01 | Installed | The management tool reports the patch, or the version or build number it sets, on every asset in the ring or group. | Management tool report, dated |
VF-02 | Restarted | No restart is pending, and the system has started since the patch was installed. | Restart status in the same report |
VF-03 | Service restored | The system owner, or the service's own health check, confirms the service starts and does its main task within [[30]] minutes of the restart. | Owner's confirmation or health check result on the change |
VF-04 | Scanner confirms | A targeted rescan no longer finds the vulnerability, and P01 closes the finding (VM-13). | Scan report, attached to the finding |
VF-05 | Gaps handled | Every asset still missing the patch is listed with the reason, and rescheduled inside its deadline or deferred before the deadline passes (PM-14). | Straggler list; deferral reference where one was needed |
CY-10 Report: after verification
The headline measures must be reported monthly to the security and IT leadership team, and any measure outside tolerance to the next executive committee with its plan. Any other departure from this standard is a P02 exception, and a Critical exception is approved by the board or its equivalent (PM-19).
Action | What to do | Who | Output |
|---|---|---|---|
10.1 | Calculate the headline measures for the month in the Patch Compliance Dashboard: coverage, latency against deadline, deadline adherence, systems past support and expired deferrals. | IT Operations Manager | Monthly measures |
10.2 | Write the exceptions: what missed or will miss its deadline, and why, by name. Everything that went to plan is one line. | IT Operations Manager | Monthly report |
10.3 | Present the report to the security and IT leadership team. Any measure outside tolerance goes to the next executive committee with its plan (PM-19). | IT Operations Manager; Head of IT | Minutes; escalation where needed |
Decision points
Which route does a patch take?
At the release review (CY-02), for each fix on each system. Ask in order and stop at the first yes.
Question | Yes | No |
|---|---|---|
Is it Priority 1 on any system? | Emergency (RT-E) for those systems: start the Emergency Out-of-Band Patching Procedure now. An emergency change, approved by the Head of IT or the on-call approver, never by the person deploying it. | Next question. |
Would the cycle have it installed and verified only after the system's deadline? | Expedited (RT-X): the next window inside its deadline, or an extra window (PM-12). A normal change, approved by the Head of IT within [[1]] working day. | Monthly cycle (RT-C): the month's pre-approved standard change. |
Go or no-go after the pilot
Question | Yes | No |
|---|---|---|
Is any rollback criterion RB-1 to RB-5 met? | No-go. Stop the next ring or group at once; nothing further is deployed until the cause is known. Roll back the affected systems inside the window: uninstall the patch, or restore the snapshot or backup taken before it. Tell the Head of Information Security the same day, because the vulnerability is open again. Re-plan the patch inside its P01 deadline, with the vendor's fix or workaround; if that cannot be done, request a deferral before the deadline passes (PM-14). | Go. Release to the early ring on its day. |
A system cannot be patched in its window
The supplier has not certified the patch, the service cannot stop, or the window was lost. A system that cannot be restarted to patch must be handled in this order: patch one node at a time behind its redundancy; agree a window inside the deadline; use the vendor's live patching where it is supported; and only then mitigate and defer under PM-14. The lasting fix is put on a plan with a date (PM-16).
Option | How | |
|---|---|---|
RO-1 | Use the redundancy | Patch one node at a time: move the load, patch and restart, check, then swap. Most services that cannot stop already run on two nodes. |
RO-2 | Agree a window inside the deadline | A short planned outage at the quietest hour, agreed with the system owner, usually costs less than an exception. Book it at the release review. |
RO-3 | Live patching | Where the vendor supports it for that system, apply the fixes it can without a restart. The rest wait for the next window, and the system is not verified until they are in. |
RO-4 | Mitigate and defer | Block the vulnerable service, restrict who can reach the system and watch it more closely, test that, then request a deferral to the next window before the deadline passes (PM-14). |
RO-5 | Fix the cause | Put a lasting answer on a plan with a date: a second node, a standing monthly window, or a supplier who certifies patches in time. |
An asset is still missing the patch at verification
Question | Yes | No |
|---|---|---|
Can it be installed and verified before its deadline? | Reschedule it, by name, with a date. Chase it until the rescan is clean. | Next question. |
Is there an accepted reason (PM-15)? | The system owner requests a deferral on the Patch Deferral Request Form before the deadline passes (PM-14). | Install it anyway, or report it overdue: it is escalated as the Vulnerability & Exposure Management Standard sets (VM-19). |
Guidance — delete before approval
Moving a patch to a later window that is still inside its deadline is not a deferral and needs no form. Only a date after the deadline does.
Outside the cycle
Two kinds of patch leave the cycle at the release review. A Priority 1 patch takes the emergency route: mitigate within 72 hours and patch within 7 days of first detection, with an emergency change and a short test. A patch the cycle would not have installed and verified by its deadline takes the expedited route: the next window inside its deadline, or an extra one. Both are run under the Emergency Out-of-Band Patching Procedure, and both are reported with the month's measures.
A release made between cycles, such as a browser or firewall fix, is reviewed within the same review time as a release-day release, and routed the same way. If it is Priority 3 or 4, it usually joins the next cycle.
Each month the IT Operations Manager also reads the security notices of every provider that patches a service for us (AC-5, PM-13), and patches our own side: clients, agents and connectors, in the cycle.
Outputs and records
Output | Step | Held in |
|---|---|---|
Pilot list, booked windows, supplier certification dates | CY-01 | [[Change calendar; ring and window plan]] |
Release review record: each fix, its rating, deadline and route | CY-02 | [[Month's change record]] |
Approved standard change, with integrity checks | CY-03 | [[Change management system]] |
Pilot go or no-go, with the criteria checked and the reason | CY-04 | [[Month's change record]] |
Window records, with each service check and the owner's confirmation | CY-06, CY-07 | [[Month's change record]] |
Restart report | CY-08 | [[Device management export]] |
Verification record, rescans and straggler list | CY-09 | [[Month's change record]]; Patch Deployment Verification Checklist |
Deferral requests | CY-01, CY-07, CY-09 | Patch Deferral Request Form; the exception register |
Monthly report and minutes | CY-10 | Patch Compliance Dashboard; [[leadership team minutes]] |
Timing targets
Activity | Target | Basis |
|---|---|---|
Release reviewed and every fix routed | Within [[1]] working day of the release | PM-03 |
Pilot ring and test servers deployed | Release day + 1 | CY-03 |
Pilot observed before going wider | [[2]] working days | PM-05 |
Early ring deployed | Release day + 6 | CY-05 |
Broad ring and Window A | Release day + 8 | CY-06 |
Window B | Release day + 12 | CY-07 |
Forced restart | [[Release day + 14]] | PM-09 |
Each deployment verified | Within [[1]] working day of its window | PM-10 |
Every security patch installed and verified | By its P01 deadline | PM-02 |
Deferral requested where a patch will miss its deadline | Before the deadline passes | PM-14 |
Monthly report | To the security and IT leadership team each month | PM-19 |
Escalation
When | Who is told | By when | Basis |
|---|---|---|---|
A rollback starts | Head of Information Security | The same day | PM-08 |
A Priority 2 patch is not verified by day 10 | The asset owner's manager | Day 10 | P01 priority table |
A patch passes its deadline with no approved deferral | The asset owner's manager; reported as overdue | The day after the deadline | VM-19 |
Still open after a further period | The approver of the Vulnerability & Exposure Management Standard | 14 days after that | VM-19 |
A provider misses a date or sends no evidence | Head of IT | The next working day | PM-13 |
A measure is outside tolerance | Executive committee | The next meeting | PM-19 |
Keeping it reliable with a small team
Practice | How | |
|---|---|---|
ST-1 | Fix the calendar once | The same steps on the same days every month, counted from the release day. Nobody decides each month when to start. |
ST-2 | Pre-approve the routine change | The monthly cycle is a standard change approved once a year. Only emergencies and exceptions need a decision each time. |
ST-3 | Let the tool do the rings | Device management deploys each ring on its date and forces the restart on the restart date. People handle only what fails. |
ST-4 | Keep the manual work for servers and appliances | End-user devices and browsers update themselves through the rings; staff time goes to the windows. |
ST-5 | One owner and one deputy | The IT Operations Manager runs the cycle, with a named deputy who has run it at least once. |
ST-6 | Make the provider prove it | Where a provider deploys, the contract asks for the management tool's report and the scan, never just "done". |
ST-7 | Report exceptions, not activity | The monthly report lists what missed or will miss its deadline, and why. Everything else is one line. |
Worked example: September 2026
EXAMPLE, not part of the procedure. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. September 2026 was its first cycle under the standard. The release day was Tuesday 8 Sep 2026.
The release review
REL-01, monthly operating system and office software updates, with the month's browser and document reader updates, rated Critical and not exploited, released 8 Sep 2026 and first detected 9 Sep 2026. The P01 model gave each system its priority:
System | Criticality | Exposure | Priority | Deadline | Cycle verifies it | Route |
|---|---|---|---|---|---|---|
End-user devices (640, in 3 rings) | Standard | Internal | 3 | 9 Oct 2026 | 17 Sep 2026 (broad ring from 16 Sep 2026) | RT-C |
DC-01 Domain controller | Critical | Internal | 2 | 23 Sep 2026 | 17 Sep 2026 (Window A on 16 Sep 2026, SG-A) | RT-C |
FS-01 File server | High | Internal | 3 | 9 Oct 2026 | 17 Sep 2026 (Window A on 16 Sep 2026, SG-A) | RT-C |
APP-01 Application server (label printing) | Standard | Internal | 3 | 9 Oct 2026 | 17 Sep 2026 (Window A on 16 Sep 2026, SG-A) | RT-C |
PRN-01 Print server | Standard | Internal | 3 | 9 Oct 2026 | 17 Sep 2026 (Window A on 16 Sep 2026, SG-A) | RT-C |
WEB-01 Ordering platform web server (hosted, P06 SUP-002) | Critical | Internet-facing | 2 | 23 Sep 2026 | 17 Sep 2026 (Window A on 16 Sep 2026, SG-A) | RT-C |
DC-02 Domain controller | Critical | Internal | 2 | 23 Sep 2026 | 21 Sep 2026 (Window B on 20 Sep 2026, SG-B) | RT-C |
FS-02 File server | High | Internal | 3 | 9 Oct 2026 | 21 Sep 2026 (Window B on 20 Sep 2026, SG-B) | RT-C |
APP-02 Application server (intranet and reports) | Standard | Internal | 3 | 9 Oct 2026 | 21 Sep 2026 (Window B on 20 Sep 2026, SG-B) | RT-C |
WEB-02 Ordering platform web server (hosted, P06 SUP-002) | Critical | Internet-facing | 2 | 23 Sep 2026 | 21 Sep 2026 (Window B on 20 Sep 2026, SG-B) | RT-C |
WMS-APP-01 Warehouse management system application server | Critical | Internal | 2 | 23 Sep 2026 | 21 Sep 2026 (Window B on 20 Sep 2026, SG-W) | RT-C |
WMS-DB-01 Warehouse management system database server | Critical | Internal | 2 | 23 Sep 2026 | 21 Sep 2026 (Window B on 20 Sep 2026, SG-W) | RT-C |
Two releases from before the cycle were already routed. REL-02, firewall firmware security fix, was Priority 2 on the internet-facing firewalls, due 17 Sep 2026: Window A on 16 Sep 2026, verified 17 Sep 2026, met it, so it stayed in the cycle, with both firewalls in that window (GR-4). REL-03, security fix to the search component the ordering platform is built on, was Priority 2 on both web servers, due 16 Sep 2026: the cycle would have had WEB-01 verified on 17 Sep 2026 and WEB-02 on 21 Sep 2026, both after the deadline, so it was expedited (PM-12). EXAMPLE
The cycle, day by day
Step | Date | What happened |
|---|---|---|
CY-01 Prepare | Thu 3 Sep 2026 | The standard was approved the same day, and the first cycle was prepared under it. |
CY-02 Review the releases | Tue 8 Sep 2026 | REL-01 reviewed: Priority 3 on devices; Priority 2 on the domain controllers, the web servers and the warehouse management system. All in the cycle. REL-02 and REL-03 had been reviewed when released. |
CY-03 Approve and start the pilot | Wed 9 Sep 2026 | Pilot ring deployed (32 devices) with the test servers. |
CY-04 Pilot go or no-go | Fri 11 Sep 2026 | Go: no rollback criterion met; the pilot had every device installed and verified by 10 Sep 2026. |
CY-05 Early ring | Mon 14 Sep 2026 | Early ring deployed (160 devices). |
CY-06 Broad ring and Window A | Wed 16 Sep 2026 | Broad ring released (448 devices). Window A: server group A, and the firewall pair, the standby first, then the other once the standby was back in service (GR-4). |
CY-07 Window B | Sun 20 Sep 2026 | Window B: server group B. The warehouse management system was not patched: its supplier had not certified the update. |
CY-08 Forced restart | Tue 22 Sep 2026 | Forced restart of every device still waiting. |
CY-09 Verify and chase | Wed 23 Sep 2026 | Verification and rescans. 18 devices on the straggler list. The warehouse management system under deferral DEF-2026-01, requested on 21 Sep 2026 and approved on 22 Sep 2026. The search component overdue. |
CY-10 Report | October | The measures below went to the security and IT leadership team. |
Verification
Ring or group | Assets | Installed and verified | 95% reached | Deadline | Note |
|---|---|---|---|---|---|
RG-0 | 32 | 32 | 10 Sep 2026 | 9 Oct 2026 | |
RG-1 | 160 | 159 | 15 Sep 2026 | 9 Oct 2026 | One laptop away on long-term leave; it installs when it next connects. |
RG-2 | 448 | 431 | 23 Sep 2026 | 9 Oct 2026 | Restart forced on 22 Sep. 17 laptops had not connected since: staff on leave and spare devices in stores. Their deadline is 9 Oct 2026; each is chased by name. |
SG-A | 5 | 5 | 17 Sep 2026 | 23 Sep 2026 | |
SG-B | 4 | 4 | 21 Sep 2026 | 23 Sep 2026 | |
SG-W | 2 | 2 | 28 Sep 2026 | 23 Sep 2026 | Planned for 20 Sep. The supplier certified the update on 24 Sep, after the window and a day after the deadline, so it was deferred to the 27 Sep window. |
The warehouse management system (SG-W), due 23 Sep 2026: planned for 20 Sep. The supplier certified the update on 24 Sep, after the window and a day after the deadline, so it was deferred to the 27 Sep window. The system owner asked for the deferral on 21 Sep 2026, 2 days before the deadline, as the "A system cannot be patched in its window" decision requires. EXAMPLE
The search component (REL-03) shows what happens without one: routed as expedited at the release review on 2 Sep, because neither window would have both web servers verified by the 16 Sep deadline: Window A installs WEB-01 on the deadline day, verified the next working day, and Window B comes after it. Deployed on 22 Sep: the ordering platform team is two engineers short (P05 TA-03). No deferral was requested before the deadline; the finding was reported overdue and escalated to the asset owner's manager on 17 Sep (P01 VM-19). EXAMPLE
The report
The measures for September, as calculated in the Patch Compliance Dashboard, with the tolerances the leadership team set:
Measure | September | Target | Tolerance | Status |
|---|---|---|---|---|
PCM-01 Patch coverage | 639 of 657 (97%) | [[95%]] | [[90%]] | On target |
PCM-02 Patch latency | 7 of 9 (78%) | Every deployment within its P01 deadline | [[75% of deployments, while the ordering platform team is rebuilt (P05 TA-03)]] | Below target, within tolerance |
PCM-03 Deadline adherence | 635 of 639 (99%); Priority 1 and 2: 8 of 12 | [[90%]] | [[85%]] | On target |
PCM-04 Systems past vendor support | 0 (1 past support, covered; 1 on extended support; 1 within the look-ahead) | [[None without an unexpired exception and a retirement date]] | Same as the target | On target |
PCM-05 Expired exceptions | 0 of 1 (0%) | Zero High or Critical; below 5% overall | Same as the target | On target |
The report's one sentence: September's cycle reached 97% of devices, servers and appliances, and 7 of 9 deployments met their deadline. The exploited ordering platform flaw was mitigated within 4 hours and patched three days later. The two late deployments were the warehouse system, deferred under an approved exception, and the ordering platform's search component, a week late while that team is short of staff. Nothing was outside tolerance, so nothing went to the executive committee. EXAMPLE
Guidance — delete before approval
What this example teaches: the cycle met every deadline it controlled. The two misses came from outside it: a supplier's certification date and a team short of staff. The first was handled as the procedure says, with a deferral before the deadline; the second was not. Ask suppliers for their certification dates at CY-01, and start the deferral then if the date falls after the window.
Related documents
Document | Relationship |
|---|---|
Patch Management Standard | The rules this procedure runs: PM-03 to PM-10, PM-14 and PM-19 |
Vulnerability & Exposure Management Standard | Every deadline, first detection, overdue escalation; closes each finding on the rescan |
Patch Deployment Ring & Maintenance Window Plan | The rings, server groups, windows and rollback criteria the cycle uses |
Emergency Out-of-Band Patching Procedure | Takes Priority 1 and expedited patches out of the cycle |
Patch Deployment Verification Checklist | The verification checks at CY-09, ring by ring and group by group |
End-of-Life Software & Unsupported System Register | Systems the cycle cannot patch because their vendor no longer does |
Patch Compliance Dashboard | The measures reported at CY-10 |
Patch Deferral Request Form | The deferral request started at CY-01, CY-07 or CY-09 |
Adapting this template
Guidance — delete before approval
Small organisation: keep the calendar, the release review record, the pilot go or no-go and the rescan; they are what an auditor asks for. Let device management run the rings and the restart on their dates, and spend people's time on the servers and on whatever fails. With fewer than [[50]] end-user devices, the three rings PM-06 requires may be two: the pilot (RG-0), observed for [[2]] working days and still covering every hardware model and business application in use, then every other device. This is the only tailoring exception to PM-06. Keep the forced restart, and every server still has a group and a window.
Regulated entity (NIS2, DORA): keep the release review record and the window records as change records: DORA's change management article and the NIS2 Implementing Regulation's patch points both expect patches recorded, tested, approved and verified. Add a column to the review record for systems that support a critical or important function, and treat them as Critical in the P01 model.
IT run by a service provider: give the provider this calendar and the review record's fields, and ask for the management tool's report and the scan at CY-09. The release review's routing and the go or no-go may be the provider's, but the IT Operations Manager reads both, and deferrals stay with [[Organisation Name]].
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 8.8 — Management of technical vulnerabilities | The whole procedure: vulnerabilities fixed by patching within their deadlines |
ISO/IEC 27001:2022 | Annex A 8.32 — Change management | CY-03: the month's standard change; the expedited route's normal change |
ISO/IEC 27001:2022 | Annex A 8.19 — Installation of software on operational systems | CY-03 to CY-08: installing patches on operational systems in rings and windows |
ISO/IEC 27001:2022 | Annex A 5.37 — Documented operating procedures | The whole procedure: a documented, repeatable operating routine |
NIST CSF 2.0 | PR.PS-02 — “Software is maintained, replaced, and removed commensurate with risk” | The whole procedure |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | CY-02: each fix prioritised and routed |
NIST CSF 2.0 | GV.OV-03 — “Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed” | CY-10: monthly measures and escalation |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(e) — “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” | The whole procedure |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Who the Implementing Regulation binds; for other entities it shows what is expected |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 6.6.1 — “The relevant entities shall specify and apply procedures, coherent with the change management procedures referred to in point 6.4.1 as well as with vulnerability management, risk management and other relevant management procedures, for ensuring that: (a) security patches are applied within a reasonable time after they become available; (b) security patches are tested before being applied in production systems; (c) security patches come from trusted sources and are checked for integrity; (d) additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2.” | CY-02 to CY-09: patches applied in time, tested in the pilot, from trusted sources and checked for integrity |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(e) — “implement documented policies, procedures and controls for ICT change management, including changes to software, hardware, firmware components, systems or security parameters, that are based on a risk assessment approach and are an integral part of the financial entity’s overall change management process, in order to ensure that all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner” | CY-03 to CY-09: each change recorded, tested, approved, implemented and verified |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(f) — “have appropriate and comprehensive documented policies for patches and updates” | The whole procedure |
DORA — Delegated Regulation (EU) 2024/1774 | Article 10(4) — the patch management procedures shall “(a) to the extent possible identify and evaluate available software and hardware patches and updates using automated tools; (b) identify emergency procedures for the patching and updating of ICT assets; (c) test and deploy the software and hardware patches and the updates referred to in Article 8(2), points (b)(v), (vi) and (vii); (d) set deadlines for the installation of software and hardware patches and updates and escalation procedures in case those deadlines cannot be met.” | CY-02 (identify and evaluate), CY-03 to CY-08 (test and deploy), the deadlines and escalation |
ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement.
Definitions
Term | Meaning in this procedure |
|---|---|
Cumulative update | A monthly update that contains every earlier fix for the product, so installing the latest one is enough. |
Expedited route | Deploying a patch outside the monthly cycle because its P01 deadline would pass before the cycle has it installed and verified (PM-12). |
Emergency route | Deploying a patch for a Priority 1 vulnerability out of band, with an emergency change, the 72-hour mitigation and a short test (PM-11). |
Installed | The patch is on the system and in effect: the management tool reports it, and any restart it needs has happened. A patch waiting for a restart is not installed. |
Latency | Calendar days from a vendor's release to the day a ring or server group had the patch installed and verified. |
Maintenance window | An agreed, recurring time when a system may be patched and restarted, approved by its system owner. |
Monthly cycle | The routine that takes each month's releases from review through testing, deployment in rings and windows, and verification, on fixed days counted from the release day. |
Release | One publication of patches by a vendor, on its release day or out of turn, with the vendor's advisory saying what each fixes and how severe it is. |
Release day | The day a vendor publishes its regular patches. For the largest operating system and office software vendors it is the second Tuesday of the month; other vendors release monthly, quarterly or whenever a fix is ready. |
Ring | A group of end-user devices that receives a patch at the same stage. Pilot first, then early, then broad, each starting only when the one before has passed its rollback criteria. |
Rollback | Removing a patch, or restoring the system to its state before the patch, because the patch broke something. |
Server group | A group of servers or appliances patched in the same maintenance window. The two members of a redundant server pair are always in different groups; the two members of a high-availability appliance pair are in the same group and patched one at a time. |
Straggler | An asset still missing a patch at verification (CY-09): offline, failed to install, or not restarted. Listed by name with its deadline. |
Verified | Installed, the service checked by its owner, and a scan no longer finds the vulnerability (P01 VM-13). |