This guide explains how to configure and use SLA Overrides within the Phoenix Security platform to manage remediation deadlines flexibly and avoid backlog friction.

1. Introduction

The SLA Override is a core workflow capability in the Phoenix Security platform. It is designed to “reset the clock” when a finding’s risk level or severity changes (e.g. recasting a vulnerability to Critical), preventing operational and political friction with engineering teams over sudden SLA breaches.

1.1 What it does

Normally, a vulnerability’s SLA begins counting down from its original “First Seen” (discovery) date. If a security team escalates a finding’s severity retroactively, measuring against the historical discovery date could instantly push the finding into a breached status.

The SLA Reset function starts the countdown from day 0 at the exact timestamp of exception approval, giving engineers a fair, agreed-upon remediation window.

1.1.1 SLA Reset vs SLA Addition

• Reset Findings SLA: Forces the SLA countdown to start from day 0 at the timestamp of exception approval.
• SLA Addition: Appends a specified number of extra target days to the existing SLA countdown rather than doing a full reset.
• Simulating Pauses: Phoenix does not support pausing SLAs directly. To simulate a pause, add an explicit number of extra days (e.g. adding 30 days acts as a 1-month pause).

2. Requirements & Constraints

• Role-Based Approvals: Only Security Team members or Administrators can approve exceptions that override or reset SLAs. Engineering users can only suggest or propose them.
• Expiry Date Required: The SLA reset option only triggers when an expiry date is selected during the reclassification or exception request process.
• False Positives Exclusion: Do not apply SLA resets to False Positives. Marking a finding as a False Positive drops its risk score to 0 and removes it from active metrics, making the SLA irrelevant.

3. Configuration Pathways

SLA overrides can be executed through two distinct pathways depending on whether you are managing individual findings or operating at scale.

3.1 Manual Flow (via Triage/Findings Screen)

1. Navigate to Vulnerabilities > Findings.
2. Select the specific finding and click the empty grey box inside the Risk Exception column. (For bulk actions, tick selection boxes on the left and click Propose Risk Exception at the top).
3. In the side panel, locate and turn on the “Reset Findings SLA” toggle switch.
4. Enter your custom “SLA Target Days” (if left blank, the system falls back to your Organization Settings defaults).
5. Provide justification (see section 4.1) and submit for approval.

3.2 Automated Flow (via Exception Engine)

1. Navigate to Automation > Exception Engine and click “Add New Exception Rule”.
2. Define your “IF” matching conditions (e.g. Scanner, Subnet, OS or Asset Tags).
3. Under the “THEN” Action block, select “Risk Recasting” or “Risk Mitigation”.
4. Toggle “Reset Findings SLA” to on.
5. Specify the target days to award, then click “Save Rule & Enable”.

4. Best Practices & Recommendations

4.1 Supporting Evidence & File Handling

Phoenix Security intentionally does not support direct file uploads (e.g. PDFs or Word documents) inside exception forms to prevent storing sensitive internal documentation on the platform.

Store compliance or audit files securely in an internal repository (such as SharePoint or Confluence) and paste the direct URL link into the “Reason/Mitigating Factor” field.

4.2 Risk Acceptance Behavior

When Risk Acceptance is applied, findings appear as closed/ignored, do not count toward Key Risk Indicators (KRIs), and are excluded from SLA reporting until the expiration date passes. Upon expiration, the SLA clock resets.

4.3 Action Bundling

Currently, SLA overrides must be bundled as an atomic action within a single risk exception payload.