Service Level Agreements in India
Your vendor promises 99.9% uptime. Your SLA does not define how uptime is measured. When the system goes down, you discover that the promise was never a commitment. It was a number.
What an SLA Actually Does and Why Most Are Inadequate
A Service Level Agreement defines the performance standards a service provider commits to deliver. It is the operational contract beneath the commercial contract. The MSA says the provider will deliver managed IT services. The SLA says those services will be available 99.95% of the time, incidents will be acknowledged within 15 minutes, and critical issues will be resolved within 4 hours.
Most SLAs fail not because they are missing, but because they are written to look good rather than to work. They contain aspirational commitments without measurement methodology. They promise 99.9% uptime without defining how uptime is calculated, what counts as downtime, and whether planned maintenance is excluded. They list response times without specifying whether the clock starts when the customer logs the ticket or when the provider acknowledges it.
An SLA without precise measurement methodology is a marketing document, not a contract. When a dispute arises — and disputes always arise when critical systems go down — the ambiguity in the SLA becomes the provider\'s escape clause and the customer\'s frustration.
India\'s IT services industry generates over $250 billion in revenue. Every one of those engagements is governed by an SLA. The difference between a well drafted SLA and a template SLA is the difference between a customer with enforceable remedies and a customer with an unenforceable promise.
Types of SLAs: Customer, Internal, and Multi-Level
Customer SLA — Between a service provider and an external customer. This is the most common form. An IT managed services provider commits to the client on uptime, response times, and resolution targets. A SaaS provider commits on platform availability, data backup frequency, and support response. A BPO commits on transaction processing accuracy and turnaround time.
Internal SLA — Between departments within the same organisation. The IT department commits to the finance department on ERP system availability. HR commits to the business on onboarding turnaround. These SLAs lack contractual enforceability in the traditional sense but create accountability frameworks and escalation paths. In large enterprises, internal SLAs are essential for operational governance.
Multi-Level SLA — A layered structure combining corporate level (organisation wide standards), customer level (specific to a customer segment or account), and service level (specific to individual services within the account). This structure is standard in large outsourcing engagements where different services have different criticality and different performance expectations.
The choice of SLA type determines the drafting approach. A customer SLA requires legally enforceable penalty mechanisms. An internal SLA requires governance and escalation frameworks. A multi-level SLA requires hierarchy and conflict resolution between layers.
Key Performance Metrics and Measurement Methodology
Availability (Uptime) — The percentage of time the service is operational within a measurement period. Calculated as: (Total Minutes in Period minus Downtime Minutes) divided by Total Minutes in Period multiplied by 100. The critical detail is what counts as downtime. Planned maintenance should be excluded but only if the customer was given advance notice and the maintenance window was agreed. Partial degradation (service is up but slow) must be classified as downtime or not, depending on its impact.
Response Time — Time between when the customer reports an incident and when the provider acknowledges it. Must be defined by severity level. P1 (Critical — complete service outage): 15 minutes. P2 (High — significant degradation): 1 hour. P3 (Medium — minor impact): 4 hours. P4 (Low — informational): 8 business hours. Specify whether response time runs 24x7 or business hours only.
Resolution Time — Time between incident acknowledgement and service restoration. This is where most SLA disputes arise because "resolution" can mean "root cause fixed" or "workaround applied." Define it. Typically, a workaround that restores service stops the resolution clock, but the root cause must be addressed within a separate timeframe.
Throughput — Transaction volume the system can process per unit time. Critical for BPO, payment processing, and high volume data processing SLAs. Specify under normal load and peak load conditions.
Data Protection Metrics — Under DPDPA 2023, SLAs involving personal data processing must include data breach notification time (within 72 hours), backup frequency, recovery point objective (maximum acceptable data loss measured in time), and recovery time objective (maximum acceptable time to restore service after a disaster).
Penalty Mechanisms: Service Credits, Financial Penalties, and Termination
The penalty mechanism is what transforms an SLA from a statement of intent into an enforceable commitment.
Service Credits — The industry standard. For each percentage point below the committed uptime, the customer receives a credit against the next invoice. For example: 99.9% committed, actual 99.5% delivered = 0.4% shortfall = 2% service credit on monthly fees. Credits are typically capped at 10% to 30% of monthly fees. The provider\'s financial exposure is limited but the incentive to perform is real.
Earnback Provisions — The provider can "earn back" service credits by exceeding SLA targets in subsequent periods. This incentivises sustained high performance rather than just meeting minimums. Earnback should not exceed credits already applied, and should have a time limit (credits not earned back within 3 months expire).
Financial Penalties — Beyond service credits, some SLAs impose direct financial penalties for repeated or severe failures. These are more common in government contracts and critical infrastructure SLAs. Under Section 74 of the Indian Contract Act, specified penalties will be enforced only to the extent of "reasonable compensation" regardless of the stated amount.
Termination Triggers — Persistent SLA failure (missing targets for 3 or more consecutive months or 5 out of 12 months) should trigger a right to terminate without penalty. Material breach (complete service outage exceeding a specified duration) should trigger immediate termination rights. Transition assistance obligations should survive termination to prevent service disruption during provider migration.
Indemnification and Liability in SLA Context
Service credits compensate for underperformance. Indemnification compensates for losses caused by service failure.
When a cloud provider\'s outage causes a financial services client to miss trading windows, the loss is not the monthly service fee — it is the revenue from missed trades. When a BPO\'s processing error causes incorrect invoices to be sent to thousands of customers, the damage is not the processing fee — it is the reputational harm and customer churn.
SLA indemnification clauses must address:
Scope of Indemnification — What losses does the provider indemnify? Direct losses only, or consequential losses as well? Most providers resist consequential loss indemnification. Most customers need it for mission critical services. The negotiation centres on carving out specific consequential losses that are foreseeable and directly linked to the service failure.
Liability Caps — Typically expressed as a multiple of annual fees (1x to 3x). Some SLAs have tiered caps: a lower cap for general failures and a higher or uncapped liability for data breaches, confidentiality violations, and IP infringement. Under DPDPA 2023, data breach penalties from the Data Protection Board are not subject to contractual liability caps.
Exclusions — Force majeure events, customer caused issues (failure to provide access, incorrect specifications), and third party actions beyond the provider\'s control are typically excluded from indemnification.
Sector Specific SLA Considerations
IT Managed Services — Focus on infrastructure uptime, incident response, patch management, and disaster recovery. Must address multi-cloud environments, hybrid infrastructure, and the provider\'s subcontractor chain. CERT-In reporting obligations under IT Act 2000 must be allocated between provider and customer.
SaaS Platforms — Uptime commitments (99.95% is the market standard for enterprise SaaS), planned maintenance windows, data portability on termination, feature release cadence, and API availability. SaaS SLAs must address data residency under DPDPA if the platform stores personal data of Indian users on servers outside India.
BPO and Business Process Outsourcing — Transaction processing accuracy (99.5% or higher), turnaround time, quality audit scores, staffing levels, and business continuity. BPO SLAs must address regulatory compliance for the specific process being outsourced (payroll processing requires PF and ESI compliance, customer service requires POSH compliance).
Cloud Infrastructure (IaaS/PaaS) — Compute availability, storage durability, network latency, auto-scaling commitments, and data recovery guarantees. Cloud SLAs are typically non-negotiable for standard tiers but customisable for enterprise agreements. The customer must understand that multi-region deployment is the customer\'s responsibility for achieving higher availability than the single-region SLA.
AI and Machine Learning Services — Model accuracy baselines, inference latency, training data governance, bias monitoring, and explainability commitments. This is the newest SLA category and has no industry standard yet. SLAs for AI services must address model drift, retraining frequency, and the provider\'s obligations when model performance degrades below baseline.
What You Need to Know
Is Your SLA Enforceable?
The difference between a well drafted SLA and a template SLA becomes apparent only during a service failure. By then, it is too late to negotiate.
[email protected]