Your MSP SLA Has No Client Obligations Section. That's a Liability Problem.
Most MSP SLAs are written like the client is the only party worth protecting.
They define response times, escalation paths, uptime terms, remediation steps, and all the ways a client can hold the MSP accountable. Fine. Clients deserve clear commitments.
But the document usually goes quiet when the client causes the problem.
A user spins up a server you never knew existed. A manager approves a firewall change without telling you. A critical MFA recommendation sits ignored for six months. An admin leaves, but nobody tells the MSP to revoke access.
Then the incident hits. The client pulls out the SLA. It says what you owe them. It says almost nothing about what they owed you.
That is the MSP SLA client obligations problem. The fix is not a 40-page contract rewrite. It is usually a one-page addendum that makes the responsibility split explicit before the next bad night.
What are MSP SLA client obligations?
MSP SLA client obligations are the responsibilities the client must meet so the MSP can deliver the service safely. They usually cover change notification, access, approvals, accepted risk, and systems outside the agreed scope.
An SLA without client obligations creates a one-way accountability model. The MSP is measured. The client is assumed to cooperate. That assumption is where margin and liability go to die.
Scopable fits this problem because scope discipline starts before the SLA. If your quote does not define what is managed, what is excluded, and what the client must approve, the SLA inherits the same fog.
The standard MSP SLA structure has one big blind spot
Most MSP SLAs cover the same operational promises:
| SLA section | What it usually protects | What often gets missed |
|---|---|---|
| Response time | Client gets acknowledgment within a defined window | Client must provide access, context, and approval |
| Severity tiers | Client knows what counts as critical | Client cannot label every inconvenience as an emergency |
| Coverage hours | Client knows when the clock runs | Client understands after-hours exceptions and cost |
| Uptime terms | Client sees availability commitments | MSP avoids promising uptime for systems it does not control |
| Escalation path | Client knows who gets involved | Client names who can make decisions on their side |
The missing piece is not complicated. It is the reverse side of the service promise.
If the MSP must respond within four hours, the client must provide working access. If the MSP must manage security risk, the client must acknowledge declined recommendations. If the MSP is accountable for managed systems, the client must tell the MSP when those systems change.
Otherwise, every client-side miss becomes your problem by default.
For the broader SLA structure, start with the MSP SLA template guide. This article focuses on the part most templates still underwrite badly: what clients owe back.
Three scenarios where the gap burns MSPs
1. The unsanctioned change
A client IT director approves a firewall rule change with a vendor. Nobody tells the MSP. A remote site breaks on Monday morning.
The client opens a critical ticket. The SLA says outages get urgent response. It does not say what happens when the outage was caused by a change the MSP never reviewed.
Now the MSP is in emergency mode, rebuilding context from scratch, defending response time, and absorbing labor that should have been billable change cleanup.
2. The ignored security recommendation
You flag a missing MFA policy in a QBR. The client says they will revisit it after budget season. Six months later, an account is compromised.
Everyone suddenly remembers that the MSP handles security. Nobody remembers the part where the client declined the fix.
If the SLA has no recommendation acknowledgment process, your evidence is whatever happens to be buried in a meeting note, ticket comment, or someone's memory. That is not good enough when blame starts getting expensive.
3. The stale credential problem
A client admin leaves. HR tells the department manager, but nobody tells the MSP. The account stays active for weeks.
If that account is used in an incident, the client will ask why you did not remove it. Your answer may be true: you were never notified.
But if the SLA does not require personnel-change notification, the argument becomes messier than it needed to be.
The three clauses that fix the asymmetry
This is practical guidance, not legal advice. Have your attorney review the final clause language before you send it to clients.
But operationally, three clauses solve most of the problem.
1. Client change notification requirement
This clause says the client must notify the MSP before changes that affect managed systems, access, vendors, software, credentials, infrastructure, or security controls.
Plain English version:
If you change something we manage without telling us, we are not responsible for the damage caused by that unannounced change.
The clause should define:
- Which systems and change types require notice
- How much notice the MSP needs
- Where notice must be sent
- What happens if emergency work is needed because notice was skipped
This is not about blocking the client from running their business. It is about making sure the MSP is not held liable for invisible changes.
2. Security recommendation acknowledgment
This clause covers declined or deferred recommendations. If the MSP recommends a security fix and the client says no, the client must acknowledge the residual risk in writing.
Plain English version:
If we tell you to fix a risk and you choose not to, that decision belongs to you.
Do not make this theatrical. You do not need a scary waiver for every minor item. Use it for meaningful risk decisions:
- MFA not deployed for privileged users
- Unsupported operating systems left in production
- Backup gaps accepted because of cost
- Endpoint protection exclusions requested by the client
- Admin access kept active after a staffing change
This also protects the client from vague MSP advice. A good acknowledgment should name the risk, the recommendation, the client decision, and the next review date.
3. Out-of-scope liability carveout
This clause says the MSP is not responsible for incidents caused by unmanaged systems, client-managed changes, undocumented assets, or approved deviations from recommended configuration.
Plain English version:
We are responsible for what is in scope. We are not responsible for systems, changes, or exceptions we were not hired to manage.
This clause matters because clients often treat proximity as responsibility. If you touch one part of the network, they assume you own the whole mess.
You do not.
The carveout should connect back to the scope document, quote, MSA, or statement of work. If a system is excluded, unmanaged, client-administered, or pending discovery, write that down before the incident.
The MSP scope of work template is useful here because exclusions belong in the commercial document too, not only in the legal wrapper.
Add the fix without reopening the whole MSA
The cleanest path is usually a one-page SLA addendum.
Use it as an exhibit attached to the existing MSA or SLA. Keep it operational. Do not turn it into a legal novella nobody reads.
A useful addendum should include:
- Client change notice. What the client must tell you before changing systems, access, vendors, or security settings.
- Approval owner. Who at the client can approve changes, exceptions, and risk acceptance.
- Declined recommendation process. How you document security or operational risks the client chooses not to fix.
- Access dependencies. What happens when the MSP cannot work because the client delays credentials, approvals, or site access.
- Out-of-scope carveout. What systems, actions, and exceptions are not covered by the managed services fee.
- Review cadence. When the addendum gets reviewed, usually renewal, onboarding, or after a major incident.
Good moments to introduce it:
- New client onboarding
- Contract renewal
- SLA annual review
- After a near-miss incident
- Before adding compliance, security, or vCIO advisory work
Do not surprise a client with it after an incident and pretend it was always obvious. Put it in before you need it.
Why this matters for quoting and margin
Client obligations are not only a legal hygiene issue. They are a margin issue.
When the agreement is silent, out-of-scope work gets dragged into the monthly fee. Emergency labor becomes relationship management. Security exceptions become your operational burden. Client delays become your SLA miss.
That is how MSPs end up with clients who look profitable in MRR and terrible in effective hourly rate.
The same discipline that protects the SLA protects the quote:
| Commercial question | SLA version | Quoting version |
|---|---|---|
| What are we responsible for? | Managed service scope | Included line items |
| What is excluded? | Liability carveout | Assumptions and exclusions |
| What does the client own? | Client obligations | Required client inputs |
| What happens when scope changes? | Change notification | Change order process |
| What risks did the client accept? | Recommendation acknowledgment | Declined option or deferred project |
If your quote does not define these things, your SLA has to clean up the mess later. It rarely does.
For the pricing side of this, read the MSP pricing and margin protection guide. For tool selection, the MSP quoting software comparison shows why quoting tools are only useful when scope is clear.
The practical checklist
Before your next renewal cycle, pull one active SLA and ask these questions:
- Does it list what the client must provide before the MSP can meet response obligations?
- Does it require notice for client-side changes that affect managed systems?
- Does it define who can approve exceptions and accepted risk?
- Does it document what happens when security recommendations are declined?
- Does it carve out unmanaged systems, undocumented assets, and client-managed changes?
- Does it connect back to the quote, SOW, or service scope?
- Does it tell the client when after-hours or emergency work becomes billable?
If the answer is no, add the one-page exhibit before the next client argument teaches the lesson for you.
The quiet part belongs in the contract
Managed services only works when both sides have obligations.
The MSP should respond on time, document work, escalate clearly, and deliver the services it sold. The client should provide access, communicate changes, approve decisions, and own the risks it chooses to accept.
That is not adversarial. It is honest.
The goal is not to make your SLA more hostile. The goal is to make every incident conversation shorter because the responsibility split is already written down.
If you are cleaning up client agreements, start with scope. Define what is managed, what is excluded, what the client owes back, and how accepted risk gets documented. If you want the quoting workflow to carry that context from assessment to roadmap to quote, join Scopable early access.
