A high-severity CVE drops on a Tuesday morning. The security researcher tweets a thread. NVD publishes the entry with a 9.8 base score. Your scanner vendor sends an alert email. Three different Slack channels start pinging simultaneously. Every engineer who reads tech Twitter asks "are we affected?" at roughly the same moment.
If your team has two or three people managing security, you don't have the luxury of declaring a war room and dedicating a half-day to triage. You need a process that takes 20 minutes and gives you a credible answer to three questions: Are we affected? If yes, on what assets? What do we do in the next hour?
This is the zero-day triage workflow we use with Vendrsec. It's not designed for incident response after an exploit lands — it's designed for the window between "CVE published" and "we know our exposure status," which is where improvisation causes the most damage.
The Problem With Improvised Zero-Day Response
When there's no established process, zero-day response follows a predictable pattern. Someone senior starts a Slack thread. People search their scanner dashboards with the CVE ID — often before the scanner has had time to push updated detection rules. The search returns zero results. The team concludes they're not affected. Two days later, the scanner runs with updated detection and finds 14 affected assets that were invisible to the initial search.
The false-negative window is the core risk. Scanners require time to update their detection logic after a new CVE is published — typically 24-72 hours for an unauthenticated network check, longer for authenticated plugin tests. If your zero-day triage process relies entirely on scanner output during this window, you're making a decision based on absence of evidence, not evidence of absence.
A repeatable process accounts for this. It doesn't wait for scanner confirmation before making a first-pass determination.
Step 1: Classify the CVE Before Doing Anything Else (3 minutes)
The first thing the triage lead does is answer three classification questions from primary sources — NVD, the vendor advisory, and CISA KEV — not from media coverage or secondhand summaries.
What is the attack vector? Network-exploitable CVEs with no authentication requirement (AV:N/AC:L/PR:N in CVSS vector notation) are the highest immediate concern. CVEs that require local access, physical access, or prior authentication are a priority, but the urgency is lower. Read the CVSS vector string, not just the base score — a 9.8 with AV:N/PR:N is categorically different from a 9.8 with AV:L/PR:H even though the score is identical.
What software is affected? Product name, vendor, and version range. This is the query you'll run against your asset inventory in the next step. You need the affected version range from the vendor advisory, not just the CVE description — NVD descriptions are sometimes written before vendor specifics are available.
Is there active exploitation? Check CISA KEV (search the current KEV catalog, not last week's version). Check your threat intel sources if you have them. If neither confirms active exploitation, check the CVE's NVD page for references to exploit code — look for GitHub links, PoC advisories, or Metasploit module references in the reference list.
These three answers determine the urgency tier before you know your own exposure. Active exploitation + network-accessible + no-auth = immediate triage regardless of scanner status. No active exploitation + local access required = you have 24-48 hours to wait for scanner confirmation.
Step 2: Query Your Asset Inventory — Without Waiting for the Scanner (7 minutes)
This step runs against your asset inventory and CMDB, not your scanner findings. The scanner hasn't updated yet. Your inventory knows what software is running where.
The query is: which assets in your inventory are running a version of the affected software within the vulnerable range? This requires that your asset inventory actually tracks software versions — which is where many teams discover gaps in their asset management. If you don't have software inventory, you're stuck waiting for the scanner, which means the 24-72 hour detection lag is unavoidable.
The assets that come back from this query are your initial affected set. Cross-reference against asset criticality: which of these are customer-facing? Internet-accessible? Running on assets adjacent to sensitive data? This cross-reference takes about 3 minutes if your asset inventory has business function tags.
The output of this step is two lists: confirmed-at-risk assets (in your inventory, running affected software, internet-accessible or business-critical) and possible-at-risk assets (in your inventory, software version data stale or unavailable). Both lists drive different actions.
Step 3: Determine Immediate Mitigation Options (5 minutes)
Before contacting anyone, the triage lead needs to know what the mitigation options actually are. The vendor advisory is the right source, not Twitter.
For confirmed-at-risk assets, the options are typically: apply the vendor patch (if available), apply a compensating control specified in the vendor advisory (e.g., disable a specific feature, add network-level blocking rule), or isolate the asset if neither is immediately available. Write these down with the specific version to upgrade to or the specific config change needed — you'll need this for the remediation tickets in the next step.
A note on compensating controls: we're not saying a compensating control is equivalent to a patch. It isn't. But in the zero-day triage window, a documented compensating control that reduces exposure while a patch is prepared is strictly better than an undocumented "we haven't patched yet" status. The control gets you out of "immediate exploitation risk" into "managed risk with timeline," which changes the SLA obligation from hours to days.
Step 4: Create Targeted Remediation Tickets (5 minutes)
For confirmed-at-risk critical assets: create a remediation ticket immediately, before any further triage. Assign it to the asset owner. Set the deadline based on exploit status (72 hours if active exploitation confirmed, 14 days if PoC only).
The ticket must include: asset hostname/IP, CVE reference, affected version currently installed, target version to upgrade to (from vendor advisory), specific patch command if available, and the compensating control in case the patch can't be applied immediately. A ticket that just says "apply patch for CVE-2025-XXXX" is not a remediation ticket — it's a note. Engineers need the specific version, the specific command, the specific deadline.
For possible-at-risk assets: create a tracking ticket to revisit after the scanner updates. Tag these tickets with the CVE ID so they surface automatically when the scanner run completes. Don't assign them to engineers yet — wait for scanner confirmation.
Step 5: Communicate Status — Once, Clearly (2 minutes)
Send a single status message to the relevant stakeholders. Not a Slack thread, not a meeting invite — a single message with: affected asset count (confirmed), affected asset count (pending scanner), highest-criticality affected assets, what's been done (tickets created, compensating controls status), and when the next update will come.
The "when the next update will come" part is critical. If you don't give a time for the next update, you'll get asked every 2 hours by everyone who read the first message. "Next update at 5 PM when scanner run completes" closes the loop and eliminates most of the follow-up questions.
What This Process Doesn't Handle
This workflow is specifically for the window between CVE disclosure and scanner confirmation. It's not a full incident response procedure. It doesn't cover coordination with vendors when a patch isn't available, communication with customers if affected systems are customer-facing, or the post-remediation verification flow.
It also assumes your asset inventory has meaningful software version data. If you're running a scanner-only asset inventory where software data is only available after a scan run, this workflow reduces to "wait for scanner" — which is where the false-negative risk lives. The real prerequisite for repeatable zero-day triage isn't the process itself; it's the asset management hygiene that makes the process fast rather than theoretical.
In practice, teams that run this workflow consistently report that the high-urgency decisions happen in the first 20 minutes and are defensible — you can explain why you did or didn't act based on the CVE classification and inventory data, rather than "we checked the scanner and it said nothing." The scanner confirmation comes later and either validates the initial call or prompts additional tickets on the possible-at-risk list. Either way, you're not in reactive mode on the third day when the news cycle peaks.