Most vulnerability programs do not fail because they cannot find issues. They fail because nobody agreed on how fast each issue has to be fixed. A scanner reports thousands of findings, the queue grows, and without a clock attached to each item there is no honest way to say whether the program is on track or quietly falling behind.
A service-level agreement, or SLA, is the clock. In vulnerability management it answers one question in concrete terms. Once a finding is confirmed, how many hours or days do you have to close it before you have broken your own commitment? This article defines what a vulnerability management SLA is, how deadlines are tied to severity, what a breach actually means, and how pausing, severity changes and escalation fit the picture. It stays at the level of definitions. Where a topic has its own deeper mechanics, you will find a link to follow.
What an SLA Means in Vulnerability Management
In the broadest sense, a service-level agreement is a documented commitment about the quality or speed of a service. In vulnerability management the service is remediation, and the commitment is time. A remediation SLA is the maximum amount of time a finding of a given severity may remain open before it counts as overdue.
Three pieces make a vulnerability SLA concrete. The first is a starting point, usually the moment a finding is created or confirmed. The second is a duration, expressed in hours or days, that depends on how severe the finding is. The third is a resulting deadline, which is simply the start time plus the allowed duration. When you say “critical findings must be fixed within 72 hours,” you have described all three. The start is finding creation, the duration is 72 hours, and the deadline is whatever timestamp falls 72 hours later.
This matters because an SLA turns a vague intention into a measurable promise. “We patch quickly” cannot be audited. “Critical findings are remediated within 72 hours of confirmation, 95 percent of the time” can be. The SLA is what makes the difference between a program people believe and a program people can actually verify.
It is worth being precise about what the SLA does not do. An SLA does not fix anything by itself. It does not decide which finding is more important on technical grounds. It is a governance layer that sits on top of the work, setting the deadline and making lateness visible. The remediation still has to happen. The SLA only tells you how late you are if it does not.
SLA vs SLO vs KPI: Quick Definitions
These three terms get used interchangeably, and the confusion causes real problems when teams try to report on their programs. They are related but distinct.
An SLA is the agreement itself, the committed target. “Critical findings are remediated within 72 hours” is an SLA. It is the promise, and a breach of it has consequences, whether contractual, regulatory or reputational.
An SLO, or service-level objective, is the internal goal you set in order to stay safely inside the SLA. If your SLA with a customer is 72 hours, your internal SLO might be 48 hours, giving you a buffer so that ordinary delays do not turn into breaches. The SLO is usually stricter than the SLA. It is what the team aims for, not what it is contractually held to.
A KPI, or key performance indicator, is the measurement that tells you whether you are meeting the SLA and the SLO. Mean time to remediate, the percentage of findings closed within SLA, and the count of currently breached findings are all KPIs. The KPI is the number on the dashboard. The SLA is the line that number is judged against.
In short, the SLA is the promise, the SLO is the safety margin, and the KPI is the evidence. A mature program tracks all three. This article is about the SLA layer, but every remediation deadline you set is what your KPIs will later be measured against.
Why SLAs Are Tied to Severity
Not every finding deserves the same urgency, and treating them all the same is how programs drown. A critical remote code execution flaw on an internet-facing server and a low-severity informational finding on an isolated test box are not the same problem, and giving them the same deadline either rushes the trivial work or under-prioritizes the dangerous one.
The standard answer is to tie the SLA to severity. Higher severity means a shorter deadline. The reasoning is straightforward. Severity is a proxy for how much damage a finding could cause and how attractive it is to an attacker, so the more severe a finding is, the less time you can responsibly leave it open. This is the core idea behind risk-based remediation timelines, and it is reflected in public guidance as well. The CISA Binding Operational Directives use a due-date model in which more urgent classes of vulnerability carry tighter remediation windows, and NIST patch management guidance frames remediation timing around risk rather than a single universal deadline.
The practical result is a small table. Each severity maps to a number of hours, and that number is the SLA duration for any finding at that severity.
Typical Severity-to-Deadline Mappings
A common way to express this is a five-tier scale running from urgent down to low. The exact hours are a policy choice, but a representative default set looks like this.
| Severity | SLA duration | Roughly |
|---|---|---|
| Urgent | 24 hours | 1 day |
| Critical | 72 hours | 3 days |
| High | 168 hours | 7 days |
| Medium | 720 hours | 30 days |
| Low | 2160 hours | 90 days |
These specific numbers are the built-in fallback values a platform might use when no custom policy has been configured. They are a sensible starting point rather than a law. A regulated organization with a strict patching mandate may shorten them, and a team with limited remediation capacity may negotiate longer windows for lower tiers. The point is the shape, not the exact figures. Severity climbs, the deadline tightens, and every finding inherits a duration from the tier it lands in.
In practice these mappings are rarely set once and frozen. A platform that manages SLAs usually lets you define them at more than one scope. A company-wide default can apply across the board, and a specific project that carries higher contractual obligations can override one or more severities with tighter numbers. Any severity left unset simply inherits the value from the level above it, so a team can tighten only the tiers that matter to a given contract and let the rest cascade.
What an SLA Breach Is
A breach is the moment a promise is broken. In vulnerability management terms, a finding has breached its SLA when its deadline has passed and the finding is still open. Both conditions have to be true. A finding that was closed before its deadline is not a breach, even if it took most of the allowed time. A finding whose deadline is in the future is not a breach, even if it has been sitting untouched.
The mechanics are simple to picture. Every open finding carries an SLA deadline, computed from its creation time and its severity-based duration. As long as the finding is closed, accepted as risk, or otherwise resolved before that deadline, the SLA is met. The instant the deadline passes while the finding is still in an open state, it is in breach.
Breaches are the most important single signal a program produces, because they represent commitments the organization has already failed to keep. A growing breach count is not a backlog problem to schedule around later. It is a list of promises currently being broken, and it is usually the first thing an auditor, a customer security questionnaire, or a board-level risk review will ask about. This is why breached findings are typically surfaced at the very top of any SLA dashboard rather than buried in a report.
How SLA Clocks Pause and Resume
Real remediation work does not always run uninterrupted, and a fair SLA model has to account for that. The mechanism is a pause and resume on the SLA clock.
A pause stops the countdown. There are legitimate reasons to do this. A finding might be blocked waiting on a third-party vendor to ship a patch, or it might be parked behind a change-management window where no deployment is allowed. During such a period the remediation team genuinely cannot act, so continuing to burn down the clock would penalize them for a delay outside their control. Pausing freezes the deadline so that the time spent waiting does not count against the SLA.
A resume restarts the countdown and, importantly, accounts for the time that was lost. The system records how long the finding was paused and effectively pushes the deadline out by that same amount. The net effect is that a finding always gets its full allotted working time, regardless of how many legitimate interruptions occurred along the way. A finding that was paused for ten days ends up with a deadline ten days later than it would have had if it had never been paused.
The takeaway at the definition level is that an SLA deadline is not necessarily a fixed timestamp set once at creation. It is a live value that can move when the clock is paused and resumed, so that the promise reflects only the time the team could actually have been working.
What Happens When Severity Changes
Severity is not always correct on the first pass. A finding might be raised as high and then, after triage or enrichment, reassessed as critical because it turns out to be exploitable on an exposed asset. It might also go the other way and be downgraded once it is understood to be unreachable in practice. When severity changes, the SLA cannot stay where it was.
The reason is direct. The SLA duration comes from the severity tier, so if the severity changes, the duration changes, and therefore the deadline has to be recomputed. A finding that was high with a 168-hour window and is upgraded to critical should now be measured against a 72-hour window. Leaving the old deadline in place would mean tracking the finding against a promise that no longer matches its risk. Recalculation keeps the deadline honest by re-deriving it from the new severity, while still respecting any time the clock was paused.
There is a subtle and useful detail here. If recalculation produces a new deadline that is now in the future, the system can reset the finding’s notification state so that the team is warned again as the new deadline approaches. This prevents a downgraded finding from silently slipping past everyone’s attention just because its earlier alert already fired.
This recalculation has more moving parts than a definition can do justice to, including the order in which different policy scopes take precedence and how paused hours fold into the new deadline. If you want the full mechanics, see the deeper explainer on SLA deadline recalculation.
SLA Escalation in Plain Terms
A deadline that nobody is reminded about is just a number in a database. Escalation is the mechanism that turns an approaching or missed deadline into action by putting it in front of progressively more senior people.
The common pattern is tiered escalation, often three levels. Each level is defined by a contact and a trigger, typically expressed as a number of days after the breach. The first level might notify the assigned remediation owner shortly after the deadline passes. If the finding is still open some days later, the second level notifies that owner’s manager. If it remains open beyond a further threshold, the third level escalates to a security lead or a department head. Each step widens the circle of accountability.
The purpose of tiering is to match the response to how long a problem has been ignored. A breach that gets resolved a day late never needs to reach a manager. A breach that is still open two weeks later clearly does, because the normal owner has either been blocked or has dropped it, and someone with more authority needs to intervene. Escalation chains encode that judgment as policy instead of relying on someone to remember to chase it.
Like the deadlines themselves, escalation contacts and timing are usually configurable per scope, so a high-stakes project can route breaches up the chain faster and to different people than a routine internal one.
Where SLA Targets Come From
SLA durations are not chosen at random. They generally come from one of three sources, and most real policies are a blend of all three.
The first is regulatory. Standards bodies and government directives increasingly set explicit remediation expectations. The CISA Known Exploited Vulnerabilities catalog, for example, attaches due dates to vulnerabilities that are being actively exploited, effectively dictating an SLA for the agencies and organizations bound by it. CIS Controls likewise call for timely remediation of discovered vulnerabilities. Where such mandates apply, they often set the strictest deadlines a program must honor.
The second is contractual. A vendor that processes a customer’s data may commit, in writing, to remediating critical vulnerabilities within a defined window. That commitment becomes an SLA the vendor must track and report against, and missing it can carry real penalties.
The third is internal policy. Beyond anything externally imposed, a security team sets its own deadlines based on its risk appetite and its remediation capacity. These internal targets fill the gaps that no regulation or contract addresses, and they are usually where the bulk of the day-to-day SLA model actually lives.
When these sources conflict, the strictest one generally wins, because meeting the tightest deadline automatically satisfies the looser ones. This is also why per-scope overrides are valuable. A single project bound by a demanding contract can carry tighter deadlines than the organization’s general baseline without forcing everyone else onto the same schedule.
Why SLAs Make Vulnerability Programs Measurable
The deepest value of an SLA is that it converts remediation into something you can measure, report and improve. Without deadlines, the only metric available is volume, the raw count of open findings, and volume is a famously misleading number. A team that closes a thousand trivial findings while leaving three critical ones open for a month looks busy and is actually failing.
Attach SLAs and the picture sharpens immediately. You can now ask the questions that matter. What percentage of critical findings are closed within their SLA? How many findings are currently in breach? Is the breach count trending up or down? How long, on average, does it actually take to remediate each severity tier, and how does that compare to the deadline you committed to? These are the questions that tell you whether the program is healthy, and none of them can be answered without an SLA to measure against.
This is also what makes a program defensible to outsiders. An auditor, a customer, or an executive does not want a tour of the scanner. They want evidence that risks are being closed inside agreed timeframes. SLA-based metrics are exactly that evidence, and they connect directly to the broader compliance and audit picture covered in the vulnerability management compliance and audit guide.
Why PMAP
PMAP treats the SLA as a first-class part of every finding rather than a manual spreadsheet exercise. When a finding is created, its deadline is computed automatically from its severity using the configured policy. Deadlines can be set at the company level and overridden per project, with any unset severity inheriting from the level above it. When severity changes or the clock is paused and resumed, deadlines recompute so the promise always matches the finding’s current state. Breaches and approaching deadlines surface in the analytics layer, and tiered escalation routes them to the right people on a schedule you control. The result is that a remediation promise is something the platform tracks and proves, not something a team has to remember.
To see how SLA deadlines, breaches and escalation are surfaced as live metrics, explore the PMAP risk analytics and SLA KPIs datasheet.
Frequently Asked Questions
What is an SLA in vulnerability management?
An SLA in vulnerability management is a committed timeframe for remediating a finding. It defines the maximum time a finding of a given severity may remain open before it counts as overdue. The deadline is derived from when the finding was created plus an allowed duration that depends on its severity.
How are remediation SLAs set by severity?
Each severity tier is mapped to a duration, and higher severity means a shorter deadline. A common default set assigns roughly 24 hours to urgent, 72 hours to critical, 168 hours to high, 720 hours to medium and 2160 hours to low findings. The exact hours are a policy choice and can be tightened for regulated or high-stakes scopes.
What does an SLA breach mean?
A breach means a finding’s deadline has passed while the finding is still open. Both conditions must hold. A finding closed before its deadline is not a breach, and a finding whose deadline is still in the future is not a breach. Breach count is one of the most important signals a program reports, because it lists commitments currently being missed.
Can an SLA clock be paused?
Yes. A pause stops the SLA countdown when the team genuinely cannot act, for example while waiting on a vendor patch or a change-management window. When the work resumes, the deadline is pushed out by the amount of time the clock was paused, so the finding keeps its full allotted working time and the delay does not unfairly count as a breach.
What happens to the SLA when a finding’s severity changes?
The deadline is recalculated. Because the SLA duration comes from the severity tier, a change in severity changes the allowed time, so the deadline is re-derived from the new severity while still accounting for any paused hours. If the new deadline lands in the future, notifications can be reset so the team is warned again as it approaches. The full mechanics are covered in the SLA deadline recalculation explainer.
What is the difference between an SLA and an SLO?
An SLA is the committed target you are held to, such as “critical findings remediated within 72 hours.” An SLO is a stricter internal goal you set to stay safely inside the SLA, such as aiming for 48 hours. The SLA is the promise with consequences attached, and the SLO is the safety margin the team works toward.
Where do SLA deadlines come from?
They come from three sources that are usually blended together. Regulatory mandates such as the CISA Known Exploited Vulnerabilities due-date model set externally required deadlines, contractual obligations commit a vendor to specific windows for customers, and internal policy fills the rest based on the team’s risk appetite and capacity. When sources conflict, the strictest deadline generally wins.
SEO summary: Definition-first glossary article owning the primary keyword “vulnerability management sla.” Covers what a remediation SLA is, the SLA versus SLO versus KPI distinction, severity-based deadlines with a representative 24/72/168/720/2160-hour mapping, breach meaning, pause and resume, severity-change recalculation at definition depth, tiered escalation, and where SLA targets originate. Upward internal link to the P1-08 compliance and audit pillar and a cluster link to the P3-07 recalculation mechanics explainer. External authority references to CISA Binding Operational Directives, the CISA KEV due-date model, NIST patch management guidance and CIS Controls. Schema: Article plus FAQPage with seven questions.
