A Kerala HealthTech startup and its FinTech partner set out to build something genuinely useful: a SaaS medical-billing platform that hospitals across the state could subscribe to. The product was strong. The SaaS agreement underneath it was not. As reported by a technology-law firm, the two companies ran the entire venture on a generic contract pulled off the internet rather than a bespoke India-specific document.
When the relationship soured, the cracks showed exactly where you would expect: who owned the platform’s intellectual property, how revenue was meant to be shared, and whether either side had locked the other into exclusivity. The dispute only got salvaged through mediation and a re-drafted agreement.
It’s a small story with a large lesson. India now houses 3,500 plus SaaS firms and more than 25 SaaS unicorns, a market that various industry estimates project will reach USD 50 billion by 2030, with billions in venture capital flowing in every year. That’s a staggering amount of money moving through contracts. And here’s the uncomfortable part: a large share of those contracts still run on pre-DPDP, US-style templates that are quietly non-compliant under Indian law.
The platform is Indian. The customers are Indian. The data is Indian. The contract, more often than not, is borrowed from somewhere else entirely.
Now, here’s where it gets interesting. The Digital Personal Data Protection Act, 2023 changed the arithmetic of risk in a way most of these templates never accounted for. Under the new regime, the customer (acting as the Data Fiduciary) stays liable for the vendor’s data handling “irrespective of any agreement to the contrary,” and a data breach can attract penalties of up to Rs 250 crore.
Meanwhile, the standard vendor contract caps the vendor’s own liability at twelve months’ fees. That mismatch isn’t a drafting quirk. It’s a financial time-bomb sitting inside thousands of Indian SaaS contracts, waiting for the first regulatory action to go off.
So let’s be clear about the stakes. A SaaS agreement in India is not boilerplate. The Kerala founders learned that the hard way, through a dispute that cost them time, legal fees, and very nearly the business itself. Contrast that with the in-house teams and contract counsel who treat the agreement as the product’s legal operating system, not an afterthought downloaded the night before a deal closes.
Those are the professionals who close enterprise deals faster, survive a DPDP audit without panic, and command real fees precisely because they can draft what most cannot. Get the clauses right, and you protect your IP, your data-compliance position, and your tax exposure all at once. Get them wrong, and you inherit someone else’s litigation.
A SaaS agreement in India is a contract granting a customer the right to access cloud-hosted software on a subscription basis, rather than transferring software copies. Governed by the Contract Act, the IT Act, the DPDP Act 2023 and GST law, it must cover the subscription, service levels, data protection, IP and liability.
Getting each of those elements right is what separates an enforceable, compliant SaaS agreement from a downloaded template that collapses under Indian law. Here’s how to draft one, clause by clause, starting with what the instrument actually is.
What is a SaaS agreement, and why generic templates fail in India
Every SaaS deal starts with a deceptively simple question: what exactly is the customer paying for? Get the answer wrong in the contract and everything downstream, from IP to tax, drifts off course. This is the situation the Kerala founders walked into, and it’s the most common point of confusion in SaaS contracting.
A SaaS agreement (Software as a Service agreement) is a contract under which a vendor grants a customer the right to access cloud-hosted software over the internet on a subscription basis. The customer never receives a copy of the software. There’s no installation file, no perpetual licence, no transfer of the code itself. The customer rents access to functionality that lives on the vendor’s (or a cloud provider’s) servers.
That distinction is the whole point. A perpetual software licence transfers a long-term right to use a specific copy of software; a SaaS agreement grants a recurring, revocable right to access a hosted service that the vendor continues to operate, update and control.
Why does the difference matter so much? Because the wrong instrument imports the wrong assumptions. A perpetual-licence template assumes the customer holds something tangible. A SaaS agreement has to account for uptime, data hosted on someone else’s infrastructure, ongoing payment, and what happens to that data when the subscription ends.
Borrow a licence template (or a US SaaS template) and you inherit clauses that simply don’t map onto Indian law: no DPDP carve-outs, no GST or OIDAR treatment, no stamp-duty awareness, governing-law provisions pointing at Delaware. The contract looks complete. It collapses the moment Indian regulation touches it.
In practice, what experienced technology-contract counsel know is that the failure rarely shows up at signing. It shows up at exit, during a data-breach incident, or in a tax assessment, which is to say at exactly the moment the customer can least afford it. A downloaded template feels like a saving on day one. It becomes the most expensive line item in the dispute that follows.
A short history of how SaaS contracting law evolved in India
SaaS contracting law in India didn’t arrive fully formed. It assembled itself in layers over two decades, which is precisely why pre-2023 templates are now outdated. The first layer came with the Information Technology Act, 2000, whose Section 10A (inserted by the Information Technology (Amendment) Act, 2008) confirmed that contracts formed electronically are valid and enforceable. That single provision is what makes clickwrap “I Agree” buttons binding in the first place.
The next layers stacked quickly. In 2017, the GST regime classified SaaS as a service taxed at 18% under the Online Information Database Access and Retrieval (OIDAR) category. In 2019, the Consumer Protection Act introduced the concept of an “unfair contract,” giving courts a statutory hook to nullify one-sided terms. And then in August 2023 came the largest reset of all: the Digital Personal Data Protection Act, 2023, followed by the DPDP Rules notified in 2025.
A SaaS agreement drafted before the DPDP Act simply does not contain the data-fiduciary allocations, breach-notification timelines, or sub-processor flow-down that the law now effectively demands. The template that was perfectly serviceable in 2022 is, today, a compliance gap.
Who needs a SaaS agreement, and the two sides of the table
A SaaS agreement has two sides, and the same document reads completely differently depending on which chair you’re sitting in. On the vendor side are SaaS companies selling subscriptions: they want predictable revenue, capped liability, and protection for their intellectual property. On the customer side are businesses (and their in-house counsel) subscribing to the software: they want uptime, control over their own data, and protection if the vendor’s platform causes a breach or a fine.
Founders sit in a third, often-overlooked seat. A startup building a SaaS product is a vendor to its customers but also a customer to its own cloud and infrastructure suppliers, which means it lives on both sides of the table at once. (That double exposure, as we’ll see in the liability section, is where a lot of growth-stage firms quietly get caught out.) Founders structuring these relationships also need to get their co-founder agreement right, because the IP and revenue questions that surfaced in the Kerala dispute often trace back to gaps between the founders before a single customer ever signs.
Which Indian laws govern a SaaS agreement
Ask most people which law governs a SaaS contract and they’ll name one statute. The real answer is at least six, working together, and missing any one of them leaves a hole. This is the foundational map every drafter needs before touching a single clause.
The Indian Contract Act, 1872 supplies the bones: formation (offer, acceptance, consideration, free consent), damages for breach under Sections 73 and 74, and indemnity under Sections 124 and 125. The Information Technology Act, 2000 makes the electronic contract valid through Section 10A, while the admissibility of the electronic record in evidence is governed by Section 65B of the Indian Evidence Act, 1872 (now Section 63 of the Bharatiya Sakshya Adhiniyam, 2023).
The Digital Personal Data Protection Act, 2023 controls how personal data flowing through the platform must be handled, who is liable, and what happens after a breach. GST law (principally the Central Goods and Services Tax Act, 2017) sets the tax treatment. The Arbitration and Conciliation Act, 1996 governs how disputes get resolved when the parties choose arbitration. And the Consumer Protection Act, 2019 supplies the unfair-contract doctrine that can strike down oppressive standard-form terms.
So is a SaaS agreement legally binding in India? Yes, and the anchor is electronic-contract validity. Because Section 10A of the IT Act recognises contracts formed by electronic means, a properly structured clickwrap or negotiated SaaS agreement is as enforceable as any signed-on-paper commercial contract, provided the Contract Act essentials are met.
(We unpack exactly how that plays out for clickwrap in the next section.) The binding force isn’t in doubt. What varies is how well the agreement survives a challenge, and that depends entirely on the drafting.
Worth flagging: these statutes don’t operate in neat silos. A single liability clause can be shaped by the Contract Act (damages), the DPDP Act (data-breach exposure that can’t be contracted away), and the IT Act (whether the e-signed version is admissible at all). The better approach, in our view, is to draft each clause with the full statutory map in view, not one Act at a time.
Contract Act essentials applied to SaaS
For a SaaS agreement to bind, the four Contract Act essentials still have to be present, just expressed in a digital form. There must be an offer (the vendor’s published terms), acceptance (the customer clicking “I Agree” or counter-signing the MSA), consideration (the subscription fee), and free consent (genuine, uncoerced agreement). The interesting question for SaaS is the last one. When terms are presented on a take-it-or-leave-it basis, is consent truly “free”?
The short answer is usually yes, but not always. Indian courts will generally uphold standard-form terms a customer clicked to accept, because clicking is acceptance. But where the terms are oppressive and the bargaining power grossly unequal, the free-consent and public-policy doctrines give a court room to intervene.
That’s not theoretical; it’s the exact terrain the standard-form fairness cases occupy, and it’s why a vendor who over-reaches in a clickwrap can find the very clause it relied on read down. Balanced drafting isn’t just good manners. It’s enforceability insurance.
Where DPDP, GST and the IT Act each plug in
Think of the statutory map as four plugs into four sockets. The IT Act plugs into formation and evidence (is the contract validly made, and can you prove acceptance?). The DPDP Act plugs into data (who is liable for personal data, and what must the data clauses say?). GST law plugs into money (how is the subscription taxed, and who pays?). The Contract Act plugs into everything structural (formation, damages, indemnity, termination).
Each of those gets a dedicated deep-dive below, so a reader who only needs the DPDP analysis or only the tax position can jump straight there. Data protection sits in the DPDP section; GST, OIDAR and stamp duty sit in the tax section; electronic execution and Section 65B proof sit in the execution section. The point of naming them here is simple: if your contract addresses formation but ignores DPDP, or covers data but never mentions GST, it isn’t an India-complete SaaS agreement. It’s a partial one wearing a complete one’s clothes.
Are clickwrap and browsewrap SaaS contracts enforceable in India?
Most SaaS contracts in India are never wet-signed. A customer clicks a checkbox, ticks “I have read and agree,” and starts using the product. So the question that keeps in-house counsel up at night is straightforward: does that click actually create a binding contract? For clickwrap, the answer is a reassuring yes. For its weaker cousins, it’s a heavily qualified maybe.
The legal foundation is Section 10A of the Information Technology Act, 2000, which validates contracts formed by electronic communication. Combine that with the Contract Act essentials, and a clickwrap “I Agree” becomes a genuine acceptance creating a genuine contract. The Supreme Court reinforced the underlying principle in Trimex International FZE Ltd. v. Vedanta Aluminium Ltd., (2010) 3 SCC 1, holding that a binding contract (including an arbitration agreement) can form through an exchange of emails once the Section 10 essentials are satisfied. If a contract can form by email, it can certainly form by a deliberate, recorded click.
But enforceability runs on a spectrum, and not every “acceptance” is created equal. Clickwrap, where the user must actively click to accept before proceeding, sits at the strong end: there’s a clear, recordable act of assent. Browsewrap, where terms are merely linked at the bottom of a page and the user is deemed to accept by continuing to browse, sits at the weak end, because proving the user ever saw the terms is genuinely difficult. A fully negotiated Master Services Agreement, signed or counter-signed, is the strongest of all. The practical reality is that a vendor relying on browsewrap is relying on the contractual equivalent of a handshake nobody remembers.
There’s a ceiling on enforceability too, even for clickwrap. One-sided or oppressive standard-form terms can be struck down where bargaining power is grossly unequal. The Supreme Court laid this down in Central Inland Water Transport Corporation Ltd. v. Brojo Nath Ganguly, (1986) 3 SCC 156, allowing courts to refuse enforcement of unconscionable terms in standard-form contracts, and reinforced it in LIC of India v. Consumer Education & Research Centre, (1995) 5 SCC 482, where unfair take-it-or-leave-it terms were held void.
So a vendor cannot simply bury a total liability exclusion in a clickwrap and assume it holds. A common question practitioners raise is whether “the customer clicked, so they’re bound to everything.” Not quite. They’re bound to fair terms they clicked. Oppressive ones remain vulnerable.
Clickwrap vs browsewrap vs negotiated SaaS contract
Here’s how the three formation methods compare on the dimensions that actually decide a dispute.
| Type | Enforceability | Notice required | Best use |
|---|---|---|---|
| Clickwrap | Strong: active assent is recorded | User must click to accept before access | High-volume, self-serve B2B and B2C SaaS sign-ups |
| Browsewrap | Weak: assent is only implied | Hard to prove the user saw the terms | Avoid for anything material; supplement at most |
| Negotiated MSA | Strongest: signed, bargained terms | Both parties sign or counter-sign | Enterprise deals, custom pricing, regulated data |
The drafting takeaway is to match the method to the deal. A self-serve product priced per seat can live on clickwrap perfectly well. An enterprise deal moving sensitive personal data should never rest on a checkbox alone. (Browsewrap, frankly, gets overlooked as a risk because it feels frictionless. That frictionlessness is exactly the problem when you later need to prove acceptance.)
Evidentiary proof: Section 65B certificates
Forming the contract is one thing. Proving it in court is another. When a SaaS contract has to be enforced, the acceptance lives as an electronic record: a server log of the click, a timestamped acceptance, an email exchange. To put that record before an Indian court, you generally need a certificate under Section 65B of the Indian Evidence Act, 1872 (now Section 63 of the Bharatiya Sakshya Adhiniyam, 2023), which authenticates the electronic record’s source and integrity.
This is where well-run SaaS vendors quietly pull ahead. They build an audit trail at the point of acceptance: who clicked, when, from which account, against which version of the terms. That trail, properly certified, is what turns “we have a contract” into “we can prove the contract.” Skip the evidence plan and you can find yourself holding a perfectly valid agreement you cannot actually establish in litigation. We’d recommend treating the Section 65B-ready audit trail as part of the contracting infrastructure, not an afterthought for the legal team to reconstruct later.
Key clauses every SaaS agreement in India must include
A SaaS agreement that’s missing a core clause isn’t a leaner contract. It’s an exposed one. Before drafting, it helps to have the full clause set in front of you, so you can see what each piece does and where the gaps would otherwise open up. These are the SaaS agreement key clauses that every India-ready document needs.
- Service description and scope of access
- Subscription, fees and payment
- Service level agreement (SLA) and uptime
- Data protection and data ownership
- Intellectual property ownership and licence grant
- Confidentiality
- Warranties and disclaimers
- Limitation of liability and indemnity
- Term, renewal and termination
- Governing law and dispute resolution
Each of those clauses earns its place by closing a specific risk. The service description defines what the customer is actually buying, which is the clause the Kerala dispute turned on. The payment clause sets out fees, billing cycle, taxes and what happens on non-payment. The SLA and the liability clause each get their own deep section below, because they carry the most India-specific complexity. What follows here is the practical drafting guidance on the remaining core clauses, grouped the way they tend to be negotiated.
Service description, subscription and payment clauses
The service description is the clause that defines the deal, and vague drafting here is where commercial disputes are born. Spell out exactly what functionality the subscription grants, the number of users or seats, any usage limits, and what counts as “the service” versus an optional add-on. The clearer this clause, the harder it is for either side to later argue the deliverable was something else.
The payment clause needs to do more than state a number. It should set the fee, the billing cycle, the currency, accepted payment methods, late-payment consequences (suspension, interest), and, critically for India, that fees are exclusive of GST so the tax position is unambiguous. Pay close attention to auto-renewal and price-escalation provisions. Auto-renewal clauses that roll the customer into a fresh term unless they cancel within a tight window are common, and so are uncapped annual price increases.
The practical fix is a renewal-notice requirement and a price-escalation cap (say, no more than a fixed percentage or a published index per year). Without those, a customer can find next year’s invoice materially higher with no realistic exit. So how long should the term be? For most B2B SaaS, an annual term with a clearly-defined renewal mechanism strikes the right balance between vendor revenue certainty and customer flexibility.
IP ownership and licence grant
This is the clause the Kerala founders fought over, and it’s the one customers most often misread. The default position in a well-drafted SaaS agreement is clean: the vendor retains all intellectual property in the software, the platform, and any improvements, while the customer receives a limited, non-exclusive, non-transferable licence to access and use the service for the subscription term. The customer is not buying the software. It’s renting access.
The mirror-image point is just as important: the customer owns its own data and configurations. Anything the customer uploads, generates, or configures inside the platform remains the customer’s property, and the vendor’s rights to that data should be limited to what’s necessary to provide the service.
Where things get genuinely contested is feedback, custom development, and AI-generated outputs. If the customer pays for bespoke features, who owns them? If the platform generates outputs from the customer’s data, whose are they? Leaving these silent (as the generic template did in Kerala) is an invitation to litigate. Name the owner of each category expressly.
Confidentiality, warranties and termination or exit
A SaaS confidentiality clause should be mutual and specific. Define what counts as confidential information, carve out the usual exceptions (information already public, independently developed, or lawfully obtained), set the duration of the obligation, and require return or destruction of confidential material on termination. Mutuality matters: a one-way NDA buried in a vendor’s standard terms is exactly the kind of imbalance a customer’s counsel should push back on.
Warranties are where vendors and customers tug hardest. A SaaS provider typically warrants that the service will perform materially in accordance with its documentation, that it has the right to grant the licence, and that it will comply with applicable law, then disclaims everything else (no warranty of uninterrupted or error-free service).
The termination and exit clause is the one customers neglect until it’s too late. It must cover termination rights (for cause, for convenience, for insolvency), and, more importantly, the exit mechanics: how the customer gets its data back, in what format, within what window, and confirmation that the vendor will delete the data afterward. Without a hard data-return-and-deletion clause, a customer can exit a contract and lose access to its own information. Think of it this way: the exit clause is the parachute. You hope never to use it, but you check it before you board.
MSA and Order Form precedence hierarchy
Real SaaS deals are rarely one document. They’re a stack: a Master Services Agreement (MSA) setting the legal terms, one or more Order Forms recording the commercial specifics, a Data Processing Agreement (DPA) for personal data, an SLA for uptime, and an Acceptable Use Policy (AUP). The question that wins or loses arguments is: which one controls when they conflict?
A precedence (order-of-priority) clause answers exactly that. A common and sensible hierarchy puts the Order Form on top for commercial terms (price, term, quantities), the DPA on top for data matters, and the MSA governing everything else, with policies incorporated by reference. That last phrase carries legal weight. The Supreme Court confirmed in M.R. Engineers & Contractors Pvt. Ltd. v. Som Datt Builders Ltd., (2009) 7 SCC 696 that incorporation by reference is valid where the reference is clear and specific, which is what lets a SaaS MSA pull in an SLA, DPA and AUP without restating them in full.
The drafting discipline is to make every cross-reference explicit (“the DPA attached as Schedule 2”) rather than vague (“our policies as updated from time to time”), because a loose reference is a weak incorporation. Frankly, this gets overlooked, and it’s the single most common structural defect we see in stitched-together SaaS paper.
How to draft the SLA and service-credit clause
The SLA is the clause that converts a marketing promise (“99.9% uptime!”) into an enforceable obligation, and the gap between those two things is where customers get burned. A SaaS SLA needs three working parts: a measurable uptime commitment, a defined remedy when the vendor misses it, and clear rules for how uptime is calculated. Drafting an SLA in a SaaS agreement well means getting all three to interlock.
Start with the uptime number, because the difference between tiers is larger than it looks. A 99.9% uptime commitment permits roughly 8.76 hours of downtime per year. Push to 99.99% and the allowance shrinks to about 52 minutes per year.
So which should a customer negotiate for? It depends on how critical the service is. A back-office reporting tool can live with 99.9%; a payments or healthcare platform where minutes of downtime cost real money should hold out for 99.99% (and price accordingly). The vendor will resist the higher tier because it raises their operational risk, which is precisely why it belongs in the negotiation.
The remedy for a missed SLA is the service credit: a percentage of the monthly fee refunded or credited when uptime falls below the committed level. Here’s the India-specific trap most templates ignore. A service credit is, in substance, a pre-agreed sum payable on breach, which means it sits squarely within Section 74 of the Indian Contract Act, 1872 (compensation for breach where a sum is named in the contract). Drafted badly, a service credit can be attacked as a penalty rather than a genuine pre-estimate of loss, and penalties aren’t recoverable beyond reasonable compensation.
The line between liquidated damages and a penalty under Section 74 is exactly the kind of analysis that decides whether the credit survives a challenge. The practical fix is to frame service credits as a genuine, proportionate pre-estimate of the customer’s loss from downtime, not as a punitive multiple, and to tie them to a rational uptime-to-credit ladder.
Worked example: calculating a monthly uptime service credit
The cleanest way to make service credits enforceable and transparent is a banded ladder: the worse the uptime, the larger the credit, in proportionate steps. Here’s a representative structure for a service with a 99.9% monthly commitment.
| Uptime achieved | Approx. monthly downtime | Service credit (% of monthly fee) |
|---|---|---|
| 99.9% or above | Up to ~43 minutes | 0% (commitment met) |
| 99.0% to 99.89% | ~43 min to ~7.3 hours | 10% |
| 95.0% to 98.99% | ~7.3 to ~36 hours | 25% |
| Below 95.0% | More than ~36 hours | 50% |
The proportionality is doing the legal work here. Because each band reasonably tracks the escalating harm of more downtime, the credit reads as a genuine pre-estimate of loss rather than a penalty, which is what keeps it defensible under Section 74. (A flat “100% credit for any miss” would look punitive and invite exactly the challenge you’re trying to avoid.) Customers should also negotiate the right to terminate for chronic breach, because a credit alone is cold comfort if the platform is down every month.
Exclusions, measurement windows and sole-remedy caveats
The fine print of an SLA can quietly hollow it out, so read the exclusions closely. Vendors typically exclude downtime caused by scheduled maintenance, the customer’s own misuse, third-party failures, and force majeure. Some of that is fair; a maintenance window announced in advance is reasonable. But watch for exclusions broad enough to swallow the commitment, such as undefined “emergency maintenance” with no cap on frequency or duration.
The measurement window matters just as much as the number. Is uptime measured monthly or annually? A monthly window is far more customer-friendly, because a bad week shows up immediately rather than being averaged away across a year.
And then there’s the “sole and exclusive remedy” caveat, where the vendor says service credits are the customer’s only remedy for downtime. A customer should resist making credits the sole remedy for serious or persistent failures, and at minimum preserve the right to terminate. In practice, the SLA is often the most negotiated schedule in the whole agreement, because it’s where service quality meets money.
Limitation of liability and indemnity: the re-architecture playbook
If there’s one clause where Indian SaaS contracts are systematically mis-drafted, it’s this one. The limitation of liability clause decides who absorbs the cost when something goes badly wrong, and the standard vendor template is engineered to make sure that someone is the customer. Understanding how the cap is built (and where it leaks) is the difference between a clause that protects you and one that protects only the other side.
The typical liability cap limits each party’s total liability to the fees paid in a defined period, most commonly the trailing twelve months, sometimes twenty-four. So what should the cap actually be? For balanced enterprise deals, twenty-four months’ fees is a more defensible position for the customer, because twelve months can be trivially small relative to the damage a platform failure or data breach can cause.
The bigger problem is asymmetry. Vendor form contracts routinely cap the vendor’s liability while leaving the customer’s payment and indemnity obligations effectively uncapped, which means the contract is “mutual” in name only. Why do vendors draft it this way? Because it shifts risk off their balance sheet, and most customers never read the cap closely enough to push back.
Then there are the carve-outs, and this is where the real protection lives. Certain categories of harm should sit outside the liability cap entirely, because capping them would defeat the purpose of having them in the contract at all. Data-breach liability, IP infringement indemnity, breach of confidentiality, and regulatory fines are the standard carve-outs. A vendor will resist each one (an uncapped data-breach exposure is genuinely frightening to a vendor), but a customer that lets data breaches sit inside a twelve-month cap has effectively agreed that the most catastrophic risk is also the most cheaply settled. That’s backwards.
The DPDP Act adds a hard constraint that no liability clause can override, and it’s worth flagging here before the full treatment below. Under Section 8(1) of the DPDP Act, the customer-as-Data-Fiduciary stays liable for the vendor’s data handling “irrespective of any agreement to the contrary.” Read that phrase again. No liability cap, no indemnity, no clever drafting can shift the Data Fiduciary’s statutory liability onto the vendor. So the cap has to be drafted around that reality, not in denial of it.
Indemnities deserve their own attention. Under Sections 124 and 125 of the Indian Contract Act, 1872, an indemnity is a promise to make good a loss, and a SaaS agreement typically includes mutual indemnities for IP infringement and, increasingly, data breaches. Here’s a misconception worth correcting: a blanket exclusion of “consequential loss” or regulatory fines from the indemnity is often ineffective, because the customer’s regulatory exposure under DPDP is precisely the loss the indemnity exists to cover. If you exclude it, the indemnity becomes decorative. The mistake we see most often is a vendor cheerfully offering a data-breach indemnity and then quietly excluding regulatory fines from it, leaving the customer indemnified for everything except the one thing that actually hurts.
What to carve out of the liability cap
Here’s the carve-out map a customer’s counsel should work from, and the reason each item belongs outside the cap.
| Risk | Inside the cap? | Recommended treatment |
|---|---|---|
| Ordinary service failures | Yes | Capped at 12 to 24 months’ fees |
| Data-breach liability | No | Carved out (uncapped or a separate higher super-cap) |
| IP infringement indemnity | No | Carved out; vendor indemnifies fully |
| Breach of confidentiality | No | Carved out or subject to a higher cap |
| Regulatory fines (DPDP) | No | Carved out; cannot be shifted off the Data Fiduciary |
| Payment obligations | No (by nature) | Always payable in full |
A vendor will fight several of these, and that’s normal; negotiation is the point. But a customer who accepts every risk inside a single twelve-month cap has signed a clause that looks protective and isn’t. The carve-outs are not luxuries. They’re the load-bearing part of the clause.
The vendor exposure gap
There’s a second-order consequence of all this that most parties miss, and it bites the vendor rather than the customer. As growth-stage Indian SaaS firms scale, their enterprise customers increasingly demand enhanced data-breach liability and uncapped indemnities, which the vendor grants to win the deal. But those same vendors typically sit beneath cloud and infrastructure suppliers whose own contracts cap liability at twelve months’ fees. The vendor has promised more downstream than it can recover upstream.
That gap doesn’t stay still. As DPDP enforcement intensifies and a breach at the infrastructure layer cascades into the vendor’s enterprise commitments, growth-stage firms are likely to face renegotiation pressure all the way up the supply chain, pushing to align their upstream caps with their downstream promises. Early signals suggest the smartest vendors are already auditing this mismatch before it becomes a balance-sheet problem. The contract you sign with your customer is only as strong as the contract you signed with your cloud provider. Most firms discover that connection the hard way.
Data protection under the DPDP Act 2023: the SaaS liability re-architecture
This is the section that should change how you read every SaaS contract you touch. The Digital Personal Data Protection Act, 2023 didn’t just add a data clause to the SaaS checklist. It re-wired who bears the risk, and most contracts haven’t caught up. If you draft a SaaS agreement data protection clause for India the way you would have in 2022, you’re drafting a compliance gap.
Start with the roles, because everything flows from them. Under the DPDP Act, the customer is usually the Data Fiduciary (the entity that decides why and how personal data is processed), and the SaaS vendor is the Data Processor (the entity processing data on the Fiduciary’s behalf). That allocation isn’t cosmetic. It determines who answers to the regulator.
And here is the provision that re-architects everything: under Section 8(1) of the Digital Personal Data Protection Act, 2023, the Data Fiduciary remains responsible for compliance “irrespective of any agreement to the contrary,” including for processing carried out by its processor. The customer cannot contract its way out of liability for the vendor’s data handling. No cap, no indemnity, no clause can move that statutory responsibility.
The numbers make the stakes concrete. A breach of the Act’s security-safeguard obligations can attract a financial penalty of up to Rs 250 crore, and the DPDP framework requires prompt breach notification, with the Data Principal and the Data Protection Board to be informed in line with the timelines set out in the DPDP Rules (a tight window measured in hours, not days). So when a customer is told “the vendor will indemnify us,” the right response is: an indemnity is a contractual promise that depends on the vendor’s solvency and willingness to pay, whereas the Section 8(1) liability is statutory and lands on the customer first. The indemnity is a backstop, not a shield.
That’s why the vendor’s continued liability for its sub-processors matters so much. A SaaS vendor rarely runs everything itself; it relies on cloud hosting, email providers, analytics tools, each a sub-processor. The vendor remains liable for those sub-processors, and the contract must flow the data obligations down to them and give the customer rights to know who they are and, ideally, to object.
What is a sub-processor in practice? It’s anyone the vendor hands your data to in order to deliver the service, and the rule of thumb experienced data counsel use is simple: if your data touches a third party, that third party is your problem until the contract makes it the vendor’s problem. Audit rights, sub-processor consent, and a sub-processor list are how you make that shift.
Cross-border transfer is the other place templates go wrong. Under Section 16 of the Digital Personal Data Protection Act, 2023, the government may restrict transfers of personal data to certain countries, and the key drafting insight is that DPDP jurisdiction follows the data, not the server. Hosting data on a server outside India does not place it outside DPDP’s reach if it relates to Indian Data Principals. So a contract that assumes “our data is in Singapore, so DPDP doesn’t apply” has misread the statute entirely. The data clause must address transfer restrictions, localisation where required, and the practical points that follow a breach or an exit: portability, return, and deletion of the data on termination.
Mandatory DPDP clauses for a SaaS agreement
A DPDP-ready SaaS agreement needs a defined set of data clauses, each tied to a specific obligation in the Act. These are the ones that should never be missing.
| Clause | DPDP basis | What it must say |
|---|---|---|
| Purpose limitation | Lawful-processing principle | Vendor processes data only for the specified, agreed purpose |
| Security safeguards | Section 8 security obligation | Vendor implements reasonable technical and organisational measures |
| Breach notification | DPDP Rules notification timeline | Vendor notifies the customer immediately, enabling onward Board/Principal notice |
| Sub-processor controls | Processor accountability | Sub-processor list, flow-down of obligations, customer consent or objection rights |
| Deletion on termination | Storage-limitation principle | Data returned and then deleted on exit, with confirmation |
| Audit rights | Fiduciary oversight duty | Customer can audit or obtain evidence of the vendor’s compliance |
The mistake we see most often is treating data protection as a single sentence (“the vendor will comply with applicable data-protection law”) instead of the structured set above. That sentence is not a clause. It’s a hope.
Do you need a separate Data Processing Agreement?
Yes, in almost every case where personal data is involved. The Data Processing Agreement (DPA) is the companion document to the SaaS agreement: it’s the place where the detailed processor obligations, sub-processor terms, security measures, breach procedures and audit rights actually live, so the main MSA doesn’t get cluttered and the data terms can be updated as the law evolves. A SaaS agreement that names personal data but has no DPA behind it is incomplete.
For the full mechanics of how a DPDP-compliant DPA is structured, including the model clauses and the processor-fiduciary allocation in detail, it’s worth setting up a dedicated data processing agreement under the DPDP Act alongside the SaaS contract. The two documents are designed to work as a pair: the SaaS agreement governs the service, the DPA governs the data.
Cross-border data and the foreign-vendor question
A large share of SaaS used in India comes from foreign vendors hosting data abroad, which raises the question every procurement team eventually asks: does Indian data protection law even apply? It does. The DPDP Act has extraterritorial reach where the processing relates to offering goods or services to Data Principals in India, so a foreign SaaS vendor serving Indian customers is squarely within scope.
The drafting consequence is that “the data sits on US servers” is not an answer to a DPDP question. Section 16 lets the government restrict transfers to specified countries, and the Fiduciary’s obligations travel with the data regardless of where the server is. So a contract with a foreign vendor needs the same DPDP architecture as a domestic one: clear roles, breach notification that meets Indian timelines, sub-processor controls, and a transfer clause that anticipates restriction. Server geography is a logistics detail. It is not a jurisdictional escape hatch.
GST, stamp duty and tax treatment of SaaS in India
Tax is the part of SaaS contracting that lawyers tend to wave off to the finance team and finance teams assume the lawyers handled. The result is contracts that get the tax treatment wrong, and in India that’s an expensive blind spot. Here’s the practical map of GST on SaaS in India, plus stamp duty, in the detail a drafter actually needs.
The starting point is classification. SaaS is treated as a service under GST, specifically as an Online Information Database Access and Retrieval (OIDAR) service, taxed at 18%. The place of supply rule generally fixes the supply at the recipient’s location, which matters enormously for cross-border deals. When a foreign SaaS vendor supplies an Indian business customer, the reverse-charge mechanism typically applies, meaning the Indian recipient accounts for the GST rather than the foreign vendor. So the contract’s price clause needs to state clearly whether fees are inclusive or exclusive of GST, and which party bears the tax, because an ambiguous price clause turns into a tax dispute at the first invoice.
There’s a freshness point here that no competing guide carries. The Equalisation Levy (the 2% charge that applied to certain digital and SaaS supplies by non-resident providers) was abolished with effect from 1 August 2024. Contracts and tax memos still referencing it are out of date, and a drafter who removes a now-defunct Equalisation Levy clause from a borrowed template signals exactly the kind of current-law fluency that distinguishes good drafting from copy-paste.
Stamp duty is the quietly tricky one, because it’s a state subject and there’s no single national rule for an electronically-executed SaaS contract. Stamp duty on agreements varies by state, and the treatment of e-contracts (and e-stamping practicalities) differs across jurisdictions. The practical drafting move is to identify the relevant state (usually tied to where the agreement is executed or the place of the parties), check that state’s stamp schedule for the applicable instrument, and use e-stamping where the state’s framework supports it. Treating stamp duty as “not applicable because it’s electronic” is a common and risky assumption; the better approach is to verify the position state by state.
The SaaS tax table
Here’s the SaaS India tax position at a glance, which doubles as a quick-reference for the price and tax clauses.
| Item | Treatment | Rate or note |
|---|---|---|
| GST classification | Service, taxed as OIDAR | 18% GST |
| Place of supply | Recipient’s location | Determines Indian taxability |
| Foreign vendor to Indian business | Reverse charge | Indian recipient accounts for GST |
| Equalisation Levy | Abolished | Effective 1 August 2024 |
| Stamp duty | State-dependent | Varies by state; verify per jurisdiction |
The single most useful thing this table does is force the price clause to be specific. Once you know GST is 18% and may fall on the recipient under reverse charge, “fees are Rs X” becomes “fees are Rs X exclusive of GST, which the recipient shall account for under reverse charge where applicable.” That’s the difference between a clause and an argument waiting to happen.
Does a foreign SaaS provider have to comply with Indian GST and DPDP?
Short answer: yes, on both counts. On GST, a foreign provider supplying digital or SaaS services to Indian customers falls within the OIDAR framework, and depending on whether the customer is a business or a non-taxable recipient, either the reverse-charge mechanism applies or the foreign provider must register and account for Indian GST itself. On DPDP, as covered above, the Act’s extraterritorial reach pulls a foreign vendor serving Indian Data Principals into scope.
The combined effect is that a foreign SaaS vendor cannot treat India as out of reach simply because it has no Indian office. Both the tax regime and the data-protection regime follow the customer and the data, not the vendor’s address. For an Indian customer, that’s reassuring: it means the contract can and should hold a foreign vendor to Indian standards. For the foreign vendor, it means an India-specific contract is not optional.
Common mistakes when drafting or signing a SaaS agreement in India
After all the clause-by-clause detail, it helps to step back and look at the patterns, because the same handful of mistakes shows up again and again. Recognising them is faster than re-reading the whole contract, and most of these are avoidable in a single review pass. So what goes wrong most often?
The most damaging SaaS contract mistakes in India
The first mistake is the one the Kerala startups made: using a downloaded US template. It imports clauses that don’t map onto Indian law, omits DPDP and GST treatment entirely, and points governing law at the wrong jurisdiction. The second is accepting an asymmetric liability position, where the customer’s exposure is uncapped while the vendor’s is capped at twelve months’ fees. The third is ignoring the DPDP carve-outs, leaving data-breach and regulatory-fine exposure trapped inside a cap that can’t legally hold the Section 8(1) liability anyway. Each of these feels like a detail at signing and behaves like a crisis later.
The remaining mistakes cluster around things that only matter at the worst moment. Treating server location as the DPDP test (it isn’t; jurisdiction follows the data) leaves a foreign-hosted contract under-protected. Missing a hard data-return-and-deletion clause means a customer can exit and lose its own data, or worse, leave its data sitting on a vendor’s servers indefinitely. And having no Section 65B evidence plan means a perfectly valid clickwrap contract that you can’t actually prove in court.
None of these is exotic. They’re the predictable failure points, and a single careful review catches all of them.
Vendor-side vs customer-side mistakes
The same contract produces different mistakes depending on which side drafted or signed it. Here’s the split.
| Vendor-side mistakes | Customer-side mistakes |
|---|---|
| Over-reaching with oppressive standard-form terms that a court can read down | Signing a US template without checking DPDP, GST and stamp duty |
| Granting uncapped data-breach liability downstream while capped upstream | Accepting an uncapped customer liability against a capped vendor |
| Weak browsewrap acceptance with no Section 65B audit trail | Letting data-breach and regulatory fines sit inside the liability cap |
| Vague service description inviting scope disputes | Missing the data-return-and-deletion exit clause |
| No clear sub-processor flow-down to cloud suppliers | Assuming foreign hosting puts the data outside DPDP |
What this table really shows is that good SaaS drafting isn’t about winning every clause. It’s about each side closing the gaps it tends to ignore. The vendor who fixes its acceptance trail and the customer who fixes its carve-outs end up with a contract that actually works for both.
Executing a SaaS agreement and resolving disputes
You’ve negotiated the clauses. Now the contract has to be signed and, if things go wrong, enforced. Both ends of that lifecycle have India-specific wrinkles that a US template won’t have prepared you for. Getting execution and dispute resolution right is what makes everything above actually usable.
Execution, for most SaaS, is electronic. A clickwrap acceptance, an e-signature, or a counter-signed PDF all create a valid contract under Section 10A of the Information Technology Act, 2000, provided the Contract Act essentials are present. The practical step that separates a defensible execution from a fragile one is the audit trail: capture who accepted, when, against which version of the terms, and retain it in a form you can later certify under Section 65B. (We covered the evidence mechanics in the enforceability section; the execution takeaway is to build the trail at the moment of signing, not reconstruct it during a dispute.) For higher-value enterprise deals, a counter-signed MSA with proper e-signatures gives the cleanest evidentiary position.
Dispute resolution is where cross-border SaaS gets genuinely complicated, and the governing-law and dispute clause deserves real thought rather than a copy-paste. The contract should specify the governing law, the dispute mechanism (arbitration or litigation), and, for arbitration, the seat and the venue. For an Indian customer dealing with a foreign vendor, the instinct to accept the vendor’s home jurisdiction is usually a mistake, because enforcing an award or judgment becomes far harder.
So what governing law and dispute clause should a SaaS agreement use? For India-centric deals, Indian governing law with arbitration seated in India is the cleanest position; for genuinely cross-border deals, a neutral seat with a clear choice of law beats whichever party’s home turf the other side proposes. The most common SaaS disputes in India, for what it’s worth, cluster around exactly the clauses this guide has emphasised: IP ownership, data and breach liability, payment and renewal, and service-level failures.
Arbitration vs litigation for SaaS disputes
For most commercial SaaS contracts, arbitration is the preferred route, and the reasons are practical. Arbitration is private (useful when the dispute touches confidential platform details or a data breach), generally faster than crowded commercial courts, and produces an award that’s enforceable across borders under international conventions, which matters when one party sits abroad. Litigation has its place for urgent injunctive relief and for low-value disputes where the cost of arbitration outweighs the benefit, but for the typical B2B SaaS relationship, a well-drafted arbitration clause is the better default.
The seat-versus-venue distinction is where cross-border arbitration clauses live or die, and the Supreme Court’s Constitution Bench settled the framework in Bharat Aluminium Co. v. Kaiser Aluminium Technical Services Inc., (2012) 9 SCC 552. The seat determines which courts have supervisory jurisdiction over the arbitration and which law governs the arbitral process, while the venue is merely the physical location of hearings. Conflating the two (writing “venue: Singapore” when you meant the seat) can hand supervisory jurisdiction to a court you never intended. The drafting discipline, anchored in the Arbitration and Conciliation Act, 1996, is to name the seat expressly and separately from the venue, so there’s no ambiguity about which courts can intervene.
Future outlook for SaaS contracting in India
The next two to five years are likely to reshape SaaS contracting more than the last ten did, and the direction of travel is already visible. As the DPDP Rules operationalise and the Data Protection Board begins active enforcement, the data clauses that are negotiated line by line today will harden into market-standard terms, with data-breach carve-outs, sub-processor flow-down, and cross-border contingency clauses becoming default rather than optional. Early signals from the way enterprise customers are already drafting suggest this shift is well underway.
Two further trends are worth watching. AI-in-SaaS contracting is pushing model-error indemnity, training-data IP, and AI-output liability into MSAs, as products that were pure software become products that make decisions. And cyber-insurance-backed risk transfer is emerging as the realistic answer to data-breach exposure that no liability cap can absorb, with insurers increasingly part of the SaaS risk conversation. Practitioners expect that the SaaS agreement of 2028 will look meaningfully different from today’s, and the firms building those clauses now will be the ones setting the standard rather than scrambling to catch up.
SaaS agreement vs software licence vs subscription agreement
These terms get used interchangeably, and that loose usage causes real drafting errors, because the wrong instrument imports the wrong assumptions. A SaaS agreement is not a software licence, and neither is quite the same as a generic subscription agreement. Knowing which instrument fits the deal is the first decision, before any clause gets drafted.
The cleanest way to see the differences is side by side, across the dimensions that actually change the legal and tax treatment.
| Instrument | Delivery | IP | Payment | India tax treatment |
|---|---|---|---|---|
| SaaS agreement | Cloud-hosted access, no copy delivered | Vendor retains; customer gets limited access licence | Recurring subscription | Service, OIDAR, 18% GST |
| Perpetual software licence | Copy installed or delivered to the customer | Long-term licence to use a specific copy | One-time (often with annual maintenance) | Can attract differing GST treatment depending on supply |
| Subscription agreement | Generic recurring-payment framework | Depends on the underlying product | Recurring | Depends on what’s supplied |
| MSA or Terms of Service | Umbrella legal terms over a service relationship | Set by the underlying deal | Set by Order Form | Follows the service supplied |
The distinctions are practical, not academic. SaaS is really a specialised subset of the broader service-contract family, and it helps to understand how SLAs and stamp duty work in a general service agreement before drilling into the SaaS-specific layers. Choose a SaaS agreement when the customer accesses hosted software it never installs; choose a perpetual licence when a copy is genuinely delivered and the customer wants long-term rights in that copy; use a subscription agreement only as a generic wrapper when the recurring relationship doesn’t fit a cleaner instrument.
And how do an MSA and Terms of Service differ for SaaS? An MSA is a negotiated, signed master contract for a specific relationship, while Terms of Service are the vendor’s standard, non-negotiated terms applied to all users; the same SaaS product might use an MSA for enterprise customers and clickwrap ToS for self-serve sign-ups.
There’s also a meaningful gap between drafting a SaaS agreement for India versus the US, and it’s bigger than swapping the governing-law clause. India-specific drafting has to account for the DPDP Act (where the US would use GDPR or CCPA concepts that don’t map cleanly), GST and OIDAR (where the US has sales tax that works entirely differently), stamp duty (a state subject with no US equivalent), and Indian governing law and dispute resolution. A US template handles none of these, which is precisely why the borrowed-template approach fails. The instrument has to be Indian, not just labelled as such.
SaaS agreement drafting checklist (before you sign)
Everything in this guide condenses into a pre-signature checklist, the kind of scannable list competitors rarely provide. Run through it before signing any SaaS agreement in India, grouped by the area each item protects. If you can tick every box, the contract is genuinely India-ready.
Commercial 1. Service description precisely defines what’s included and excluded 2. Fees are stated exclusive of GST, with reverse charge addressed where relevant 3. Auto-renewal has a notice requirement and the price escalation is capped 4. Term and renewal mechanics are clear
Data and DPDP 5. Data Fiduciary and Data Processor roles are correctly allocated 6. Mandatory DPDP clauses are present (purpose limitation, security, breach notice, sub-processor controls, deletion) 7. A separate Data Processing Agreement is in place 8. Cross-border transfer and Section 16 restrictions are addressed
Liability 9. The liability cap is mutual, not one-sided 10. Data breach, IP indemnity, confidentiality and regulatory fines are carved out of the cap 11. Indemnities do not exclude the DPDP regulatory exposure they exist to cover
IP 12. Vendor IP and customer data ownership are clearly separated 13. Custom development, feedback and AI-output ownership are expressly assigned
Tax 14. GST, OIDAR and reverse charge are correctly reflected in the price clause 15. Stamp duty is verified for the relevant state
Execution 16. Electronic execution is valid under Section 10A and an audit trail exists for Section 65B proof
Exit 17. Data return and deletion on termination is mandatory, with format and timeline specified 18. Governing law, seat and dispute mechanism are clearly drafted for the cross-border position
The discipline this checklist enforces is simple but powerful: it stops you signing a contract that’s strong on the clauses you happened to read and silent on the ones you skipped. Most SaaS disasters trace back to a box that nobody ticked.
Frequently asked questions
1. What is a SaaS agreement? A SaaS (Software as a Service) agreement is a contract under which a vendor grants a customer the right to access cloud-hosted software on a subscription basis, without transferring any software copy. The customer rents access to functionality running on the vendor’s servers, rather than buying or installing the software itself.
2. Is a SaaS agreement legally binding in India? Yes. Section 10A of the Information Technology Act, 2000 validates contracts formed electronically, so a properly structured clickwrap or negotiated SaaS agreement is binding once the Indian Contract Act essentials (offer, acceptance, consideration, free consent) are met. Enforceability depends on the quality of the drafting and the proof of acceptance.
3. Which Indian laws govern a SaaS agreement? At least six work together: the Indian Contract Act, 1872 (formation, damages, indemnity), the Information Technology Act, 2000 (e-contracts, evidence), the DPDP Act, 2023 (data), GST law (tax), the Arbitration and Conciliation Act, 1996 (disputes) and the Consumer Protection Act, 2019 (unfair terms). Missing any one leaves a gap.
4. What is the difference between a SaaS agreement and a software licence agreement? A SaaS agreement grants recurring, revocable access to hosted software the vendor continues to operate; no copy is delivered. A perpetual software licence transfers a long-term right to use a specific delivered copy. The difference drives IP, payment, hosting and even GST treatment.
5. Is the SaaS vendor a Data Fiduciary or a Data Processor? Usually a Data Processor. The customer typically decides why and how personal data is processed, making it the Data Fiduciary, while the SaaS vendor processes that data on the customer’s behalf as the Data Processor. The roles determine who answers to the regulator.
6. Do I need a separate Data Processing Agreement with my SaaS vendor? In almost every case where personal data is involved, yes. The DPA is the companion document that houses detailed processor obligations, sub-processor terms, security measures, breach procedures and audit rights, keeping the main agreement clean and the data terms updatable as the law evolves.
7. What is the DPDP penalty for a data breach? A breach of the security-safeguard obligations under the Digital Personal Data Protection Act, 2023 can attract a financial penalty of up to Rs 250 crore. The Act and DPDP Rules also require prompt breach notification to the affected Data Principals and the Data Protection Board within tight timelines.
8. Can SaaS data be stored or processed outside India? Generally yes, but DPDP still applies. Under Section 16 of the DPDP Act, the government can restrict transfers to specified countries, and the Fiduciary’s obligations follow the data regardless of server location. Hosting abroad does not place Indian Data Principals’ data outside the Act’s reach.
9. How do you draft an SLA in a SaaS agreement? Draft three interlocking parts: a measurable uptime commitment (such as 99.9% or 99.99%), a defined remedy (service credits), and clear rules for calculating uptime, including exclusions and the measurement window. Frame service credits as a proportionate pre-estimate of loss so they survive challenge as liquidated damages under Section 74.
10. What uptime should a SaaS SLA guarantee, 99.9% or 99.99%? It depends on how critical the service is. 99.9% allows roughly 8.76 hours of downtime a year and suits non-critical tools. 99.99% allows about 52 minutes a year and suits payments, healthcare or other systems where minutes of downtime cause real loss. Higher uptime costs more and the vendor will resist it.
11. Is a clickwrap SaaS agreement enforceable in India? Yes, clickwrap is the strong end of the enforceability spectrum because the user actively clicks to accept, creating recordable assent under Section 10A of the IT Act. The exception is genuinely oppressive standard-form terms, which Indian courts can read down even where the customer clicked to accept.
12. What is a SaaS agreement checklist before signing? A grouped pre-signature review covering commercial terms (service scope, fees, renewal), data and DPDP clauses, a mutual liability cap with the right carve-outs, IP ownership, GST and stamp-duty treatment, valid electronic execution with an evidence trail, and a hard data-return-and-deletion exit clause. The detailed list appears in the checklist section above.
13. What governing law and dispute-resolution clause should a SaaS agreement use? For India-centric deals, Indian governing law with arbitration seated in India is cleanest. For cross-border deals, choose a neutral seat with a clear choice of law rather than accepting the other party’s home jurisdiction. Always name the seat separately from the venue to avoid handing supervisory jurisdiction to the wrong court.
14. What should the liability cap be, 12 or 24 months’ fees? Twelve months is the vendor’s typical default, but 24 months is the more defensible position for a customer, because twelve months can be trivially small relative to the harm a platform failure or breach can cause. More important than the number is making the cap mutual and carving out data breach, IP indemnity and regulatory fines.
15. Who owns the data in a SaaS agreement? The customer owns its own data and configurations; anything the customer uploads, generates or configures inside the platform remains the customer’s property. The vendor retains IP in the software and platform. The vendor’s rights to the customer’s data should be limited to what’s strictly necessary to provide the service.
16. Is GST applicable on SaaS in India and at what rate? Yes. SaaS is treated as a service under GST, classified as OIDAR, and taxed at 18%. The place of supply is generally the recipient’s location, and where a foreign vendor supplies an Indian business, the reverse-charge mechanism typically applies so the Indian recipient accounts for the GST.
17. Is stamp duty payable on a SaaS agreement? Possibly, and it depends on the state. Stamp duty is a state subject, so the treatment of an agreement (including electronically executed ones) varies by jurisdiction. Verify the relevant state’s stamp schedule and use e-stamping where supported, rather than assuming an electronic contract is automatically exempt.
18. Why are downloaded or generic SaaS templates risky in India? Because they import clauses built for other legal systems and omit India-specific essentials: DPDP carve-outs, GST and OIDAR treatment, stamp duty, IT Act e-contract proof, and Indian governing law. The most common SaaS disputes in India, over IP, data liability, payment and service levels, trace back to exactly the gaps these templates leave.
References
Case Law
- Bharat Aluminium Co. v. Kaiser Aluminium Technical Services Inc., (2012) 9 SCC 552; Supreme Court of India, Constitution Bench, 6 September 2012.
- Central Inland Water Transport Corporation Ltd. v. Brojo Nath Ganguly, (1986) 3 SCC 156; AIR 1986 SC 1571; Supreme Court of India, 6 April 1986.
- LIC of India v. Consumer Education & Research Centre, (1995) 5 SCC 482; AIR 1995 SC 1811; Supreme Court of India, 10 May 1995.
- M.R. Engineers & Contractors Pvt. Ltd. v. Som Datt Builders Ltd., (2009) 7 SCC 696; Supreme Court of India, 7 July 2009.
- Trimex International FZE Ltd. v. Vedanta Aluminium Ltd., (2010) 3 SCC 1; Supreme Court of India, 22 January 2010.
Statutes
- Indian Contract Act, 1872; sections cited: 10, 73, 74, 124, 125.
- Indian Evidence Act, 1872; section cited: 65B (now Section 63 of the Bharatiya Sakshya Adhiniyam, 2023).
- Indian Stamp Act, 1899.
- Arbitration and Conciliation Act, 1996.
- Information Technology Act, 2000; section cited: 10A.
- Central Goods and Services Tax Act, 2017.
- Consumer Protection Act, 2019.
- Digital Personal Data Protection Act, 2023; sections cited: 8, 16; the maximum penalty of Rs 250 crore is prescribed in the Schedule read with Section 33; read with the Digital Personal Data Protection Rules, 2025.
Product teams should understand the misclassification risk when you engage developers as consultants instead of employees.
This article is for informational purposes only and does not constitute legal advice. For specific legal guidance, consult a qualified legal professional.
