After a slow fix, ask ten questions in stage order, from how you learned about the flaw to how you confirmed the fix. Keep the review blameless and short, and end with one change to the process, not a list of regrets. The goal is a shorter window next time.
Before you start
Build the timeline first: advisory published, your alert, triage decision, fix ready, merge, deploy, verified. Without timestamps, the review turns into opinions. If a timestamp is missing, that is finding number zero: record how to capture it next time.
The ten questions
Detection
- How did we learn about it, and how long after the advisory? Was the alert enabled and routed to a person?
- Did our inventory show where the affected component ran? If it took searching, how long?
Triage
- Who decided priority, and on what basis? Did we know whether the vulnerable code was reachable and the service exposed?
- Was there an owner within the first hour, or did the item wait for assignment?
Fix
- Was a fixed version available at the time? If not, what interim mitigation did we consider?
- Did the fix need a parent upgrade or a major version change? What made it hard?
Review and merge
- How long did the pull request wait for review, and why? Was there a backup reviewer?
- Did tests fail for reasons unrelated to the fix?
Deploy and verify
- How long between merge and deploy? What approvals, freezes or release cycles applied?
- How did we confirm the fix was running in every environment?
Turning answers into actions
| Finding | Possible action |
|---|---|
| Alert not routed | Assign default owners and a channel |
| Inventory gap | Generate and keep an SBOM per service |
| No priority criteria | Write tiers and a decision table |
| Review wait | Backup reviewers, stated response target |
| Flaky tests | Quarantine and repair the tests |
| Slow deploy | Add an expedited path with gates |
| No verification | Script a version check |
Pick one action, give it an owner and a date, and follow up at the next review.
Rules for the meeting
- Blameless. Ask what the system allowed, not who failed.
- Short. Thirty minutes is enough for one fix.
- Written. Keep a one page record: timeline, answers, one action.
- Sampled. You do not need a review for every fix. Review the slowest few each quarter, plus any that involved an exploited flaw.
Watch for these patterns
If the same stage appears in three reviews, treat it as a systemic issue and escalate it. If the cause is waiting, no one person is at fault, and the fix is a policy or a tool. If the cause is unclear ownership, fix the ownership map before anything else.
Compare against the earlier ones
Keep each review's total window in a simple list. Over a year, you will see whether the typical slow fix is getting less slow. That trend is a better indicator than any single story.
Try it yourself
Open the zero-day watch demo and trace how a newly published flaw reaches your inventory, which is where your timeline begins.
Click through it at your own pace, or open it full screen.
Safeguard provides asset discovery, dependency scanning and remediation tracking to support the data you need for these reviews. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do I need a review for every fix?
No. Review the slowest and the highest risk cases on a regular cycle.
What if we have no timestamps?
Start recording them now. That is the first improvement.
Last reviewed: 19 October 2026.
