Do I really need both an MSA and an SOW, or can one document cover it?

You can put everything in one document, but separating them is cleaner. The MSA holds the terms that stay constant (liability, payment, termination), and the SOW holds the client-specific scope and price. That way you sign the MSA once and hang new or revised SOWs off it without renegotiating the legal terms every time.

When does an MSP need a BAA?

You likely need a Business Associate Agreement whenever a client handles protected health information and you have access to systems that store or transmit it. Medical, dental, and healthcare-adjacent clients usually trigger it. If you're unsure whether a client counts, ask your attorney before onboarding, since the BAA is required under HIPAA and not optional.

Should all the documents be signed before onboarding starts?

Ideally yes. Signing after work has already begun creates a gap where it's unclear which terms apply and gives up your leverage. The cleaner practice is to have the MSA, SOW, SLA, any BAA, and access authorization countersigned before the first credential is created.

Client onboarding paperwork: the contract stack every new MSP engagement needs

Q: What's the difference between response time and resolution time in an SLA?

Response time is how fast you acknowledge and start working an issue, which you control. Resolution time is how long until it's fixed, which often depends on vendors and factors outside your hands. Committing to a specific response time and using best-effort language on resolution keeps you from promising outcomes you can't guarantee.

A new MSP client needs more than a signed proposal before you start work. The stack is usually five or six documents: a Master Services Agreement, an SLA, a Statement of Work, an Acceptable Use Policy, a Business Associate Agreement if any health data is involved, and a signed authorization to access their systems. Get those in place and countersigned before onboarding day, and most of the fights that blow up in month four never happen.

I've seen too many MSPs onboard on a handshake and a one-page quote, then discover during an incident that nobody agreed on who pays for after-hours work or what "response time" actually means. The paperwork is boring. It's also the difference between a clean invoice and a client who won't pay because "that wasn't in scope."

This is general information, not legal advice. Use it to figure out what to look for and what to ask your own attorney, not as a substitute for one reviewing your specific agreements.

Why the "just send the MSA" approach fails

An MSA on its own is a frame with no picture in it. It says the two companies will do business and sets the legal terms. It usually doesn't say what you're actually delivering, how fast, or for how much. When a client escalates, the MSA won't answer the question they're asking. The SOW and SLA will.

The other failure is timing. If any of these documents get signed after you've already started work, you've given up leverage and created a gap where nobody's sure which terms apply. Everything should be countersigned before the first credential is created.

The core stack, document by document

Master Services Agreement (MSA)

The MSA is the umbrella. It covers the terms that don't change client to client: payment terms, liability caps, indemnification, termination, dispute resolution, and how you handle their data. You sign it once, then hang individual SOWs off it.

Clauses to read twice:

Limitation of liability. A common cap is fees paid in the prior 12 months. If yours is uncapped or set at some huge multiple, that's real exposure. Look at whether the cap has carve-outs (gross negligence, data breach, IP claims) that swallow the rule.
Termination for convenience. How many days notice, 30 or 60 or 90? And does the client owe anything on early exit? A month-to-month client who can leave with 30 days notice is a very different business than one locked into a term.
Auto-renewal. Note the renewal term and the notice window to cancel. A 12-month auto-renew with a 60-day cancellation notice means the client (or you) has to act well before the anniversary.

Service Level Agreement (SLA)

The SLA is where "we'll take good care of you" becomes numbers. Response times by priority, hours of coverage, uptime targets, and what happens when you miss.

Watch the difference between response time and resolution time. Promising a 15-minute response to a P1 is defensible. Promising a 15-minute resolution is a trap, because you can't control how long a vendor's cloud outage lasts. Most well-drafted SLAs commit to response and use best-effort language on resolution.

If you offer service credits for missed targets, define them tightly. A credit of 5 percent of monthly recurring for a missed P1 SLA is normal. An open-ended "client may claim damages" clause is not something you want in a document you drafted.

Statement of Work (SOW)

The SOW is the picture in the frame. It lists exactly what's included: number of endpoints, servers, users, which sites, what's monitored, what's patched, backup retention, and the monthly price. It's also where you spell out what's not included, because scope creep lives in the gap between "IT support" and a specific list.

Two lines that save arguments later:

A per-unit price so adds and drops are automatic. "$95 per user per month, billed monthly, adjusted quarterly for headcount." Now onboarding a new hire isn't a negotiation.
An out-of-scope rate. "Project work and anything outside the listed services is billed at $175/hour with prior written approval." When the client asks you to migrate a file server that was never in the managed plan, you have a clean answer.

Acceptable Use Policy (AUP)

The AUP sets the rules for how the client's people use the systems you manage. It covers things like not sharing admin credentials, not installing unapproved software, and reporting suspected phishing. It matters for security, and it matters for blame. When a user clicks a link and you get pulled into an incident, an AUP that the client agreed to shows the boundary of what you controlled.

Business Associate Agreement (BAA)

If the client touches protected health data, a medical office, a dental practice, a billing company, you likely need a BAA under HIPAA. This isn't optional and it isn't a formality. The BAA defines your obligations as a business associate handling their data, including breach notification timelines and safeguards. If you're not sure whether a client triggers it, that's a question for your attorney before onboarding, not after.

Authorization to access and letter of agency

You need written permission to touch their systems, and often a Letter of Agency (LOA) so you can act on their behalf with third parties: their ISP, their phone carrier, their domain registrar. Without an LOA, the carrier won't talk to you when a circuit goes down, and you'll be stuck reading a hold script while the client loses money.

Client onboarding paperwork: what actually needs to be signed before day one

Here's the short version of the stack, in the order I'd want it signed:

MSA signed by both companies.
SOW attached to the MSA, with the specific scope and price.
SLA referenced by the SOW.
AUP acknowledged (client circulates it to their staff).
BAA if health data is in play.
Access authorization / LOA so you can legally do the work.

A few more that come up depending on the client:

Data Processing Agreement (DPA) if privacy laws like GDPR or a state privacy act apply to their data.
Non-disclosure agreement, though a good MSA usually has confidentiality baked in and a standalone NDA becomes redundant.
Payment authorization (ACH or card on file), so you're not chasing invoices at net 30.

The clauses that bite MSPs specifically

A few terms show up in MSP contracts that owners sign without reading, then regret.

Data ownership and return on exit. When the relationship ends, what do you owe the client and in what format? If your agreement is silent, you can end up in a standoff over documentation and backups. Look for a clause that says client data is returned in a usable format within a set number of days, and that you can charge for extended transition help.

Indemnification direction. Read carefully which way it runs. Mutual indemnification is common. A one-sided clause where you indemnify the client for everything, including their own users' mistakes, is worth flagging to your lawyer.

Insurance requirements. Enterprise clients often require you to carry cyber liability and E&O at specific limits, name them as additional insured, and provide a certificate. If the contract requires $2M in cyber coverage and you carry $1M, you're in breach on day one. Check the numbers against your actual policy.

Third-party and vendor liability. You resell and manage software you didn't write. If a vendor's product causes an outage, your contract should make clear you're not the guarantor of every tool in the stack.

Make the stack repeatable

The point of a stack is that you're not drafting from scratch every time. Build template versions of each document with your standard terms, then change only the SOW and SLA numbers per client. Version them, store the signed copies where you can find them during an incident (not in one person's inbox), and track renewal and cancellation dates so an auto-renew never surprises you.

The MSPs who handle this well treat contracts like any other managed asset: templated, versioned, and monitored. The ones who don't find out what their agreement says at the worst possible moment, usually while a client is threatening to leave and refusing to pay the final invoice.

Have your attorney review your base templates once. After that, onboarding is filling in blanks, not reinventing the paperwork every time someone signs.