A small team can be ready for the next zero day in 90 days by building a dependency inventory, naming one decision maker, writing a short emergency rule, preparing mitigations, and running one rehearsal. None of this needs a large budget. It needs a few focused weeks and the discipline to repeat the drill.
What does "ready" mean?
Not that you will prevent a zero day. NIST describes a zero day attack as one exploiting a previously unknown vulnerability, so by definition there is no patch on day one. Ready means that within hours of an announcement you can say what you run, what is exposed, and what you will do about it.
Days 1 to 30: know what you run
Week 1: list deployables. Write down every service, job, site and mobile app your team ships or runs, with the repository and the place it runs. Include the forgotten ones. Expect surprises.
Week 2: generate dependency inventory. Produce a software bill of materials or dependency list for each deployable, using your package manager or a scanner. Store them where search works, even if it is a folder and a grep script at first.
Week 3: automate refresh. Run inventory generation in CI so every build updates it. A stale list is worse than none, because it gives false comfort.
Week 4: find the gaps. Compare list one with list two. Which deployables lack an inventory? Fix the three most important.
Days 31 to 60: decide before you need to
Name a decision maker and a deputy. Who approves an out of cycle patch or a temporary shutdown? Put names and phone numbers in one page.
Write the trigger. A constructed example rule: "Treat as an emergency if the flaw is exploited in the wild, the component is on an internet facing service, and we cannot rule out reachability." Exploitation evidence can come from CISA's Known Exploited Vulnerabilities catalog.
Build a mitigation menu. For each type of system, list quick actions: turn off a feature, restrict the network path, add a filter, rotate credentials, increase logging. Check that each action is something your team can do without a vendor.
Check access. Can the on call person deploy to production at night? Test it now.
Days 61 to 90: practice
Add reachability. If your tooling supports it, add analysis of whether your code calls the vulnerable function. It sharply cuts the list. Sample results by hand until you trust them.
Run the drill. Pick a real package you use and pretend it has an announced flaw. Start a timer. Record time to affected list, time to exposure check and time to mitigation proposal. Do not blame anyone for slow steps; fix them.
Write the after action note. Three lines: what slowed us down, what we guessed, what we change.
Schedule the next one. Put a quarterly drill on the calendar before the team forgets.
Common traps for small teams
- Waiting for a perfect tool. A script and a folder beat nothing.
- Making the plan too long. One page gets read.
- Forgetting vendor software and SaaS, which you cannot patch yourself but still need to track.
- Relying on one person who is the only one with deploy rights.
Where Safeguard fits
Safeguard provides dependency inventory, reachability analysis and policies that can gate a build, which cover steps in weeks 2, 3 and 9 here. It also runs zero day discovery for your own code in agentic and scanner modes. Fix pull requests are available but are off by default and start on manual approval. It does not handle endpoint or network incident response.
What if you only have two weeks?
Do the minimum that changes the first hour of a response. First, write the list of deployables and where each runs, even on one page. Second, generate a dependency list for the three most exposed services and store it somewhere searchable. Third, write the names of the decision maker and deputy, and the trigger rule, in a shared note. Fourth, check that two people can deploy to production.
That is a day or two of work spread over a fortnight, and it moves you from "we would start from scratch" to "we know where to look." The rest of the 90 day plan then fills in coverage, mitigations and practice.
Resist the urge to buy tooling in these two weeks. The first value comes from clarity about ownership and access, which a purchase does not provide. Tools earn their place after you have seen where your manual process hurts: usually inventory refresh and reachability.
What to do
- By day 7, list every deployable.
- By day 30, have inventory for the most important ones, refreshed in CI.
- By day 45, publish the emergency rule and the decision makers.
- By day 60, finish the mitigation menu and test deploy access.
- By day 90, run the drill, write the note and schedule the next.
Quick check
What is the minimum viable zero day plan?
An inventory you can search, a named decision maker, a written trigger for emergencies, and one rehearsal.
How often should we rehearse?
Quarterly is a good start. Use a different package or system each time.
Sources
Last reviewed: 18 October 2026.
