What should be in your IT support contract or SLA

An IT support service level agreement, usually shortened to SLA, is the part of your contract that sets out what your provider promises to do, how quickly it will respond, and what is not covered. A good one is specific about scope, response and resolution commitments, priority definitions, exclusions, escalation, security responsibilities and what happens when a target is missed. This guide explains each part in plain English, sets out the questions worth asking before you sign, and describes the red flags that usually signal vague intentions rather than firm commitments. Use it on any contract in front of you, including one of ours.

What is an SLA, and how is it different from the contract itself?

The two documents do different jobs, and the difference is worth ten minutes of your time before you sign anything.

The contract is the overall legal agreement. It covers the term, the fees and how they change, notice periods, liability, confidentiality, data protection and the conditions under which either side can walk away. It is the document your solicitor will want to read.

The service level agreement is normally a schedule inside that contract. It sets the performance standards: how quickly the provider will acknowledge a problem, how issues are prioritised, what is in scope, what is excluded, and how performance is measured and reported. It is the document you will actually live with.

A tenancy agreement is a reasonable analogy. The tenancy sets the rent, the term and the deposit. The repairs clause is what tells you how quickly the landlord will come out when the boiler fails in January. A tenancy can look perfectly respectable and still leave the repairs clause vague. IT support contracts fail in exactly the same way: the commercial terms are tight, the performance schedule is thin, and nobody notices until something breaks.

So when you review a proposal, read the schedule first. If there is no SLA schedule at all, or if it amounts to a paragraph of reassuring adjectives, that is the finding.

What a good SLA should cover

A good service level agreement typically specifies eight things. Use this as a checklist against whatever document is in front of you.

1. Scope of cover. Exactly which users, devices, applications, sites and hours are included, and which are not. Vague scope is where most disputes start.
2. Response time commitments. How quickly the provider acknowledges an issue and begins work, set out by priority level, rather than a general promise to act as soon as possible.
3. Resolution time commitments or targets. How quickly issues are expected to be fixed, clearly distinguished from response. Some issues genuinely cannot carry a fixed resolution time, but the agreement should say how they will be handled.
4. Priority or severity definitions. How urgent is separated from routine, with examples, and who decides. Agree the definitions before an incident, not during one.
5. Escalation path. What happens when a target is missed: who is notified, at what point, and what the next step is. An escalation clause with named roles is worth more than one that promises attention.
6. Exclusions. What sits outside the agreement. Common and reasonable examples include third-party software faults, hardware beyond a certain age, and problems caused by changes made without the provider’s knowledge.
7. Reporting. How performance against the SLA is measured, what is reported, and how often. If nothing is measured, nothing is promised.
8. Review and change process. How the agreement can be updated as you grow, take on a new site or adopt a new system, and how much notice each side needs to give.

None of these needs to be complicated. They need to be written down. A commitment that exists only in a sales conversation is not a commitment.

Response time versus resolution time (a common point of confusion)

These two terms are easy to confuse, and in marketing copy they are sometimes blurred on purpose.

Response time is how quickly somebody acknowledges that your problem exists and starts work on it. Resolution time is how quickly the problem is actually fixed.

A fifteen minute response is a good sign of a well-staffed service desk. On its own, it tells you nothing about whether your finance team will be able to run payroll this afternoon. If an agreement commits to a response time and says nothing whatsoever about resolution, the practical protection it offers you is limited to the speed of the first reply.

This does not mean every issue can carry a guaranteed fix time. Some depend on a third party, a hardware replacement or a vendor patch. What a good agreement does instead is commit to resolution targets where they are realistic, explain how the remainder are managed, and give you regular updates so that you are never left guessing.

When you read a proposal, find both numbers. If only one exists, ask why.

Questions to ask before you sign

Nine questions, and a note on what a straight answer sounds like.

1. How are response and resolution times defined, and how are they measured? A good answer describes both, names the measurement system and offers to show you a report.
2. What counts as a priority one issue? You want examples relevant to your business, such as an entire site offline, rather than an abstract definition.
3. What is explicitly excluded from the SLA? Every agreement has exclusions. A provider who says there are none has either not read their own schedule or is not being straight with you.
4. What happens if a target is missed? Look for a defined escalation route and, where offered, a stated remedy. The absence of any consequence is itself informative.
5. Is out-of-hours or 24×7 cover included, or charged separately? If your team works evenings, weekends or across time zones, get this in writing rather than in principle.
6. How is pricing structured, and does it change when something breaks? Ask directly whether per-incident, per-device or project-rate charges can arise inside the covered scope.
7. How will performance be reported back to us, and how often? Monthly reporting with named measures beats an open invitation to ask any time.
8. What security monitoring is included as standard rather than sold as an extra? Managed detection and response, the service that watches for attacks around the clock and acts on them, is now a baseline expectation rather than a luxury.
9. How much notice do we need to give to leave, and what does offboarding look like? A confident provider will describe how they hand over documentation, administrative access and data without drama.

Ask these of everyone you are considering. The pattern of answers across two or three providers tells you more than any brochure.

Ask us these questions

Or call 020 7123 4910

Red flags in an IT support contract

Six things that should slow you down before signature.

Response times promised in conversation but absent from the document. If it matters enough to say out loud, it matters enough to write into the schedule. Ask for it to be added.

Vague language with no measurable target. Phrases such as reasonable endeavours, prompt attention and industry-leading response sound like commitments and are not. A target you cannot measure is a target nobody can miss.

Pricing that depends on per-incident or per-device charges. This one is about incentives rather than cost. When a provider bills per incident, a busy month is a good month for them. When they bill per device and the scope is drawn narrowly, the cheapest way to protect their margin is to define more of your estate as out of scope. Neither structure means a provider is acting badly, and plenty of good firms use them. It does mean your interests and theirs are not automatically pointing the same way, so read the covered scope closely. Our managed IT services pricing guide sets out how the main pricing shapes compare in more detail.

Security monitoring offered as an optional extra. Continuous monitoring is now part of a normal baseline for a business of 20 to 500 users. If it appears as a line item you can decline, ask what the service actually covers without it. The National Cyber Security Centre’s supply chain security guidance is a useful reference point for what you should expect a supplier to take responsibility for.

No clear definition of what counts as urgent. Without agreed severity definitions, priority becomes a negotiation held at the worst possible moment, when your systems are down and everybody is under pressure.

Terms that make leaving difficult. Long automatic renewals, short windows in which to give notice, charges for handing back your own data, or administrative credentials the provider will not share. None of these improve the service you receive. They only raise the cost of changing your mind.

How Lanmark structures its own contracts

Judge any contract against the checklist above, including ours.

Lanmark’s managed IT support in London is priced per user, with unlimited support included and no per-device or per-incident billing. That structure exists for the incentive reason set out above: when the price does not move with the number of tickets or devices, we do not earn more because something broke, and we have every reason to fix the underlying cause rather than the symptom. The same model applies whether you use us for full IT outsourcing or to support an in-house team.

Security monitoring is part of the service rather than a bolt-on. Our 24x7x365 managed detection and response service, run from a security operations centre, is included as standard at pricing built for SMBs rather than for enterprises.

On capability, we would rather point at something verifiable than describe ourselves. Lanmark is a Microsoft Direct CSP, meaning we hold a direct billing and support relationship with Microsoft under its Cloud Solution Provider programme rather than working through a distributor. We also hold Microsoft’s Support Service Designation, an accreditation held by only a handful of companies worldwide and awarded on the basis of assessed support quality. Both are facts you can check, which is rather the point of this article.

Before you sign anything

Take the checklist and the nine questions and put them to whoever has sent you a contract. If the answers are specific, written down and measurable, you are probably in good hands regardless of whose logo is on the front page. If they are warm but vague, you now know exactly what to ask for next. We are happy to look over what you have been offered, whether or not it is ours, and if you would prefer a smaller first step, our free Microsoft 365 licence review is a straightforward place to start.

Talk to us about your IT support contract

Or call 020 7123 4910

Frequently asked questions

What is the difference between an IT contract and an SLA?

The contract is the overall legal agreement covering the term, fees, notice periods, liability and data protection. The service level agreement is normally a schedule within it that sets the performance standards, such as response times, priority definitions, exclusions and reporting. The contract governs the commercial relationship, while the SLA governs what you experience day to day when something goes wrong.

What should a good IT support SLA include?

A good IT support service level agreement specifies eight things: the scope of cover, response time commitments by priority, resolution times or targets, clear priority and severity definitions, an escalation path when a target is missed, explicit exclusions, regular performance reporting, and a process for reviewing and changing the agreement as your business grows. Each should be written into the schedule rather than described in conversation.

What is the difference between response time and resolution time?

Response time is how quickly the provider acknowledges your issue and begins work on it. Resolution time is how quickly the issue is actually fixed. The two are easily conflated in marketing material, but a fast response with no resolution commitment offers limited practical protection. A good agreement addresses both, and explains how issues that cannot carry a fixed fix time will be managed and updated.

What counts as an exclusion in an IT support contract?

An exclusion is something the agreement specifically does not cover, so it falls outside the promised response and resolution standards. Common and reasonable examples include faults in third-party software the provider does not manage, hardware beyond a defined age, and problems caused by changes made without the provider’s knowledge. Every agreement has exclusions, so ask to see them listed rather than assuming there are none.

Is 24×7 security monitoring usually included in an IT support SLA?

It varies considerably. Many providers treat continuous security monitoring, often described as managed detection and response, as a chargeable extra rather than part of the core service, so check whether it appears as an optional line item. Lanmark includes 24x7x365 managed detection and response as standard, run from a security operations centre and priced for smaller businesses rather than enterprises.

Should I be wary of per-incident or per-device pricing?

Be aware of it rather than automatically wary. The point is incentives. If a provider bills per incident, more problems mean more revenue. If they bill per device and the covered scope is drawn narrowly, more of your estate falls outside the agreement. Plenty of good providers use these models, but read the scope closely so you understand where the boundary sits.

What happens if my IT provider misses an SLA target?

That depends entirely on what the agreement says, which is why it is worth checking before you sign. A good contract sets out an escalation path: who is notified, at what point, and what happens next. Some agreements also include a remedy such as a service credit, though many do not. If the document describes no consequence at all, that tells you something useful.

How often should an IT support SLA be reviewed?

Most agreements are reviewed annually, but the better test is whether anything material has changed. New sites, significant growth or reduction in headcount, a move to different core systems, or a shift in working patterns can all leave the original scope out of date. A good SLA sets out how it can be varied and how much notice each side needs, so the review is straightforward rather than a renegotiation.