The first enterprise contract: six clauses a small software vendor should read twice

The security questionnaire went back two weeks ago. The analyst had a few follow-up questions, you answered them, and this morning the buyer's procurement team sent "our standard terms" for signature. It is a 38-page master agreement, a 12-page data processing agreement, a service level schedule and an AI addendum that did not exist in their template last year.

For a five-person software company this is usually the largest contract it has ever been asked to sign, and the first one written entirely by the other side. Most of it is fine. A few clauses are not, and they are not the ones founders tend to argue about. This article goes through the six that carry real money or real work, what is normal to ask for in each, and when to pay a lawyer.

It follows on from the security questionnaire article. The questionnaire asked what you do. The contract turns some of those answers into promises.

First: whose paper?

Large buyers start with their own template, and their template was written for suppliers much bigger than you. Before you mark it up line by line, ask once whether they would accept your standard terms instead. If you do not have standard terms, there are free ones.

Common Paper publishes a plain-language Cloud Service Agreement for selling software as a service, free to use under a CC BY 4.0 licence (Common Paper). It has a cover page with the business terms and standard terms that sit at a fixed public address and do not change once signed. A buyer's lawyer can read a published standard faster than your own bespoke terms, and can check it against the same text other vendors use. Even when they say no, it gives you a reference point: "the market standard does it this way" is a stronger line than "we would prefer".

The rest of this article assumes they said no and you are reading their paper.

1. The limitation of liability

This is the clause that decides how much a bad day can cost you. Read it before anything else, and read the definitions it points to.

A typical shape has three tiers. Most claims are capped at the fees paid or payable in the twelve months before the claim. A short list of claims, almost always data breaches and breaches of confidentiality, sits under a separate, higher "super cap". And a few claims have no cap at all. Common Paper's standard uses exactly these three tiers, calling them the General Cap, Increased Claims and Unlimited Claims, and lets the parties choose the multiples on the cover page.

What goes wrong for a small vendor is rarely the general cap. It is the other two:

Data breach left uncapped. A buyer's template may move "breach of data protection obligations" into the unlimited tier. For a vendor holding the buyer's customer data, that is a bet of the whole company on never having an incident. Ask for it to sit under a super cap instead, and set that cap at a figure your cyber insurance actually covers. Then check the policy. Many small companies discover at this point that they have no cyber cover, or a limit far below what the buyer is asking for.

A cap that is mutual on paper only. "Each party's liability is limited to fees paid" sounds even. But the buyer's main obligation is to pay you, which is not limited by the cap anyway, so in practice only your exposure is capped. That is normal and fine. What is not fine is a cap with carve-outs that apply only to the vendor. Read the exclusions list for each party.

Indirect damages. Most agreements exclude lost profits and consequential losses for both sides. Check that the exclusion survives in the super cap tier too, or a data incident becomes a claim for the buyer's lost business.

The right-hand column matters. A small vendor who argues about everything gets a slower deal and a tired counterpart. Concede what costs you nothing and save the time for the uncapped data clause.

2. The service levels and credits

The schedule will promise availability, often 99.9% a month, and give the buyer a credit off the next invoice when you miss it. Do the arithmetic before agreeing to a number. A 30-day month has 43,200 minutes. At 99.9% you may be down for 43 of them. At 99.99%, four.

Now look at what your own host promises you. Amazon's compute service level, for example, gives a 10% credit if a region is available less than 99.99% of the month, 30% below 99%, and 100% below 95%, and says that is your "sole and exclusive" remedy (AWS). Read your host's version. Whatever you promise on top of it is a promise you keep with your own staff and your own architecture, not theirs.

Four things to check in the schedule:

How downtime is measured. By your monitoring, theirs, or "as reasonably determined by Customer"? Ask for yours, with the buyer able to report an outage you missed.

What is excluded. Planned maintenance with notice, the buyer's own network, outages of third-party services you told them about. Without these, a cloud provider's outage counts against you in full.

Whether credits are the only remedy. If credits are the sole remedy for downtime, the worst case is a known number. If the agreement is silent, a long outage can also be argued as a breach of contract under the general cap. Ask for credits to be the sole remedy, with a right for the buyer to terminate after repeated misses. Common Paper's sample wording offers termination with a prorated refund after two consecutive bad months, or three in any twelve. Buyers usually accept that trade.

Response times. Some schedules promise a reply to a critical ticket in 15 minutes, around the clock. Five people cannot do that without someone being on call every night. Offer what you can staff, in writing, and price anything faster as a support plan.

3. The data processing agreement

If your product handles personal data about people in Europe or the UK, the buyer must have a contract with you that covers the points in Article 28 of the GDPR. Their DPA template will be long, but most of it restates the law. Three parts are worth slowing down for.

Sub-processors. The law says you may not engage another processor "without prior specific or general written authorisation" of the buyer, and that under a general authorisation you must tell them of changes, "giving the controller the opportunity to object" (GDPR Article 28). Ask for the general kind. Specific authorisation means asking permission every time you add an email provider or switch AI model provider, which a small company does several times a year. Agree a notice period you can keep (30 days is common) and a published list you update.

Breach notice. The GDPR asks a processor to tell the controller "without undue delay". Templates turn this into a fixed number of hours, sometimes 24, sometimes fewer, counted from when you "become aware". Agree a figure you can meet on a weekend, counted from confirmation rather than suspicion, and make sure it matches whatever you wrote in the questionnaire. If you said 72 hours there, do not sign 24 here.

Where the data lives. Check the clause on transfers outside the buyer's region against your actual stack: the database, the backups, the error tracker, the email sender and the model provider. The model provider is the one most often forgotten.

4. Audit rights

The GDPR also says a processor must "allow for and contribute to audits, including inspections" by the controller or an auditor it appoints. Buyer templates take this literally: on-site audits, at any time, at your cost, by any auditor the buyer chooses.

You cannot remove the right, and you should not try. You can shape it. A version most buyers accept:

This is where the questionnaire work pays back. A vendor with a well-kept answers file can satisfy most audit requests by sending it again with a date on it.

5. The AI clauses

This is the new section, and it varies more between buyers than any other part of the contract. Most AI addenda ask for some version of four things.

No training on our data. The buyer wants a promise that its content will not be used to train or improve models, yours or your provider's. Check what you actually do first. Common Paper's standard, for instance, by default allows a provider to use usage data and customer content to train models in its own products, after aggregating and de-identifying it; buyers often strike that sentence, and the standard provides a way to do so. If you do not train on customer data, agreeing is free. Then check your model provider's terms for the plan you are actually on, and keep a link to that page with the date you read it.

Notice of model changes. Some buyers now ask to be told before you change the AI model behind a feature, or to approve the change. Approval is not workable: providers retire models on their own timetable, sometimes with two months' notice. Notice is workable, if it is short. Offer something like "we will notify the customer of a change of AI model provider at least 30 days in advance, and of a change of model version within the same provider without undue delay". The reason this matters, and what a forced switch actually costs, is the subject of what a model deprecation notice costs a small product.

Accuracy of outputs. Templates sometimes ask the vendor to warrant that AI output is accurate. Nobody can honestly promise that. Offer instead to describe what the feature does, say that outputs may be wrong and need human review where it matters, and warrant that the feature works as the documentation describes. Common Paper's wording is a useful model: outputs "may be incorrect or inaccurate" and are "not a substitute for human oversight".

A way to turn it off. If the buyer can switch AI features off for their whole account, many of the other AI clauses become less contentious, because a cautious team can simply not use them. If you can build that switch, it is often the cheapest concession in the whole negotiation.

6. Termination and the exit

Small vendors tend to read the termination clause as "how do we get out". The buyer reads it as "how do we get out, and what happens to our data". Three points:

Termination for convenience. The buyer may ask to be able to end the agreement at any time for no reason. If they prepaid a year, that can mean refunding months of revenue you have already spent on staff. A fair compromise is to allow it, with no refund of fees already paid, or only after the first year. Common Paper's standard does not give either party a right to terminate for convenience at all; you can point to that.

Auto-renewal. Check the renewal notice window and put the date in a calendar. Large buyers cancel by sending a form letter 90 days before renewal, sometimes by mistake, and a missed renewal date is the one way to lose a happy customer to paperwork.

Data at the end. Expect to return or delete the buyer's data within a fixed period after the end. Common Paper uses 60 days on request. Make sure the number covers your backups as well: if backups are kept for 90 days, a promise to delete everything within 30 is one you will break automatically. Say what format the export comes in, and whether you charge for help moving to the next supplier.

What else to skim, not skip

Insurance. A schedule listing the policies you must hold and their limits. Compare it with your actual certificates before signing; if you do not hold the cover, it is a breach on day one.

Order of precedence. Which document wins when the master agreement, DPA, order form and their security policy disagree. You want the signed order form and the DPA to win over their general policies.

Their policies by reference. "Supplier shall comply with Customer's Information Security Policy as updated from time to time." Ask for a copy of the version you are agreeing to, and for changes to apply only once both sides agree.

Most favoured customer. A clause saying no other customer will get a better price. For a small company still finding its pricing, that is a constraint on every future deal. Ask to remove it.

When to pay a lawyer

Not for everything. A small vendor can read most of a template with the list above and a free afternoon. Pay for an hour or two of a commercial lawyer's time when any of these is true:

The liability clause leaves anything uncapped beyond fraud and wilful misconduct, or puts a figure larger than your insurance on the table.

There is an indemnity for anything other than intellectual property infringement, especially for data protection fines or third-party claims about your AI outputs.

The governing law is a country you have never done business in, or disputes go to a court you could not afford to travel to.

The contract is worth more than a year of one person's salary. At that size, the lawyer's fee is small next to the risk of signing something you cannot keep.

Ask for a fixed fee to review one contract against a list of your concerns. Bring the list. A lawyer who is told "look at the liability, the DPA and the AI addendum, the rest we can live with" costs far less than one asked to review everything.

Keep a playbook

The second enterprise contract will look very like the first. Keep a short document: each clause you negotiated, what they asked for, what you agreed, and the wording that worked. Note your insurance limits, your real breach notice time and your sub-processor list next to it. By the third customer you will have your own standard positions, and your answers will arrive in the buyer's inbox the same day, which a procurement team notices more than any single concession.

Sources

Common Paper, Cloud Service Agreement (version 2.1) (the three liability tiers, the sample service level remedy, the 60-day deletion, no termination for convenience, the machine learning and AI output wording); GDPR Article 28, processor (sub-processor authorisation and objection, audits and inspections); Amazon EC2 service level agreement (credit tiers and the sole remedy wording). Pages read on 15 October 2026. The tables, suggested positions and sample wording are our own, drawn from common practice in software contracts; they are not legal advice, and a contract you will sign deserves a lawyer's eye where the list above says so.