It’s the Your Most Important Document, but You Probably Don’t Give It the Attention It Deserves

There are few documents more important to an MSP than its Master Services Agreement.

There are also few documents MSP owners spend less time thinking about.

The pattern is pretty common. Someone starts an MSP and needs a contract. They find one online, borrow one from another MSP, download a template from a peer group, or modify an agreement they used somewhere else.

Maybe an attorney reviews it.

Then the agreement starts getting signed and nobody thinks much about it again.

Five years later, almost everything about the MSP has changed.

The services have changed. The technology stack has changed. Cybersecurity has become a significant part of the offering. The MSP may now support regulated customers, rely heavily on cloud platforms, provide security monitoring, manage Microsoft 365, or offer services that didn't even exist when the agreement was written.

The MSA, meanwhile, still looks almost exactly the same.

That is a problem.

Your MSA Is Part of Your Operating Model

An MSA isn't just a legal document that gets pulled out when a customer relationship goes bad.

It defines how the relationship is supposed to work.

What are you responsible for? What is the customer responsible for? What happens when the customer refuses an important recommendation? What work is included in the monthly agreement and what generates an additional charge?

What happens when Microsoft, an internet provider, or another third party has an outage? Who owns documentation? How are price increases handled? What happens when the customer doesn't pay? What are your obligations when the relationship ends?

Those questions may seem theoretical when everything is going well.

They become very real when something goes wrong.

Don't Just Copy Another MSP's Agreement

There is nothing wrong with reviewing other agreements to understand how people approach them.

There is a lot wrong with assuming someone else's MSA is appropriate for your business.

You don't know why their language exists. You don't know their service model, insurance coverage, customer base, risk tolerance, or what state laws apply to them.

For that matter, you don't necessarily know whether their agreement is any good.

Your MSA should reflect how your MSP actually operates, and that requires input from both qualified legal counsel and the people running the business.

Your attorney understands contracts.

You understand what actually happens when a customer calls the service desk at 4:45 on a Friday afternoon.

You need both perspectives.

Customer Responsibilities Matter Too

MSP agreements tend to spend a great deal of time describing what the MSP will do.

They often spend far less time defining what the customer must do.

That is becoming increasingly important as cybersecurity responsibilities become more complicated.

What happens if the customer refuses MFA? What if they continue using unsupported hardware or software? What if they disable endpoint protection, reject a security recommendation, refuse a required upgrade, or won't provide information you need to support the environment properly?

What happens if they bring in another vendor that makes changes to systems you manage?

An MSP cannot accept responsibility for an environment while the customer retains the ability to undermine the controls required to manage it.

Shared responsibility needs to be more than something everyone talks about after an incident. It should be reflected in the agreement.

Be Clear About What Is Not Included

Ambiguity is expensive.

After-hours work, projects, moves, adds and changes, major upgrades, onsite work, unsupported applications, vendor coordination, cybersecurity incidents, restores, hardware replacement, and remediation work are just some of the areas that can create disagreement if the boundaries aren't clear.

The exact answer will vary by MSP.

What matters is that there is an answer.

Your agreement structure should make it reasonably easy for both sides to understand the difference between the managed service they are paying for every month and work that will generate an additional charge.

If your customer believes everything involving technology is included because they pay you a monthly fee, you are eventually going to have a problem.

Third Parties Need to Be Addressed

Modern MSPs rely on a long list of companies they do not control.

Microsoft. ISPs. Cloud providers. Security vendors. Backup platforms. Line-of-business applications. Distributors. Telecom providers.

Yet customers often experience all of those services as part of the relationship with the MSP.

Your agreement should recognize that reality without making you responsible for guaranteeing the performance of another company's platform.

It also needs to contemplate pricing. If Microsoft or another major vendor increases its price 15 percent, are you contractually stuck absorbing that increase until the customer's next renewal?

That is the kind of small contractual issue that can become a large financial issue when multiplied across hundreds or thousands of users.

Cybersecurity Has Changed the Contract

Many older MSP agreements were written when cybersecurity was a much smaller part of the managed service.

That world is gone.

MSPs need to be clear about what they are actually promising. Managed IT does not mean a guarantee that the customer will never experience a cyber incident.

The agreement should address the responsibilities of both parties, required controls, what happens when recommendations are declined, the customer's obligations during an incident, and what incident-response activities are included in the managed agreement.

This is also an area where your contract, cyber insurance, service delivery model, and actual security practices need to agree with each other.

Having strong contract language doesn't help much if your team operates completely differently in practice.

Understand Your Limitation of Liability

Most operators aren't excited about reading limitation-of-liability and indemnification provisions.

You should be.

Those sections may become some of the most important language in the entire agreement when something serious happens.

What damages could you potentially be responsible for? Is there a cap? Are there exceptions to that cap? What are you indemnifying the customer for? What are they indemnifying you for?

And does any of that line up with the insurance coverage you actually carry?

This is where competent counsel matters. You don't need to become an attorney, but you should understand in plain English what happens to your company under several realistic worst-case scenarios.

Don't Forget the End of the Relationship

MSPs spend enormous amounts of time thinking about onboarding.

They should spend more time thinking about offboarding.

What happens when the agreement ends? How long will you provide transition assistance? Is that work included or billable? What documentation will be provided? What happens to customer data and backups? When do licenses terminate? How and when are administrative credentials transferred?

Most importantly, at what point does your responsibility for the customer's environment end?

A difficult customer transition is the worst possible time to discover that neither side agrees on the answers.

A good MSA should make the offboarding process boring.

Review It Before You Need It

I think MSPs should formally review their MSA at least annually. For a company changing rapidly, every six months isn't unreasonable.

That doesn't mean rewriting the agreement twice a year. It means sitting down and asking whether the business has changed enough that the contract should change with it.

Have you introduced new services? Entered new states? Taken on more regulated customers? Changed your security requirements? Started using new third-party providers? Changed your pricing model? Learned something from a customer dispute, cyber incident, or difficult offboarding?

Those experiences should feed back into the agreement.

And don't make this a legal-only exercise. Have the people responsible for sales, service, security, account management, and operations periodically read the MSA.

Then ask what surprised them.

If your sales team is routinely promising things that aren't reflected in the agreement, you have a problem. If your service team thinks something is out of scope that the MSA says is included, you have a problem. If nobody knows what happens when a customer refuses an important security control, you have a problem.

The goal isn't to create the most aggressive contract your attorney can write.

The goal is to create a clear agreement that reflects how your MSP and your customers actually work together.

Because the worst time to discover what your MSA says is when you desperately need it.