In the SLA (Service Level Agreement) section, you can define time-bound remediation targets for vulnerabilities based on their risk level. Each level — from No Risk to Critical — is assigned a specific number of days, indicating how quickly vulnerabilities must be addressed after detection in order to remain compliant with your organization’s SLA policy.
These SLA thresholds allow security administrators to enforce remediation expectations across teams and align with internal governance or external regulatory standards. They are prominently used in Phoenix dashboards to monitor real-time compliance, drive accountability, and proactively flag overdue issues before they escalate into security incidents.
Additionally, you can configure “Resolution SLA” values per risk level. These define the maximum number of days allowed to fully resolve a vulnerability — measured by the time from a creation of a ticket to the closure of a ticket. This ensures that vulnerabilities not only receive attention but are completely addressed within the agreed timeframe, helping maintain both system integrity and compliance posture.
Using Finding based SLA
When Finding-based SLA is active (default setting), SLA tracking is performed at the individual finding level. This method enables your organization to:
- Measure how long each finding has remained open.
- Identify SLA breaches based on the specific criticality level assigned to the finding.
- Report and visualize SLA status across all unresolved vulnerabilities regardless of how they are managed.
This approach is particularly useful when remediation is not yet tied to external ticketing systems and offers a granular view of open risk across the environment.
Using Ticket based SLA
To shift from Finding-based to Ticket-based SLA, scroll to the bottom of the SLA configuration table and select the Ticket-based SLA option.
This mode is ideal when your organization uses tools like Jira, ServiceNow, or similar platforms to manage remediation work. Instead of tracking individual findings, Phoenix will track SLA compliance based on:
- How long remediation tickets have been open, from creation to closure.
- Whether the duration exceeds the threshold set in the Resolution SLA configuration.
This allows for a workflow-aligned SLA model, where teams are measured not just on detection response but on the end-to-end resolution process. It also ensures that SLA monitoring is in sync with how remediation tasks are actually performed and completed across engineering and DevSecOps teams.
