Four legal gaps most SaaS businesses have

Most SaaS agreements start as templates. The vendor’s template, drafted when the company was smaller, signed because the deal needed to close. The problem is not that templates exist. It is that they accumulate, and the clauses inside them drift further from the business’s actual position with every renewal.

The liability cap that only runs one way. The data provision that does not reflect the volume or type of processing actually happening. The auto-renewal term with a 90-day notice period nobody logged. The IP clause that assigns rights the business did not intend to give. None of these are obvious on a first read. All of them become obvious when something goes wrong.

• The fix: Review the liability cap, data provisions, IP terms, and exit clauses before every contract is signed, not after it is running.
• The signal that this gap exists: You are signing contracts drafted by the other side with no legal input on yours.

Under UK GDPR, whether you are a controller or a processor determines your legal obligations, your liability exposure, and what your data processing agreement must say. Most businesses know they need a DPA. Far fewer check whether the role they are accepting in that DPA matches what they actually do.

A SaaS vendor that makes independent decisions about how customer data is used, or that aggregates it across clients for model training, may be acting as a controller or joint controller, not a processor. Signing a DPA in the wrong role is a compliance gap that does not stay invisible forever. South Africa’s POPIA update and the broader pattern of regulatory enforcement moving from awareness to action makes this more pressing, not less.

• The fix: Before signing any DPA, check whether the role assigned matches your actual data relationship. Controller vs processor is a legal assessment, not a label to accept.
• The signal that this gap exists: You have signed DPAs without checking whether the processing description matches what you actually do.

Every AI feature in a SaaS product runs on someone else’s model. Every AI tool a business uses was built under someone else’s terms. The contracts governing those relationships are where the exposure starts, and most of them were written to protect the vendor, not the deploying business.

The CMA has confirmed that where a business deploys an AI system that causes harm, the deploying business is responsible, even if a third party built the underlying model. AI vendor agreements typically cap the vendor’s liability at a low level. Most SaaS businesses have not checked whether their AI vendor contracts, product terms, and DPAs reflect the AI features that are now running inside their product.

• The fix: Review AI vendor liability caps, check whether product terms reflect what the AI actually does, and confirm DPAs cover AI data flows.
• The signal that this gap exists: You have shipped AI features without reviewing the contractual stack around them.

Most people review a contract front to back. They slow down when something looks complex and speed up when something looks standard. The problem is that the clauses carrying the most risk are often not the ones that look complex. They are the ones that read as routine, right up until they are enforced.

Reviewing in order of risk means starting with liability and indemnity, then payment and exit terms, then IP and data provisions, then confidentiality, then governing law and boilerplate. It means the highest-exposure terms get scrutinised first, while attention is fresh and there is still time to negotiate.

• The fix: Review contracts in order of risk, not page order. Liability first. Boilerplate last.
• The signal that this gap exists: You review contracts front to back and rely on flagging what looks unusual rather than what is highest risk.