Resource
What should be in a managed IT contract?
A fast response time promised in a contract means nothing if the same problem keeps coming back. The managed IT services contract you sign should reflect whether a provider is managing your environment to a standard. Not just promising to show up quickly when something breaks.
Dawn Sizer · CEO and Co-Founder, 3rd Element Consulting · Response times matter. They're not the whole story.
Most conversations about managed IT contracts start and end with response time. How fast will someone answer. How fast will the issue get resolved. Those numbers matter and a contract without them isn't worth much.
But a response time commitment measures one thing: how fast a provider reacts after something has already gone wrong. It says nothing about whether the same issue will happen again next month, whether the underlying condition that caused it ever gets addressed, or whether anyone is looking at your environment between incidents.
A provider can hit every response time in the contract and still be running reactive support. Fast reaction to recurring problems isn't a sign of good management. It's a sign that nobody is asking why the problem keeps coming back. The contract should tell you whether you're paying for speed alone or for an environment that's actually being managed against a standard.
Scope: the section that determines every future argument.
Scope defines what the provider is actually obligated to do. This is the section most disputes trace back to, because vague scope language almost always favors whoever wrote the contract.
A scope section that says "comprehensive managed IT services" tells you nothing. A real scope section names services specifically enough to be measured: which systems are covered, what patch cadence applies, what's included in Microsoft 365 administration, what backup monitoring actually means versus backup management.
That last distinction matters more than most buyers realize. Many contracts only monitor backups, confirming a job ran, while the backup software itself is billed as a separate line item. If your contract doesn't say which one you're getting, you may find out the difference at the worst possible time.
Compare the contract against whatever proposal or sales conversation led to it. If the contract describes a narrower scope than what was discussed, the contract is what governs in a dispute, not the conversation that got you to sign.
"Commitment" and "target" are not the same word.
This is a small detail that creates a large gap in practice. Contract language that says a provider will respond within a certain time is binding. Language that says response time is a goal, an objective, or "typically" within a certain window is not.
Read your contract specifically for this distinction. A response time described as a commitment means something happens if it's missed. A service credit, an escalation, a remedy defined elsewhere in the document. A response time described as a target or a goal is aspirational. Nothing is owed to you if it's missed because nothing was actually promised.
This single word choice is one of the easiest things to overlook and one of the most consequential. If a contract is full of soft language around its performance promises, that tells you something about how seriously those promises are meant to be kept.
What an SLA should say about response time
A response-time promise is only useful if you know what it measures. Check whether the clock counts business hours or every hour, whether "response" means a person working the problem or an automated acknowledgment, whether urgent issues get a faster tier than routine ones, and what happens if the provider misses the number.
How we handle it: our average response time runs under 15 minutes. We don't write 15 minutes into the contract, because a contractual SLA should be a number a provider can meet on its worst day, not its average one. The SLAs in our contracts are ones we meet. Our office hours are Monday through Friday, 8:30am to 5:00pm Eastern, with staff on call after hours for issues and emergencies.
What's normal to exclude. And why that's not a red flag.
Every managed IT contract has boundaries, and a contract with no exclusions at all is usually hiding the cost of "everything included" somewhere else.
Common and reasonable exclusions: major infrastructure projects like new servers or office buildouts, initial compliance certification work, custom development beyond a defined threshold, line-of-business application support for industry-specific software the provider doesn't own, and hardware costs passed through at acquisition price.
None of these exclusions are a problem by themselves. The problem is when they're not named. A contract that's vague about what falls outside the agreement leaves you discovering the boundary the first time you need something and get billed for it unexpectedly. Ask for the exclusions list explicitly, and read it alongside how managed IT pricing is actually built so you understand what's inside the number and what isn't. A provider who can hand it to you without hesitation has a contract built on clarity. One who can't is asking you to find out as you go.
Security has to be specific, not implied.
A contract should name security responsibilities the same way it names support hours. Specifically, not generally. Who patches what and on what cadence. Whether MFA and conditional access are part of the base agreement or a separate line item. What endpoint protection product is actually deployed, and whether it's enterprise-grade or a consumer tool. Who owns monitoring alerts and how quickly they get reviewed, not just generated.
Security language that says the provider will "implement best practices" is not specific. It's the same vague pattern as scope language that says "comprehensive services." If you can't tell from reading the contract exactly what security controls you're paying for, you don't actually know what you're buying.
Backup and recovery: what's covered versus what's true.
The contract should distinguish between backup monitoring and backup management, and it should say whether restore testing is part of the agreement or something you'd need to request separately.
A contract that promises backups without specifying recovery time and recovery point objectives is promising you a copy of your data exists somewhere. Not that you can actually get your business running again within a timeframe you'd find acceptable. Ask the contract to answer the same question we've raised elsewhere on this site: if a critical system went down tonight, how long would recovery take, and is that answer written down anywhere, or just assumed.
Who owns what when the relationship ends.
This section gets the least attention and matters the most. The contract should state plainly that your data, your documentation, and your credentials belong to you, not the provider, and it should describe what the exit process looks like before you ever need it.
Look for a defined transition period, a commitment to provide admin access and credentials without delay, and clarity on what happens to your data and configurations if you leave. A provider who is vague about this section, or who treats a transition-support request as a new negotiation, is telling you something about how the relationship will go if it doesn't work out.
What good contract language actually sounds like.
Specific, not aspirational. Response and resolution times stated as commitments with defined remedies if missed, not goals.
Enumerated, not generic. A scope section that lists what's covered in enough detail that "is this included" is rarely a question anyone has to ask.
Named exclusions. A clear list of what falls outside the agreement, agreed to upfront rather than discovered later.
Explicit security ownership. Specific tools, specific cadences, specific accountability. Not a sentence about following best practices.
Clear data and exit terms. Your ownership of your data and a defined transition process stated plainly, not left to be negotiated if the day ever comes.
Contract red flags
- Auto-renewal with a long notice window. Many contracts renew for a full term unless you give notice 60 to 90 days ahead. Miss the window and you're committed for another term.
- Termination fees tied to the remaining contract value. Some contracts charge a share of every remaining month to leave early, even when service has been poor.
- Documentation owned by the provider. Network diagrams, configurations, and system records you paid to have created should belong to you.
- "Best efforts" SLAs. A response commitment without a number and a remedy isn't a commitment.
- Out-of-scope defined too broadly. If routine work like a vendor call or setting up a new application triggers a project fee, "all-inclusive" isn't.
- Automatic annual price increases with no cap.
- No exit terms. The contract should say what the provider hands over, and how quickly, when the relationship ends.
How we handle it: Our contracts spell out the exact exit terms before you sign. We ask for 90 days' notice, and we never hold a client's accounts, data, or access hostage. When a client leaves, the business keeps what's theirs.
What this means before you sign anything.
A contract full of fast response promises and thin on everything else is a contract for reactive support with good marketing. The response time tells you how quickly someone shows up. It doesn't tell you whether anyone is preventing the next incident, whether your backups would actually work, or who owns your data if you decide to leave.
If you're reviewing a current contract or evaluating a new one and want a clear read on what it actually commits a provider to, that's exactly what an IT Environment Review is for.
Common questions
Questions leadership usually asks first.
Is a fast response time enough to know an IT contract is good?
What's the difference between a "commitment" and a "target" in an IT contract?
Should I be concerned if a managed IT contract has exclusions?
What should a contract say about backup and data recovery?
What contract terms should we watch for with an IT provider?
What are 3rd Element's exit terms?
What is an IT Environment Review?
Can our IT provider refuse to give us our passwords?
Continue reading
Related work and reading.
Questions to Ask Before Choosing a Managed IT Provider
The conversation to have before the contract shows up on your desk.
Read more: Questions to Ask Before Choosing a Managed IT ProviderHow Much Does Managed IT Actually Cost?
What's inside the number, and what shows up as a separate line item later.
Read more: How Much Does Managed IT Actually Cost?IT Environment Review
A read on what a proposed or existing contract actually commits your provider to.
Read more: IT Environment ReviewNext step
Schedule an IT Environment Review.
Get a clear read on what your current or proposed managed IT contract actually commits to, and whether it matches what your business needs.