Managed Services Agreement (MSA) for IT Services: Key Components 

Managed Services Agreement (MSA) for IT Services: Key Components

In the IT services industry, managed services are becoming the preferred model.  In 2022, three-quarters of businesses, surveyed by Deloitte, obtained at least some of their IT services via third-party models.

As digital transformations continue and the competition for tech talent becomes stiffer, strategic partnerships with managed services providers (MSPs) move even higher up on the leader’s agenda. Gartner expects that in most industries, 50% more will be spent on external IT provinces than in-house staff by 2027.

Unlike traditional outsourcing, managed services are more outcome-driven engagements that infuse outside expertise to support complex IT processes, applications, or entire functional areas (like cybersecurity).

Central to this collaboration model is a managed services agreement (MSA).

What is a Master Service Agreement (MSA)?

A master service agreement (MSA) establishes the key terms and conditions between the client and the vendor before service delivery begins. It aims to minimize disputes by clearly outlining and establishing the basic terms of collaboration, responsibilities on both ends and limiting liability.

An MSA typically addresses legal considerations, and dispute resolution methods, and provides a framework for subsidiary agreements. By clearly defining terms for all involved parties, an MSA offers protection against unforeseen risks and potential losses in service relationships. So that both sides can avoid wasted costs, unmet expectations, or mutual misunderstandings regarding the obligations.

An MSA is usually a “preamble” to follow-up legal contracts like work orders, statements of work, and service agreements. It lays out the key provisions up for debate, leaving room for negotiation and amendments. Once finalized, an MSA becomes the main reference for subsequent legalese provisions.

Key Components of an MSA

The purpose of an MSA is to set clear expectations on both sides, eliminating any ambiguities regarding:

  • Scope of services
  • Mutual obligations
  • Service levels
  • Confidentiality
  • Billing arrangements
  • Legal considerations

To that end, a standard MSA will include the following sections (subject to difference, depending on the type of commissioned IT services).

Scope of Services

The section details what services will be delivered to the client as part of the agreement. Each service description usually includes:

  • Description of the nature of services
  • Extent (specific tasks, deliverables, responsibilities)
  • Limitations (i.e., what’s excluded or not explicitly covered under the agreement)

For clients, the Scope of Services section provides a general overview of what’s part of the deal and how the services will be rendered. For example, an AWS managed services agreement can cover 24/7 infrastructure monitoring of the entire estate, which would include monitoring tools setup, resource utilization management, cost optimization, and security updates. The section may also include provisions for requesting extra services or modifying the scope.

Fundamentally, the Scope of Services definition helps level-set expectations to prevent ambiguities and scope creep during the collaboration.

Roles and Responsibilities

The Roles and Responsibilities section delineates the duties and obligations of the MSP and the client. It outlines what each party is expected to do throughout the course of the agreement.

A service provider may provide a list of the main roles that will be involved in the project. For example, a cross-functional managed team of a Cloud Architect, cloud software engineers, DevOps specialist, and quality assurance staff, integrated within your organization, as well as details on the degree of their involvement in the project. For example, key responsibilities, applicable key performance indicators (KPIs), and hourly commitment among other provisions.

For the clients, the section may put forth responsibilities such as providing access to necessary project documentation or corporate resources, direct involvement in project management, or any other collaborative efforts required for successful project delivery. It can specify key points of contact on both sides, their involvement in the service delivery process, escalation procedures for addressing critical issues, and other mutually helpful governance provisions.

Service Level Agreements (SLAs)

Service level agreements (SLAs) can be part of a managed services agreement or a standalone document.

An SLA specifies the quality and availability of delivered services, using pre-agreed metrics. 

These can be general performance metrics like:

  • System uptime/downtime 
  • Support ticket response time
  • Service request fulfillment time
  • Change request response time

Or more precise parameters, covering specific provisions for an externalized process. For example, SLAs for managed cybersecurity services may include the following terms:

Incident Resolution TimeVulnerability Detection FrequencySecurity Awareness Training Completion Rate
Target: 1h

Measurement: Time from detection to resolution

Reporting: Monthly incident resolution report
Target: 2 scans per week 

Measurement: Frequency of vulnerability scans 

Reporting: Weekly overview report
Target: 100%

Measurement: Percentage of corporate users who completed the training

Reporting: Quarterly training completion report

SLAs should specify the consequence of not meeting the target performance standards. Typically, an MSP may extend a service credit in return (e.g., a discount or extended service periods) to compensate for below-target performance.

Generally, SLAs are a good tool for setting a performance baseline, but it doesn’t negate the need for effective vendor management. To ensure peak outcomes, you should invest in building relationships with your MSPs, based on mutual trust and transparency, which allow the vendor to best align their service models with your business needs at present and in the future.

Differences Between an SLA and an MSA

  • Scope and focus: MSAs provide a broad, overarching framework for the entire client-vendor relationship, while SLAs focus on specific services, detailing KPIs and acceptable performance thresholds.
  • Timeframe: MSAs are long-term agreements spanning the entire business relationship, whereas SLAs are often tied to specific projects and/or services. They may have shorter durations and change over time.
  • Legal implications: Both MSAs and SLAs become legally binding when incorporated into legal contracts. However, MSAs set the overall governance framework, while SLAs define enforceable performance expectations for specific service(s).

Change Management

One of the big boons of managed IT services is flexibility. IT estates expand, product development plans evolve, and new regulations call for tighter data protection measures.

Change management procedures help accommodate the modifications to original service terms and conditions.

This section outlines the process for initiating, evaluating, approving, and implementing changes throughout the duration of the agreement. For example, increasing the service scope or expressing concerns over SLA breaches.

At the same time, it should address problem management i.e., how service issues should be escalated and handled by the provider. Change management may include specific steps the MSP promises to take in response to a submitted request. For example, conduct a root cause analysis of a recurring issue and propose a resolution plan.

Confidentiality Clauses

As part of the MSA, confidentiality clauses set forth high-level provisions for handling sensitive information among parties. Usually, it includes:

  • Definition of confidential information within the scope of this agreement (criteria and exclusions)
  • Permitted uses of confidential information for effective service delivery
  • Data protection obligations of both parties (e.g., safeguards to prevent unauthorized data access, use, or disclosure)
  • Duration of the confidentiality obligations (which may extend past the MSA date)
  • Legal liabilities for breaching the confidentiality terms

Confidentiality clauses in the MSA are usually used to then create specific non-disclosure agreements (NDAs) for different parties involved in the project. NDAs can differ, depending on the nature of the provided services. For example, a team working on a HIPAA-compliant healthcare system may be subject to more stringent provisions as they may be dealing with sensitive patient data.

Liability Limitations

As the name implies, the Liability Limitations section sets the boundaries of financial responsibility for both parties in response to breaches or losses related to the agreement. Provisions may include:

  • Included and excluded liabilities (e.g., indirect or consequential damages)
  • Liability cap for each party, recorded as a fixed amount or a percentage of the contract value
  • Exclusions — cases when neither party can be held accountable for certain losses (e.g., force majeure events), or, on the contrary, face higher liability (e.g., intellectual property rights violations)
  • Indemnification provisions for when either party agrees to compensate for losses

The section should also specify the procedure for raising liability concerns and dealing with related disputes. Again, clearly defined terms provide clarity on financial exposure and help both parties manage risks better.

Payment Terms

The Payment Terms section expounds on the managed services provider pricing model. It articulates the pricing structure for different types of services, payment schedule, invoice frequency, applicable taxes, and timeframe for payment (e.g., net 30 days). The section also addresses any deposit requirements, retainer fees, or advance payments, as well as invoice currency and accepted payment methods.

That said, payment terms in MSA do not always include the final price quote per provided service. It rather illustrates the expected payment schedule and ballpark ranges. Final price quotes are typically provided in the Scope of Work (SoW) agreements and supporting legal work contracts.

Similar to other MSA sections, Payment Terms will include a process for disputing charges, escalating payment issues, and approaches to resolving disagreements.  It may also include any circumstances in which payments may be withheld or services suspended.

Termination and Renewal

Coming in last, the Termination and Renewal section states the conditions and procedures for ending or extending the partnership.

This section should clearly specify the various grounds for termination and the process for initiating one, including the notice period and notice submission format. It should also cover the rights and obligations of both parties in the event of termination, such as project handover, return of confidential information, or any financial settlements (e.g., outstanding invoices or early termination penalties).

Regarding renewal, this section should explain the process for extending or renewing the contract. It should clarify whether the agreement will automatically renew or if explicit action is required from either party to initiate a renewal. If automatic renewal is included, the section should detail the conditions under which it occurs and any provisions for opting out. The section may also address how changes to terms or service pricing can be negotiated during the renewal process.

Key SLA Metrics to Evaluate Managed IT Services Delivery

As mentioned already, SLAs help establish a minimally acceptable performance threshold for the vendor. It’s a helpful tool for establishing accountability and ensuring legal protection for both parties through better expectation management.

In the context of managed IT services, a vendor may offer one of the following types of SLAs:

  • Customer-based SLA, tailored to meet the customer’s unique needs and requirements, tracked through a roster of metrics.
  • Service-based SLA establishes acceptable performance levels for a commissioned service.
  • Operational SLA defines performance standards for daily service operations like vulnerability management or system downtime.
  • Multi-level SLA can be a combination of customer-based aspects and service-based SLAs, setting performance standards on several levels.

The selection of SLA metrics will differ a lot depending on the service type, scope, and duration — and are often up for discussion with the MSP. But here are several common options.

Response Time

Response time is the agreed timeframe for an MSP to acknowledge a reported issue or request. SLAs may include specific response times for:

  • Critical security issues
  • Customer support requests
  • IT service desk requests
  • After-hour emergency system support

In most cases, the response times for each type of request further differ depending on the priority issue. A password reset problem can wait slightly longer than addressing a newly discovered system vulnerability. An MSP should advise you on realistic response times, feasible in each case.

Service Quality

Service quality SLAs establish specific KPIs for delivered services. The exact KPIs can vary greatly depending on the nature and scope of the services delivered.

Sample Managed Services Quality Metrics

Managed Cloud Infrastructure MonitoringManaged Data Analytics ServicesManaged IT Service Desk
99.9% monitoring uptime per month

25-minute average alert response time

95% accuracy in alert notification

Critical alert resolution time within 2 hours; low-priority within 12 hours
99.5% data accuracy for processed datasets

Report generation within 48 hours of request submission

Data freshness updates every 15 minutes

100% compliance with GDPR and HIPAA
Average ticket resolution time of 4 hours

Escalation of high-priority issues within 30 minutes

Average wait time in chat: 15 minutes during work hours

90% or higher end-user satisfaction

System Availability

Since MSPs often cover infrastructure management and optimization processes, system availability metrics are included in SLAs. They’re applicable to managed cloud infrastructure services, network, security, database, application, and disaster recovery services among others.

The common system availability SLA metrics can include:

  • Uptime percentage
  • Downtime percentage
  • Service availability
  • Failover time
  • Scheduled maintenance window 
  • Acceptable service degradation time
  • Recovery time objectives (RTO)

To establish reasonable thresholds an MSP will need to evaluate your IT portfolio to better understand the systems’ stability i.e., all factors that may negatively affect its performance and thus availability. Based on the assessment, an MSP may also recommend implementing certain improvements. For example, updating legacy, downtime-prone on-premises systems to the cloud to improve availability or making changes to cloud-based cold or warm failover configuration to expedite switching.

Incident Metrics

Rapid incident investigation and resolution are critical for preventing unplanned downtime and prolonged exposure to potential vulnerabilities. The faster you are — the less damage your business incurs. MSPs, in charge of infrastructure management and/or system security, usually agree to corroborate their commitment through the following  incident metrics:

  • Mean time between failures (MTBF) — the average timeframe between repairable system failures. The higher the time between failures, the more reliable the system is.
  • Mean time to recover (MTTR) — the average time it takes to recover from a system failure and restore normal operations.
  • Mean time to resolve (MTTR) — the average time it takes to fully resolve a failure. Unlike the previous metric, the mean time to resolve also factors in the time the team takes to fix the problem that caused system failure (for example, patch the identified vulnerability).
  • Mean time to respond (MTTR) —  average time elapsed between receiving an alert to recovering from a system failure.
  • Mean time to acknowledge (MTTA) — average time from when an alert is triggered to when work begins

These incident metrics provide a different perspective on the issue and the team’s effectiveness, so when combined, they give the complete picture of the event. 

tracking incident management

Source: Atlassian

Conclusion

As managed IT services delivery moves into co-management territory — such where MSPs work alongside client teams on more complex projects — leaders are also choosing to incorporate business success metrics into their SLAs. This shift reflects a growing understanding that IT services should directly contribute to overall business performance, not just technical benchmarks.

Evaluate the MSA and individual SLAs through the pane of organization impacts: Do the proposed terms contribute to potential revenue growth or cost savings? Can they improve operational efficiencies through downtime reduction and better IT service delivery? Will the partnership lead to faster time-to-market and more innovative products?

By approaching a potential partnership from a business-oriented perspective MSPs and their clients can ensure that IT services are not just meeting technical standards, but are truly driving strategic priorities.

Meanwhile, our team is open to discussing your business challenges. Drop us a line and we'll get in touch with you promptly!