What is a Master Services Agreement (MSA) and what to check in the security clauses

At some point in your first serious enterprise deal, someone from the buyer's legal team will send over a Master Services Agreement and ask you to review and sign it. If you have never seen one before, it can be intimidating, dense with clauses that all sound important and none of which explain themselves in plain language. This article explains what an MSA actually is, and specifically what to look for in the security related clauses, which are the parts most likely to create real risk for an AI startup if you sign without understanding them.

What a Master Services Agreement actually is

A Master Services Agreement, usually shortened to MSA, is the overarching contract that governs the relationship between you and a customer. Rather than negotiating a full new contract every time you do a piece of work together, the MSA sets out the general terms once, things like payment, liability, confidentiality, term and termination, and data handling. Specific pieces of work are then often covered by shorter documents, sometimes called statements of work, that sit underneath the MSA and reference it.

For an AI startup, the MSA is usually presented by the enterprise buyer, using their own template, which means it is written to protect them, not you. That is normal and not a red flag by itself, but it is exactly why you need to read it carefully rather than treating it as a formality to sign quickly so the deal can close.

Why the security clauses matter more than the rest

Most sections of an MSA are commercial boilerplate that a lawyer can review quickly. The security and data related clauses are different, because they translate directly into obligations your product and your team have to actually meet, sometimes for years after signing. Get these wrong and you can end up contractually promising security practices you do not have, with real financial and legal consequences if something goes wrong later.

Here are the specific things to look for.

Data protection and processing terms

The MSA should reference or incorporate a proper Data Processing Agreement covering how you handle the customer's personal data, consistent with UK GDPR. Check that it does not silently expand what you are agreeing to beyond your standard DPA, for example by requiring data residency in a specific region you cannot currently guarantee, or imposing retention rules that do not match how your product actually works. If the MSA's data terms conflict with your own DPA, resolve that before signing rather than after.

Security standards and certifications you are committing to

Watch closely for language that commits you to maintaining a specific security certification or standard, such as SOC 2 or ISO 27001, for the life of the contract. If you do not currently hold the certification named, do not sign a clause promising to maintain it, because that turns an aspiration into a binding contractual obligation you can be held to. If you are working towards a certification, negotiate language that reflects your actual roadmap, such as a target date, rather than an unqualified promise. Also look for vague phrases like industry standard security practices, and where possible get specific about what that means, because vague security language becomes a source of dispute if something goes wrong.

Breach notification obligations

Almost every MSA includes a clause requiring you to notify the customer if a data breach occurs, and the details matter considerably. Check the notification window, since some contracts demand notification within an unrealistically short period, sometimes as little as 24 or 48 hours, before you would even have a complete picture of what happened. Check what counts as a breach under the definition given, since some are drafted extremely broadly. And check what information you are required to provide, because overly detailed disclosure requirements early in an incident can create problems of their own. Where the terms are unrealistic for a team your size, negotiate them rather than accept an obligation you cannot practically meet.

Audit and inspection rights

Many MSAs give the customer the right to audit your security practices, sometimes including on site inspection or the right to request evidence of specific controls on demand. This is a normal and reasonable ask from a buyer, but check the scope and frequency. Unlimited audit rights with no notice period can be genuinely disruptive for a small team, so reasonable notice periods and limits on frequency are worth negotiating if the initial draft is open ended.

Sub processor and AI specific provisions

This is the clause most likely to be missing entirely, and its absence is itself worth addressing. If your product sends data to third party AI model providers, the MSA should acknowledge this as part of your sub processor arrangements, consistent with your DPA. If the MSA is silent on AI use entirely, and increasingly some buyers now specifically ask about AI model providers, training data use, and prompt handling within the MSA or an attached AI addendum, be ready to proactively disclose your architecture rather than letting a gap in their template create ambiguity later. Increasingly, sophisticated buyers are adding AI specific riders to their standard MSAs, prohibiting the use of their data to train models, for example, so read carefully for anything along these lines.

Liability and indemnity related to security

Look at how liability is structured specifically for a security incident or data breach, as opposed to general liability under the contract. Many MSAs carve out data breaches from the standard liability cap, meaning your exposure in the event of an incident could be considerably higher than the cap that applies to other kinds of dispute. Understand this before signing, because it directly affects how much financial risk you are taking on, and it is worth discussing with your insurer if you hold cyber insurance, since carved out liability may exceed what your policy would cover.

Termination and data return or deletion

Check what happens to the customer's data when the contract ends. A well drafted MSA specifies a timeframe for returning or securely deleting their data after termination. If this is missing or vague, it is worth raising, both because it is good practice and because a buyer's security team will often expect to see it addressed.

What to actually do when one lands on your desk

Do not sign an MSA the same day it arrives, however much pressure there is to close the deal quickly. Read the security, data, and liability sections carefully, ideally with input from whoever understands your actual security posture, not just your commercial terms. Where a clause commits you to something you do not currently do, either fix the gap, negotiate the language, or be honest with the buyer about your current position and a realistic path forward. Buyers who are serious about the deal are generally willing to negotiate reasonable adjustments, particularly with an early stage vendor, provided you engage constructively rather than either signing blindly or refusing to engage at all.

The honest takeaway

An MSA is not just a formality standing between you and a signed deal. The security and data clauses inside it are promises you will have to keep, sometimes for years, and signing without understanding them can create real exposure. Read them properly, negotiate what does not fit your reality, and make sure what you are committing to on paper matches what your product and your team can actually deliver.