Offer tiers you can measure and meet, tied to severity and exploitability, with clear start and stop definitions and an exception path. Do not agree to a single number for all findings, and do not promise what your tooling cannot track. Have counsel review the wording, since this post is general information only.
Why one number fails
A flat "all vulnerabilities fixed in 30 days" sounds neat and breaks in practice. Many findings are unreachable in your product. Some need an upstream fix that does not exist yet. Others need a major version change that takes testing. A blanket promise turns into a standing breach of contract or into rushed, risky changes.
A tiered structure to propose
| Tier | Definition | Proposed target | Notes |
|---|---|---|---|
| Exploited | Listed as exploited in the wild and reachable in the product | Fastest, measured in days | Interim mitigation counts if a fix is not available |
| Critical reachable | Critical severity, reachable | Short, measured in days to a few weeks | |
| High reachable | High severity, reachable | Weeks | |
| Medium and lower, or unreachable | Others | Next scheduled release | Documented reasoning for unreachable |
Choose the actual numbers from your own measured history, not from aspiration. CISA's Known Exploited Vulnerabilities catalog is a reasonable way to define the first tier, since CISA says organizations should use it as an input to prioritization.
Definitions that prevent disputes
- Clock start: when you learn of the finding, or when the advisory is published? Pick one and write it.
- Clock stop: fix released, or fix deployed to the customer? For on-premises software the customer controls deployment.
- Severity source: which scoring and which date's score.
- Exceptions: no fix available, fix requires breaking change, finding is not reachable. State that you will give notice and a mitigation.
Steps to prepare your response
- Pull twelve months of your own remediation data and compute the median time for each tier.
- Draft targets you hit in most cases, with room for the rest.
- Write the definitions above in plain language.
- Prepare the exception process and an example.
- Send a counterproposal, not a refusal, and offer a call.
What to say
"We commit to severity based targets measured from advisory publication for hosted services, and from release availability for on-premises installs. We prioritize findings that are exploited and reachable. Where no fix exists we will provide mitigation guidance and a status update on a regular cadence."
Try it yourself
Click through it at your own pace, or open it full screen. Notice how age and priority are tracked per finding, which is the data you need to prove a timeline.
Safeguard's policies, gates and guardrails can encode tier rules, and its vulnerability tracking helps you measure time to fix. Contract terms are a matter for you and your counsel.
Quick check
Should we count unreachable findings in the commitment?
Often it is better to define the commitment around reachable and exploited findings and document the reasoning for the rest.
What if a fix does not exist upstream?
Say so in the exception clause: mitigation, monitoring and regular updates until a fix is available.
Sources
Last reviewed: 19 October 2026.
