A vulnerability SLA is an internal target for how quickly a finding is fixed or mitigated once it is confirmed, usually varying by severity or exposure. Customer success should describe it as a target with a process behind it, not as a guarantee, unless a contract says otherwise and legal has approved the wording.
What the term covers
"SLA" is used loosely. Inside security it often means a service level target for remediation time. In a contract, it can mean a binding commitment with consequences. Customer success lives where those two meanings meet, so they need to know which one they are talking about.
| Term | Meaning | Who can promise it |
|---|---|---|
| Internal remediation target | How fast we aim to fix, by category | Security and engineering leadership |
| Contractual commitment | A fixed term in a customer agreement | Legal and the contract owner |
| Customer notice window | When we tell customers about an event | Legal and security, per policy |
Customer success should never convert the first into the second in conversation.
What to say when a customer asks
A safe answer has four parts:
- We have a documented process for assessing and fixing vulnerabilities.
- Fix targets depend on severity and exposure, and the targets are set by security and engineering.
- We assess exploitation evidence as well as scores. (CISA's exploited-vulnerability catalog is one input it recommends for prioritization, per its KEV page.)
- For anything in the contract, the contract wording applies. We can send the relevant section.
Why severity alone does not set the clock
Many targets are tied to a severity band. That is a reasonable start, but FIRST says CVSS is designed to measure severity and should not be used alone to assess risk (FIRST). Mature processes move the clock for exposure and exploitation. A customer who asks "why was this fixed in two days and that one in two months?" deserves the real answer: one was exposed and exploited, the other was not reachable.
Handling a missed target
Targets get missed. Agree in advance what customer success says: the target was missed, here is the reason, here is the new date, here is the interim mitigation. Do not hide it and do not blame a team by name.
Keep a shared FAQ
Maintain a short internal FAQ with approved answers to the questions customers ask most:
- How fast do you fix critical issues?
- Do you tell customers about vulnerabilities in your product?
- How do you know whether a library issue affects you?
- Can we see your latest report?
Update it after every quarter or notable event. The goal is that every customer hears the same answer.
A word on proof
If a customer wants evidence, offer what exists: policy documents, a summary of process, or a sample of recent fixes with identifying details removed. Do not describe any audit as finished unless it is.
Try it yourself
Click through it at your own pace, or open it full screen. Click through the workflow to see findings, owners and states. This is the process behind a fix target, which is what customer success is describing.
Where Safeguard fits
Safeguard's policies, gates and guardrails can make fix targets visible and enforceable inside the workflow. The free scan is at gold.safeguard.sh/scan.
Quick check
Can customer success quote a fix time?
Only the internal target as a target, and the contract wording if there is one. Never an invented number.
What if a customer demands a guaranteed timeline?
Route it to the contract owner and legal. Do not agree to it on a call.
Sources
Last reviewed: 19 October 2026.
