Managed Services
What a managed IT service agreement should include — and the clauses to push back on
Most managed IT agreements promise a fast response. Far fewer commit to the problem actually being fixed. Here is what a good agreement covers, the wording to look for, and the clauses worth negotiating before you sign.
Response time is not resolution time
The most common line in a managed IT contract is a response target: "we respond to critical issues within 15 minutes." Response means someone acknowledged the ticket. It says nothing about when your systems work again. A useful agreement defines both: a response target and a resolution or restoration target for each priority level, with the clock rules written down — when it starts, whether it pauses outside business hours, and what counts as resolved. If the only number in the contract is response time, you have bought a promise to pick up the phone.
Define the priority levels in business terms
Priority definitions decide which clock applies, so they should describe business impact rather than technical symptoms. "P1: a system the business cannot operate without is down for everyone" is testable. "P1: critical severity" is not. Check who sets the priority — you, the provider, or an agreed rule — and how a disagreement gets escalated. Providers that classify every incident as P3 can meet any target on paper.
Scope: what is in, what is out, and what it costs when it's out
Every agreement has a boundary: devices, users, locations, applications and cloud accounts that are covered. Write the list down and say how it changes as you grow — per user, per device, or by tier. Equally important is what happens outside scope. Projects, new office set-ups, after-hours work and third-party software support are common exclusions. They are reasonable, but the rate for them should be in the agreement, not invented on the day you need it.
Service credits that actually mean something
A service credit is what you get when the provider misses a commitment. Many credits are capped so low, or require so much paperwork to claim, that they never change behaviour. Look for credits that apply automatically when a target is missed, that scale with how badly it was missed, and that are reported to you without you having to ask. Ask how often credits were paid out last year; a provider that measures its own performance will know.
Security responsibilities, written as a split
Security is where assumptions cause the most damage. The agreement should state who patches what and how fast, who reviews alerts and at what hours, who holds administrator credentials, how backups are tested, and who leads incident response. A shared-responsibility table — one column for you, one for the provider — removes most of the ambiguity. Also check notification duties: how quickly the provider must tell you about a suspected breach, which matters for your own obligations under PIPEDA and provincial privacy law.
Your data, your documentation, your exit
The clauses that matter most are often the ones about leaving. You should own your configuration, documentation, passwords and data, and the agreement should commit the provider to hand them over in a usable form within a set number of days of termination. Watch for long auto-renewal terms, termination fees that apply even when the provider is in breach, and tooling that only the provider can operate. A provider confident in its service does not need lock-in to keep you.
Reporting you can check
Finally, ask what you will see each month: tickets opened and closed by priority, targets met and missed, patch compliance, backup test results and open risks. Reports built from the ticketing system are verifiable; reports written as prose usually are not. If the provider cannot show a sample report before you sign, assume you will not get one afterwards.
Frequently asked questions
- What is the difference between an SLA and a managed services agreement?
- The managed services agreement is the whole contract: scope, price, term, responsibilities and exit. The SLA (service level agreement) is the part that sets measurable targets — response and resolution times, uptime and service credits — and is usually a schedule to the main agreement.
- What response time should a managed IT SLA have?
- It depends on the priority level and your hours. A common pattern is minutes for a full outage, a few hours for a degraded system and a business day for routine requests. More important than the number is that the SLA also sets a resolution target and defines the priority levels in business terms.
- Can I leave a managed IT contract early?
- Only on the terms in the agreement. Look for termination for cause when the provider repeatedly misses SLA targets, a reasonable notice period, and a commitment to hand over documentation, credentials and data within a fixed number of days.
Next step
Want early access to our thinking?
Subscribe to receive Aethon Core insights as they publish — practical, plain-language content on enterprise technology from people who build it.