Vulnerability Remediation SLA Calculator

Introduction:

A remediation deadline is only defensible when the policy, clock start, source dates, and approved exceptions are visible together. A severity label alone cannot answer when a finding became actionable, whether a repair existed, or whether the asset owner completed the work on time.

A vulnerability remediation service level agreement (SLA) converts an organization's policy into calendar-day due dates. It separates open findings that remain within their window from items that are due soon, have consumed most of their time, or are already overdue. Closed findings also need a fixed date so the report can distinguish an on-time repair from a late one.

The clock rule changes the meaning of every date. Starting at first detection holds the owner to the discovery timeline. Starting at fix availability can be useful when remediation cannot begin before a vendor patch or internal repair exists. Choosing the later of detection and fix availability waits for both conditions. None of those policies is universal; the approved agreement and system of record decide which one is valid.

• Severity window supplies the normal number of calendar days for critical, high, medium, or low findings.
• Known exploitation can shorten that window when the source row is already marked exploited or KEV.
• Extension days lengthen the effective window and should correspond to an approved exception.
• Reference date freezes the open backlog at one reporting cutoff, making repeated reports comparable.

CVSS communicates technical severity, not complete organizational risk. Asset exposure, business criticality, compensating controls, exploit evidence, patch availability, and operational impact can change remediation priority. CISA's Known Exploited Vulnerabilities catalog is also a living source with its own due dates; a locally supplied exploited flag is not proof that a row currently appears in that catalog.

Deadline arithmetic cannot prove remediation. Scanner evidence, deployment records, validation scans, change tickets, exception approvals, and owner confirmation remain necessary. A clean percentage built from missing or stale dates can be more misleading than an explicit warning.

The day presets in this model are configurable examples, not official NIST, FIRST, CISA, or industry-wide SLAs. Confirm every window and clock rule against the policy that governs the backlog.

How to Use This Tool:

Use a reporting snapshot from the scanner or ticket system, then make the policy that governs its dates explicit.

1. Paste Vulnerability records CSV, browse to a CSV or text file, or load the sample. A header is optional; common aliases are accepted for finding ID, severity, CVSS score, detection, closure, fix availability, owner, asset, exploitation, and extension days.
2. Set Reference date to the reporting cutoff. Open age, days remaining, and breach state are calculated against this date.
3. Choose SLA policy preset, then verify the critical, high, medium, and low day windows. Editing a window changes the selection to Custom policy.
4. Choose when SLA clock starts. Fix-availability mode falls back to detection when a row has no usable fix date; the later-date mode selects the later of the two when both exist.
5. Set Known exploited cap only when rows already marked exploited or KEV should use a shorter maximum window. Zero disables the cap; no catalog lookup is performed.
6. Set the Due-soon buffer and At-risk threshold. These change watch classification, not the due date.
7. Use Default extension only for an approved queue-wide exception when a row leaves its extension blank. A row-specific value takes precedence.
8. Resolve data warnings before sharing the result. Invalid detected dates or extension values exclude rows; unknown severity uses the low-severity window; a closed row without a fixed date cannot establish timeliness.
9. Review overdue, due-soon, critical/high, and evidence-quality signals against the priority-sorted ledger. Confirm owners and source records before escalating or reporting compliance.

Interpreting Results:

An open row is Overdue only after the reference date passes its due date. A row exactly on its due date has zero days remaining and enters Due soon, even when the due-soon buffer is zero. The at-risk percentage is considered only after the overdue and due-soon checks.

Compliance is the share of valid rows that are not open overdue, closed late, or closed without a usable fixed date. It is a result of this supplied dataset and policy, not proof of control effectiveness. The due-soon count includes both calendar-buffer and percentage-consumed watch rows.

The ledger is sorted by a planning priority score that favors severity, known exploitation, breach state, and days past due. Use that order for triage, then confirm asset exposure and business impact rather than treating the score as a risk standard.

Technical Details:

Each eligible record receives one clock start, one severity window, an optional exploited cap, and extension days. Dates use UTC calendar-day arithmetic rather than elapsed hours, so daylight-saving changes do not alter the difference between two date strings.

Formula Core:

The cap is applied before the extension. A marked exploited row uses the smaller of its severity window and the configured cap when the cap is greater than zero.

Rule Core:

Classification follows the first matching condition, so later watch rules never override closure or breach evidence.

Severity text recognizes critical, high, medium or moderate, low, and P0 through P4 labels. A numeric CVSS-style value maps 9.0 to 10.0 to Critical, 7.0 to below 9.0 to High, 4.0 to below 7.0 to Medium, and above 0 to below 4.0 to Low. Anything else is Unknown and uses the low-severity window with a warning.

Up to 250 non-comment records are parsed. Rows need a valid detected date and an extension that is blank or a whole number no greater than 3,650. A fixed date closes a row; status text also recognizes fixed, resolved, closed, remediated, mitigated, risk accepted, false positive, waived, and deferred as closed states. Without a fixed date, those status-only closures cannot establish timeliness.

The visible ledger limit, from 5 to 250 rows, does not change summary or chart calculations.

Priority score adds severity points, 45 points for an exploited flag, 60 plus twice days past due for an overdue row, or 22 points for a watch row. It controls sorting only. It does not change due dates, compliance, or state.

Privacy and Scope Notes:

CSV text and imported files are parsed in the browser. No scanner or live CISA catalog is queried. Exports can still contain finding IDs, asset names, owners, dates, and vulnerability status.

• Remove or replace sensitive asset and owner data before sharing an export.
• Verify exploited flags, patch availability, closure dates, and exception approvals in their systems of record.
• Do not present preset day windows as a legal, contractual, or regulatory requirement without an approved policy source.

Worked Examples:

References:

• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning, National Institute of Standards and Technology, April 2022.
• CVSS v3.1 Specification Document, Forum of Incident Response and Security Teams.
• BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, Cybersecurity and Infrastructure Security Agency, 3 November 2021.