Managed IT services SLA documents get read twice: once at signature, when nobody is anxious, and once during an outage, when every single word suddenly matters. The second reading is the one that decides whether you bought a contract or a leaflet.
This guide is a clause-by-clause inventory. It sets out what a managed IT services SLA has to contain to be worth anything, why each clause exists, and what the wording usually looks like when a supplier is protecting themselves rather than committing to you. It is written for a UK buyer with 30 to 250 users who is comparing two or three proposals and cannot tell which one is actually stronger.
Every legal and published figure below was read off source on 21 August 2026: the Microsoft Volume Licensing Service Level Agreement for Microsoft Online Services, the Unfair Contract Terms Act 1977, the Supply of Goods and Services Act 1982, the Limitation Act 1980, UK GDPR Articles 28 and 33 on legislation.gov.uk, ICO guidance on processor contracts, and the Crown Commercial G-Cloud 14 agreement. Where a number had to be modelled rather than read off a page it is labelled modelled and the working is shown.
The worked example throughout is a 60-user UK professional services firm across three sites paying £55 per user per month — £3,300 a month, £39,600 a year. Our two earlier guides cover the numbers themselves: the managed IT SLA guide explains what response, resolution and uptime targets mean, and response vs resolution explains how the two clocks differ. This one is about the document. What we deliver sits on our managed IT services page.
Table of contents
- What a Managed IT Services SLA Is, and What It Is Not
- The Twelve Clauses Every Managed IT Services SLA Needs
- Scope: What a Managed IT Services SLA Actually Covers
- Availability: The Uptime Arithmetic in a Managed IT Services SLA
- Priority, Response and Resolution
- Service Credits: What a Missed Target Actually Pays
- The Legal Clauses a Managed IT Services SLA Leans On
- Security, Backup and Continuity Commitments
- Reporting, Change, Term and Exit
- Scoring a Managed IT Services SLA Before You Sign
- What We Put in Our Own Managed IT Services SLA
- Managed IT Services SLA: Frequently Asked Questions
- References
What a Managed IT Services SLA Is, and What It Is Not
Most buyers of managed IT services are handed three documents and told they are one thing. They are not. Separating them is the first step to reading any of them properly, because the promises you care about are rarely in the document with the promising-sounding name.
The SLA is a schedule, not the whole agreement
A managed IT services SLA is a performance schedule bolted onto a master services agreement. The master agreement holds the money, the liability cap, the term and the exit rights. The schedule holds the numbers. Neither works without the other, and a supplier who will only show you the schedule is showing you the half with no consequences in it.
Three documents that get confused
The master services agreement governs the relationship. The service schedule or scope document says what is covered. The managed IT services SLA says how well the covered things will be done and what happens if they are not. Ask for all three by name, in writing, before you compare prices.
Why “we aim to respond quickly” is not a service level
A service level needs four parts to exist at all: a measurable thing, a target number, a measurement method, and a consequence. Drop any one and it becomes an intention. Most weak managed IT services SLA wording fails on the third and fourth — the target is there, but nobody says who measures it or what a miss costs.
The test to apply to every clause
Read each clause of the managed IT services SLA and ask what a hostile but competent supplier could do while still complying with it. If the answer is “almost anything”, the clause is decorative. This single test will do more for your review than any checklist, including the one below.
The Twelve Clauses Every Managed IT Services SLA Needs
A managed IT agreement can be short and still be strong, but it cannot be vague. Twelve clauses carry almost all of the weight, and a document missing more than two of them is not a service level agreement in any meaningful sense.
The inventory at a glance
The table below is the whole article in one view. Each clause gets its own section further down, with what good wording looks like and the failure mode to watch for.
| # | Clause | What it must actually state | Common failure |
|---|---|---|---|
| 1 | Parties, term and commencement | Who is bound, from what date, for how long | Service starts before the schedule is signed |
| 2 | Covered assets and users | Counts by device, user, server and site | Scope described in adjectives, not numbers |
| 3 | Out of scope and chargeable work | A named list, plus the rate for anything on it | Silence, so everything awkward becomes a quote |
| 4 | Service hours and coverage | Days, hours, time zone, holidays, out-of-hours route | “Business hours” with no definition |
| 5 | Availability target | A percentage, a measurement window and a source | A percentage with no method behind it |
| 6 | Priority definitions | Impact times urgency, with worked examples | The supplier alone assigns priority |
| 7 | Response and resolution targets | Separate numbers per priority tier | Response only; resolution omitted entirely |
| 8 | Exclusions and clock stops | A closed list of what pauses the clock | “Awaiting customer” with no time limit |
| 9 | Security, patching and backup | Patch windows, RPO, RTO, restore testing | Backup promised, restore never tested |
| 10 | Reporting, review and audit | Monthly report contents and a review date | Reports on request, which means never |
| 11 | Service credits and remedies | A credit table, a claim window, an escalation right | Credits capped so low they cost nothing |
| 12 | Change control and exit | How targets change, and what you get on the way out | Supplier may amend the schedule on notice |
How to use the list
Score each managed IT services SLA clause present, partial or absent, and keep the tally. In our experience a strong proposal covers ten or eleven properly. Anything below eight is a document that will be argued over rather than relied on, and the arguing always happens on your worst day.
Scope: What a Managed IT Services SLA Actually Covers
Scope is where most disputes begin, and it is the cheapest thing in the world to fix at signature. Every hour spent making a managed IT services SLA specific about scope is an hour you will not spend on a call about whether a printer is included.
Covered assets, counted rather than described
Count the estate: endpoints, servers, firewalls, switches, wireless access points, mobile devices, and every line-of-business application with a support entitlement. “All IT” is not a scope statement. A managed IT services SLA that names 78 endpoints and 6 servers can be checked; one that says “your infrastructure” cannot.
Covered people and locations
Name the sites and the user count, and say what happens to a home worker’s broadband, a director’s personal laptop and a site you open in month eight. Growth clauses in the managed IT services SLA matter here: agree now what a new site costs and how much notice the provider needs, because agreeing it later costs more.
The out-of-scope list is the important half
A good managed IT services SLA names what is excluded: hardware supply, cabling, third-party vendor licence fees, project work above a stated number of hours, out-of-hours changes, and anything unsupported by its own manufacturer. An exclusion list is not a supplier being difficult. It is a supplier telling you the truth about the fee.
Service hours and the size of the gap
Coverage is the quietest multiplier in the document. A week has 168 hours, and the window you buy decides how much of it is genuinely covered. The chart below is straightforward arithmetic on those 168 hours and nothing else.
Why the uncovered hours decide the response target
A four-hour response target inside a 10×5 window is not a four-hour target. A failure at 17:00 on a Friday is answered at 12:00 on Monday under a strict reading, because the clock only runs during covered hours. Say explicitly, in the managed IT services SLA, whether clocks run in elapsed time or covered time. The difference here is 67 hours.
Availability: The Uptime Arithmetic in a Managed IT Services SLA
Availability percentages are the most quoted and least examined numbers in the document. They are also the easiest to check, because the arithmetic is fixed and takes about a minute.
What each nine actually costs you in minutes
On a 30-day month of 43,200 minutes and a 365-day year of 525,600 minutes, the allowances work out as follows. Nothing here is a claim about any supplier — it is division.
| Target | Allowed per 30-day month | Allowed per 365-day year | Reads as |
|---|---|---|---|
| 99.0% | 432.00 minutes (7.20 hours) | 5,256.00 minutes (87.60 hours) | Most of a working day, every month |
| 99.5% | 216.00 minutes (3.60 hours) | 2,628.00 minutes (43.80 hours) | An afternoon, every month |
| 99.9% | 43.20 minutes | 525.60 minutes (8.76 hours) | One long incident a month |
| 99.95% | 21.60 minutes | 262.80 minutes (4.38 hours) | One short incident a month |
| 99.99% | 4.32 minutes | 52.56 minutes | Effectively a single reboot a year |
Measured over what period, and by whom
A monthly measurement window and an annual one behave very differently. Under a 99.9% annual target, a single 8-hour outage can be absorbed by eleven clean months. Under a monthly target, that same outage breaches the month it happens in. Insist the managed IT services SLA names the window, and prefer monthly.
The measurement source has to be named
Microsoft’s published SLA is instructive here because it does name its source: uptime is calculated from user minutes, where downtime is each incident’s length multiplied by the number of users affected. Whatever your provider uses — RMM agent, synthetic monitor, ticket timestamps — the tool must be named in the managed IT services SLA and its data must be available to you.
Scheduled downtime is not downtime
Almost every agreement excludes planned maintenance from the availability calculation, and that is reasonable. What is not reasonable is unlimited planned maintenance. Microsoft commits to at least five days’ notice before scheduled downtime; borrow that structure and cap both the notice period and the number of maintenance hours per quarter.
The exclusion list that shrinks the promise
Microsoft’s general terms exclude fourteen categories from its availability commitment, including factors outside its reasonable control, third-party software and services, customer misconfiguration, unauthorised action by your own staff, use of preview features, exceeding quotas, and performance degradation without actual unavailability. A managed IT services SLA with a similar list is normal. One with an open-ended list is not.
Priority, Response and Resolution
This is the part of the document your staff will feel every week. Two earlier guides on this site go deep on the two clocks; here the concern is only what has to be written down.
Priority is impact times urgency, agreed in advance
Priority should be a function of two things you define together: how much of the business is affected, and how time-critical it is. Both sides need the same matrix written into the managed IT services SLA, and the customer needs a documented right to escalate a priority. Without that right, every ticket is whatever the supplier’s queue needs it to be.
A worked priority table
The table below is a model, not a standard — adjust the numbers to your own tolerance. What matters is that a managed IT services SLA contains a table like it, that resolution appears alongside response, and that the examples are drawn from your business rather than a template.
| Priority | Definition | Response | Resolution or workaround |
|---|---|---|---|
| P1 Critical | Whole site or a core system down; no workaround | 15 minutes | 4 hours |
| P2 High | A team or a billing-critical function blocked | 1 hour | 8 working hours |
| P3 Medium | One user blocked, or degraded service with a workaround | 4 working hours | 2 working days |
| P4 Low | Request, question, or cosmetic fault | 1 working day | 5 working days |
| P5 Scheduled | Starters, leavers, planned change | 1 working day | By the agreed date |
What “response” has to mean
Define response as a human acknowledgement that names an owner, not an automated ticket receipt. Every managed IT services SLA that counts the auto-reply as the response has a 100% response record and tells you nothing. One sentence fixes it: response means contact by a named engineer who has read the ticket.
Resolution, workaround and the words in between
Resolution is the promise most suppliers avoid, and where they do commit, they usually commit to a workaround. That is defensible, provided the document says what a workaround is and how long it may stand before a permanent fix is due. Fourteen days is a reasonable outer limit to negotiate for.
Clock stops, and the limit on them
Pausing the clock while waiting for you is fair. Pausing it indefinitely is not. Require that a clock stop is logged with a timestamp, that it only starts after a documented request to a named person, and that it expires after a stated period. A managed IT services SLA without that last part has no resolution target at all.
Service Credits: What a Missed Target Actually Pays
Service credits are the enforcement mechanism, and they are almost always weaker than buyers assume. Understanding how weak is the point of this section, not an argument for abandoning them.
How the published benchmarks are structured
Microsoft’s Office 365 services use a three-step table: below 99.9% uptime the credit is 25% of the applicable service fees, below 99% it is 50%, and below 95% it is 100%. That structure — a tiered percentage of the monthly fee for the affected service — is the model most managed IT services SLA documents copy, and it is a reasonable starting point.
The claim window is the trap
Credits under a managed IT services SLA are almost never automatic. Under Microsoft’s general terms you must submit a claim with a description of the incident, its time and duration, affected resource names, the number and location of affected users, and the errors seen. For non-Azure services the claim must arrive by the end of the month following the month of the incident. Miss that and the credit is gone.
Sole and exclusive remedy
Read this phrase carefully wherever it appears. In Microsoft’s SLA, service credits are the sole and exclusive remedy for availability problems, credits cannot exceed the monthly fee for the affected service, and they explicitly do not compensate lost revenue or operational costs. A managed IT services SLA that copies this wording has capped your recovery at one month’s fee.
What a credit is worth against real loss
Modelled, on the worked 60-user firm: assume an average fully loaded staff cost of £32 per working hour, so one hour of total outage costs 60 × £32 = £1,920.00. Apply the Microsoft credit tiers to the £3,300 monthly fee and compare the credit with the modelled cost of the downtime the tier permits.
What to do with that arithmetic
The credit shrinks as the failure grows, which is the opposite of what you want. So treat credits as a signal of seriousness rather than as insurance, and put the real protection elsewhere: a termination right after a stated number of consecutive misses, and a liability position that is not capped at one month’s fee. A managed IT services SLA with a rolling three-strike exit right is worth more than one with generous credits.
The Legal Clauses a Managed IT Services SLA Leans On
The performance schedule sits on top of a body of English law and a set of statutory obligations — contract, liability and data protection — that apply whether or not the document mentions them. Knowing which ones are automatic tells you which clauses are genuinely negotiable.
Reasonable care and skill is implied anyway
Under section 13 of the Supply of Goods and Services Act 1982, where a supplier acts in the course of a business there is an implied term that the service will be carried out with reasonable care and skill. That baseline exists even if your managed IT services SLA is silent. It is a floor, not a substitute for targets, because “reasonable” is decided years later by a court rather than next Tuesday by your team.
Liability caps and the reasonableness test
Section 3 of the Unfair Contract Terms Act 1977 applies where one party deals on the other’s written standard terms of business, and it prevents a supplier excluding or restricting liability for breach except so far as the term is reasonable. Section 11(5) puts the burden on the party relying on the term to prove it. Section 11(4) directs the court to consider the resources available to meet the liability and how far insurance was available.
What that means at the negotiating table
A cap set at one month’s fee — £3,300 on the worked example, or 8.33% of the annual £39,600 — sits against a supplier who almost certainly carries professional indemnity cover in the millions. Ask what cover is held, then ask why the managed IT services SLA caps recovery so far below it. Twelve months’ fees, or the value of the insurance, are both common landing points.
Limitation: six years, or twelve
Section 5 of the Limitation Act 1980 gives six years from the date the cause of action accrued for an action founded on simple contract. Section 8 gives twelve years for an action on a specialty, which in practice means a contract executed as a deed. Whether your managed IT services SLA is signed under hand or as a deed therefore doubles or halves your window, and nobody ever mentions it.
Data protection is not optional wording
Your provider processes personal data on your behalf, so UK GDPR Article 28 requires a written contract containing eight specific terms. Article 28(9) requires it in writing, including electronic form. These are not clauses you negotiate; they are clauses that must be present. Their absence tells you something about the supplier’s maturity before you read anything else.
| Article 28(3) | The processor must | What to look for in practice |
|---|---|---|
| (a) | Process only on documented instructions | Where those instructions actually live |
| (b) | Ensure staff are bound by confidentiality | Contracts and vetting for engineers |
| (c) | Implement Article 32 security measures | Named controls, not “industry standard” |
| (d) | Respect the conditions on sub-processors | A current list, and notice of changes |
| (e) | Assist with data subject rights requests | A stated turnaround for a search |
| (f) | Assist with Articles 32 to 36 compliance | Breach support and DPIA input |
| (g) | Delete or return data at end of service | Which one, in what format, by when |
| (h) | Provide information and allow audits | Audit rights that are not fee-gated |
Breach notification timing belongs in the schedule
Article 33(1) gives a controller 72 hours from becoming aware of a personal data breach to notify the ICO, and Article 33(2) requires the processor to notify the controller without undue delay. “Without undue delay” is not a number. Convert it into one in your managed IT services SLA — 24 hours is a common and achievable figure — because your own 72-hour clock is running inside theirs.
Security, Backup and Continuity Commitments
A support agreement that says nothing about patching, backup or restore is a break-fix contract with a monthly invoice. These are the clauses that decide whether the service is preventive or merely reactive.
The patching clock
State a maximum time from vendor release to deployment for high-risk and critical updates, separately for operating systems, firmware and applications. Fourteen days is the standard the Cyber Essentials question set uses, and failing it is an automatic assessment failure, so aligning the managed IT services SLA to it costs nothing and keeps two obligations in step.
Backup, RPO and RTO as numbers
Recovery point objective is how much data you accept losing, measured in time. Recovery time objective is how long recovery may take. Both must appear in the managed IT services SLA as numbers per system, not a single figure for the estate. A file server at RPO 1 hour and RTO 4 hours is a different service from a mailbox at RPO 24 hours and RTO 48 hours, and both should appear in the schedule.
Restore testing, witnessed
A backup that has never been restored is a theory. Require a restore test at a stated frequency — quarterly is normal — with a written result, and require that at least one test a year is witnessed by you. This is the single most valuable line you can add to a managed IT services SLA and it is almost never in the first draft.
Identity, MFA and the cybersecurity baseline
Multi-factor authentication on every cloud service that offers it is now an auto-fail question in the Cyber Essentials scheme, which makes it a sensible cybersecurity minimum to write into the contract too. Add privileged account review at a stated interval, joiner and leaver turnaround times, and a named owner for the tenant’s break-glass account.
Monitoring and what triggers a human
The managed IT services SLA should say what is monitored, at what interval, and which alerts create a ticket automatically rather than waiting for someone to notice. An alert that lands in an unwatched mailbox is not monitoring, and the distinction only becomes visible after the incident it should have prevented.
Reporting, Change, Term and Exit
The last group of clauses governs the life of the agreement rather than the delivery of the service. They are the ones buyers skim, and the ones that decide how the relationship ends.
What a monthly service report must contain
Ticket volumes by priority, performance against every target with the misses listed individually, patch compliance by device, backup success and failure counts, restore tests completed, open risks, and changes made. Specify the contents in the managed IT services SLA. A report whose format the supplier chooses will drift towards whichever numbers look best.
The review cadence and the right to verify
Monthly operational reporting, quarterly service review with the named leads, annual strategic review. Add a right to inspect the underlying data behind any reported figure within a stated number of working days, written into the managed IT services SLA itself. ISO/IEC 20000-1:2018 puts service level management on the same footing — targets are agreed, monitored and reviewed — so a certified provider should have no objection.
Term, renewal and notice
Fixed term, auto-renewal behaviour, and notice periods on both sides, stated in days rather than months to avoid arguments about what “three months” means. For scale, the Crown Commercial G-Cloud 14 agreement caps an initial call-off at 36 months with a single extension of up to 12 months, a total of 48. A 60-month lock-in with 6 months’ notice is out of step with that benchmark.
Change control and the price review clause
Two clauses need attention. One: neither party may amend the service targets unilaterally, and any change is by signed variation. Two: the price review mechanism must be bounded — an index and a cap, not “the provider may adjust charges on 30 days’ notice”. An unbounded price clause makes every other number in the managed IT services SLA provisional.
Exit, data return and documentation
A managed IT services SLA should say that on termination you get, within a stated number of days: all your data in a usable format, administrative credentials, documentation and network diagrams, and reasonable transition assistance at a rate agreed now. Article 28(3)(g) already requires deletion or return of personal data, so the commercial clause only has to add everything that is not personal data.
Scoring a Managed IT Services SLA Before You Sign
A checklist tells you what is missing. A weighted score tells you whether what is missing matters. This is the model we use when reviewing an incoming agreement, and it is designed to be run by a non-lawyer in about an hour.
The weighted model
Six sections, one hundred points, weighted by how much damage a gap in each part of a managed IT services SLA does. Score each section on its own merits, then add them. The weights are a judgement rather than a standard, and you should adjust them if your business is unusual.
The pass mark, and the override
Seventy-five out of a hundred is a workable managed IT services SLA. Below 60 it is a marketing document. And there is an override that beats the total: any section scoring under half its weight is a fail regardless of the score elsewhere, because a perfect availability clause cannot rescue an agreement with no exit rights.
Five questions to ask in the room
Which tool measures uptime, and can we see its data? What does response mean, exactly? What stops the resolution clock and for how long? What is the liability cap, and what insurance sits behind it? What do we get on day one after termination? A supplier who answers all five without checking has a managed IT services SLA worth reading.
When to bring in a lawyer
For a contract under about £50,000 a year, an hour of specialist review on the liability, data protection and exit clauses is usually enough, provided you have already done the operational review yourself. Send them a marked-up copy with your scorecard attached rather than the raw document; it makes the hour go a great deal further.
What We Put in Our Own Managed IT Services SLA
For transparency, here is how the twelve clauses land in what we offer, so you can compare it against whatever else is on your desk rather than take a general principle on trust.
Scope and hours
Assets are counted and listed, with an explicit exclusions schedule and a named rate for anything on it. Coverage windows are quoted as hours per week using the arithmetic above, and the clock convention — elapsed or covered — is stated rather than assumed.
Targets and evidence
Availability is measured monthly from a named tool whose data you can see. Priorities use an impact-times-urgency matrix with worked examples from your business, resolution targets sit next to response targets, and clock stops expire. The monthly report contents are fixed in the schedule.
Security, exit and the review rhythm
Patching aligns to the 14-day critical standard, RPO and RTO are set per system, restores are tested quarterly with one witnessed test a year, and exit returns your data, credentials and documentation on a stated timetable. Our onboarding checklist covers the first thirty days, and our guide to what a managed IT contract should contain covers the commercial wrapper. To have your current agreement scored against the model above, the contact page is the quickest route.
Managed IT Services SLA: Frequently Asked Questions
What is the minimum a managed IT services SLA must contain?
Scope with counts, service hours, an availability target with a named measurement source, priority definitions, response and resolution targets per priority, exclusions with bounded clock stops, security and backup commitments with RPO and RTO, reporting contents, a credit table with a claim window, and exit terms. Ten items, and a managed IT services SLA containing all of them still fits on four pages.
Is 99.9% uptime a good target for a small business?
It is a reasonable one. It allows 43.20 minutes a month, which is one moderate incident. Writing 99.99% into a managed IT services SLA pushes you into resilient hardware, redundant connectivity and out-of-hours cover, and the cost usually exceeds the value unless downtime genuinely costs you thousands per hour.
Are service credits worth negotiating hard for?
Only up to a point. As the modelled figures above show, a credit recovers 59.68% of the modelled cost of a small miss but only 4.77% of a severe one. Spend your negotiating capital on a managed IT services SLA termination right after repeated misses, and on the liability cap, instead.
Can a supplier change the SLA during the term?
Not unilaterally, if the document is drafted properly. Require that any change to targets, scope or price is by signed variation, and that price adjustments are tied to a published index with a stated cap. A clause letting the provider amend the schedule on notice undoes everything else you negotiated.
Do we need a separate data processing agreement?
You need the Article 28 terms in writing somewhere, and most providers put them in a separate DPA that the master agreement incorporates. That is fine. What is not fine is a managed IT services SLA that mentions data protection only in a single sentence about taking security seriously.
How often should the agreement be reviewed?
Operationally every month, formally every quarter, and properly once a year against your actual ticket data. The annual review is where targets get corrected — most agreements are written against an estate that has since changed shape, and reviewing a managed IT services SLA against reality is cheaper than renegotiating one after a failure.
References
Service Level Agreement for Microsoft Online Services — Microsoft Volume Licensing
How to read a service-level agreement — Microsoft Learn
UK GDPR Article 28: Processor — legislation.gov.uk
UK GDPR Article 33: Notification of a personal data breach — legislation.gov.uk
Contracts and liabilities between controllers and processors — ICO
Unfair Contract Terms Act 1977, section 3 — legislation.gov.uk
Unfair Contract Terms Act 1977, section 11 — legislation.gov.uk
Supply of Goods and Services Act 1982, section 13 — legislation.gov.uk
Limitation Act 1980, section 5 — legislation.gov.uk
Limitation Act 1980, section 8 — legislation.gov.uk
G-Cloud 14 agreement RM1557.14 — Government Commercial Agency
ISO/IEC 20000-1:2018 Service management system requirements — ISO
