Do not invent a number to fit the form. Write down realistic targets by severity this week, check them against your last few real fixes, and answer with those targets and the date they took effect. If you have not met them yet, say they are internal targets, not contractual commitments.
Why this question is common
Reviewers ask for patch timelines because they want to know how long a known flaw stays open in software that handles their data. A written target shows you have thought about it. A measured record shows you meet it.
The worst answer is a confident number you have never achieved. A reviewer may ask for examples, and one missed example undermines everything else you said.
Set targets from your own history
- Pull the last ten to twenty vulnerabilities you fixed, from tickets or advisories.
- For each, record the date you learned of it and the date the fix shipped.
- Group them by severity and note the longest and the typical time.
- Set a target slightly better than your typical time, not your best case.
- Add an exception route for cases where no fix exists, such as a mitigating control with a review date.
- Write the result on one page, with an owner and an effective date.
A layout for the page
| Severity | Target to remediate or mitigate | Exception route |
|---|---|---|
| Critical | Short, in days | Mitigation plus a dated review |
| High | Longer, in weeks | Same |
| Medium | Next planned release | Same |
| Low | Backlog review each quarter | Same |
Fill the target column from your own history. This post deliberately gives no numbers, because the right ones depend on your product and team.
How to word the answer
"We maintain internal remediation targets by severity, effective from a stated date. Exceptions are recorded with a mitigation and a review date. Recent examples are available on request." That sentence promises nothing you cannot show.
Avoid "all vulnerabilities are patched within a stated time". Words like all and every are easy to break with a single case. Say "we target" and "we track".
Adjust for exploitability
Severity scores are not the whole story. A flaw that is being exploited in the wild, or that sits in code you actually call, deserves faster handling than one buried in an unused function. Reachability analysis helps here, and so does a public list of known exploited flaws. Write your rule for moving an item up the queue, and record the reason each time you use it.
Keep evidence that the target is real
- A ticket for each finding with discovery and fix dates.
- A monthly count of items open past target, with owners.
- Exception records with approver and review date.
- A short note each quarter on whether the targets still fit.
Where Safeguard fits
Safeguard's dependency scanning, reachability analysis and vulnerability management give you the discovery dates and exploitability context behind each ticket, and fix PRs from autonomous remediation are off by default with every category on Manual, so a person approves each change. The demo shows a vulnerability workflow.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how each finding carries a status and a date you could cite.
Quick check
Can we copy a standard timeline from a template?
Only if your history shows you can meet it. Otherwise set targets from your own record and improve them.
Is a target the same as an SLA?
No. An SLA is usually a contractual commitment. Call yours an internal target unless a contract says otherwise.
Last reviewed: 19 October 2026.
