Patch Management Policy Template: Timelines, Testing and Exceptions

Most patching failures are not technical: they come from a policy that never said who decides, how fast, or what happens when a system cannot be patched. This template gives you numbered policy statements for patch timelines, testing, emergency patching, unpatchable and end-of-life assets, exceptions and measurement. It follows the structure of NIST SP 800-40 Rev. 4, uses the CISA Known Exploited Vulnerabilities (KEV) catalog as the prioritisation trigger, and includes the identity controls that patching tools and patched hosts need. It is written for security, IT operations and risk leaders who need a policy they can adopt quickly and defend to auditors. Adapt the values in brackets to your risk appetite and have the final text approved through your normal governance route.

How to use this template

• Replace text in square brackets, such as [Organisation], [CISO] and [7 days], with your own terms and values. Timelines shown in brackets are illustrative starting points, not regulatory requirements.
• "Must" is a mandatory requirement; "should" is recommended practice where a documented deviation is acceptable.
• Keep this policy short and stable. Put product-specific detail (WSUS or Intune rings, Linux repository mirrors, maintenance windows) in a supporting patching standard or procedure that can change without re-approval.
• This policy covers applying fixes. Scanning, discovery and vulnerability prioritisation sit in the companion Vulnerability Management Policy Template; use both together so the two timelines match.
• Check the timelines against any contractual or regulatory obligations that bind you. US federal civilian agencies, for example, are bound by CISA BOD 22-01; most other organisations adopt similar targets voluntarily.

Choosing your remediation timelines

The table below is a starting point. NIST SP 800-40 Rev. 4 recommends setting deadlines by the combination of asset importance and vulnerability severity rather than one number for everything, and measuring against those deadlines.

For reference, BOD 22-01 requires federal agencies to remediate KEV entries within two weeks, or within six months for CVE IDs assigned before 2021, and allows CISA to set shorter deadlines for grave risk. Exploitation evidence (KEV) and exploit likelihood (FIRST EPSS) should be able to move an item up a category; a high CVSS score alone should not be the only driver.

1. Purpose

This policy sets the requirements for identifying, testing, deploying and verifying security updates across [Organisation]'s technology estate, and for managing risk where updates cannot be applied. Its aim is to reduce the window in which known vulnerabilities can be exploited, while protecting the availability of business services, in line with [Organisation]'s [Information Security Policy].

2. Scope

This policy applies to all technology assets owned, managed or operated by or for [Organisation], including:

• Servers, virtual machines and hypervisors, on premises and in cloud infrastructure (IaaS).
• End-user devices: laptops, desktops, mobile devices and, where they access [Organisation] data, personal devices under the [BYOD Policy].
• Operating systems, applications, browsers and browser extensions, databases, middleware and runtime libraries.
• Network and security appliances: firewalls, VPN concentrators, load balancers, switches, routers and wireless controllers, including firmware.
• Container base images, machine images, serverless runtimes and infrastructure-as-code modules.
• Operational technology (OT) and IoT devices, subject to the safety provisions in section 4.6.
• Patching, deployment and endpoint management tools themselves.

Software developed by [Organisation] is covered by the [Secure SDLC Policy]; its third-party dependencies are in scope here once deployed. SaaS services patched by the provider are in scope for supplier assurance only (section 4.8). The policy applies to all staff, contractors and suppliers who administer in-scope assets.

3. Roles and responsibilities

4. Policy statements

4.1 Inventory and maintenance groups

• All in-scope assets must be recorded in [CMDB / asset inventory] with an owner, platform, management tool, business importance and any outage restrictions.
• Inventory should be kept current by continuous automated discovery (platform APIs, agents, authenticated scans), not periodic manual review.
• Assets must be assigned to a maintenance group: a set of assets with similar characteristics that share the same patching approach. Assets that cannot be patched must still belong to a group with a defined risk response.
• Assets not in the inventory that are found on the network must be investigated within [5 working days] and either onboarded or removed.

4.2 Identifying and categorising updates

• [Vulnerability management team] must monitor vendor advisories, the CISA KEV catalog and [threat intelligence sources] at least [daily].
• Every security update must be assigned a category from the timeline table within [1 working day] of release.
• A vulnerability added to the CISA KEV catalog, or reported by the vendor as actively exploited, must be treated as Emergency for affected internet-facing and critical assets.
• The remediation clock starts at vendor release of the fix, or at KEV listing if later, and is recorded in [ticketing system].

4.3 Testing and deployment

• Routine updates must be deployed in rings: [pilot / canary group], then [early adopters], then [broad deployment], with defined soak times of [24 to 72 hours] between rings.
• Testing must be proportionate and short. Testing must not be used as a reason to exceed the remediation timeline; where testing cannot finish in time, apply a mitigation and raise an exception.
• Every deployment must have a documented rollback method (uninstall, snapshot, image revert or configuration restore) tested for each maintenance group at least [annually].
• End-user devices must have automatic updates enabled for the operating system, browsers and office applications, enforced through [MDM / endpoint management], with a forced install and restart after a grace period of [3 days].
• Routine patching must run as a pre-approved standard change under the [Change Management Policy].

4.4 Emergency patching and mitigation

• When an Emergency is declared, the accelerated route applies: canary testing of [hours, not days], emergency change approval by [named approvers], and deployment outside normal windows if needed.
• Where no fix exists, a temporary mitigation (configuration change, feature disablement, WAF or IPS rule, network isolation) must be applied within the Emergency timeline and replaced with the permanent fix within [7 days] of its release.
• For a vulnerability exploited before patching, the host must be assessed for compromise. Patching alone does not remove persistence or stolen credentials.

4.5 Verification

• Remediation must be verified by authenticated scanning or endpoint telemetry, not by deployment-tool success status alone.
• Updates that require a restart or service recycle are not complete until the restart has happened.
• Tickets must not be closed until verification succeeds.

4.6 End-of-life, unpatchable and OT assets

• Software and hardware must be supported by the vendor for security updates. Assets reaching end of support must have a replacement plan approved [12 months] before the date.
• Unsupported or unpatchable assets must be isolated by network segmentation, have unnecessary services disabled and be reviewed at least [quarterly] until removed.
• OT and safety-related systems must follow manufacturer-approved update procedures and scheduled outage windows. Where updates are delayed for safety or warranty reasons, compensating controls must be documented.

4.7 Patching tools and machine identities

• Patching, configuration management and deployment tools must be treated as tier 0 systems: hardened, patched first, restricted to named administrators with phishing-resistant MFA.
• Service accounts, agent credentials and SSH keys used by patching tools must be unique per tool and environment, stored in [approved secrets manager or PAM vault], scoped to the systems they manage and rotated at least [every 90 days] or on staff change.
• Patching tools must not use shared domain administrator accounts. Rights should be delegated to the minimum needed to install updates.
• Package and update sources must be authenticated: vendor signatures verified, internal repository mirrors protected from unauthorised write, and repository signing keys held in [HSM / key vault].
• Where a host was exploited, all secrets it held (service account passwords, API tokens, certificates, machine keys) must be rotated after patching.

4.8 Suppliers and cloud services

• Contracts for managed services and supplied systems must require security updates within timelines no weaker than this policy, and notification of exploited vulnerabilities within [24 hours].
• For SaaS, [Procurement and third-party risk] must confirm the provider's patching commitments; [Organisation] remains responsible for patching any on-premises connectors or agents.

5. Exceptions

• An exception is required for any asset that will miss its remediation timeline. It must be requested by the asset owner before the deadline, recorded in [risk register], and state the vulnerability, affected assets, reason, compensating controls and expiry date.
• Exceptions must use one of the NIST SP 800-40 risk responses: mitigate (compensating controls), transfer (for example to a supplier under contract), avoid (remove the asset or feature) or accept.
• Approval levels: [Security manager] for Medium and Low; [CISO] for Critical and High; [CISO and business executive] for Emergency or KEV items, which should not exceed [30 days].
• Exceptions must not exceed [90 days] and must be re-approved, not rolled over, on expiry.

See the Security Exceptions and Risk Acceptance Guide for a risk acceptance workflow.

6. Compliance and monitoring

[Vulnerability management team] must report the following at least [monthly] to [CISO], broken down by maintenance group, business unit and platform:

NIST SP 800-40 notes that simple patch counts are not actionable and that monthly or unauthenticated scans understate exposure, so metrics must be weighted by asset importance and based on authenticated data. Compliance will also be checked by [internal audit]. Non-compliance may lead to assets being disconnected and to action under [disciplinary procedure].

7. Review and approval

• Policy owner: [CISO]. Approved by: [risk committee / executive board] on [date].
• This policy must be reviewed at least annually and after any significant incident caused by a missing patch, any change to regulatory obligations, or a major change in the estate.
• Version history: [version], [date], [summary of change], [approver].
• Related documents: [Information Security Policy], [Vulnerability Management Policy], [Change Management Policy], [Asset Management Policy], [Secure SDLC Policy], [Incident Response Plan].

Implementation guidance

Rolling out the policy

1. Baseline: measure current time to patch and inventory coverage for [3 months] before setting targets, so timelines are achievable.
2. Fix the inventory first: map every asset to an owner and maintenance group. Unknown assets are the usual reason metrics look better than reality.
3. Adopt KEV as the emergency trigger: subscribe to KEV updates and automate matching against your inventory.
4. Build rings and rollback: set up pilot groups per maintenance group and test rollback before you rely on it in an emergency.
5. Pilot the timelines on one business unit for a quarter, tune the values, then publish organisation-wide.
6. Run an emergency drill: simulate a KEV listing on an internet-facing product and time detection to verified fix.

Decisions for small and large organisations

• Small organisations: rely on automatic updates and managed services, keep one ring plus a small pilot group, and spend effort on edge devices (VPNs, firewalls) and end-of-life replacement.
• Large organisations: separate timelines by asset importance, publish maintenance group calendars, and automate KEV matching and ticket creation.
• Regulated or OT-heavy organisations: agree manufacturer-validated windows in advance and document compensating controls in the policy, not in individual exceptions.

Common failure patterns

• Patched but still compromised: in the ToolShell SharePoint exploitation, attackers stole ASP.NET machine keys before patches were applied, and access persisted until those keys were rotated. Statement 4.7 exists for this reason.
• Edge devices left out: firewalls and VPN appliances managed outside the patching tool, with firmware updated only during projects.
• Success equals installed: tickets closed on deployment status while hosts wait for a restart.
• Permanent exceptions: exceptions rolled over each quarter with no replacement funding.
• Over-privileged patch accounts: one domain admin service account used by the deployment tool across every server.

Framework mapping

Implementation detail sits in these guides: the Patch Management Guide for tooling and rings, the Vulnerability Management Guide for prioritisation, the Zero-Day and Exploited Vulnerabilities Guide for emergency response, and the Asset Inventory and CMDB Security Guide for discovery. Sources: NIST SP 800-40 Rev. 4, CISA BOD 22-01, CISA KEV and NCSC device update guidance.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Patch Management Buyer's Guide · Vulnerability Management Policy Template · Change Management Policy Template · Secrets Management Guide