What should be in a managed IT services agreement

Short answer: A managed IT services agreement (MSA) should spell out eight things clearly – scope of services, SLA definitions with teeth, exclusions and out-of-scope work, pricing structure and change terms, data handling and ownership, termination and exit procedures, security and compliance commitments, and escalation paths. Anything vague in these eight sections will become a source of friction. Anything missing will become a surprise. This is not legal advice – a lawyer should review the contract before you sign – but it is a practical buyer’s guide to the structure a solid MSP contract should have.

The MSP relationship lasts an average of 3-5 years. The contract you sign is what you will be operating under the whole time. Most buyers skim the contract because the salesperson seemed nice and the proposal looked fine. Most disputes then happen because the contract was vague exactly where it needed to be specific. This guide walks through what each section of the agreement should cover, what good language looks like, and what to watch out for.

The eight sections every MSA should have

Section	What it defines	Common gotcha
Scope of services	What the MSP actually delivers	Generic language that leaves everything arguable
SLAs	Response time, resolution time, availability commitments	Response SLA without resolution SLA
Exclusions	What is out of scope and how it is billed	Vague “project work” catchall
Pricing	How you are charged and how rates change	Open-ended price escalation
Data handling	Who owns what during and after the contract	MSP-owned documentation you cannot retrieve
Term and termination	Length, notice, exit process	Auto-renewal with impossible notice windows
Security and compliance	MSP’s security posture, breach notification	No commitments on their own security
Escalation	How disputes and urgent issues get escalated	No named contacts, no path to leadership

Everything below is an expansion of this table.

1. Scope of services

This is the heart of the contract. Scope defines what the MSP is actually obligated to do. The clearer it is, the less you will argue about “is that included” over the next three years.

What good scope language looks like

Good scope statements are specific and enumerated, not generic. Instead of “comprehensive managed IT services,” a real scope section names the services with enough detail to be measurable:

• Helpdesk: business-hours support (7am-6pm local time, Mon-Fri), email + ticket portal + phone, response SLAs per priority tier, up to X tickets per user per month included
• Endpoint management: RMM agent deployed on all managed workstations and servers, OS and approved application patching on a defined cadence, compliance reporting monthly
• Microsoft 365 administration: user provisioning and deprovisioning, license management, security configuration (MFA, conditional access, Defender), tenant monitoring
• Email security: spam filtering, anti-phishing, attachment sandboxing via [specific tool]
• Endpoint security: EDR deployed and managed on all workstations and servers, 24/7 alert monitoring
• Backup: workstation and M365 data backup via [specific tool], daily backup jobs, monthly restore tests, 30-day retention (minimum)
• Documentation: asset inventory, network diagram, account inventory, vendor contacts, maintained quarterly
• Reporting: monthly operations report, quarterly business review

What to watch out for

• Scope defined only in the proposal. The proposal and the contract should match. If the contract has vaguer scope than the proposal, the contract wins in a dispute.
• “Managed IT services as described in Appendix A” with no Appendix A. Sounds obvious. Happens more often than you would think.
• Service level “commitments” that turn out to be “targets” or “goals.” Language matters. “Commitment” is binding. “Target” is aspirational.
• No numerical limits on anything. A helpdesk with no included ticket count can be throttled when you get busy. Most MSPs honor unlimited helpdesk within reason, but the contract should say so.

2. SLAs – response time, resolution time, and availability

Service level agreements are where the MSP commits to performance. A good SLA section covers three things: how fast they respond, how fast they resolve, and what happens when they do not meet the commitment. (This is also question 1 in the how to choose an MSP playbook, and the broader what is an SLA primer walks through each piece in depth.)

Response time SLAs

Response time is the time from ticket submission to first meaningful human response (not an auto-reply). Typical tiers:

Priority	Example definition	Typical response SLA
Critical (P1)	Business-down, multiple users affected, security incident	15-30 minutes
High (P2)	Single user blocked from work, major function impaired	1-2 hours
Normal (P3)	Inconvenience, workaround exists	4-8 business hours
Low (P4)	Request, not a problem	1-2 business days

The priority definitions matter as much as the SLA numbers. A vague “critical” definition lets the MSP downgrade your ticket to a tier with looser SLAs.

Resolution time SLAs

Resolution time is when the issue is actually fixed. This is where weak contracts go soft – they commit to response and stay vague on resolution. Insist on resolution commitments per priority tier, even if they are “target” resolution times with defined exceptions (parts on order, Microsoft bug, dependencies on third parties).

Availability SLAs

For infrastructure the MSP manages (firewalls, network devices, M365 tenant config), availability SLAs commit to uptime. 99.9% is the typical SMB-grade commitment. Higher tiers cost more. Watch for:

• What counts as “unavailable”? Complete outage only, or degraded performance too?
• How is availability measured? Monthly? Quarterly? Rolling 90 days?
• What is excluded from the measurement? Scheduled maintenance should be excluded. Third-party outages usually are. Make sure the exclusions are reasonable.

Penalties when SLAs are missed

Without consequences, an SLA is a suggestion. Common structures:

• Service credits. Missed SLA results in a credit against the next month’s fee (e.g., 5% for each missed response commitment, up to 25% of monthly fee).
• Escalation rights. Repeated SLA misses trigger an escalation to MSP leadership with a written remediation plan.
• Termination rights. Chronic SLA failure (e.g., missing the same SLA three months in a row) is grounds for termination without penalty.

The exact percentages matter less than having some teeth. A contract with SLAs and no remedies is a contract without SLAs.

3. Exclusions and out-of-scope work

Every MSP contract has scope boundaries. The ones that do not name them clearly are the dangerous ones. Key exclusions to expect:

Standard exclusions

• Major infrastructure deployments. New servers, new offices, datacenter migrations, network redesigns – these are project work.
• Compliance certifications. Initial SOC 2, HIPAA, PCI, or CMMC certification work is specialty effort, separate from ongoing compliance maintenance.
• Custom development. PowerShell automation beyond a defined threshold, custom integrations, Power Platform builds, Zapier/Make work.
• Hardware procurement. The MSP may handle ordering/imaging/shipping as a service, but the hardware cost is passed through.
• Line-of-business application support. Your industry-specific software (legal practice management, EHR, construction estimating) is usually out of scope unless explicitly named.
• On-site visits. Many contracts include a small allotment of on-site hours per quarter and bill additional visits per trip.
• After-hours coverage beyond included tier. 24/7 helpdesk is a premium; standard tiers include after-hours response for critical issues only.

How out-of-scope work is billed

The contract should specify:

• Project work: scoped and quoted separately, with a written statement of work before the work starts
• T&M (time-and-materials) work: billed hourly at a rate defined in the contract, with any cap or approval threshold clearly stated
• Incident response above standard: forensics, breach notification support, legal liaison – often gated by an incident response retainer

What to watch out for

• “Everything else” clauses. Language like “anything not specifically included is subject to project rates” gives the MSP unlimited discretion to call things out of scope.
• Hidden T&M thresholds. Some contracts include “up to 8 hours of project work per quarter” with anything above billed hourly. Know the threshold before you sign.
• Scope creep via proposal amendments. Some MSPs quietly narrow scope in future amendments. Compare the original MSA to the current one annually.

Framed positively: the MSP scope you want is one where deployments are separate projects, ongoing operations are the managed service – the same scoping pattern applies consistently.

4. Pricing structure and change terms

How you are charged, and how those charges change over time, should be explicit.

The pricing structure itself

• Per-user, per-device, or flat tier? Whichever model applies should be clearly stated with the current rate. (How MSPs are paid – understanding managed IT pricing models covers the mechanics of each.)
• What counts as a user or device? Contractors? Shared workstations? Servers? IoT devices? Ambiguity here turns into billing disputes.
• How often is the user or device count reconciled? Monthly true-up is common. Some MSPs reconcile quarterly. Avoid contracts that let the MSP reconcile whenever they want.
• Billing cycle and payment terms. Monthly in advance is typical. Net 30 is typical. Late payment fees should be reasonable.

Price change terms

Rates are not fixed forever. The question is how they change:

• Annual increases. Some contracts include a fixed annual escalator (e.g., 3-5% per year). Others require written agreement for any increase.
• Pass-through cost changes. Microsoft licensing costs, third-party tooling costs – some contracts allow pass-through with notice. Reasonable, but insist on notice (30-60 days) before the change.
• Scope-driven changes. Adding a new service or substantially expanding scope triggers a pricing conversation, not an automatic increase.

What to watch out for

• Open-ended price change rights. Contracts that let the MSP change rates “with 30 days notice” at their discretion give them unilateral pricing power. Require mutual agreement for rate changes beyond a named escalator.
• Pricing tied to consumption metrics you cannot predict. Pay-per-ticket, pay-per-alert, pay-per-GB of backup – these can blow up if your usage changes.
• Escalators with no cap. “Annual increase equal to CPI plus 5%” in a high-inflation environment can get expensive fast.

5. Data handling and ownership

This is where most contracts get weakest, because buyers do not think about it until they need to leave.

What the contract should say

• All client data is owned by the client. Full stop. This includes data stored in tooling the MSP provides.
• All documentation is owned by the client. Asset inventory, network diagrams, account inventory, password vaults, runbooks – all deliverables are yours, not the MSP’s.
• Configurations, automation, and custom scripts are owned by the client. If the MSP built it for you, you own it.
• Access credentials and accounts are held in trust. The MSP administers them on your behalf; you retain ownership.
• Data portability commitments. The MSP commits to providing your data and documentation in a usable format on termination, within a defined timeline.

What to watch out for

• MSP-owned documentation. Some contracts state the MSP’s “work product” (including documentation) belongs to the MSP. That leaves you dependent on their continued cooperation to understand your own environment.
• Proprietary tooling with no export. If the MSP’s ticketing system, RMM, or documentation platform has no export capability, your historical data disappears when the contract ends.
• Password vault ownership. The credentials to your critical systems must be yours. Some MSPs try to retain ownership of password vaults.
• Data residency silence. For regulated industries, the contract should specify where data is stored (US? EU? specific region?) and any cross-border transfer commitments.

6. Term and termination

How long the contract runs and what happens at the end.

Contract term

• 1-3 year initial term is typical. Longer terms may come with discounted pricing.
• Month-to-month after the initial term is buyer-friendly and common.
• Multi-year with annual renewals is also common, but watch the renewal terms.

Termination clauses

A fair contract has both:

• Termination for cause. If the MSP materially breaches the contract (chronic SLA failure, security failure, missed deliverables), you can terminate with a defined cure period (usually 30-60 days). Cause should be concretely defined.
• Termination for convenience. Either party can terminate with advance notice (typically 60-90 days) for any reason. May involve early termination fees in an initial term.

Auto-renewal

Many contracts auto-renew for another year if no one gives notice. The trap is in the notice window:

• Reasonable: 30-60 days notice to prevent auto-renewal
• Borderline: 90 days
• Red flag: 120+ days, or notice required during a specific window (e.g., only between day 60 and day 90 of the contract year)

Set a calendar reminder for the notice window the day you sign the contract. Buyers who miss the notice window renew for another year they did not want.

Exit process

The most important part of termination, and the most often missed. The contract should commit the MSP to:

• Transfer all data, documentation, and credentials within a defined timeline (commonly 30-90 days)
• Remove all MSP-owned tooling from your environment without disrupting operations
• Cooperate with the incoming provider during the transition
• Provide a transition coordinator who owns the handover
• Charge reasonable transition fees (or none) rather than punitive ones

A bad exit process is how businesses end up stuck with a bad MSP for an extra year – the cost of leaving gets bigger than the cost of staying. (If you are reading this article because you are already planning to switch, the switching playbook walks through the pre-notice audit and the parallel running period.)

7. Security and compliance commitments

You are about to give the MSP admin access to your most critical systems. Their security posture is your security posture. The contract should commit them to specific security practices.

Baseline commitments

• Their own security controls. MFA on all MSP accounts, EDR on MSP endpoints, documented security practices. Usually reflected in a SOC 2 Type 2 attestation.
• Cyber insurance. Minimum coverage limits (usually $2M-$5M for SMB MSPs).
• Breach notification. Specific timeline for notifying you if the MSP is breached (72 hours is common; aggressive is 24 hours).
• Background checks on MSP personnel with admin access to your environment.
• Subcontractor disclosure. If the MSP uses any subcontractors (offshore helpdesk, specialty vendors), that should be disclosed in the contract.

For regulated industries

If your business operates under HIPAA, SOC 2, PCI, or CMMC, the contract needs additional language. (The broader question of whether to pick a vertical MSP or a generalist with compliance practice – and how to tell which one fits your situation – is covered in the specialization comparison.)

• Business Associate Agreement (BAA) for HIPAA-covered entities. This is a separate legal document and should be executed alongside the MSA.
• Specific compliance-aligned controls. The MSP commits to operating in a way that supports your compliance posture (audit logs, access controls, encryption standards).
• Right to audit. You (or your auditor) can inspect the MSP’s practices relevant to your compliance scope.
• Data residency and subprocessor requirements per the relevant framework.

What to watch out for

• No commitment on their own security. If the MSP cannot tell you what MFA, EDR, or SOC 2 status looks like on their side, they should not be touching your environment.
• Long breach notification windows. “Within a commercially reasonable time” is not a commitment. Pin it to a specific hour count.
• Liability caps that make the security commitments meaningless. A $100K liability cap is not serious protection for a 50-person business with real data exposure.

For context on why MSP security posture matters specifically – managed cybersecurity providers work with your most sensitive data, and a breach of the MSP propagates to every client.

8. Escalation paths and named contacts

When something goes wrong – a missed SLA, a difficult outage, a billing dispute – you need a way to escalate that does not depend on knowing someone’s personal cell phone.

What the contract should define

• Named day-to-day contacts (account manager, technical lead) with email and phone
• Named escalation contacts at the MSP (service manager, operations lead, executive sponsor)
• A documented escalation process. What happens when your first call does not resolve the issue? When does it go to leadership?
• Regular cadence meetings. Monthly service reviews, quarterly business reviews – defined in the contract so they do not quietly stop happening.
• Dispute resolution procedure. If you disagree about scope, billing, or performance, how does that get resolved? Written notice, meeting requirements, mediation/arbitration clauses.

What to watch out for

• “Contact your account manager” as the only escalation path. Account managers have every incentive to protect the MSP’s interests, not yours.
• No defined executive sponsor. At some point you need to talk to someone at the MSP whose job depends on you being happy. If there is no one named, there is no one.
• Meetings that quietly disappear. Put the meeting cadence in the contract, not just in the onboarding document. (The onboarding document itself should have its own structure – see what to expect in the first 90 days of MSP onboarding for what good onboarding deliverables look like.)

Red flags in the contract itself

A few contract patterns are bad enough to walk away from:

One-sided liability. The MSP disclaims all liability while holding you fully liable for every possible contingency. Fair contracts have symmetric liability caps and mutual indemnification.

“As-is” services. If the MSP does not commit to any standard of performance, you have no contract worth having.

Unlimited right to subcontract. If the MSP can subcontract any portion of the work to anyone without your approval, your data and access could end up anywhere.

No audit rights. For regulated businesses, the inability to audit the MSP’s controls is disqualifying.

Indefinite term, vague termination. Contracts with no defined term or with termination rights that depend on MSP consent are traps.

Non-standard governing law and venue. If the contract specifies a distant jurisdiction (MSP is in California but contract is governed by Delaware and venue is in Florida), that is friction designed to discourage disputes.

Boilerplate language that does not match their sales pitch. A sales process that promised “dedicated engineers” followed by a contract that says “services delivered by qualified personnel” is a signal that the sales process was aspirational and the contract is the reality.

Before you sign: the final review checklist

Once you have a contract, read it with the following questions:

1. Does the scope match what the sales process described?
2. Are the SLAs specific (response, resolution, availability) with penalties for misses?
3. Are the exclusions named clearly, and do they match what the MSP said was included?
4. Is the pricing structure clear and the change terms reasonable?
5. Do you own your data, documentation, and credentials unambiguously?
6. Is the term sane, the notice period reasonable, and the exit process fair?
7. Are security commitments specific (SOC 2, cyber insurance, breach notification)?
8. Are escalation paths and named contacts defined?
9. Does the liability framework protect you proportionally to the risk?
10. Has a lawyer you trust reviewed it?

The last point is not optional for anything above a small business with simple needs. A one-hour review by an attorney who handles IT services contracts is cheap insurance against a multi-year commitment.

How Sequentur approaches MSAs

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. We share our MSA template with prospects during the evaluation process, not after they have committed. We want you to see the scope definitions, SLA language, exclusions list, and exit terms before you sign – because a contract that feels fair at the start is the foundation of a multi-year relationship that works.

Our standard MSA includes enumerated scope, priority-tier SLAs with service credits for misses, a clear exclusions list with defined rates for project work, per-user pricing with a named annual escalator, client ownership of all data and documentation, 60-day termination for convenience, SOC 2-aligned security commitments with a 72-hour breach notification clause, and named escalation contacts including an executive sponsor. For regulated clients we execute a BAA alongside the MSA when HIPAA applies and support compliance-specific clauses (audit rights, residency, subprocessor disclosure) as needed.

If you want to see how our MSA compares to what you have been quoted by other providers, schedule a call. We will walk through the contract with you, flag what we would negotiate differently, and tell you if staying with the provider you are already evaluating is the right answer.