Most SaaS Master Service Agreements signed in India are not written for India. They are lightly-adapted versions of US-style templates, copied from a North American counterpart or a parent company's standard form. They work most of the time because most SaaS engagements never reach a dispute. When one does, the gaps show up quickly. Indian stamp duty, Indian GST, the DPDP Act, Section 27 of the Contract Act, and Section 194J TDS each have something to say about a SaaS MSA, and a template that ignores them creates real exposure.
This is a walkthrough of the clauses that matter in an India-context SaaS MSA, what they should say, and the Indian-law features that make them different from the standard global template.
The architecture: MSA plus order form plus DPA plus SLA
A well-structured SaaS engagement in India typically has four documents, not one. The MSA is the framework agreement signed once between the parties, setting out the terms that govern any subscription. The order form is the commercial document for each subscription period, setting fees, term, scope, and any service-specific terms. The DPA is the data processing agreement under the DPDP Act, mandatory if the SaaS provider processes personal data of the customer's end-users or employees. The SLA, often an annexure to the MSA or order form, sets uptime commitments and service credits.
Putting everything into one document is possible but messy. The advantage of the layered architecture is that the MSA can be signed once and then reused across multiple order forms, the DPA can be updated as the DPDP rules evolve without renegotiating the commercial terms, and the SLA can be reviewed independently when service levels are renegotiated.
Clause one: service description and uptime
The service description should reference an exhibit or order form rather than describing the service in the body of the MSA. SaaS products evolve constantly; freezing the description in the MSA body forces an amendment every time the feature set changes. A reference to the order form, with the order form describing the service as it exists on the order date and as it may be updated by the provider from time to time, is industry standard.
Uptime commitments belong in the SLA, not the MSA. Typical uptime targets are 99.5% for early-stage SaaS, 99.9% for mature B2B SaaS, and 99.95% or higher for enterprise SaaS handling critical workloads. The uptime percentage matters less than how it is measured and what the remedy is. Measurement should specify whether scheduled maintenance is excluded, what the measurement window is (typically monthly), and how downtime is calculated when only part of the service is degraded. The remedy is almost always service credits, not refunds, capped at a percentage of monthly fees (typically 25 to 50 percent of the monthly fee for the affected month).
Clause two: fees, taxes, GST, and TDS
This is the clause most often left ambiguous in templates imported from outside India. The MSA should specify:
- Whether stated fees are inclusive or exclusive of GST. Indian SaaS services attract GST at 18 percent. Saying "fees are Rs. X" without specifying GST treatment creates immediate ambiguity. Industry practice is to state fees exclusive of GST, with GST charged additionally at the prevailing rate.
- How TDS is handled. Payments to a SaaS provider for "professional or technical services" may attract TDS under Section 194J at 10 percent, although the classification of pure SaaS subscriptions as professional services is contested and depends on whether the supply is treated as goods or services for direct tax purposes. The MSA should specify that the customer will deduct TDS as required by law, and that the customer will issue Form 16A within statutory timelines.
- Cross-border supplies. If the customer is outside India, the supply may qualify as an export of services under the IGST Act, which is zero-rated subject to specific conditions. The provider should reserve the right to bill GST if the supply does not qualify as export, and the customer should agree to gross-up if applicable.
- Late payment interest. Indian commercial practice typically provides for interest at 12 to 18 percent per annum on amounts unpaid beyond thirty days. The Micro, Small and Medium Enterprises Development Act, 2006 imposes a statutory interest rate of three times the RBI bank rate on payments to MSMEs delayed beyond forty-five days, which overrides anything contractual.
- Annual escalation. Most SaaS MSAs renew automatically, often with a 5 to 10 percent annual price escalation. The escalation should be stated clearly in the MSA or order form, not buried in the renewal clause.
Clause three: liability cap and exclusions
The liability cap is the most negotiated clause in any SaaS MSA. Industry practice in India:
- Aggregate cap: Provider's total liability is typically capped at the fees paid by the customer in the trailing twelve months. Some providers push for caps as low as three months' fees; some customers push for caps as high as two times annual fees. The twelve-month cap is the dominant midpoint.
- Carve-outs: Standard exceptions to the cap are: provider's indemnity obligations for third-party IP infringement claims, breaches of confidentiality, breaches of the DPA, and gross negligence or wilful misconduct. Customer-side counsel sometimes also push for an exception for data breach liability, particularly for SaaS handling sensitive personal data.
- Exclusion of indirect damages: Both parties exclude liability for indirect, consequential, incidental, special, and punitive damages, and for loss of profits, revenue, goodwill, or data. This is mutual but is more often invoked by the provider.
A common provider-side mistake: capping liability at the fees paid by the customer in the trailing three or six months. For a low-value MSA, this can produce a cap of a few thousand rupees, which courts may strike down as unconscionable. Verbatra's contract risk review flags caps below INR 1,00,000 specifically.
Clause four: intellectual property
SaaS IP clauses break into three buckets.
The platform. The SaaS provider owns the underlying software, the platform, any improvements made to it, all general-purpose features, and any insights derived from aggregated, anonymised customer data. This should be stated clearly. The customer's use is licensed, not transferred.
Customer data. The customer owns the data it uploads to the platform, the data it generates by using the platform, and any output produced specifically for the customer. The provider's licence to use customer data should be limited to providing the service, supporting it, improving it on an anonymised basis, and complying with law. Marketing use of customer data should require separate written consent.
Configurations and integrations. Where the customer configures the platform extensively, or where the provider builds integrations or customisations specific to the customer, the IP allocation needs to be expressly addressed. The provider typically wants to own the integration so it can be productised. The customer often wants exclusive use of the customisation. The middle ground is provider ownership of the integration with a perpetual, customer-exclusive licence to use it in the customer's business.
Clause five: confidentiality and data protection
The confidentiality clause should be reciprocal. Standard duration of confidentiality obligations is three to five years from termination of the MSA, with an exception for trade secrets which remain confidential indefinitely. The clause should also expressly permit each party to share confidential information with auditors, regulators, professional advisers, and acquirers, subject to those recipients being bound by equivalent confidentiality obligations.
Data protection should be governed by a separate DPA referenced into the MSA. The DPA should address: classification of the parties under the DPDP Act, the purposes for which personal data is processed, the categories of data and data subjects, security measures, sub-processor management, breach notification timelines (industry standard is 48 hours from discovery for processor-to-fiduciary notification), data subject request handling, return and deletion of data on termination, and audit rights.
For SaaS providers serving customers in regulated sectors (banking, insurance, healthcare), the DPA should also address sector-specific data-localisation requirements. The Reserve Bank of India requires payment system data to be stored in India, the Insurance Regulatory and Development Authority has localisation requirements for insurance data, and several Ministry of Health and Family Welfare instruments require health data to be stored in India. The DPA should expressly acknowledge any such requirements applicable to the customer's data.
Clause six: termination
SaaS MSAs typically include four termination grounds:
- Termination for convenience by the customer. Standard in SaaS, typically on thirty days' notice. The customer pays for the notice period; the customer does not get a refund of pre-paid fees beyond the notice period unless expressly agreed.
- Termination for convenience by the provider. Less standard. Providers usually prefer not to grant a unilateral termination right to themselves because it undermines customer commitment. Where granted, longer notice (sixty to ninety days) and proportionate refund of pre-paid fees are reasonable.
- Termination for cause. Either party can terminate on material breach, with a cure period (typically 30 days) and a written notice. The cure period should not apply to specified non-curable breaches such as breach of confidentiality, breach of the DPA, or failure to pay beyond the cure period.
- Termination for insolvency. Either party can terminate immediately if the other becomes insolvent, files for liquidation, has an insolvency professional appointed, or has its operations materially disrupted.
On termination, the provider should be obligated to return or delete customer data, give the customer a defined window (typically 30 days) to export data, and pay any pro-rated refunds owed. The customer should pay all outstanding fees and confirm deletion of any provider IP it has access to.
Clause seven: indemnity
The standard two-way indemnity package in a SaaS MSA:
Provider indemnifies customer for: third-party claims that the SaaS infringes the third party's intellectual property rights; third-party claims arising from the provider's breach of its data protection obligations; third-party claims arising from the provider's gross negligence or wilful misconduct.
Customer indemnifies provider for: third-party claims arising from the customer's use of the service in breach of the MSA, in breach of law, or for purposes other than those permitted; third-party claims arising from the customer's data or content uploaded to the platform; third-party claims arising from the customer's breach of its confidentiality or data protection obligations.
Each indemnity should specify the conditions: prompt notification of claims, sole control of defence by the indemnifying party with the indemnified party's right to participate, the indemnified party's obligation to cooperate, and the indemnified party's right to consent to any settlement that imposes obligations on it. Indemnity sums are usually carved out of the overall liability cap, which makes the IP indemnity in particular potentially uncapped. Some providers push for a higher sub-cap on indemnities instead of an uncapped exposure.
Clause eight: limitation of warranties
A SaaS MSA in India should not contain a blanket "AS IS" disclaimer of all warranties. Indian courts have held that completely disclaiming the service warranty can be unconscionable. The recommended structure is:
- Provider warrants that the service will materially conform to the documentation, that it will use commercially reasonable security measures, that it has the right to provide the service, and that the service will be provided in a workmanlike manner.
- The provider disclaims any implied warranties of merchantability, fitness for purpose, non-infringement (except as expressly covered by the indemnity), uninterrupted operation (except as covered by the SLA), and freedom from defects (except as covered by the service warranty).
- The customer's exclusive remedy for warranty breach is the service-credit or refund mechanism specified in the SLA, supplemented by termination for cause if the breach is material and uncured.
This structure gives the provider real warranty protection without being so one-sided that an Indian court would strike it down.
Indian-context wrinkles often missed
Stamp duty. A SaaS MSA is a commercial contract and is subject to stamp duty under the state stamp act of the place of execution. The rate varies. Most Indian states treat MSAs as a "general agreement" stampable at Rs. 100 to Rs. 500. Some states (Maharashtra, Karnataka) have higher ad valorem rates for MSAs with specified consideration. Stamping does not affect the validity of the agreement between the parties but is required if the document is to be produced as evidence in court.
Section 27 of the Contract Act. Any post-engagement non-compete restriction on the customer or its employees (preventing them from using a competing SaaS) is void as an agreement in restraint of trade. Non-solicitation, confidentiality, and IP-protection restrictions are enforceable; outright non-compete is not.
Limitation period. Claims under a SaaS MSA must be brought within three years of the cause of action under the Limitation Act, 1963. The MSA cannot extend this period contractually beyond what the Act permits. Some providers attempt to shorten the limitation period contractually to one year; whether this is enforceable is contested.
Dispute resolution. Arbitration is dominant for B2B SaaS MSAs in India. The arbitration clause should specify the seat (most often Mumbai, Delhi, or Bangalore), the rules (most commonly the Arbitration and Conciliation Act, 1996 with reference to the SIAC or LCIA rules for international parties), the number of arbitrators (usually one for amounts below INR 5 crore, three for amounts above), and the language of the arbitration. Court jurisdiction for interim relief and enforcement should be expressly specified to avoid jurisdictional disputes.
What Verbatra does
Verbatra has a free MSA generator that builds India-context Master Service Agreements with all the clauses above. The generator handles the Indian-law wrinkles automatically: GST and TDS treatment, stamp duty notation, Section 27 compliance for restrictive covenants, DPDP-compatible data protection clause, and arbitration provisions calibrated to the value of the deal. There is also a free Risk Review tool that scans an existing SaaS MSA against 200-plus risk patterns and flags issues like below-market liability caps, missing IP carve-outs, and indemnity asymmetry.
Neither tool replaces a lawyer reviewing a high-value MSA. They produce a solid first draft, or a risk-flagged version of a counterparty draft, that a lawyer can refine. For a routine B2B SaaS engagement between commercial parties at the early-stage end of the market, the generator output is often sufficient. For an enterprise deal, an IP-heavy SaaS, or anything that would change the company materially if it went wrong, get the document reviewed by counsel before signing.