How to Review a SaaS Agreement: An In-House Playbook

The SaaS deal that burns you looks harmless. It is $18,000 a year, so it never gets a real review. It touches your customer data, it auto-renews for twelve months on 90 days' notice, and it caps all liability at fees paid. Low dollar, high risk, waved through because the number was small. That is the pattern in-house teams miss, and it is why a SaaS agreement needs a different read than a professional-services contract of the same size.

A SaaS agreement is a subscription to someone else's software running on someone else's infrastructure, holding your data. The risk is not in the commercial terms you already know how to read. It sits in the SaaS-specific clauses: what happens to your data, what the vendor actually promises on security and uptime, how the price climbs at renewal, whether the vendor can train AI on your content, and who is liable when a sub-processor two layers down leaks your records. This playbook goes straight to those, with the position to take on each.

TL;DR

• Price is not risk. An $18k tool holding customer data can hurt you more than a $200k tool that touches none. Review by data sensitivity, not deal size.
• The DPA is the whole game. No signed, compliant data processing agreement when personal data is in play is a hard stop.
• The SLA is only as good as its remedy. A 99.9% uptime promise backed by a token service credit is marketing, not protection.
• Auto-renewal plus an uncapped increase is the most common SaaS budget trap. Fix the notice window and cap the uplift in writing.
• The liability cap must carve out data breach. A cap tied to 12 months of fees is meaningless if the vendor loses your customer database.
• AI vendors get an extra clause: no training on your data, and no reuse of your outputs. "Improve the services" is a data-rights grant in disguise.

Which SaaS deals actually need a full review

Triage first, so the queue does not drown you. A SaaS contract needs a real review, whatever the price, if any of these is true:

• It processes personal, health, financial, or children's data (which pulls in state privacy laws, HIPAA and a BAA, GLBA, or COPPA).
• It gets production-database or admin access, or SSO into your identity provider.
• It runs on sub-processors you cannot see or control.
• It is an AI vendor that could train on your content.

If none is true, a $10k tool is fast-path: check the cap, the term, and auto-renewal, and move on. If several are true, it is a deep review no matter how small the invoice.

Data type also sets your positions:

• Employee data (HRIS): most state privacy laws exclude it, except California, so scope by where your workforce sits.
• Customer PII (CRM, support tools): the data-breach carve-out and a compliant DPA are non-negotiable.
• Health data: you need a Business Associate Agreement, not just a DPA.
• Financial data: GLBA service-provider terms apply on top of the DPA.
• Code repositories or production access: IP and security terms matter as much as data terms, because a leak here is your source code or your customers.

The SaaS-specific clauses, with accept / push / escalate

Run these after a standard commercial review. For each, here is the buyer-side market position, what to push for, and when to escalate. These are common positions from in-house practice, not a published survey, so your leverage and the vendor's data exposure shift them.

How to review a SaaS agreement clause by clause

1. Data ownership and use

The contract should say plainly that you own your data, and the vendor gets only a limited license to host and process it to deliver the service. The trap is a broad right to use your data to "improve the services," which is wide enough to cover analytics, benchmarking, and AI training. Pin it down: narrow the license to service delivery, and for anything sensitive, strike the improvement language.

2. Data processing agreement (DPA)

If the service touches personal data, a signed, compliant DPA is mandatory, not a nice-to-have, and US state privacy laws now require the controller/processor terms explicitly (see US state privacy laws in 2026). Check the four high-leverage items: transfer mechanism, breach clock in defined hours, sub-processor list plus an objection right, and breach liability carved out of the cap. The common dodge is a sub-processor "list" that is just a webpage the vendor can change without notice, so require notice and objection, not a link. The full method is in the DPA review field guide.

3. Security commitments

You want a named standard (SOC 2 Type II or ISO 27001), the right to see the current report, encryption in transit and at rest, and a defined incident-response process with a real breach-notification deadline (48 to 72 hours from the vendor becoming aware, not "without undue delay"). A vendor that will not share its SOC 2 report is telling you something.

4. Uptime and the SLA remedy

The uptime number matters less than what happens when the vendor misses it. Service credits are usually the sole remedy, so check the credit is meaningful and, more important, that chronic or severe downtime gives you a termination right. A 99.9% promise with a 5% credit and no exit is a number, not a protection. Confirm what the vendor excludes as scheduled maintenance, because a generous exclusion hollows out the whole SLA.

5. Auto-renewal and price increases

Read the renewal clause for the notice window and the price-increase mechanism. The trap is a 90-day notice on an auto-renew: nobody calendars it, and you are locked into another year at a price the vendor was free to raise. Shorten the window, calendar the reminder at signing, and cap the increase in writing.

6. Liability and the exit

The limitation of liability must put data breach and IP indemnity outside the cap. This is the single most important SaaS carve-out, and the one vendors resist hardest. The negotiation ladder runs from uncapped breach liability (rare) down through a security-obligation super-cap, a data-breach super-cap, and finally the plain general cap. Vendors fight each rung because it enlarges their tail risk, and when they will not move on the cap at all, a contractual cyber-insurance requirement (say $5M, naming you as an additional insured for data claims) is the common backstop. On the exit, get your data back in a usable, non-proprietary format on a defined timeline, followed by return or deletion with confirmation, so the vendor is not holding your records hostage. See the limitation of liability clause.

AI SaaS vendors: the clause a standard review misses

If the vendor's product is or uses a model that touches your content, add one position: no training on your data. The default you want is an explicit contractual statement that the vendor will not use your data, prompts, or inputs to train or improve any model, and will not share them with its model providers for that purpose. A vague "to improve the services" line is broad enough to cover training, so it is a data-rights grant, and you read it as one.

Here is the judgment call that separates a real reviewer: do not spend an hour fighting for mutual indemnity while the vendor keeps a broad right to train on your customer data. The training grant is the bigger exposure. Trade the smaller redlines to win it.

This is not hypothetical. When Zoom's 2023 terms were read to permit training AI on customer content, the backlash was loud enough to force a public walk-back, and enterprise AI vendors like OpenAI and Anthropic now market no-training-on-your-data as the default for their business and API tiers. That shift is why an explicit contractual no-training clause is both a reasonable ask and one you can usually win. If a vendor will not put it in writing, treat the refusal as the answer.

Red flags, as the scenarios they actually are

The vendor that will not carve breach out of the cap. You ask to put data-breach liability outside the 12-month-fees cap. The vendor refuses and offers only the base cap. On a vendor holding your customer PII, that means your maximum recovery for a breach is a few months of fees against a seven-figure incident. Escalate or walk.

The sub-processor webpage. The DPA lists sub-processors "as updated at vendor.com/subprocessors." The vendor can add a new one, in a new country, without telling you, and you have agreed in advance. Require notice and an objection right, not a link.

The $18k tool that auto-renews. Low dollar, so it skipped real review. It holds customer data, auto-renews for a year on 90 days' notice, and caps all liability at fees. Twelve months later you are still on it, at a higher price, because the number looked too small to bother with.

Sample fallback language

Redline-ready language for the clauses worth the fight.

• No AI training: "Provider shall not use Customer Data, including inputs and prompts, to train, fine-tune, or improve any model, nor share it with any model provider for such purposes."
• Data-breach super-cap: "Provider's liability for breach of its data-security obligations shall not exceed three times (3x) the fees paid in the prior 12 months, separate from and in addition to the general cap."
• Sub-processor control: "Provider shall give Customer at least 30 days' notice of any new sub-processor and a right to object, and shall bind each sub-processor to data-protection terms no less protective than this Agreement."
• Exit and data return: "On termination, Provider shall make Customer Data available for export in a commonly used format for 30 days, then delete it and certify deletion."

Running SaaS review at volume

Most in-house teams review the same SaaS clauses over and over, which makes it a delta check: where does this agreement deviate from your standard on data, security, renewal, liability, and AI training. In Vaquill AI, a structured review flags the missing DPA terms, the trivial SLA remedy, the uncapped renewal, and the "improve the services" grant, with the language quoted so you redline in one pass. For how AI fits SaaS legal teams, see legal AI for SaaS in-house counsel.

FAQ

What should I look for in a SaaS agreement? Beyond standard commercial terms, take a position on data ownership and export, a compliant data processing agreement, security and uptime commitments with real remedies, auto-renewal and price-increase terms, a liability cap that carves out data breach, and, for AI vendors, no training on your data.

Does a SaaS contract need a DPA? When the vendor processes personal data on your behalf, yes. A compliant data processing agreement is required under GDPR and US state privacy laws where those laws apply and the vendor acts as a processor or service provider, and no DPA in that situation should be a hard stop.

What is a good uptime SLA for SaaS? 99.9% is a common commitment, but the remedy matters more than the number. Confirm the service credits are meaningful, that chronic or severe downtime gives you a termination right, and check what the vendor excludes as scheduled maintenance, since a broad exclusion guts the SLA.

How do I avoid SaaS auto-renewal traps? Shorten the notice window, calendar the deadline at signing, and cap any renewal increase in writing (a common ask is 5 to 7%). A 90-day notice on an auto-renew with an uncapped increase is how an affordable year one becomes an expensive year two.

Who owns the data in a SaaS agreement? You should. A well-drafted SaaS contract states the customer owns its data and grants the vendor only a limited license to host and process it. Watch for broad rights to use your data to "improve the services," which can cover analytics, benchmarking, and AI training.

What should I check in an AI SaaS vendor contract? Whether the vendor can train on your data (you want an explicit no), who owns the AI outputs, how "improvement" or "feedback" clauses grant data rights, and whether your data terms flow down to the vendor's model providers and sub-processors.

What happens to my data when a SaaS contract ends? The contract should give you an export in a usable format on a defined timeline, then return or deletion with confirmation. Vague exit terms risk losing access to your own records or leaving them with the vendor indefinitely.

Start free trialBook a demo

For more, see the contract review checklist, the DPA review field guide, and legal AI for SaaS in-house counsel.

Arshita Anand

Co-Founder & CEO · Attorney

Arshita leads product and strategy at Vaquill, building the legal AI suite that solo, small-firm, and in-house US lawyers use to run a matter end to end.