Client Onboarding Paperwork: The Contract Stack Every New MSP Client Needs

Most messy client situations at MSPs start the same way.

Work begins before the paperwork is finished.

The client is in a hurry. Sales wants to keep momentum. Someone says, “We’ll clean up the contract later.” Then six months pass, the scope has expanded, the invoice is disputed, and nobody can agree on what was originally included.

The problem usually is not bad service. It is bad documentation.

Getting the contract stack right is less exciting than a Friday go-live, but it is one of the most important parts of onboarding a new client. The right documents set expectations, protect your margins, and give both sides something clear to refer back to when questions come up.

This article covers the core documents most MSPs should have in place, what each one does, and which terms deserve extra attention.

This is general business information, not legal advice. Use it to understand what your agreements should address, then have your own attorney review your templates.

Why One Agreement Usually Is Not Enough

A lot of MSPs try to fit the entire relationship into one document.

That may feel simpler at first, but it usually creates more work later.

When your legal terms, pricing, service scope, response commitments, and onboarding details all live in one agreement, every client change can turn into a full contract revision.

Adding a location should not require reopening the entire legal relationship.

Changing the number of supported users should not require rewriting the limitation of liability clause.

Raising a per-user rate should not force both sides to renegotiate confidentiality and termination language.

A cleaner structure separates the relationship into layers.

The master agreement handles the legal relationship.

The statement of work handles the actual services, pricing, scope, exclusions, and service-level commitments.

Supporting documents handle access, security, acceptable use, and offboarding.

This structure makes agreements easier to manage, easier to update, and easier for the client to understand.

The Master Services Agreement

The Master Services Agreement, or MSA, is the legal foundation of the relationship.

It should cover the terms that apply across every service you provide to the client, regardless of which package, project, or support plan they purchase.

The MSA should not try to describe every endpoint, user, application, or support commitment. That belongs in the SOW.

Instead, the MSA should address the rules of the relationship.

Term and Termination

The agreement should state:

• How long the initial term lasts
• Whether the agreement renews automatically
• How much notice is required to cancel
• Whether early termination fees apply
• What happens when the relationship ends

Pay close attention to renewal notice windows.

A 60-day cancellation deadline is only useful if someone is actually tracking it. If your renewal process depends on a calendar reminder buried in one person’s inbox, it is going to fail eventually.

Limitation of Liability

This is one of the most important sections in the agreement.

A limitation of liability clause places a cap on the amount either party may be able to recover if something goes wrong. Many agreements tie that cap to fees paid over a defined period, such as the previous six or twelve months.

The exact language matters.

An agreement can appear to include a liability cap while still leaving large exceptions that make the cap less meaningful. Have your attorney review the exclusions, carve-outs, and wording carefully.

Payment Terms and Suspension Rights

The MSA should explain:

• When invoices are due
• Whether payments are made by ACH, credit card, or another method
• Whether late fees or interest apply
• What happens when an invoice is disputed
• When you may suspend services for nonpayment

The right to suspend service should be clear, but it should also include a reasonable notice process.

You do not want the first discussion about suspension to happen after the client is already past due.

Confidentiality

Confidentiality should work in both directions.

You will have access to the client’s systems, credentials, business processes, and data.

The client may also gain access to your internal documentation, pricing methods, tools, workflows, and intellectual property.

The agreement should explain what is considered confidential, how it must be protected, and which disclosures are allowed.

Data Handling and Security Responsibility

The MSA should define the broad responsibilities of each party.

That includes:

• The client’s responsibility to follow security recommendations
• Your responsibility to protect information under your control
• How security incidents are reported
• Which systems or services are outside your control
• How third-party vendors affect responsibility

Avoid language that makes the MSP responsible for every possible security outcome.

No provider can guarantee that a breach, outage, or attack will never happen.

The agreement should focus on responsibilities, procedures, and reasonable safeguards rather than impossible guarantees.

The Statement of Work

The Statement of Work, or SOW, is where the actual deal lives.

This is the document that defines what the client is buying, what you are responsible for, what is excluded, and how much the client will pay.

When a dispute happens, the SOW is often the first document both sides should review.

A good SOW should answer one basic question:

Is this request included, or is it billable?

If the document cannot answer that question, the scope is probably too vague.

Define Exactly What Is Covered

The SOW should identify the services being provided and the environment being supported.

That may include:

• Number of users
• Number of endpoints
• Number of servers
• Number of locations
• Supported applications
• Included security tools
• Backup services
• Help desk coverage
• Vendor management
• Network monitoring
• Patch management
• Microsoft 365 administration

Avoid phrases like “all IT support” unless you truly intend to include everything.

Broad language may help close the sale, but it creates problems later when the client expects unlimited work under a fixed monthly fee.

Be specific enough that someone outside the sales process can read the SOW and understand what is included.

Define What Is Not Covered

The exclusions section is just as important as the included-services section.

Common exclusions may include:

• Projects
• Office moves
• New site deployments
• Cabling
• After-hours work
• Hardware replacement
• Unsupported software
• Line-of-business application consulting
• Major cloud migrations
• Cybersecurity remediation
• Third-party vendor fees
• Work caused by unauthorized client changes

Exclusions should not be hidden.

They should be clear, direct, and written in plain language.

A strong exclusions section protects your margin and reduces confusion. It also gives your team a clear basis for quoting additional work.

Put Service Levels Inside the SOW

Service levels should usually be part of the SOW instead of a separate agreement.

The SOW already defines the services, support package, coverage hours, and pricing. Keeping response commitments in the same document makes it easier to connect the promise to the actual service being purchased.

A separate SLA can create unnecessary overlap and make it harder to tell which commitments apply to which services.

Inside the SOW, define ticket priorities and response targets.

For example:

• Priority 1: Full outage or widespread business interruption
• Priority 2: Major issue affecting multiple users
• Priority 3: Standard issue affecting one or a few users
• Priority 4: Request, question, or planned change

The most important word is usually response, not resolution.

You can control how quickly your team acknowledges and begins working an issue.

You cannot always control how quickly the issue is fully resolved.

Resolution may depend on:

• The client
• An ISP
• A software vendor
• A hardware manufacturer
• A cloud platform
• A third-party application provider

Promising a one-hour resolution for a critical issue may sound good during the sales process, but it can create an obligation you cannot consistently meet.

Promising a one-hour response is measurable and within your control.

The SOW should also define:

• Support hours
• After-hours availability
• Whether after-hours work costs extra
• When the response clock starts
• What pauses the response clock
• How client delays are handled
• Whether scheduled maintenance is excluded
• Whether third-party delays are excluded

If service credits are offered, define them carefully.

Credits should be capped, tied to the affected service, and subject to a clear claim process.

A missed response target should not automatically place the client’s entire monthly fee at risk.

Define Pricing and True-Ups

The SOW should explain how pricing works and how it changes.

That may include:

• Per-user pricing
• Per-device pricing
• Flat-rate pricing
• Minimum monthly commitments
• Onboarding fees
• Project rates
• After-hours rates
• Hardware markups
• Annual increases

If pricing is based on users, devices, sites, or servers, explain how counts are reviewed and updated.

For example:

• Counts are reviewed monthly
• Added users are billed immediately
• Removed users are adjusted at the next billing cycle
• A minimum quantity applies
• True-ups occur automatically

Do not leave true-ups to informal conversations.

If the client grows from 40 users to 90 users, the contract should explain exactly how the price changes.

Authorization and Access Documents

Before onboarding begins, the client should provide written authorization for you to access and manage its systems.

This does not need to be a long agreement, but it should be specific.

The authorization document should identify:

• Who may approve work
• Who may approve spending
• Who may request user changes
• Who may authorize security changes
• Who may approve major projects
• Which systems you are permitted to access
• Which tools you are permitted to install
• Which vendors you may contact on the client’s behalf

You are likely going to receive administrative access to critical systems.

You may install agents, change configurations, reset passwords, create accounts, disable accounts, and contact third-party providers.

That authority should be documented.

The client should also acknowledge that onboarding changes may occasionally cause brief disruptions.

That does not excuse poor planning. It simply recognizes that system changes carry some operational risk.

Set Approval Thresholds

The authorization document or SOW should also define spending authority.

For example, the client may authorize the MSP to incur up to a certain amount in third-party costs without separate approval.

That threshold could apply to:

• Replacement hardware
• Shipping
• Emergency licensing
• Small accessories
• Vendor support charges
• Temporary services

A reasonable threshold prevents your team from chasing approval for every minor expense.

Anything above the threshold should require written approval from an authorized client contact.

Data Processing and Security Addendum

Some clients need a separate data processing or security addendum.

This is especially common when the client handles:

• Healthcare information
• Financial data
• Education records
• Payment card information
• Personal information
• Government information
• Data belonging to the client’s own customers

The addendum should explain:

• What data you process
• Why you process it
• Where it is stored
• Which safeguards apply
• How incidents are reported
• Which subprocessors are used
• What happens to data at termination

Even when an industry-specific addendum is not legally required, larger clients may still request one during procurement.

Having a prepared security addendum can make the sales process smoother and show that your organization takes data handling seriously.

Do not sign a client’s security addendum without reviewing it carefully.

Some documents quietly shift nearly all security responsibility to the MSP, including responsibility for systems, users, and vendors outside your control.

Acceptable Use Terms

Acceptable use terms define what the client and its users may do on systems you manage.

These terms may address:

• Illegal activity
• Credential sharing
• Unauthorized software
• Personal device usage
• File-sharing tools
• Security-control bypasses
• Prohibited websites
• Unapproved cloud applications
• Administrative access
• Client changes made without notice

The goal is not to police every action the client takes.

The goal is to establish that your security and support obligations depend on the client following reasonable rules.

If a user disables protection, shares credentials, installs unapproved software, or ignores security requirements, the agreement should explain how that affects your responsibility.

Offboarding Terms

Offboarding should be documented before the client decides to leave.

Once the relationship becomes strained, it is much harder to agree on transition terms.

The contract should explain:

• How much notice is required
• What assistance is included
• What transition work is billable
• How credentials are transferred
• How documentation is returned
• When tools and agents are removed
• How long backups are retained
• When client data is deleted
• Whether unpaid invoices delay transition work
• How third-party licenses are handled

Be careful with language that allows you to hold the client’s own data hostage.

You should protect your right to be paid, but your attorney should help you distinguish between your tools and intellectual property versus the client’s systems, credentials, and business data.

A clean offboarding clause protects both sides and reduces the chance of a hostile transition.

Keep the Document Stack Manageable

The goal is not to overwhelm the client with paperwork.

The goal is to separate the documents by purpose.

A practical MSP contract stack may include:

• Master Services Agreement
• Statement of Work with service levels
• Authorization and access form
• Data processing or security addendum
• Acceptable use terms
• Offboarding terms

Some of these can be exhibits or attachments instead of fully separate contracts.

The exact structure matters less than clarity.

The client should be able to understand:

• What legal terms govern the relationship
• What services are being purchased
• What is excluded
• How much the services cost
• What response commitments apply
• Who may approve changes
• What happens when the relationship ends

Do Not Start Work Before the Paperwork Is Signed

This is the rule that saves the most trouble.

Do not begin onboarding because “the agreement is almost done.”

Do not install tools because “the client already verbally approved it.”

Do not start a project because “legal is still reviewing the MSA.”

At a minimum, the SOW and authorization documents should be signed before work begins.

The MSA should also be completed before the relationship moves forward, but the greatest immediate risk comes from starting work without documented scope and authority.

Once work begins, your leverage drops.

The client has already received value, the environment may already be changing, and the boundaries become harder to enforce.

A clean process protects the relationship before either side has a reason to argue.

Make Signing Part of the Workflow

If your process depends on sending separate PDFs through email, downloading attachments, renaming files, and manually checking signatures, something will eventually get missed.

A good contract workflow should let you:

• Send the full document package together
• Control signing order
• Track outstanding signatures
• Store completed agreements
• Track agreement versions
• Monitor renewal dates
• Reissue SOWs when scope changes
• Maintain an audit trail
• See which clients are using older templates

This is not just administrative convenience.

It is part of protecting the business.

A signed contract does not help much if no one can find it, no one knows which version applies, or nobody notices that the renewal deadline passed.

Review Scope Every Year

Client environments change.

Users are added.

Locations are opened.

Applications are introduced.

Security expectations increase.

Your team slowly takes on tasks that were never included in the original SOW.

That is how scope creep becomes permanent.

At least once a year, compare the active SOW to the services you are actually providing.

Ask:

• Are user and device counts accurate?
• Are all supported sites listed?
• Are we managing tools that are not documented?
• Are we performing recurring project work?
• Are support hours still accurate?
• Are response commitments still realistic?
• Are exclusions still being enforced?
• Does pricing reflect the current environment?

When the work changes, the paperwork should change with it.

The Bottom Line

A successful onboarding is not complete when the tools are installed.

It is complete when the paperwork matches the work.

The MSA should define the legal relationship.

The SOW should define the services, pricing, exclusions, and service-level commitments.

Authorization documents should define who can approve work and what access you are allowed to use.

Security, acceptable use, and offboarding terms should address the risks that appear before, during, and after the relationship.

Keep the documents reusable.

Keep the scope clear.

Keep service levels tied to the SOW.

Most importantly, do not start work until the agreement reflects what both sides actually expect.

Then, when the client asks six months later, “Wait, isn’t that included?” you will have a document that answers instead of a memory that argues.