State your remediation targets by severity, say when the clock starts, describe how exceptions are approved, and point to evidence that you meet the targets. Avoid a single flat number for everything and avoid words like "immediately", which no one can verify.
What the buyer is trying to learn
Reviewers want to know whether you find issues, rank them sensibly and fix them in a predictable time. The exact numbers matter less than a defined process you follow and can show.
Decide your policy first
Do not write an answer to fit the questionnaire. Write a policy and then answer from it. A usable policy includes:
- Severity bands. Critical, high, medium, low, with what each means in your environment.
- Targets. Days to remediate or mitigate per band, set at levels you meet most of the time.
- Clock start. Discovery, advisory publication or triage? Pick one and state it.
- Exploitability override. A known exploited issue may jump the queue regardless of score.
- Exceptions. Who can approve a delay, for how long, with what compensating control.
Sample wording
"We classify vulnerabilities by severity and exploitability. Critical issues that affect our production systems are targeted for remediation or mitigation within a defined number of days set in our vulnerability management policy, with known exploited issues prioritised ahead of score. Exceptions require documented approval and a compensating control. We track remediation in our ticketing system and review the backlog weekly."
Replace the generic phrase with your real numbers.
Prove it with a metric
Pick one evidence type: a report of closed tickets by severity with open and close dates, or a dashboard export. Redact customer data. If you miss targets sometimes, say so, and show the exception process working.
The questions behind the questions
Expect follow ups on third party components, container images and cloud misconfigurations. Make sure your answer covers dependencies as well as your own code. See answering SBOM questions.
Prioritisation helps your numbers
If every finding is treated as urgent, targets get missed and exceptions pile up. Ranking by exploitability and reachability keeps the urgent list short enough to meet. Safeguard's reachability analysis is built for this kind of narrowing.
Quick check
Should we promise a fix time for every customer reported issue?
Promise a triage and acknowledgement time. Fix times depend on severity and complexity, so tie them to your policy bands.
What if a vendor patch does not exist yet?
Describe mitigation options such as configuration changes or isolation, and record the exception with a review date.
Last reviewed: 19 October 2026.
