MSA vs SOW vs SLA: what each MSP contract does, and when you need it
MSA vs SOW vs SLA: what each MSP contract does, and when you need it
Most disputes between an MSP and a client are not about whether work happened. They are about which document the work belonged to. The client points at a service-level promise. The MSP points at a scope list that never mentioned the thing the client now wants for free. Both are reading from real paperwork. The problem is that the paperwork was never sorted into the right three buckets.
Those buckets are the MSA, the SOW, and the SLA. They are not three names for the same contract, and they are not interchangeable. Each one answers a different question, and when you collapse them into a single ten-page document, you lose the ability to change one without renegotiating all of it.
Here is the short version, then the long one.
Quick definitions
Master Service Agreement (MSA). The MSA is the rulebook for the entire relationship. It sets the legal and commercial terms that apply no matter what work you do: liability limits, indemnification, payment terms, confidentiality, data handling, termination rights, dispute resolution, intellectual property ownership. You sign it once. It governs everything that comes after.
Statement of Work (SOW). The SOW is the specific job. It defines what you are actually delivering for this client: which services, which devices or users, what is explicitly out of scope, the change-order process, acceptance criteria, and the price. A single MSA can have many SOWs hanging off it, one per engagement or per service line.
Service Level Agreement (SLA). The SLA is the set of measurable promises. Response time, resolution time, uptime targets, hours of coverage, escalation paths, and what happens (credits, remedies) when you miss a target. The SLA puts numbers on the commitments the SOW describes.
If you remember nothing else: the MSA sets the rules, the SOW defines the work, the SLA promises the numbers.
How they nest
The cleanest way to think about it is layers, from broadest to most specific.
The MSA sits at the top. It is the umbrella. Everything below it inherits its terms unless a lower document deliberately overrides them.
The SOW sits underneath the MSA and points back to it. A well-drafted SOW says, in effect, "this work is governed by the MSA dated such-and-such." That one sentence pulls in every liability cap and payment term you already negotiated, so you do not re-argue them per project.
The SLA usually lives inside the SOW, or as an attached exhibit referenced by it. It applies to the specific services that SOW covers. A monitoring SOW and a project-based migration SOW can carry very different SLAs even though both sit under the same MSA.
This nesting is the whole point. When a client wants to add a new service line next quarter, you write a new SOW. You do not touch the MSA. When you tighten your uptime target or add a same-day response tier, you revise the SLA exhibit. You do not reopen the master agreement. Separation of concerns, applied to paperwork.
Comparison table
| MSA | SOW | SLA | |
|---|---|---|---|
| Answers | What are the rules of this relationship? | What work are we doing, and for what price? | What performance do we promise, and what if we miss? |
| Scope | The entire relationship | One engagement or service line | The services in that SOW |
| Typical contents | Liability, indemnity, IP, confidentiality, payment terms, termination, governing law | Services, deliverables, managed units (devices/users), exclusions, change orders, acceptance, fees | Response and resolution times, uptime targets, coverage hours, escalation, credits/remedies |
| How often signed | Once, then amended rarely | Once per engagement; many per MSA | Usually bundled with or attached to a SOW |
| Changes when | Legal or commercial terms shift | New work, new pricing, new scope | Performance targets or remedies change |
| Lifespan | Long, often multi-year | Tied to the engagement | Tied to its SOW |
When each one is required
The honest answer is that none of these are legally mandatory in the abstract. A handshake can form a binding contract. But "can form" and "should rely on" are very different things, and for an MSP the practical answers are clear.
You need an MSA the moment you have an ongoing relationship. Recurring managed services, anything multi-month, anything where you are holding the client's data or accessing their systems on a continuing basis. The MSA is where your liability cap lives. Operating without one means every project re-litigates the same risk terms, and a single bad engagement can expose you with no agreed ceiling on damages. Sign the MSA first, before the first device is onboarded.
You need a SOW for every distinct piece of work. This is the document that wins scope-creep arguments, because it is the one that says, in writing, what you are and are not doing. One-off projects get their own SOW. New service lines added to an existing client get their own SOW under the existing MSA. If a client asks for something and you cannot point to where it sits in a signed SOW, you are about to do unpaid work or have an awkward conversation. Probably both.
You need an SLA wherever you make a measurable promise. Managed services with monitoring and a help desk live or die on response and uptime commitments, so they need a real SLA. A short fixed-scope project (migrate a mailbox, stand up a firewall) may not need one at all, because there is no ongoing performance to measure. Do not bolt an uptime SLA onto a one-week project just because the template had a field for it.
A common and reasonable setup for a managed-services client is one MSA, one SOW per service line, and an SLA exhibit attached to each recurring SOW. Templating that structure once, so every new client starts from the same shape, is exactly the kind of repeatable contracting our MSP contract templates are built for.
Where NDA, AUP, and DPA fit
Three more acronyms turn up constantly, and they confuse people because they are not part of the MSA-SOW-SLA hierarchy. They are specialized companions that attach where they are relevant.
NDA (Non-Disclosure Agreement). Confidentiality. A standalone NDA makes sense early, during sales conversations or a discovery assessment, before you have an MSA in place and before either side has committed to anything. Once the MSA is signed with a confidentiality section, a separate NDA is usually redundant, because folding confidentiality into the MSA is the cleaner approach for an ongoing client.
AUP (Acceptable Use Policy). The rules for how the client's people may use the services and systems you manage. What is prohibited, what triggers suspension, who is responsible for end-user behavior. It protects you from being blamed for what a client's employee does. The AUP typically rides along as an attachment to the MSA or the SOW and is referenced by it.
DPA (Data Processing Agreement). This is the one with real legal teeth, and it is not optional when it applies. If you handle personal data on a client's behalf, you are acting as a data processor, and data-protection law requires a written agreement governing that processing. Under the EU and UK GDPR, Article 28 spells out the specific terms that contract must contain: processing only on the controller's documented instructions, confidentiality, security measures, rules for sub-processors, assistance with data-subject rights, breach notification, and what happens to the data at the end (GDPR Article 28, ICO guidance on required contract terms). Many MSPs fold a DPA into the MSA or attach it as an exhibit. If you serve clients with European data subjects, treat the DPA as required, not nice-to-have. If your clients fall under comparable data-protection laws elsewhere (CCPA and CPRA in California, for example), check whether a written processing agreement is similarly required, because the specifics vary by jurisdiction. Either way, have a lawyer confirm it covers what you actually do with the data.
A quick map: NDA covers secrets, AUP covers behavior, DPA covers personal data. They plug into the framework rather than replacing any part of it.
A note on getting this right
XClause is software for building, sending, signing, and tracking these documents. It is not a law firm and does not give legal advice. The structure above reflects how MSP agreements are commonly organized, but your liability caps, your DPA, and your governing-law choices are decisions to make with counsel who knows your jurisdiction and your clients. Get the legal substance reviewed once, then make the structure repeatable.
The repeatability is where the day-to-day payoff lives. When your MSA, SOW, and SLA are separate, versioned documents instead of one tangled file, you can update one layer without disturbing the others, see at a glance which client signed which version, and rarely lose an argument because the work fell between two documents. That is the difference good contract management makes: not fancier paperwork, just paperwork sorted so each document has a clear job.
If you want the line-item view of what belongs inside each of these documents, the next stop is the clause-by-clause MSP contract checklist. Sort your documents into the right three buckets first, then make each bucket complete.