MSA Drafting for Technology Companies: Critical Clauses to Include

By LegalInk Editorial ·

MSA Drafting for Technology Companies: Critical Clauses to Include

A master services agreement between a technology vendor and its customer is not a formality. It determines who owns what was built, who bears the cost when things go wrong, and whether either party can exit cleanly when the relationship deteriorates. Yet in practice, many MSAs in technology engagements are either borrowed from US-origin templates without India-specific adaptation, or drafted too loosely to be enforceable on the points that actually matter. This guide is written for corporate counsel — in-house or external — advising technology companies or their enterprise customers. It addresses the five clause families where imprecision creates the most litigation risk: IP ownership, indemnity, limitation of liability, data protection under the Digital Personal Data Protection Act 2023, and termination rights.

IP Ownership and Background vs. Foreground IP

This is the single clause family most frequently litigated in technology service disputes, and the one most often drafted without adequate precision.

Background IP

Background IP refers to pre-existing intellectual property that a party brings into the engagement — the vendor's proprietary frameworks, libraries, methodologies, and tools developed independently before the contract began. The MSA must define this clearly, because in the absence of explicit language a customer who has paid for a deliverable may assert ownership over components the vendor considers core to its business.

The correct approach is a schedule-based carve-out: list or describe categories of vendor background IP at execution, and include an express statement that the customer receives only a limited, non-exclusive licence to use background IP solely to the extent embedded in the deliverables. The vendor retains all ownership. Symmetrically, customer background IP — existing data structures, proprietary algorithms, business logic — should be subject to an equivalent carve-out, with the vendor receiving only the licence needed to perform the services.

A practical example: a vendor building a custom analytics dashboard for a banking customer will typically rely on its own ETL framework, a charting library it has refined across engagements, and a proprietary data normalisation engine. If the MSA grants the customer "all rights in the deliverables", the vendor has either lost ownership of its core toolkit or set up a dispute the next time it deploys that toolkit elsewhere. Schedule 1 should list each such component by name with a one-line description, and the operative clause should refer back to that schedule.

Foreground IP (Work Product)

Foreground IP is what gets built during the engagement. The default position under Indian law is more nuanced than many practitioners assume. Under Section 17 of the Copyright Act 1957, work done in the course of an author's employment vests in the employer — but the vendor's employees are employed by the vendor, not the customer. Absent a written assignment, a customer paying substantial fees for bespoke software development has, at best, an implied licence rather than ownership.

If the customer requires ownership of foreground IP — source code, custom models, documentation, databases — the MSA must contain an explicit, present-tense assignment: "Vendor hereby assigns to Customer all right, title, and interest in and to the Work Product." Future-tense language ("shall assign") creates an obligation to assign rather than an assignment itself, and is weaker in enforcement. Pair the assignment with a further-assurances clause requiring the vendor to execute any document and procure any waiver of moral rights from individual authors that may be necessary to perfect title.

Where the vendor is unwilling to assign outright — which is common when deliverables incorporate background IP — a tiered structure works better: the customer owns the bespoke layer; the vendor retains the underlying framework; the customer gets a perpetual, irrevocable, worldwide licence to the combined output for its internal business purposes. Map this clearly. A vague "customer shall own all deliverables" clause combined with heavy background IP reliance is a conflict waiting to happen.

Open-Source Disclosure

Technology engagements routinely involve open-source components. The MSA should require the vendor to disclose all open-source licences used in deliverables before or at delivery, typically through a Software Bill of Materials. Copyleft licences — GPL variants in particular — can affect the customer's ability to commercialise the product. This is not hypothetical risk; it is a standard due diligence item in any technology M&A that frequently surfaces undisclosed GPL dependencies. Build the disclosure obligation into the MSA, with a representation that no open-source component has been incorporated in a manner that would require the customer to open-source its proprietary code, and an indemnity tied specifically to breach of that representation.

Indemnity: Scope, Carve-Outs, and Procedure

What the Indemnity Should Cover

In vendor MSA drafting under Indian law, IP indemnity and data breach indemnity are the two most commercially significant heads. IP indemnity protects the customer against third-party claims that the vendor's deliverables infringe existing IP rights — patents, copyrights, trademarks. Data breach indemnity covers losses arising from the vendor's failure to maintain data security obligations, including regulatory penalties under the DPDP Act and third-party claims by affected Data Principals.

A well-drafted IP indemnity includes the standard remedy ladder: the vendor may, at its option, procure the right to continue using the infringing component, replace or modify it to make it non-infringing, or — failing both — accept termination of the affected SOW and refund the fees paid for the affected deliverable on a depreciated basis. Without this ladder, the vendor's exposure on an IP indemnity is theoretically unlimited, which creates negotiation deadlock at the table.

Carve-Outs the Vendor Should Insist On

The vendor should not indemnify for infringement caused by: the customer's modification of the deliverables; use of the deliverables in combination with third-party products not specified in the SOW; the vendor's compliance with customer-supplied specifications where the infringement results from that specification; or use in a manner not authorised under the MSA. These carve-outs are standard and reasonable — they exclude vendor liability for risks the vendor cannot control or foresee.

Indemnification Procedure

The procedure clause is often left as boilerplate, which is a mistake. It should require prompt written notice of the claim (with a consequence for late notice only to the extent the delay actually prejudiced the indemnifying party); the indemnifying party's right to assume sole control of the defence and settlement, subject to the indemnified party's right to be represented at its own cost; the indemnified party's obligation to cooperate, preserve evidence, and not settle or admit liability without consent; and a clear allocation of who controls publicity around the dispute. An indemnity without a procedure clause is enforceable in principle but chaotic in practice — particularly where regulatory disclosure timelines run in parallel with the dispute.

Limitation of Liability: Getting the Numbers and Exclusions Right

The Cap

Limitation of liability is the clause both parties' counsel fight hardest over, and for good reason. The standard formulation caps aggregate liability at fees paid in the twelve months preceding the claim. For a multi-year, high-value engagement, this may be grossly inadequate from the customer's perspective. Worse, in the first year of an engagement the customer's "trailing twelve months" cap may be a fraction of the actual exposure. Negotiate the cap by reference to the specific risk profile: a vendor managing the customer's core transaction processing carries a different risk than one building a marketing microsite.

Consider a tiered cap: a higher aggregate limit — often a multiple of annual fees, or a fixed rupee figure tied to insurance coverage — for data breach and IP indemnity, which represent the most foreseeable, high-consequence risks; and a lower cap for other claims. This structure gives the customer meaningful protection where it matters while keeping vendor exposure manageable on routine performance failures. Always confirm that the vendor's cyber and professional indemnity insurance actually responds at the level the contractual cap implies — a contractual cap higher than the insurance limit shifts genuine balance-sheet risk to the vendor.

Consequential Loss Exclusion

The mutual exclusion of indirect, consequential, incidental, and punitive damages is standard in MSA clauses. However, carve-outs to this exclusion are increasingly important in technology contracts. The exclusion should not apply to a party's breach of confidentiality; a party's fraud or wilful misconduct; indemnity obligations; and — critically now — a vendor's breach of data protection obligations. Without these carve-outs, the consequential loss exclusion can effectively immunise a vendor for a catastrophic data breach, since the customer's primary loss (regulatory penalties, customer churn, reputational harm) is almost entirely consequential in nature.

Under Indian contract law, Section 73 of the Indian Contract Act 1872 governs damages for breach — compensation is available for losses arising naturally from the breach or which the parties knew, at the time of contracting, to be likely. The limitation of liability clause overrides this statutory baseline by agreement, which is why the carve-outs matter: they define the floor below which the contractual cap cannot go. Be alert also to Section 74 implications where the MSA includes liquidated damages for SLA failure — the cap should clarify whether SLA credits count against the aggregate liability cap or sit outside it.

DPDP Act Compliance: What the MSA Must Now Address

The Digital Personal Data Protection Act 2023 fundamentally changes the data protection obligations that technology vendor MSAs must reflect. Rules under the Act are still being finalised, but the statutory framework is in force. Corporate counsel must begin incorporating DPDP-compliant language now rather than retrofit it under time pressure when the rules are notified.

Data Fiduciary and Data Processor Roles

The DPDP Act uses the terms "Data Fiduciary" (the entity that determines the purpose and means of processing personal data) and "Data Processor" (the entity that processes on behalf of the Fiduciary). In a typical technology vendor engagement, the customer is likely the Data Fiduciary and the vendor is the Data Processor. This has direct MSA implications: liability under the Act rests primarily with the Fiduciary, but the Fiduciary's ability to control vendor behaviour comes entirely from the contract.

Section 8 of the DPDP Act imposes obligations on the Data Fiduciary, including ensuring that the Data Processor processes data only for the purposes and in the manner specified by the Fiduciary. The MSA should contain a data processing annex specifying categories of personal data processed; purpose and duration of processing; the vendor's obligation to process only on documented instructions; technical and organisational security measures (encryption standards, access controls, logging, vulnerability management); sub-processor restrictions and prior-notice or approval requirements; breach notification obligations (Section 8(6) requires the Fiduciary to notify the Data Protection Board and affected Data Principals in the prescribed form, which means the vendor must notify the customer fast enough for the customer to comply); audit and inspection rights; and data deletion or return obligations at contract end.

If the vendor's services involve any processing of personal data of the customer's end-users or employees, the MSA should address the lawful basis for processing under Section 4 of the DPDP Act. In most B2B technology arrangements, consent or legitimate use under Section 7 will be the operative basis — but the MSA should clarify which party is responsible for obtaining and maintaining consent records, providing notice to Data Principals, and handling rights requests (correction, erasure, grievance redressal). The contract should indemnify each party against failures attributable to the other in performing these allocated obligations.

Cross-Border Data Transfers

Section 16 of the DPDP Act permits the Central Government to restrict transfer of personal data to notified countries. Until the list of restricted countries is published, counsel should include a clause that automatically incorporates compliance with any transfer restrictions notified under Section 16, requires the vendor to maintain a current inventory of processing locations and sub-processor jurisdictions, and obliges the vendor to notify the customer immediately if any proposed change in location would trigger a restriction. Where the vendor uses hyperscale cloud infrastructure, the MSA should require disclosure of the specific cloud regions used for storage and processing.

Use the LegalInk compliance framework for technology to track the status of DPDP rules and populate your MSA data processing annex with current, regulation-aligned language.

Termination: Rights, Consequences, and Transition

Termination for Cause

The MSA should specify the events that constitute a material breach entitling the non-breaching party to terminate — and the cure period before termination takes effect. Thirty days is standard for most breaches. For data security incidents, the cure period should be shorter or the right to terminate should be immediate upon specified trigger events: a confirmed breach of personal data affecting more than a threshold number of Data Principals, repeat security incidents within a defined window, or a regulatory order against the vendor.

Include specific termination triggers for the vendor — non-payment beyond a defined grace period, customer-caused obstruction of service delivery — and for the customer: persistent SLA failure (typically defined as a stated number of breaches in a rolling period); vendor insolvency or initiation of corporate insolvency resolution under the IBC; assignment or change of control without consent; breach of confidentiality; and unremediated breach of the vendor's DPDP Act obligations.

Termination for Convenience

Many enterprise customers insist on termination for convenience. Vendors should negotiate a minimum notice period (typically 30–90 days, longer for managed services with significant ramp-up cost); a payment obligation for work performed and non-cancellable commitments incurred up to the termination date; and — where the vendor has made upfront investments in custom infrastructure or hiring — a fair wind-down payment calibrated to the unrecovered investment. Without these protections, termination for convenience provisions can be used as leverage in commercial renegotiations rather than as a genuine exit right.

Transition and Exit Assistance

The termination clause should be paired with a transition assistance obligation. On termination or expiry, the vendor must continue providing services for a defined transition period (typically 90–180 days) at the same fee, or at a pre-agreed transition rate; provide all customer data in a portable, machine-readable format with documented schemas; deliver documentation sufficient for an incoming vendor to understand the system; and cooperate reasonably with any replacement vendor, including knowledge transfer sessions. Data portability at exit is not merely commercial — it aligns with the DPDP Act framework, which recognises the right of Data Principals to access their data and limits a Fiduciary's ability to retain data beyond the purpose for which it was collected.

The LegalInk MSA drafting assistant covers all five of these clause families with India-specific defaults, including a DPDP-compliant data processing annex, tiered limitation of liability structures, and IP ownership schedules. The contract review checklist can be used in parallel to stress-test a counterparty's draft against the same framework.

Why This Matters

MSA drafting for technology companies is commercial risk allocation in writing, and gaps in these five clause families have a consistent track record of producing disputes that are expensive to litigate and difficult to settle. The increasing enforcement posture around data protection under the DPDP Act adds a regulatory dimension that makes precise drafting even more consequential — a poorly drafted data processing annex now creates not only contractual exposure but also direct statutory liability for the customer as Data Fiduciary. Counsel advising either side of a technology services relationship should treat the MSA as a living document, reviewed against each new engagement and updated as the regulatory baseline shifts. For a structured starting point that reflects current Indian law and the DPDP Act framework, visit legalink.co.in.

Related posts

← Back to all posts