What is a master services agreement (MSA)?
By SuLe · Updated 12 May 2026
A master services agreement is a contract that sets the standing terms of a business relationship once — liability, IP, data, confidentiality, payment and termination — so each new project can be added through a short statement of work that inherits them. It exists so you negotiate the hard terms a single time, then move fast on the specifics for every engagement after.
Key facts
- An MSA holds the constant legal terms; each project attaches via a statement of work (SOW).
- It covers liability, IP ownership, confidentiality, data protection, payment and termination.
- The SOW sets deliverables, timeline and price, and inherits the MSA's terms.
- Liability caps in the MSA must be reasonable under the Unfair Contract Terms Act 1977.
- If personal data is processed, a DPA is attached to the MSA as a schedule.
What does an MSA actually do?
It separates the durable from the project-specific. The MSA carries the legal terms that should not change from job to job — who owns what IP, how liability is capped, confidentiality, data handling, payment mechanics and how the relationship ends.
Each individual project is then documented in a statement of work: a short paper listing deliverables, timeline and price. The SOW inherits the MSA's terms rather than restating them.
The payoff is speed with safety. Once the MSA is signed, a new project is a one-page SOW, not another full contract negotiation — and every project rests on the same, already-agreed legal foundation.
When should my startup use one?
When you expect repeat business with the same counterparty. A startup selling implementation services, a design studio with ongoing clients, or a company using the same contractor across projects all benefit from settling terms once.
For a genuinely one-off engagement, an MSA plus SOW is overkill — a single combined services agreement is simpler and just as safe. The MSA earns its keep only when there will be more than one project.
It also helps on the buying side. If you regularly engage the same agencies or contractors, your own MSA lets you bring them onto your terms and add work by SOW, keeping your obligations consistent across suppliers.
| Document | Holds | Changes per project? |
|---|---|---|
| Master services agreement | Liability, IP, data, confidentiality, payment, termination | No — constant |
| Statement of work (SOW) | Deliverables, timeline, price, milestones | Yes — one per project |
| DPA schedule | UK GDPR Article 28 data terms | No — applies to all SOWs |
How is liability and IP handled across the MSA and SOWs?
Put the risk-allocation terms in the MSA so they govern everything beneath it. The liability cap, IP ownership rules and confidentiality obligations belong at the master level, applying uniformly to each SOW.
The liability cap is the term to get right. In B2B contracts it must pass the reasonableness test of the Unfair Contract Terms Act 1977, and liability for death or personal injury from negligence, and for fraud, can never be excluded — an overreaching cap risks being struck out.
IP ownership should say clearly who owns deliverables and any pre-existing materials. Because it lives in the MSA, you settle it once instead of arguing project by project — which is exactly when ownership disputes otherwise surface.
How does data protection fit into an MSA?
Through a schedule, when personal data is in play. If the services involve one party processing personal data for the other, UK GDPR Article 28 requires a data processing agreement.
The clean approach is to attach that DPA as a schedule to the MSA. Then the data terms apply automatically to every SOW issued under it, rather than being renegotiated or, worse, forgotten each time a project starts.
Be clear about roles. Often the customer is the controller and your startup is the processor, but some engagements are controller-to-controller, which needs a data sharing arrangement instead. Getting the roles right shapes which data terms the schedule should contain.
Worked example
Yusuf runs Northpin, a data-engineering consultancy, and lands a retailer as a repeat client. Rather than paper each project separately, they sign an MSA covering IP, confidentiality, a liability cap set at the last 12 months' fees, and payment terms.
Because Northpin will handle the retailer's customer data, they attach an Article 28 DPA as a schedule — with the retailer as controller and Northpin as processor. The MSA is negotiated once, over a fortnight.
The first project — a data-warehouse migration — is then a two-page SOW listing scope, milestones and a fixed price. The next project, three months later, is another short SOW. Both inherit the MSA's liability cap, IP terms and DPA without reopening any of them.
Where founders go wrong
Using an MSA for a one-off job.
Without repeat work, the MSA-plus-SOW structure adds friction for no benefit — a single contract is better.Leaving key terms in the SOW.
Liability, IP and data belong in the MSA; scattering them across SOWs creates inconsistency and gaps.Setting an unreasonable liability cap.
A cap that fails the UCTA 1977 reasonableness test can be struck down, undoing the protection you wanted.Forgetting the DPA schedule.
If personal data is processed, Article 28 still applies — an MSA without a DPA leaves a compliance hole under every SOW.
Related questions
What is the difference between an MSA and a statement of work?
The master services agreement holds the standing legal terms — liability, IP, confidentiality, data, payment and termination — that stay constant across the relationship. A statement of work, or SOW, is a short document for each project setting out the specific deliverables, timeline and price, which inherits the MSA's terms rather than restating them.
When should a startup use an MSA?
When you expect repeat work with the same customer or supplier. Negotiating full terms for every project wastes time, so you agree them once in the MSA and then add each project with a short SOW. For a genuinely one-off engagement, a single combined contract is usually simpler than an MSA plus SOW.
Can I limit liability in an MSA?
Yes, and the liability cap usually sits in the MSA so it governs every SOW. In B2B contracts the cap must pass the reasonableness test of the Unfair Contract Terms Act 1977, and you can never exclude liability for death or personal injury from negligence, or for fraud. An unreasonable cap can be struck down.
Does an MSA need a data processing agreement?
If personal data will be processed under the engagement, yes — a DPA is required by UK GDPR Article 28 and is usually attached to the MSA as a schedule. That way the data terms apply automatically to every SOW, rather than being renegotiated or forgotten each time a new project starts. [More: What is a data processing agreement (DPA) and when do I need one?]
An MSA looks like a formality until a project goes wrong and you discover the liability cap, IP ownership or data terms were never nailed down. A SuLe solicitor can build you a reusable MSA and SOW template that hold up across every engagement. Book a free compliance check call and stop renegotiating the same terms with every client.
Keep reading: What should B2B SaaS terms of service include? · What is a data processing agreement (DPA) and when do I need one? · Are e-signatures legally valid in the UK? · Do I need terms and conditions and a privacy policy for my startup? · What does UK GDPR require from an early-stage startup? · Can I use legal templates instead of a lawyer?
Primary sources: GOV.UK — Data protection · Unfair Contract Terms Act 1977
