{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Open findings use this date to calculate days remaining or days past SLA.
Start from a common vulnerability-management policy, then adjust the days to match your control owner agreement.
Use fix availability when teams cannot remediate until a vendor patch exists.
Critical findings should normally be the shortest business-approved window.
days
Use the high window your scanner gate and patch program actually enforce.
days
Medium findings often align to planned patch cycles or routine releases.
days
Low findings can still breach if they remain in backlog beyond the policy window.
days
Use this for active exploitation or KEV-style urgent remediation queues.
days
Paste scanner exports, ticket rows, or a trimmed backlog slice. Dates should be YYYY-MM-DD when possible.
{{ sourceMeta }}
Use the same label your scanner, ticket queue, or risk register uses.
Default 7 days keeps the base SLA math unchanged.
days
This affects triage wording only, not the breach due date.
%
Leave at 0 unless a formally approved exception applies to the queue.
days
Show the highest-pressure open findings first.
rows
{{ header }} Copy
{{ cell }}
No rows for the current vulnerability input.
Tags: Devops, Security
Export to PDF Fullscreen
Customize
Advanced
:

Vulnerability remediation service level agreements turn security findings into dated repair commitments. A finding is not only critical, high, medium, or low; it also has an age, an owner, a due date, and sometimes an approved exception. Those dates matter when a patch queue has more work than a team can finish in one maintenance window.

A useful remediation review starts with the question of when the clock begins. Some teams count from the first detected date. Others wait until a vendor fix is available, or use the later of discovery and fix availability so a backlog is not penalized for a patch that did not exist. Once the start date is set, the severity window, exploited status, and exception days decide whether a row is still in SLA, due soon, overdue, or closed late.

Timeline showing detected date and fix availability feeding an SLA start date, then due date, reference date, and overdue area.

Severity alone should not be mistaken for business risk. A high-severity issue in an isolated test host may need a different owner conversation than a medium issue on an exposed production service, and an actively exploited vulnerability can deserve a shorter cap than its normal severity window. The SLA view is strongest when it is paired with scanner evidence, asset context, patch availability, and a clear exception record.

The result is a planning and audit aid, not a vulnerability scanner. It does not confirm exploitability, prove that a patch was deployed, or validate that an accepted-risk decision is appropriate. It converts the dates and flags already in the queue into due dates, status labels, breach counts, and owner-focused follow-up rows.

Technical Details:

Remediation SLA math is calendar-day date arithmetic applied to a normalized vulnerability record. Each usable record needs a detected date or a fix-availability date that can become the SLA start. The reference date represents the reporting day for open findings, while a fixed date represents the closure day for closed findings.

Severity sets the base remediation window. Text labels such as critical, high, medium, and low are preferred when present. When a numeric CVSS-style value is supplied instead, the qualitative cut points follow the common CVSS v3.1 scale: 9.0 and above is critical, 7.0 to 8.9 is high, 4.0 to 6.9 is medium, and a positive score below 4.0 is low. Unknown severity stays visible and uses the low-severity window for due-date math, with a warning so the row can be corrected.

Known exploited treatment is a cap, not a separate lookup. Rows marked exploited, active, KEV, or known exploited use the shorter of the severity window and the configured exploited cap when that cap is greater than zero. Exception days are then added after that cap decision, so an approved extension increases the effective SLA window for the row.

Formula Core

The core due date is the selected SLA start date plus the effective SLA days. Open findings compare that due date with the reference date. Closed findings compare the fixed date with the same due date.

D = S + E
E = B + X
Symbol Meaning Source in the record or settings
D Calculated due date SLA start date plus effective SLA days.
S SLA start date First detected, fix availability, or the later of those two dates.
E Effective SLA days Base SLA days plus row-level or default exception days.
B Base SLA days Severity window, shortened by the known exploited cap when the row is flagged and the cap is enabled.
X Exception days Row extension_days value, or the default extension when the row leaves that field blank.

Rule Core

Status labels are deterministic from the row dates, policy windows, and advanced thresholds. The due-soon buffer and at-risk percentage change triage wording only; they do not move the due date.

Status Boundary Meaning
Open in SLA Open, not overdue, not due soon, and below the at-risk progress threshold The row still has time before its due date under the current settings.
At risk Open, days remaining > due-soon buffer, and SLA progress >= at-risk percentage The row is consuming most of its window and needs owner confirmation.
Due soon Open, days remaining >= 0 and <= due-soon buffer The due date is close enough to appear in the watch queue.
Overdue Open and days remaining < 0 The finding has passed its calculated due date.
Closed in SLA Fixed date is on or before the due date The closure date meets the calculated SLA window.
Closed late Fixed date is after the due date The historical record missed its calculated SLA window.
Closed date missing Status is closed but no fixed or resolved date is parsed The row cannot prove whether closure met SLA.
Invalid date No usable detected date for SLA aging The row is excluded from valid-record aging until the date is fixed.

The CSV parser accepts a header row when one exists and otherwise falls back to column order. Common header aliases cover scanner and ticket exports, including IDs or CVEs, severity or CVSS score, detected or first-seen dates, fixed or resolved dates, status, fix or patch availability, owner, asset, exploited flags, and extension days.

Record concept Common headers Effect on calculation
Finding ID id, cve, finding_id Labels the ledger, queue, JSON, and copied rows.
Severity severity, risk, priority, cvss_score Selects the critical, high, medium, low, or low-window unknown SLA days.
Detected date detected, first_detected, first_seen, created Can start the SLA clock and is required for aging.
Fix availability fix_available, patch_available, vendor_fix, published Can start or delay the SLA clock when the selected clock basis uses vendor fix availability.
Closure evidence fixed, resolved, closed_date, remediated Determines closed-in-SLA, closed-late, or closure-date-missing status.
Exploit flag exploited, kev, active_exploit, internet_exposed Applies the known exploited cap when the cap is enabled.
Exception days extension_days, exception_days, waiver_days Adds approved days after the base severity or exploited cap decision.

The priority queue sorts open findings by pressure: severity weight, exploited flag, overdue days, due-soon status, and at-risk status. That sort is a triage aid. It does not certify exploitability, asset reachability, compensating controls, or whether a waiver is valid.

Everyday Use & Decision Guide:

Start with Reference date set to the day of the review. For an active dashboard, that is usually today's reporting date. For an audit packet, use the date the evidence snapshot was taken so days remaining and days past SLA match the exported records.

Choose SLA policy preset as a starting point, then edit the critical, high, medium, and low day fields if your team's policy differs. The security operations baseline uses 7, 30, 90, and 180 days. The accelerated internet-facing patch profile shortens high, medium, and low windows to 14, 30, and 90 days. The product and monthly high-risk profiles use 30, 30, 90, and 180 days.

Set SLA clock starts before judging any dates. First detected date is strict and simple. Fix availability date when present is useful when ownership begins after a vendor patch is available. Later of detected or fix availability protects rows where discovery happened before a fix existed, as long as the CSV actually includes fix-availability dates.

  • Use Known exploited cap for actively exploited or KEV-style queues. Set it to 0 only when the policy should not shorten flagged rows.
  • Paste scanner or ticket rows into Vulnerability records CSV. A header row is safest because it prevents column-order mistakes.
  • Use Due-soon buffer for watch-list timing. The default 7 days marks rows due within a week without changing the due date.
  • Use At-risk progress threshold to surface rows that have consumed most of their SLA window but are not due soon yet.
  • Use Default extension only when an approved exception applies to rows that do not carry their own extension days.
  • Use Priority queue rows to limit the visible queue from 5 to 250 rows while keeping the complete normalized record set in JSON.

The first output to read is the summary box. breach active means at least one open row is overdue. watch queue means due-soon, at-risk, closed-late, or warning conditions deserve review. SLA clear means the current valid records have no active breach signal under the selected settings, not that the environment has no unresolved vulnerability risk.

Use SLA Compliance Snapshot for the management view, Vulnerability SLA Ledger for row-level evidence, Remediation Priority Queue for owner follow-up, and SLA Guidance Brief for the short handoff. The charts are most useful after the tables look coherent because they summarize the same normalized records by severity and deadline pressure.

Step-by-Step Guide:

Work from policy settings to source rows, then read warnings before trusting the queue.

  1. Set Reference date and, when helpful, System or queue label. SLA Compliance Snapshot should later show the same label and reference date.
  2. Pick SLA policy preset. If you change Critical remediation SLA, High remediation SLA, Medium remediation SLA, or Low remediation SLA, the policy becomes custom and the Policy thresholds row should reflect the edited days.
  3. Choose SLA clock starts. If the output should wait for vendor patch availability, make sure the CSV includes a fix-availability or patch-availability column.
  4. Set Known exploited cap. A value above zero shortens exploited, active, or KEV-marked rows when the cap is shorter than the severity window.
  5. Paste rows into Vulnerability records CSV, browse for a CSV or TXT source, or load the sample queue. The source status should show the row count and character count.
  6. Open Advanced only when the defaults need adjustment. Set Due-soon buffer, At-risk progress threshold, Default extension, and Priority queue rows to match the review.
  7. Check the warning panel. If it reports invalid detected dates, unknown severity, or closed rows without closure dates, fix the source rows before using the result as compliance evidence.
  8. Read SLA Compliance Snapshot, then inspect Vulnerability SLA Ledger and Remediation Priority Queue. The queue should list the highest-pressure open findings first.
  9. Use SLA Status by Severity and Remediation Deadline Timeline after the tables make sense. If a chart has no data, confirm that valid rows were parsed and the selected tab has records to plot.

A clean finish is a summary state that matches policy, a ledger with explainable start and due dates, and a queue whose first rows can be assigned to real owners.

Interpreting Results:

Read Open SLA breaches before SLA health. One open overdue critical finding can be more urgent than a high compliance percentage. SLA health is calculated across valid records after subtracting active open breaches, closed-late rows, and closed rows that lack closure dates.

  • Open in SLA means the row is still before its due date and has not crossed the due-soon or at-risk thresholds.
  • At risk means the configured percentage of the SLA window has elapsed, but the due-soon buffer has not been reached.
  • Due soon means days remaining is from 0 through the configured due-soon buffer.
  • Overdue means days remaining is less than 0; Days past SLA is the overdue amount.
  • Closed late means the fixed date is after the calculated due date, even though the finding is no longer open.
  • Closed date missing means closure timeliness cannot be audited until a fixed or resolved date is added.

Mean open age uses the selected clock basis, not necessarily the first detected date. Changing from detected-date aging to fix-availability aging can reduce age and move due dates when fix availability is later than discovery. Compare runs only when the clock basis, reference date, severity windows, exploited cap, and exception-day policy are the same.

Do not treat SLA clear as proof that vulnerabilities are harmless. It means the current rows fit the selected SLA math. Verify scanner evidence, patch status, production exposure, owner acceptance, and exception approvals before closing a remediation review.

Worked Examples:

Exploited critical finding is already overdue

A production API row is marked critical and exploited. It was detected 15 days before the reference date, and a fix was available 14 days before the reference date. With SLA clock starts set to Later of detected or fix availability, the start is the fix-availability date. Under the security operations baseline, the critical window is 7 days, and the 14-day exploited cap does not extend it. Vulnerability SLA Ledger shows a due date 7 days after fix availability, SLA state is Overdue, and Remediation Priority Queue should put the row near the top.

High finding lands exactly in the watch queue

A high-severity edge proxy finding has a fix available 23 days before the reference date. The high SLA is 30 days and Due-soon buffer is 7 days. The due date is 7 days after the reference date, so SLA state becomes Due soon rather than Open in SLA. That boundary is useful for weekly patch planning because the row is not late yet, but it should not wait behind lower-pressure backlog work.

Exception days change the due date but not the base policy

A medium finding was first detected 125 days before the reference date and has a row-level extension_days value of 14. With the security operations baseline, the medium window is 90 days, so the effective SLA is 104 days. If the finding is still open, Vulnerability SLA Ledger shows it as Overdue by about 21 days, and Policy thresholds still reports the base 90-day medium policy.

Closed record cannot prove timeliness

A scanner export marks a row as resolved but leaves the fixed or resolved date blank. The row is treated as closed, but SLA state becomes Closed date missing, and SLA health is reduced because closure timeliness cannot be audited. Add the closure date from the ticket system, then recheck the ledger before using the row in evidence.

CSV dates need cleanup before review

A pasted backlog uses mixed date formats and one row has detected as TBD. The warning panel reports an invalid detected date and excludes that row from SLA aging. Replace the value with a usable date such as 2026-05-01, then confirm Records parsed, valid record(s), and the row's SLA start in the ledger.

FAQ:

Which CSV columns do I need?

Use a header row with id, severity, detected, fixed, status, fix_available, owner, asset, exploited, and extension_days when possible. The parser also accepts common aliases, but a clear header row reduces column-order mistakes.

Why did an exploited row not use the cap?

The cap applies only when the row has an exploited, active, KEV, or known-exploited style flag and Known exploited cap is greater than 0. It also only shortens the severity window; it does not make a longer cap override a shorter critical or high SLA.

Why did the same row move from overdue to in SLA?

Check SLA clock starts. Switching from first detected date to fix availability can move the SLA start later when a patch date exists, which moves the due date and changes days remaining.

What does SLA health actually count?

SLA health counts valid records that are not open overdue, not closed late, and not closed without a closure date. Invalid detected-date rows are reported separately and should be fixed before the percentage is used as evidence.

What should I do when warning messages appear?

Fix the source rows first. Invalid detected dates block SLA aging, unknown severity uses the low window, and closed rows without fixed dates cannot prove closure timeliness.

Is the pasted CSV sent to a server for calculation?

No server-side parser is used for the calculation. Pasted text and selected CSV or TXT sources are parsed in the browser, though normal site assets still load as part of the page.

Glossary:

SLA
A service level agreement that defines how many calendar days a finding may remain unresolved under the selected policy.
Reference date
The reporting date used to age open findings and compute days remaining or days past SLA.
Clock basis
The rule that chooses whether SLA age starts at detection, fix availability, or the later of those two dates.
Known exploited cap
A shortened maximum window for rows flagged as exploited, active, KEV, or known exploited.
Exception days
Approved extension days added after the base severity window or exploited cap is chosen.
SLA health
The valid-record percentage without an active open breach, closed-late row, or missing closure date.

References: