Give a number for each severity, say when the clock starts, say how you track it, and describe what you do when a deadline is missed. A reviewer trusts a stated policy with a visible exceptions process far more than a promise to fix everything fast.
What the reviewer wants to see
The question hides four others. Do you have a defined timeline? Do you measure against it? Does it cover your dependencies and infrastructure as well as your own code? Do you handle actively exploited flaws differently? An answer that covers all four usually ends the thread.
NIST's guide on enterprise patch management describes patching as identifying, prioritizing, acquiring, installing and verifying updates across an organization, and recommends a strategy rather than ad hoc effort. That sequence is a good outline for your answer.
A structure for the answer
- Timelines by severity. State your own targets. Make them ones you actually meet. A table keeps it readable.
- Clock start. From public disclosure, from vendor patch release, or from detection in your environment. Say which.
- Scope. Application code, third party libraries, container base images, operating systems, and managed services.
- Prioritization. Severity scores alone mislead. Say you also weigh whether the flaw is exploited in the wild, whether the vulnerable code is reachable, and how exposed the system is.
- Tracking. Where findings live, who owns them, and how you report on overdue items.
- Exceptions. When a patch cannot ship in time, you record a risk acceptance with an owner and an expiry, and add a mitigation.
| Priority | Example trigger | Example target (replace with yours) |
|---|---|---|
| Emergency | Actively exploited in the wild | Shortest target you can meet, with on call |
| High | Critical or high severity and reachable | Days |
| Normal | Moderate severity | Next regular release |
| Low | Low severity or unreachable | Backlog, reviewed periodically |
These rows are a shape, not a promise. Use your real figures.
Using exploitation signals
CISA maintains a catalog of vulnerabilities known to be exploited in the wild. Mentioning that you check it, and that listed items move to your fastest path, shows a reviewer you prioritize on evidence. Do not claim a particular federal deadline applies to you unless it truly does.
Evidence to attach
- Your remediation policy page with a review date.
- A report showing time to fix for recent findings, with names removed.
- An example of a documented exception.
If you are still writing the policy, see how to write a vulnerability remediation SLA policy and set remediation SLA by asset criticality and exposure.
Words to avoid
Avoid "immediately" and "as soon as possible" because they cannot be measured. Avoid "zero vulnerabilities". Avoid promising a fix for every issue found by a customer's scanner, since scanners report false positives and unreachable findings.
Try it yourself
Open the vulnerability management demo and look at how findings are prioritized and tracked toward a fix. This is the kind of view that backs up a patching answer.
Click through it at your own pace, or open it full screen.
Safeguard offers dependency scanning and reachability analysis, which help separate flaws your code can actually reach from those it cannot, and autonomous remediation with fix pull requests is available as an opt in feature that is off by default.
Quick check
Should we publish exact patch timelines?
Only publish figures you reliably meet. If you share a range, track your performance against it so you can show evidence on request.
What if a customer's scan shows an old finding?
Check whether it is reachable and whether a fix exists. Reply with the finding, your assessment and a date, rather than a blanket denial.
Sources
- NIST, SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA, Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
