IT Outsourcing Agreement in India: SLAs, Data and Liability

A Mumbai insurer outsources its policy administration platform to a mid-sized IT vendor on a five-year contract. The transition goes well for eleven months. Then month twelve brings a two-day outage during renewal week, followed by a data migration error that duplicates 14,000 policies. The insurer pulls out the contract and finds a service level table measured in "reasonable endeavours", a liability cap of one month's fees, and no exit obligation at all. The vendor's position is simple: the contract does not require anything more.

IT outsourcing agreements in India are usually drafted when the relationship is optimistic and read only when it is not. By then the leverage has moved: the customer cannot operate without the service, the vendor knows it, and the document decides who bears the cost of the failure. This guide covers the four areas that determine that outcome — service levels, data obligations, liability allocation and exit — and the drafting choices that separate an enforceable agreement from a letter of intent with a price on it.

What an IT outsourcing agreement covers in India

Outsourcing is not a single transaction. It is a transfer of operational responsibility for a defined set of services over time, and the agreement has to describe that responsibility precisely enough that both sides know where it starts and stops. Indian engagements commonly cover infrastructure management, application support and maintenance, helpdesk and end-user support, network operations, security monitoring, payroll and HR processing, and finance and accounting processes.

The structure usually has three layers: a master services agreement containing the legal terms, one or more service schedules containing the service descriptions and service levels, and a pricing schedule containing the rate card and the charging mechanism. Where the engagement is large, a transition schedule and a transformation roadmap sit alongside. Splitting the document this way is not bureaucratic — it lets the service levels be renegotiated annually without reopening the liability and IP provisions.

Defining the service: the schedule that prevents most disputes

An outsourcing dispute is almost always a scope dispute wearing a service level costume. The vendor says the activity was never in scope; the customer says the service cannot function without it. The way to reduce that risk is to write the service description in three passes.

Pass one: the service catalogue

List every service as a discrete item with an identifier, a description of the activity, the output, the hours of coverage, the supported user group and the responsible party. For an application support engagement that means separate lines for incident management, problem management, change management, release management, database administration, monitoring and reporting.

Pass two: the responsibility matrix

For every service, allocate responsibility between customer and vendor across the activities that surround it: design, build, operate, monitor, approve, pay and audit. A RACI table — responsible, accountable, consulted, informed — attached as a schedule resolves more arguments than any amount of narrative drafting. The matrix should also name the customer-side dependencies: access provisioning, change approval, licence procurement and data quality.

Pass three: the exclusions

List what is not included. Third-party application vendors' fees, hardware refresh, new integrations, regulatory remediation projects and out-of-hours coverage beyond the stated window are the usual candidates. An exclusion list is not an admission of weakness; it is the boundary that makes the price meaningful.

Service levels that actually measure something

An SLA in an Indian outsourcing contract typically has four dimensions: availability, performance, resolution and security. Each needs a metric, a measurement method, a reporting cadence, an exclusions list and a consequence.

Severity definitions drive everything

Define severity by business impact and make the definition objective. A four-tier scheme works for most engagements: Severity 1 is a complete loss of a critical service or a confirmed data breach affecting live data; Severity 2 is a material degradation with no workaround; Severity 3 is a degradation with a workaround; Severity 4 is a request or a cosmetic issue. The clock rules should differ by tier — fifteen minutes to acknowledge a Severity 1, four working hours for a Severity 3.

Two clock rules matter more than the targets. First, the clock must not stop because the vendor is waiting for the customer, unless the vendor has escalated in writing through the agreed channel and the customer has failed to respond within its own committed time. Second, planned downtime must be genuinely planned: notified in advance, within an agreed window, and capped per month. A vendor that schedules maintenance during business hours and excludes it from availability is not meeting a 99.9% target; it is defining the target away.

Measurement, reporting and audit

State who measures. The safest position for the customer is that the vendor reports against the SLA monthly, using data from a monitoring tool the customer can access, and the customer may audit the data. The vendor will resist unlimited audit rights; a compromise is one audit per year at the customer's cost, plus audit rights on a security incident or a regulatory request.

Reports should be delivered by a fixed date — the tenth working day of the following month is common — and should show the metric, the target, the actual, the breach days and the credits accrued. A report that only shows a green dashboard is not a report.

Service credits, earn-back and termination for chronic failure

Service credits are the standard remedy for missed service levels: a percentage of the monthly fee is credited back to the customer, scaled to the severity and duration of the breach. They are easy to draft and easy to get wrong.

The first mistake is to make credits the sole and exclusive remedy for all failures. That is fine for ordinary service misses and dangerous for repeated or systemic failures. The clause should say credits are the exclusive remedy for a service level breach, but expressly preserve termination, indemnity and damages for material breach, data breach and wilful misconduct.

The second mistake is to cap credits so low that they do not change behaviour. A cap of 5% of the monthly fee means a vendor facing a two-day outage pays a rounding error. Indian market practice ranges from 5% to 20% of the monthly charge, with a higher cap for Severity 1 incidents. Credits should be calculated automatically, without the customer having to claim them, and should be shown on the next invoice.

The third mistake is to omit the escalation path. Credits address the symptom; chronic failure needs a structural remedy. The agreement should define a chronic failure trigger — for example, three Severity 1 incidents in a quarter or the same SLA missed in three consecutive months — and give the customer a right to require a remediation plan within a stated period. If the plan is not delivered or not effective, the customer should have a termination right without penalty.

Data: ownership, location, security and return

The customer's data is the most valuable asset in most outsourcing arrangements, and Indian contracts routinely leave its treatment to a generic confidentiality clause. That is inadequate for three reasons: confidentiality protects against disclosure, not against loss, misuse or retention; data protection law imposes specific obligations on the parties; and sectoral regulators impose their own outsourcing requirements on banks, insurers and securities intermediaries.

Ownership and licence

State plainly that all customer data, including derivatives such as cleaned datasets, models trained on the data and reports, belongs to the customer. The vendor gets a limited licence to process the data for the purpose of providing the services and for no other purpose. Prohibit the vendor from using customer data to train its own models, benchmark other customers or build products, unless the customer expressly agrees in writing.

Location and cross-border transfer

Name the countries and the facilities where data will be stored and processed, and require prior written consent for any change. Under the Digital Personal Data Protection Act 2023, cross-border transfer is subject to restrictions notified by the central government, and sectoral rules may be stricter. For financial sector customers, the Reserve Bank's outsourcing directions require certain data to be kept within India and impose notification and audit obligations on the regulated entity.

Where the vendor uses sub-processors, list them or require approval before appointment, and make the vendor liable for their acts as if they were its own.

Security, breach notification and return

Set out the security standard by reference to a recognised framework — ISO 27001 certification, the CERT-In directions on cyber incident reporting, or the customer's own policy — and require evidence of compliance at least annually. Breach notification should be measured in hours, not days: the vendor must notify the customer within twenty-four hours of becoming aware, provide a written report within seventy-two hours, and cooperate with the customer's own regulatory notifications.

On termination, the vendor must return the data in a usable format, certify deletion, and retain nothing except what law requires. The return obligation should have a deadline and a format specification, because a data dump in an unusable format is not a return.

Liability: the clause everyone negotiates last

Liability in outsourcing agreements is allocated through three devices: the cap, the exclusions and the indemnities.

The cap is usually expressed as a multiple of annual fees — one times annual fees is vendor-friendly, two to three times is customer-friendly — or as the fees paid in the preceding twelve months. For a five-year deal, a cap of the total contract value is sometimes offered in exchange for a longer term. Whatever the number, the customer should insist that the cap is per claim or per annum rather than an aggregate for the whole term, otherwise a single early breach consumes the entire protection.

The exclusions typically cover indirect and consequential loss, lost profits, lost revenue, loss of goodwill and loss of anticipated savings. Data loss should not be excluded outright; it is the most likely real loss in an outsourcing arrangement, and the customer should negotiate a separate sub-cap for data breach and restoration costs.

The indemnities should cover third-party intellectual property claims arising from the vendor's deliverables, breach of confidentiality, breach of data protection law and regulatory fines attributable to the vendor's failure. Fines are a growing exposure in India: penalties under the DPDP Act 2023 can be substantial, and a vendor that causes a breach should bear the penalty it caused, subject to the cap.

Governance, change control and benchmarking

Outsourcing relationships fail slowly, through accumulated dissatisfaction that nobody escalates. The agreement should build a governance structure that surfaces problems early: an operational review monthly, a service review quarterly and a steering committee twice a year, each with a defined agenda, attendees and decision rights.

Change control should cover both service changes and price changes. Any new service, volume increase beyond an agreed band or technology change should require a written change request with an impact assessment. Price changes should be tied to an index or a benchmarking exercise rather than left to annual negotiation from scratch.

Benchmarking clauses are common in large deals and rare in mid-market Indian contracts. A benchmark gives the customer a right, once a year or at defined milestones, to compare the vendor's pricing and service levels against the market, with a process for adjusting the price if the benchmark shows a material gap. Vendors resist it; customers who expect a five-year relationship should ask for it anyway.

Exit, transition and step-in rights

The exit clause is the most under-drafted part of Indian outsourcing agreements. The vendor has every incentive to make exit expensive, and the customer has no leverage once the service is embedded. Four provisions reduce the risk.

• Transition assistance. A defined obligation to assist the customer or a successor vendor for a period — six to twelve months is typical — at agreed rates, with a named transition manager.
• Asset transfer. Clarity on what the customer owns and what the vendor owns: hardware, licences, tools, documentation, runbooks, configuration and custom scripts. Custom scripts and runbooks are operationally essential and routinely omitted.
• Step-in rights. A right for the customer to take over the service, or appoint a third party, on a defined trigger such as insolvency or a sustained failure, with the vendor obliged to cooperate.
• Exit fees. If there is an exit fee, state it as a formula, not a number to be negotiated at the time. A formula the customer can calculate in advance is a cost of doing business; a number negotiated under duress is a ransom.

Employee transfer deserves separate attention. Indian law has no equivalent of the automatic transfer of undertakings regime. Employees of the vendor do not transfer to the customer or to a successor vendor by operation of law; transfer requires consent and, in practice, fresh offers or a tripartite arrangement with continuity of service preserved. An agreement that assumes automatic transfer will fail at the worst possible moment.

Stamp duty and execution

An IT outsourcing agreement is generally stamped as an agreement not otherwise specifically provided for, at a fixed duty that varies by state. Where the agreement includes a licence of software, a lease of premises or an assignment of intellectual property, additional duty may apply to those components. Confirm the current rate with the sub-registrar or the state e-stamp portal before execution, and stamp each schedule that is separately executed.

Registration is not required for a services agreement. Execution by electronic signature is valid under Section 10A of the Information Technology Act 2000, but obtain board resolutions or partnership authorisations and keep the complete execution set.

Common mistakes in Indian IT outsourcing agreements

• Service levels measured by the vendor's own tool with broad exclusions. The SLA is never breached on paper.
• Credits as the sole remedy for everything. A systemic failure costs the vendor a few percent of one month's fee.
• No chronic failure trigger. The customer can terminate only for a single material breach, which is hard to prove.
• Data ownership left to the confidentiality clause. The vendor's rights over customer data are undefined.
• No sub-processor control. Data ends up in a jurisdiction nobody approved.
• Liability cap aggregate for the whole term. One incident exhausts the protection.
• No exit assistance obligation. The customer cannot leave without rebuilding from scratch.
• Assuming staff transfer automatically. Indian law does not provide for it.
• No governance calendar. Problems surface at renewal, when leverage has moved.

Frequently asked questions

What is a reasonable uptime SLA for an Indian IT outsourcing contract?

For business-critical systems, 99.5% to 99.9% monthly uptime is the usual range. 99.9% allows roughly forty-three minutes of unplanned downtime a month. Higher figures — 99.95% or 99.99% — are offered for high-availability architectures but are meaningful only if the measurement method and the exclusions are tight.

Do not accept an uptime figure without agreeing how it is measured, from where, and what counts as excluded downtime. The definition matters more than the number.

Are service credits enforceable in India?

Yes. Service credits are a contractual pre-estimate of loss and are generally enforceable as liquidated damages under Section 74 of the Indian Contract Act 1872, provided they are a reasonable estimate and not a penalty. Indian courts will reduce a credit regime that is punitive rather than compensatory.

To be enforceable, the credit should be calculable from the metric without discretion, should be capped, and should be expressly stated to be the remedy for service level breaches while preserving other remedies for material breach.

Who owns the data in an IT outsourcing arrangement?

The customer should, and the contract should say so expressly. Under Indian law, data as such is not "owned" in the property sense, but contractual ownership and control rights are enforceable, and the DPDP Act 2023 imposes obligations on the data fiduciary that require it to control how a processor handles personal data.

Make the vendor a processor, prohibit use for its own purposes, and require return and deletion on exit.

What regulatory rules apply to IT outsourcing by banks and insurers in India?

Regulated entities face additional requirements. The Reserve Bank's directions on outsourcing of financial services require board-approved policies, due diligence on service providers, contractual clauses on data confidentiality and security, audit and inspection rights, and the ability to terminate and transition. Insurers face similar requirements from the insurance regulator, and securities intermediaries from the securities board.

Where the customer is a regulated entity, the outsourcing agreement should include the regulator's mandated clauses, including a right for the regulator to inspect the vendor and a right to terminate on regulatory direction.

How long should an IT outsourcing contract run?

Three to five years is the Indian market norm for infrastructure and application support, because the vendor needs time to recover transition costs and the customer needs stability. Longer terms — seven to ten years — are offered in exchange for price reductions and investment commitments, but they lock the customer into a service level regime that may not fit future needs.

Whatever the term, build in a renewal decision point at least six months before expiry and a right to terminate for convenience after the initial term on reasonable notice.

What happens to the vendor's employees when the contract ends?

In India, nothing automatic. There is no statutory transfer of undertakings, so the employees remain with the vendor unless they are redeployed, made redundant in accordance with applicable labour law, or rehired by the customer or a successor on agreed terms.

If continuity is important, negotiate a transition commitment from the vendor — cooperation with offers of employment, preservation of service records and a restriction on poaching for a defined period — and handle the employment terms separately with each individual.

Drafting Support

Our drafting team prepares IT outsourcing agreements for Indian customers and service providers, including service level schedules, responsibility matrices, data processing annexures and exit plans.