The patch triage meeting that ends with owners, not opinions

You know the meeting. Someone shares the scan output, sorted by CVSS, and the room spends fifty minutes arguing about whether a 9.1 nobody can reach matters more than a 6.8 that’s already being used. Nothing leaves with an owner. Next week the same CVEs are back on the agenda, because no one wrote down what was decided. The meeting was an hour long and it decided nothing.

The fix isn’t a better tool. It’s a different meeting. The triage that finds the work is pre-work, done by one analyst against public signals before anyone gathers. The companion to this post, a 30-minute Patch Tuesday triage you can actually run, covers that part: filtering 150-plus CVEs down to a short-list of four to eight. This post is about what happens to that short-list in the room. The meeting’s only job is to put a name and a clock on each item, then end.

The “15 minutes” is shorthand, and that’s fine

Let’s be honest about the number up front. No standards body publishes a “15-minute patch triage meeting.” NIST doesn’t, CISA doesn’t, FIRST doesn’t. The framing is practitioner shorthand, and saying so costs you nothing because the discipline behind it is real.

It borrows from two well-documented practices. The first is the agile daily standup’s hard time-box. Mountain Goat Software’s daily scrum guide is explicit that the 15-minute cap exists to keep the session from becoming a problem-solving forum; anything that needs real discussion goes to what Scrum people call the “sixteenth minute.” Parabol’s guide operationalizes the same rule: past roughly ninety seconds, the item leaves the synchronous meeting. The second is a defined, repeatable patch process. NIST SP 800-40 Rev 4 doesn’t prescribe a meeting interval, but it’s clear that effective patch management needs a documented lifecycle and treats patching as preventive maintenance rather than reactive fire-fighting. A standing ceremony is the natural home for closing that loop.

Put those together and the time-box stops being arbitrary. It’s a constraint that forces the meeting to decide rather than analyze.

What the meeting actually does

It buckets, assigns, and starts a clock. That’s the whole job.

If a CVE still needs technical investigation before anyone can name an owner, it is not agenda business. It goes offline and comes back when the investigation is done. The recurring failure is drift into root-cause or architecture debate, which, per one bug-triage guide, “consumes crucial meeting time and distracts from the primary goal.” You’ve seen it: one unreachable edge appliance becomes a twenty-minute segmentation discussion, and the other six items never get touched.

A workable agenda is four short beats:

• Confirm the short-list is current. Any KEV additions or severity upgrades since the last session? This is a thirty-second check, not a re-triage.
• Decision pass. Walk each item through the agreed rubric and call a bucket. Ten seconds an item, not five minutes.
• Owner and window. For every “act” item, name the person and the date out loud, and write it into the tracker before the next item.
• Blockers. Flag anything that needs escalation outside the room, and stop. Don’t solve it here.

Write each decision into the tracker as it’s made. A verbal commitment that never becomes a ticket is just next week’s repeat agenda item.

Cadence is a separate choice, and the three common ones stack: a weekly standing meeting for continuous volume, a Patch-Tuesday-anchored session the Wednesday after Microsoft’s second-Tuesday drop, and a short daily KEV catalog check-in for elevated posture between cycles. Pick the trigger that matches your volume.

The rubric: from a signal to a one-word call

The speed comes from a rubric the team agreed to in advance, so each item gets a ten-second bucket instead of an argument. The standard one is SSVC, built by CMU’s Software Engineering Institute and adapted by CISA. The deployer tree walks a fixed sequence of decision points: exploitation status, exposure, automatable, technical impact, and a mission-criticality input. The output is one of four buckets.

Bucket	What it means	The clock
Track	No action now. Handle in standard update cycles.	Next routine window
Track*	Standard timeline, but worth closer monitoring.	Next routine window, watched
Attend	Needs supervisory attention, sooner than standard SLAs.	Off-cycle, ahead of routine
Act	Leadership involvement and immediate remediation.	Now, not the next window

(Bucket names are CISA’s relabeling, per the SSVC calculator. The original SEI labels were Defer, Scheduled, Out-of-Cycle, and Immediate. Same tiers, different words.)

The load-bearing joint is the exploitation decision point, and it resolves in seconds. It takes three values: None, PoC, and Active. Every CVE in the KEV catalog is Active by definition; inclusion is the signal, not a score, and it cascades toward Act regardless of CVSS. That’s why a CVSS 6.8 in KEV outranks a CVSS 9.1 with no exploitation evidence. FIRST is blunt that EPSS addresses the threat component while CVSS addresses the vulnerability component, and that “CVSS is not meant to reflect overall risk.”

EPSS supplies the probability input: a 0-to-1 score for the likelihood a CVE is exploited in the wild within thirty days. A high score on a non-KEV CVE raises the exploitation value to at least PoC and often justifies Attend even without confirmed active use. The SEI’s caution holds, though: EPSS has blind spots for non-network bugs and OT, so use it to set the exploitation value inside the tree, not to skip the tree. Because exploitation gets evaluated first and answered fast, most items bucket Track or Track* before the group debates anything.

Keep two numbers in your pocket for the meeting where someone wants to “just patch everything 7 and above.” Tenable found more than 75% of CVSS 7-plus vulnerabilities have never had a published exploit, and Picus found 28% of actively exploited bugs carried only medium base scores. The CVSS-sorted queue is not the work queue.

Who’s in the room, and how items get owned

The roster is built backward from who will be asked to own something. You want IT operations and sysadmins for deployment capacity and scheduling, security or vulnerability management for the short-list and the risk case, change management to bridge a decision into the formal change record, and the application or business-system owner for anything touching their workloads. Skip the app owner and the items touching their systems become orphaned action items that stall at scheduling.

This follows from how SSVC is built. It’s stakeholder-specific by design, separate models for deployers, coordinators, and suppliers, so no one person owns every decision at the table. Security owns “is this worth acting on?” The sysadmin or app owner owns “when and how?”

The enforcement layer is one accountable name per item. “The security team will patch this” is a group assignment, not an owner, and group assignments don’t get done. The accountable person is whoever controls the affected asset: a sysadmin for infrastructure, an app owner for a software system, a network engineer for an appliance. Security is consulted and informed, not accountable for the deployment unless it owns the asset too.

Change management is where the assignment turns structural. ITIL 4 defines three change types: standard (pre-approved, documented runbook), normal (risk assessment plus a change-authority approval), and emergency (expedited approval, post-implementation review required). Actively exploited bugs fit the emergency profile, and the Emergency Change Advisory Board lets a KEV-listed vulnerability bypass a multi-week change cycle without bypassing governance. Every item elevated to “act” should leave with a change type and a change authority already named.

The clocks the meeting starts

The mechanical output is placing each item on the right clock. A few matter.

KEV entries carry their own deadlines. CISA BOD 22-01 requires federal civilian agencies to remediate KEV-listed bugs by the catalog due date, roughly two weeks for entries from 2021 onward and six months for older ones. It binds federal agencies, but plenty of non-federal shops adopt it as a benchmark, and the due date is already printed in the catalog entry, so there’s nothing to calculate.

Severity-tiered SLAs cover the rest. UK Cyber Essentials and related guidance require patching critical and high (CVSS 7-plus) within 14 days on internet-facing systems, and the NCSC’s 2024 guidance recommends as little as five days for internet-facing services and 14 for internal. CIS Controls suggest a 24-to-72-hour emergency cadence for critical patches. Pick the standard you’re held to, write the day-count next to the owner, move on.

The meeting is a gate, not a debate

A patch triage meeting that runs long is almost always a meeting doing the wrong job. It’s analyzing when it should be deciding, or debating exposure that triage already settled. The fifteen-minute frame isn’t a stopwatch you enforce for its own sake. It’s the symptom of a meeting that buckets fast, assigns by name, and pushes the hard conversations to the sixteenth minute where they belong.

The test for whether you ran it right is simple. Open the tracker after the meeting. Every item has one name and one date, or it doesn’t. If it doesn’t, you held a discussion, not a triage.

PatchDay Alert’s daily digest runs this same exploitation-first filter every weekday, so the short-list is already sorted by what’s being used in the wild before your meeting starts. The clocks and the owners are yours. We can get the right items in front of you.

Sources

• Daily Scrum Meeting — Mountain Goat Software — ongoing
• Daily Scrum Guide — Parabol — ongoing
• NIST SP 800-40 Rev 4: Guide to Enterprise Patch Management Planning — 2022-04-01
• Complete Bug Triage Meeting Process — ThinkSys — ongoing
• CISA Known Exploited Vulnerabilities Catalog — ongoing
• Stakeholder-Specific Vulnerability Categorization (SSVC) — CISA — ongoing
• SSVC Calculator — CISA — ongoing
• EPSS User Guide — FIRST — ongoing
• Exploit Prediction Scoring System (EPSS) — FIRST — ongoing
• Probably Don’t Rely on EPSS Yet — CMU SEI — 2022-01-01
• Why You Need to Stop Using CVSS for Vulnerability Prioritization — Tenable — 2020-01-01
• Vulnerability Prioritization: Why CVSS Isn’t Enough — Picus Security — 2026-04-01
• What’s New in SSVC — CMU SEI — 2024-01-01
• Change Enablement — itsm.tools — ongoing
• Comprehensive Guide to ITIL Change Management — PDCA Consulting — ongoing
• BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities — CISA — 2021-11-03
• Key Insights from the NCSC’s Vulnerability Management Guidance — Qualys — 2024-04-02
• Patch Management Standards — Reliance Cyber — ongoing