Remediation SLA

What it means

A remediation SLA is a written commitment to fix vulnerabilities within a set time, with a shorter time for worse ones. A typical policy might allow days for critical findings, weeks for high ones and a longer period for medium and low. The exact numbers are yours to choose, and they are usually set in a security policy.

SLA stands for service level agreement, though here it is often an internal promise as much as a contract. It names who owns the fix, when the clock starts, and what counts as done. Without those three points the numbers mean little.

Why it matters

Without a deadline, security fixes lose to feature work every time. A deadline gives the owner a reason to schedule the fix and gives the business a way to see whether it is being met. Customers and auditors often ask for the policy and then for evidence that you followed it.

It also protects you when a fix cannot meet the deadline. A documented exception with an owner and an end date, handled through risk acceptance, looks very different from a finding that has simply sat for a year. Measuring against it feeds directly into mean time to remediate.

How it shows up

You will meet it in security policies, in vendor questionnaires, and in the due dates on tickets. Compliance frameworks such as PCI DSS expect high-risk findings to be fixed and verified, and customers often write expected windows into contracts. Most ticketing tools can show the due date and flag the overdue items.

The common failures are an unclear start date, severity ratings nobody trusts, and tickets closed because a fix was merged rather than because it works. Start the clock when the finding is confirmed, base severity on evidence, and close it only after a verified fix. Write the rule down once, and apply it to every team, so there is no argument later.