Master Service Agreements for IT Services in India: 10 Clauses Technology Companies Should Review Carefully

Quick Answer

An MSA is not a formality; it is the document that allocates commercial risk between a technology company and its customer for the life of the relationship. It determines who owns the code once it's delivered (Indian copyright law does not hand that over automatically), what happens when an SLA is missed, how liability is capped, and what obligations survive termination. Most disputes that reach a lawyer's desk years into an engagement trace back to one of these points being left vague at signing, not to bad faith on either side.

Introduction

Most technology companies treat the Master Service Agreement as a formality to clear before the real work, the Statement of Work, the delivery timeline, begins. That's a mistake. Across technology contracts in India, whether structured as a classic MSA, a SaaS agreement, or a broader software services agreement, the same handful of clauses tend to decide how a dispute plays out years later. The MSA is where liability gets capped or left open, where it's decided who actually owns the code once the invoice is paid, and where a data breach three years from now either stays manageable or becomes existential. This piece works through the provisions that do the most commercial damage when rushed, using Indian statutory and case law as it currently stands rather than boilerplate carried over from other jurisdictions.

What Is the Difference Between an MSA and a Statement of Work?

The MSA sets the durable terms, liability, IP, confidentiality, data protection, termination, that shouldn't be renegotiated every project. The SOW captures what's actually being delivered this time: scope, milestones, pricing, team. Problems show up when the two documents say different things. A well-drafted MSA states plainly that its terms govern unless a SOW expressly and specifically varies a named clause, not just “notwithstanding anything in the MSA.” Vague precedence language is a common source of dispute once a project goes sideways, since both sides can point to language supporting their reading. Courts read documents together and try to give effect to intent, but that's a poor substitute for a precedence clause that actually says what it means. Whether an SOW itself needs to be stamped or registered separately from the MSA is a question worth checking early; our explainer on whether a contract signed but not stamped or registered is still valid covers the general position. Getting this relationship right is the foundation of most IT service contracts in India: a clean precedence clause means neither document ends up fighting the other three years into delivery.

Why Do Technology Contracts Need a Real Change-Control Clause?

Scope creep is rarely one dramatic event. It's a hundred small “can you also just” requests that never go through a change order. The MSA should require any change to scope, timeline, or fees to be recorded in writing and signed by an authorised representative on each side, not approved over Slack by whichever engineer is on the call. Equally important is spelling out customer dependencies, test data, environment access, timely sign-offs, since a vendor's delivery obligations are often conditional on the customer doing its part first. A clause silent on customer-caused delay leaves the vendor absorbing costs it never priced in.

What Should an SLA Agreement in an MSA Actually Cover?

An SLA is only useful if it measures something real and excludes what it should. Uptime percentages, response and resolution tiers by severity, and the service-credit formula all need to be specific enough that neither side is guessing at renewal. Exclusions matter just as much as commitments: scheduled maintenance, force majeure, and delays caused by the customer's own infrastructure should be carved out explicitly. Two things frequently go wrong: vendors commit to SLA numbers during sales that operations never validated, and MSAs rarely address what happens after repeated breaches, an escalating credit, a right to terminate for chronic non-performance, or nothing at all. Service credits are usually structured as a price adjustment rather than damages, which keeps them outside the stricter scrutiny Indian courts apply to sums payable on breach under Section 74 of the Indian Contract Act, 1872. That provision entitles the aggrieved party only to reasonable compensation not exceeding the amount named, and the Supreme Court held in Kailash Nath Associates v. Delhi Development Authority ((2015) 4 SCC 136) that a court won't enforce a stipulated sum mechanically without some link to actual loss. A credit framed as a fee adjustment, not a penalty for breach, sits on firmer ground; the distinction is explored further in our piece on penalty versus liquidated damages clauses.

Consider a vendor promising 99.9% uptime with credits capped at 10% of monthly fees. If the platform is down for 40 hours in a month against a roughly 43-minute allowance, that reads as a clear breach, but if the MSA never defines whether “downtime” includes partial degradation, slow response times, or outages caused by a third-party dependency, the vendor can plausibly argue the metric was never triggered at all. The dispute that follows is rarely about whether the service was bad; it's about what the words in the SLA actually meant, which is exactly the kind of argument a precise definition avoids.

When Is a Deemed Acceptance Clause Actually Enforceable?

Acceptance criteria drafted as “software meets customer's requirements” invite disputes, since requirements evolve and memories differ. Criteria should tie to a defined, written specification, ideally referenced directly in the SOW, with a fixed testing window and a clear procedure for a failed test: is there a cure period, how many attempts, what happens if it still fails. Deemed acceptance clauses, where a deliverable is treated as accepted if the customer doesn't object within a stated period, are common and generally enforceable, but only work fairly if the customer had a realistic opportunity to test. A ten-day window isn't realistic for a complex integration; a rushed clause here tends to get renegotiated in a dispute rather than relied upon.

Take a data-migration project priced at roughly ₹1.2 crore, where the SOW required customer sign-off within ten business days of delivery. The customer's procurement team was largely unavailable for three weeks; the vendor invoked deemed acceptance and invoiced the final milestone. The customer refused to pay, arguing it never had a genuine opportunity to test. Both sides had a plausible reading of the clause, and that is precisely the problem: the SOW never addressed what happens when the customer's own unavailability, rather than the vendor's delay, eats into the testing window.

How Should Fees and Payment Disputes Be Handled in an IT Services Agreement?

Fixed-fee and time-and-material models allocate risk very differently, and the MSA should be explicit about which applies to which SOW, since mixing them without clarity is a common drafting error. Payment terms should address invoicing frequency, the process for disputing an invoice (ideally requiring the customer to pay the undisputed portion while the dispute is resolved), GST treatment, and consequences of late payment, interest, suspension, or both. A vendor that doesn't reserve a right to suspend services for material non-payment, subject to notice, often finds itself delivering to a customer that has stopped paying, with limited recourse beyond litigation.

Two specific gaps recur often enough to call out. First, GST: a customer that withholds the GST component of an invoice pending “internal reconciliation” effectively makes the vendor fund the customer's own compliance delay, since the vendor has typically already accounted for output tax on an accrual basis regardless of when it's actually paid. Fixing the invoice due date independently of the customer's internal approval cycle, and stating that GST is payable alongside the base fee rather than folded into any disputed amount, closes this gap. Second, tax deducted at source: domestic services contracts should flag the customer's obligation to deduct TDS under the Income Tax Act, 1961 before payment, since a vendor that hasn't budgeted for this can be caught off guard by a lower-than-expected receipt and mistake it for a payment shortfall rather than a routine statutory deduction.

Who Owns the Intellectual Property in a Software Contract?

This is where MSAs most often get it wrong, and the mistake is expensive. Indian copyright law does not automatically vest ownership of custom-developed software in the customer just because the customer paid for it. Under Section 17 of the Copyright Act, 1957, the author of a work is ordinarily its first owner. There's a narrow exception under Section 17(b) for certain commissioned works, photographs, paintings, portraits, engravings, and cinematograph films, made for valuable consideration at another's instance, where the commissioner becomes first owner. That list doesn't include literary works, and computer programs are treated as literary works under the Act. A separate exception under Section 17(c) covers works created by an employee in the course of employment, but that doesn't help a customer engaging an outside vendor on a contract for services. In practice, a customer that commissions software from a vendor without an express written assignment may not own the resulting code, regardless of what either side assumed. Sections 18 and 19 require any copyright assignment to be in writing and signed by the assignor, so a verbal understanding or an invoice reference isn't enough. This exact gap is discussed at greater length in our guides on IP ownership in SaaS agreements and source code protection for startups.

A recurring pattern: a startup engages a freelance developer to build its core product for around ₹8 lakh, paid in full, with no written IP clause anywhere, not even a line in the invoice. Two years later, at Series A due diligence, the developer, who remains the copyright owner under Section 17 regardless of having been paid, is in a position to demand a licensing fee or hold up the deal until a retrospective assignment is signed. This is not a rare edge case; unassigned IP in commissioned code is one of the more common reasons technical due diligence stalls a funding round.

A properly drafted IP clause should separately address background IP each party brings and continues to own, newly developed IP created specifically for the customer (with an express, signed assignment or an appropriately scoped licence, depending on the commercial deal), customer-supplied materials and data, and third-party or open-source components, including a warranty that their use doesn't infringe third-party rights and disclosure of any copyleft licensing terms that could affect the customer's freedom to use the deliverable.

How Should Confidentiality Be Protected in a SaaS Agreement?

Confidentiality clauses in a SaaS agreement or any IT services MSA typically cover source code, business processes, customer data, and commercial terms, and should specify the standard of care (no lower than the receiving party applies to its own confidential information, never less than reasonable care), carve-outs for information independently developed, publicly available, or legally required to be disclosed, and survival after termination, commonly for a fixed period, or indefinitely for trade secrets.

A gap that shows up often in practice: the clause restrains the vendor as a legal entity but says nothing about the individuals actually handling the information. Consider a senior engineer who leaves a vendor to join a competing product team, taking internal architecture notes and client-specific customisation details along with them. If the MSA's confidentiality clause doesn't separately require the vendor to bind its own employees and any subcontractors to equivalent obligations, and doesn't fix survival to a defined period after termination rather than tying it to the life of the underlying SOW, the customer can find that by the time the misuse actually surfaces, the practical window for doing anything about it has narrowed considerably.

Where confidentiality is breached, damages alone are often inadequate since the harm, competitive disadvantage, lost trust, is hard to quantify; an express right to seek injunctive relief, available under the Specific Relief Act, 1963, is worth including rather than assumed. It's also worth keeping confidentiality analytically separate from data protection in the drafting: confidentiality protects information as a commercial secret, while data protection obligations, covered next, apply specifically to personal data regardless of whether that data happens to be confidential. An MSA that treats the two as interchangeable, using one clause to do both jobs, tends to underprotect whichever one wasn't actually top of mind when the clause was drafted.

What Data Protection Obligations Apply to Technology Contracts in India?

This section needs particular care because India's data protection framework is mid-transition. The Digital Personal Data Protection Act, 2023 received presidential assent in August 2023, but most of its substantive obligations aren't yet operative. A notification dated 13 November 2025 brought into force the definitional provisions and the sections establishing the Data Protection Board of India, along with the Digital Personal Data Protection Rules, 2025, but only in a limited, staggered way. Consent Manager provisions are scheduled for around November 2026, and the bulk of the substantive obligations on data fiduciaries, notice, consent architecture, data principal rights, breach notification, cross-border transfer conditions, aren't scheduled until 13 May 2027. Until then, the existing regime under Section 43A of the Information Technology Act, 2000 and the SPDI Rules, 2011 continues to apply, requiring reasonable security practices for sensitive personal data, with civil liability for negligence causing wrongful loss. Our complete guide to the DPDP Act, 2023 covers the framework in more depth.

Since MSAs typically run for years, drafting data protection clauses purely for the current SPDI regime is short-sighted. It's worth building in obligations that anticipate DPDP compliance, purpose limitation, data minimisation, breach notification timelines, and return or deletion of personal data on termination, even before those specific obligations become independently enforceable. Where the arrangement involves an international customer, the clause should also separately address that customer's own regulatory regime (GDPR, for instance), since Indian law compliance doesn't automatically satisfy foreign obligations.

What Representations, Warranties and Indemnities Should an MSA Include?

Standard representations cover authority to contract, non-infringement of third-party IP, compliance with applicable law, and, where relevant, that the vendor's personnel have no conflicting obligations. It's worth keeping representations and warranties conceptually distinct when drafting, even though Indian courts often treat them together as contractual promises: a representation is typically a statement of fact intended to induce the other party into the contract, while a warranty is a promise about performance. Getting this distinction right matters because the remedy for a false representation can, depending on the facts, extend beyond ordinary damages to a claim that the contract itself was induced by misrepresentation, whereas a breached warranty usually just sounds in damages under the agreement's own terms.

Consider an MSA representation that the vendor's software “does not infringe any third-party intellectual property rights.” If the customer later discovers, mid-engagement, that a component was in fact built on code licensed under terms the vendor never disclosed, the representation has been breached regardless of the vendor's good faith. Whether the customer's remedy is limited to whatever the indemnity clause provides, extends to termination for material breach, or opens up a broader claim, depends entirely on how the representations are cross-referenced to remedies elsewhere in the MSA. A related point worth negotiating explicitly, and rarely addressed in Indian technology contracts, is whether the customer loses its right to claim on a representation it already knew, before signing, was inaccurate; leaving this silent invites argument rather than resolving it in advance.

Indemnities typically address third-party IP infringement claims, breach of confidentiality, and data or security incidents caused by the indemnifying party's own default. The details matter more than the headline categories: does the indemnity require prompt notice and let the indemnifying party control the defence, is it mutual or one-sided, and does it carve out situations where the customer modified the deliverable or combined it with something that caused the infringement. An IP indemnity that doesn't exclude customer-caused infringement effectively makes the vendor an insurer against the customer's own conduct. Our piece on indemnity clauses looks at how a single poorly scoped line can turn into disproportionate exposure.

A vendor that signs an indemnity covering “any and all claims arising from the services,” with no cap and no carve-out for customer misuse, is exposed further than the deal probably justifies. If the customer later integrates the vendor's API with a third-party system in a way the vendor never anticipated or approved, and that integration causes a data leak, the vendor can end up defending and paying for a claim arising from a decision it had no part in and no visibility into. An indemnity this broad effectively insures the customer's own choices, not just the vendor's conduct.

How Should Limitation of Liability Be Drafted in IT Contracts?

Getting limitation of liability right in IT contracts deserves real negotiation, not a number copied from the last deal. A common structure caps aggregate liability at a multiple of fees paid in the preceding twelve months, with carve-outs, provisions typically excluded from the cap, for breach of confidentiality, IP infringement, gross negligence or wilful misconduct, and increasingly, data breaches involving personal data. Whether an unlimited liability commitment is appropriate depends heavily on contract value: a five-person development shop signing a ₹15 lakh annual SOW with an uncapped liability clause is theoretically exposed to a multi-crore claim if the customer's downstream business is disrupted, an exposure entirely disproportionate to the deal size and, in most cases, to the vendor's own insurance cover. This is one of the most common mistakes smaller vendors make under pressure from a larger counterparty who simply hands over its standard paper. Exclusions for indirect and consequential damages are standard, but their effectiveness depends on precise drafting; Indian courts interpret exclusion clauses narrowly against the party relying on them, so a bare “no consequential damages” clause leaves room for argument about what counts as direct loss. As discussed under SLAs, any liquidated sums here remain subject to the reasonable-compensation standard under Section 74 rather than being automatically enforceable at face value.

Who Is Responsible When a Cloud Provider or Subcontractor Fails?

Most IT services sit on top of cloud infrastructure, APIs, and other third-party components the vendor doesn't control, and this is one of the more thinly drafted areas in practice. The MSA should state whether subcontracting requires prior consent, and whether that consent can be blanket for named subcontractors or must be sought engagement by engagement, confirm the vendor remains fully responsible for subcontractor performance and confidentiality compliance as if it had performed the work itself, and require the vendor to flow down equivalent confidentiality and data-protection obligations to every subcontractor with data access.

A second, frequently missed issue is what happens when a critical dependency, a cloud outage, an API deprecation, a pricing change from a third-party vendor, changes or fails. Consider a SaaS product that depends entirely on a single cloud provider's managed database service. If that service has a regional outage lasting fourteen hours, is the vendor's own SLA breached, even though the root cause sat entirely outside its control? Customers often assume the vendor bears full responsibility regardless of cause; whether that's actually true depends entirely on how the SLA defines “downtime” and whether third-party infrastructure failures are carved out as force majeure or excluded events. Silence on this point tends to be read against whoever least expected the gap, usually the vendor, at the worst possible moment, mid-outage, with a customer citing the SLA. A well-drafted clause also addresses what happens if a subcontractor's own terms change materially, a cloud provider raising prices or deprecating an API the product depends on, including whether the vendor can pass through the increased cost or has to absorb it.

What Should a Termination and Exit Management Clause Cover?

Termination rights should cover termination for convenience (with a defined notice period, commonly 30 to 90 days for enterprise engagements), for material breach (with a cure period, typically 15 to 30 days), and for insolvency or prolonged force majeure. Exit management is where MSAs are most often thin, and the gap is rarely visible until the relationship is actually ending and neither side is in a cooperative mood.

Specific questions worth answering in the clause itself: what transition assistance does the vendor owe, for how long, and at what cost (free for the first 30 days, then billed at standard rates, is a common structure); does termination accelerate any remaining fees, or does the customer only pay for work actually delivered; do any licences granted during the term survive or continue briefly to allow migration to a replacement system; and, critically, what is the vendor's obligation to return or securely delete customer data, and within what timeframe, 30 days with written confirmation of deletion is typical.

Consider a customer that terminates a five-year MSA for convenience with 30 days' notice, only to discover the contract says nothing about transition assistance. The vendor is under no obligation to help extract data in a usable format, walk the incoming team through the system architecture, or keep the environment live during migration. The customer is technically free to terminate but practically locked in, precisely the outcome a termination right is meant to prevent. Silence on data return and deletion compounds the problem: the customer's data protection exposure stays open indefinitely, which becomes a live issue once DPDP obligations are fully in force and a data principal asks where their data went, a question the customer, not the former vendor, will have to answer.

What Are the Most Common MSA Mistakes Technology Companies Make?

•        Accepting unlimited liability without weighing it against the actual value of the contract, a single claim can then exceed years of the relationship's total revenue.

•        Leaving source code and developed IP ownership unclear, or assuming payment alone transfers copyright, under Indian law it doesn't, and the gap tends to surface only during a funding round or acquisition, when it's hardest and most expensive to fix.

•        Using vague, subjective acceptance criteria instead of a defined written specification, “meets requirements” invites both sides to remember the requirements differently once money is on the line.

•        Allowing the MSA and SOW to contain conflicting terms with no clear precedence clause, this turns an ordinary scope dispute into a contract-interpretation dispute, doubling the legal cost of resolving it.

•        Committing to SLA numbers in the sales process that engineering hasn't actually validated, the gap between what was promised and what's achievable becomes the customer's problem only after the contract is signed.

•        Granting indemnities that are uncapped or broader than the risk actually being taken on, this can quietly convert a services engagement into open ended insurance for the customer's own decisions.

•        Skipping a real change-control process, so scope changes happen informally and go unbilled, the vendor ends up delivering far more than it priced, with no paper trail to point to afterward.

•        Ignoring third-party and cloud dependencies when allocating responsibility for downtime or failures, silence here is usually read against the vendor exactly when a major outage makes the stakes highest.

•        Leaving termination and data exit provisions thin, with no clear timeline for transition assistance or data deletion, this leaves both parties negotiating exit terms for the first time under the worst possible conditions, after the relationship has already broken down.

FAQ

Q: Does paying a vendor automatically give us ownership of the software they build for us?

No. Under Section 17 of the Copyright Act, 1957, the author (the vendor or its developers) is the default first owner unless there is an express written assignment. Payment alone does not transfer copyright.

Q: Is the Digital Personal Data Protection Act, 2023 currently enforceable against IT service providers?

Only partially. The provisions establishing the Data Protection Board and certain definitions are in force, but most substantive obligations on data fiduciaries are scheduled to come into force by 13 May 2027. The existing regime under Section 43A of the IT Act, 2000 and the SPDI Rules, 2011 remains operative in the meantime.

Q: Can an MSA cap liability at zero or exclude all liability?

Parties can negotiate liability caps, but a clause that tries to exclude liability entirely for matters like gross negligence, wilful misconduct, or statutory obligations is unlikely to be treated as enforceable in the way the drafter intended, and courts scrutinise such exclusions narrowly.

Q: Are service credits under an SLA treated as a penalty under Indian law?

Generally not, if they are structured as a price adjustment rather than a sum payable on breach. If a clause functions as damages for breach, it falls within Section 74 of the Indian Contract Act, 1872, which limits recovery to reasonable compensation regardless of the figure named.

Q: Does the MSA or the SOW take priority if they conflict?

It depends entirely on what the contract says. Without an explicit precedence clause naming which document governs and for which categories of terms, this becomes a matter of contractual interpretation and a common source of disputes.

Q: Is a deemed acceptance clause enforceable if the customer never actually tested the deliverable?

Deemed acceptance clauses are generally enforceable, but their fairness depends on whether the customer had a genuinely adequate opportunity to test within the stated window. An unrealistically short window is more likely to be challenged.

Related Blogs

1.      https://solvlegal.com/blogs/ip-ownership-saas-agreements-guide

2.      https://solvlegal.com/blogs/source-code-protection-for-startups-why-even-non-unique-business-ideas-need-strong-ip-clauses

3.      https://solvlegal.com/blogs/indemnity-clauses-explained-why-one-line-in-your-contract-can-cost-you-crores

4.      https://solvlegal.com/blogs/penalty-vs-liquidated-damages-clauses-what-is-enforceable-in-contracts-globally

5.      https://solvlegal.com/blogs/dpdp-act-2023-complete-guide-for-businesses-india

6.      https://solvlegal.com/blogs/contract-signed-not-stamped-or-registered-validity

Conclusion

Strip away the legal language and an MSA is doing three jobs at once: deciding who owns what gets built, who pays when something goes wrong, and what happens when the relationship ends. Most of the commercial pain technology companies experience later, a customer claiming ownership of code nobody assigned in writing, an SLA breach with no consequence, a termination with no plan for data return, traces back to one of these three questions being left vague at signing.

None of this requires exotic drafting. It requires treating the MSA as a live commercial document, reviewed clause by clause against the actual deal on the table, rather than a template to sign quickly so the “real” SOW negotiation can start.

About Author

This blog was written by Yashvardhan, a lawyer with experience in technology, IP, and data privacy law, including cross-border and UK-adjacent matters. He works closely with corporate and technology-driven legal frameworks, with particular focus on data protection, commercial documentation, and contract drafting for technology transactions.

Disclaimer

This article is intended solely for general informational and educational purposes and does not constitute legal advice. Contractual outcomes depend on the specific wording used, the facts of each transaction, and how a particular clause interacts with the rest of the agreement. Independent legal advice should be obtained before finalising or signing an MSA.