Vulnerability Remediation SLA Calculator

A vulnerability backlog is easier to manage when every open finding has a due date that can be defended. Severity tells part of the story, but remediation work also depends on when the clock starts, whether a fix exists, whether exploitation is known, who owns the asset, and whether an approved exception extends the deadline.

A remediation service level agreement (SLA) turns those policy choices into calendar commitments. It gives security teams a consistent way to ask which findings are still within target, which ones need owner attention soon, which ones have already breached, and which closed items missed their deadline. That is different from a risk score: the SLA measures repair timeliness under a chosen policy, not the full business impact of the vulnerability.

Teams often misread SLA reports when they collapse all findings into one overdue count. A due-soon critical item may deserve more attention than a stale low finding, and an exploited medium finding may need a shorter deadline than its severity normally implies. The calendar view should support triage, not replace ownership, exposure review, or patch validation.

Remediation SLA reporting is also limited by source quality. It can expose deadline pressure and closure timeliness, but it cannot prove that a patch deployed correctly, that the vulnerability is exploitable on a specific asset, or that an accepted-risk decision is appropriate.

How to Use This Tool:

Paste vulnerability records as CSV, import a CSV or TXT file, or load the sample queue to inspect the expected structure. Header rows are supported, and common aliases are accepted for finding ID, CVE, severity, CVSS score, detected date, fixed date, status, fix availability, owner, asset, exploited or KEV flag, and extension days.

1. Set Reference date to the reporting cutoff used for this review. Open findings use that date for days remaining, days past due, and progress percentage.
2. Choose SLA policy preset, then adjust the critical, high, medium, and low remediation windows if your agreement uses different day counts.
   Editing a severity window switches the policy to custom without changing the date rules.
3. Choose SLA clock starts. Use detection when ownership begins at discovery, fix availability when teams cannot act before a vendor or internal repair exists, or the later date when both signals must be respected.
4. Paste or import Vulnerability records CSV. Keep owner, asset, status, fixed date, fix availability, exploited flag, and extension columns when they exist because they affect the ledger and priority queue.
5. Set Known exploited cap only when rows marked exploited, active, KEV, or known exploited should use a shorter maximum window than severity normally allows.
6. Open Advanced to tune the due-soon buffer, at-risk progress threshold, default extension days, and priority queue length.
7. Resolve the Review SLA inputs warnings before using the report. Invalid detected dates exclude rows from SLA aging, unknown severity uses the low-severity window, and closed rows without fixed dates cannot prove closure timeliness.
   The compliance percentage is not audit evidence until scanner exports, ticket history, closure dates, and exception approvals still support the rows.
8. Review SLA Compliance Snapshot, Vulnerability SLA Ledger, Remediation Priority Queue, and the charts. A result is ready to share when overdue rows, due-soon rows, warnings, and owner assignments match the source queue.

Interpreting Results:

Read the summary as a point-in-time backlog health view for the selected reference date. It may show an active breach queue, a watch queue, or an SLA health percentage. The health percentage uses valid records and is reduced by open breaches, closed-late findings, and closed findings with missing closure dates.

The ledger is the best audit trail because it keeps each valid finding with its start date, due date, age, status, and action text. The priority queue is better for daily triage because it lifts exploited rows, overdue rows, due-soon rows, at-risk rows, and higher severities above lower-pressure backlog work.

A favorable percentage does not mean the program has no remaining risk. Verify exploited flags, asset exposure, exception approvals, and closure evidence in the vulnerability-management system before using the results for compliance or executive reporting.

Technical Details:

Remediation SLA math is calendar-day arithmetic applied after classification. Each valid finding needs a severity bucket, an SLA start date, a base repair window, any exploitation cap, and any extension days. Open findings compare the due date with the reference date. Closed findings compare the fixed date with the due date.

Severity normalization accepts text labels and numeric scores. Critical, high, medium, moderate, low, and P0 through P4 map to the four severity buckets. Numeric scores follow common CVSS v3.1 qualitative bands: 9.0 and above is critical, 7.0 to 8.9 is high, 4.0 to 6.9 is medium, and positive scores below 4.0 are low. Unknown severity remains visible and uses the low-severity window for date math.

Formula Core:

Clock-basis selection changes the start date before any window is applied. A detection clock uses the first detected date when available. A fix-availability clock uses the fix available date when present, falling back to detected date when it is missing. The later-date clock compares the detected and fix available dates and starts from whichever is later.

The priority score is a sorting aid. It starts from severity weight, then adds pressure for exploited rows, open overdue rows, due-soon rows, and at-risk rows. Overdue days increase the score further, so an old breach rises above a newer breach with otherwise similar severity. This queue order is useful for triage, but it is not a replacement for asset exposure, compensating controls, or business owner review.

For example, a critical finding that starts on May 1 under a 7-day policy is due on May 8. If it is still open on May 10, days remaining is -2 and the finding is overdue by two calendar days. If it closed on May 7, it is closed in SLA; if it closed on May 9, it is closed late.

Privacy and Scope Notes:

The pasted or imported CSV is parsed locally in your browser. Vulnerability IDs, asset names, owner names, queue labels, and exported reports can reveal sensitive operational data, especially for internet-facing systems, unpatched services, and internal ownership paths.

The calculator does not query a scanner, confirm that a CVE affects a live asset, verify patch deployment, or check the current CISA KEV catalog. Use the output for planning and reporting, then confirm exploit status, exposure, compensating controls, exceptions, and closure evidence in the systems that own those records.

Advanced Tips:

• Keep Reference date aligned with the scanner export, ticket extract, or evidence-pack cutoff so days remaining match the report period.
• Use Known exploited cap as a policy override, not as a lookup. Rows must already identify exploited, active, KEV, or known exploited status correctly.
• Choose a fix-availability clock only when the CSV reliably includes vendor fix, patch available, or internal remediation dates.
• Use row-level extension days for approved exceptions and reserve Default extension for a whole queue covered by the same waiver.
• Tune Due-soon buffer and At-risk progress threshold to your review cadence. A weekly review usually needs a larger buffer than a daily triage meeting.
• Raise Priority queue rows high enough to show all active breaches during triage, then use the full ledger or JSON for complete reporting.
• Compare Remediation Deadline Timeline with release freezes and maintenance windows before escalating a deadline that cannot be met through normal deployment paths.

Worked Examples:

FAQ:

Glossary:

SLA

A service level agreement that defines how many calendar days a finding may remain unresolved under the selected remediation policy.

Reference date

The reporting cutoff date used to age open findings and calculate days remaining or days past due.

Clock basis

The rule that chooses whether SLA aging starts at detection, fix availability, or the later of those two dates.

Known exploited cap

A shortened maximum repair window for rows flagged as exploited, active, KEV, CISA, 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 finding, or closed row missing closure timing.

References:

• SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, National Institute of Standards and Technology, April 2022.
• CVSS v3.1 Specification Document, FIRST.
• CVSS v3.1 User Guide, FIRST.
• Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, Cybersecurity and Infrastructure Security Agency, November 3, 2021.
• Known Exploited Vulnerabilities Catalog, Cybersecurity and Infrastructure Security Agency.