Guide
What should be included in an IT support contract
An IT support contract should state the scope of covered work, the response and resolution commitments, what on-site costs, what is explicitly excluded, the term and notice period, who owns your data and documentation, and what happens on the day you leave. Anything missing from that list is a disagreement waiting to happen, usually at the worst possible moment.
By James 10 min read
Why the contract matters more than the sales meeting
Almost every dispute between a small business and its IT provider comes down to the same thing: both parties had a reasonable but different understanding of what was included. Nobody was lying. The document simply did not say.
That is why the useful reading is not the pages of liability language at the back, which are broadly standard, but the two or three pages describing what you are actually buying. Those are the pages that get skimmed, and they are the pages that decide whether you feel well served in month nine.
The twelve things a contract should state
If any of these is absent, ask for it in writing before signing. A provider who will not put it in the contract will not do it on a Tuesday either.
- Covered scope, which devices, users, servers, sites and applications are supported, listed rather than implied
- Response commitment: how quickly someone starts work, broken down by severity, with "stops the business trading" defined
- Resolution expectation: separate from response, and honest about what depends on a third party
- On-site terms, whether visits are included, the coverage area in miles or postcodes, the rate outside it, and the travel policy
- Hours of cover: the actual hours, plus what out-of-hours costs and how it is requested
- Explicit exclusions: project work, hardware, licensing, out-of-hours, anything outside the coverage area
- Backup specifics: what is backed up, how often, where it is held, how long it is retained, and how often restores are tested
- Security baseline: what protection is included and what is chargeable, including whether MFA rollout is in or out
- Documentation, that an asset register, network documentation and account inventory exist and are given to you on request
- Change control: how new users, devices and sites get added, and what that does to the price mid-term
- Term, notice and price review: the length, the notice period both ways, and when and how the price can change
- Exit: what you get back, in what format, within how many days, and at what cost
Free, before any money changes hands
Want this looked at properly, for nothing?
Ninety minutes mapping how the work actually flows, then a written plan and a fixed quote you keep either way. A working session, not a sales meeting.
- No obligation, no follow-up sequence
- You keep the plan and the quote
or call 01623 354250
Response time versus resolution time
These are different promises and providers frequently blur them. A response commitment is how long before a human being starts working on your problem. A resolution commitment is how long before it is fixed.
Only the first can be genuinely guaranteed. Nobody can promise a resolution time for a fault whose cause is unknown, and any provider offering a blanket four-hour fix guarantee is either excluding everything interesting or planning not to honour it.
What a good contract does instead is define severity levels in business terms, not technical ones. "Priority 1: a fault preventing the business from trading, or affecting all users at a site" is meaningful. "Priority 1: critical system failure" is not, because you and the provider will disagree about what is critical at exactly the moment you cannot afford to.
The clauses that cost you later
Automatic renewal with a long notice period. A twelve-month term that renews automatically unless cancelled 90 days in advance is a contract designed to catch you out, and it usually does. Thirty days on a rolling monthly term is fair to both sides.
Uncapped price review. "Prices may be reviewed annually" with no mechanism means the price can move by any amount. A cap, or a link to a published index, is reasonable to ask for.
Exit fees and data ransom. Charges for handing back your own documentation, credentials or backups are indefensible. So is a clause requiring you to pay for the provider’s time in transitioning away at a punitive rate.
Minimum user counts that only go up. Some contracts let you add users mid-term but not remove them until renewal. If your headcount is seasonal, that clause is expensive.
Bundled licensing you cannot take with you. If the provider resells your Microsoft 365 tenant, check you can move the tenant to another partner without disruption. Usually you can, but the process is worth confirming.
Sole discretion. Any clause where the provider determines, at its sole discretion, whether work falls inside scope is a clause that will be used.
How ours is structured
Rolling monthly, 30 days’ notice either way, no exit fee, and documentation and credentials handed over rather than held. The coverage area is a defined radius rather than a judgement call, and what falls outside the monthly fee is listed rather than implied.
What "unlimited support" actually means
Unlimited is almost always unlimited remote support during business hours, for covered devices, for reactive faults. That is a reasonable offer and it is not the same as unlimited everything.
What sits outside it, in nearly every contract in the market: on-site time, out-of-hours, project work, anything on a device that is not in the covered list, and anything requiring a third-party vendor’s involvement beyond raising the case.
Ask specifically about the fair use clause. If one exists, ask what has triggered it in practice. A provider who has never invoked it will say so; one who invokes it routinely will be vague.
Documentation is the clause nobody reads
The most valuable clause in an IT support contract is the least discussed: a commitment that your environment is documented, and that the documentation is yours.
An asset register, a network diagram, an inventory of accounts and licences, and a record of where the backups sit and how to restore them. If those exist, changing provider is a fortnight of work. If they do not, changing provider is a forensic exercise, and the incumbent knows it.
Ask to see a sample: redacted, from another client, before you sign. A provider that documents properly will be pleased to show you. One that does not will explain why it is not necessary.
What a fair exit looks like
You give 30 days’ notice. Within that period you receive: the asset register and network documentation, administrative credentials for every system the provider holds, a final backup in a restorable and documented format, and a reasonable amount of cooperation with the incoming provider.
You should not be charged for any of it, and none of it should be contingent on settling a disputed invoice. Those two conditions are the difference between a contract that assumes a good relationship and one that plans for a hostage situation.
It is worth reading the exit clause first, before the rest of the document. How a supplier writes about leaving tells you a great deal about how they expect to behave while you stay.
What the contract should say about security
Your IT provider holds administrative access to every system you own. That makes them, in security terms, the largest single risk in your estate, and compromise of an IT provider in order to reach its clients is now a well-documented attack pattern rather than a theoretical one.
A contract should therefore say something about how that access is protected. At minimum: that administrative accounts are individually named rather than shared, that they are protected by multi-factor authentication, that access is logged, and that credentials for your environment are held in a managed vault rather than a spreadsheet.
It should also set out what happens if the provider suffers an incident that could affect you: who tells you, how quickly, and what they will do. A supplier who has thought about this will have an answer ready. One who has not will treat the question as an accusation, which is itself informative.
The other security clause worth reading is the one about your data. It should say plainly that your data remains yours, that it will be returned on request in a usable format, and that it will be securely destroyed from the provider’s systems after a stated period once you leave.
Reading the exclusions properly
The exclusions list is where a contract tells you what it actually is, and it is the section most people skim because it is the least pleasant reading. Two techniques make it faster.
First, take each exclusion and ask how often it happened last year. "Excludes project work" is entirely reasonable, and it matters enormously if half your calls are what the provider would classify as projects. Ask for the classification rule, not just the word.
Second, look for exclusions that are really pricing decisions in disguise. "Excludes support for equipment more than five years old" is a common one, and for a business running perfectly serviceable six-year-old machines it converts a support contract into a hardware refresh proposal. That may be the right answer; it should be a conversation rather than a clause you discover in month three.
A genuinely fair exclusions list is specific, short, and framed around what gets quoted separately rather than what gets refused. If yours reads as a list of ways to say no, that is what it will be used for.
Frequently asked questions
If the answer is not here, ask us. You will get a straight one, from someone who does the work.
Mon–Fri, 9am–5:30pm
What should be included in an IT support contract?
Covered scope, response commitments by severity, on-site terms including the coverage area, hours of cover, explicit exclusions, backup and retention specifics, the security baseline, a documentation commitment, change control, term and notice, price review terms, and exit arrangements. Anything missing from that list becomes a disagreement later.
How long should an IT support contract be?
A rolling monthly term with 30 days’ notice either way is fair and increasingly standard for small business support. Multi-year terms with 90-day notice periods exist to make leaving difficult rather than to make the service better.
Does unlimited support really mean unlimited?
It usually means unlimited remote support during business hours for covered devices and reactive faults. On-site time, out-of-hours, project work and third-party escalations normally sit outside it. Ask whether a fair use clause exists and what has triggered it in practice.
Should an IT support contract guarantee resolution times?
Response times can be guaranteed; resolution times generally cannot, because the cause of a fault is unknown when it is reported. A blanket fix guarantee usually means the exclusions are doing the work, so read those instead.
What should we get back if we leave our IT provider?
The asset register and network documentation, administrative credentials for every system they hold, a final backup in a restorable and documented format, and reasonable cooperation with the incoming provider, at no charge, and not contingent on any disputed invoice.
Can an IT support provider increase the price mid-contract?
Only if the contract allows it, which many do via an annual review clause with no cap. Ask for either a cap or a link to a published index, and check whether adding users mid-term triggers a repricing of the whole agreement.
Who owns our data and documentation?
You should, unambiguously, and the contract should say so. If the documentation of your own network is treated as the provider’s intellectual property, switching becomes far harder and far more expensive than it needs to be.
Should the contract name a specific engineer?
Naming a person is unusual and generally unwise, since people leave. What is reasonable is a commitment to continuity of knowledge: that your environment is documented, that a named account contact exists, and that you are not starting from scratch every time somebody new picks up a ticket.
What should the contract say about our IT provider’s own security?
That administrative accounts are individually named rather than shared, protected by multi-factor authentication and logged, and that your credentials are held in a managed vault. It should also set out who tells you, and how quickly, if the provider suffers an incident that could affect you.