A Noida startup sells a billing and inventory tool to three hundred shops and clinics on monthly plans, with terms copied from an American company’s website. Then a pharmacy chain asks for a proper agreement, a hospital asks where patient data is stored, a bank’s procurement team sends a forty-page questionnaire, and a customer who stopped paying demands its data back in a format the product does not export. Software sold as a service is sold on trust — that it will be available, that data put into it is safe, and that the customer can leave. The subscription agreement is where that trust is written down. This page explains how to write it, for providers and for the businesses that buy from them.
Traditional software was sold as a product: the customer bought a licence, received a copy on a disc or as a download, installed it on its own computers, and ran it. Software as a service reverses that. The provider runs the software on its own servers or cloud infrastructure, and the customer uses it through a browser or an app, paying a subscription for as long as it wants access.
That shift changes the legal character of the deal. The customer usually receives no copy of the software, so the heart of the contract is not a licence to use a copy but a promise to provide a service — to keep the software available, secure and working, to store the customer’s data, and to return it when the customer leaves. Many SaaS agreements still include a licence, because customers use the provider’s documentation, mobile apps, browser extensions or on-premise connectors, but the obligations that matter are those of a service provider.
Three consequences follow. First, availability and support become central, because the customer cannot run the software itself if the provider fails. Second, the customer’s data sits with the provider, so data ownership, privacy and security move from the back of the contract to the front. Third, the customer’s ability to leave — with its data, in usable form — is what keeps the relationship fair, because switching costs in SaaS are high.
This page is written for both sides. A provider needs terms that can be accepted quickly by hundreds of small customers and negotiated sensibly with large ones. A customer needs to know which clauses to look for before it moves its business onto someone else’s servers.
Most SaaS providers use a layered set of documents rather than one long contract for each customer:
| Document | What it contains | How often it changes |
|---|---|---|
| Master subscription agreement | The legal terms: fees mechanism, data, IP, liability, termination, disputes | Rarely; versioned |
| Order form | The customer, the plan, users or usage, price, term, start date, special terms | For every customer and every upgrade |
| Service level schedule | Availability, maintenance windows, credits, support hours and response times | Occasionally |
| Data processing addendum | Processing of personal data, sub-processors, security, breaches, deletion | When law or sub-processors change |
| Security schedule | Controls, certifications, audits, penetration tests | Annually |
| Acceptable use policy | What customers and their users may not do with the service | Occasionally |
The order form should say which prevails in case of conflict — usually the order form for commercial points specific to the customer, and the master agreement for everything else — and should list exactly which versions of the schedules apply. A customer should keep a copy of the versions it accepted, because online documents change.
Enterprise customers often send their own procurement terms. Where the parties sign both sets, the agreement should state which prevails, or the parties will later argue over which document governs a problem neither expected.
Small customers usually accept terms online, by clicking during sign-up. Larger customers sign a negotiated agreement. Both are valid ways of making a contract.
Online acceptance works if the terms are presented clearly before the customer commits, the customer takes a positive step to accept, and the provider keeps a record of what was accepted and when. Our website terms guide explains how online contracts are formed and why clickwrap is stronger than browsewrap. The same guide explains the limits on one-sided terms, particularly unfair terms against consumers.
A provider that serves both kinds of customer should use the same core terms online and in negotiated contracts, with negotiated changes recorded in the order form. Maintaining two completely different sets of terms leads to inconsistent promises and support teams who do not know which applies.
Where the provider updates its online terms, it should tell existing customers in advance, allow them to object or leave before material changes take effect for them, and keep previous versions available. Our website terms guide covers changing terms and keeping versions.
The order form should describe exactly what the customer is buying. SaaS pricing is usually built on one or more of these measures:
The agreement should say how usage is measured, where the customer can see it, what happens when limits are exceeded, and whether unused volumes roll over. Surprise overage charges are one of the commonest reasons SaaS relationships sour.
Many SaaS products are not usable on day one. They need configuration, data migration from the customer’s old system, integration with its accounting, payment or messaging tools, and training. That work is a separate service and should be described separately:
Customers are often surprised to find that the subscription clock started months before the system was actually in use. A clause starting the subscription on go-live, or giving a free implementation period, avoids that argument. If the implementation is really custom development, a software development agreement may be the right document for that part.
How such build work is specified, tested and handed over — requirements, user acceptance testing, deemed acceptance and code ownership — is explained in our software development agreement guide.
The fees clause should state:
Annual prepayment is attractive to providers and often comes with a discount. Customers who prepay should make sure the agreement refunds the unused portion if they terminate because of the provider’s breach or the provider discontinues the product.
An Indian provider registered as a micro or small enterprise may also be able to use the statutory protection against late payment by business buyers, which our freelance agreement guide describes.
Most subscriptions renew automatically for successive terms unless either party gives notice. That is convenient for both sides, but three rules should be observed.
Tell the customer clearly. The order form and invoices should state the renewal date, the notice period for cancelling, and the renewal price. Many providers send a reminder before annual renewals, which is good practice for businesses and increasingly expected for consumers.
Price changes at renewal. A business customer will want the price fixed for the current term and increases only at renewal, on notice of at least a month or two before the cancellation deadline, sometimes capped at a percentage. A clause allowing the provider to raise prices at any time should be resisted.
Recurring payments. Where fees are collected by card or UPI autopay, the RBI’s framework for e-mandates applies to the bank and payment provider: the customer registers the mandate with authentication, receives a pre-debit notification before each charge, and can withdraw the mandate. Transactions above a set limit need additional authentication. The subscription agreement should be consistent with how the mandate is actually set up, and should not promise the provider a right to debit amounts the mandate does not cover.
For consumer subscriptions, the Central Consumer Protection Authority’s guidelines on dark patterns list the subscription trap — making cancellation difficult, hiding auto-renewal, or taking payment details for a “free” trial without clear disclosure — as a prohibited practice. Cancellation should be as easy as sign-up.
For a business that runs its operations on a SaaS product, availability is the most important promise in the agreement. The service level schedule should cover availability, measured monthly; scheduled maintenance windows and notice; how downtime is measured; service credits; and support hours, channels and response times by severity.
We do not repeat the detail here, because our service level agreement guide works through each element: how to express uptime, how to define severity levels, how service credits should be framed, and why credits should be the price adjustment for ordinary failures while chronic failure gives a right to terminate. Our SLA drafting service prepares the schedule.
Two points are specific to SaaS. First, availability should be measured at the provider’s service boundary, not the customer’s own internet connection, and the agreement should say so. Second, many SaaS products depend on third-party cloud infrastructure. The provider remains responsible to its customer for availability, but it should not promise more than its own infrastructure providers commit to, unless it has built redundancy.
SaaS products change constantly. The provider needs freedom to improve the product; the customer needs assurance that features it relies on will not disappear overnight. A balanced clause:
Customers who integrate the product with their own systems through APIs should look particularly at API versioning and deprecation notice, because an unannounced API change can break their operations even though the SaaS itself keeps running.
Every business SaaS agreement should say, in plain words, that data the customer and its users put into the service belongs to the customer. The provider needs a licence to that data, but only to host it, process it, back it up and display it as needed to provide the service to that customer, and to comply with law.
The questions that then need answers:
A clause that gives the provider broad rights over “all data submitted to the service” for any purpose is a warning sign for a customer, and increasingly a commercial problem for providers selling to larger businesses.
Almost every business SaaS product processes personal data — the customer’s employees, its clients, its patients, its students. The Digital Personal Data Protection Act, 2023 decides who is responsible for that data.
Where the business customer decides the purpose and means of processing — it chooses to keep its patient records or payroll in the product — the customer is the data fiduciary, and the SaaS provider processes the data on its behalf as a data processor. The Act allows a fiduciary to engage a processor only under a valid contract, and holds the fiduciary responsible for what the processor does. That is why business customers ask for a data processing addendum, and why providers should have one ready. Our data protection guide explains processors, breach intimation and transfers outside India in detail, and our data processing agreement service prepares the addendum.
For a clause-by-clause treatment of the addendum itself, including how to review a customer’s or vendor’s paper, see our data processing agreement guide.
The addendum should cover:
Where the provider uses personal data for its own purposes — marketing to users, analytics about individuals, training its own models — it may be a data fiduciary for those purposes, with its own duties of notice and consent. The rules under the Act were notified in 2025 with phased commencement, so providers should check which obligations are already in force. Our DPDP compliance review helps providers map their position.
SaaS products increasingly include AI features — drafting, summarising, forecasting, chat assistants — often powered by third-party models. This raises questions that older agreements do not answer.
Indian law does not impose a general rule that business data must stay in India, and the DPDP Act permits transfers outside India except to countries the government restricts. But several sector rules do require local storage, and customers increasingly ask anyway.
The agreement should state the hosting region, the cloud infrastructure provider, whether data may be moved to another region, and on what notice.
Security obligations are best set out in a schedule that can be updated, rather than in the body of the agreement. It should describe the provider’s controls in terms a customer’s IT team can assess: encryption in transit and at rest, access control and multi-factor authentication for staff, logging and monitoring, vulnerability management and penetration testing, secure development, business continuity and disaster recovery, and any certifications the provider holds.
Two legal duties run alongside the contract: CERT-In’s short deadline for reporting specified cyber incidents and its rule on keeping system logs in India, and the duty under the data protection law to report personal data breaches. Our service level agreement guide summarises both in its section on data protection and security. For a SaaS product the practical point is that the provider’s clock and the customer’s clock start at different moments, so the agreement should require the provider to tell the customer about any incident touching its data quickly enough for the customer to meet its own deadlines, to share what it knows as the investigation proceeds, and to preserve the evidence.
Customers should also ask what happens when the customer itself is at fault — a user shares a password, an administrator grants excessive access — and the agreement should allocate responsibility for account security to the customer for its own users.
An acceptable use policy protects the provider from customers who use the service for spam, fraud, infringement, harassment, attacks on other systems or unlawful content. It should list the prohibited uses, the provider’s right to investigate and suspend, and the customer’s responsibility for its own users.
Where customers can publish or share content through the service, the provider may be an intermediary under the Information Technology Act, with due diligence obligations and a conditional safe harbour. Our website terms guide explains intermediary obligations and user content.
The provider owns the software, the platform, its documentation, and improvements to them. The customer owns its data and its outputs. Between those two, the agreement should deal with:
Providers building their own product should make sure the code actually belongs to the company; our freelance agreement guide explains why an assignment in writing is needed from outside developers. The product name should be protected by a trademark registration.
A reasonable provider warranty says that the service will perform materially as described in its documentation, that the provider will not materially reduce security or functionality during the term, that implementation services will be performed with reasonable skill, and that the provider will comply with laws applicable to it as a provider. The remedy is usually to fix the problem, and if it cannot, to allow the customer to terminate and recover prepaid fees for the unused period.
Beyond those warranties, providers disclaim other promises — that the service will be error-free or uninterrupted, or fit for every purpose. Disclaimers are generally accepted between businesses, but a disclaimer that contradicts the provider’s own marketing is weak, and against consumers, sweeping disclaimers may be unfair terms.
SaaS providers serve many customers at low prices, and cannot carry unlimited liability to each of them. Standard terms therefore cap liability, commonly at the fees paid or payable in the twelve months before the claim, and exclude indirect and consequential loss, such as loss of profits or data. Our website terms guide discusses liability limits in online terms.
Customers negotiate in three directions:
Providers, in turn, cap their exposure to what their insurance and pricing can support, and exclude liability for the customer’s own misuse, third-party services the customer connects, and content the customer uploads. A cyber liability insurance policy is increasingly expected of providers selling to large customers.
Suspension — switching off access without ending the agreement — is a powerful remedy, and should be used proportionately. Legitimate grounds include non-payment after notice, a security threat, a breach of the acceptable use policy, or a legal requirement. A fair suspension clause:
Customers should be particularly careful about suspension where the SaaS product runs their billing, pharmacy, patient or payroll operations, because even a short suspension can stop the business.
Every SaaS relationship ends eventually. The agreement should make the end orderly.
Our service level agreement guide discusses exit planning for outsourced services generally. For SaaS, the single most useful test a customer can run before signing is to ask for a sample export of test data and check that it can actually be used.
Many SaaS relationships begin without payment: a fourteen-day trial, a free tier with limited features, or a paid pilot for a large customer. Each needs its own terms, because the default assumption — that the full agreement applies from the first login — rarely fits.
Business SaaS rarely stands alone. It connects to the customer’s accounting software, payment gateway, messaging provider, identity system or other SaaS products, through the provider’s API or through ready-made integrations. The agreement should cover:
SaaS is often sold through others: implementation partners who resell subscriptions, IT distributors, cloud marketplaces, or larger platforms that bundle the product. Each channel changes who the customer’s contract is with.
Commissions and revenue shares with resellers raise their own drafting points, which our revenue sharing guide covers for digital products.
A customer that runs its business on a small provider’s product faces a real risk: the provider may run out of money, be acquired by a competitor, or discontinue the product. The agreement cannot remove that risk, but it can reduce the damage.
Enterprise buyers now send security and privacy questionnaires before signing: where data is hosted, who can access it, how staff are vetted, how incidents are handled, which certifications the provider holds, which sub-processors it uses. For a young provider, the questionnaire is often the first time these questions are asked.
The answers matter legally as well as commercially. Statements in a questionnaire can be treated as representations that induced the contract, and a customer who relied on a false answer may have remedies for misrepresentation. Providers should therefore answer accurately, keep a record of what was said, and make sure the security schedule in the agreement matches the answers. Customers, for their part, should attach the key answers to the agreement, or have them warranted, rather than relying on a spreadsheet exchanged months before signing.
Inside a business customer, a SaaS account is used by many people, and most security failures begin with account management rather than with the provider’s systems. The agreement and the product’s administration settings should work together:
For small customers, the most common dispute is simpler: the only person who knew the administrator password has left, and the owner of the business cannot get in. A documented account recovery process, requiring proof that the requester represents the customer, saves both sides a difficult conversation.
An Indian SaaS provider must register for GST once its turnover crosses the threshold for suppliers of services, and may register voluntarily earlier so that business customers can claim input tax credit on its invoices. Our GST registration service handles the application. Once registered, it charges GST on subscription and implementation fees, issues tax invoices showing the customer’s GSTIN, and, once its turnover crosses the limit for electronic invoicing, generates invoices through the e-invoicing system. Business customers will reject invoices that do not meet these requirements, so billing systems should be set up correctly before the first enterprise sale.
The agreement should state that fees are exclusive of GST, that GST will be charged at the applicable rate, and that the customer will provide its GSTIN and billing address. Where the customer deducts tax at source, the agreement should require it to issue certificates promptly so that the provider can claim credit.
Indian businesses buy a great deal of SaaS from providers outside India, usually on the provider’s standard terms. There is limited room to negotiate with the largest providers, but a customer should understand what it is agreeing to:
Indian SaaS companies increasingly sell to customers in other countries. Points to consider:
A SaaS product sold to individuals for personal use — a fitness app, a personal finance tool, a learning platform — is subject to consumer protection law as well as contract. The Consumer Protection Act, 2019 allows consumer commissions to declare unfair contract terms void, and treats misleading claims and unfair practices as actionable. The dark pattern guidelines apply to subscriptions, as explained above. Consumer terms should be short, plain and fair, with an easy route to cancel and a clear refund policy. Our website terms and conditions service and the website legal pack cover consumer-facing terms and privacy policies.
Some customers are bound by rules that flow into their SaaS contracts.
A negotiated SaaS agreement signed on paper or electronically is an agreement under the stamp law of the state where it is executed. It is worth stamping, since a court or tribunal will not act on an unstamped agreement until the shortfall and a penalty are made good; the duty for an ordinary agreement is small in most states. Electronic signatures are valid for such contracts. Online terms accepted by clicking are rarely stamped, and providers rely on records of acceptance instead. Our e-stamp guide explains how duty is paid.
Enterprise agreements should be signed by authorised signatories, with a board resolution where the customer or provider is a company that requires one.
Most SaaS disputes are about outages and credits, overage charges, suspension, data export at the end, and security incidents. The agreement should set a path: notice of the dispute, escalation to named senior contacts, and then arbitration or the courts at an agreed place. Technical questions, such as whether an outage was within the provider’s control, can be referred to an independent expert. Where an amount is simply unpaid, a legal notice often resolves it.
Arbitration and court proceedings are for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it. You can find an advocate through our directory.
The Noida startup in the introduction, selling billing and inventory software, wins a pharmacy chain with forty outlets. Its website terms, copied from a foreign company, promise nothing about availability, give the startup rights over “all data submitted”, and say nothing about data export.
The startup adopts a master subscription agreement, with an order form for the chain covering forty locations and a hundred and twenty users, annual billing, and a fixed price for two years with increases capped at renewal. A service level schedule commits to monthly availability, with credits and a right to terminate after repeated failures, and priority support during pharmacy hours. A data processing addendum treats the chain as data fiduciary for patient and customer data, lists the startup’s cloud host and messaging provider as sub-processors, and commits to breach notification. Customer data belongs to the chain; the startup may use only anonymised aggregate data for product analytics; no customer data trains any model. Liability is capped at twelve months’ fees, with a higher cap for data protection breaches. On termination, the chain has sixty days to export in CSV and database format, after which data is deleted with written confirmation.
The startup then uses the same master agreement for its small customers, accepted online, with a simpler order flow. Its sales team no longer negotiates each contract from scratch.
Dr. Mehta runs a dental clinic in Dwarka and is choosing between two practice-management products, one Indian and one foreign. Before signing, she asks each provider five questions drawn from this page: where patient data is hosted; whether data is used to train AI; how appointment reminders are sent and by whom; what export format is available; and what happens to data if she stops paying.
The Indian provider hosts in India, prohibits training on customer data, uses a named messaging provider as sub-processor, exports in a documented format, and preserves data for ninety days after suspension. The foreign provider’s terms allow data to be moved to any region, reserve rights to use “de-identified” data for any purpose, and delete data thirty days after non-payment. Price is similar. She chooses the first, pays GST on an Indian invoice rather than under reverse charge, and keeps a copy of the version of the terms she accepted.
A SaaS subscription agreement from us costs ₹4,999 and is ready in 2 – 5 days. We start from your product — what it does, what data it holds, how it is priced, who your customers are — and draft the document set around it.
| Included | Why it helps |
|---|---|
| Master subscription agreement and order form template | One set of terms for every customer, with the deal in the order form |
| Service level and support schedule | Availability and support promises that can be measured |
| Data processing addendum and sub-processor list | What enterprise customers ask for first |
| Security schedule and incident process | Answers to security questionnaires, and CERT-In readiness |
| Acceptable use policy and AI terms | Protection from misuse, clarity on training |
| Renewal, suspension, termination and data exit clauses | Fair terms at the start and the end |
Stamp duty, where needed, is extra at actual cost, and we tell you the total before we start. Tax and foreign exchange treatment is for your chartered accountant, and security certifications for your auditors. If a dispute ever reaches an arbitrator or a court, it is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it.
Customers who move their business onto your software are trusting you with availability, data and a way out. A clear subscription agreement turns that trust into terms your sales team can offer confidently and your customers can accept quickly. Tell us about your product, your data and your customers, and we will prepare the document set.
Two doors, both free. Clients search a factual directory of enrolled advocates. Advocates apply to be listed on it — no fee, no commission, nothing paid in either direction.
Search Bar Council enrolled advocates by what your matter is about, by court, or by city. Searching and sending a request are both free.
Enrolled advocates anywhere in India can apply to be listed. Your entry is published only after we verify your enrolment number with your State Bar Council.
This directory carries no ratings, no reviews, no rankings and no fees — only the factual particulars the Bar Council of India permits, published at each advocate's own request. Browse the network · Terms for Advocates