# Patch Management Policy: [Organisation name]

> Organisation policy for applying software and firmware updates as preventive maintenance: asset scope, maintenance groups, routine, expedited and emergency cadences, testing rings, deployment windows, rollback, end-of-life software, mitigations when no patch exists, exceptions, evidence and metrics. Based on NIST SP 800-40 Rev. 4, *Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology* (April 2022), and informed by CISA Binding Operational Directive 26-04, *Prioritizing Security Updates Based on Risk* (June 2026). Remediation deadlines for vulnerabilities are owned by the vulnerability management policy; this policy defines how updates are delivered to meet them. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- This policy is the operating rulebook for update delivery. It does not set vulnerability prioritisation or remediation deadlines; those live in Vulnerability Management Policy (`security/vulnerability-management-policy`). Link to it instead of copying its SLA table, so there is one source of truth.
- Build the maintenance groups in section 6 from the asset inventory first. Every asset belongs to exactly one maintenance group, including assets that cannot be patched.
- Kubernetes minor-version upgrades follow Kubernetes Cluster Upgrade Runbook (`ops/kubernetes-cluster-upgrade-runbook`); node image rotation follows the cadence set here. Application dependency updates in source code follow Dependency Management Policy (`dev/dependency-management-policy`).
- Changes made under this policy go through Change Request (`ops/change-request`) as standard, normal or emergency changes, and customer-visible windows are announced with Maintenance Notice (`ops/maintenance-notice`).
- Use MUST for mandatory statements and SHOULD for expected practice where a documented reason allows deviation.
- Example organisation: Corvid Commerce, a fictional SaaS company. Delete every *Example* row before approval.
-->

## Document control

<!-- Guidance: Identify the policy owner, approver and review cycle. A change to cadences or maintenance groups is a minor version; a change of scope or authority is a major version. -->

| Field | Value |
|---|---|
| Document ID | [POL-PATCH-001] |
| Policy owner | [@head-of-infrastructure] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Retired] |
| Owner | [@head-of-infrastructure] |
| Approvers/reviewers | [@ciso], [@cto], [@head-of-it], [@change-manager] |
| Effective date | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least annually) |
| Classification | [Internal] |
| Applies to | [All business units, subsidiaries, contractors operating organisation assets] |
| Related documents | [Vulnerability management policy], [Change management procedure], [Asset inventory], [Backup policy] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief Information Security Officer | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief Technology Officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of IT | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; replaces the 2023 server patching standard |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added OT maintenance group and container image cadence |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose](#1-purpose)
2. [Scope](#2-scope)
3. [Roles and responsibilities](#3-roles-and-responsibilities)
4. [Principles](#4-principles)
5. [Policy statements](#5-policy-statements)
6. [Maintenance groups](#6-maintenance-groups)
7. [Risk response scenarios and cadences](#7-risk-response-scenarios-and-cadences)
8. [Testing rings and staged deployment](#8-testing-rings-and-staged-deployment)
9. [Deployment windows and change control](#9-deployment-windows-and-change-control)
10. [Verification and rollback](#10-verification-and-rollback)
11. [End-of-life software](#11-end-of-life-software)
12. [Mitigations when no patch exists](#12-mitigations-when-no-patch-exists)
13. [Exceptions and risk acceptance](#13-exceptions-and-risk-acceptance)
14. [Evidence, metrics and reporting](#14-evidence-metrics-and-reporting)
15. [Procurement and supplier requirements](#15-procurement-and-supplier-requirements)
16. [Review and related documents](#16-review-and-related-documents)
17. [Glossary and references](#17-glossary-and-references)

## 1. Purpose

<!-- Guidance: Explain why patching matters in business terms, not only security terms. Pitfall: framing patching as a security team demand, so operations teams see it as interruption rather than maintenance. -->

This policy makes software and firmware updates a planned, routine part of operating every technology asset, in the same way that vehicles and buildings receive preventive maintenance. Regular updates reduce the chance of compromise, data breach and outage, and keep assets supportable by their vendors.

The policy sets the rules for:

- knowing which assets need updates and who maintains them;
- grouping assets so each group has a realistic maintenance plan;
- delivering routine, expedited and emergency updates safely;
- protecting assets that cannot be updated, or not yet;
- proving that updates happened, and measuring how well.

## 2. Scope

<!-- Guidance: Name every asset class in scope, including the ones that are hard to patch. Pitfall: leaving out firmware, network devices, SaaS configuration and container images, which then age without an owner. -->

### 2.1 In scope

| Asset class | Examples | Notes |
|---|---|---|
| End-user devices | Laptops, desktops, mobile phones, tablets | Operating system, browsers, office suites, endpoint agents |
| Servers and virtual machines | Linux and Windows servers, hypervisors | Operating system, middleware, agents |
| Containers and images | Base images, application images, Kubernetes node images | Rebuilt rather than patched in place |
| Managed cloud services | Database engines, Kubernetes control planes | Version upgrades the provider exposes to the customer |
| Network and security devices | Firewalls, routers, switches, VPN gateways, load balancers | Firmware and operating system |
| Firmware | BIOS and UEFI, baseboard management controllers, storage controllers | Often missed; vendor tools needed |
| Commercial and open-source applications | Line of business systems, developer tools | Including plugins and extensions |
| Operational technology and IoT | Building management, payment terminals, cameras | Usually a special maintenance group |

### 2.2 Out of scope

- Vulnerability discovery, scoring and remediation deadlines: Vulnerability Management Policy (`security/vulnerability-management-policy`).
- Product security fixes the organisation ships to its own customers: PSIRT Vulnerability Handling (`security/psirt-vulnerability-handling`).
- Changes to source-code dependencies of in-house software, which follow Dependency Management Policy (`dev/dependency-management-policy`), except where those changes are deployed as images covered in section 2.1.

## 3. Roles and responsibilities

<!-- Guidance: Give each maintenance group a named owner and separate deciding from doing. Pitfall: the security team owning patching in name while infrastructure teams own the systems in practice. -->

| Role | Responsibilities |
|---|---|
| Policy owner | Maintains this policy, reports metrics to leadership, approves changes to maintenance groups |
| Chief Information Security Officer | Declares emergencies, approves risk acceptances above team level |
| Maintenance group owner | Owns the maintenance plan of one group, schedules and executes updates, records evidence |
| Asset owner | Accountable for the business service, agrees windows and accepts residual risk within limits |
| Vulnerability management team | Prioritises vulnerabilities and sets deadlines under the vulnerability policy; tracks closure |
| Change manager | Classifies and approves changes, publishes the change calendar |
| Service desk | Supports users during end-user device rollouts, collects issue reports from early rings |
| Procurement | Applies the supplier requirements in section 15 |

| Activity | Policy owner | Group owner | Asset owner | Vuln. mgmt | CISO | Change manager |
|---|---|---|---|---|---|---|
| Maintain asset inventory and group membership | A | R | C | C | I | I |
| Define maintenance plan per group | A | R | C | C | I | C |
| Routine patch deployment | I | A/R | C | I | I | C |
| Declare emergency patching or mitigation | C | R | I | C | A | I |
| Approve exception up to [90] days | I | R | A | C | I | I |
| Approve exception beyond [90] days or for critical assets | C | R | C | C | A | I |
| Monthly metrics report | A/R | C | I | C | I | I |

R = Responsible, A = Accountable, C = Consulted, I = Informed.

## 4. Principles

<!-- Guidance: State the few ideas every later rule follows. -->

1. **Patching is maintenance, not an exception.** Every asset has a planned maintenance rhythm, and updates are expected, scheduled work.
2. **Every asset has a maintenance group.** Assets that cannot be patched still need maintenance, through other forms of risk response.
3. **Risk drives speed.** The more exposed, exploited and important the asset and vulnerability, the faster the response. Prioritisation follows the vulnerability policy.
4. **Small blast radius first.** Updates reach a small set of assets before the rest, even in an emergency.
5. **Automate by default.** Manual patching does not scale and leaves no reliable evidence.
6. **Replace rather than repair** where the platform allows it: rebuild images and redeploy instead of patching running containers or nodes.
7. **Proof over intent.** An update counts only when deployment is verified.

## 5. Policy statements

<!-- Guidance: Number each statement so audits and exceptions can refer to it. Pitfall: statements that cannot be measured, such as "patch promptly". -->

| ID | Statement |
|---|---|
| PATCH-01 | Every in-scope asset MUST be recorded in the asset inventory with an owner and a maintenance group. |
| PATCH-02 | Each maintenance group MUST have an approved maintenance plan covering the four risk response scenarios in section 7. |
| PATCH-03 | Routine updates MUST be deployed on the cadence of the asset's maintenance group, and SHOULD be automated. |
| PATCH-04 | Updates that remediate a vulnerability MUST be deployed within the deadline set by the vulnerability management policy for that vulnerability and asset. |
| PATCH-05 | Routine updates MUST pass through at least one test ring before broad deployment (section 8). |
| PATCH-06 | Emergency updates SHOULD reach a small canary set first, for at least the minimum observation time of the group, unless the CISO waives it in writing. |
| PATCH-07 | Updates MUST be deployed through the change process; routine updates on approved automation qualify as standard changes. |
| PATCH-08 | Each maintenance plan MUST define a rollback or recovery method and the backup it depends on. |
| PATCH-09 | Deployment MUST be verified from an independent data source (inventory, endpoint agent or scanner), not only from the deployment tool's job status. |
| PATCH-10 | Software and firmware past vendor end of support MUST NOT be introduced, and existing instances MUST have a dated retirement plan (section 11). |
| PATCH-11 | When no patch is available for a vulnerability that the vulnerability policy requires to be addressed, an approved mitigation MUST be applied within the same deadline (section 12). |
| PATCH-12 | Temporary mitigations MUST be removed once the permanent fix is deployed, by a scheduled date. |
| PATCH-13 | Users MAY defer routine end-user updates for a grace period of up to [7] days, after which installation MUST be enforced. |
| PATCH-14 | Container images MUST be rebuilt from updated base images at least [weekly] and redeployed within the routine cadence. |
| PATCH-15 | Deviations MUST be recorded as exceptions with an owner, compensating controls and an expiry date (section 13). |
| PATCH-16 | Patch metrics MUST be reported monthly to the policy owner and quarterly to [the risk committee]. |

## 6. Maintenance groups

<!-- Guidance: Group assets by similar maintenance needs: what software they run, how much downtime they tolerate, which controls already protect them and how much harm a compromise would cause. Pitfall: groups defined by team names, which change, rather than by maintenance characteristics. -->

Define groups at the level of detail that lets one plan fit every member. Review the groups at least annually and whenever a new platform is adopted. Define groups so that few assets need exceptions; assets with similar long-term exceptions belong in their own group with its own plan. The exceptions that remain are recorded and tracked under section 13.

| Group ID | Assets | Software to update | Downtime tolerance | Existing mitigations | Impact if compromised | Owner |
|---|---|---|---|---|---|---|
| MG-01 *(Example)* | Employee laptops | OS, browsers, office apps, agents | Tolerant, user restarts | Endpoint detection, disk encryption | Moderate | End-user computing |
| MG-02 *(Example)* | Mobile phones | OS, managed apps | Tolerant | Mobile device management | Moderate | End-user computing |
| MG-03 *(Example)* | Production Kubernetes nodes | Node image, kubelet patch, container runtime | Tolerant per node with surge | Restricted pod security, network policy | High | Platform team |
| MG-04 *(Example)* | Container images | Base image packages, language runtimes | Tolerant, rolling deploy | Image signing, admission policy | High | Product teams with platform |
| MG-05 *(Example)* | Managed databases | Engine minor versions | Window required | Private endpoints | High | Data platform |
| MG-06 *(Example)* | Network edge devices | Firmware, OS | Window required, HA pair | Management plane isolated | High | Network team |
| MG-07 *(Example)* | Warehouse scanners (OT) | Vendor bundle only | Low, shift-based | Isolated VLAN | Moderate | Facilities with IT |
| MG-08 *(Example)* | Legacy reporting server | None, unsupported | Window required | Segmented, no internet | High | Finance IT |

## 7. Risk response scenarios and cadences

<!-- Guidance: Define the plan for each scenario per group: routine patching, expedited or emergency patching, emergency mitigation, and unpatchable assets. Pitfall: one cadence for everything, which is too slow for exploited flaws and too disruptive for routine ones. -->

NIST SP 800-40 Rev. 4 describes four risk response scenarios that every maintenance plan should cover: routine patching, emergency patching, emergency mitigation and unpatchable assets. This policy adds an expedited cadence between routine and emergency for updates that the vulnerability policy marks as urgent but that do not justify an emergency change.

| Scenario | Trigger | Who decides | Change type |
|---|---|---|---|
| Routine | Vendor release on the normal cycle, or no urgent vulnerability | Group owner | Standard |
| Expedited | Vulnerability policy deadline shorter than the routine cycle | Group owner with vulnerability management | Normal, fast-tracked |
| Emergency patching | Vulnerability policy places the issue in its most urgent class, or active exploitation on the organisation's estate | CISO | Emergency |
| Emergency mitigation | Same triggers, but no patch available or patch cannot be applied in time | CISO | Emergency |
| Unpatchable asset | Asset cannot receive updates (end of life, vendor certification, safety) | Policy owner | Not applicable; long-term mitigation plan |

### 7.1 Cadence by group

The values below are *Example* delivery targets, not remediation SLAs. Remediation deadlines for vulnerabilities are set only by Vulnerability Management Policy (`security/vulnerability-management-policy`). Set each cadence so that it meets those deadlines; when a routine cadence would miss a vulnerability policy deadline, the vulnerability policy deadline governs and the update moves to the expedited or emergency route.

| Group | Routine cadence | Expedited target | Emergency target | Grace for users |
|---|---|---|---|---|
| MG-01 Laptops *(Example)* | Monthly, within 14 days of vendor release | 7 days | 72 hours | 7 days, then forced restart |
| MG-02 Phones *(Example)* | Monthly | 7 days | 72 hours | 7 days, then access blocked |
| MG-03 Kubernetes nodes *(Example)* | Weekly node image rotation | 72 hours | 24 hours | Not applicable |
| MG-04 Container images *(Example)* | Weekly rebuild, deploy within 7 days | 72 hours | 24 hours | Not applicable |
| MG-05 Managed databases *(Example)* | Quarterly minor version | 14 days | Provider-driven, 72 hours | Not applicable |
| MG-06 Network edge *(Example)* | Quarterly | 7 days | 48 hours | Not applicable |
| MG-07 OT scanners *(Example)* | Vendor bundle, twice a year | Mitigation within 7 days | Mitigation within 72 hours | Not applicable |
| MG-08 Legacy server *(Example)* | None | Mitigation within 7 days | Mitigation within 24 hours | Not applicable |

### 7.2 Relationship to CISA BOD 26-04

For US federal civilian executive branch agencies, BOD 26-04 (issued 10 June 2026, superseding BOD 22-01 and BOD 19-02) requires remediation timelines driven by risk factors rather than severity scores alone. The factors include whether the affected asset is publicly exposed, whether the vulnerability is in CISA's Known Exploited Vulnerabilities catalog, whether exploitation can be automated, and the technical impact of exploitation. The directive binds only those agencies; other organisations may adopt the same factors voluntarily. Organisations that follow the directive, voluntarily or by contract, MUST encode its factors and the current timeline table in the vulnerability management policy and keep this policy's emergency and expedited cadences fast enough to meet them. Check the directive and its implementation guidance at cisa.gov for the current timelines, because CISA updates the guidance on a rolling basis, and check there which mitigations, such as removing public exposure, count as meeting a timeline.

```mermaid
flowchart TD
  start["Update or vulnerability notice"] --> vm{"Vulnerability policy class"}
  vm -->|"Most urgent"| patch{"Patch available and safe to apply in time?"}
  vm -->|"Urgent"| exp["Expedited cadence"]
  vm -->|"Other or no vulnerability"| routine["Routine cadence"]
  patch -->|"Yes"| emerg["Emergency patching with short canary"]
  patch -->|"No"| mit["Emergency mitigation"]
  mit --> fix["Schedule permanent fix and mitigation removal"]
  exp --> rings["Testing rings, compressed"]
  routine --> rings2["Testing rings, standard"]
  emerg --> verify["Verify deployment"]
  rings --> verify
  rings2 --> verify
  fix --> verify
```

## 8. Testing rings and staged deployment

<!-- Guidance: Use real assets as early indicators, from technical staff outward. Pitfall: a test lab that does not resemble production, which gives false confidence. -->

Routine updates move through rings. Each ring has an entry condition, an observation period and an exit criterion. An issue found in a ring stops promotion until the group owner decides to proceed, hold or apply a temporary mitigation instead.

| Ring | Members | Share of group | Observation period | Exit criterion |
|---|---|---|---|---|
| Ring 0: lab and automated tests | Test devices, staging clusters | Not applicable | Until tests pass | Automated test suite green |
| Ring 1: technical early adopters | IT, platform and security staff | 2 to 5 % | [2] business days | No new incident, error rate within baseline |
| Ring 2: broad pilot | Volunteers across departments, one production zone | 10 to 20 % | [3] business days | Service desk contacts within [1.2] times baseline |
| Ring 3: general | Remaining assets | Remaining | Not applicable | Compliance target reached |

*Example:* For MG-01 (1,200 laptops at Corvid Commerce), ring 1 has 40 devices (3.3 %), ring 2 has 180 devices (15 %) and ring 3 the remaining 980 (81.7 %). Totals: 40 + 180 + 980 = 1,200.

Emergency patching uses the same rings with compressed timing: a canary set observed for minutes to hours, then the rest of the group. Emergency changes MUST still record which assets were updated first and what was observed.

## 9. Deployment windows and change control

<!-- Guidance: Agree windows with asset owners in advance, so emergencies do not need negotiation. Pitfall: windows that collide with business peaks or with other changes on the same service. -->

| Group | Routine window | Emergency window | Customer notice | Change type |
|---|---|---|---|---|
| MG-01 Laptops *(Example)* | Any time, restart prompt during working hours | Immediate | None | Standard |
| MG-03 Kubernetes nodes *(Example)* | Tuesday to Thursday 09:00 to 16:00 local, surge rotation | Any time | None (no expected impact) | Standard |
| MG-05 Managed databases *(Example)* | Sunday 02:00 to 05:00 | Any time with on-call DBA | 5 business days via maintenance notice | Normal |
| MG-06 Network edge *(Example)* | Second Sunday 01:00 to 04:00, one HA member at a time | Any time | 5 business days | Normal |

Rules:

- Respect the change calendar and freeze periods. Emergency updates MAY proceed during a freeze with CISO and change manager approval.
- Do not schedule routine updates for both members of a high-availability pair in the same window.
- Announce customer-visible windows with Maintenance Notice (`ops/maintenance-notice`).
- Record every deployment in the change record with the assets covered.

## 10. Verification and rollback

<!-- Guidance: Prove updates landed and define how to undo them. Pitfall: counting a job as successful when devices were offline or the update needed a restart that never happened. -->

### 10.1 Verification

After each deployment, the group owner MUST confirm:

1. the update is installed, from an independent source such as the endpoint agent, a configuration scan or the image registry;
2. any required restart has happened;
3. the vulnerability, where one triggered the update, no longer appears in the next scan;
4. service health indicators are within baseline.

Assets that fail installation twice are escalated to the asset owner and tracked until fixed or excepted.

### 10.2 Rollback

| Group | Rollback method | Dependency | Maximum time to roll back |
|---|---|---|---|
| MG-01 Laptops *(Example)* | Uninstall update through management tool, or pause ring | Vendor supports uninstall | 1 business day |
| MG-03 Kubernetes nodes *(Example)* | Recreate pool from previous image | Previous image retained [30] days | 2 hours |
| MG-04 Container images *(Example)* | Redeploy previous image digest | Registry retention | 30 minutes |
| MG-05 Managed databases *(Example)* | Restore from snapshot or fail over to replica not yet upgraded | Snapshot before change | 4 hours |
| MG-06 Network edge *(Example)* | Boot previous firmware partition | Dual image support | 1 hour |

Backups that rollback depends on follow Backup Policy (`ops/backup-policy`). When rollback re-exposes a vulnerability, the group owner MUST apply a mitigation under section 12 and inform vulnerability management the same day.

## 11. End-of-life software

<!-- Guidance: Treat end of support as a known date to plan for, not a surprise. Pitfall: discovering end of life only when a critical vulnerability arrives and no patch will ever ship. -->

1. The asset inventory MUST record the vendor end-of-support date for operating systems, databases, runtimes, firmware and major applications.
2. Group owners MUST plan upgrade or retirement so that no asset passes its end-of-support date; plans start at least [12] months before the date.
3. Assets past end of support MUST move to an unpatchable maintenance group with long-term mitigations (section 12) and a dated retirement plan approved by the policy owner.
4. Paid extended support MAY be used as a bridge for at most [12] months and MUST be recorded as an exception.
5. New purchases and new deployments of software already past, or within [12] months of, end of support MUST NOT be approved.

| Asset or product | End of support | Assets affected | Plan | Owner | Status |
|---|---|---|---|---|---|
| Server OS version [x] *(Example)* | YYYY-MM-DD | 14 servers | Upgrade in place, quarter 2 | Infrastructure | On track |
| Kubernetes 1.34 *(Example)* | 2026-10-27 (upstream) | 0 clusters | Already upgraded | Platform team | Closed |
| Reporting server *(Example)* | Passed | 1 server (MG-08) | Replace with managed service by YYYY-MM-DD | Finance IT | At risk |

## 12. Mitigations when no patch exists

<!-- Guidance: Pre-approve a menu of mitigations per group so they can be applied quickly. Pitfall: inventing a mitigation during an emergency without knowing if it works or what it breaks. -->

NIST SP 800-40 Rev. 4 frames patching as one of several risk responses: accept, mitigate, transfer and avoid. When a patch is not available, cannot be applied in time or would cause unacceptable disruption, apply a pre-approved mitigation:

| Mitigation type | Examples | Typical groups |
|---|---|---|
| Disable the vulnerable feature | Turn off a protocol, plugin or service | All |
| Reduce exposure | Remove internet exposure, restrict source addresses, move behind a proxy or VPN | MG-03, MG-05, MG-06 |
| Isolate | Micro-segmentation, separate VLAN, block outbound traffic | MG-07, MG-08 |
| Add detection or blocking | Web application firewall rule, intrusion prevention signature, endpoint rule | MG-01, MG-04 |
| Configuration hardening | Vendor workaround settings, stricter permissions | All |
| Avoid | Uninstall the software or decommission the asset | All |
| Transfer | Move the workload to a managed or SaaS service where the provider maintains it | MG-05, MG-08 |

Requirements:

- Security architecture MUST review the mitigation menu for each group at least annually so it is ready before it is needed.
- Every mitigation applied MUST be recorded with the vulnerability or update it covers, its expected removal date and the permanent fix ticket.
- For unpatchable assets, apply more than one layer of mitigation, and reassess alternatives to patching at least [annually].

## 13. Exceptions and risk acceptance

<!-- Guidance: Make exceptions visible, time-bound and owned. Pitfall: open-ended exceptions that outlive the people who approved them. -->

An exception is needed when a group cannot meet its cadence, a mitigation cannot be applied, or a statement in section 5 cannot be met.

| Field | Content |
|---|---|
| Exception ID | EXC-PATCH-NNN |
| Statement or deadline affected | [PATCH-xx, vulnerability ID] |
| Assets | [List or group] |
| Reason | [Vendor certification, business peak, technical incompatibility] |
| Compensating controls | [Mitigations from section 12] |
| Residual risk | [Low / Medium / High, with rationale] |
| Approver | Per RACI in section 3 |
| Expiry | [Date, at most 90 days; any renewal beyond 90 days needs CISO approval] |

| Exception ID | Assets | Reason | Expiry | Approver |
|---|---|---|---|---|
| EXC-PATCH-001 *(Example)* | MG-07 scanners | Vendor certifies bundle twice a year | YYYY-MM-DD | Asset owner |
| EXC-PATCH-002 *(Example)* | MG-08 reporting server | End of life, replacement in progress | YYYY-MM-DD | CISO |

Exceptions concerning vulnerability deadlines are recorded in the vulnerability management process and referenced here, not duplicated.

## 14. Evidence, metrics and reporting

<!-- Guidance: Use metrics that show performance by asset importance and urgency, not a single raw count. Pitfall: reporting "number of open vulnerabilities", which rises with better scanning and hides what matters. -->

NIST SP 800-40 Rev. 4 recommends enterprise-level metrics that are actionable, built from the low-level data tools already collect, and broken down by the relative importance of assets and vulnerabilities. This policy uses:

| Metric ID | Metric | Formula | Target | Audience |
|---|---|---|---|---|
| PM-01 | Inventory coverage | assets with owner and maintenance group / assets discovered | 100 % | Policy owner |
| PM-02 | Routine compliance by group | assets at current routine baseline / assets in group | [95] % | Group owners |
| PM-03 | On-time update rate by importance cell | updates installed by deadline / updates due, per asset importance and urgency | [90] % high-importance cells | Leadership |
| PM-04 | Mean and median time to update | average and median of (install time minus release or notice time) per cell | Trend down | Group owners |
| PM-05 | End-of-life exposure | assets past end of support / total assets | [0] % excluding approved exceptions | Leadership |
| PM-06 | Mitigation age | days since temporary mitigation applied, open items | None older than [90] days | CISO |
| PM-07 | Failed update rate | deployments rolled back / deployments | below [2] % | Group owners |
| PM-08 | Active exceptions | count and age of open EXC-PATCH records | Trend down | Policy owner |

*Example* for PM-03, one month at Corvid Commerce, high-importance assets:

| Urgency | Updates due | Installed by deadline | On-time rate | Median days |
|---|---|---|---|---|
| Emergency | 6 | 6 | 100 % | 1 |
| Expedited | 25 | 22 | 88 % | 5 |
| Routine | 420 | 399 | 95 % | 9 |
| Total | 451 | 427 | 94.7 % | Not applicable |

In this *Example*, "deadline" means the vulnerability policy deadline for emergency and expedited updates and the group's routine cadence for routine updates.

Evidence retained for at least [13] months: change records, deployment reports, independent verification exports, exception records and the monthly metrics pack.

## 15. Procurement and supplier requirements

<!-- Guidance: Make maintainability a buying criterion. Pitfall: buying products whose vendors patch rarely or only on request. -->

Before purchase or renewal, procurement and the future group owner MUST obtain from the supplier:

1. the support period committed for security updates, in years;
2. how and how often updates are released, and how customers are notified;
3. whether updates can be deployed automatically, staged and rolled back;
4. the supplier's vulnerability disclosure process and advisory format;
5. whether a software bill of materials is provided;
6. for SaaS and managed services, which updates the provider applies and which remain the customer's duty.

Products that cannot be maintained within an existing maintenance group SHOULD NOT be bought unless the policy owner approves a new group and its plan.

## 16. Review and related documents

<!-- Guidance: State when the policy is reviewed and what it connects to. -->

The policy owner reviews this policy at least annually, and after any SEV1 or SEV2 incident (as defined in Incident Severity Matrix, `ops/incident-severity-matrix`) caused by a missing update or by a failed update. Maintenance groups and the mitigation menu are reviewed with it.

Related documents:

- Vulnerability Management Policy (`security/vulnerability-management-policy`): prioritisation and remediation deadlines.
- Kubernetes Cluster Design (`ops/kubernetes-cluster-design`) and Kubernetes Cluster Upgrade Runbook (`ops/kubernetes-cluster-upgrade-runbook`): cluster version policy and minor upgrades.
- Change Request (`ops/change-request`) and Maintenance Notice (`ops/maintenance-notice`): change control and notice.
- Backup Policy (`ops/backup-policy`): backups that rollback depends on.
- Asset Inventory (`compliance/asset-inventory`): inventory records.
- Supplier Security Assessment (`compliance/supplier-security-assessment`): supplier checks in section 15.
- Information Security Policy (`compliance/information-security-policy`): parent policy.

## 17. Glossary and references

<!-- Guidance: Define terms readers outside IT operations need, and list sources with the version checked. -->

### 17.1 Glossary

| Term | Meaning |
|---|---|
| Patch or update | Vendor-supplied change to software or firmware that fixes defects or vulnerabilities or adds features |
| Maintenance group | Set of assets with similar characteristics that share one maintenance plan |
| Maintenance plan | Agreed method, cadence, window, testing and rollback for a maintenance group |
| Routine patching | Planned delivery of updates on a regular cycle |
| Emergency patching | Accelerated delivery of an update in response to an urgent risk |
| Emergency mitigation | Temporary measure that reduces risk when a patch cannot be applied in time |
| Unpatchable asset | Asset that cannot receive updates, protected by long-term mitigations |
| Testing ring | Subset of assets that receives an update before the next subset |
| End of support | Date after which a vendor no longer releases security updates |
| KEV | CISA Known Exploited Vulnerabilities catalog |

### 17.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, csrc.nist.gov/pubs/sp/800/40/r4/final | April 2022 (published 2022-04-06) | Preventive maintenance framing, maintenance groups, four risk response scenarios, phased deployment, metrics |
| CISA BOD 26-04, Prioritizing Security Updates Based on Risk, cisa.gov | Issued 2026-06-10 | Risk factors and relationship to timelines |
| CISA Known Exploited Vulnerabilities catalog, cisa.gov/known-exploited-vulnerabilities | Living catalog | Exploitation evidence |
| [Vendor end-of-support calendars] | [Date checked] | Section 11 |

## Standard and licence note

Based on NIST SP 800-40 Rev. 4, *Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology* (April 2022), and CISA Binding Operational Directive 26-04 (June 2026), both US Government works. Concepts are summarised in original words; no text or table is copied, and the directive's timeline table is deliberately not reproduced. Cadences, targets and examples in this template are illustrative and not normative. This template is original text written for this collection. Check the current NIST publication and the current directive and implementation guidance at cisa.gov before use. Template licence: MIT.