Patch Management Policy Template (NIST SP 800-40 Rev. 4)

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.

Document control

Approvals

Revision history

Contents

1. Purpose
2. Scope
3. Roles and responsibilities
4. Principles
5. Policy statements
6. Maintenance groups
7. Risk response scenarios and cadences
8. Testing rings and staged deployment
9. Deployment windows and change control
10. Verification and rollback
11. End-of-life software
12. Mitigations when no patch exists
13. Exceptions and risk acceptance
14. Evidence, metrics and reporting
15. Procurement and supplier requirements
16. Review and related documents
17. Glossary and references

1. Purpose

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

2.1 In scope

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

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

4. Principles

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

6. Maintenance groups

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.

7. Risk response scenarios and cadences

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.

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.

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.

8. Testing rings and staged deployment

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.

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

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

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

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

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.

12. Mitigations when no patch exists

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:

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

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.

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

14. Evidence, metrics and reporting

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:

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

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

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

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

17.1 Glossary

17.2 References

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.