A managed IT services contract should do four things: define what is covered and what is billed separately, set service levels against numbers you can actually verify, state the provider’s own security obligations to you, and spell out exactly how the relationship ends.
Most buyers read the service catalogue closely and skim the exit clauses. That is the wrong way round. The service catalogue describes a good year. The exit, change of control and data return clauses describe a bad one, and those are the ones you will be reading under pressure.
These contracts tend to get signed in a hurry, at the end of a procurement process that has already worn everyone out. The schedule arrives as a PDF, the commercial terms look reasonable, and the parts that carry the most risk are the parts nobody reads twice.
This guide sets out what belongs in a managed IT services contract, which clauses actually decide your exposure, and the questions worth asking before signing. Transputec sits on the supplier side of these agreements, which we would argue makes this more useful rather than less.
Why the Contract Matters More Than the Pitch
A pitch is about capability. A contract is about obligation. They are not the same thing, and the gap between them is where most unhappy outsourcing relationships quietly begin.
A provider can be genuinely excellent at everything they demonstrated and still carry no duty to do any of it at the speed you assumed. Response times, out of hours cover, who absorbs the cost when a migration overruns, what happens to your data on the way out: these are contract questions, and a good sales meeting will not answer a single one of them.
There is a regulatory dimension now too. The government factsheet on relevant managed service providers brings IT outsourcing inside the scope of the Cyber Security and Resilience Bill, which makes your provider’s security posture your compliance problem in a far more formal way than before. We set out what that means in MSP vs MSSP: What Is the Difference.
What a Managed IT Services Contract Must Define
Strip out the boilerplate and a managed IT services contract has to answer six questions without ambiguity.
- What is covered. Named services, named systems, named sites.
- What is explicitly not covered. The expensive surprises live here.
- How fast, and measured how. Including who owns the clock and who stops it.
- What the provider owes you on security. Their controls, their certifications, their notification duties.
- What happens when something goes wrong. Remedies that are not just a service credit.
- How it ends. Notice, transition assistance, and the return of your data.
Everything else in the document is detail. If any of those six is vague, the vagueness is not an accident and it will not resolve in your favour.
Reviewing a contract you have been sent?
Send it over. A Transputec service lead will read it and tell you plainly which clauses would give us pause if we were the ones being asked to sign.
Book a consultationScope: What Is Covered, and What Is Billed Separately
Scope is where almost every dispute starts, and it starts because the contract described the service in adjectives rather than nouns. A managed IT services contract that promises comprehensive IT support has promised nothing. One that names the systems, the sites and the user count has promised something you can hold it to.
Three things to pin down. First, what unit drives the price: users, devices, sites or tickets. Each behaves differently when you grow, and a per device model gets expensive the moment everyone picks up a second laptop. Second, where business as usual stops and project work begins, because that line is where unplanned invoices live. Third, who manages your third party vendors. Somebody has to sit on hold to a software vendor for an hour, and if the contract is silent, that somebody works for you.
Then look for the clause that should exist and often does not: an explicit out of scope list. A provider willing to write down what they will not do is a provider who has thought about delivery. A provider who will not write it down has left themselves room, and that room is not for your benefit.
Service Levels: The Numbers That Mean Something
Most service level schedules guarantee a response, not a resolution. Responding is cheap. An automated acknowledgement technically responds. What you need to know is how quickly the problem goes away, and who is allowed to stop the clock while it is being measured.
| Clause | Weak version | What to insist on |
|---|---|---|
| Response time | We aim to respond promptly | A stated time per priority, 24/7 or explicitly not, measured from ticket creation |
| Resolution | Not mentioned at all | Target resolution per priority, reported monthly whether or not it is met |
| Stopping the clock | Provider decides when a ticket is awaiting customer | Defined pause states, logged, visible to you in the ticket |
| Priority | Provider assigns the priority | You assign it, the provider may propose a change with a reason |
| Remedy for failure | A service credit | Credit plus a formal escalation path, plus a termination right if breaches repeat |
| Measurement | Provider’s own monthly summary | The same report, with the underlying ticket data available on request |
Be honest with yourself about service credits. A credit is a partial refund, not a remedy. It returns a slice of the fee and does nothing about the day your finance team could not close the month. The clause that actually protects you is the one that lets you leave when failures repeat.
Service levels also measure the wrong thing fairly often. A provider can hit every target while your staff quietly lose faith in IT. That gap is the argument for experience level agreements, and our take on SLA driven IT support covers where the traditional model still earns its place.
Security and Supply Chain Obligations
This is the section that has changed most, and the one most contracts have not caught up with. Your provider holds privileged access to everything you own. Under the incoming regime they are a regulated supplier, and their weaknesses arrive on your risk register whether or not the contract mentions them.
The government’s Cyber Security Breaches Survey 2025/2026 found that just 15% of businesses had reviewed the risks posed by their immediate suppliers, and only 6% had looked at their wider supply chain. The contract is the one moment when reviewing a supplier is easy, because they want your signature.
Four things to require in writing. A notification window for any incident at the provider that could affect your data, stated in hours rather than as soon as reasonably practicable. A named security contact with an escalation path that does not run through the service desk. Evidence of the certifications they claim, not a logo on a website, which is what our own certifications page exists to provide. And disclosure of subcontractors, because the firm you audited may not be the firm doing the work at 2am.
The Exit Clauses Most Buyers Skip
Nobody signs a managed IT services contract while thinking about leaving, which is exactly why these clauses are where providers get to be creative. Read them first, while you still have leverage.
Notice period, and whether it is symmetrical. Twelve months from you and three from them is a common and unbalanced arrangement. Ask why.
Transition assistance. Is the provider obliged to help you move to a successor, is that help included or chargeable, and at what day rate. An uncapped day rate during an exit is a hostage arrangement with a nicer name.
Data return. In what format, within how many days, and does it cover ticket history and documentation as well as the obvious systems. Then ask for written confirmation of deletion afterwards.
Knowledge and credentials. Administrator accounts, the asset register, licence records, network diagrams and anything else the next provider will need on day one. If this is not listed, assume it is not coming.
Change of control. Consolidation in this market is constant, and the firm you chose may be owned by somebody else inside the term. A change of control clause gives you a defined right to review, and sometimes to exit, if the company you signed with becomes a different company. Transputec has been on the acquiring side of that, so we would rather you asked the question than discovered the answer later.
Auto renewal. Check the renewal window and the notice required to stop it. A contract that rolls for another two years because a diary reminder was missed is not a negotiation you will enjoy.
A Managed IT Services Contract Checklist
Take this to the review meeting. If a line cannot be answered from the document itself, it is not in the contract, whatever anyone says in the room.
- Are the covered services, systems and sites named rather than described?
- Is there an explicit out of scope list?
- What unit drives the price, and what happens when that number grows by a third?
- Where does business as usual end and chargeable project work begin?
- Are resolution targets stated, or only response targets?
- Who assigns ticket priority, and who may pause the clock?
- Is there a remedy beyond a service credit, including a right to terminate on repeated failure?
- What is the incident notification window, in hours?
- Are subcontractors disclosed, and can they change without telling you?
- Is the notice period the same in both directions?
- Is transition assistance included, and is the day rate capped?
- In what format and timescale does your data come back, and is deletion confirmed?
- What happens if the provider is acquired?
- When does it auto renew, and what stops it?
How Transputec Approaches This
Two things shape how Transputec writes a managed IT services contract, and both are visible on our Managed IT Services page rather than buried in a schedule.
The first is that we measure ourselves on experience level agreements, not only on SLAs. Hitting every response target while users quietly give up on IT is a failure we would rather catch, and that only happens if the contract measures something closer to how the service actually feels.
The second is scope under one statement of work. Service desk, network, cloud, cyber and AI sit together rather than as separate agreements with separate escalation paths and a gap in the middle where nobody owns the problem. The underlying services, including the Managed IT Service Desk, infrastructure, DBA, network and DevOps, are named individually so you can see what you are buying.
On transitions, the reference point we would point any buyer to is World Rugby: a global managed IT transition delivered with zero service disruption across 132 federations and six regional associations. Transition is the part of a contract that is easiest to promise and hardest to evidence, so ask any provider, including us, for the example rather than the assurance.
The Short Version
A managed IT services contract is really four documents pretending to be one: a service catalogue, a service level schedule, a security annex and an exit plan. Buyers spend most of their attention on the first. Most of their risk sits in the last.
So read the ending first. If the exit, data return and change of control clauses are clean, the rest of the negotiation is about price and scope, and those are problems you can solve later. If they are not clean, nothing else in the document will rescue you.
Transputec is content to be read in that order, and if you are reviewing a proposal from somebody else, our managed IT services team will go through it with you and say which clauses we would want changed.
Frequently Asked Questions
How long should a managed IT services contract run?
Three years is common, one year is safer, and the right answer depends on how much transition work sits at the front. A provider absorbing a complex migration will want a longer term to recover that cost, which is reasonable. What is not reasonable is a long term with a short notice period in the provider’s favour. If you agree to three years, ask for a break at the end of year one tied to service level performance.
Are service credits worth negotiating?
Worth having, not worth spending your negotiating capital on. A service credit refunds a fraction of a monthly fee and never covers what an outage actually cost you. Spend the effort on the escalation path and on a termination right that triggers after repeated failures. Those change behaviour. Credits mostly get written off quietly on both sides.
Should the contract name specific people?
Name roles, not individuals. A named account manager leaves and the clause dies with them. What you want is a defined role with a stated response obligation, a named escalation contact at director level, and a commitment that any replacement is introduced before the handover rather than after. Continuity of the team is a fair thing to ask about; a specific person’s name in a contract is rarely enforceable.
What should the incident notification window be?
State it in hours, not in language. Twenty four hours for an incident at the provider that could affect your data is a defensible position, and shorter if you are regulated. Avoid as soon as reasonably practicable, which means whenever the provider’s own legal review finishes. Also specify what the notification must contain, because a message saying we are investigating an issue is not notification in any useful sense.
Can we exit a managed IT services contract early?
Usually only if the contract lets you, which is why it matters before signing rather than after. Look for a termination right on repeated service level failure, a change of control clause, and a termination for convenience option with a defined fee. Without one of those you are negotiating from a weak position. If you are already in a managed IT services contract you want out of, read the exit and assistance clauses first, then talk to Transputec about what a clean transition would look like.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
