SaaS Agreements in India
Your organisation signed the SaaS agreement because the sales demo was compelling. No one reviewed the auto-renewal clause, the data portability provisions, or the provider's right to deprecate the features you selected the platform for. When you try to exit in year three, you discover the switching cost exceeds the remaining contract value. This is not a negotiation failure — it is an architecture failure.
What a SaaS Agreement Governs and Why It Differs from Software Licensing
A SaaS agreement governs a fundamentally different relationship than a traditional software licence. In a licence, the customer acquires a right to use a copy of the software, typically installed on their own infrastructure. In SaaS, the customer accesses functionality delivered over the internet. The customer never possesses the software. The provider maintains the infrastructure, deploys updates, manages security, and controls access.
This structural difference creates five contractual concerns that do not exist in traditional licensing: (1) continuous dependency — the customer cannot operate without the provider's infrastructure being available; (2) data custody — the customer's data resides on the provider's servers; (3) unilateral change — the provider can modify the platform without the customer's agreement; (4) exit difficulty — switching SaaS providers requires data migration, integration rebuilding, and user retraining; and (5) multi-tenancy risk — the customer's data shares infrastructure with other customers.
Under the Indian Contract Act 1872, a SaaS agreement is a service contract, not a transfer of property rights. This classification affects GST treatment (18% on services vs. potential equalisation levy considerations for cross-border SaaS), withholding tax obligations (no royalty characterisation for pure SaaS, though the distinction is contested in certain treaty contexts), and termination consequences (the customer loses all access upon termination, unlike a perpetual licence where the licensed copy remains).
The SaaS agreement must be drafted with these structural realities in mind. A licence agreement template repurposed for SaaS will fail to address data governance, service continuity, platform changes, and the exit problem that define the SaaS relationship.
Subscription Scope: Defining What the Customer Actually Gets
The subscription scope defines the boundary of the SaaS relationship. Everything within scope is the provider's obligation. Everything outside scope is either excluded or subject to additional fees. Ambiguity in scope is the root cause of most SaaS disputes.
Module and Feature Definition: The agreement should specify exactly which SaaS modules, features, and tiers are included in the subscription. Feature lists evolve — the agreement should reference the feature set as of the subscription effective date and address how subsequent feature additions and deprecations are handled. A general reference to "the SaaS platform" without feature specificity creates disputes when the provider claims a requested capability is an add-on rather than a core feature.
User and Usage Limits: Per-user SaaS should define what constitutes a user (named user vs. concurrent user), whether users can be reassigned, the minimum commitment (if any), and the process for adding or removing users mid-term. Usage-based SaaS should define the metered unit (API calls, transactions, storage, compute time), the measurement methodology, usage alerts and caps, and overage pricing. The agreement should specify whether unused allocation rolls over or expires at period-end.
Customisation and Configuration: SaaS platforms offer varying degrees of customisation. The agreement should distinguish between: configuration (using the platform's built-in settings to tailor behaviour — included in the subscription), customisation (modifying or extending the platform code or creating bespoke features — typically additional scope), and integration (connecting the SaaS platform with the customer's other systems — may be included or additional depending on complexity). Ownership of customisations is particularly contentious — the provider wants to incorporate useful customisations into the platform for all customers; the customer who paid for the customisation wants exclusivity or at least a fee reduction.
Support and Maintenance: The agreement should define the support included in the subscription: support hours, support channels (email, phone, chat, dedicated account manager), response time commitments by severity level, and the escalation process. Premium support tiers should be separately priced and documented. The provider's obligation to maintain the platform, deploy security patches, and release updates should be specified, including whether major version upgrades are included in the subscription or priced separately.
Service Level Architecture: Uptime, Performance, and Remedies
The SLA is the mechanism that converts the provider's service promises into measurable, enforceable commitments. Without an SLA, the customer has no contractual basis for claiming that the service was inadequate, no matter how poor the performance.
Uptime Commitment: Uptime is measured as a percentage of total available minutes in the measurement period, excluding scheduled maintenance. The industry tiers: 99.9% (8.76 hours downtime per year — enterprise standard), 99.95% (4.38 hours — premium tier), 99.99% (52.6 minutes — mission-critical). The SLA must define what constitutes downtime: is the service "down" only when completely inaccessible, or also when response times exceed specified thresholds? The measurement period matters: monthly measurement allows 43 minutes of downtime at 99.9%, while annual measurement allows the same total but permits clustering of downtime in a single incident.
Exclusions: Standard exclusions from uptime calculation include: scheduled maintenance (notified at least 72 hours in advance, conducted during off-peak hours), downtime caused by the customer's network or systems, force majeure events, third-party service failures outside the provider's control, and government-ordered shutdowns. Each exclusion should be narrowly defined to prevent the provider from attributing all downtime to excluded causes.
Service Credits: Service credits are the contractual remedy for SLA breaches. The standard structure credits a percentage of the monthly fee for each defined shortfall: 10% credit for uptime between 99.0% and 99.9%, 25% credit for uptime between 95.0% and 99.0%, 50% credit for uptime below 95.0%. Credits are applied against future invoices, not refunded in cash. The maximum credit per period is typically capped at 30% of monthly fees. The customer must claim credits within a specified period (typically 30 days) with supporting documentation.
Termination Right for Persistent Failure: Service credits alone are an inadequate remedy if the platform is consistently underperforming. The SLA should include a termination trigger: if uptime falls below a specified threshold (for example, 95%) for three consecutive months or any single month below 90%, the customer has the right to terminate without penalty and receive a pro-rata refund of prepaid fees. This termination right is the real enforcement mechanism — without it, the provider's maximum exposure is capped at service credits, which may be commercially insignificant relative to the customer's losses from service failure.
Data Governance: Ownership, Residency, and DPDPA Compliance
Data governance is the defining challenge of SaaS procurement. The customer's most valuable asset — their data — resides on infrastructure controlled by a third party. The SaaS agreement must establish clear rules for who owns the data, where it is stored, how it is protected, and what happens to it when the relationship ends.
Data Ownership: The agreement should unambiguously state that all data uploaded by the customer, generated through the customer's use of the platform, and derived from the customer's data belongs to the customer. The provider has no ownership interest in customer data and may not use, disclose, or analyse customer data except as instructed by the customer or as necessary to provide the service. The contentious area is aggregated and anonymised data: the provider typically seeks the right to use such data for product improvement and industry benchmarking. If granted, the anonymisation standard must be specified to prevent re-identification risk.
Data Residency and Localisation: The agreement should specify the data centre locations where customer data will be stored (primary and disaster recovery). For Indian customers, multiple regulatory requirements apply: DPDPA 2023 will restrict transfers to jurisdictions notified by the Central Government; RBI mandates that payment system data must be stored exclusively in India; sector-specific regulators (IRDAI, SEBI) have their own data localisation requirements. The agreement should include: the current data centre locations, the provider's obligation to notify changes with 90 days advance notice, the customer's right to require India-only storage, and a migration plan if a permitted jurisdiction becomes restricted.
DPDPA Compliance: A Data Processing Agreement should be appended as a schedule, covering: processing instructions, categories of personal data and data principals, security measures (encryption standards, access controls, audit logging, vulnerability management), sub-processor engagement protocol (prior written approval, flow-down of obligations, current sub-processor list), data breach notification (within 72 hours to the customer, who then notifies the Data Protection Board), data retention and erasure (upon purpose fulfilment or contract termination), Data Principal rights facilitation (the provider assists the customer in responding to access, correction, and erasure requests), and audit rights (the customer or its designated auditor can verify compliance with the DPA).
Security Obligations: The SaaS agreement should require: SOC 2 Type II or ISO 27001 certification maintained throughout the subscription, annual penetration testing by an independent firm with summary results shared with the customer, encryption of data at rest (AES-256) and in transit (TLS 1.2+), multi-factor authentication for administrative access, role-based access controls, audit logging with 12-month retention, incident response plan with defined escalation procedures, and compliance with CERT-In reporting requirements under the Information Technology Act 2000.
Pricing Structures, Escalation Caps, and Auto-Renewal
SaaS pricing is not a one-time negotiation. It is an ongoing commercial relationship governed by the pricing model, escalation mechanics, and renewal terms. The agreement must address all three dimensions to prevent economic lock-in.
Pricing Models: Per-user (fixed fee per named or concurrent user per period — simple but can become expensive at scale), per-usage (metered charges based on transactions, API calls, storage, or compute — aligns cost with value but creates budget unpredictability), tiered (feature-based packaging with ascending price points — encourages upselling), and flat-rate (unlimited users and usage for a fixed fee — simple but typically includes fair-use caps). The agreement should specify which model applies, the unit of measurement, the billing frequency, and the mechanism for adjusting the pricing model at renewal if the customer's usage profile changes.
Price Escalation Caps: SaaS subscriptions typically auto-renew with annual price increases. Without a contractual cap, the provider can increase prices by any amount at renewal, exploiting the switching costs that make it impractical for the customer to move. The agreement should cap annual price increases at a defined percentage: typically 5-7% or CPI (Consumer Price Index) plus a margin, whichever is lower. Multi-year commitments should lock in pricing for the commitment period with escalation applying only at the end of the committed term.
Auto-Renewal Terms: Auto-renewal is standard in SaaS. The agreement should specify: the renewal term (typically 12 months), the cancellation notice period (30-60 days before the renewal date), the method of providing cancellation notice (written notice to a specified address or email, not buried in a portal setting), the consequence of failing to cancel (automatic renewal at the escalated price), and the customer's right to downgrade at renewal. The provider should be required to send a renewal reminder at least 60 days before the renewal date, specifying the renewal price and any changes to terms.
Mid-Term Adjustments: The agreement should specify the process for adding users or modules mid-term (immediate activation, pro-rata billing for the remainder of the current term), removing users or modules mid-term (typically effective at the next renewal, not during the current term — this is a common trap), and upgrading or downgrading tiers (upgrade effective immediately with price adjustment, downgrade effective at renewal). The agreement should also address what happens if the customer exceeds usage limits: automatic overage charges, throttling, or service suspension.
Intellectual Property and Customisation Ownership
In a SaaS relationship, the IP landscape is structurally different from traditional software licensing. The customer never receives the software code. The provider retains full ownership of the platform. The agreement must delineate the boundary between provider IP, customer data, and the grey area of customisations and configurations.
Provider Platform IP: The SaaS platform — source code, object code, algorithms, user interface, APIs, documentation, and all underlying technology — belongs to the provider. The customer receives a non-exclusive, non-transferable, non-sublicensable right to access and use the platform during the subscription term for the customer's internal business purposes. This right terminates immediately upon expiry or termination of the subscription.
Customer Data and Content: All data uploaded by the customer, generated through the customer's use of the platform, and derived from the customer's data belongs to the customer. The provider is granted a limited licence to host, process, and display the customer's data solely for the purpose of providing the service. This licence terminates upon subscription termination, after which the provider must return and delete the data as specified in the exit provisions.
Customisation Ownership: Customisations are the contested territory. If the customer pays for bespoke development — new modules, modified workflows, custom integrations — who owns the resulting code? Three positions: (1) the customer owns the customisation code and grants the provider a licence to host it on the platform, (2) the provider owns the code and grants the customer a perpetual licence to use it, or (3) the provider owns the code and includes it in the subscription with no separate licence. Position (1) is strongest for the customer but creates complexity if the customisation is integrated into the platform codebase. Position (2) is the most common compromise. The agreement should also address whether the provider can incorporate the customisation concepts into the platform for all customers.
Configuration as Customer IP: Configurations — the settings, workflows, templates, and rules the customer creates using the platform's built-in tools — should be treated as customer IP because they reflect the customer's business logic and operational knowledge. The agreement should ensure that configurations can be exported in a usable format and that the provider does not use or disclose them to other customers.
Exit Architecture: Data Portability, Transition, and Wind-Down
The exit from a SaaS relationship is the moment when the vendor lock-in risk materialises. The customer must migrate data, rebuild integrations, retrain users, and maintain business continuity throughout the transition. The SaaS agreement must address each dimension of exit.
Data Export: The provider must export all customer data in industry-standard formats (CSV, JSON, XML, or as agreed) within a specified period after termination notice. The export should include all data categories: transactional records, configuration data, user data, audit logs, and any derived data the customer is entitled to. The agreement should specify the export format for each data category, the timeline for completing the export (typically 30-60 days), and the charges (if any) for the export service.
Transition Assistance Period: After termination, the customer needs time to migrate to an alternative platform. The agreement should provide a transition assistance period of 90-180 days during which the customer retains read-only access to the platform for data verification and the provider provides reasonable cooperation with the replacement provider. Transition assistance should be available at the provider's then-current professional services rates or at the rates specified in the agreement.
Data Destruction: After the data export period and transition assistance period, the provider must permanently delete all customer data from primary systems, backup systems, disaster recovery sites, and any sub-processor systems. The provider should issue a written certification of data destruction signed by an authorised officer. Under DPDPA, this is not merely a contractual obligation — failure to erase personal data after purpose fulfilment is a statutory violation.
API and Integration Documentation: During the subscription term, the provider should maintain and provide API documentation that enables the customer to build integrations. Upon termination, the customer should have the right to retain API documentation for the purpose of migrating integrations to an alternative platform. The agreement should specify that API documentation is not confidential information of the provider for this limited purpose.
Liability Framework and Indemnification
SaaS liability structures must account for the unique risk profile of the relationship: the customer's data is in the provider's custody, the customer's business operations depend on the provider's infrastructure, and the provider's platform is accessible to all customers simultaneously — meaning a vulnerability affects everyone.
Tiered Liability Caps: General liability (service failures, non-performance): capped at 12 months of fees paid or payable. Elevated liability (data breaches, confidentiality violations, IP infringement): capped at 2-3x the general cap. Uncapped: fraud, wilful misconduct, and DPDPA penalties imposed by the Data Protection Board. The customer should resist a single aggregate cap that conflates service failures with data breaches — the risk profile is fundamentally different.
Data Breach Indemnification: The provider should indemnify the customer against losses arising from data breaches caused by the provider's failure to implement the agreed security measures. The indemnification should cover: notification costs to affected data principals, credit monitoring services (if applicable), regulatory fines imposed on the customer as Data Fiduciary (to the extent caused by the provider's failure), forensic investigation costs, and legal costs. DPDPA penalties for failure to implement reasonable security safeguards can reach ₹250 crore — the indemnification cap must be adequate to address this exposure.
IP Indemnification: The provider should indemnify the customer against third-party claims that the SaaS platform infringes intellectual property rights. This is critical because the customer has no visibility into the platform's codebase and cannot assess infringement risk independently. The indemnification should include the provider's obligation to: defend the claim at its expense, pay any damages or settlement, and if the platform is found to infringe, either procure the right for the customer to continue using the platform, modify the platform to be non-infringing, or terminate the subscription and refund prepaid fees.
Consequential Damages: Most SaaS agreements exclude consequential damages. However, for enterprise SaaS that is integrated into the customer's core business operations, the most significant losses from platform failure are consequential: lost revenue, lost customers, regulatory penalties, and business disruption. The customer should negotiate carve-outs for foreseeable consequential losses directly linked to specific provider failures: data breach, prolonged outage exceeding the SLA termination threshold, and wrongful termination of the subscription.
Regulatory Compliance: DPDPA, IT Act, and Sector-Specific Requirements
SaaS procurement in India must navigate a multi-layered regulatory environment. The agreement must allocate compliance obligations between the customer and provider for each applicable regulation.
DPDPA 2023: The customer is the Data Fiduciary. The provider is the Data Processor. The customer bears primary responsibility for obtaining consent, defining processing purposes, and responding to Data Principal rights requests. The provider must process data only as instructed, implement reasonable security safeguards, notify breaches within 72 hours, and not engage sub-processors without prior approval. The agreement should clearly map each DPDPA obligation to the responsible party.
Information Technology Act 2000: The IT Act and associated rules impose obligations on intermediaries and service providers. CERT-In directions (April 2022) require reporting of cybersecurity incidents within 6 hours of becoming aware, maintaining logs for 180 days, and synchronising system clocks with NTP servers. The SaaS provider must comply with these requirements for its infrastructure and cooperate with the customer's compliance obligations. The agreement should specify the provider's CERT-In reporting obligations and the process for coordinating incident response between the customer and provider.
RBI for Financial Services SaaS: SaaS platforms used by banks, NBFCs, and payment system operators must comply with RBI outsourcing guidelines, data localisation requirements, and vendor risk management frameworks. The agreement must include: the right of RBI to access the provider's premises, audit rights, business continuity requirements, and the provider's obligation to maintain operations in India even if the provider's global operations are disrupted.
GST Treatment: SaaS provided by an Indian provider to an Indian customer attracts 18% GST. Cross-border SaaS raises complex questions: SaaS provided by a foreign provider to an Indian customer may attract GST under reverse charge mechanism, and the customer must self-assess and pay. The agreement should specify which party bears the GST obligation, whether the stated fees are inclusive or exclusive of GST, and the process for handling changes in tax treatment.
Platform Change Management and Feature Deprecation
SaaS platforms are living systems. The provider continuously updates the platform — adding features, modifying interfaces, updating APIs, and deprecating legacy capabilities. The customer chose the platform for its current feature set. Uncontrolled changes can disrupt the customer's operations.
Change Notification: The agreement should require the provider to notify customers of material platform changes: new features (30 days advance notice), interface changes (60 days), API changes (90 days, with backward compatibility for 12-24 months), feature deprecation (90-180 days), and security-related emergency changes (as soon as practicable). The notification should specify the nature of the change, the timeline, the impact on existing functionality, and any required customer action.
Backward Compatibility: For enterprises that have built integrations using the SaaS platform's APIs, backward compatibility is operationally critical. The agreement should require the provider to maintain backward compatibility for the current API version for at least 12 months after releasing a new version, provide migration tools and documentation for API transitions, and offer a sandbox environment for customers to test integrations against new API versions before production deployment.
Feature Deprecation Rights: If the provider deprecates a feature that was a material reason for the customer's subscription decision, the customer should have the right to: require the provider to maintain the feature for a defined transition period (typically 12 months), negotiate a replacement feature or workflow, or terminate the subscription without penalty if no adequate replacement is provided. This right prevents the provider from effectively changing the product the customer purchased.
Customer-Initiated Change Requests: The agreement should include a mechanism for the customer to request enhancements: the process for submitting requests, the provider's obligation to evaluate and respond, and the commercial terms for implementing customer-specific enhancements (whether included in the subscription or separately priced).
Dispute Resolution and Governing Law
SaaS disputes typically involve technical complexity: was the platform actually down or was the customer's network at fault? Did the provider's security failure cause the data breach or was the customer's credential management the root cause? The dispute resolution mechanism must be designed to handle technical fact-finding efficiently.
Technical Expert Determination: For SLA disputes and technical performance disagreements, the agreement should include a technical expert determination mechanism before escalating to arbitration. An independent technical expert, agreed by both parties, reviews the monitoring data, system logs, and technical evidence to determine whether the SLA was breached. The expert's determination is binding on both parties for factual matters and reduces the time and cost of formal dispute resolution.
Tiered Escalation: Tier 1 — Account manager and customer IT lead within 10 business days. Tier 2 — Senior management of both parties within 20 business days. Tier 3 — Mediation under the Mediation Act 2023. Tier 4 — Arbitration under the Arbitration and Conciliation Act 1996. Most SaaS disputes involve ongoing relationships — mediation preserves the relationship while providing a structured forum for resolution.
Arbitration: The agreement should specify: seat (Mumbai, New Delhi, or Bengaluru are typical for technology disputes), rules (MCIA for domestic, SIAC for cross-border), sole arbitrator for disputes below ₹5 crore, three-member tribunal for larger disputes, language (English), and timeline (12 months for the award). For SaaS agreements with foreign providers, the governing law and seat selection become particularly important — Indian customers should prefer an Indian seat to benefit from the supervisory jurisdiction of Indian courts.
Governing Law: Indian law governs for domestic SaaS. For cross-border SaaS, the foreign provider typically proposes their home jurisdiction's law. The customer should negotiate for Indian law for data protection matters (DPDPA compliance obligations) and the provider's home jurisdiction law for platform IP matters, with Indian arbitration seat. This split-law approach is increasingly common in cross-border technology agreements.
What You Need to Know
Is Your SaaS Agreement Built for the Exit?
The SaaS agreement that works during the subscription is rarely the agreement that works during the exit. Data portability, transition assistance, and vendor lock-in mitigation must be designed at the procurement stage, not negotiated during the wind-down.
[email protected]