Hour zero: four questions, in order
A name trends. Someone forwards a link. Before anyone opens a change ticket, answer these four, in this sequence, because each one can end the exercise:
- Do we run the affected product at all? Not "might we" — do we. Your software inventory answers this or it does not, and how fast it answers is a measure of your programme.
- Is the affected version the one we run? Advisories frequently cover a version band; backported fixes complicate it in both directions.
- Is it reachable? An affected package on an internal host with no inbound path is a different problem from the same package on your edge. Reachability, not presence, sets the clock.
- Is there evidence of exploitation, and is it ours? "Exploited in the wild" is a statement about the world. Check your own logs for the indicators before assuming either way.
Teams that cannot answer the first three within an hour do not have a zero-day problem. They have an asset-inventory problem that only becomes visible during a zero-day.
Hours one to four: contain what you cannot patch
By definition a zero-day may have no patch yet. That does not leave you without options, and the options are worth deciding in advance rather than under pressure:
- Remove the reachability. The fastest mitigation is usually not a fix but an access-control change: take the management interface off the internet, restrict by source, put it behind the VPN it should have been behind.
- Apply the vendor's workaround, and read it critically. Workarounds are written fast; some break functionality in ways the advisory does not mention.
- Virtual patching at the edge. A WAF rule buys time. It is not a fix, and treating it as one is how organisations end up permanently protected by a rule nobody remembers.
- Increase logging on the affected path before you change anything, so you can tell later whether you were hit before you acted.
Write down which of these you chose and why. In four weeks, when the real patch ships, that note is what stops the temporary mitigation becoming permanent architecture.
Hours four to twelve: look for the intrusion you already had
The uncomfortable part of zero-day response is that the disclosure date is not the exploitation date. If the flaw was used before it was public, the useful question is not "are we vulnerable" but "were we compromised".
That means retrospective hunting, against whatever indicators the advisory provides, over a window that extends before the announcement. It is also the moment you discover how long your logs are actually retained — which, for a lot of teams, turns out to be shorter than the exposure window they need to examine.
Hours twelve to twenty-four: the business conversation
Someone will ask "are we affected?" long before you can answer definitively. Three sentences work better than a status page:
- What we know: the product, the versions, whether we run it, whether it is reachable.
- What we have done: the mitigation applied, with its own tradeoff stated plainly.
- What we do not know yet, and when we will know: the hunt in progress, and the next update time.
The third sentence is the one that earns trust, and it is the one most often omitted. Saying "we do not yet know whether we were accessed before the disclosure; we are checking logs back to the first of the month and will update by 18:00" is a stronger position than confident silence.
For regulated organisations the clock may be formal rather than social. NIS2 sets early-warning and reporting obligations for significant incidents, and DORA imposes its own timeline on financial entities. Knowing whether your event crosses those thresholds is part of hour twelve, not a legal question for next week.
What actually determines your response time
Across every real zero-day, the teams that respond quickly are not the ones with the biggest security budget. They are the ones that could answer "do we run it, and is it reachable" without a meeting. Everything else in this playbook is downstream of that.
Which means the work that shortens your next zero-day response is work you do now, when nothing is on fire: know your external footprint, know your versions, keep an asset inventory that reflects reality rather than intent, and rehearse the decision of who is allowed to take a service off the internet at 2am without waiting for a change board.
Anything that turns the first hour from searching into reading is worth having in place beforehand. That is what ZeroDayAlert is for: every newly confirmed-exploited vulnerability with an action plan attached, rather than a browser full of vendor advisories opened at 2am.
The one-page version
Do we run it. Is it the affected version. Is it reachable. Were we already hit. Remove reachability first, patch when the patch is real, write down every temporary measure with an expiry, and tell the business what you do not know along with what you do. That is the whole playbook, and the hard part is the inventory, not the incident.
Frequently Asked Questions
What is the difference between a zero-day and a KEV entry?
A zero-day is a vulnerability being exploited before a fix is available. A KEV entry is a CVE confirmed as exploited, published after the fact. The zero-day window is the period before the catalog can help you.
Should we apply a WAF rule instead of patching?
As a temporary measure while a patch is unavailable or being tested, yes. It buys time and nothing more. Record it with an expiry date, because virtual patches that are forgotten become invisible architecture.
How far back should we hunt for evidence of exploitation?
Past the disclosure date, since exploitation usually precedes it. In practice the window is limited by your log retention, which is often the real constraint teams discover during the hunt.
Who decides to take a service offline during a zero-day?
Decide that before the incident. The teams that respond fastest have a named person with standing authority to remove internet reachability without convening a change board.
Do we have to report a zero-day to regulators?
Only if it becomes an incident meeting the relevant threshold. NIS2 and DORA impose their own timelines, so establishing whether the threshold is crossed belongs in the first day, not the following week.