What your SaaS terms and conditions must cover

There is nothing wrong with starting from a template. Every commercial lawyer starts from something. A good template saves you from forgetting an entire category of term, and it gets the architecture roughly right: definitions, licence grant, payment, data, liability, term and termination.

What a template cannot do is know anything about your product. It does not know what your software does, what data it touches, how it is hosted, what your support team can realistically respond to, or how much margin sits in a typical account.

So it fills those gaps with wording that sounds reasonable in the abstract. Reasonable in the abstract is not the same as true for you.

Before you touch the wording, write down the plain answers to five questions. Every meaningful term in your terms and conditions follows from these.

• What does it do: the function you are actually selling, described the way a customer would describe it, not the way marketing does.
• What data does it touch: personal data, payment data, client files, employee records, anything regulated, and where it is stored.
• What does it depend on: hosting, third party APIs, models, payment providers. Anything you resell is something you are now on the hook for.
• What can you promise on availability: what your infrastructure genuinely sustains on a bad month, not on a good one.
• What is a deal worth: because your liability cap should bear some relation to the revenue, not to a number a template picked.

Answer those honestly and most of your terms write themselves. Skip them and you are simply hoping the template guessed well.

Across the SaaS terms I review, the same handful of clauses cause the same problems, and they are almost always inherited rather than written.

• Availability: a template that mentions uptime at all tends to pick a round, impressive number. If it appears in your terms, it is a promise, and missing it is a breach.
• Data protection: generic wording rarely matches how your product actually processes data, who your sub-processors are, or where the data sits.
• Liability: caps copied from another business bear no relation to your deal sizes, and exclusions drafted for a different model may not hold.
• Intellectual property: the licence grant is often wider than intended, and feedback, configuration and customer data ownership go unaddressed.
• Termination and exit: what happens to customer data on the way out is the clause most likely to be missing entirely, and the one enterprise buyers ask about first.
• Support: response commitments get inherited from businesses with support teams you do not have yet.

The problem with inherited terms is that they are invisible until they are expensive. Nobody reads your terms on the way in. They read them at the moment something has gone wrong, and they read them looking for the sentence that helps them.

A founder I worked with shipped on an off the shelf template. Six months later a customer held them to an availability commitment the template had made and the product had never been built to keep. The commitment was never a commercial decision. It was a line nobody had reread since the day it was pasted in.

That is the pattern. Not a dramatic drafting error, just a promise made on the business’s behalf by a document it did not write.

You do not need a rewrite. You need a pass that reconciles the document against the product. In practice that is a short, structured exercise.

• Read only the promises: every sentence where you commit to do, achieve or maintain something. Check each against reality.
• Reprice the liability: set the cap against actual contract value and your insurance position, not against a template default.
• Match the data terms to the architecture: including every sub-processor you genuinely rely on.
• Close the exit: say plainly what happens to data and access on termination, in both directions.
• Delete what does not apply: clauses about things you do not do are not harmless. They confuse the picture and can create obligations.

Done properly this is a focused piece of work, not a project. It is also considerably cheaper than the alternative, which is discovering the gap during a dispute or halfway through enterprise due diligence.

Choice, understood. Start from a template. Ship terms that fit the product.