Reserve a small, named buffer for unplanned security upgrades, separate from your planned upgrade slice. Define what triggers it, who can draw on it, and what happens when it runs dry. Review use each quarter, and resize it from what you actually spent, not from fear.
Why a separate buffer
When an urgent advisory arrives mid-quarter and there is no reserved time, the work comes from somewhere. Usually it is the planned upgrade work, which quietly slips. By quarter end the roadmap says upgrades were done, and the drift number says otherwise.
A named buffer fixes the accounting. Urgent work draws from the buffer, planned work stays planned, and the gap between them becomes data.
Step 1: Size it from history
Look back at the last two quarters. How many times did a security advisory force unplanned work, and how long did each take from first message to merged fix? Sum the hours. That total, not a guess, is the starting size. If you have no records, start modestly and track from today.
Step 2: Write down the triggers
An unwritten trigger means every advisory is an emergency. Agree on a short rule, for example:
| Trigger | Draws on buffer? |
|---|---|
| Reachable advisory on an internet-facing service with a fix available | Yes |
| Listed in a public known-exploited catalog and you run the component | Yes |
| Advisory in a package your code never calls | No, goes to planned backlog |
| Customer asks about a scanner finding | Triage first, then decide |
Our post on emergency versus routine patch criteria gives a fuller decision table.
Step 3: Name who can spend it
One or two people, usually the manager and a security lead, decide when the buffer is used. This stops the buffer from becoming a general overflow for any urgent request.
Step 4: Decide what happens at zero
Write the answer before you need it. Typical options:
- Pull from the planned slice and record exactly what slipped.
- Extend the quarter's upgrade epic and tell stakeholders.
- Escalate to the manager's own manager when two emergencies overlap.
Silent overspending is the failure to avoid.
Step 5: Review each quarter
Record, for every draw, the advisory, the hours, and whether the work was truly unplanned or just late. If the buffer is never touched, shrink it. If it empties by month two, either the planned slice is too small, or the trigger rule is too loose.
Use a runbook so emergency work is fast when it comes. Ours is at emergency dependency patch runbook.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory is matched against what you run, which is the moment the buffer gets drawn on.
Where Safeguard fits
Safeguard's zero-day discovery and reachability analysis help you see quickly whether a new advisory touches code you call, which keeps the buffer for cases that need it. A free scan is at gold.safeguard.sh/scan.
Quick check
How big should the buffer be?
Base it on your own record of unplanned security work over the past two quarters. If you lack records, start small and track every draw.
Can the buffer be spent on planned work if unused?
Yes, but decide the rule in advance, such as releasing unused buffer in the last two weeks of the quarter.
Last reviewed: 19 October 2026.
