In the first hour of a zero-day, confirm the report is real, name one incident owner, list where the affected product runs, apply the vendor's stopgap if one exists, and set a time for the next update. Do not wait for a patch before you start asking where you are exposed.
Minutes 0 to 15: confirm and assign
Read the primary source, not a social media summary. That means the vendor advisory, the maintainer's repository, or a government catalog entry. Note the product, the affected versions, whether exploitation is reported, and whether a fix or workaround exists.
Then name one owner. Shared ownership in the first hour means nobody sends the first message. The owner does not do all the work. They keep the list, the clock and the log.
Open a single channel and a single running document. Every decision goes in it with a time stamp. You will need it for the review later and, if the worst happens, for regulators and customers.
Minutes 15 to 40: find where it runs
This is the step that decides how the day goes. You need a list of every place the affected product or library exists: servers, containers, laptops, build images, vendor-managed systems, and software you ship to customers.
If you keep an inventory or a software bill of materials, query it. If you do not, start with the internet-facing systems, because those are what attackers reach first. A guide on finding a library everywhere walks through the sources to check.
Record three answers per system: affected, not affected, or unknown. Unknown is a valid answer in hour one. It becomes a task, not a reason to stall.
Minutes 40 to 60: reduce exposure now
If the vendor published a workaround, such as disabling a feature or blocking a path, apply it to the internet-facing systems first. If no workaround exists, consider removing the system from public access, adding a network rule, or turning the feature off. Emergency mitigation when no patch exists yet covers the options and their limits.
Write down every stopgap you apply. Stopgaps that nobody tracks become permanent by accident.
Finish the hour by setting the next update time, even if the update is "no change." People stop interrupting you when they know when to expect news.
First-hour checklist
| Task | Output | Owner |
|---|---|---|
| Read the primary advisory | Product, versions, exploitation status | Incident owner |
| Open channel and log | One place for decisions | Incident owner |
| Query inventory | Affected, not affected, unknown list | Platform or security |
| Apply stopgap | Change record per system | System owners |
| Set next update | Time and audience | Incident owner |
CISA describes its Known Exploited Vulnerabilities catalog as an input to vulnerability management prioritization. If the flaw appears there, treat exploitation as confirmed.
Safeguard can answer the "where does it run" question from SBOM and dependency scanning data, and its zero-day discovery work flags new advisories against your dependencies. You can try a free scan of a repository to see the inventory view.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped by severity and fix status.
Quick check
Should we wait for a patch before acting?
No. Inventory, exposure reduction and communication can all start before a fix exists. Waiting only lengthens the time attackers have.
Who should own a zero-day response?
One named person who keeps the list, the log and the update schedule. Technical work can be spread across many people.
Sources
Last reviewed: 19 October 2026.
