Defender SLA Breach and Escalation

What to do when a Defender for Cloud finding exceeds its SLA. This procedure covers automated escalation (via Jira automation rules) and manual escalation steps.

SLA Thresholds

Severity	SLA Target	Escalation Trigger	Automation
High	1 week	7 days in “To Do”	Rule 1: SLA reminder comment
High + prod	2 weeks	14 days open (any status except Done)	Rule 4: Priority bump + overdue label
Medium	2 weeks	14 days in “To Do”	None (manual review during weekly check)
Low	1-2 sprints	No automatic trigger	None (reviewed quarterly)

Automated Escalation

Two automation rules handle escalation automatically. See the automation setup guide for configuration details.

Level 1: SLA Reminder (Day 7)

What happens: Automation Rule 1 posts a comment on High-severity issues that have been in “To Do” for 7+ days.

What to check:

1. Is the issue assigned? If not, assign it.
2. Is the issue blocked? If yes, document the blocker as a comment and create a dependency ticket.
3. Does the issue need to be re-prioritized? If the finding is not actionable, consider moving to Non-Issue or Won’t Do (with approval per the process).

Level 2: Overdue Escalation (Day 14)

What happens: Automation Rule 4 fires on High+prod items open 14+ days:

• Priority bumped to Highest
• overdue label added
• Escalation comment posted

Required actions:

1. Team lead reviews the item within 2 business days
2. Determine root cause of delay: capacity? dependency? unclear scope?
3. Take one of these actions:

Situation	Action
Unassigned	Assign immediately to available team member
Assigned, no updates	Contact assignee directly — are they blocked or is this deprioritized?
Assigned, blocked	Document the blocker. Is it an external dependency? Create a linked ticket.
Needs more information	Add needs-triage label and discuss in next team sync
Genuinely not actionable	Start the Won’t Do approval process

Level 3: Team Lead Intervention (Day 21+)

There is no automation for this level. If an item reaches 21+ days open:

1. Team lead must review personally
2. Consider:
   • Is this a systemic issue (team capacity, missing skills, unclear ownership)?
   • Should this be escalated beyond the team?
   • Does the SLA need to be formally waived?
3. If waiving the SLA:
   • Add sla-waived label to the issue
   • Add a comment with justification: why the SLA is being waived and the new target date
   • This removes the item from the automated escalation cycle

Manual Escalation (Medium/Low)

Medium and Low findings don’t have automated escalation, but should still be reviewed:

Medium Findings

• Reviewed during the weekly review
• If a Medium finding has been in “To Do” for 14+ days, apply the same decision matrix as Level 2 above
• Medium + prod items should get priority over Medium + non-prod

Low Findings

• Reviewed during quarterly full review (see process cadence)
• Low findings are backlog items — they don’t trigger escalation unless they also carry risk-critical or attack-path labels
• If a Low item has those risk labels, treat it as Medium for escalation purposes

Useful JQL Queries

# All overdue High items (automated escalation targets)
project = DEVOPS AND labels = Defender AND labels = defender-high AND labels = overdue AND status != Done

# High items approaching SLA (5-7 days, not yet flagged)
project = DEVOPS AND labels = Defender AND labels = defender-high AND status = "To Do" AND created <= -5d AND created > -7d

# Medium items overdue (14+ days, manual review)
project = DEVOPS AND labels = Defender AND labels = defender-medium AND status = "To Do" AND created <= -14d

# Items with waived SLA
project = DEVOPS AND labels = Defender AND labels = sla-waived AND status != Done

Notes

• SLA clock starts at issue creation, not assignment
• Weekends and holidays count toward the SLA (calendar days, not business days)
• The overdue label is permanent — it stays on the issue even after resolution, serving as a historical record
• If an issue is re-opened after being marked Done, the original creation date still applies for SLA purposes