What every MSP contract should include: a clause-by-clause checklist

The contract you grabbed from a forum three years ago is probably still the one you send to new clients. It has the wrong legal entity name on it, a liability cap that protects nobody, and an auto-renewal clause your account manager has never once enforced. Most MSP contracts are not written. They are inherited, copied, and quietly mutated until nobody on your team can say what they actually promise.

This is the checklist I wish more MSPs ran before they sent the next agreement out. Eleven clauses, what each one does in plain terms, and the specific way it tends to go wrong. Read it as a way to audit what you already have, not as a fill-in-the-blanks form.

One honest caveat up front: this is operational guidance from people who build contract software, not legal advice. XClause is software, not a law firm. Use it to spot gaps and have a sharper conversation with an attorney who knows your state and your client base, not as a substitute for one.

1. The parties

Name the actual legal entities. Not the trade name, not the founder's first name, the registered entity: "Acme IT Services LLC" and "Northgate Dental Group, P.C." If you signed as a sole proprietor two years ago and incorporated last spring, the contract still binds the old you, and that mismatch is exactly what a client's lawyer reaches for when they want out.

Get this wrong and everything downstream gets shaky. The wrong party means your limitation of liability might protect a company that no longer exists, and your invoices go to an entity that can argue it never agreed to anything.

2. Scope of services

Scope is where MSP contracts live or die. A vague scope ("provide IT support and maintenance as needed") is an open invitation for the client to assume everything is included and for your techs to do unpaid work because saying no feels rude.

Be concrete. List what you cover: which endpoints, which servers, which SaaS apps, how many users, what response model. Then list what you do not cover. Project work, hardware procurement, after-hours emergencies, third-party vendor coordination, cabling, and "that thing the office manager's nephew set up" all belong in an exclusions line so there is no debate later.

Most real scope detail belongs in a statement of work attached to the master agreement, not buried in the body of the contract itself. The master agreement sets the terms that never change; the SOW describes the specific engagement and can be reissued per client or per project without renegotiating everything. Our contract management workflow is built around exactly that nesting.

3. Term and renewal

State the start date, the length of the initial term, and what happens at the end. The clause that causes the most arguments is auto-renewal. If the agreement renews automatically, say so, say for how long, and say how many days of notice either side needs to give to stop it. Thirty days is common; sixty gives you more runway to react.

Worth saying plainly: a renewal clause you do not track is worse than no clause at all. If your contract auto-renews for twelve months unless cancelled sixty days out, and you have no system reminding you when that window opens, you will either trap a client who wanted to leave (bad relationship, possible legal fight) or let a renewal lapse and operate with no agreement at all (worse). The clause is only as good as the calendar behind it.

4. Fees and payment terms

Spell out what they pay, when, and what happens when they do not.

• The recurring fee and what unit it is tied to (per user, per device, per site, flat).
• The billing cycle and the due date.
• How and when fees change. An annual price-adjustment clause tied to a fixed percentage or an index saves you the awkward email every January.
• Late payment consequences: interest, a grace period, and your right to suspend services past a defined number of days due.
• How out-of-scope and project work gets quoted and approved before you do it.

That last point plugs revenue leaks. If your contract says any work outside the defined scope requires a written change order at your standard hourly rate, you have a clean basis to bill for the favors that otherwise pile up uncompensated.

5. Service levels (SLAs)

An SLA is a promise about how you respond, measured in time: response time by severity, target resolution windows, hours of coverage, and how those are measured. Be careful not to promise more than your tooling can prove. If you commit to a one-hour response on critical issues, you need a ticketing system that timestamps acknowledgment, or you have written yourself a liability you cannot defend.

Two things make an SLA fair to both sides. First, define severity levels precisely, because "critical" means something different to a client whose printer is down. Second, decide whether missing an SLA carries a remedy (a service credit, usually) or is just a target. Service credits are common and reasonable. Just make sure the credit is capped and is the client's sole remedy for a missed target, or a customer-service gesture becomes an open-ended damages claim.

6. Limitation of liability and indemnification

This is the clause that matters most when something goes badly wrong, and it is the one inherited templates butcher.

A limitation of liability cap puts a ceiling on what you can be sued for, usually tied to the fees paid over some recent window (the last twelve months is typical). Without a meaningful cap, a single bad incident, a ransomware event, a botched migration, can expose your entire business to a claim far larger than the account was ever worth. A cap is not a license to be sloppy. It just keeps your worst-case exposure tied to what the account is actually worth.

Indemnification decides who covers whom when a third party brings a claim. You generally want mutual indemnification: the client covers claims arising from their data or their misuse, you cover claims arising from your negligence. Watch for one-sided versions where you indemnify the client for everything and get nothing back. Pair this with a clause excluding indirect and consequential damages (lost profits, lost data value), which is standard and important.

Get an attorney on this clause specifically. The exact wording, the size of the cap, and which carve-outs survive it carry real legal weight that varies by jurisdiction, and this is not the place to trust a template you found online.

7. Data handling and the DPA

You touch your clients' data constantly: backups, email, endpoint monitoring, sometimes regulated records. The contract needs to say how you handle it. For clients in healthcare, finance, or anyone subject to a privacy regime, this often means a separate data processing addendum (DPA) or a business associate agreement under HIPAA.

The DPA covers what data you process, for what purpose, how it is secured, who your subprocessors are, where it lives, and what happens to it when the relationship ends. If a client ever has a breach, the first document their counsel asks for is the one defining your data obligations. Having it ready is both a sales advantage and a defense. You can point clients to how we handle data and security when they ask.

8. Termination

Define how the agreement ends and what happens after. Cover termination for convenience (either side leaves with notice), termination for cause (a material breach that goes unfixed after a cure period, commonly thirty days), and immediate termination for nonpayment.

Offboarding is the section that protects your reputation, and almost nobody writes it. Spell out what you return and when: data exports, documentation, admin credentials, license transfers. Decide whether offboarding assistance is included or billed as a project. An ugly exit with no defined handoff is how you end up in a dispute with a former client who is now telling everyone in town you held their data hostage.

9. Intellectual property

Decide who owns what. Configurations, scripts, documentation, automations, and runbooks you build during the engagement: do they belong to you or the client? There is no single right answer, but there is a wrong outcome, which is leaving it undefined.

A common and defensible position: the client owns their data and any deliverables they paid for as project work, you retain ownership of your proprietary tools, templates, and methods and grant them a license to use them while the contract is live. Whatever you choose, write it down. A client leaving who wants every script you ever wrote is a fight you do not want to have over a silent contract.

10. Acceptable use policy

An AUP defines what the client and their users may not do with the systems and access you provide, and it puts responsibility for misuse on the people committing it. If a client's employee uses your remote access tooling to do something illegal, or runs unlicensed software on a machine you manage, the AUP separates your liability from theirs.

It does not need to be long. Cover prohibited activities, compliance with applicable law, responsibility for end-user conduct, and your right to act if the policy is violated. Attach it as an exhibit so you can update it without reopening the whole agreement.

11. Signatures

A contract nobody signed is a draft. The signature block needs the right legal entity names, a named individual with actual authority to bind that entity, their title, and the date. A signature from the office manager who cannot bind the company is a hole an unhappy client can climb through later.

This is where execution matters as much as the words above it. A signed, dated, tamper-evident copy that both parties can produce on demand is worth more in a dispute than a beautifully drafted clause sitting in an unsigned Word file in someone's downloads folder. Capturing the signature, the consent, and the date in a way you can prove later is the whole point.

How to use this list

Print it. Pull your current standard agreement next to it. Go clause by clause and mark each one green (it is there and it is right), yellow (it is there but vague), or red (it is missing). In my experience most agreements come back with three or four reds and a fistful of yellows on the first pass, and the reds are almost always liability, data handling, and termination.

You do not have to start from a blank page. We maintain a set of MSP contract and SOW templates built around this structure, so you can adopt a clean baseline and adjust it with your attorney instead of rebuilding from a forum download.

One last reminder, because it matters: this checklist is a starting point for a better contract and a better conversation with a lawyer. It is not legal advice, and no template, ours included, replaces counsel who knows your jurisdiction and your clients. Use it to find the gaps. Then close them with someone licensed to tell you exactly how.