CA Vulnerability SLA Policy

The Vulnerability SLA policy defines, by severity, how many days a vulnerability is allowed to remain open before it breaches the organisation's service-level agreement.

The platform uses this policy to compute remediation deadlines, surface overdue vulnerabilities, and feed SLA dashboards.

Anchor

• SLA anchor — the date used as day 0 when computing the deadline. Two options:

  • detected_at — the date the vulnerability was first recorded in CISO Assistant (default).

  • published_date — the date the vulnerability was publicly disclosed (relevant when working from CVE feeds).

The choice matters: published_date tightens deadlines for vulnerabilities that were known publicly before you imported them; detected_at gives a fresh clock starting from import.

Deadlines by severity

For each severity level, set the number of days allowed to remediate. Leave a field empty (null) to mean no policy at this severity.

• Critical — typically the tightest (e.g. 7-14 days).

• High — typically 30 days.

• Medium — typically 60-90 days.

• Low — typically 180+ days, or unset.

• Info — usually unset; informational entries aren't on a clock.

Behaviour

• Vulnerabilities whose anchor_date + deadline_days is in the past are flagged as SLA breached.

• Severity is read from the vulnerability record itself; the policy is a lookup, not a per-vulnerability field.

• Changes to the policy apply going forward and retroactively recompute the breach status of existing vulnerabilities.