How to Write an MSA for an Indian IT Outsourcing Partner

Adapt the MSA to the Indian vendor and actual delivery model#

Start with the entities, people and assets involved in the engagement. The contract needs to explain who performs the work, which rights the client receives and how delivery, payment or exit disputes will be handled.

1) IP ownership under Indian default law#

Under Section 17 of India's Copyright Act, the author is the first owner of copyright unless an exception applies or the contract says otherwise. The employment exception refers to work created under a contract of service, so do not assume a vendor relationship gives you automatic ownership.

That is where generic templates break down. Broad work-for-hire wording, or language that assumes payment alone transfers rights, may not be enough without explicit assignment language. The practical risk is simple: you pay, ship, and still end up arguing over code, documentation, models, or integrations at handover or exit.

2) Disputes and enforcement in the real world#

Foreign judgments can be conclusive in India under CPC Section 13, but only subject to statutory exceptions. Direct execution under Section 44A depends on whether the country is a reciprocating territory notified by India's Central Government. The Section 44A decree route also excludes arbitral awards.

That makes a generic "home court only" clause weaker than it looks. The risk is not losing on paper. It is winning on paper and then fighting again to enforce. Cross-border arbitration can be a practical option because New York Convention awards are recognized and enforced through local procedure. India's arbitration statute also includes a New York Convention enforcement chapter. Pick a neutral seat and rules based on enforceability, not habit.

3) Scope certainty under Indian contract law#

Section 29 addresses agreements whose meaning is neither certain nor capable of being made certain. A broad phrase does not automatically void an MSA, but measurable outputs, dependencies and acceptance tests reduce uncertainty about the promised performance.

This is another place where standard templates usually underperform. Phrases like "industry standard," "timely," or "as requested" do not give you objective specs, milestones, dependencies, acceptance tests, or change control. The result is predictable. You get scope creep, acceptance disputes, and weaker breach arguments because the expected outcome was never pinned down.

4) Data protection across India and your home-law duties#

The DPDP Act’s Section 3 addresses processing in India and certain processing abroad connected with offering goods or services to individuals in India. Under the November 13, 2025 commencement notification, Section 3 and most substantive processing duties start eighteen months later, on May 13, 2027. As of October 2026, do not describe that future tranche as fully in force. Map current privacy duties separately and plan for the scheduled change.

Record data categories, access locations, controller and processor responsibilities, subprocessors, security measures and incident procedures. Confirm the currently applicable Indian and home-jurisdiction rules, then allocate implementation work for future DPDP duties. A general applicable-law clause does not tell either team how to handle an incident.

Fix these clauses before you negotiate price:

• Add explicit IP assignment mechanics in the MSA and each SOW, tied to deliverable categories and handover.
• Redesign dispute language around enforceability you can verify, not assumptions.
• Define measurable outputs, acceptance criteria, dependencies and written change approvals.
• Add a data schedule covering India exposure, home-law exposure, subprocessors, incident notice, and deletion or return at exit.

For a step-by-step walkthrough, see A Guide to TDS (Tax Deducted at Source) for Payments to Indian Freelancers.

Before You Sign: Ownership, Payment Release, and Confidentiality#

Before you sign, get three controls in writing: party ownership and obligations, payment release mechanics, and confidentiality handling. If any of them stays vague, the MSA starts acting like a pricing sheet instead of a risk-control document.

Step 1. Name the owner and the paper trail#

The first checkpoint is basic but often missed. Confirm which legal entity is actually bound at each contract level. The MSA sets the framework, but work is often placed through a Service Agreement. Subsidiaries are not automatically bound unless they expressly join.

Local service agreements may be modified for local law or commercial custom, so do not assume obligations carry over unchanged.

Verify: the entity doing the work is the same Contracting Party, or the Service Agreement expressly binds the delivery entity. Red flag: a parent signs, an affiliate delivers, and the affiliate never accepts the key obligations.

Step 2. Define the billing model and invoice triggers#

Keep payment release mechanics explicit in each Service Agreement. Treat acceptance language as something you confirm in your own template and legal review. For scope and prioritization changes, require written updates before they flow into billing.

Require a written change record identifying the affected scope, fee, priority and delivery date. Agree the acceptance review window in the signed SOW.

Verify: every billed change can be tied to the written scope or prioritization process in the Service Agreement. Red flag: billing references "requested changes" or "priority shifts" with no signed written record.

Step 3. Build confidentiality as data and access control#

Define confidential information, permitted use, authorized recipients and handling duties during delivery and after exit. Reference any existing NDA consistently.

Make the operating limits explicit:

• Use only for performing services under the MSA and applicable Service Agreement.
• Need-to-know access controls.
• Written obligations for employees and any subcontractors that receive access.
• Return or secure deletion process for information, copies, credentials, and access tokens at exit.

Agree a specific incident-notice process and a return or deletion process before signature. Identify any legally required retention and who can access those retained records.

Verify: identify the people, repositories, cloud environments, and subcontractors that will handle your information before signing. Red flag: shared accounts, unnamed subcontractors, or no return or deletion duty at exit.

Make service levels measurable and remedies explicit#

Once ownership and payment are under control, performance has to be enforceable too. Your SLA should do four jobs: define done, define measurement, define communication rules, and define remedies when performance misses.

Step 1. Define done inside each SOW#

Put scope, acceptance tests, review procedure, timing and fees in each SOW. U.S. federal procurement acceptance rules can illustrate a process but do not govern an ordinary private Indian outsourcing contract. Define the procedure the parties actually agree to use.

For a failed acceptance test, agree the rework obligation and resubmission deadline. State whether silence has any acceptance consequence, how notice is delivered and what exceptions apply. Keep that mechanism consistent with the MSA.

The vendor submits the evidence, the named client reviewer applies the agreed tests and both sides record acceptance or specific failures. State which milestones affect invoicing, warranty or support; advance and time-and-materials invoices may use other agreed triggers.

Verify: every deliverable has a named approver, evidence requirement, and written accept-or-reject path. Red flag: "industry standard," "high quality," or "best efforts" with no objective test.

Step 2. Measure only the commitments you can verify#

SLA packs often fail because they measure too much and prove too little. Track a small set of commitments that affect continuity, delivery reliability, and intervention speed. Then tie each one to evidence you can review independently.

Agree the target, exclusions, measurement method and remedy for every service level before signing. A target without a clock definition or evidence source leaves both teams arguing over whether it was missed.

Step 3. Lock in cross-border communication and escalation#

Informal updates are not enough in a cross-border delivery model. Put the operating controls in the contract text:

• Named channels for routine work and incidents
• Severity matrix
• Primary and backup contacts
• Escalation ladder

For time-zone handoffs, require an end-of-day written update for open critical items. It should cover current status, last action, next owner, blocker, and the next expected update window.

For work supplied to a regulated Indian financial entity, check the current RBI directions that apply to that entity and outsourcing arrangement. Its sector-specific monitoring, security and outsourcing duties are additional contract inputs; they are not universal requirements for all IT buyers.

Verify: run a mock escalation before signing using real contacts and channels. Red flag: one chat group, one project manager, and no backup incident path.

Step 4. Separate credits, cure periods, and termination triggers#

Do not let service credits swallow every other remedy. Credits are useful for measurable misses, but some templates make them the sole and exclusive remedy unless you preserve other rights. If you need payment protection, termination rights, or other claims, say so directly.

Define the cure notice, recipients, start event and period for each breach category. Choose the period for the service risk and agreed remedy, then connect uncured or repeated failures to termination rights. No single ten-day cure period applies to all private outsourcing contracts.

Use penalty language carefully. Under Section 74 of the Indian Contract Act, recovery tied to a named amount is framed as reasonable compensation up to that amount, not automatic penalty payout. The stronger structure is usually this: credits for measurable service misses, rework for failed deliverables, cure notice for nonperformance, and termination for uncured or repeated breach.

Define who claims a service credit, what evidence is required and whether it is automatic or notice-based. A 30-day claim window is a possible negotiated term; use the window in the signed SLA rather than importing one from another vendor’s policy.

Plan termination, handover and disputes before you need them#

A workable exit clause should do three things: let you exit, require an orderly handover, and make disputes more predictable. Here, termination and dispute terms are not boilerplate. They are control points.

Step 1. Write an exit clause you can actually use#

The clause should answer these points in plain language:

• Termination for convenience: say whether it applies to the MSA, a single SOW, or both, and what notice is required.
• Termination for cause: define the trigger events and whether a cure chance applies.
• Cure process: state who sends notice, what the notice must include, where it must be sent, and when the cure clock starts.
• Valid notice method: name the formal notice channel or channels and recipients, and clarify whether routine project email counts.
• Amounts payable at exit: list what survives termination, including accepted work, approved expenses, agreed transition support, and undisputed invoices.

If the vendor resists convenience termination, reduce your exposure somewhere else by shortening the term, narrowing scope, or limiting prepayment. If you cannot tell in one read what you owe when you exit, the clause is still too vague.

Step 2. Turn wind-down into a handover obligation#

Give the handover plan named owners, deliverables and agreed deadlines. Distinguish services included in the existing fees from separately priced transition assistance, and preserve access long enough to complete an authorized transfer.

Also attach an exit inventory so the return obligation is concrete. One practical failure pattern is partial handover: code is delivered, but keys, admin rights, or current runbooks are not.

Step 3. Design dispute terms for predictability, not optimism#

For cross-border disputes, define the mechanics up front: forum, seat, governing law, language, and the interim-relief pathway. If arbitration is selected, state which court can grant urgent relief while arbitration is pending.

Check arbitrability, mandatory law and the intended enforcement countries before finalizing the clause. Define how urgent court relief interacts with arbitration. Confidentiality and disclosure rules should follow the chosen process rather than a generic assumption that every arbitration is private.

We covered this in detail in How an Indemnification Clause in an MSA Can Create Unlimited Liability.

Check the MSA against one real project#

Use your MSA to lock core risk terms once, then run each project through SOW-level details. If IP rights, payment terms, SLAs, dispute handling, and contracting-entity coverage are not explicit, you are still operating on assumptions.

Before your next outsourcing engagement, review your current template against these five control points and flag any clause gaps for legal review. Related: How to Write a Master Service Agreement (MSA) for Long-Term Client Engagements.

Test the signed contract against a delivery dispute, a late payment and an exit. Both teams should be able to identify the owner, evidence and next action in each case.