Question 1

What is a vulnerability remediation SLA?

Accepted Answer

A vulnerability remediation SLA is the agreed maximum time between a finding being reported and that finding being verified closed. It is set per severity (critical, high, medium, low, informational) so the most dangerous findings get the shortest fix windows. The SLA is the lever that turns a finding list into a programme: without a target close date, severity becomes a label rather than a deadline. The calculator on this page gives you defensible default windows you can adapt to your release cadence and risk tolerance.

Question 2

What are sensible default SLA windows by severity?

Accepted Answer

A common starting ladder is critical within 7 days, high within 30 days, medium within 90 days, low within 180 days, and informational on best-effort. Mature programmes often tighten critical to 24 to 72 hours when the asset is internet-facing or carries regulated data. PCI DSS expects critical and high to be remediated and rescanned in line with the requirement, and most internal-audit cycles want a documented SLA per severity tied to evidence of closure. The calculator lets you start from those defaults and adjust by industry or asset exposure.

Question 3

How does CVSS score map to SLA window?

Accepted Answer

CVSS base score is converted to a severity rating using the CVSS qualitative bands: 9.0 to 10.0 is critical, 7.0 to 8.9 is high, 4.0 to 6.9 is medium, 0.1 to 3.9 is low, and 0 is informational. The SLA window is then set per band, which is why a calculator that produces both a severity rating and an SLA target is useful at triage time. The page references the bands defined in the CVSS 3.1 specification and reflects the same severity levels SecPortal applies in findings management.

Question 4

How should asset exposure adjust the SLA?

Accepted Answer

Internet-exposed assets carry shorter SLAs than internal assets at the same severity, because exploitability is higher and exposure window matters more. A common adjustment is to halve the critical and high windows for public-facing systems (so critical moves from 7 days to 3, high from 30 to 14). The calculator includes an exposure modifier so you can produce both a baseline SLA and a tightened SLA for internet-facing assets without rebuilding the model from scratch.

Question 5

Should compliance frameworks drive SLA windows?

Accepted Answer

Yes, where a framework specifies a target. PCI DSS expects timely remediation of critical and high findings tied to scoped assets and rescanning to confirm closure. ISO 27001 expects a documented vulnerability management process with prioritisation and treatment timelines, but does not prescribe specific days. SOC 2 expects evidence that severity-driven remediation actually happens. NIST SP 800-40r4 and CISA KEV recommend prioritising actively exploited vulnerabilities ahead of CVSS-only ranking. The calculator surfaces the framework signal so the SLA window is defensible during audit.

Question 6

What is the difference between an SLA and an SLO for vulnerabilities?

Accepted Answer

An SLA is the contractual or policy-defined maximum window. Missing it is an audit and risk event. An SLO is the internal operational target the team plans against, usually tighter than the SLA so there is buffer when something slips. A mature programme reports both: SLA performance to leadership and audit, SLO performance to the engineering teams owning the fix. The calculator returns SLA targets; teams adopting it should set their internal SLOs slightly tighter so the SLA is rarely tested.

Question 7

How do retests fit into the SLA?

Accepted Answer

The SLA clock should run from finding open to finding verified closed (after retest), not just to fix-deployed. A finding that is fixed but never retested is not closed. Pair every retest to the original finding so the verification record sits next to the original scope, evidence, and remediation guidance. If the retest fails, the SLA clock resumes rather than restarts, so the original deadline still applies and the team can see how far overdue the closure is.

Question 8

What happens when a finding cannot be fixed inside the SLA?

Accepted Answer

It becomes a documented exception. The exception captures the reason the SLA cannot be met, the compensating controls in place, the residual risk accepted, the review cadence, and the formal sign-off. Exceptions are not failures, they are the way a programme handles legitimate delivery constraints (vendor patch unavailable, breaking change required, end-of-life roadmap). What is a failure is silent slippage: a finding past the SLA with no exception, no owner, and no escalation path. Track exceptions on the same record as the finding so the audit trail stays intact.

Question 9

How does SecPortal track SLAs against findings?

Accepted Answer

SecPortal stores SLA targets per severity at the workspace level and applies them to every finding at logging time. The finding record carries the open timestamp, the SLA deadline, the remediation owner, the close timestamp, and the SLA performance result (met, exceeded, exception). Overdue findings surface in dashboard views and weekly digests so escalation happens before the next steering meeting, not after it. The calculator on this page is the policy layer that feeds those workspace SLA settings.

Severity	CVSS band	SLA window	SLO target	SLA deadline	SLO deadline
Critical	CVSS 9.0 to 10.0	7 days	6 days	2026-05-17	2026-05-16
High	CVSS 7.0 to 8.9	30 days	24 days	2026-06-09	2026-06-03
Medium	CVSS 4.0 to 6.9	90 days	72 days	2026-08-08	2026-07-21
Low	CVSS 0.1 to 3.9	180 days	144 days	2026-11-06	2026-10-01
Informational	CVSS 0	365 days	292 days	2027-05-10	2027-02-26

Severity	CVSS band	SLA window	SLO target	SLA deadline	SLO deadline
Critical	CVSS 9.0 to 10.0	7 days	6 days	2026-05-17	2026-05-16
High	CVSS 7.0 to 8.9	30 days	24 days	2026-06-09	2026-06-03
Medium	CVSS 4.0 to 6.9	90 days	72 days	2026-08-08	2026-07-21
Low	CVSS 0.1 to 3.9	180 days	144 days	2026-11-06	2026-10-01
Informational	CVSS 0	365 days	292 days	2027-05-10	2027-02-26

Vulnerability Remediation SLA Calculator
severity-driven fix windows that survive an audit

1. Programme profile

2. Asset exposure and SLO buffer

SLA windows by severity

How to operationalise the SLA

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Your brand. Your portal. Your clients love it.

Remediation tracking

Pentest retesting

Cybersecurity risk assessment

Run these SLAs against real findings

1. Programme profile

2. Asset exposure and SLO buffer

SLA windows by severity

How to operationalise the SLA

Vulnerability Remediation SLA Calculatorseverity-driven fix windows that survive an audit

1. Programme profile

2. Asset exposure and SLO buffer

SLA windows by severity

How to operationalise the SLA

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Your brand. Your portal. Your clients love it.

Remediation tracking

Pentest retesting

Cybersecurity risk assessment

Run these SLAs against real findings

1. Programme profile

2. Asset exposure and SLO buffer

SLA windows by severity

How to operationalise the SLA

Vulnerability Remediation SLA Calculator
severity-driven fix windows that survive an audit