Master Service Agreement (MSA) or Service Level Agreement (SLA): Which Do You Need in Business?

In the IT sector, internal and external relationships are often governed by legal or quasi-legal documents. In IT and ITSM, the terms "Master Service Agreement" and "Service Level Agreement" are often used interchangeably. 

However, there are differences between the two kinds of agreements that can impact how you want to use them in your organization. While both can be used for similar purposes — such as establishing clear expectations for internal IT service providers or external vendors — what separates them and how they're used are sufficiently different that it's worth taking the time to understand why this is important.

A Master Service Agreement (MSA) or Service Level Agreement (SLA) can set expectations and guidelines between an IT department and IT help desk (also known as IT Service Management) and the rest of the company.

At the same time, either of these approaches can be used to govern a relationship between an IT or software vendor and a client.

In this article, we will take a closer look at the difference between an SLA and an MSA, and when and how you can use both types of results-oriented agreements in ITSM and between IT vendors and companies. 

What is a Service Level Agreement (SLA)?

A Service Level Agreement (SLA) is a type of contractual agreement between two parties that establishes the service levels that will be provided by one party to another. SLAs are often used by IT departments (ITSM teams) and organizations, or software/IT service providers and vendors and the clients they work for.

Within SLAs are the definitions for the quality and availability of the service that will be provided, including what happens when something goes wrong, and how problems will be resolved. In most cases, Key Performance Indicators (KPIs) in SLAs for internal IT teams include timescales for when support tickets will be resolved, and IT service availability, usually agreed at 99.999% uptime.

Quick recap: What is an SLA?

For more information, here are the 3 types of Service Level Agreements.

Now let's compare a Service Level Agreement with a Master Service Agreement.

What is a Master Service Agreement (MSA)? 

Unlike an SLA, an MSA covers a wider range of contractual provisions and services and is often used as a legally binding contract between vendors and clients.

An MSA sets out the terms of the relationship between the two parties, including which services are to be provided, and how and when they will be delivered, including pre-agreed KPIs. It can also include other obligations such as non-disclosure agreements (NDAs) or confidentiality and intellectual property (IP) provisions.

An MSA should cover all aspects of your business relationships with your service provider, including any SLA or Statement of Work (SOW) that has been agreed upon by both parties (more about these below).

In legal terms: "When signing parties know they will continue to work together in the future, a Master Services Agreement (MSA) can simplify those future agreements and speed up the negotiation process."

"With an MSA, additional contracts do not need to be renegotiated, and the basics of the initial agreement can be included in all future contracts."

When an MSA is required, it's often because a vendor provides multiple services to a business customer. For example, an IT or Software as a Service (SaaS) vendor might:

• Provide multiple software suites
• Provide IT help desk support
• Manage other third-party relationships
• Deliver cloud hosting for your organization 

Now let's compare the differences between an SLA and MSA, to help you determine which is best suited to your organization.

MSA vs. SLA: What's the Difference and Which Do You Need?

At times, there is confusion as to whether one or both is a legally binding agreement, or not. The answer to this is, it depends on the context and the relationship between the parties involved.

When an SLA is between an internal IT team, such as a Help Desk or IT Service Management department it doesn't act as a contractual agreement. Instead, an SLA acts more like a series of guidelines and expectations between an internal service department and (internal) customers. In most cases, SLAs include the KPIs and other metric-driven performance indicators that the IT department agrees to achieve.

Here's an example of an SLA for an internal IT Help Desk.

In many respects, when an internal IT team fails to hit targets the consequences aren't as serious as when the same happens between a third-party vendor and a customer. Organizational leaders can withhold bonuses or reduce departmental budgets, but only in extreme cases might a business terminate an entire department and outsource that function.

On the other hand, when an SLA is signed within the terms of a contract between an IT vendor and a client, failure to adhere to targets can more easily result in the termination of the contract. In that scenario, although the SLA itself isn't a legal document, SLAs are usually included within the Statement of Work (SOW) or service provisions of a contract. Therefore, failure to deliver would usually be considered a contractual breach and grounds for termination.

Hence the importance of agreeing to realistic targets, both parties meeting their obligations under the terms, and a vendor achieving the KPI-based targets included in an SLA.

A Master Service Agreement is almost exclusively used between vendors and clients. In this scenario, your organization is the client and an IT or software vendor is the company providing the service that's being paid for, usually on a monthly retainer basis.

MSAs are commonly used in the IT and software sector, and they cover a wider range of provisions than an SLA. Yet again, in this scenario, an MSA is not a contract; however, an MSA can outline the scope of service provisions and targets within a contract. Similar to SLAs, they can be included within the appendices of a contractual agreement and the terms outlined in an MSA define what's agreed within a contract between both parties.

However, an MSA goes much further than the provisions of an SLA.

Unlike an SLA, an MSA provides the basis for ongoing future relationships. It allows for faster agreements between both parties when either new services are provided, or the scope of contracts are extended, often encompassing multi-year contracts.

In legal terms: "At its most basic, an MSA is a contract between two or more parties that establishes what terms and conditions will govern all current and future activities and responsibilities. MSAs are useful because they allow the parties to plan for the future while also speeding the ratification of future agreements. That's because MSAs create a contract framework that establishes the foundation for all future actions."

When we consider this, the main differences are:

• Neither an MSA nor SLA are legally binding, except when they're used to define the terms of legal contracts between providers and clients
• MSAs and SLAs can become legally binding when the provisions or KPIs contained within aren't consistently met, forcing a breach of contract situation
• An MSA encompasses a much wider and more long-term scope, and is used between vendors and clients in the IT and software sector
• Whereas, an SLA is usually exclusively used between an IT department and internal customers and stakeholders

And finally, we will cover how these agreements, such as an MSA, SLA, SOW, and an NDA can be used together in different scenarios.

How Can an MSA, SLA, SOW, and NDA Be Used Together?

We've covered MSAs and SLAs, and the way organizations can use either one or the other, or in some cases, combine them. Alongside these are Statements of Work (SOW) and Non-Disclosure Agreements (NDAs).

Statements of Work are a way of outlining the scope of a project. In the IT sector, this is usually when a project involves digital transformation work or another one-off project with fixed outcomes, timescales, and a budget to achieve the desired goals. An SOW describes how two parties will work together towards achieving mutually beneficial goals using agreed-upon metrics to measure progress toward those goals over time under defined conditions outlined in each section within this document until the completion date.

Non-Disclosure Agreements (NDAs) are contracts between two parties whereby both agree to keep any confidential and intellectually or commercially sensitive information private. It's a contract that many people and organizations sign to confirm the adherence to confidentiality in the business relationship.

In most cases, an NDA and SOW are included within a Master Service Agreement.

SLA vs SOW

Whereas, an SOW isn't usually needed within the scope of an SLA, an SOW is only included in an SLA when the work involved is project-based, with fixed goals, timescales, and budgets.

NDAs are often included in SLAs when the relationship is between a third-party vendor and a client. However, an SLA isn't usually needed when this is between an IT department and internal customers and stakeholders because everyone is an employee of the same organization and NDAs (or comparable confidentiality clauses) are already included in employment contracts.

For more information, and a more in-depth look at this topic, here are 6 Key Components of SLAs.