What to Include in an IT Support SLA (And What to Demand)
An SLA that doesn't specify the right things gives you false comfort. Here's exactly what a properly structured IT support SLA should contain.
Why Most SLAs Are Inadequate
Many IT support contracts include SLA language that sounds reassuring but provides little actual protection. "Best effort response times." "We will endeavour to resolve issues promptly." These are not SLAs. They're polite commitments that are impossible to enforce.
A real SLA has specific numbers, specific consequences, and specific obligations on both sides.
What a Proper IT Support SLA Must Contain
1. Response time definitions — by priority level
Not one response time. Multiple, based on incident severity.
Example structure:
- Critical (production system down, security breach): Response within 30 minutes
- High (major functionality impaired): Response within 2 hours
- Medium (partial functionality impaired): Response within 4 business hours
- Low (minor issue, workaround available): Response within next business day
When is support available? Business hours only? Extended hours? 24/7 for critical incidents? This should match your actual business risk.
3. Escalation paths
If the first responder cannot resolve the issue, who does it escalate to? By when? What triggers escalation?
4. Reporting obligations
Monthly reports should be contractually required, not optional. At minimum: uptime statistics, incident log, actions taken, open items.
5. Consequences for breach
What happens if the vendor misses the SLA? A credit against the next invoice is standard. Without this, the SLA is unenforceable in practice.
Questions to Ask Before Signing
- "Can you show me an example monthly report from an existing client?"
- "What was your last SLA breach, and what happened?"
- "Who specifically responds to critical incidents at 2am?"
The answers tell you whether the SLA describes actual practice or just aspirations.