Service Level Agreements¶
SLA policies define the response and resolution targets for tickets based on priority, ticket type, and other criteria. The platform uses these targets to track SLA compliance, surface breached or at-risk tickets, and trigger escalation notifications.
Navigation
Configuration > Service Level Agreements on the GRC-ITSM website navigation.
Overview¶
SLAs in the platform are configured around priority levels. Each priority defines a response target (how quickly the ticket should be acknowledged) and a resolution target (how quickly it should be resolved). Targets can be measured in working hours or calendar hours depending on the priority.
SLA policies can be assigned as defaults per ticket type, applied automatically via ticket rules, or set manually on individual tickets. Priority names are SLA-scoped: the same priority level can carry different labels and targets under different SLA policies, so an SLA is always read as a (policy, priority) pair.
SLA Escalation Rules¶
Separate from ticket rules, SLA escalation rules fire based on SLA timer events (approaching breach, breached) rather than ticket property changes. These are configured within the SLA policy and determine who is notified and what actions are taken when SLA targets are at risk.
Remediation SLAs¶
For compliance ticket types like Issues, remediation SLAs are baseline-specific. Both models are configured as SLA policies assigned to the Issue ticket type and enforced through the platform's SLA tracking.
Remediation timelines follow the FedRAMP Continuous Monitoring Strategy Guide:
| Severity | Remediation Timeline |
|---|---|
| Critical | 30 days |
| High | 30 days |
| Moderate | 90 days |
| Low | 180 days |
Remediation follows the Class Remediation SLA ladder (VDR-TFR-PVR): priority is set by the issue's PAIN rating and its evaluation flags (internet reachability, likely exploitability), and the target is reduction to a lower PAIN rating within the timeframe. KEV findings additionally carry the CISA KEV catalog due date per BOD 26-04, enforced independently of the ladder, and the 192-day accepted-vulnerability boundary applies from evaluation. See the Vulnerability Detection & Response policy for the Class C values.
When an approved Vulnerability Deviation adjusts an issue's rating, the issue's priority is remapped against its Remediation SLA at the approved tier and the remediation clock re-baselines.
Reporting OLAs¶
Incident reporting clocks are tracked as operational-level agreements (OLAs) on the incident ticket: the Initial, Ongoing, and Final Incident Report timeframes are keyed to the incident's PAIN rating (for example, a PAIN 5 incident carries a 1-hour Initial Incident Report target and a 6-hour Ongoing Incident Report cadence). The full PAIN-keyed table lives in the Incident Response policy ODV table.
Related documentation¶
- Vulnerability Detection & Response policy -- the remediation model behind the Issue SLAs
- Incident Response policy -- the reporting timeframes behind the incident OLAs
- Ticket Rules -- applying SLA policies automatically