What an MSP Scope of Work Should Actually Say

An MSP scope of work should say what is excluded, not just what is included. Inclusion lists are marketing and exclusion lists are operational. Every scope dispute in a managed services relationship traces back to a task both parties assumed the other one owned, and the exclusions page is the only document that prevents it.

I am Amelia S. Gagne, CEO of Kief Studio. We run managed operations, so this is written from inside the problem. The selection stage is how to evaluate a managed service provider, and the performance terms are in reading an MSP service level agreement.

Why does an MSP scope of work fail?

Not usually through bad faith. Through category language.

"Workstation support" is a category, not a scope. It covers the laptop that will not boot. Does it cover the workstation a contractor owns? The machine in the warehouse running vendor software nobody supports? The laptop of someone who left in March?

Each of those has a defensible answer. The problem is that both parties have a defensible answer and they are different ones, and neither discovers this until something breaks. The discovery happens at the worst moment because that is when someone finally needs the answer.

This is the mechanism behind client onboarding is where scope creep starts, seen from the buying side.

What belongs in the covered-assets section?

A count and a definition, not a category.

The scope should state how assets are counted, what happens when the count changes, and what the threshold for repricing is. A contract priced for 40 endpoints that silently absorbs 90 will be renegotiated, and it is better to know the trigger in advance than to receive the news as a surprise invoice.

Specifics worth naming:

• Endpoints, including whether personally owned and contractor devices count and whether they are supported at all.
• Servers and infrastructure, physical and virtual counted separately, because the effort differs.
• Cloud tenants and SaaS applications named individually. "Microsoft 365 support" and "we manage your SaaS" are different promises.
• Network equipment, including who owns firmware updates on hardware you bought before the engagement.
• Users, with a definition covering shared accounts, service accounts, and seasonal staff.

Service and machine accounts are the ones most often unaddressed, and they are the ones with standing privilege. The category deserves an explicit owner, which is the argument in non-human identity.

What should the exclusions page say?

This page is the reason to read the document. If the provider does not have one, ask them to write it, and treat their willingness as diagnostic.

Common exclusions that are legitimate and should be stated rather than discovered:

• Line-of-business application support. Your industry-specific software is usually supported by its own vendor. Whether the provider coordinates with that vendor, and whether coordination is billable, should be explicit.
• Projects versus support. Migrations, rollouts, and office moves are typically project work. The scope should define the line, because the line is where most surprise invoices originate.
• End-of-life equipment. Most providers will not warrant response times on unsupported hardware or operating systems. Fair, and it should come with a named inventory and a remediation timeline rather than an open exclusion.
• Data recovery beyond the backup system. Restoring from backup is in scope. Forensic recovery from a failed drive with no backup is a different service.
• Incident response beyond containment. This is the important one. Many agreements cover isolating a compromised machine and stop well short of forensic investigation, legal notification support, and negotiation. Those are separately priced and often carrier-panel-restricted, which is covered in why cyber insurance claims get denied.

What about security responsibilities?

Managed security is the fastest-growing segment of the category, and it is also where scope language is loosest. "We handle your security" can mean anything from patch deployment to a staffed detection function, and those differ by an order of magnitude in cost.

Ask the scope to distinguish:

• Patch management: which systems, on what cadence, with what exception process and what reporting.
• Endpoint detection: whether alerts are monitored by a human, during what hours, and what the response is outside those hours.
• Identity administration: who provisions and deprovisions, and how fast deprovisioning happens. Departure-day access removal is a common gap.
• Backup: what is backed up, retention, where copies sit, and critically who tests restores and how often. A backup nobody has restored is a hypothesis, which is the point of backing up a business against ransomware.
• Logging: what is collected, retained how long, and whether you can access it directly. Log access shapes every investigation.

The insurance link matters here. Your cyber application asks about endpoint coverage percentage and the date of the last restore test. If your provider owns those functions, they own the answers, and the scope should require them to supply the evidence on request. That connects to what a renewal application asks now.

What should the scope say about documentation?

That it exists, that it stays current, and that it belongs to you.

Documentation is the asset that decides whether a future transition is a project or a crisis. Network diagrams, configuration records, integration maps, and a credentials inventory should be produced during onboarding, maintained on a stated cadence, and delivered to you in a portable format.

A provider that keeps documentation only inside its own platform has created switching cost as a side effect, whether or not that was the intent. Ask for export rights in the scope rather than in the exit clause, so the artifact exists continuously rather than being assembled under duress. That is the operational half of technology vendor contract exit terms, and it is the same principle as institutional memory that survives turnover.

How do you keep the scope honest over time?

A scope document describes a state, and states change. New applications arrive, headcount moves, and someone stands up a system nobody told the provider about.

The mechanism that works is a quarterly review of the asset count and the exclusions list against reality, attached to an existing meeting so it actually happens. Providers generally welcome this, because unacknowledged scope growth is their problem too.

Left alone, the gap between documented and actual scope widens in one direction only. That is entropy, and the response is maintenance rather than better initial drafting. The same logic runs through automation maintenance is the job.

We publish developer tooling openly at kief.dev, and the managed operations model is at ltfi.ai. Brian Gagne handles the infrastructure and security architecture side, and briansgagne.com is the deeper technical read.

Related reading

• How to evaluate a managed service provider
• Response time is not resolution time
• Co-managed IT without splitting accountability
• What is included in managed hosting
• Client onboarding is where scope creep starts

Frequently Asked Questions

What should an MSP scope of work include?

A counted asset list with a repricing threshold, a written exclusions page, named security responsibilities broken into patching, detection, identity, backup, and logging, and documentation obligations including your right to export it. The exclusions page is the most useful section.

What is usually excluded from a managed services agreement?

Line-of-business application support, project work such as migrations and office moves, end-of-life hardware and operating systems, data recovery where no backup exists, and incident response beyond containment. All five are legitimate exclusions that should be stated rather than discovered.

Does an MSP handle incident response?

Often only containment. Forensic investigation, breach counsel, notification support, and negotiation are typically separate services, and your cyber insurer may require its own panel vendors for them. Confirm the boundary in the scope before an incident rather than during one.

Who owns the documentation an MSP produces?

It should be you, with export rights written into the scope rather than the exit clause. Documentation held only inside a provider's platform becomes switching cost whether or not that was intended.

How often should the scope be reviewed?

Quarterly, checking the asset count and exclusions against what is actually running. Attach it to a meeting that already exists. Undocumented scope growth is a problem for the provider as much as for the buyer.