Patch Management Standard

Finding weaknesses

Scans, advisories and exploitation sources find them and record each as a finding (VM-01 to VM-07, VM-11).

Reads each vendor release and asks whether it applies (PM-03).

How urgent, and by when

The rating model sets each finding's priority and deadline, from first detection (VM-08, A04).

Uses those deadlines unchanged, and chooses the route that meets them (PM-02, PM-11, PM-12).

Getting the fix onto systems

Tracks the finding until it is closed (VM-11).

Tests, deploys in rings and windows, and restarts (PM-04 to PM-09).

Proving the fix worked

Closes a finding only on a scan or other objective evidence (VM-13).

Asks for that scan as the last verification step (PM-10).

When the deadline cannot be met

An exception before the deadline passes (VM-16 to VM-18).

The deferral form, which feeds the P02 exception register (PM-14, PM-15).

Systems past vendor support

Recorded with compensating controls and a retirement date, reviewed quarterly (VM-15).

The end-of-life register holds the plan for each (PM-17).

Weaknesses no patch fixes

Configuration changes and other fixes, through the triage procedure (A03).

Not covered: P17 handles only vendor updates.

Reporting

Scan coverage, time to remediate, deadline adherence, overdue exposure (VM-20).

Patch coverage, latency, systems past support and expired deferrals; deadline adherence imported from P01 (PM-19).

Head of IT

[[e.g. Head of IT]]

Owns this standard and the cycle, approves emergency changes, and is accountable that every system is patched.

IT Operations Manager

[[e.g. IT Operations Manager]]

Runs the monthly cycle: release review, rings, windows, verification and the monthly report. Owns the end-of-life register.

Head of Information Security

[[e.g. Head of Information Security or CISO]]

Owns the vulnerability standard (P01), rates exploited flaws with the owner, approves deferrals as P02 sets, and receives the measures.

Approver

[[e.g. Chief Operating Officer]]

Approves this standard with the vulnerability standard (P01), and approves Priority 1 deferrals (P01 VM-18).

System owner

[[the business owner of each system or service]]

Agrees the system's maintenance window, checks the service after patching and requests any deferral for it (P01 VM-16).

Application team

[[e.g. the ordering platform team]]

Patches the applications and components it builds or runs, on the same deadlines.

Service provider

[[e.g. managed IT provider]]

Deploys patches where the contract gives it the job, with scan evidence, never just a "done".

Pilot users

[[2]] people from each department and site

Use the pilot ring's devices for their normal work and report anything that stops working.

On-call approver

[[the on-call approver list]]

Approves an emergency change out of hours, by phone, never for a change they will deploy themselves.

AC-1

End-user devices

Laptops, desktops and tablets: their operating system, office software, browsers, document readers and other installed applications.

IT operations, through device management

Three rings (RG-0 to RG-2), automatically through device management; the restart forced on the cycle's restart date

Pilot ring, [[2]] working days

AC-2

Servers

Server operating systems, databases and server applications, on premises and in the organisation's own cloud subscriptions.

IT operations, or the provider the contract names

By server group in its maintenance window; one member of a redundant pair at a time

Test server or the first group, then the rest

AC-3

Network and security appliances

Firewalls, remote access gateways, switches, wireless controllers and storage appliances.

IT operations, or the network provider

Firmware one high-availability member at a time in the window; internet-facing devices first

The vendor's release notes and one member of the pair

AC-4

Business applications

Line-of-business applications, web applications and the components and libraries they are built on.

The application team or the application's supplier

In the application's own window, after the supplier has certified any operating system patch it depends on

A test or staging copy of the application

AC-5

Cloud and software services the provider patches

Software as a service, and hosting where the provider patches the platform beneath what the organisation runs.

The provider, under the contract clause (PM-13); the organisation patches its own side

The provider's own process; the organisation checks the provider's notices every month and patches its clients, agents and connectors

The provider's; the organisation tests its own side

Priority 1

Exploited vulnerability on an internet-facing or Critical system

Mitigate within 72 hours; fix within 7 days

Emergency (RT-E)

Priority 2

Exploited vulnerability on an internal system; Critical or High severity on an internet-facing system

14 days

Monthly cycle (RT-C), or expedited (RT-X) where the cycle would not have it installed and verified by the deadline

Priority 3

Critical or High severity on an internal system; Medium severity on an internet-facing system

30 days

Monthly cycle (RT-C), or expedited (RT-X) where the cycle would not have it installed and verified by the deadline

Priority 4

Medium severity on internal systems; Low severity anywhere

90 days

Monthly cycle (RT-C), or expedited (RT-X) where the cycle would not have it installed and verified by the deadline

Fixes and improvements with no security content

In the next monthly cycle where a system needs them, and within [[90]] days of release at the latest

Firmware with no security content

In the next quarterly window of the device, and within [[90]] days of release at the latest

Version upgrades (a new operating system or application version)

Planned [[6]] months before the running version's support ends, and in the end-of-life register from [[12]] months before (PM-17)

RT-C

Monthly cycle

Priority 2 to 4 patches whose P01 deadline falls on or after the date the cycle has them installed and verified.

The month's pre-approved standard change

RT-X

Expedited

Any patch whose P01 deadline would pass before the cycle has it installed and verified: typically a Priority 2 fix released between cycles (PM-12).

A normal change, approved by the Head of IT within [[1]] working day

RT-E

Emergency

Every Priority 1 patch: an exploited vulnerability on an internet-facing or Critical system (PM-11).

An emergency change, approved by the Head of IT or the on-call approver, never by the person deploying it

RG-0

Pilot

The IT team's own devices, test servers, and [[2]] pilot users from each department and site: about [[5]]% of devices, covering every hardware model and every business application in use

The day after the release review

[[2]] working days

RG-1

Early

About [[25]]% of devices, spread across every site and department, and never more than half of any one team

When the pilot has passed its rollback criteria

[[2]] working days

RG-2

Broad

Every other device

When the early ring has passed its rollback criteria

Until the forced restart date

GR-1

Every server belongs to one group, and every group to one maintenance window.

GR-2

The two members of a redundant server pair (domain controllers, clustered nodes, load-balanced web servers) are in different groups with different windows, so one is always running and a faulty patch reaches only one.

GR-3

The first server group is patched only after the pilot ring and the test servers have passed their rollback criteria.

GR-4

The two members of a high-availability appliance pair (firewalls, remote access gateways) are in the same group and patched in the same window, one at a time: the standby first, the other only after the first is back in service and has passed its service check. A pair never runs two firmware versions for longer than the window.

GR-5

Internet-facing systems are in the earliest group their redundancy allows, because their deadlines are the shortest (P01).

GR-6

A system whose supplier must certify each patch has its own group, whose window falls after the certification date the contract sets.

MW-A

Window A

The Wednesday of the week after the release day, [[20:00 to 23:00]]

8

Server group A, and the appliance pairs whose group uses it (both members, one at a time, GR-4)

MW-B

Window B

The Sunday after Window A, [[02:00 to 06:00]]

12

Server group B, the appliances whose group uses it, and systems with a Sunday change window

MW-E

Emergency window

Any time the emergency change sets (PM-11)

As needed

Priority 1 patches, and expedited patches with no window inside their deadline

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.

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.

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

Low

1–3

Control owner

5

90 days (P02 allows 365; P01 caps it)

Medium

4–6

Head of Information Security

10

90 days (P02 allows 180; P01 caps it)

High

8–9

Head of Information Security and the accountable executive (risk owner)

10

90 days

Critical

12–16

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, such as in an owner-managed company, executive management

5

30 days

DA-1

Priority 1

Only once the 72-hour mitigation is in place (P01 VM-09), and approved by the approver of the vulnerability standard (P01 VM-18), or by the band's approver where that approver is more senior.

DA-2

The risk left is outside appetite, or scored Critical

The P05 approver for that position signs as well: the stricter of the two always applies (P05).

DA-3

The approver requested the deferral, or runs the patching

The approval passes to the next level up (P02 EX-05).

DA-4

A Critical band deferral

Approved by 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, such as in an owner-managed company, executive management; a renewal beyond its limit goes to [[the full board, or its equivalent]] (P02 EX-08).

DR-1

The patch failed in the pilot or a test with a confirmed fault, or the vendor withdrew it or published a known issue that affects us.

DR-2

The system's supplier has not yet certified the patch, and installing it uncertified would end the supplier's support.

DR-3

The system cannot be restarted inside the deadline without stopping a critical service, and none of the other options in PM-16 works in time.

DR-4

No patch exists: the vendor has not released one, or the system is past support (PM-17).

DR-5

The system is being retired before the next window, on an approved date.

EO-1

Still needed?

Ask the owner. If the system is no longer needed, retire it now.

EO-2

Upgrade or replace

Move to a supported version or product. This is the only lasting answer.

EO-3

Extended support

Buy the vendor's extended security updates where they are offered, for the time it takes to replace the system. The system stays in the register.

EO-4

Isolate

Its own network segment, only the connections it needs, no internet, no email or browsing, and its administration interfaces off.

EO-5

Compensating controls

Application allow-listing, closer monitoring, checked backups and the fewest accounts possible, each tested.

EO-6

Record and decide

A P02 exception with its expiry, a retirement date, a quarterly review (P01 VM-15), and the P05 approver's signature as well where the risk is outside appetite.

Past support: no security patches

The vendor no longer releases security patches, and no extended support is in place. Needs the controls and decision in EO-4 to EO-6.

Past normal support: on extended support

Security patches the vendor still releases, usually for a fee, for a limited time after the end of normal support. A system on extended support is still recorded in the end-of-life register.

Support ends within 12 months

In the register now, with a plan, so the replacement is done before support ends (look-ahead 12 months).

Supported

Not in the register.

PCM-01

Patch coverage

Assets in scope with every security patch deployed to their ring or server group installed and verified at the period end, out of all assets in scope, by asset class. Services a provider patches are left out and assured through the contract (PM-13).

[[95%]]

PCM-02

Patch latency

For each deployment in the period, the calendar days from the vendor's release to the day [[95%]] of the ring or server group had the patch installed and verified, shown by P01 priority and by ring or group, each against its P01 deadline. The figure judged is the share of deployments that met their deadline.

Every deployment within its P01 deadline

PCM-03

Deadline adherence

(P01, catalogue MC-03)

Findings closed in the period within their deadline ÷ findings closed in the period. Reported for the findings that patching closed, with Priority 1 and 2 shown apart, as the board measure for critical exposure counts them (P03 BM-02).

[[Target, e.g. ≥ 90%]]

PCM-04

Systems past vendor support

Systems in use at the period end that are past the end of vendor support with no extended support, each shown with whether it has an unexpired P02 exception and a retirement date. The figure judged is how many have neither.

[[None without an unexpired exception and a retirement date]]

PCM-05

Expired exceptions

(P02, catalogue MC-06)

Exceptions past their expiry date that are neither closed nor renewed, as a share of all open exceptions. Reported for patch deferrals.

Zero High or Critical; below 5% overall

Asset inventory with patch owner, asset class, ring or group and window

[[Asset inventory or device management tool]]

[[Current, with changes kept for 12 months]]

Release review records, with each fix's rating and route

[[Change or ticketing system]]

[[3 years]]

Standard, normal and emergency change records

[[Change management system]]

[[3 years]]

Pilot go or no-go decisions and rollback records

[[Change management system]]

[[3 years]]

Deployment reports, service checks and confirming scans

[[Management tool and scanner exports]]

[[12 months, and 3 years for the confirming scans]]

Deferral requests and decisions

The organisation's exception register (P02)

[[3 years after expiry]]

End-of-life register and its quarterly reviews

[[Location]]

[[3 years after the system is retired]]

Monthly reports and escalations

[[Location]]

[[3 years]]

Approved versions of this standard

[[Document management system]]

[[Life of the management system plus 3 years]]

PM-01

Pick ten systems from the asset inventory. Each has a patch owner, an asset class, a ring or server group and a window.

The inventory export, with the four fields filled for every row

PM-02, PM-12

Pick five security patches from last quarter. Each was installed and verified by the deadline of the P01 finding it fixed.

The finding's first detection date and priority, and the confirming scan's date

PM-03

Show the review of last month's releases.

The release review record: each fix, its P01 rating and its route, dated within the review time

PM-04, PM-05

Show where last month's patches came from and how they were tested.

The update source settings; the pilot ring's go or no-go record with its date

PM-06, PM-07, PM-08

Show the rings, the server groups and the windows, and the rollback criteria agreed for each.

The ring and window plan, approved by the system owners

PM-09, PM-10

Show that last month's deployment was verified.

The management tool report, the service checks, the rescan and the straggler list

PM-11

Show the last emergency.

The emergency change, its approver, and the times of detection, mitigation, deployment and rescan

PM-13

Show that the providers who patch your services are bound to do it.

The contract clause, and last month's check of each provider's security notices

PM-14, PM-15, PM-16

Show every patch installed after its deadline in the last six months.

For each, a deferral approved before the deadline, or the overdue report and escalation

PM-17

Show the systems past vendor support.

The end-of-life register, its last quarterly review, and the exception and retirement date of each system

PM-18

Show how updates with no security content are scheduled.

The cycle record showing them deployed, and the version upgrade plan

PM-19

Show the last three monthly reports.

The reports, the leadership team's minutes, and any escalation to the executive committee

REL-01

Monthly operating system and office software updates, with the month's browser and document reader updates

8 Sep 2026

9 Sep 2026

Critical

No

REL-02

Firewall firmware security fix

2 Sep 2026

3 Sep 2026

High

No

REL-03

Security fix to the search component the ordering platform is built on

1 Sep 2026

2 Sep 2026

High

No

REL-04

Emergency security release of the ordering platform's web commerce software, for a remote code execution flaw the vendor reports is being exploited

24 Sep 2026

24 Sep 2026, 09:15

Critical

Yes

RG-0

REL-01

RT-C

3

9 Oct 2026

10 Sep 2026

Yes

RG-1

REL-01

RT-C

3

9 Oct 2026

15 Sep 2026

Yes

RG-2

REL-01

RT-C

3

9 Oct 2026

23 Sep 2026

Yes

SG-A

REL-01

RT-C

2 and 3

23 Sep 2026

17 Sep 2026

Yes

SG-B

REL-01

RT-C

2 and 3

23 Sep 2026

21 Sep 2026

Yes

SG-W

REL-01

RT-C

2

23 Sep 2026

28 Sep 2026

No

NW-1

REL-02

RT-C

2

17 Sep 2026

17 Sep 2026

Yes

Ordering platform

REL-03

RT-X

2

16 Sep 2026

23 Sep 2026

No

Ordering platform

REL-04

RT-E

1

1 Oct 2026

28 Sep 2026

Yes

[[Information Security Policy]]

Parent policy

Vulnerability & Exposure Management Standard

Sets every security deadline this standard uses, the priority model, first detection, exceptions and overdue escalation

Monthly Patch Cycle Operating Procedure

Runs the monthly cycle: PM-03 to PM-10 and PM-19

Patch Deployment Ring & Maintenance Window Plan

Records the rings, groups, windows and rollback criteria: PM-06 to PM-08

Emergency Out-of-Band Patching Procedure

Runs the emergency and expedited routes: PM-11 to PM-13

Patch Deployment Verification Checklist

The verification checks: PM-10

End-of-Life Software & Unsupported System Register

The end-of-life register: PM-17

Patch Compliance Dashboard

The headline measures: PM-19

Patch Deferral Request Form

Requests a deferral: PM-14 to PM-16

Security Exception & Waiver Standard

Scores, approves and records every deferral as an exception (P02)

Risk Acceptance Form & Approval Record

Adds the risk approver's signature where a deferral leaves a risk outside appetite (DA-2)

Supplier Contract Security Clause Library

The provider clause PM-13 relies on (CL-08)

Security Incident Management Policy

Takes over when an exploited vulnerability may have been used against us (PM-11)

ISO/IEC 27001:2022

Annex A 8.8 — Management of technical vulnerabilities

The whole standard: technical vulnerabilities fixed by patching on P01's deadlines

ISO/IEC 27001:2022

Annex A 8.19 — Installation of software on operational systems

PM-04 to PM-09: patches installed on operational systems from trusted sources, tested, in rings and windows

ISO/IEC 27001:2022

Annex A 8.32 — Change management

PM-03, PM-11 and PM-12: each route's change approval

ISO/IEC 27001:2022

Annex A 5.22 — Monitoring, review and change management of supplier services

PM-13: providers' patching checked every month

ISO/IEC 27001:2022

Annex A 5.36 — Compliance with policies, rules and standards for information security

PM-14 and PM-19: departures recorded as exceptions

NIST CSF 2.0

PR.PS-02 — “Software is maintained, replaced, and removed commensurate with risk”

The whole standard

NIST CSF 2.0

PR.PS-03 — “Hardware is maintained, replaced, and removed commensurate with risk”

Asset class AC-3: firmware of network and security appliances

NIST CSF 2.0

ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated”

PM-03, PM-11 and PM-12: each fix routed by its priority

NIST CSF 2.0

ID.RA-07 — “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked”

PM-14 and PM-15: deferrals assessed, recorded and tracked

NIST CSF 2.0

ID.AM-08 — “Systems, hardware, software, services, and data are managed throughout their life cycles”

PM-17 and PM-18: systems managed through to the end of support

NIST CSF 2.0

GV.OV-03 — “Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed”

PM-19: 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 standard

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.”

PM-02 (a reasonable time), PM-05 (tested), PM-04 (trusted sources, integrity), PM-14 to PM-17 (measures where a patch is not applied)

NIS2 — Implementing Regulation (EU) 2024/2690

Annex, point 6.6.2 — “By way of derogation from point 6.6.1(a), the relevant entities may choose not to apply security patches when the disadvantages of applying the security patches outweigh the cybersecurity benefits. The relevant entities shall duly document and substantiate the reasons for any such decision.”

PM-14 and PM-15: the reasons for not applying a patch recorded and approved

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”

PM-03 to PM-12: patches recorded, tested, approved, deployed and verified as changes

DORA — Regulation (EU) 2022/2554

Article 9(4)(f) — “have appropriate and comprehensive documented policies for patches and updates”

The whole standard

DORA — Delegated Regulation (EU) 2024/1774

Article 10(2)(f) — the vulnerability management procedures shall “prioritise the deployment of patches and other mitigation measures to address the vulnerabilities identified”

PM-02, PM-03, PM-11 and PM-12: deployment prioritised by P01 priority

DORA — Delegated Regulation (EU) 2024/1774

Article 10(3) — “financial entities shall develop, document and implement patch management procedures”

The whole standard and the procedures it names

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.”

PM-03 (identify), PM-11 (emergency), PM-05 to PM-09 (test and deploy), PM-02 and PM-14 (deadlines and escalation)

Compensating control

A measure that makes a vulnerability harder to exploit while the patch is not installed: blocking the vulnerable service, restricting who can reach the system, disabling the affected feature or isolating the system. It counts only once it has been tested (P02 EX-07).

Cumulative update

A monthly update that contains every earlier fix for the product, so installing the latest one is enough.

Deferral

Installing a patch after its P01 deadline, approved in advance as a P02 exception (PM-14). Moving a patch to a later window that is still inside its deadline is not a deferral.

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).

End of support

The date after which the vendor no longer releases security patches for a product or version.

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).

Extended support

Security patches the vendor still releases, usually for a fee, for a limited time after the end of normal support. A system on extended support is still recorded in the end-of-life register.

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.

Internet-facing

Reachable from the internet, directly or through a published service, without first connecting to the organisation's private network; or reachable from any network the organisation does not fully control, such as partner links, guest Wi-Fi or third-party connections.

Latency

Calendar days from a vendor's release to the day a ring or server group had the patch installed and verified.

Live patching

Applying some fixes to a running system without a restart, where the vendor supports it for that product. Fixes it cannot apply wait for the next restart.

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.

Patch

An update from a software or hardware vendor that changes installed code or firmware. A security patch fixes one or more vulnerabilities; other patches fix faults or add features.

Patch owner

The person who makes sure a system is patched: deploys the patch, or makes sure the team or provider who does it has done so.

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.

Verified

Installed, the service checked by its owner, and a scan no longer finds the vulnerability (P01 VM-13).