What is the difference between break-fix and managed IT support?

Break-fix support bills you each time something goes wrong, usually at an hourly rate, and the provider has no obligation to prevent problems. Managed support charges a flat monthly fee to monitor, maintain, and fix your systems, which aligns the provider with keeping things running. A contract should state clearly which model applies, because it changes who pays when a server fails at 2 a.m.

What response times should an IT support contract include?

Tie response times to severity. A common structure is one hour for critical outages that stop the business, four hours for high-priority issues affecting several users, and one business day for routine requests. Distinguish response time (when the provider acknowledges the ticket) from resolution time (when it is fixed), because providers can guarantee the first but rarely the second.

Should an IT support contract cover after-hours and emergency work?

Yes. Spell out the supported hours, what counts as an emergency, and the rate for work outside business hours. Many disputes start when a client assumes 24/7 coverage and the provider assumed 8-to-5. If you need overnight or weekend coverage, name it and price it in the agreement.

Who is liable if an IT provider causes data loss?

That depends entirely on the contract. Most providers cap their liability at the fees paid over the prior few months and exclude consequential damages like lost revenue. As a client, push for a backup and data-integrity obligation and confirm the provider carries errors-and-omissions and cyber-liability insurance, since a liability cap is only useful if the provider can actually pay it.

Can an IT support contract auto-renew?

Many do, on a month-to-month or annual basis. Auto-renewal is fine as long as the notice period to cancel is reasonable (30 to 60 days is typical) and the renewal terms, including any price increase, are stated up front. Watch for clauses that lock you in for another full year unless you cancel months in advance.

IT Support Contract Template: How to Write an IT Services Agreement

A guide to writing an IT support contract. Covers scope, SLA response times, pricing models, data security, exclusions, and common mistakes to avoid.

An IT support contract is the document that decides who fixes the network when it goes down, how fast, and who pays for it. Get it right and a small business runs for years on a predictable monthly fee with few surprises. Get it wrong and the first real outage turns into an argument about scope, hourly rates, and whether overnight work was ever covered.

This guide walks through how to write an IT support contract that protects both sides: what to put in the scope, how to structure response-time commitments, which pricing model fits which client, and the clauses that quietly prevent most billing fights before they start.

What an IT Support Contract Actually Does

An IT support contract (also called an IT services agreement, a managed services agreement, or simply a support agreement) is a contract between a technology provider and a client that defines the services, the service levels, the price, and the rules of the relationship. It sits in the same family as a managed services agreement and often borrows structure from a broader master service agreement, but it is narrower: its job is to keep computers, networks, and software working.

The core questions a good agreement answers are simple to ask and easy to get wrong:

What systems are covered, and what is explicitly not?
How fast does the provider respond, and to what?
Is this a flat monthly fee or pay-per-incident?
What happens to the client's data, and who is liable if it is lost?
How does either party get out?

Everything below maps back to one of those questions.

Choose a Pricing Model First

Pricing drives the rest of the contract, so decide on it before drafting anything else. There are three common models, and mixing them up is where most disagreements begin.

Break-Fix (Hourly)

The client calls when something breaks and pays an hourly rate to fix it. The provider has no duty to monitor or prevent problems. This suits very small offices with simple needs, but it puts the provider and client on opposite sides of every incident: the provider earns more when things break.

If you use this model, the contract should state the hourly rate, the minimum billing increment (15 or 30 minutes is common), travel charges, and whether there is a higher rate for emergency or after-hours work.

Managed Services (Flat Monthly Fee)

The provider charges a fixed monthly fee per user, per device, or per site to monitor, maintain, patch, and support everything in scope. This is the dominant model for ongoing IT support because it aligns incentives: the provider keeps systems healthy to avoid being called.

A flat-fee agreement needs a tight scope and a clear list of what counts as in-scope support versus a billable project. Without that boundary, every large request becomes a negotiation.

Block Hours (Prepaid)

The client buys a block of hours up front (say, 20 hours) and draws them down as needed. It is a middle ground: cheaper per hour than ad-hoc break-fix, but without the full coverage of a managed plan. State whether unused hours roll over, when they expire, and the rate once the block runs out.

Defining the Scope of Services

Scope is the single most disputed part of any IT contract. Be specific. A scope that says "general IT support" invites the client to assume everything is covered and the provider to argue almost nothing is.

List the covered services concretely:

Help desk and end-user support for a defined number of users
Monitoring of servers, network devices, and endpoints
Patch management and operating-system updates
Antivirus and endpoint security management
Backup management and periodic restore testing
Network administration: firewalls, switches, Wi-Fi, VPN
Vendor coordination with ISPs and software vendors on the client's behalf

Then list the covered assets by name or category: how many workstations, how many servers, which locations, which cloud platforms. If a device is not on the list, it is not covered.

Spell Out Exclusions

A scope section is only half complete without exclusions. Common carve-outs that should be billed separately or not at all:

Major projects: server migrations, office moves, new-site buildouts
Hardware and software purchases (the cost of the equipment itself)
Support for personal devices not enrolled in management
Cabling and physical infrastructure
Recovery from issues the client caused by ignoring the provider's advice

Naming exclusions is not adversarial. It is what lets the provider quote a low monthly fee, because both sides know where the line is.

Service Levels and Response Times

This is the heart of an IT services agreement and the part clients read most closely. A service-level commitment turns a vague promise of "good support" into something measurable. If you want a deeper treatment of this section on its own, the service-level agreement guide covers it in detail; here is what an IT support contract specifically needs.

Tie Response Times to Severity

Not every ticket deserves an emergency response, and not every emergency can wait a day. Define severity levels and attach a target response time to each:

Critical (P1): a full outage that stops the business, such as a server down, no internet, or ransomware. Respond within 1 hour and work continuously until it is resolved.
High (P2): a major issue affecting several users but with a workaround. Respond within 4 business hours.
Medium (P3): a single-user problem or a degraded service. Respond within 1 business day.
Low (P4): routine requests, new-user setup, and questions. Respond within 2 business days.

Separate Response From Resolution

The most important distinction in this section: response time is when the provider acknowledges and begins work; resolution time is when the issue is fixed. A provider can credibly promise the first. The second often depends on third parties, like an ISP or a software vendor, so most contracts commit to response times and treat resolution as a best-effort target. State this plainly so a client never reads a one-hour response guarantee as a one-hour fix guarantee.

Define Supported Hours and Uptime

Say exactly when support is available (for example, 8 a.m. to 6 p.m. local time, Monday through Friday, excluding holidays) and what after-hours coverage costs. If the provider guarantees infrastructure uptime, state the percentage, how it is measured, and what gets excluded from the calculation, such as scheduled maintenance windows and client-caused outages.

Data Security and Confidentiality

An IT provider holds the keys to everything: admin credentials, customer databases, financial records. The contract has to address that access directly.

Include obligations covering:

Confidentiality of all client data the provider can access. For sensitive engagements, pair the support contract with a standalone non-disclosure agreement.
Data handling: how backups are stored, encrypted, and tested, and where data physically lives if that matters for compliance.
Regulatory compliance: if the client handles health, payment-card, or EU personal data, the contract should reference HIPAA, PCI-DSS, or GDPR duties and which party is responsible for what.
Breach notification: how quickly the provider must tell the client about a security incident.
Credential return: a duty to hand back all admin access, documentation, and data on termination and to delete copies afterward.

Liability, Insurance, and Indemnification

This is where the provider protects itself and where a careful client pushes back.

Most providers cap their total liability at the fees paid over a recent period (commonly the prior 3 to 12 months) and exclude consequential damages, meaning they will not pay for the client's lost revenue, lost profits, or reputational harm from an outage. That is standard and reasonable for a small-margin service business.

A client's leverage is insurance and a backup duty. Require the provider to carry errors-and-omissions (professional liability) and cyber-liability coverage at a stated minimum, and provide a certificate of insurance. A liability cap means little if the provider cannot pay it; insurance is what makes the cap real. Pair that with an explicit obligation to maintain working backups, because the cheapest protection against catastrophic data loss is a restore that actually works.

Term, Renewal, and Termination

Decide how long the relationship lasts and how either side exits.

Initial term: month-to-month, one year, or longer. Longer terms usually come with a lower monthly rate.
Renewal: many IT contracts auto-renew. That is fine if the cancellation notice period is reasonable (30 to 60 days) and any renewal price increase is disclosed in advance.
Termination for convenience: how much notice either party must give to walk away without cause.
Termination for cause: what counts as a material breach (non-payment, repeated SLA failures) and how long the breaching party has to cure it.
Offboarding: a transition-assistance clause requiring the provider to hand over documentation, credentials, and configurations so the client is not held hostage at the end. This is one of the most overlooked clauses, and the one clients most regret omitting.

How to Write an IT Support Contract: Step by Step

Step 1: Identify the parties. Full legal names, entity types, and addresses for both the provider and the client.

Step 2: Pick the pricing model. Break-fix, managed flat fee, or block hours. State the price, billing cycle, and what triggers extra charges.

Step 3: Define the scope. List covered services and covered assets by name. Add an exclusions list for projects, hardware, and out-of-scope work.

Step 4: Set the service levels. Severity tiers, response times per tier, supported hours, after-hours rates, and any uptime commitment.

Step 5: Address data and security. Confidentiality, backups, compliance obligations, breach notification, and credential return.

Step 6: Allocate risk. Liability cap, exclusion of consequential damages, indemnification, and required insurance.

Step 7: Set the term and exit. Initial term, renewal, notice periods, termination for cause and convenience, and offboarding duties.

Step 8: Add the boilerplate. Governing law, dispute resolution, assignment, and signatures from people authorized to bind each party.

Common Mistakes to Avoid

Leaving scope vague. "All IT support as needed" is not a scope. It guarantees a future argument the moment a large request lands.

Confusing response time with resolution time. Promising to fix every issue within an hour is a commitment no honest provider can keep. Commit to response; treat resolution as best-effort.

Ignoring after-hours coverage. If the supported hours are not written down, the client will assume nights and weekends are included and the provider will assume they are not.

Skipping the offboarding clause. Without a transition-assistance duty, a client leaving a bad provider can be stuck waiting for credentials and documentation that never come.

No insurance requirement. A liability cap is meaningless if the provider cannot pay. Require E&O and cyber-liability coverage and ask for proof.

Auto-renewal with a long lock-in. A renewal that re-commits the client for a full year unless they cancel 90 days out is a trap. Keep notice periods proportionate.

Related guides

Generate Your IT Support Contract with Contractable

A solid IT support contract is mostly about being specific: clear scope, severity-tiered response times, the right pricing model, and clean exit terms. Drafting all of that from a blank page is slow, and copying a generic template usually leaves the gaps that cause disputes. Contractable builds a customized IT services agreement in seconds, with the scope, service levels, and risk terms that fit your engagement, so both provider and client know exactly what they signed up for.