How to find what you expose, decide what to fix first using evidence of real exploitation rather than a severity score, hit a deadline you can defend, and prove the fix actually landed.
Who needs this: CISO, Head of IT Operations, Patch/Endpoint Engineering, Platform and Cloud Engineering, Network Operations, SOC Lead, Risk Manager | Read time: 24 min | Maps to: CSF 2.0 IDENTIFY (ID.AM, ID.RA), PROTECT (PR.PS, PR.IR), DETECT (DE.CM), RESPOND (RS.MI), GOVERN (GV.PO) | CIS Controls 1, 2, 4, 7, 12, 18
Cyber-survivors, gather round, because the numbers this year finally settled an argument we have been having since roughly 2004.
For the first time in the Verizon DBIR's nineteen-year history, vulnerability exploitation overtook credential abuse as the top breach vector — 31% of breaches versus 13% (SecurityWeek). Mandiant's frontline data says the same thing from a different population: exploits were the top initial infection vector at 32%, for the sixth consecutive year (M-Trends 2026). And across the Channel, the UK NCSC handled 429 incidents in its 2024/25 reporting year, of which 204 were nationally significant — three vulnerabilities alone drove 29 of them: Ivanti Connect Secure CVE-2025-0282, Fortinet FortiManager CVE-2024-47575, and Microsoft SharePoint CVE-2025-53770 (NCSC Annual Review 2025).
Now the part that should make you put the coffee down. In the same DBIR dataset, only 26% of CISA KEV vulnerabilities were fully remediated by the 13,000 organizations polled — down from 38% — and median patching time went up to 43 days from 32 (Help Net Security). Exploitation became the number one way in, and our collective response was to get slower at fixing the exact vulnerabilities we know are being used. That is not a technology gap. That is a prioritization and accountability gap, and it is fixable without buying anything.
This chapter builds the fix on CISA's Vulnerability Response Playbook — the 2021 federal document that established the whole model, whose opening line is still the most useful sentence in vulnerability management: "One of the most straightforward and effective means for an organization to prioritize vulnerability response and protect themselves from being compromised is by focusing on vulnerabilities that are already being actively exploited in the wild" (CISA Playbooks). Everything modern — the KEV catalog, tiered SLAs, exception registers, board burndown charts — descends from that one choice. We are going to take the process it defines, supply the four things it deliberately left blank, and end up with a program you can run on a small team.
One caution about that source, in the same spirit as Chapter 13. It was written in November 2021 for federal civilian agencies, and it sets no numeric deadline anywhere — its only temporal language is "in a timely manner," and it defers every hard date to CISA's own binding and emergency directives. It also predates BOD 26-04, the KEV catalog's growth into the industry's default triage input, SSVC in its current published form, and an estate where most of what you expose is cloud and SaaS rather than agency-operated tin. So, the same rule as Chapter 13: where this chapter follows the playbook, it says so. Where it supplies what the playbook left blank — the SLA matrix, the exception process, the metrics and the checklist — that is this book going beyond CISA, not CISA speaking through this book.
CISA's vulnerability response process has five phases: Preparation → Identification → Evaluation → Remediation → Reporting and Notification. It is explicitly not a replacement for a vulnerability management program — it is the rapid lane that runs on top of one, for vulnerabilities being actively exploited in the wild.
The most under-implemented idea in the whole document sits in Evaluation, and it belongs before the table: that phase asks two questions, not one. Does the vulnerability exist here — and was it already exploited here? Almost every commercial program answers only the first. The playbook is unambiguous: if the vulnerability exists, you address it and you determine whether it has already been exploited in your environment, using an IOC sweep, investigation of anomalous access on the affected systems, any detection steps an advisory specifies, and third-party incident response if needed. If you find exploitation, you stop running a vulnerability process and start running an incident (Chapter 13).
Here is the process as an operational sequence.
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 1 | Ingest the exploited-vulnerability feed (CISA KEV, vendor advisories, ISAC, SOC detections) into the ticket queue automatically | SOC / Vuln Manager | New KEV entries create tickets within one business day of publication with no human transcription | Feed timestamp, ticket creation timestamp |
| 2 | Determine applicability: does this product and version exist in our estate, in a configuration that is affected? | Vuln Manager + asset owner | Every asset is classed Not Affected or Susceptible; the count of "unknown" is recorded, not hidden | Query used, asset list, unknown count |
| 3 | Determine exposure: is any affected asset reachable from an untrusted network? | Network Ops | Every Susceptible asset carries an internet-exposed true/false flag | External scan result or ASM export |
| 4 | Assign the SLA tier and the due date from the matrix below; notify the named remediation owner | Vuln Manager | Ticket has a tier, a due date, and a named human owner — not a team alias | Ticket record |
| 5 | Compromise assessment on every internet-facing Susceptible asset: sweep advisory IOCs, review authentication and admin logs for the exposure window, run any vendor- or advisory-specified detection procedure | SOC | Sweep completed and result recorded as clean or suspicious, per asset | Query outputs, timestamps, analyst name |
| 6 | If signs of exploitation are found: declare an incident and hand to the Incident Commander. Do not continue in the vulnerability process | SOC → IC | Incident declared; vulnerability ticket cross-linked to the incident case | Declaration record, case ID |
| 7 | Remediate — patch where possible; where not, apply a compensating control from the approved catalog and open a dated exception | Remediation owner | Asset state is Remediated or Mitigated. "Mitigated" keeps the ticket open | Change record, config diff |
| 8 | Verify by independent re-scan or re-check — not by the change ticket being closed | Vuln Manager | Re-scan confirms the asset is no longer susceptible | Post-remediation scan artefact with timestamp |
| 9 | Report status and close | Vuln Manager | Per-asset states reconcile to the total; exceptions carry expiry dates and owners | Burndown export, exception register entry |
Steps 5 and 7 run in parallel, step 6 can fire at any time, and step 8 is not optional and cannot be done by whoever did step 7. Sequence matters most between 2 and 4: assign SLA tiers before confirming applicability and you generate a queue of false clocks, your team learns the deadlines are noise, and within two quarters nobody believes any due date you publish. Applicability first. Always.
The playbook also gives you the per-asset state model, which is the data structure your dashboard actually needs. Evaluation produces Not Affected / Susceptible / Compromised. Remediation produces Remediated / Mitigated / Susceptible-or-Compromised. Three things about it are load-bearing: the state is per asset, not per CVE; "Mitigated" is a tracked state, not a closed one; and status is tracked explicitly for reporting purposes — the polite federal way of saying you cannot report what you do not track per asset.
Actionable takeaway: Rebuild your vulnerability ticket schema this quarter so every ticket carries a per-asset state from that six-value list, plus an applicability decision and an exposure flag. If your tooling only reports per-CVE counts, you have a scoreboard, not a program.
The playbook puts asset management in Preparation for a reason, and it is specific about the scope: agency-operated systems, systems shared with partner organizations, and systems operated by others — cloud, contractor, and service-provider systems. Then it adds the requirement everyone skips: track operating systems and applications for all systems, so you can determine relevance when an advisory lands.
Here is why this is the whole ballgame. Every metric in vulnerability management is a fraction, and asset inventory is the denominator. A program reporting "97% of critical vulnerabilities remediated within SLA" across 4,000 scanned assets, in an estate that actually contains 5,300, is reporting a number about a subset it chose. The 1,300 assets nobody scans are not low risk — they are unmeasured, which is the one category attackers reliably prefer. An inventory you do not reconcile is a shopping list you wrote before you moved house.
The reconciliation is the work. Pick three sources that see your estate from different angles and compare them monthly:
Anything present in one source and absent from another is an inventory defect with an owner and a due date. That comparison is free. It takes a scheduled query and a spreadsheet, and it will find more real exposure in its first run than a new scanner license will find in a year.
On the external side, the discipline is attack surface management: the authoritative list of what an unauthenticated stranger can reach. CISA's BOD 26-04 makes federal agencies tag every publicly exposed asset with required metadata and keep the dashboard's IP list current, refreshed quarterly or on request (BOD 26-04). Adopt the same idea: a maintained register of external IP ranges, domains and SaaS tenants, owned by a named person, refreshed on a schedule.
The cheap version, if you have no budget: you do not need a CAASM platform. Certificate transparency logs will enumerate hostnames on your domains for free, your registrar and DNS zone exports give you the domain list, your cloud providers' inventory APIs are included in the subscription you already pay for, and one scheduled external port scan of your own declared ranges — run from outside — closes most of the loop. The expensive tools mainly automate the reconciliation and the diffing. Do it by hand monthly until the manual pain justifies the license.
Actionable takeaway: Publish your asset-inventory coverage percentage next to every remediation percentage on every report, forever. A remediation rate without a denominator statement is a marketing claim, and once the two numbers sit side by side, the inventory gap starts getting funded.
This is the section to bring to the meeting where operations tells you the next maintenance window is in five weeks.
VulnCheck's 1H-2026 analysis is the best-sourced dataset on the question, and the headline is blunt: 23.43% of KEV-listed vulnerabilities showed evidence of exploitation on or before the day the CVE was published — down from 28.93% in 2025, but still nearly one in four. Roughly 200 CVEs reached exploited status within 31 days. There were 495 KEV additions in the half, up 10%, while CVE issuance grew 45% — dropping the KEV-to-CVE ratio to 1.4%, from 2.7% in late 2023. The median time from CVE publication to KEV listing fell from 120 days to 80 (VulnCheck).
Read those two facts together, because they point in opposite directions and both are true. The proportion of published CVEs that matter is shrinking — 1.4% ever reach KEV. And for the ones that matter, a quarter are already being used before the CVE is public. That combination is the entire argument for KEV-first triage: you have permission to ignore vastly more than you think, in exchange for moving in days rather than weeks on the small set that counts.
Two corroborations from different datasets. CrowdStrike reports a 42% year-over-year increase in zero-days exploited before public disclosure, with 40% of China-nexus exploits targeting edge devices (CrowdStrike 2026 GTR). Mandiant reports mean time-to-exploit as effectively negative — exploitation occurring before a patch exists — with clusters specializing in VPNs, routers and edge appliances (M-Trends 2026).
Actionable takeaway: Measure and publish your median time from KEV publication to verified remediation, per tier, monthly. Not per-ticket average — median from publication. It is the only vulnerability metric that maps directly onto the attacker's timeline, and it is the number that wins the maintenance-window argument.
Four scoring systems, four different questions. Most programs fail here by trying to blend them into one magic number. They answer different questions and they are not commensurable — a point FIRST makes so firmly it has a name for the failure.
| System | The question it answers | What it is not |
|---|---|---|
| CISA KEV | Has this been confirmed exploited in the wild? | Not a severity rating; not exhaustive |
| EPSS | What is the probability this CVE is exploited in the next 30 days? | Not a live attack feed; not a severity rating |
| CVSS | How bad is successful exploitation, in the abstract? | Not a likelihood; not environment-aware in its base form |
| SSVC / BOD 26-04 | Given exposure, exploitation, automatability and impact — what should we do? | Not a score at all; a decision tree |
KEV is a binary gate, not a score. It is CISA's authoritative list of vulnerabilities exploited in the wild, and CISA's own guidance is to use it as an input to your prioritization framework (KEV catalog). FIRST is explicit about the interaction: when a vulnerability appears on KEV, treat it as actively exploited and prioritize accordingly, regardless of its EPSS score (Using EPSS).
EPSS is a calibrated probability — a machine-learning estimate of the chance a published CVE is exploited in the wild in the next 30 days, published daily for every CVE with a percentile alongside (FIRST EPSS). It is how you triage the enormous middle of the queue that is not on KEV. FIRST's own translation for programs migrating off CVSS is useful and rarely quoted: if you currently treat CVSS Critical as your action threshold, the equivalent effort level is roughly the 90th percentile (EPSS ≥ 0.04); a CVSS High-and-above workflow lands near 0.008. Mean EPSS across all vulnerabilities is about 2.8%, median about 0.7%.
SSVC is the decision tree that turns signals into an action. CISA's model uses exploitation status, technical impact, automatability, mission prevalence and public well-being impact, and outputs four decisions: Track (no action now, standard timelines), Track\ (monitor closely, standard timelines), Attend (supervisory attention, remediate sooner than standard), Act (supervisory and* leadership attention, remediate as soon as possible) (CISA SSVC).
And in June 2026 CISA turned that tree into a binding schedule. **BOD 26-04, Prioritizing Security Updates Based on Risk (10 June 2026), supersedes and revokes both BOD 19-02 and BOD 22-01 — the directive that created the KEV catalog. It sets deadlines from four variables: publicly exposed, KEV-listed, automatable, technical impact (BOD 26-04). Steal its definitions verbatim: publicly exposed means accessible to unauthenticated or untrusted entities via the internet, regardless of physical or logical location; automatable means a public proof-of-concept achieving remote code execution that reliably executes against a vulnerable system; total technical impact means the attacker can install and run arbitrary software or obtain full administrative privileges, and partial** covers lesser outcomes such as denial of service.
The resulting matrix — which is the SLA table this chapter promised, and which is now the closest thing to an industry reference standard:
| Publicly exposed | On KEV | Automatable | Technical impact | Deadline |
|---|---|---|---|---|
| Yes | Yes | Yes | Total | 3 days + forensic triage |
| Yes | Yes | Yes | Partial | 3 days + forensic triage |
| Yes | Yes | No | Total | 3 days + forensic triage |
| Yes | Yes | No | Partial | 7 days |
| Yes | No | Yes | Total | 7 days |
| Yes | No | Yes | Partial | 14 days |
| Yes | No | No | Total | 14 days |
| Yes | No | No | Partial | 30 days |
| No | Yes | Yes | Total | 7 days |
| No | Yes | Yes | Partial | 14 days |
| No | Yes | No | Total | 14 days |
| No | Yes | No | Partial | 30 days |
| No | No | — | — | Fix on system upgrade |
Three design decisions in that table are worth copying even though you are not a federal agency. Exposure moves the deadline more than severity does — an internal KEV vulnerability with total impact gets 7 days; the same thing internet-facing gets 3. The top tier requires forensic triage, not just a patch: agencies must remediate within three days and carry out a forensic triage of the asset to assess whether the system is compromised. That is the CISA playbook's two-question Evaluation, made mandatory. And the bottom row — internal, not on KEV — is "fix on system upgrade." CISA, of all organizations, is telling you most internal non-KEV vulnerabilities do not need their own project. That permission is what makes the top tier achievable.
The decision order that keeps this out of spreadsheet hell — run it as gates, top to bottom, and stop at the first one that fires:
FIRST's three localization checks belong at step 1: presence (is it here), reachability (can an attacker actually reach the vulnerable code path), and consequence (does this asset matter). Those three questions are what turn a population-level score into your decision.
Actionable takeaway: Write the gate order and the SLA matrix into one page of policy, get IT Operations to sign it before the next KEV entry lands, and delete every other severity field from your ticket template. A prioritization scheme nobody can recite from memory is a prioritization scheme nobody follows at 4pm on a Friday.
VPN concentrators, firewalls, load balancers, file-transfer appliances and management gateways are the dominant mass-exploitation surface, and they break every assumption your patch program makes. They sit outside your EDR coverage. They often cannot run an agent at all. They are managed by network engineering, not endpoint engineering. And they are, by definition, exposed.
The evidence is not subtle. VulnCheck's new-KEV vendor list for 1H-2026 reads like a networking catalog: Cisco, Palo Alto, Check Point, F5, Juniper, Fortinet, SonicWall, Ubiquiti, TOTOLINK, Tenda, D-Link, Netgear, Linksys. Forty percent of China-nexus exploits targeted edge devices. Mandiant recorded the BRICKSTORM backdoor sitting on edge devices for around 400 days.
Two emergency directives define the modern standard of care, and both are worth reading even if no federal rule binds you. ED 25-03 (25 September 2025) covered Cisco ASA and Firepower — CVE-2025-20333 (unauthenticated RCE) and CVE-2025-20362 (authentication bypass to restricted endpoints) — which chained give full unauthenticated device control. Cisco tied the campaign to ArcaneDoor and confirmed the actor modified ASA ROM to persist across reboot and upgrade; agencies had to collect and transmit memory images to CISA within a day (CISA ED 25-03; CISA alert). ED 26-01 followed the F5 disclosure of 15 October 2025, in which nation-state actors held access to F5's own network for at least twelve months and exfiltrated BIG-IP source code and information on undisclosed vulnerabilities; agencies had to inventory F5 products, find internet-exposed management interfaces, and patch on a deadline measured in days (CISA).
The lesson both encode: on an internet-facing edge appliance, patching is a containment step, not a remediation step. The patch stops the next attacker. It does nothing about the one who was already there, and firmware-level persistence survives the upgrade you just performed. So the edge tier's procedure is patch and assume compromise: capture what memory and configuration evidence the platform allows before you upgrade, verify firmware and ROM integrity by the vendor's documented method, rotate every credential, certificate, API key and pre-shared secret the device held, and hunt for the persistence mechanisms named in the advisory. Chapter 14.12 is the full edge-device playbook; execute it rather than improvising.
There is now also a directive about the devices you cannot patch at all. **BOD 26-02, Mitigating Risk From End-of-Support Edge Devices (5 February 2026)**, covers end-of-support devices at network boundaries reachable from the internet — load balancers, firewalls, routers, switches, wireless access points, network security appliances and IoT edge devices. Its schedule: update supported devices immediately where operationally feasible; inventory against CISA's end-of-support list within 3 months; decommission the devices on CISA's preliminary inventory within 12 months; decommission all identified end-of-support edge devices within 18 months; and within 24 months establish continuous discovery so devices are retired before they reach end of support (BOD 26-02).
That last item is the one to steal. An end-of-support date is a fact you can know years in advance. Treating an appliance's EOS date as a scheduled decommissioning deadline — budgeted, calendared, owned — converts a future emergency into a routine refresh. The cheap version: a single spreadsheet with every internet-facing appliance, its model, its firmware version, its vendor EOS date, and its owner, reviewed quarterly. That costs an afternoon and prevents the specific failure where an unsupported VPN box becomes the entry point for the entire incident.
Actionable takeaway: Create a distinct edge tier in your SLA policy today, populate it from the vendor list above plus anything else terminating an internet connection, and set the standing rule that a KEV entry against an edge appliance triggers both a patch and a compromise assessment. Not one or the other. Both. Every time. No exceptions for busy weeks.
Scanning is where programs quietly go wrong, because an unauthenticated scan produces a clean-looking report by seeing almost nothing.
Authenticated versus unauthenticated is not a preference; they are two tools for two jobs. An unauthenticated scan tells you what an attacker sees from outside: exposed services, reachable versions, certificate problems. An authenticated or agent-based scan tells you what is actually installed: patch levels, library versions, configuration state, the vulnerable component behind a service that does not announce its version. Run unauthenticated scans from outside your perimeter against your external ranges, and authenticated scans internally against everything. A program running only unauthenticated internal scans is measuring its own banner grabbing.
A cadence that holds up:
| Scan type | Scope | Cadence | Why this frequency |
|---|---|---|---|
| External unauthenticated | All declared external IP ranges and domains | Weekly, plus on-demand for any advisory | New exposure appears from changes, not from attackers |
| Authenticated / agent | All servers, endpoints, and managed appliances | Continuous where agents exist; otherwise weekly | Patch state changes daily |
| Container image | Every image in the registry, and every build | On build, and re-scan the registry daily | A stored image's vulnerability count rises with no change to the image |
| Cloud configuration | All accounts, all regions | Continuous | Chapter 6 owns this in detail |
| Authenticated web application | Internet-facing applications | Quarterly minimum, plus on major release | Logic and auth flaws need session context |
Containers change the remediation verb. You do not patch a running container; you rebuild the image and redeploy. That is genuinely better — deterministic and auditable — but only if two things are true. You must scan the registry as well as the build, because an image scanned clean in March accumulates new vulnerabilities in April without a single byte changing. And you must scan the running workload, because what is deployed and what is in the registry diverge the moment someone pins a tag. Base-image currency is the highest-leverage control in the whole pipeline: one base-image bump remediates hundreds of downstream images at once. Component-level identification, SBOM ingestion and VEX-based applicability suppression are Chapter 11's material — that is where you go when the question shifts from "which host" to "which library, in which of our products."
Penetration testing sits alongside this, not inside it — it answers "can these findings be chained into something that matters," which no scanner answers. Chapter 18 covers exercising; the obligation here is simply that pen-test findings enter the same queue, with the same tiers, deadlines and exception process as scanner findings. A separate "pen test remediation tracker" is how findings go to die.
Actionable takeaway: Audit your scan configuration this week for exactly one thing — the percentage of in-scope assets where authentication actually succeeded. Most tools report this and almost nobody looks. If it is below 90%, your vulnerability counts are fiction, and fixing credential failures will change your risk picture more than any new tool.
Sometimes there is no patch. Sometimes the patch breaks a clinical system, an OT control loop, or a revenue-generating application whose vendor went out of business in 2019. This is the case that dominates real-world exception volume, and it is where most programs lose their integrity — not through bad decisions, but through undated ones.
CISA's playbook gives the complete taxonomy of non-patch responses, and it is still correct. As remediations: limiting access; isolating vulnerable systems, applications, services, profiles or other assets; making permanent configuration changes. Where a patch does not exist, has not been tested, or cannot be applied promptly: disabling services; reconfiguring firewalls to block access; increasing monitoring to detect exploitation. Adopt that list verbatim as your approved compensating-control catalog — a closed list means the control chosen has to be one you already know how to verify.
Then adopt the playbook's reversion rule, which is the part people drop: "Once patches are available and can be safely applied, mitigations can be removed, and patches applied." A compensating control is temporary and reversible by design. It pauses the remediation obligation. It never extinguishes it. The ticket stays open in state Mitigated, with a re-evaluation date.
An exception record is not a paragraph in an email. It has fields, and every one of them is load-bearing:
| Field | Requirement |
|---|---|
| Vulnerability and affected assets | Specific CVE and enumerated asset IDs — never "the ERP environment" |
| Business reason | Why the fix cannot be applied, stated as an operational fact, not a preference |
| Compensating control applied | One or more items from the approved catalog, with the config evidence |
| Residual risk | What an attacker could still achieve, in one plain sentence |
| Expiry date | A date, not a condition. Maximum 90 days for an internet-facing asset |
| Named accountable owner | An individual, by role and name. Never a team alias or a distribution list |
| Approver | Per the authority tiers below |
| Re-evaluation trigger | Patch availability, KEV listing, or expiry — whichever is first |
Review the register quarterly and put two numbers in front of leadership: open exceptions, and exceptions renewed more than once. The second is your real technical-debt indicator. An exception renewed three times is not a vulnerability problem — it is an unfunded replacement project wearing a security hat, and it belongs in the capital plan, not the risk register.
Actionable takeaway: Export every current exception, deviation and risk acceptance in your program, and delete the expiry field's contents wherever it says "permanent," "N/A," or "until replacement." Give each one a date inside 90 days and a named human. The ones nobody will accept ownership of are the ones to fix first.
Here is the failure mode that costs organizations their KEV compliance while their dashboard stays green: the change ticket closed, so the vulnerability was recorded as remediated, and nobody checked.
NIST SP 800-40 Rev. 4 defines enterprise patch management as five activities — identifying, prioritizing, acquiring, installing, and verifying (NIST SP 800-40r4). Verifying is a named, separate step from installing, and it is the one that gets cut when the change window runs long.
Three things break the assumption that installed equals fixed.
The patch installed but the fix is not active. Plenty of remediations require a service restart, a reboot, a configuration change or a feature toggle in addition to the package update. The version string says patched. The vulnerable code path is still live.
The patch was incomplete. This happens more than the industry likes to admit. CISA had to re-issue guidance in November 2025 for the Cisco ASA campaign because devices that had been patched remained exposed (Help Net Security). I covered a similar case in Cyber Shield Weekly on 3 August 2026: N-able's first fix for an authentication bypass in N-central proved incomplete, and attackers exploited the patch bypass in the wild — CVE-2026-18577, with build 2026.3.1.7 the first unaffected version (SecurityWeek). Shocking, I know. Patch your patch's patch — and subscribe to your vendors' security advisories directly, so you are not learning about incomplete fixes from a newsletter.
The attacker was already inside. Firmware and ROM-level persistence — as Cisco confirmed on ASA — survives the upgrade. A patched device with a modified boot ROM is a compromised device with a current version number.
So the rule is: remediation is closed by an independent re-check, not by the change record. Re-scan the asset with authenticated credentials after the change and attach the result to the ticket; confirm the specific artefact the advisory names (build number, hotfix ID, mitigation flag) rather than the marketing version; run any verification procedure the advisory publishes; and for edge appliances, confirm firmware integrity by the vendor's documented method. The person who verifies should not be the person who patched — not out of distrust, but for the same reason we do not let developers approve their own pull requests.
CISA's playbook builds the same principle into closure at the federal level: agencies must proactively provide completed checklists and a completed report to close a ticket, and CISA may require additional actions, more information including log data and technical artefacts, or third-party incident response before it closes. A fix is not closed because the owner says so. It is closed because evidence was produced and someone else checked it.
Actionable takeaway: Add one mandatory field to your remediation workflow — "verification artefact" — and make it impossible to close a ticket without a post-remediation scan result or advisory-specified check attached. Then sample 10% of closed tickets each month and re-verify them independently. The first month's sample will be educational.
Four metrics, and a rule about each. Median time from advisory publication to verified remediation, per tier — median, not mean, so one 300-day outlier cannot hide forty good weeks. KEV SLA attainment, the percentage of KEV-applicable assets remediated or mitigated inside the tier deadline, always printed beside asset-inventory coverage or it is a fraction with an unstated denominator. Open exception count and renewals-per-exception, where the renewal count is the honest one. And verification rate, the percentage of closed remediations carrying a verification artefact — the integrity check on the other three.
Chapter 16 owns the wider metrics and board-reporting model. The discipline that belongs here is narrower: if a number can improve while your actual exposure worsens, it does not go on the executive slide alone. Total vulnerability count is the classic offender — it drops beautifully when a scanner quietly loses credentials to 400 hosts.
Actionable takeaway: Instrument those four metrics this quarter and stop reporting raw vulnerability totals entirely. Report the queue you owe an answer on, not the queue you happened to scan.
Vulnerability management is the least glamorous thing in this book and the one that would have prevented the most damage this year. The 2026 data is unusually clear: exploitation is now the leading way in, roughly one in four confirmed-exploited vulnerabilities is used on or before disclosure day, and our industry's median fix time got worse. The gap between those facts is where the incidents live — and closing it does not require a purchase order. It requires a list of what you own, a one-page rule for what jumps the queue, a deadline with someone's name on it, and the discipline to check that the fix actually took.
Patch what is being used against you, prove it landed, and put a date on everything you chose not to fix.
[IG1] [ID.RA] [CIS 7][IG1] [ID.RA] [CIS 7][IG1] [ID.AM] [CIS 1] [CIS 2][IG1] [ID.AM] [CIS 12][IG2] [ID.RA][IG1] [GV.PO] [CIS 7][IG2] [ID.RA][IG2] [ID.RA][IG2] [DE.CM] [RS.MI][IG1] [RS.MA][IG1] [PR.IR] [CIS 12][IG2] [PR.IR] [RS.MI][IG1] [ID.AM] [CIS 12][IG2] [DE.CM] [CIS 7][IG1] [DE.CM] [CIS 7][IG2] [PR.PS] [CIS 7][IG2] [ID.RA] [CIS 18][IG2] [RS.MI] [PR.PS][IG1] [GV.PO] [ID.RA][IG2] [GV.PO][IG2] [GV.OV][IG2] [PR.PS] [CIS 7][IG3] [PR.PS][IG2] [ID.IM] [GV.OV][IG3] [ID.RA]