Skip to main content

SLA Tracking

SLA tracking measures how quickly vulnerabilities are remediated relative to agreed timelines, usually based on risk bands, asset criticality, and regulatory scope.

Use this guide to understand how vulnerability SLAs are defined, tracked, and reported in Cloudaware, including how exceptions affect SLA status and reporting.

SLA Model​

Typical SLA parameters:

  • Risk band (Critical/High/Medium/Low).
  • Environment (production vs non‑production).
  • Regulatory scope, e.g., PCI, HIPAA, etc.

For each combination, define:

  • Target remediation time (e.g., Critical in prod PCI systems fixed within 7 days).
  • Grace periods or warning thresholds for escalation.

These rules drive:

  • Due dates on Remediation Tasks.
  • Dashboard metrics such as “% of Critical vulnerabilities within SLA.“

See Severity & Scoring and Risk Models for how risk bands are calculated.

Tracking and Reporting​

Cloudaware can track:

  • How long a vulnerability has been open on a given asset.
  • Whether a related task is ahead of or behind schedule.
  • Age and SLA status rolled up by OU, application, or platform team.

Recommended reports and dashboards:

  • SLAs by OU, environment, and risk band.
  • Top overdue vulnerabilities and tasks.
  • Trends in mean-time-to-remediate (MTTR) per severity.

See also: Vulnerability Scans with SLAs dashboard

Interaction with Exceptions​

Exceptions modify SLA behavior:

  • Findings under an active exception are typically excluded from “breach” counts.
  • However, you may still want to track:
    • Number of exceptions per OU or application.
    • Total risk deferred via exceptions.

Use dedicated exception dashboards and escalation reports to ensure that risk acceptance remains a conscious, reviewed decision rather than a silent backlog reducer.