Remediation SLA

Overview

The Remediation SLA lets your company define how long a vulnerability may remain open before it must be fixed. The deadline is not a single global number: it is computed from a matrix that combines two dimensions:

• the severity of the vulnerability (Critical, High, Medium, Low); and
• the business impact of the asset where it was found (High, Medium, Low).

Each cell of the matrix holds a time to fix, in days. When a vulnerability is created, the platform looks up the cell that matches its severity and its asset's business impact, adds that many days to the date the vulnerability was created, and stores the result as the vulnerability's SLA deadline.

From then on, every view of the vulnerability shows a live SLA state (On Track, Approaching, Breached, …) calculated against the current date, and the platform sends notifications as deadlines get close or pass.

note

The SLA is configured per company and applies to every asset and vulnerability in that company. A vulnerability only receives a deadline when both its severity is tracked and its asset has a business impact and the matrix has a cell for that combination.

The SLA Matrix

The matrix is a grid of severity × business impact. With four tracked severities and three business-impact levels, it holds up to 12 cells, each with its own number of days to fix.

	Business impact: High	Business impact: Medium	Business impact: Low
Critical	e.g. 7 days	e.g. 15 days	e.g. 30 days
High	e.g. 15 days	e.g. 30 days	e.g. 45 days
Medium	e.g. 30 days	e.g. 60 days	e.g. 90 days
Low	e.g. 60 days	e.g. 90 days	e.g. 180 days

The values above are only an example — you set the days that match your organization's remediation policy.

info

You do not have to fill in every cell. Cells you leave empty simply mean "no SLA defined for this combination": vulnerabilities that fall into an empty cell get no deadline and are reported as Not Parameterized (see SLA States).

Configuring the Matrix

1. Open your company's SLA configuration screen.
2. For each severity / business-impact combination you want to track, enter the number of days to fix (must be a whole number greater than zero).
3. Save. The whole matrix is saved as one atomic operation:
   • cells you filled in are created or updated;
   • cells you cleared are removed.

When you save, the platform recomputes the deadline of every open vulnerability in the company in the background, so existing findings immediately reflect the new policy. Resolved vulnerabilities are left untouched.

The SLA Deadline

The deadline is anchored on the date the vulnerability was created, not on the date the SLA was configured or the date the severity changed:

SLA deadline = creation date + (days to fix for this severity × business impact)

Anchoring on the creation date means the clock reflects how long the vulnerability has actually existed. A consequence worth knowing:

warning

If you raise a vulnerability's severity (or it is reclassified later), the deadline is recomputed from the original creation date with the new, shorter window. A finding that has been open for a long time can therefore become Approaching or even Breached the moment its severity goes up — the platform treats it as "it was always this severe, we just learned it later."

SLA States

Every vulnerability shows one of the following states. The state is computed on every read against the current date, so it is always up to date without any background job having to "move" the vulnerability between states.

State	Meaning
On Track	The deadline is in the future and less than 75% of the SLA window has elapsed.
Approaching	The deadline is still in the future, but 75% or more of the SLA window has already elapsed. This is the early-warning state.
Breached	The deadline has passed and the vulnerability is still open.
Resolved	The vulnerability reached a terminal status (Fixed/Risk Accepted, False Positive, or Suppressed). SLA tracking stops.
Not Tracked	The finding is informational (notification severity). Informational findings never carry a remediation SLA — they stay Not Tracked even after they are closed.
Not Parameterized	The vulnerability has no deadline because of a configuration gap — its asset has no business impact set, or the matrix has no cell for its (severity, business impact) combination. This is actionable: fill in the missing piece and the deadline appears.

note

State precedence. When more than one condition applies, the state is decided in this order: Not Tracked (informational severity) first, then Resolved (terminal status), then Not Parameterized, then the live clock states (On Track / Approaching / Breached). Two consequences worth knowing:

• An informational finding stays Not Tracked even once it is closed — it was never an SLA item, so it is never reported as Resolved.
• A vulnerability without a deadline that gets closed is shown as Resolved, not Not Parameterized — a closed finding no longer needs its configuration gap fixed, so it is not flagged as actionable.

A few concrete combinations make the precedence easier to read:

Severity	Status	Has a deadline?	State
Notification (informational)	Open or closed	— (never gets one)	Not Tracked
Critical / High / Medium / Low	Closed (terminal)	Yes	Resolved
Critical / High / Medium / Low	Closed (terminal)	No (unparameterized)	Resolved
Critical / High / Medium / Low	Open	No (unparameterized)	Not Parameterized
Critical / High / Medium / Low	Open	Yes	On Track / Approaching / Breached

Days Remaining

Alongside the state, the platform shows days remaining until the deadline:

• a positive number while On Track or Approaching;
• a negative number once Breached (how many days overdue);
• empty when the vulnerability is Resolved, Not Tracked, or Not Parameterized.

Filtering and Sorting by SLA

In the Vulnerabilities list you can:

• Filter by SLA state — select one or more states (e.g. show only Breached and Approaching) to focus on what needs attention. Filtering is multi-select: choosing several states shows vulnerabilities in any of them.
• Sort by SLA deadline — order the list by deadline, ascending or descending.

note

When sorting by deadline, vulnerabilities without a deadline are always placed at the end of the list, regardless of sort direction, so unmeasured findings never crowd the top. This covers every deadline-less finding — Not Tracked and Not Parameterized, but also a Resolved vulnerability that never had a deadline (e.g. one closed before its SLA was parameterized).

Notifications

A scheduled job runs once a day and sends two kinds of SLA notification:

• Approaching — the vulnerability has just crossed the 75% mark of its SLA window (the same threshold as the Approaching state).
• Breached — the vulnerability has just passed its deadline while still open.

Each notification is sent once per vulnerability per kind: you get at most one Approaching alert and one Breached alert for a given vulnerability.

Recipients are:

• the people assigned to the vulnerability; plus
• the members of the teams attached to the vulnerability's asset (active accounts only).

info

SLA notifications use dedicated notification workflows. They are delivered through the platform's standard notification channels for your company.

Edge Cases and Behavior to Know

This section documents the less obvious behavior so there are no surprises.

Informational findings are never tracked

Findings with informational (notification) severity never receive a deadline and always show as Not Tracked, no matter how the matrix or the asset's business impact is configured — and even after they are closed: an informational finding in a terminal status is still reported as Not Tracked, not Resolved, because it was never an SLA item. They are excluded from SLA notifications and from SLA sorting/filtering totals.

Assets without a business impact

If an asset has no business impact set, its vulnerabilities cannot be matched to a matrix cell and are reported as Not Parameterized:

• New vulnerabilities on that asset are created without a deadline.
• When you set the asset's business impact, the platform recomputes deadlines for that asset's open vulnerabilities in the background, and they move out of Not Parameterized.
• When you clear an asset's business impact (set it back to empty), the platform removes the deadline from that asset's open vulnerabilities, moving them back to Not Parameterized. Their previous deadline is discarded, not frozen.

Saving the matrix over an existing backlog

The first time a company configures its matrix — or any time you change it — every open vulnerability is back-filled with a deadline. Because deadlines are anchored on the creation date, a large backlog can produce many deadlines that are already in the past, i.e. immediately Breached.

note

Back-filling a past-due backlog does not trigger a flood of notifications. Notifications fire only when a vulnerability crosses a threshold within the recent window (see below) — deadlines that land in the past on configuration are treated as historical and are not re-announced. You will see them as Breached in the list, but no notification storm is sent.

Deleting a matrix cell

Removing a cell from the matrix (saving the matrix without that combination) clears the deadline from the open vulnerabilities that depended on it; they return to Not Parameterized until a cell covers their combination again.

Resolved vulnerabilities

Once a vulnerability reaches a terminal status (Fixed/Risk Accepted, False Positive, or Suppressed) it is Resolved for SLA purposes: it stops being tracked, is excluded from notifications, and is left untouched by matrix recalculations. If a Fixed vulnerability is detected again, it reverts to an open status and SLA tracking resumes against its existing deadline.

The one exception is informational findings: a closed notification-severity finding stays Not Tracked rather than Resolved (see State precedence). A closed vulnerability that had no deadline, on the other hand, is reported as Resolved — not Not Parameterized — since a closed finding no longer needs its configuration gap fixed.

Re-breaching after a deadline change

Because each vulnerability is alerted at most once per kind, extending a deadline (for example by lowering its severity and later raising it again) does not generate a second Breached notification if one was already sent. The in-list state, however, always reflects the current deadline.

Notification timing and outages

The daily job evaluates threshold crossings within a 48-hour window — double its daily cadence — so a late run or a one-day outage still catches the crossings it would otherwise have missed. An outage longer than 48 hours can cause some crossings in that gap to go unannounced; the affected vulnerabilities still show the correct state in the list, only the one-time notification is skipped. This is the same trade-off as the platform's other daily digest notifications.

Summary

• The SLA is a per-company matrix: severity × business impact → days to fix.
• The deadline is creation date + days to fix; raising severity recomputes it from the original creation date.
• The state (On Track / Approaching / Breached / Resolved / Not Tracked / Not Parameterized) is computed live on every read.
• You can filter the vulnerability list by SLA state and sort by deadline (unmeasured findings sort last).
• A daily job sends one Approaching and one Breached notification per vulnerability, to assignees and the asset's teams.
• Configuration changes and business-impact changes recompute deadlines in the background without re-announcing historical breaches.