How to Draft and Negotiate a SaaS Agreement Under Indian Law: Key Clauses and Compliance

Kaustav Chowdhury
23 hours ago
9 min read

Software-as-a-Service (SaaS) agreements are now the dominant model for enterprise software procurement in India. Unlike traditional perpetual license agreements, a SaaS agreement grants the customer a subscription-based right to access and use software hosted on the provider's infrastructure, typically through a web browser or API. The shift from on-premise licensing to cloud-based delivery introduces a distinct set of legal issues: service levels and uptime guarantees, data processing obligations under the Digital Personal Data Protection Act, 2023, intellectual property ownership boundaries, limitation of liability, data portability on termination, and cross-border data transfer restrictions.

This guide provides a clause-by-clause framework for drafting and negotiating SaaS agreements that are enforceable under Indian law, with practical guidance on compliance with the IT Act, 2000, the DPDP Act, 2023, and the DPDP Rules, 2025.

1. License vs. Subscription: Characterising the SaaS Model

The first drafting decision is whether to characterise the arrangement as a "license" or a "subscription for services." This distinction has significant legal implications.

Tax Treatment: Under the Income Tax Act, payments for a "license to use" software may be characterised as royalty income, subject to withholding tax under Section 194J (now Section 393 under the IT Act, 2025) and potentially under applicable Double Taxation Avoidance Agreements (DTAAs). By contrast, payments for a subscription service may be characterised as business income or fees for technical services, with different withholding obligations.
GST Classification: SaaS supplied by a domestic provider is classified as an "information technology software service" under SAC 998314 and is subject to 18% GST. For cross-border SaaS supplied by a non-resident provider, the import is subject to GST under the reverse charge mechanism.
Stamp Duty: The applicability of stamp duty to SaaS agreements varies by state. States such as Maharashtra, Rajasthan, and Gujarat have amended the definition of "instrument" to include electronic records, while other states may not impose stamp duty on e-contracts.

The agreement should clearly state that the provider grants the customer a non-exclusive, non-transferable, limited right to access and use the software during the subscription term, and that no ownership of the underlying software is transferred. This characterisation aligns with the "subscription for services" model and avoids the intellectual property transfer implications of a traditional license grant.

2. Validity of E-Contracts Under the IT Act, 2000

SaaS agreements are typically executed electronically, either through click-wrap acceptance (where the user clicks "I Agree" to the terms) or through e-signatures on a negotiated Master Services Agreement (MSA). Section 10A of the Information Technology Act, 2000 (introduced by the IT Amendment Act, 2008) provides that a contract shall not be deemed unenforceable solely on the ground that it was formed through electronic means. This provision gives legal validity to click-wrap and browse-wrap SaaS agreements in India.

For enterprise SaaS agreements with higher contract values, parties often use Aadhaar e-Sign or digital signatures issued by a licensed Certifying Authority under Section 35 of the IT Act, which provide the highest level of legal assurance. Digital signatures under Section 3A of the IT Act have the same legal effect as handwritten signatures under Section 5.

3. Service Level Agreement (SLA) and Uptime Guarantees

The SLA is the commercial backbone of any SaaS agreement. It defines the provider's performance commitments and the remedies available to the customer if those commitments are not met.

Uptime Commitment

The standard industry uptime commitment is 99.9% (commonly referred to as "three nines"), which translates to approximately 8.76 hours of permissible downtime per year. Mission-critical applications may warrant 99.95% or 99.99% uptime. The SLA should clearly define what constitutes "downtime" (typically, periods when the service is materially unavailable as measured by the provider's monitoring tools), and exclude scheduled maintenance windows, force majeure events, and customer-caused outages from the uptime calculation.

Service Credits and Remedies

If the provider fails to meet the uptime commitment, the customer should be entitled to service credits (typically expressed as a percentage of the monthly subscription fee), escalating based on the severity of the SLA breach. For example, a tiered structure might provide 10% credits for uptime between 99.0% and 99.9%, 25% for uptime between 95.0% and 99.0%, and the right to terminate without penalty for uptime below 95.0%. Service credits are typically the customer's sole and exclusive remedy for SLA failures, and the agreement should state this explicitly.

4. Data Processing Addendum: DPDP Act Compliance

If the SaaS provider processes personal data on behalf of the customer, a Data Processing Addendum (DPA) is mandatory under Section 8(2) of the Digital Personal Data Protection Act, 2023. A standard MSA or SaaS terms of service does not satisfy this requirement; a separate DPA addendum is needed.

Under the DPDP Act, the customer is the "Data Fiduciary" (the entity that determines the purpose and means of processing), and the SaaS provider is the "Data Processor" (the entity that processes data on behalf of the Data Fiduciary). The DPA must address the following requirements.

Scope and Purpose Limitation: The DPA must define the categories of personal data processed, the purposes for which processing is permitted, and the duration of processing. The Data Processor must not process the data for any purpose beyond what the Data Fiduciary has authorised.
Security Safeguards: The DPDP Rules, 2025 require "reasonable security safeguards," including encryption (at rest and in transit), access controls, logging and monitoring, regular vulnerability assessments, and backup and disaster recovery procedures.
Breach Notification: The DPA should require the Data Processor to notify the Data Fiduciary without undue delay (typically within 72 hours) after becoming aware of a personal data breach. The Data Fiduciary, in turn, must notify the Data Protection Board of India as required under the Act.
Sub-Processor Controls: If the SaaS provider engages sub-processors (such as cloud infrastructure providers or analytics vendors), the DPA should require prior written consent, maintain a list of approved sub-processors, and impose equivalent data protection obligations on each sub-processor.
Cross-Border Transfers: The DPA should include a change-of-law clause that allows the Data Fiduciary to direct the Data Processor to suspend cross-border transfers if required by a notification restricting transfers to certain jurisdictions.
Data Deletion: Upon termination of the agreement, the Data Processor must delete or return all personal data within a specified period, and certify the deletion in writing.

A critical difference from the GDPR framework is that the DPDP Act places sole liability on the Data Fiduciary for the Data Processor's actions. This means the DPA must include robust contractual indemnification and penalty pass-through provisions to protect the customer from regulatory penalties arising from the provider's breaches.

5. Intellectual Property Ownership

IP ownership is often the most contentious clause in SaaS negotiations. The agreement should clearly delineate between three categories of IP.

Provider IP: The underlying software, algorithms, infrastructure, documentation, and any pre-existing intellectual property of the provider. The agreement should state unambiguously that the provider retains all rights, title, and interest in its IP, and the subscription grant does not transfer any ownership.
Customer Data: All data uploaded, entered, or generated by the customer through use of the SaaS platform. The agreement should state that the customer retains all rights in its data, and the provider has only a limited license to process the data for the purpose of providing the service.
Customisations and Derivatives: If the provider develops custom features, integrations, or configurations for the customer, the ownership of these customisations must be negotiated. Options range from full customer ownership (common in enterprise deals) to provider ownership with a perpetual license to the customer, to joint ownership (which is generally inadvisable due to the complexity of managing joint IP under Indian law).

The provider should also warrant that its software does not infringe any third-party IP rights, and should indemnify the customer against infringement claims. Companies with ESOP programmes should ensure that employees who develop the SaaS product have executed proper IP assignment agreements to avoid ownership disputes.

6. Indemnity and Limitation of Liability

The indemnity and liability clauses are among the most heavily negotiated provisions in any SaaS agreement.

Indemnification Triggers

Common indemnification triggers include IP infringement claims by third parties, data breaches attributable to the provider, breach of the provider's representations and warranties, and breach of confidentiality obligations. The customer should also seek indemnification for regulatory penalties imposed under the DPDP Act arising from the provider's failure to implement adequate security safeguards or comply with the DPA.

Limitation of Liability

SaaS agreements typically include a cap on the provider's total aggregate liability, commonly set at the total fees paid by the customer in the preceding 12-month period. However, certain categories of liability are typically carved out from the cap, including liability for IP infringement indemnity, data breach indemnity, breach of confidentiality, gross negligence or wilful misconduct, and regulatory penalties under the DPDP Act. The agreement should also address whether consequential, indirect, and punitive damages are excluded. Under Indian law, such exclusion clauses are generally enforceable, but they must be drafted with clarity and mutual agreement.

7. Termination, Data Portability, and Transition Assistance

The termination provisions should address ordinary expiry (non-renewal at the end of the subscription term), termination for cause (material breach not cured within a specified notice period, typically 30 days), termination for convenience (with a longer notice period, typically 90 days, and potential early termination fees), and termination upon insolvency or bankruptcy of either party.

Upon termination, the following obligations are critical.

Data Export: The provider must make all customer data available for export in a standard, machine-readable format (such as CSV, JSON, or XML) for a specified period after termination (typically 30 to 90 days). This is essential for vendor migration.
Data Deletion: After the export period, the provider must permanently delete all customer data from its systems (including backups) and provide written certification of deletion, consistent with the requirements under the DPDP Act.
Transition Assistance: For enterprise SaaS deployments, the provider should be required to provide reasonable transition assistance (at pre-agreed rates) to help the customer migrate to a replacement solution.

8. Confidentiality and Information Security

The confidentiality clause should define "Confidential Information" broadly to cover all non-public information disclosed by either party, including the customer's business data, the provider's proprietary technology, and the commercial terms of the agreement. Standard carve-outs should apply for information that is publicly available, independently developed, received from a third party without restriction, or required to be disclosed by law or court order.

The provider should be required to implement and maintain information security measures consistent with industry standards such as ISO 27001 or SOC 2 Type II. The customer should have the right to conduct periodic security audits or request third-party audit reports. Companies should ensure their vigil mechanism and whistleblower policy covers reporting of data security incidents involving SaaS vendors.

9. Governing Law and Dispute Resolution

The governing law clause determines which jurisdiction's laws will apply to the interpretation and enforcement of the agreement. For SaaS agreements between two Indian parties, Indian law is the natural choice, with the courts of a specific city (typically the provider's headquarters or the customer's principal place of business) having exclusive jurisdiction.

For cross-border SaaS agreements involving a foreign provider and an Indian customer, the dispute resolution mechanism requires careful consideration. Options include arbitration under the rules of the Singapore International Arbitration Centre (SIAC), the ICC International Court of Arbitration, or domestic arbitration under the Arbitration and Conciliation Act, 1996, with the seat in India. The principles of transnational issue estoppel in enforcement of arbitral awards are relevant when foreign arbitral awards need to be enforced in India.

The agreement should also provide for interim relief (such as injunctions for IP infringement or data breach) to be available from courts of competent jurisdiction notwithstanding the arbitration clause.

10. Representations, Warranties, and Compliance Covenants

The agreement should include representations and warranties from the provider covering the following areas.

Authority and Capacity: The provider has the corporate authority to enter into the agreement and perform its obligations. The board approval for significant contracts may be required under the Companies Act, 2013 for contracts exceeding specified thresholds.
Non-Infringement: The service does not infringe any third-party intellectual property rights.
Compliance with Laws: The provider will comply with all applicable laws, including the IT Act, 2000, the DPDP Act, 2023, and the DPDP Rules, 2025.
Malware and Vulnerabilities: The service is free from viruses, malware, trojans, backdoors, and known security vulnerabilities at the time of delivery.
POSH Compliance: For enterprise SaaS providers with employees in India, compliance with the POSH Act, 2013 and other employment laws is often included as a compliance covenant.

11. Additional Negotiation Points

Beyond the core clauses discussed above, the following points frequently arise in SaaS negotiations and should be addressed in the agreement.

Auto-Renewal and Price Escalation: Many SaaS agreements include auto-renewal clauses with annual price escalation caps (typically 5% to 10%). The customer should negotiate the right to opt out of auto-renewal with adequate notice.
Change of Control: Include provisions addressing what happens if the SaaS provider is acquired or undergoes a change of control. The customer may want the right to terminate without penalty if the provider is acquired by a competitor.
Source Code Escrow: For mission-critical SaaS applications, the customer may negotiate a source code escrow arrangement, under which the provider deposits the source code with a neutral escrow agent, to be released to the customer upon specified trigger events (such as provider insolvency or material breach).
Cross-Border Compliance: For SaaS providers serving customers across jurisdictions, ensure compliance with FEMA regulations for subscription payments from Indian customers to foreign providers, including withholding tax and RBI reporting obligations.
Whistleblower and Compliance Reporting: Enterprise customers may require the provider to maintain a whistleblower reporting mechanism for reporting ethical violations, data protection breaches, or other compliance concerns.

Conclusion

A well-drafted SaaS agreement under Indian law must balance commercial flexibility with regulatory compliance across multiple legal frameworks: the IT Act, 2000 for electronic contract validity, the DPDP Act, 2023 and the DPDP Rules, 2025 for data processing obligations, the Indian Contract Act, 1872 for general enforceability, and applicable GST and stamp duty regulations. By addressing each of the key clauses outlined in this guide, from SLA and uptime guarantees to data processing addendums, IP ownership, indemnity, limitation of liability, termination and data portability, governing law, and dispute resolution, both providers and customers can create agreements that protect their respective interests while enabling a productive commercial relationship.