Give a target by severity, say when the clock starts, say what you do when no fix exists, and back it with measured history. A timeline you have never measured is a promise, and buyers who read the answer closely will ask how often you meet it.
Define the clock
Most disputes come from vague wording. Decide and write down:
- Does the clock start at public disclosure, at your detection, or at triage?
- Does "patched" mean merged, released, or deployed to customers?
- Which severity scale do you use, and do you adjust it for context?
Without these, "critical within 7 days" can mean three different things.
Use more than severity
A severity score alone sends teams to the wrong work. CISA says organizations should use its Known Exploited Vulnerabilities catalog as an input to their prioritization framework, and FIRST describes EPSS as a probability, from 0 to 1, that a CVE will be exploited in the next 30 days. You can say in your answer that actively exploited issues and high exploit probability move a finding up the queue, and that issues in code that is never called move down with a recorded reason.
| Signal | Effect on timeline |
|---|---|
| Listed as exploited in the wild | Fastest track |
| High exploit probability | Faster than severity alone |
| Vulnerable code not reachable | Slower, with a recorded reason |
| No fix available | Mitigate and monitor, with review date |
A model answer
"We set target remediation timelines by severity, measured from the time a finding is confirmed in a product we ship to the time a fixed release is available to customers. Vulnerabilities known to be exploited are handled first regardless of score. When no fix exists we apply a mitigation where possible and review weekly. We track attainment against these targets and can share summary figures."
Replace the generic sentences with your real numbers only if you have them. Leave the numbers out of the public answer if you cannot show attainment data.
Evidence
Offer a policy excerpt, a screenshot of a remediation dashboard, or an export of closed tickets with created and closed dates. Redact customer names and internal hostnames first.
Pitfalls
Do not promise different timelines to different buyers unless contracts require it. Do not describe your target as your performance. If you missed targets last quarter, say how you changed the process. That honest answer tends to land better than a perfect claim.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how exploitation signals change the priority of a finding. Your timeline answer should describe exactly this logic.
Quick check
Should we publish our patch SLA on the trust center?
You can publish the policy and targets. Keep attainment data for NDA sharing unless you are comfortable with it being public.
What do we say about vulnerabilities with no fix?
Say you record the decision, apply mitigations where possible and review on a schedule. Never imply a fix is always available.
Safeguard supports reachability analysis, policies and gates, and fix pull requests that are off by default. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
