Patch Management Policy: Timelines, Exceptions and Evidence

TL;DR: A patch management policy sets scope, owners, deadlines by severity tier, a written exception path and the evidence that proves each patch was installed and verified. The Cybersecurity and Infrastructure Security Agency (CISA) revoked Binding Operational Directive (BOD) 22-01 through BOD 26-04, which ties urgency to exposure and exploitability. Exceptions need a named risk owner, compensating controls and an expiry date. In our reading, auditors look for post-change scans, not closed tickets.

What patch management is and what a policy has to settle

Patch management is the work of finding, testing and applying software updates across everything an organization runs. A patch management policy is the written rulebook for that work. It sets what is in scope, who owns each step, how fast fixes must land and what counts as proof that they did.

The National Institute of Standards and Technology (NIST) supplies the process definition most programs start from. Verification sits inside the process.

The same publication frames patching as "a cost of doing business" (NIST). In our reading, that phrase works well when a business owner asks why a maintenance window keeps appearing on the calendar.

The policy is a separate artifact from the process. One vendor guide describes it as a documented framework covering how an organization identifies, prioritizes, tests and deploys updates to reduce vulnerabilities, support compliance and prevent disruption (Tanium). The tools do the patching. The policy decides the rules they run under.

Patch management and vulnerability management overlap, but they are different jobs. Vulnerability management is the continuous process of identifying, prioritizing, remediating and reporting on security weaknesses, while patch management is narrower in scope (Rapid7). Patching is one remedy among several. Compensating controls are another, often used when a fix is not yet available, to buy time before remediation (Rapid7).

What the policy has to settle

A policy that leaves any of these open will be argued over during the next urgent release.

On scope, a typical policy covers operating systems, apps, firmware and connected devices across on-premises, cloud and hybrid environments (Tanium). On ownership, it names who is responsible for each stage, from identification through verification (Tanium).

Exceptions need their own written path. The same guide calls for a formal process for requesting, approving and tracking them, and for reviewing the policy itself, typically annually or after a major security incident (Tanium).

We think the evidence row is where most policies are thinnest. A deadline nobody can prove was met is a weak control. For how this responsibility sits with the chief information security officer (CISO), see what a CISO does.

How NIST SP 800-40 Rev. 4 frames patching as preventive maintenance

The National Institute of Standards and Technology (NIST) built Special Publication (SP) 800-40 Rev. 4 as a planning document. Its predecessor was a technology primer. In our reading, that change of purpose matters more to a policy author than any single recommendation in it.

From tools to planning

Rev. 3 was finalized on July 22, 2013, under the title Guide to Enterprise Patch Management Technologies. Its stated aim was to help organizations understand the basics of enterprise patch management technologies. It defined patch management as identifying, acquiring, installing, and verifying patches. Prioritization was not one of those steps.

Rev. 4 started as an initial public draft on November 17, 2021, with comments due by January 10, 2022. Its title swapped Technologies for Planning, and it added prioritization to the definition.

The draft announcement from the National Cybersecurity Center of Excellence (NCCoE) was blunt: keeping software current with patches remains a problem for most organizations.

The argument it makes to the business

The guide names a specific gap. It says there is often a divide between business/mission owners and security/technology management about the value of patching. Its answer is an enterprise strategy to simplify and operationalize patching, presented as maintenance that helps prevent compromises, data breaches, operational disruptions, and other adverse events.

In our reading, this is the framing a CISO can carry into a budget or board conversation. Patching is upkeep with an owner and a schedule. It is not a series of emergencies.

The steps a policy should name

A companion draft, SP 1800-31, covered tooling for the inventory and patching capabilities organizations need for routine and emergency patching situations, as well as implementing workarounds and other alternatives to patching. That split between routine and emergency work, plus a path for when patching is not possible, is a useful skeleton for a policy.

We think verification is the step policies most often leave vague. A policy that ends at deployment gives auditors a promise and no proof. Later sections of this guide cover the evidence that closes that gap.

How the federal directives and NIST guidance compare

The four documents most often quoted in patch policies split into two kinds. CISA's Binding Operational Directives (BODs) bind a defined set of federal systems and set clocks. The NIST SP 800-40 revisions explain how to run a patch program and leave the clock to you.

The federal directives

BOD 22-01 tied remediation to CISA's Known Exploited Vulnerabilities (KEV) catalog. It required action within 6 months for vulnerabilities with a Common Vulnerabilities and Exposures (CVE) ID assigned prior to 2021 and within two weeks for all other vulnerabilities. It also gave agencies 60 days to update their internal procedures.

BOD 26-04 supersedes and revokes BOD 22-01 and the older BOD 19-02. Its stated approach focuses patching efforts on the areas of highest risk rather than treating all vulnerabilities and systems equally. Urgency turns on four variables:

• Asset Exposure: whether the asset is publicly exposed.
• KEV Status: whether the CVE is in the catalog.
• Exploit Automation: whether an adversary can automate every step.
• Technical Impact: whether exploitation yields partial or total control.

Both directives do not apply to national security systems or to certain defense and intelligence systems.

The NIST guidance

Rev. 3 was a technology primer. It briefly discusses metrics for measuring the effectiveness of patch tools. Rev. 4, covered in the previous section, replaced it with a planning frame.

Using the comparison

In our reading, a private-sector policy that copied the BOD 22-01 clocks now points at a revoked text. That alone is a reason to revise it. The four BOD 26-04 variables are a ready checklist for your own severity tiers, even if no directive binds you.

Check three things in your current document:

1. Any citation of BOD 22-01 or SP 800-40 Rev. 3 as a live source.
2. Whether your tiers consider exposure and exploit automation, not only a severity score.
3. Whether your deadlines are your own choice, documented as such, since the NIST guidance does not hand you any.

How a policy should handle emergency patching

Emergency patching breaks the normal schedule.

Define the trigger

A usable trigger is external and checkable. A listing in CISA's Known Exploited Vulnerabilities (KEV) catalog is one. Under the now-revoked Binding Operational Directive (BOD) 22-01, CISA said it would add entries based on reliable evidence that the exploit is being actively used against organizations.

The window can be short. Huntress wrote that a zero-day can go from disclosed to actively exploited within hours. CISA's current directive warned that attackers' use of artificial intelligence (AI) may further narrow the time defenders have to react.

In our reading, the trigger works best when it pairs an outside signal with an inside one. For the outside signal, CISA publishes answers to KEV Status, Exploit Automation, and Technical Impact for every CVE ID. For the inside signal, the directive defined a publicly exposed resource as one accessible to unauthenticated or untrusted entities via public networks.

Here is how that plays out:

• A KEV-listed flaw on an internet-facing VPN gateway goes out tonight.
• The same flaw on an isolated lab server waits for the next cycle.

Name who can approve without full testing

BOD 22-01 required agency policies to assign roles and responsibilities for its actions. An emergency clause needs the same thing in plain terms: one named approver and a deputy who can authorize deployment with reduced testing.

Huntress described an approval workflow as setting out who signs off before something hits production. It paired that with rollback procedures covering what happens when a patch breaks something.

We think the approver should hold authority over both security risk and service risk. Usually that means the CISO or a delegate acting with the system owner. The rollback plan should be written before the deploy, not after it fails.

Hold the line while a fix is pending

Sometimes a patch does not exist yet, or it cannot be applied safely. In that case the policy should list the stopgaps it accepts:

• Pull the asset off public networks or put it behind an access gateway.
• Disable the vulnerable feature.
• Add detection rules for the exploit.
• Watch the asset more closely.

Each stopgap gets an owner and an end date. In our reading, a compensating control without an expiry becomes a permanent exception by default.

Record the decision afterward

BOD 22-01 told agencies to set internal tracking and reporting requirements and to establish internal validation and enforcement procedures. For a private-sector policy, the record can be short. It should feed the exceptions process covered earlier.

The verification row matters most. Huntress argued that specific roles should own specific phases: discovery, testing, deployment, and verification. An emergency record that stops at deployment leaves the last phase unowned.

How to approve, time-box and review patch exceptions

Every patch policy meets systems that cannot take an update on schedule. Tanium's policy guide names the usual causes: legacy software, critical systems with operational constraints, or complex application dependencies. An exception process turns those cases into decisions that are recorded, owned and set to expire, so they do not become quiet gaps.

The same guide calls for a formal process for requesting, approving, and tracking exceptions, with compensating controls documented for any system where a patch is deferred. It describes service-level agreement (SLA) timelines as "guardrails, not absolutes". In our reading, an exception is where that flexibility becomes formal. The deadline can move, but only in writing and only with a signature.

What a request should carry

The owner field matters most. NIST SP 800-40 Rev. 4 observes that there is often a divide between business/mission owners and security/technology management about the value of patching. We think the signature on an exception should belong to the business owner, with security confirming the controls. That puts the risk decision with the person who runs the system. For more on where that line falls, see our guide to CISO accountability.

Two worked examples

Legacy medical device. An imaging workstation runs an older operating system that the manufacturer has not cleared for updates. The clinical department head owns the exception. Controls might include a separate virtual local area network (VLAN), blocked internet access and alerting on unusual connections. The expiry ties to the manufacturer's clearance or the replacement date in the capital plan.

Vendor-certified build. A plant control system or trading platform is supported only on a certified configuration, and an operating system patch would void that support. The application owner signs. Controls might include restricted administrative access, application allowlisting and extra logging. The expiry ties to the vendor's next certified release, and the request should note the vendor's stated timing.

Review cadence

The expiry date forces the review. Before an exception lapses, the owner either closes it or renews it with fresh evidence that the controls still work. In our reading, an exception renewed several times in a row should go up a level, since it has become a standing risk rather than a delay.

The policy itself needs a review too. Tanium suggests this happens typically annually or after a major security incident. The open exception register is a useful input to that review: it shows where the policy's timelines do not fit the estate.

What evidence auditors and boards ask to see

Auditors and directors seldom start by reading the policy. They ask for the records that show it runs. Tanium's guide states the expectation plainly: a policy provides the documentation auditors expect. In our reading, four records carry most of that weight.

The four records

Coverage comes first because every other figure is a fraction of it. The inventory should match what the policy claims to cover: operating systems, apps, firmware, and connected devices across on-premises, cloud, and hybrid environments. An asset missing from the register never shows up as late.

Verification is easy to skip. The National Institute of Standards and Technology (NIST) defines enterprise patch management in SP 800-40 Rev. 4 as a sequence that ends in verifying the installation of patches, updates, and upgrades. A ticket closed on deployment is a claim. A post-change scan is evidence.

Mapping records to frameworks

The practical step is a single matrix. Give it one row per record and one column per framework the organization reports against. Fill each cell with the control reference from the current edition of that standard.

Beside each row, record the evidence location, the owner and the last refresh date. An auditor can then pull a sample without a meeting.

Federal agencies, and suppliers that mirror federal practice, should check their citations. Binding Operational Directive (BOD) 26-04 from the Cybersecurity and Infrastructure Security Agency (CISA) supersedes and hereby revokes BOD 19-02 and consolidates and clarifies vulnerability remediation guidelines. Evidence packs that still point to the older directives need updating.

One number for the board

Boards want a trend line, not four tables. Tanium gives an example objective of 95 percent patch compliance across all production systems within service-level agreement (SLA) windows. We think a stricter version serves a board better: the share of in-scope assets with no overdue top-tier patch and no expired exception. That one line folds coverage, timeliness and exception discipline together.

Tiering matters here. BOD 26-04 pairs prioritizing high-risk vulnerabilities for timely action, while deferring action against low-risk vulnerabilities. In our reading, a board metric that counts every low-tier deferral as a failure punishes the behavior that directive asks for. Put the top-tier figure in the headline and keep lower tiers in the appendix.

For how committees take in metrics like this, see our board committee oversight report and the glossary entry on board cybersecurity oversight.

A patch management policy template, section by section

The outline below follows the order most policy documents use. Each part says what to write and who owns it. Change the wording to fit your organization, but keep every part.

1. Purpose and scope. State what the policy protects and which assets it covers. Name third-party software explicitly. Tanium calls it a common source of vulnerabilities.
2. Severity tiers and target timelines. See the table below.
3. Testing and deployment. Tanium's outline puts patches through a dedicated test environment before production. It requires backups before any deployment and rolls out in rings, starting with a small group of systems. Add the rollback steps covered earlier.
4. Emergency procedure. Name who can invoke it and which normal steps it may skip. Point to the emergency section for the full process.
5. Exceptions. Link to the exception process set out earlier. Do not restate it inside this policy.
6. Communication. Say when and how affected teams and end users are told before scheduled deployments.
7. Records and review. Keep deployment logs and verification scans for each cycle. Check that every external reference in the policy is still current.

Severity tiers

The timelines here are Tanium's example of a common approach. They are not our figures and not a federal requirement.

BOD 26-04 starts its urgency test by asking whether the vulnerable asset is publicly exposed. In our reading, the policy should let that answer move a finding up the table.

Here is how that works in practice. A High finding on a customer login portal that anyone on the internet can reach moves into the Critical row and runs on the Critical clock. The same finding on an internal reporting server stays High.

References to retire

Two common citations are out of date.

• BOD 26-04 revoked BOD 22-01.
• National Institute of Standards and Technology (NIST) Special Publication (SP) 800-40 Rev. 4 superseded Rev. 3, dated July 2013.

Monday checklist

• Pull the current approved policy, not a draft copy.
• Flag any citation of BOD 22-01 or SP 800-40 Rev. 3.
• List open exceptions that have no expiry date.
• Confirm that a post-change verification scan exists for the last patch cycle.

What this guide does not cover

This guide does not list control numbers for individual compliance frameworks. It describes what federal directives and NIST guidance say. For the rules and the record behind it, see What Does a CISO Do? Responsibilities, Reporting Lines and Required Skills.