# SLAs and exceptions

> Due dates for vulnerabilities by severity, known exploitation and EPSS; breach alerts; and risk acceptance, false positive and not affected exceptions with an approver and an expiry.

## SLA policies

Every open finding gets a due date from the first policy that matches it. Until you change them, the policies are:

| Policy                         | Fix within |
| ------------------------------ | ---------- |
| Known exploited (CISA catalog) | 7 days     |
| Critical                       | 15 days    |
| High                           | 30 days    |
| Medium                         | 90 days    |
| Low                            | 180 days   |

Edit them under **Vulnerabilities → Settings → SLA → Edit rules**. A rule can match severities, known exploitation, an exploit likelihood (off, or the top 10% or top 1% most likely to be exploited, by EPSS percentile), the criticality of the owning service, and the finding's source (dependency, license, secret, code). Policies are checked in order, so put the most specific first. Changing policies updates the due dates of open findings: dependency and license findings at once, code findings (secrets, code patterns, configuration, AI) within the hour, when new code findings get theirs too.

When a finding later matches a stricter policy, for example its vulnerability is added to CISA's known exploited catalog, its due date moves earlier: the stricter policy's days count from that moment. The finding's timeline shows the change. A due date never moves later on its own; only changing the policies can do that.

When a finding passes its due date it is marked **SLA breached** and the **SLA breached** notification fires. **Vulnerabilities → Settings → SLA** shows breached and due-soon findings by team, business unit, service or repository, and how many fixes landed within their SLA over the last 90 days.

## Exceptions

Some findings should be closed without a fix. Request an exception from the finding (or for an advisory across a repository, a service or the whole organization):

- **Risk accepted**: needs a reason and an expiry date, at most 180 days ahead by default. When it expires, the findings reopen.
- **False positive**: the finding is wrong.
- **Not affected**: the package is present but the vulnerability does not apply. Choose the reason: the component is not present, the vulnerable code is not present, the vulnerable code is not in the execution path, the vulnerable code cannot be controlled by an attacker, or mitigations already exist. These reasons appear in [VEX](https://mergeharbor.com/docs/vex) exports.

Exceptions wait for approval. Members who can manage security settings approve or reject them, and you can name extra approvers and the longest acceptance in **Vulnerabilities → Settings → Exceptions**. Requests and active exceptions are under **Vulnerabilities → Findings → Exceptions** (code findings: **Security → Findings → Exceptions**). Nobody approves their own request. Approved exceptions can be revoked, which reopens the findings. Requests, decisions and revocations are in each finding's timeline and in the audit log.