Vulnerability Remediation SLAs: Setting Deadlines a Small Team Can Actually Hit

A remediation SLA is two decisions: how long each severity gets, and when the clock starts. Teams argue endlessly about the first and get the second wrong, which is what actually breaks the numbers.

If the clock starts when someone triages a finding, then a team that ignores its queue for three weeks reports the same on-time percentage as a team that fixes everything the day it appears. The metric measures your triage habits, not your remediation. Auditors know this, buyers' security questionnaires increasingly ask about it, and it is the first thing worth fixing.

Start the clock at first detection, not at triage

The clock starts the moment the finding became knowable to you. For a scanner, that is the scan that first surfaced it. For a dependency advisory, the moment the advisory matched your lockfile. For a report from outside, the moment it arrived in your inbox.

Three consequences follow, and all three are the point:

1. Ignoring the queue costs you. Time spent not looking at a finding is time on the clock. That is the incentive you want.
2. Your numbers become comparable between quarters, and between you and the SLA you promised a customer.
3. The date is machine-generated, so it survives an auditor asking where it came from.

The counter-argument is real: a team returning from a long backlog will breach a lot of SLAs at once. That is not a reason to move the clock. It is a reason to declare a starting baseline — everything open on the day the policy takes effect gets a one-time exception with an agreed catch-up date — and to measure honestly from there.

Materialise the due date; never recompute it

The second implementation detail that decides whether your history is worth anything: write the due date to the row the first time you see the finding, and never derive it again.

If the due date is computed on read from the current policy, then editing the policy rewrites history. Loosen "critical" from 7 days to 14 and every past breach silently becomes compliant. Every report you already sent a customer is now inconsistent with the system that produced it. This is not hypothetical — it is the default behaviour of most homegrown trackers, because computing on read is the obvious way to write it.

Materialising the deadline means a policy change applies to findings discovered after the change, which is also the only version an auditor will accept.

A severity table that survives contact with a five-person team

Published frameworks tend to assume a security function exists. These are the windows small engineering teams actually hit, and the reasoning behind each.

Two rules make this table work in practice:

Exposed credentials get their own row, outside the severity ladder. A live API key in a client bundle is not "critical, 7 days" — it is rotate now. Detection to rotation should be hours. Keep it as its own class or your critical bucket fills with things that are urgent in genuinely different ways.

Publicly-reachable beats theoretically-severe. A medium-severity issue on an unauthenticated production endpoint deserves attention before a high-severity one behind an admin login used by four people. If your tracker cannot express that, add an "exposure" field and sort on both.

Exceptions are a feature, not a failure

The single biggest reason SLA programmes collapse is that there is nowhere to put "we are not fixing this, and that is fine."

Some findings genuinely should not be fixed on schedule: a dependency CVE in a code path you do not call, a header missing on an endpoint that serves one static file, a finding whose fix costs a fortnight and whose impact is a paragraph. Without a documented exception path, those items sit permanently overdue, the overdue count becomes noise, and the team stops reading it.

A usable exception needs four fields and no more:

• Why it is accepted, in one sentence a non-engineer can follow.
• Who approved it.
• When it was approved.
• When it gets reviewed again — always a date, never "indefinitely".

An auditor reading a report with twelve documented exceptions and zero undocumented overdue items sees a working process. A report with zero exceptions and forty overdue items is the one that generates findings.

The four numbers worth reporting

Most vulnerability dashboards report open counts, which mostly tell you how loud your scanner is. These four tell you whether the process works:

1. On-time closure rate, by severity. The percentage of findings closed inside their materialised deadline. Split by severity or the critical signal drowns in low-severity volume.
2. Median time to remediate, by severity. Median rather than mean — one nine-month straggler should not swing the number.
3. Currently overdue, excluding documented exceptions. The single number for a weekly standup.
4. Mean time to triage. Detection to first human decision. If this is climbing while closure rate holds, you are about to breach in volume, and this is the leading indicator.

A fifth, if you can get it: reopen rate. Findings marked fixed that the next scan finds again. A high reopen rate means "fixed" is being used to mean "closed the ticket."

Wiring it into the work, not beside it

An SLA nobody sees is an SLA nobody hits. Three integration points, in order of impact:

Into the tracker. Findings should arrive in Jira or Linear where the work already is, with the due date on the issue, and status should sync both ways. If closing the Jira issue does not close the finding, someone is maintaining two systems and one of them is lying. (Two-way sync needs care: map on the status category — to do, in progress, done — never on the status name, because those are per-project free text and will differ across two teams in the same company.)

Into the pull request. The cheapest possible remediation is the one that happens before merge, where the author still has the context. A finding raised in review never enters the SLA queue at all. See security review in pull requests.

Into a channel with a name on it. Breaching alerts to Slack or Teams, addressed to the assignee rather than to a room. "Someone should look at this" reliably means nobody will.

What CheckVibe does with this

Because a post about honest measurement should be specific about its own product:

• SLA policies on both team tiers. Due dates are materialised at first detection and never recomputed, exactly for the reason in the second section — a deadline that moves when the policy is edited invalidates every historical number.
• The clock starts when we first saw it, not when someone triaged it, so ignoring the queue cannot reset a deadline.
• Shared triage with assignment, comments and an activity trail, so the answer to "who owns this" is a name, not a guess.
• Slack, Microsoft Teams and signed webhook destinations for breach and status alerts.
• Two-way Jira and Linear sync on Team Advanced, mapping on status category rather than status name.
• An append-only audit log — 180 days on Team Basic, a year on Team Advanced — that the database refuses to update, so the remediation history holds up when someone asks where the dates came from.

Team plans are $25 per seat per month, minimum five seats, with Jira/Linear sync and compliance reporting on Team Advanced at $50. Details on the pricing page.

Frequently Asked Questions

When should the remediation clock start?

At first detection — the scan, advisory match, or report that first made the finding knowable — not at triage and not at ticket creation. Starting at triage means a team that ignores its backlog reports the same on-time rate as one that fixes everything immediately, because the delay happens before the clock starts. Detection is also machine-generated, which is what makes it defensible in an audit.

What are reasonable remediation SLAs for a small team?

Seven days for critical, 30 for high, 90 for medium, best-effort with a quarterly review for low, and no deadline for informational. Keep exposed credentials outside the ladder entirely, measured in hours to rotation. These windows are achievable for a five-person team without a dedicated security engineer, which matters more than matching a stricter published standard you will miss every month.

Should the due date be stored or calculated?

Stored, written once when the finding is first seen. A due date calculated from the current policy on every read means editing the policy silently rewrites your entire remediation history — past breaches become compliant, and every report you already sent disagrees with the system. Materialising it means policy changes apply going forward only, which is the only interpretation an auditor accepts.

How do you handle findings you have decided not to fix?

Record an exception with four fields: the reason, the approver, the approval date, and a review date. Never "indefinitely". A documented exception is a functioning control; an undocumented finding sitting permanently overdue is a failure, and worse, it makes the overdue count meaningless so the team stops reading it.

What is a good on-time closure rate?

Above 90% for critical and high, measured from detection, is a healthy programme for a small team. The absolute number matters less than the trend and the split: 95% overall can hide 60% on criticals if low-severity volume dominates. Always report by severity, and always alongside the count of undocumented overdue items.

Do vulnerability SLAs matter outside compliance?

Yes — they are increasingly a line item in enterprise security questionnaires and in the security addendum of B2B contracts. Buyers ask for your severity table and your on-time rate. A team that can answer with a number from a system, rather than a paragraph of reassurance, closes those reviews measurably faster.

CheckVibe ships SLA policies with due dates materialised at first detection, shared triage, and an append-only audit log on both team tiers. See what teams get, or run a free scan to see what would land in the queue today.