Plan for a zero-day week before one arrives. Name a small response pool, agree in writing what work pauses when it activates, set a time limit with a review point, and keep a short checklist ready. The aim is a fast, calm response that does not consume the whole roadmap.
Why you need a plan in advance
When a serious vulnerability lands in a widely used component, the first hours decide how disruptive the response is. Without a plan, every team is pulled in at once, the loudest voices set priorities, and the pause on feature work has no end date.
A plan answers three questions in advance: who responds, what stops, and when does normal work resume. The Scrum Guide says no changes should be made during a sprint that endanger the Sprint Goal, and that scope can be renegotiated with the Product Owner as more is learned. A surge plan is the pre-agreed way to renegotiate.
Step 1: define the trigger
Not every advisory is a surge. Write a short rule that decides when the plan activates. Useful inputs include whether the flaw appears on the CISA Known Exploited Vulnerabilities catalog, whether the affected component is internet facing in your estate, and whether your code actually calls the vulnerable function. Keep the rule to a few lines and name who can declare a surge.
Step 2: name the response pool
Pick a small group per area, not the whole company. For example:
| Role | Job during a surge |
|---|---|
| Incident lead | Runs the response, owns the timeline |
| Inventory owner | Answers where the component runs |
| Fix engineers | One or two per affected service, pulled from the teams |
| Communications | Updates leadership and, if needed, customers |
Rotate the pool each quarter so knowledge spreads and nobody burns out. Backups matter, since the event never arrives when everyone is present.
Step 3: agree what pauses
List, in advance, which work stops and which does not. A typical default is that stretch goals and unscheduled features pause first, committed customer work pauses only by decision of the product lead, and compliance deadlines are protected. Having the order written down prevents a hallway negotiation at the worst moment.
Step 4: time-box it
Set an initial window, such as two working days, with a mandatory review at the end. At review, decide whether to continue, scale down or stand down. Open ended emergencies drift. A scheduled review forces a decision. For the overall shape of a first day, see what to tell executives in the first 24 hours of a zero-day.
Step 5: protect the afterwards
After the surge, expect a tail of cleanup: follow-up fixes, tests and documentation. Reserve some capacity for it in the next sprint, or the debt created during the rush becomes tomorrow's backlog. Hold a short review and feed lessons into the plan. The multi-advisory case is covered in how to prioritize when three zero-days land the same week.
Try it yourself
The demo shows how a newly disclosed vulnerability can be matched against the components you actually ship. Look at how quickly the affected list narrows, since that list is what sizes your response pool.
Click through it at your own pace, or open it full screen.
Safeguard offers zero-day discovery, SBOM and dependency scanning and reachability analysis, which together help answer the inventory question fast. Its autonomous remediation can propose fix pull requests, but it is off by default and every category starts on Manual, so people approve each change during the surge.
Quick check
How many people should a response pool have?
As few as can cover inventory, fixes and communication, with a named backup for each role. Size it by the number of affected services, not company headcount.
Should the whole company stop feature work?
Rarely. Pause only the teams that own affected services, and set a review time so the pause does not drift.
Sources
Last reviewed: 19 October 2026.
