Service Level Agreements For UK Managed IT Providers

Yes - if you provide managed IT services in the UK, you should have a written Service Level Agreement that sets out exactly what support you'll provide, how quickly you'll respond, and where your obligations stop.

The more nuanced part is that an SLA shouldn't promise a perfect outcome every time. Your client may want guaranteed uptime, instant fixes and unlimited support, but your agreement needs to reflect how IT support actually works: some issues are urgent, some depend on third-party platforms, and some can't be fixed until the client gives you access or information.

A well-drafted managed IT service level agreement in the UK helps you look professional, quote with confidence and avoid awkward disputes about what was or wasn't included in the monthly fee.

Do You Need A Service Level Agreement For Managed IT Services?

Yes, you usually need an SLA if you provide ongoing IT support, managed services, hosting, cybersecurity monitoring, helpdesk support or maintenance services.

An SLA is the part of your contract that explains the service standards your client can expect. It's often attached as a schedule to your main managed service provider contract or built into your MSP terms and conditions.

For an IT support business, an SLA can cover things like:

• support hours, such as 9am to 5pm on business days
• priority levels for different issues
• response times for each support tier
• target resolution times, if you offer them
• uptime commitments for hosted services
• maintenance windows and planned downtime
• what is excluded from support
• what the client needs to do before you can help
• credits, remedies or limits if service levels are missed

Without a written SLA, clients may assume that any IT problem is your responsibility, at any time, for no extra fee. That can make it much harder to recover unpaid invoices or push back on out-of-scope requests.

Say you provide managed IT support to a small accountancy firm in Leeds. A printer issue on Monday morning, a suspected ransomware attack and a request to set up a new starter's laptop shouldn't all sit in the same queue. Your SLA gives you a fair way to prioritise the work and explain it to the client before there's pressure in the moment.

What Should Your MSP Contract Include Alongside The SLA?

Your SLA should sit within a wider contract because service levels are only one part of the commercial relationship.

A strong managed service provider contract usually includes:

• Services: the managed services, support and project work you'll provide
• Fees: monthly retainers, per-user charges, device charges, call-out fees and project rates
• Term: whether the contract is month to month, annual or for a fixed period
• Termination: when either side can end the contract, including for non-payment or serious breach
• Service levels: response times, support tiers, uptime targets and remedies
• Client responsibilities: access, backups, approvals, licences, hardware and user behaviour
• Data protection: UK GDPR and Data Protection Act 2018 obligations
• Confidentiality: protection for passwords, systems information and business data
• Intellectual property: ownership of scripts, documentation, tools and custom work
• Liability: caps, exclusions and limits on different types of loss

Templates can be a useful starting point, but MSP contracts often need tailoring because every provider packages support differently. For example, one provider may include Microsoft 365 administration in a monthly fee, while another charges separately for tenant migrations, security hardening and licence management.

How Should You Set Support Tiers And Response Times?

You should set support tiers based on business impact, not on how loudly a client complains.

This is where an IT support SLA in the UK can make day-to-day work much calmer. Your agreement can define different priority levels so your team knows what to deal with first and your client knows what to expect.

Common Support Priority Levels

Many MSPs use a structure like this:

• Priority 1 - Critical: major outage, significant security incident, server down or core system unavailable for many users
• Priority 2 - High: important system affected, several users disrupted, or a serious issue with a workaround available
• Priority 3 - Medium: single user issue, non-critical software problem or standard troubleshooting request
• Priority 4 - Low: minor fault, general query, change request, new user setup or advice

Your contract should say who decides the priority level. Usually, you should reserve the right to assess and reclassify tickets based on the actual impact and urgency.

Response Time Versus Resolution Time

Your SLA should clearly separate response times from resolution times because they aren't the same thing.

A response time is how quickly you'll acknowledge the issue and start assessing it. A resolution time is how quickly the issue will be fixed or worked around.

For example, your SLA might say you'll respond to a Priority 1 issue within one business hour. That doesn't mean you guarantee the server will be fully restored within one hour, especially if the issue depends on a third-party cloud platform, hardware failure, internet service provider or the client's internal approvals.

If you do offer target resolution times, make them realistic and label them carefully. For many MSPs, it's safer to promise target resolution times rather than guaranteed resolution times, unless you have full control over the environment.

Can You Promise Uptime In An Uptime Support Agreement?

Yes, you can promise uptime, but only where you control the systems that affect that uptime and you have clear exclusions.

Uptime commitments are common for hosted services, cloud platforms, managed networks and software systems. They can be attractive to clients, but they need careful drafting.

An uptime support agreement should cover:

• what service the uptime percentage applies to
• how uptime and downtime are measured
• the reporting period, such as monthly or annually
• whether planned maintenance counts as downtime
• whether third-party outages are excluded
• what remedy applies if the target is missed

For example, a 99.9 percent uptime target sounds simple, but it needs context. Does it apply to your own hosted platform only, or also to the client's internet connection, Microsoft 365, a payment gateway, hardware and third-party software? If those external services go down, you may not be able to control the result.

You can also include service credits rather than open-ended compensation. A service credit might be a percentage of the monthly fee credited against the next invoice if uptime falls below the agreed level. If you offer service credits, your contract should say whether the credit is the client's sole remedy for that SLA failure.

What Exclusions Should Your SLA Include?

Your SLA should include clear exclusions so you aren't responsible for problems outside your control or outside the agreed scope.

This is one of the most useful parts of MSP terms and conditions in the UK. It helps you draw a line between included support and chargeable work.

Common exclusions include:

• issues caused by the client's misuse, negligence or unauthorised changes
• support for unsupported or end-of-life software and hardware
• third-party outages, including internet service providers and cloud platforms
• work required because the client ignored your security or maintenance recommendations
• data loss where the client hasn't approved or maintained appropriate backups
• cyber incidents caused by weak passwords, phishing or users bypassing security policies
• new installations, upgrades, migrations and project work not included in the support plan
• after-hours work, unless the client has purchased that level of support
• site visits, hardware replacement and parts, unless included in the package

You don't need to make the exclusions harsh. The aim is to be clear. You can still help the client, but the contract should allow you to charge separately or agree a project scope before doing extra work.

Planned Maintenance Windows

Your SLA should also deal with maintenance windows because IT systems need updates, patches and security work.

You might reserve a regular window, such as outside business hours on a specified day, for planned maintenance. The contract should say how much notice you'll give where practical, and that emergency maintenance may be needed without the usual notice if there's a security or stability risk.

If you provide cybersecurity services, this is especially important. Delaying a security patch because a client doesn't like downtime can create bigger risks for both sides.

What Should Clients Be Responsible For?

Your clients should be responsible for giving you the access, information and approvals you need to provide the service.

Many SLA disputes happen because the provider is blamed for delays caused by the client. Your agreement should make it clear that response and resolution targets may pause or not apply while you're waiting for the client.

Client responsibilities often include:

• providing accurate information when logging tickets
• making key staff available to help troubleshoot
• giving secure access to systems, premises and devices
• maintaining valid software licences and subscriptions
• following your reasonable security instructions
• not making unauthorised changes to systems you manage
• approving quotes, purchases and change requests promptly
• keeping appropriate insurance where relevant
• maintaining backups if backups aren't part of your service

You should also explain how support requests must be submitted. For example, if your SLA only applies to tickets logged through your helpdesk portal, say so. A text message to a technician's personal phone shouldn't accidentally trigger a Priority 1 response time.

If you provide support to clients with employees, you may also need rules around authorised users. Otherwise, your helpdesk can quickly become an unlimited support line for every person in the organisation.

How Do Liability Caps Work In UK MSP Terms And Conditions?

Liability caps can limit your financial exposure, but they need to be drafted carefully under UK law.

For business-to-business contracts in England and Wales, the Unfair Contract Terms Act 1977 can affect whether certain exclusions and limits are enforceable. In simple terms, limits on liability need to be reasonable in the circumstances. If you deal with consumers, the Consumer Rights Act 2015 is also relevant, but most MSP work is business-to-business.

Your contract can't exclude liability for some things, such as death or personal injury caused by negligence, fraud or fraudulent misrepresentation. For other risks, you can often use sensible limits.

Common approaches include:

• capping liability at the fees paid in the previous 12 months
• setting a fixed monetary cap that matches the size of the contract
• excluding indirect or consequential loss, where appropriate
• excluding loss of profit, loss of revenue and loss of business opportunity
• using specific remedies for SLA failures, such as service credits
• requiring the client to maintain backups or business continuity plans

The right cap depends on your pricing, the type of client, the systems you manage and the level of risk. If you support a single retail laptop, the risk profile is very different from managing infrastructure for a healthcare provider or financial services business.

You should also check that your professional indemnity, cyber and public liability insurance align with your contract. A liability cap is useful, but insurance is often the practical safety net if something goes wrong.

Do You Need Data Protection Clauses In Your MSP Agreement?

Yes, you'll usually need data protection clauses because MSPs often access systems that contain personal data.

Under the UK GDPR and the Data Protection Act 2018, your role may be a processor, controller or both, depending on the services you provide. If you process personal data on behalf of your client, the contract needs processor clauses that cover the required UK GDPR terms.

These clauses commonly deal with:

• what personal data you process and why
• the client's documented instructions
• confidentiality obligations for your team
• security measures you'll use
• sub-processors, such as hosting providers or ticketing platforms
• helping the client with data subject requests and security incidents
• what happens to personal data when the contract ends

If you provide cybersecurity monitoring, remote access, backups, device management or email administration, data protection isn't just a privacy issue. It also affects your commercial risk, client trust and how quickly you need to act if there's a suspected personal data breach.

Where a breach may need to be reported to the Information Commissioner's Office, the controller usually has 72 hours from becoming aware of it to notify the ICO, unless the breach is unlikely to risk people's rights and freedoms. Your contract should require fast notification between you and the client so neither side loses time.

Key Takeaways

• A managed IT SLA should set clear response times, support tiers, exclusions, maintenance windows and client responsibilities.
• Response times and resolution times are different. Be careful about guaranteeing fixes unless you control the whole environment.
• Your SLA should sit inside a wider MSP contract covering fees, scope, termination, data protection, confidentiality and liability.
• Exclusions help you avoid being responsible for third-party outages, unsupported systems, unauthorised client changes and out-of-scope project work.
• Liability caps can protect your business, but they need to be reasonable and tailored to your services under UK contract law.
• UK GDPR clauses are usually needed because MSPs often access systems containing personal data.

If you'd like help with your MSP service agreement, service levels, support exclusions and liability clauses, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.