Look at what you did over the last quarter, state a target slightly better than your record, and show three closed examples. Do not invent a service level to match the customer's template. Say what you measure, how you triage, and where you cannot meet their number.
Why the honest answer works
Reviewers ask "how fast do you patch" because they want evidence of a working loop. A number copied from a template but unsupported is the weakest answer. A modest, true number with proof reads better.
Step 1: measure your real record
Pull the last three months of dependency and infrastructure findings that you fixed. For each, note the date it was detected and the date the fix shipped. You need no special tool. A spreadsheet export from your ticket system is enough.
Group by severity as you rate it. Look at the typical time and the slowest cases. The slowest cases usually have reasons: no fix existed, a breaking change, a release freeze. Write those reasons down.
Step 2: choose a target you can keep
| Severity you assign | Starting point | Notes |
|---|---|---|
| Critical and exposed | Fix or mitigate within the shortest window you have actually met | Mitigation counts if the fix needs time |
| High | Plan within your normal release cycle | Record the date |
| Medium and low | Batch into routine updates | Review quarterly |
Do not copy numbers from this table because none are given. Fill them from your own record. A number you meet nine times out of ten is better evidence than a tougher one you meet half the time.
Step 3: define what counts as fixed
Say whether "fixed" means the patched version is deployed, or a mitigation is in place, or the finding is judged not reachable. Customers care about the definition. Be consistent and write it into your policy.
Step 4: use two lanes
Treat findings that are reachable and exposed as urgent. Treat the rest as routine. Reachability and exposure help you spend effort where it counts, and you can explain that approach to a reviewer. Keep a record for each deferred item.
A model answer
"We triage new findings on arrival and prioritise by exposure and whether our code reaches the vulnerable function. Over the last quarter our typical time from detection to fix for items we rated critical was within the window shown in the attached summary. Where no patched version exists we apply a mitigation and track the upstream fix. We do not currently commit to a contractual time for every finding."
Replace the placeholders with your measured figures before sending.
When the customer demands a number
If the contract requires a specific time, take it to the person who can agree to it with a clear view of your record. Do not let a questionnaire answer turn into a commitment by accident. This is not legal advice, so involve counsel for contract terms.
Try it yourself
Open the vulnerability management demo and look at how findings are tracked from detection to closure. Think about which dates you would export for your own record.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning and policies record when findings appear and close, which supplies the dates for this measurement. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is it okay to say we have no SLA?
Yes, if you follow it with what you measure, how you triage and a target you can keep.
Do mitigations count as fixes?
Define it in your policy. Many teams count a verified mitigation for exposed findings and track the full fix separately.
How often should we review the target?
Quarterly. Tighten it when your record supports it.
Last reviewed: 19 October 2026.
