Skip to main content

Remediation SLA policy

This is where you set how long a finding has before it is overdue.

Remediation and SLAs explains the model. This page is about configuring it.

The structure​

One policy per organization, containing an ordered list of rules. A business unit can carry an override - its own ordered list, used instead of the organization's.

The policy as a whole can be enabled or disabled. Disabled means no due dates are computed at all.

Writing a rule​

A rule is conditions plus a target:

ConditionMatches on
SeverityCritical, High, Medium, Low, Informational
ExploitableA known exploit exists
Internet facingThe affected asset is reachable from outside
CategoryThe kind of finding

Target hours is how long from discovery until the finding is due.

A rule may use any combination, including none - a rule with no conditions matches everything, which is how you set a catch-all.

Order matters, and this is where it goes wrong​

Rules are evaluated in priority order and the first match wins. Later rules are not consulted.

Put specific rules first and general rules last:

1. Critical + exploitable + internet-facing   →  24 hours
2. Critical                                   →  7 days
3. High + internet-facing                     →  7 days
4. High                                       →  30 days
5. Medium                                     →  90 days
6. (no conditions)                            →  180 days

Reverse rules 1 and 2 and rule 1 never fires again. Every Critical matches the plain Critical rule first, so the 24-hour rule becomes unreachable.

There is no warning for a shadowed rule

Nothing flags a rule that can never match. It simply stops applying, and the first sign is usually that an urgent class of finding quietly has a relaxed deadline.

After editing the order, check a finding you expect to match the specific rule and confirm which rule name it reports.

Each finding records the rule that set its deadline, which is what makes that check possible.

Changing a policy re-dates existing findings​

Due dates are computed when a finding is read, not stored when it is created. So editing a rule re-evaluates every open finding immediately.

Tighten a Critical deadline from 7 days to 24 hours and everything already open is re-dated against the new rule. Findings can become overdue the moment you save.

That is usually correct - a policy should describe your current standard, not the one in force when each finding happened to be found - but it means rule changes are worth making deliberately rather than experimenting on a live policy.

Business unit overrides​

An override replaces the organization's rules for that unit, rather than adding to them. A unit with an override needs a complete list, including its own catch-all.

Use one where an obligation genuinely differs - a regulated product line, a client contract. Do not use one to give a struggling team more time; that hides the problem rather than showing it.

Setting targets you will meet​

A policy nobody meets is worse than none. It trains people to ignore the overdue count, and then the metric means nothing.

Start from what your team sustains today and tighten deliberately. Two deadlines you hit are worth more than five you do not.

Accepted risks still count

Risk Acceptance Approved is an open status, and due dates ignore status entirely. An accepted finding keeps its deadline and keeps accruing overdue days.

If your overdue count exceeds the work you think is outstanding, accepted risks are the usual reason. See Findings, severity, and risk.

API​

The endpoints behind this section are in the API reference.

Next​

Last updated on