What an IT Maintenance Contract Should Actually Cover
IT maintenance contracts are bought during a crisis and read during the next one. That is the wrong order, and it is how businesses end up discovering that the thing they most needed help with was explicitly excluded on page four.
The contract is not a formality. It is the document that decides, at the worst possible moment, whose problem something is.
Response Time Is Not Resolution Time
The most common misunderstanding, and the one providers are least motivated to clear up. “Four hour response” usually means someone will acknowledge the ticket within four hours. It says nothing about when the problem will be fixed.
A contract worth having distinguishes:
- Response time — when a human acknowledges and begins work
- Resolution target — when the problem is expected to be fixed, by severity
- Escalation path — what happens, and who gets involved, when the target is missed
If only response time is specified, you have bought an acknowledgement service. Ask for resolution targets by severity, in writing. A provider unwilling to commit to any is telling you something useful.
Severity Levels Must Be Defined by You
Severity definitions decide which clock applies, so they matter more than the clocks themselves.
| Level | Definition | Typical target |
|---|---|---|
| Critical | Business stopped — no email, site down, no access to core systems | Response under 1 hour, work continuous |
| High | Significant impairment with no workaround | Response 4 hours, resolution same day |
| Medium | Impairment with a workaround available | Next business day |
| Low | Requests, questions, minor issues | Within a few business days |
The important part is agreeing what counts as critical for your business. For an online retailer, a broken checkout is critical. For a consultancy, email failure is. A generic definition written by the provider will not reflect either.
What Should Be Included
A maintenance contract that only covers reacting to failures is an insurance policy, not maintenance. Proper maintenance is mostly preventive:
- Patching on a schedule — operating systems, applications and dependencies, with a stated cadence
- Backup verification — not just that backups run, but periodic test restores. Ask specifically whether restores are tested and how often, because this is where most contracts are silent and most disasters occur
- Monitoring with defined thresholds — disk, memory, uptime, certificate expiry, and who receives the alerts
- Documentation kept current — what runs where, how to access it, how to recover it
- A periodic review — quarterly is reasonable: what broke, what is ageing, what needs budgeting for
That preventive half is what separates maintenance from repair. The specifics of what good practice looks like are covered in our piece on uptime, backups and monitoring.
The Exclusions That Cause Disputes
Read this section first. It is where the disagreements live.
- Third-party software. If the provider supports the server but not the application running on it, who fixes the application?
- Hardware. Labour is usually included, parts usually are not. Confirm which.
- Out-of-hours work. Frequently billed separately even under a contract. Know the rate before you need it at 2am.
- Project work. Migrations, upgrades and new deployments are typically outside maintenance. Where the line sits is worth agreeing explicitly.
- User error and self-inflicted damage. Reasonable to exclude, but the definition should be specific rather than open-ended.
- Anything undocumented or unsupported. Providers often exclude systems they did not build or cannot see. If you have a legacy system, get it named in the contract one way or the other.
Access, Credentials and the Exit
Three clauses that seem procedural and become critical:
Who holds the credentials. The business must retain ultimate ownership of its domains, hosting, DNS and administrative accounts. A provider holding them in their own name is a hostage situation waiting to happen, regardless of how good the relationship is today.
What happens to documentation at termination. The contract should require handover of complete, current documentation on exit, within a stated period. Without this clause, leaving a provider means rediscovering your own infrastructure.
Notice period and transition support. Thirty days notice with no transition obligation leaves you scrambling. A reasonable contract includes some support for the handover, because the provider knows things the successor will need.
Questions Worth Asking Before Signing
- What are the resolution targets by severity, not just response times?
- How often are backup restores actually tested, and will you show me a report?
- Who is my point of contact, and what happens when they are on holiday?
- What is specifically excluded, and what does out-of-scope work cost?
- What monitoring is in place, what are the thresholds, and who is alerted?
- If we leave, what do we get, and how quickly?
- Can I see an example of the quarterly review you provide?
The answers matter less than the willingness to answer. A provider who has these documented already is a provider who has done this properly before.
Pricing Models and Their Incentives
Every pricing model creates an incentive, and it is worth knowing which way yours points.
Fixed monthly fee aligns interests well — the provider profits by preventing problems rather than by fixing them. Predictable for budgeting. The risk is scope creep in the provider’s favour if boundaries are vague.
Hourly, as needed means you pay for what you use, but the provider earns more when things break. Prevention has no commercial reward. Suitable for stable environments with low support needs.
Blocks of prepaid hours sit between the two. Watch the expiry terms — hours that lapse unused are a price increase by another name.
For most businesses the fixed fee is the better structure, precisely because it puts the provider on the same side as you regarding uptime.
Frequently Asked Questions
Is a maintenance contract worth it for a small business?
If the business stops when IT stops, yes. The calculation is straightforward: compare the contract cost against a day of lost operation plus emergency rates. For most businesses the contract is cheaper than one serious incident.
Can I keep an internal person and still have a contract?
Commonly the best arrangement. Internal staff handle day-to-day user support; the contract covers infrastructure, out-of-hours cover and specialist work. Define the boundary explicitly so neither side assumes the other is handling something.
What if the provider misses their targets?
A serious contract includes remedies — service credits, escalation, or termination rights after repeated failures. Without remedies the targets are aspirational.
How long should the contract term be?
Twelve months with a reasonable notice period is standard and fair. Multi-year terms should come with meaningful price protection; otherwise the length benefits only the provider.
Should the provider host our systems too?
It simplifies accountability — one party owns the whole stack. It also concentrates risk, and makes leaving harder. If you do combine them, be especially careful about the credential ownership and exit clauses.
What is the biggest red flag?
Reluctance to put resolution targets and restore testing in writing. Both are ordinary commitments for a competent provider. Hesitation usually means they are not currently doing either.
The Bottom Line
A good IT maintenance contract makes the split of responsibility unambiguous before anything goes wrong. It specifies resolution as well as response, it includes preventive work rather than only repairs, it names what is excluded, and it lets you leave with your own documentation.
Read the exclusions first. That is where the contract tells you what it really is.
Our IT maintenance and server administration services are built around the preventive half, including the restore tests that most contracts leave unmentioned. For the reactive side, our computer repair team covers the hardware that no monitoring system can save.