On this page 8 sections
An IT support SLA (service level agreement) is the part of your support contract that turns "we'll look after you" into numbers you can check: how fast someone responds, how fast things get fixed, which hours are covered and what happens when targets are missed. If your contract doesn't say those things in writing, you don't really have an SLA.
It's written for small and medium South African businesses comparing support providers, or reviewing the contract they already have.
Short answer
- A good IT support SLA lists the services covered, the support hours and how to log a request.
- It sets response and resolution targets for each priority level, with plain definitions of each level.
- It covers uptime (if the provider hosts anything), backups, security, POPIA duties, reporting and what happens when targets are missed.
- Read the exclusions, the "clock stops" rules and the exit terms before you sign.
What an IT support SLA is
Atlassian describes an SLA as a documented commitment between a service provider and a customer (opens in a new window). It covers the services, the measurable targets, how those targets are tracked and the consequences of missing them.
In IT support, the SLA usually sits inside or next to the main contract. The contract covers price, term and legal terms. The SLA covers how the service actually performs. The test is simple: "fast, friendly support" is a promise, while "we respond to critical issues within 30 minutes, 24 hours a day" is a target you can measure.
The IT support SLA checklist
1. Scope: what is and isn't covered
List the users, devices, systems and software that are covered, such as laptops, email, your website, servers and the office network. Then list what isn't covered: new projects, buying hardware, or software the provider doesn't manage. Most disputes start with a gap in this section.
2. Support hours and how to log a request
State the business hours, the time zone and how public holidays are handled. Say whether critical issues are covered after hours. List the ways to log a request (phone, email or a portal). A help desk gives each request a reference number and a timestamp, and that timestamp is what the SLA clock runs from.
3. Priority levels with plain definitions
Every target depends on priority, so each level needs a definition anyone in your business can apply. The targets below are an example only, not an industry standard. Agree your own.
| Priority | Example situation | Example response | Example resolution or workaround |
|---|---|---|---|
| 1 Critical | Whole business or a key system is down | 30 minutes, 24/7 | 4 hours |
| 2 High | A team or important function is affected | 1 business hour | 1 business day |
| 3 Medium | One person affected, a workaround exists | 4 business hours | 3 business days |
| 4 Low | A request or question | 1 business day | Agreed date |
4. Response time and resolution time
These are not the same. Response time (opens in a new window) is how quickly the provider acknowledges your request. Resolution time runs from when you report the issue to the final fix. Watch for a "response" that is only an automatic email. Ask for the response to mean that a person has started working on it. For critical issues, ask for a target to get you working again (a workaround), even if the full fix takes longer.
5. Uptime, if the provider hosts something
If the provider hosts your website, email or servers, the SLA should include an uptime target. Small differences in the percentage make a big difference in practice. Here is how much downtime each level allows in a 30-day month:
| Uptime target | Downtime allowed per 30-day month |
|---|---|
| 99% | 7.2 hours |
| 99.5% | 3.6 hours |
| 99.9% | 43.2 minutes |
| 99.95% | 21.6 minutes |
Check how uptime is measured, whether scheduled maintenance counts, and when maintenance is allowed to happen.
6. Escalation and named contacts
The SLA should say who you contact if a ticket stalls, with roles and contact details for each step up. It should also say who on your side may log tickets and approve paid work.
7. Security, backups and POPIA
Backups should be spelled out: what is backed up, how often, where the copies are kept, for how long, and how often a restore is tested. Security duties should be clear too: who applies updates, who manages antivirus and multi-factor authentication, and who watches the alerts.
If your provider can access personal information on your systems, they are likely an "operator" under POPIA. Section 21 of POPIA (opens in a new window) requires a written contract that makes the operator maintain proper security measures. It also requires the operator to tell you immediately if they believe personal information has been accessed without permission. You, as the responsible party, then report the compromise to the Information Regulator (opens in a new window). Put a clear notice time and a contact person into the SLA, and keep a plan for what to do if your website is hacked. This is general information, not legal advice.
8. Reporting and reviews
Ask for a monthly report showing tickets logged, targets met and missed, and recurring problems. A short quarterly review is where you fix the causes, not just the symptoms.
9. What happens when targets are missed
The usual remedy is a service credit, which is a percentage off your monthly fee. As a real example, Atlassian's cloud SLA (opens in a new window) promises 99.90% uptime on its Premium plans and gives a 10% credit below that, rising to 50% below 95%. Customers must claim by the 15th of the following month. Credits are usually small compared with what downtime costs you, so also check whether repeated misses let you leave the contract early.
10. Exit and handover
Agree the notice period and what you get back when you leave: passwords, admin accounts, documentation, and access to your domain and hosting, within a set number of days. The same thinking applies when you choose a web development agency.
Fine print to read twice
- Clock-stop rules. Most SLAs pause the clock while the provider waits for you or a third party. That's fair, as Atlassian notes (opens in a new window), but the situations should be listed.
- Exclusions. Look for broad wording about events "outside our control", your own changes, or unsupported equipment. Ask how power cuts and internet outages are treated.
- "Best effort" wording. "Reasonable endeavours" in place of a number means there is no real target.
- Out-of-scope rates. Find out the hourly rate for work outside the contract before you need it.
- Automatic renewal. Note the renewal date and how much notice you must give.
Which level of SLA do you need?
| If your business... | Look for |
|---|---|
| Works office hours and can wait a few hours for most fixes | Business-hours cover with a fast target for critical issues |
| Sells online or takes bookings after hours | 24/7 cover for critical issues and an uptime target for your website |
| Handles a lot of personal information (medical, financial, HR) | Written POPIA terms, a breach notice time and tested backups |
| Runs on one key system, such as an ERP or booking system | A named escalation contact and a workaround target for that system |
Questions to ask before you sign
- What exactly counts as a critical issue, and who decides?
- Does "response" mean a person is working on it, or an automatic email?
- When was a backup last restored as a test, and how long did it take?
- How will you tell us about a security incident, and how quickly?
- Can we see a sample monthly report?
- What do we get back, and how fast, if we leave?
How we can help
Our IT consulting work starts with a review. We can read through your current support contract and SLA, point out the gaps, and help set up the help desk, monitoring and backups that make the targets measurable, through our Cloud & DevOps work. If you're comparing providers, we can help you turn this checklist into questions for each one. Get in touch to book a review.
Facts checked on 9 November 2026. Sources: Atlassian: What is an SLA? (opens in a new window), Atlassian cloud SLA (opens in a new window), POPIA section 21 (opens in a new window), Information Regulator fact sheet (opens in a new window). Atlassian is a trademark of its owner, named as an example only.
Let's work together
Ready to talk? We'll reply within 2 working days. Get in touch