SaaS Agreements in India: The Clauses That Operators Get Wrong

SaaS agreements are usually negotiated while both sides are trying to get the product deployed or the deal closed. Pricing, features, implementation timelines and support requirements receive most of the attention. The remaining provisions are often accepted because they appear standard.

Problems arise when the contract does not match the way the software is actually supplied, used or integrated into the customer’s business.

Indian SaaS contracts are principally shaped by the terms agreed between the parties, alongside laws concerning contracts, intellectual property, personal data and dispute resolution. The Indian Contract Act, 1872, for example, governs contractual remedies, while the Copyright Act, 1957 recognises rights relating to computer programs. Data-processing arrangements may also need to account for the Digital Personal Data Protection Act, 2023 and the phased implementation of the Digital Personal Data Protection Rules, 2025.

The following provisions regularly require more attention than they receive.

Customer Data

A clause stating that the customer owns its data is useful, but it is not enough.

A SaaS platform may process customer records while separately generating usage statistics, diagnostic logs, metadata and aggregated information. The agreement should identify which information belongs to the customer and whether the provider may retain or use other categories of data for analytics, security, product development or similar purposes.

Where personal data is processed, the contract should also address the parties’ respective responsibilities, permitted processing, security measures, breach reporting, deletion and the use of third-party service providers. These provisions should reflect the actual data flows rather than relying on a general statement that each party will comply with applicable law.

Limitation of Liability

A liability cap is usually expressed by reference to the fees paid during a particular period. The number itself is only part of the negotiation.

The agreement should also identify whether particular claims fall outside the cap. The parties may take different positions on confidentiality breaches, intellectual property infringement, fraud, wilful misconduct, data-security incidents and violations of law.

A broad exclusion of indirect or consequential loss also requires care. Labels alone do not always explain how a particular loss will be treated. The drafting should be considered against the losses that could realistically arise from the service.

Under Section 74 of the Indian Contract Act, a contractual amount stipulated for breach does not automatically become payable in full; the provision permits reasonable compensation up to the stipulated amount. This may be relevant when drafting service credits, liquidated damages or similar contractual remedies.

Service Levels

An uptime commitment does not explain what the provider must do when the platform stops functioning properly.

The agreement should define how incidents are classified, how quickly the provider must respond and whether any resolution or workaround timelines apply. Planned maintenance, excluded downtime and the method used to calculate availability should also be clear.

Service credits are commonly offered when service levels are missed. Customers should check whether those credits are the sole remedy and whether repeated failures create any additional right, including termination.

Termination and Data Retrieval

The right to terminate is often negotiated without deciding how the customer will leave the platform.

The agreement should state how long the customer can access its information after termination, the format in which the data will be provided and whether migration assistance is available. The customer may also need continued access to APIs, integrations or a read-only account during the transition.

Deletion provisions should account for live systems, archived information and backups. Immediate deletion may be impractical, but an indefinite right to retain customer information is rarely appropriate.

These details become particularly important where the software contains operational records that cannot be replaced easily.

Automatic Renewal

Automatic renewal clauses are commercially convenient, but the notice period may not fit the customer’s procurement cycle.

A customer may be required to give notice 60 or 90 days before the subscription ends. By the time the business reviews performance or budgets for the next year, the agreement may already have renewed.

The contract should clearly state the renewal period, cancellation deadline and whether prices may be increased upon renewal. Internally, the customer should record the notice date rather than only the subscription expiry date.

Acceptable Use

Acceptable-use restrictions increasingly affect ordinary product use rather than merely unlawful conduct.

They may regulate automated queries, API volumes, scraping, security testing, benchmarking, reverse engineering and the use of AI tools. A restriction that appears harmless in isolation may prevent the customer from implementing the workflow for which the software was purchased.

The intended integrations and use cases should therefore be checked against both the agreement and any separate acceptable-use policy. The provider should also retain enough flexibility to protect the platform from misuse without being able to suspend legitimate use arbitrarily.

Subprocessors and Third-Party Services

Most SaaS products rely on other providers for hosting, communications, payments, analytics, authentication or AI functionality.

The customer may contract only with the SaaS provider, even though several third parties participate in delivering the service. The agreement should explain whether the provider may appoint subprocessors freely, whether notice will be given when material providers change and who remains responsible for their acts and omissions.

A contract should not suggest that the platform operates entirely within the provider’s own infrastructure when that is not how the service is delivered.

Intellectual Property

A standard clause usually confirms that the provider owns the software and the customer retains its pre-existing intellectual property. The position becomes less clear when the parties work together during implementation.

Custom integrations, configuration materials, new modules and customer-funded features should be addressed expressly. The same applies to feedback and suggestions that the provider may later incorporate into its product.

Ownership is not always the only workable outcome. The provider may retain the underlying product while granting the customer appropriate rights over custom deliverables. What matters is that the commercial understanding is reflected in the contract.

Computer programs receive protection under the Copyright Act, 1957, making it important for software agreements to distinguish between ownership, licensing and permitted use.

Governing Law and Dispute Resolution

Indian businesses sometimes accept overseas governing law and dispute-resolution provisions without considering the cost of enforcing them.

The clause should identify the governing law, the courts or arbitral seat, the method of appointing an arbitrator and the language of proceedings. Where arbitration is selected, the drafting should distinguish between the legal seat and the physical venue of hearings.

India’s Arbitration and Conciliation Act, 1996 governs domestic arbitration, international commercial arbitration and the enforcement of arbitral awards within its scope. The parties have considerable freedom to agree on the procedure to be followed, subject to the Act.

Reviewing the Agreement in Context

There is no single correct SaaS agreement for every transaction. A low-value productivity tool does not require the same allocation of risk as software that stores financial records, controls business-critical processes or handles substantial personal data. The appropriate drafting depends on the product, the parties’ bargaining positions, the information being processed and the consequences of prolonged failure.

Before execution, the agreement should clearly address the data the provider may access, retain, and use; what happens if the service fails or causes loss; how support and service levels will operate; how the customer can retrieve its data and exit the platform; who owns custom work and integrations; which third-party providers are involved; and where disputes will be resolved.

Many SaaS disputes begin with an operational issue. They become harder to resolve because the contract did not allocate responsibility for that issue with enough precision.

About the Author

Shauree Gaikwad is the founder of Wayver and advises founders, businesses, and technology companies on commercial contracts, intellectual property, and corporate law. Her practice includes drafting and negotiating technology agreements, including SaaS, licensing, and other software-related contracts.