The Vulnerability Management Process for IT Teams, With Deadlines Built on CISA's BOD 26-04

Updated: November 2026. BOD 26-04 timelines, this week's KEV entries, CVSS and EPSS versions and CIS Control 7 cadences checked against CISA, NIST, FIRST and CIS on 11 November 2026.

Your scanner hands back a list of findings longer than your week, and nobody has said which ones can wait. A small IT team needs a rule for what gets fixed first, by when, and who signs off on the rest. This guide sets out a six-step vulnerability management process for IT teams, with deadlines adapted from CISA's newest patching directive and an exception log for what can't be fixed yet.

TL;DR

• What it is. A repeating loop that finds software flaws on your assets, ranks them, fixes them and confirms the fix held.
• Six steps. Scope and inventory, scan, prioritize, remediate or respond, verify, then report and improve.
• Deadlines. Four yes-or-no questions from CISA's BOD 26-04 set the clock, from 3 days to the next upgrade.
• Exceptions. Whatever can't be fixed in time gets an owner, a compensating control and an expiry date.
• Proof. Report the share of fixes landed by deadline, split by asset importance.

What Is the Vulnerability Management Process?

The vulnerability management process is the set of steps an IT team repeats to find software flaws on its assets, decide which to fix first, fix or otherwise handle them, and confirm the fix held. It runs as a loop, because new vulnerabilities arrive every week and last month's scan describes last month's network.

NIST describes the same loop in SP 800-40 Rev. 4, its patch management guide, final since 6 April 2022 and still current. Its life cycle has three parts: know when new vulnerabilities affect your assets, plan the risk response, then execute it by preparing, rolling out, verifying and monitoring. NIST treats patching as preventive maintenance, a standing cost rather than a project.

The stakes moved this year. Verizon's 2026 Data Breach Investigations Report found that 31% of breaches started with exploited software vulnerabilities, ahead of stolen passwords as the top way in.

Vulnerability Management Process vs Program vs System

No standard defines the three terms against each other, so this is our working split.

A vulnerability management program is the policy layer: who owns which assets, which deadlines apply, who approves an exception and which numbers leadership sees. CIS Safeguard 7.1 asks for the process in writing, reviewed every year or after a significant change. If you report against NIST CSF, our guide maps scanning to NIST CSF ID.RA.

A vulnerability management system is the tooling. Swap the scanner and the deadlines, owners and rescan rule stay put. For scanners side by side, see our roundup of vulnerability management tools.

The 6 Steps of the Vulnerability Management Process

Six steps, each one handing something concrete to the next:

1. Scope and inventory. List the assets, their owners and which ones face the internet.
2. Scan and identify. Find the flaws, inside and outside the firewall.
3. Prioritize. Give every finding a deadline.
4. Remediate or respond. Patch, mitigate, transfer, avoid or accept, and record which.
5. Verify. Close the ticket on a clean rescan.
6. Report and improve. Measure what landed on time and change what didn't.

The loop below shows what each step hands on, and the CIS Control 7 cadence that sets its pace.

Scope and Inventory

You can't patch what you don't know you own. SP 800-40r4 asks for current software inventories across physical and virtual assets, including OT, IoT and containers, and calls a close-to-complete inventory built with automated discovery the realistic goal. Our guide to asset inventory tools compares the options.

Then sort assets into maintenance groups, NIST's term for assets with similar maintenance needs: laptops that patch on a schedule, servers that need a window, appliances only the vendor can update. Each group gets its own plan, so an odd asset doesn't become a permanent exception.

Add one column the deadline tables need later: can this asset be reached from the internet? BOD 26-04 makes exposure its first question and leaves the answer to the asset's owner. Our guide to attack surface mapping covers finding the internet-facing pieces.

Scan and Identify

CIS Control 7 sets the floor. Safeguard 7.5 asks for automated internal scans at least quarterly, authenticated and unauthenticated, with a SCAP-compliant tool. Safeguard 7.6 asks for automated external scans at least monthly.

Scanners find flaws, and CISA's Known Exploited Vulnerabilities (KEV) catalog says which ones attackers already use. A CVE gets in only with a CVE ID, reliable evidence of exploitation in the wild and clear remediation guidance. CISA tells organizations outside government to use KEV in their prioritization too, and publishes it as a JSON feed your tools can pull.

Prioritize

Prioritizing means turning each finding into a deadline. BOD 26-04 does it with four yes-or-no questions. Is the asset publicly exposed? Is the CVE in KEV? Can an attacker automate every step of the exploit? Does success give partial or total control? CISA publishes the last three answers for CVE IDs through its Vulnrichment program, so exposure is the one you answer yourself.

CVSS and EPSS become tie-breakers inside a deadline band. CVSS measures severity, and FIRST says it's at version 4.0, released in November 2023. The CVSS User Guide itself says a base score shouldn't be used alone to assess risk, and CISA repeats the point in its BOD 26-04 guidance. For how the numbers get assigned, see how CVSS scores work.

EPSS estimates how likely a CVE is to be exploited in the next 30 days. FIRST's current model is EPSS v5, published since 15 June 2026, replacing v4. For scale, the PrintNightmare flaw scored 0.998 on 10 November 2026, higher than 99.9% of scored CVEs.

In r/cybersecurity, a small team without a dedicated vulnerability person turned scanning on and got 400+ open findings. Replies put context ahead of raw severity: KEV-listed and internet-facing first, asset criticality times severity, a named owner per asset. One suggests updating all software first to clear whole batches.

Remediate or Respond

SP 800-40r4 lists four risk responses: accept, mitigate, transfer or avoid. Patching is one way to mitigate, alongside disabling a vulnerable feature or isolating the asset with firewalls and segmentation. Transfer means insurance, or SaaS where the provider patches. Avoid means uninstalling or decommissioning. By NIST's default, you accept the risk of all software you run until you decide otherwise.

NIST also names four scenarios: routine patching, emergency patching, emergency mitigation when no working patch exists, and unpatchable assets that get isolated instead. It warns that postponed routine patching widens the attacker's window and makes emergency patching harder.

Routine patches ride your normal schedule, and our guide to Windows patch rings covers the testing order. Emergency patches skip the queue, on the deadlines below.

If the same fix keeps landing on the same group, script it. Our guide to automating the fix covers where a person should approve first.

Verify

A patch job that reports success isn't proof. SP 800-40r4 asks you to confirm the patch is installed and in effect, then keep watching that nobody uninstalls it. So close the ticket when a rescan stops finding the CVE, not when the deployment tool turns green. A pending reboot can leave old code running, and a rescan that checks file versions catches it. Our guide to patch compliance gaps covers the audit checks behind this.

Report and Improve

CIS Safeguard 7.2 asks for a risk-based remediation process reviewed monthly or more often. Use that review to move deadlines, groups and owners that aren't working, and see our guide to security metrics for presenting the numbers.

Remediation Deadlines Built on BOD 26-04

CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, on 10 June 2026. It applies to US federal information systems, and to contractors only where their contract says so. It doesn't bind a private company, and CISA's KEV page says as much. The tables below are our adaptation of its Table 1 for non-federal teams.

Timelines are calendar days. The clock starts when CISA adds the CVE to KEV or when the finding is first recorded, whichever comes first. Taking a system off the internet moves it to the internal table.

Exploitation often starts early. VulnCheck added 495 vulnerabilities to its own exploited list in the first half of 2026, according to its State of Exploitation report. Of those, 23.43% showed exploitation evidence on or before the day the CVE was published.

Publicly exposed assets

Internal assets

Our column keeps CISA's 3-day and 14-day clocks and folds everything slower into the monthly patch cycle. CIS Safeguards 7.3, 7.4 and 7.7 make monthly patching and remediation the floor, so for a small team the monthly run is the system upgrade. CISA's guidance allows faster patching anyway. A KEV due date is built on CISA's own exposure data, so an internet-facing asset can need a shorter clock than the listed date.

BOD 26-04 itself requires the forensic triage alongside the 3-day fix: agencies must assess whether the system is already compromised. For a small team, we read that as a compromise check: look for signs the flaw was already used before the patch overwrites the evidence. That check belongs in your incident response plan.

The catalog shows the shift. By our count of CISA's JSON feed, 226 of 245 KEV additions in 2025 got 21 days. Of the 162 added from 10 June to 10 November 2026, 126 got 3 days and 36 got 14.

BOD 22-01, the 2021 KEV directive, set default deadlines of six months for CVEs assigned before 2021 and two weeks for all others. CISA revoked it on 10 June 2026. Agencies had to meet the due date listed in the catalog. In 2025 that meant an exploited bug on an internal kiosk usually got the same 21 days as one on an internet-facing VPN. If a guide still quotes one deadline for every KEV entry, it predates June 2026, and our explainer on the patch window covers how exploitation timing plays out.

CISA's own CISA Live! session, about 37 minutes long, walks through BOD 26-04 and its risk-based approach to patching.

A Worked Example From This Week's KEV Additions

Three of the KEV additions on 10 November 2026 show how the tables work.

The Barracuda pair chains together. The bypass gets an attacker in without credentials, and the command injection runs their commands as root. An email gateway faces the internet by design, so both land in the top row of the exposed table: 3 days and a compromise check. The due date is Friday 13 November, which feels about right.

The Chromium bug lets a crafted webpage run code inside the browser sandbox, and KEV gives it 14 days. Browsers apply updates on relaunch, so force the restart and confirm the version on the next scan.

Now a finding from the same scan that isn't in KEV: a missing November Patch Tuesday update on an internal file server. Until CISA publishes Automatable and Technical Impact for a non-KEV CVE, its guidance says to treat them as no and total. That's the bottom row of the internal table, so the fix rides this month's patch cycle.

Three findings, three clocks, and nobody had to argue about whether a CVSS 8.1 beats a 7.9.

Exceptions and Risk Acceptance

Every team ends up with fixes that can't land on time: a server the vendor hasn't certified, a lab machine, an appliance with no patch yet. SP 800-40r4 suggests giving those assets their own maintenance group and plan, rather than piling up exceptions. Track every exception, review them regularly, and move long-term ones into a group of their own.

CISA grants federal agencies no waivers under BOD 26-04. Outside government, exceptions are your call, so log each one.

Machines that can never patch fit NIST's unpatchable scenario, so isolate them instead of renewing the same exception forever. Our guide to legacy systems covers the options.

A May 2026 r/cybersecurity thread asked how small security teams keep up. Replies say ranking doesn't shrink the work, because capacity and maintenance windows are the limit. One describes documenting what can't be patched, accepting the risk with an expiry date and adding mitigating controls.

Metrics That Show the Process Works

SP 800-40r4 warns that simple counts, like the percentage of systems patched, don't tell you what to do next. Its example matrix crosses asset importance (low, moderate, high) with vulnerability importance (low to critical). Each cell shows the share fixed by the deadline, the mean time and the median time. NIST fills the cells with notional numbers, so borrow the layout, not the figures.

Bring these to the monthly review:

• Share fixed by deadline, per matrix cell, starting with the KEV and internet-facing rows.
• Mean and median days to fix per cell, since one stuck server drags the mean but not the median.
• Open KEV findings past their due date, with asset names attached.
• Scan coverage: assets scanned last cycle against assets in the inventory.
• Open exceptions, with this month's expiries flagged.

If the critical, high-importance cell misses its deadline two months running, fix what feeds it: the deadline, the maintenance group or the owner.

Running the Process Across MSP Clients

For an MSP, the process stays the same and the program splits in two. Write one deadline table per contract, agreed before the next KEV entry lands. The MSP runs scans, patching and reports, and the client signs every exception.

OpenFrame is open, AI-native infrastructure for IT and security, with RMM, patching and a native PSA in one system. A prioritized finding becomes a ticket and a patch job. Mingo runs IT operations, writing and scheduling the patch scripts and investigating devices that fail, and Fae resolves support requests. It costs $1 per device per month with 10M AI tokens included, after a 14-day free trial. Flamingo builds OpenFrame, which handles the patch side, while the deadline table and exception log stay with you and your clients.

Start With the Exposure Column

The vulnerability management process is six steps on repeat: know your assets, scan them, give each finding a deadline, fix or respond, verify on a rescan and report what landed on time. BOD 26-04's four questions turn deadlines into a lookup instead of a debate, even outside federal systems. Start by tagging which assets face the internet, because every deadline depends on that answer. Next, see where vulnerability management ends and exposure management begins.