SecOps

Remediation deadlines and SLAs

In SecOps, an SLA is the time your organisation allows to fix a finding of a given severity. This guide explains how the deadline is calculated and how to interpret Due in and Breached.

What does SLA mean here?

SLA stands for service level agreement. In this app it names your internal remediation deadline, rather than a contractual availability guarantee or a legal patching requirement. A standard or contract may impose different obligations; changing the app's setting does not change those obligations.

The default time to fix

SeverityDefault allowance from discovery
Critical30 days
High90 days
Medium180 days
Low365 days
InfoNo SLA

These are app defaults, not recommended waiting periods. An exposed or actively exploited issue can need action much sooner. Admins can set each dated severity to between 1 and 3,650 days in Settings → Time to fix, by severity.

When does the clock start?

Normally it starts when the source first discovered the finding. Importing an old finding does not give it a fresh allowance just because SecOps saw it today.

For example, a critical finding discovered 40 days ago with a 30-day allowance is about ten days past its deadline. Check the discovery date when an imported backlog immediately shows breaches.

Due in 0 d means due today. It becomes breached when the computed days left is negative. Info findings have no deadline, so No SLA is different from being overdue.

Changes and exceptions

Changing a severity's allowance affects the derived findings after the next model run. Review the draft before applying: a shorter deadline can make existing findings overdue, and a longer one can remove a breach without fixing the issue.

An active risk-acceptance or false-positive exception temporarily changes whether the finding counts as open. After its recheck date passes, a finding still reported open by the source reopens with the deadline restarted from that date. See Exceptions for the exact boundaries.

What to do with a breach

Open the finding, confirm the affected target and owner, and decide how to reduce the risk. Use fix groups to avoid creating separate work for issues one change can address.

A deadline measures timeliness of response. It does not measure whether exploitation occurred, and meeting it does not prove the target is secure.

Learn more