Insurance for Startups & New Economy

Insurance for B2B SaaS Serving Enterprise Clients: Contract Liability India

Enterprise clients increasingly demand insurance limits that early-stage B2B SaaS companies cannot meet from standard Indian policy products. This guide maps the gap between contract-required limits and what the market provides, and explains how founders can negotiate both.

Sarvada Editorial TeamInsurance Intelligence
15 min read

Listen to this article

Audio version • 15 min read

b2b-saasenterprise-contractsprofessional-indemnitycyber-insurancedpdp-actindiastartup-insurance

Last reviewed: May 2026

Why Enterprise Contracts Are Now the Primary Insurance Driver for B2B SaaS

For most early-stage B2B SaaS companies in India, the first serious engagement with insurance is not a regulatory requirement or an investor condition - it is an enterprise client's standard contract. An Indian IT services company serving a BFSI client will encounter, typically in the Master Service Agreement (MSA) at the indemnification clause, an insurance schedule that requires minimum limits for Professional Indemnity (PI), Cyber Liability, Commercial General Liability, and sometimes Directors and Officers (D&O) liability. These requirements are not negotiating points in the early stages of a commercial relationship with a large enterprise buyer; they are conditions that must be met before the contract can be signed.

The gap this creates for a Series A or Series B SaaS company is significant. A mid-size Indian bank's standard vendor insurance schedule might require INR 50 crore in PI coverage with a INR 25 crore cyber sublimit per occurrence. A Series A SaaS company typically has access to no more than INR 10-25 crore in PI coverage from the Indian market at a price it can afford, and its cyber policy may have a limit of INR 5-10 crore. The SaaS company either accepts the insurance requirement in the contract (and hopes for no claim), misrepresents its coverage, or walks away from the deal.

This is not a hypothetical problem. Several Indian SaaS founders interviewed by Sarvada's advisory team in early 2026 reported that they had accepted enterprise contract insurance clauses they could not fully satisfy, banking on the enterprise client not verifying coverage at renewal. The risk is that if a claim occurs and the required insurance is not in place, the enterprise client can treat the insurance requirement as a contract warranty - making the SaaS company liable for any uninsured portion of the claim directly, without the benefit of the indemnity limitation clauses that typically cap the SaaS company's total exposure.

Understanding the structure of enterprise insurance requirements, the Indian insurance market's capacity limits, and the negotiating levers available on both the contract and the insurance programme side is an essential skill for any B2B SaaS company targeting enterprise sales in India.

Standard Insurance Clauses in Indian IT Services Agreements

Indian enterprise technology agreements - whether an outsourcing contract with an IT services company, a SaaS subscription agreement with a cloud-based analytics provider, or a software implementation contract - follow a largely standardised structure for insurance clauses. Understanding what these clauses actually require, and how they map to IRDAI-regulated policy products, is the starting point for managing enterprise insurance risk.

The typical enterprise insurance clause in an Indian IT services agreement specifies four types of coverage. First, Professional Indemnity (PI) or Errors and Omissions (E&O) coverage for claims arising from the vendor's professional negligence, technology failures, or failure to deliver contractually promised functionality. The required limit is typically expressed as a 'per claim' and 'annual aggregate' pair - for example, INR 50 crore per claim and INR 100 crore annually. Second, Cyber Liability or Technology Liability coverage for data breaches, network security failures, and privacy violations. The required limit often mirrors the PI limit. Third, Commercial General Liability (CGL) for bodily injury and property damage. Fourth, Workers' Compensation or Employers' Liability per the Employees' Compensation Act, 1923.

The IRDAI product category most relevant to the PI/E&O requirement is the Professional Indemnity (PI) policy, which in India is filed under the Miscellaneous category and broadly covers claims arising from the insured's professional error, omission, or negligent act. For technology companies, IRDAI-filed technology E&O endorsements extend PI cover to include claims arising from software performance failures, outages, data corruption caused by the vendor's software, and intellectual property infringement in the vendor's code. The cyber liability requirement maps to IRDAI's standalone cyber insurance products, while CGL maps to the Public/Products Liability policy.

The critical mapping issue is that Indian PI policy wordings are not identical to the E&O wordings used in US or UK enterprise contracts. Specifically: Indian PI policies typically have a broad definition of 'claim' that includes both third-party suits and regulatory investigations, but the trigger is a 'claims-made' basis - meaning the claim must be made against the insured and reported to the insurer during the policy period. Enterprise contracts sometimes require 'occurrence-based' coverage that responds to incidents occurring during the contract period regardless of when the claim is made. This trigger mismatch must be identified and addressed in the contract negotiation, not discovered after a claim.

The Limit Gap: What the Indian Market Offers vs. What Contracts Demand

The central challenge for early-stage B2B SaaS companies in India is a structural mismatch between the insurance limits enterprise clients demand and what the Indian insurance market makes available at the SaaS company's price point.

For a Series A B2B SaaS company with revenue of INR 10-30 crore per year, the realistic maximum PI limit available from the Indian non-life market is INR 25-50 crore. To obtain limits above INR 25 crore, most Indian insurers require involvement from a reinsurer. The lead insurer in India may write INR 10-15 crore of the limit from its own account, with reinsurance support required for the balance. Reinsurer appetite for technology E&O risks from Indian startups varies: international reinsurers (Swiss Re, Munich Re, Hannover Re, Lloyd's syndicates) have capacity for well-structured risks, but a Series A SaaS company without a meaningful claims history, audited financials, and documented security posture may find its access to capacity limited.

Cyber insurance faces a similar constraint. The Indian market for standalone cyber policies has grown significantly since 2022, but per-occurrence limits above INR 25 crore for a Series A SaaS company are difficult to achieve at a price the company can absorb. The annual premium for a INR 25 crore cyber policy for a technology company with meaningful data processing activity typically ranges from INR 8-20 lakh - which is manageable - but limits of INR 50 crore or above require excess layers from multiple insurers or London market placement, adding placement time and cost.

Infosys and TCS as supplier insurance requirements illustrate the upper end of what large Indian IT companies demand from their own technology vendors. A significant technology vendor in an Infosys digital transformation project, for example, typically faces a contract insurance schedule requiring INR 50-100 crore in PI and a comparable cyber limit. This is achievable for a vendor of significant revenue scale, but for a Series A SaaS company that has won a single significant contract as a subcontractor to a Tier 1 IT company, meeting the insurance requirement from the Indian market at an affordable premium may not be possible.

The practical options for a SaaS company in this position are: negotiate the contract limit down (possible early in the relationship, very difficult once the enterprise client's procurement team has established a vendor insurance standard); purchase coverage up to the available limit and disclose the gap to the client (some enterprise clients will accept this with appropriate contractual acknowledgement); structure the deal through a larger integrator who has the insurance capacity and then subcontract the SaaS functionality (this delays direct enterprise relationships); or explore Lloyd's market placement through a specialist broker, which can access higher limits but requires more time and documentation. None of these options is costless, and all of them require the SaaS company to have a mature conversation with both its insurance broker and its legal team before signing the enterprise contract.

Named Insured vs. Additional Insured: What Enterprise Clients Actually Want

Enterprise insurance clauses in Indian IT agreements typically require the vendor to maintain specified insurance and provide certificates of insurance. The more sophisticated enterprise clients go further and require the client to be named as an 'additional insured' on the vendor's policy, or require that the vendor's policy contain a waiver of subrogation in favour of the client. Understanding what these requirements actually mean for the vendor's policy - and what they mean for how a claim would be handled - is essential.

A named insured is an entity that appears on the face of the policy as a primary insured, typically with full rights to make claims, receive notices, and cancel the policy. This is not what enterprise clients generally require from their vendors; they are not seeking co-ownership of the vendor's policy. An additional insured is different: it is an entity added to the policy (usually by endorsement) that has the right to be defended and indemnified by the insurer for claims arising from the named insured's (the vendor's) activities. The additional insured does not have the right to make claims on its own behalf or to affect the policy terms.

For a B2B SaaS vendor, adding an enterprise client as an additional insured on the vendor's PI policy creates a specific dynamic in a claim scenario. If the enterprise client suffers a loss arising from the vendor's software failure (for example, data corruption or a service outage that causes the client financial loss), the client can potentially claim directly against the vendor's PI policy as an additional insured rather than having to sue the vendor and wait for the vendor to make a claim. This is operationally simpler for the client, but it means the insurer is directly managing its relationship with the enterprise client as an additional insured - which can complicate the insurer's defence strategy.

Not all Indian PI underwriters will agree to add enterprise clients as additional insureds. Some require a separate endorsement for each additional insured, with a review of the underlying contract. Some impose a sub-limit on additional insured coverage. And some draw a distinction between 'additional insured' status (which gives the client direct access to the policy) and 'certificate holder' status (which merely evidences that the policy exists but does not grant direct access). A vendor should verify, before signing an enterprise contract that requires additional insured status, that its PI underwriter will actually issue the required endorsement - and should obtain this confirmation in writing from the insurer, not merely from the broker.

The waiver of subrogation requirement is equally specific. A standard PI policy gives the insurer the right of subrogation: if the insurer pays a claim by the vendor, the insurer can pursue recovery against third parties (including potentially the enterprise client) who contributed to the loss. An enterprise client that requires a waiver of subrogation is requiring the vendor's insurer to waive its right to pursue the client for any contribution to the loss. Most Indian PI underwriters will grant this waiver by endorsement, but it should be explicitly obtained rather than assumed.

DPDP Act 2023 and Data Processing Agreements: Insurance Implications

The Digital Personal Data Protection Act, 2023 (DPDP Act) has introduced a new dimension to B2B SaaS enterprise contracts: the Data Processing Agreement (DPA). Under the DPDP Act, when a B2B SaaS company processes personal data on behalf of an enterprise client, the SaaS company is a 'Data Processor' and the enterprise client is a 'Data Fiduciary'. The Data Fiduciary (enterprise client) remains responsible to the Data Protection Board of India (DPBI) for ensuring that the Data Processor (SaaS company) handles the data in compliance with the Act.

This regulatory structure is directly relevant to insurance in three ways. First, the enterprise client's exposure to DPBI penalties and enforcement action (up to INR 250 crore for serious violations) creates pressure on the client to contractually require its vendors (including the SaaS company) to maintain insurance that covers data processing failures. Enterprise clients are increasingly including in their DPAs a requirement that the SaaS vendor maintain cyber insurance covering data breaches arising from the vendor's systems, with the client named as an additional insured or loss payee.

Second, the SaaS company's own DPBI exposure is significant even though it is a Data Processor rather than a Data Fiduciary. The DPDP Act under Section 8(2) requires Data Fiduciaries to process data through Data Processors only under a valid contract and to ensure the Data Processor implements appropriate technical and organisational measures. If a breach occurs in the SaaS company's systems and the SaaS company is found to have failed to implement the security measures required by the DPA, the DPBI can pursue action against both the Data Fiduciary (enterprise client) and potentially against the Data Processor (SaaS company) as an entity that processed data in breach of its obligations. The SaaS company's cyber policy must cover DPBI investigation defence costs.

Third, the DPA will typically include a data breach liability clause that requires the SaaS company to indemnify the enterprise client for losses arising from a data breach caused by the SaaS company's failure. This is a contractual indemnity that interacts with the SaaS company's cyber policy. The sequence of events in a breach scenario is: breach occurs in SaaS company's systems, enterprise client suffers regulatory penalties and remediation costs, enterprise client invokes the contractual indemnity, SaaS company tenders the claim to its cyber insurer. The cyber policy must be structured to respond to contractual indemnity obligations of this type - not all Indian cyber policies clearly cover the insured's contractual liability to a business client as distinct from its statutory liability to regulators or individual data subjects.

SaaS companies negotiating DPAs with enterprise clients should ensure that the data breach indemnity clause in the DPA is calibrated against the cyber policy limit. A DPA that imposes unlimited data breach liability on the SaaS company, with a corresponding insurance requirement of INR 50 crore, creates an uncovered gap if the SaaS company can only obtain INR 15 crore of cyber coverage. The contractual indemnity limit and the insurance limit must be aligned.

Negotiating Insurance Provisions in Enterprise Contracts: A Practical Framework

Insurance provisions in enterprise contracts are negotiable, but the negotiation requires both legal and insurance brokerage input and must happen before the contract is signed - not after the vendor has agreed to the insurance schedule and is trying to buy coverage that does not exist at the required limit.

The first principle is to involve the insurance broker in the contract review process. Most B2B SaaS companies have their legal counsel review enterprise contracts but do not show the insurance schedule to their broker until they are trying to procure the coverage. The broker's role in contract review is to identify clauses that cannot be met with available market coverage, to suggest alternative wording that achieves the client's risk management objective without creating an uninsurable coverage gap, and to advise on the cost of meeting the insurance requirement before the company commits to it.

The second principle is to understand the enterprise client's objective. The insurance requirement in an enterprise contract is not an end in itself; it is a mechanism for ensuring that if the vendor causes a loss, there is a source of recovery available to the client beyond the vendor's balance sheet. A SaaS company that can demonstrate alternative financial assurance mechanisms - for example, a funded escrow arrangement, a parent company guarantee from a well-capitalised investor, or a letter of credit - may be able to negotiate a reduction in the insurance limit requirement in exchange for the alternative assurance.

The third principle is to negotiate the per-occurrence limit rather than the annual aggregate. Enterprise clients typically focus on the per-occurrence limit because they are concerned about a single catastrophic loss arising from the vendor's failure. If the SaaS company can demonstrate that the maximum probable loss from any single technology failure is limited (for example, by cap-limiting its contractual liability under the limitation of liability clause to a multiple of the annual contract value), the enterprise client may be willing to accept a lower per-occurrence insurance limit that reflects that cap rather than an uncapped contractual exposure.

The fourth principle is the interplay with the limitation of liability clause. Most IT services agreements include a bilateral cap on liability - typically one to two times the annual contract value - which limits the maximum financial exposure of both parties. If the SaaS company's annual contract value with the enterprise client is INR 2 crore, and the contract caps total liability at two times that amount, the maximum liability is INR 4 crore. A contract insurance requirement of INR 50 crore is disproportionate to a INR 4 crore liability cap. The SaaS company should negotiate to align the insurance requirement with the actual maximum liability exposure under the contract, not with an industry-standard template that was designed for much larger vendors.

The Path to Higher Limits: Excess Layers and London Market Access

For a B2B SaaS company that has won a significant enterprise contract and genuinely needs insurance limits beyond what the Indian market provides at the primary layer, the solution is an excess layer programme. Understanding how excess layers work, what they cost, and what documentation is required to access them is practical knowledge that most Indian SaaS founders lack.

An excess layer programme stacks coverage above the primary layer. For example, a SaaS company might purchase a INR 10 crore primary PI policy from an Indian non-life insurer (the 'primary layer'), and then purchase an additional INR 15 crore of coverage from a reinsurer or a second insurer (the 'excess layer') that attaches above the primary policy's limit. The total programme limit would be INR 25 crore. The excess layer insurer pays claims only after the primary layer limit is exhausted. Excess layers are typically cheaper per crore of coverage than the primary layer because the probability of a loss reaching the excess level is lower.

For limits above INR 25-50 crore, Indian SaaS companies typically need to access the London Market, primarily Lloyd's of London syndicates. Lloyd's syndicates have significant capacity for technology E&O and cyber risks from Indian companies, particularly those with international operations or multinational clients. A Lloyd's placement requires the company to work through an IRDAI-licensed Indian broker (who will then engage a Lloyd's broker in London under a coverholder or open market arrangement). The documentation requirements for a Lloyd's placement are more extensive than for a domestic Indian placement: underwriters will want audited financial statements, a completed technology E&O proposal form, details of the company's security posture and data handling practices, the specific enterprise contracts that are driving the insurance requirement, and a copy of any previous claims.

A well-prepared SaaS company can obtain Lloyd's market coverage relatively efficiently. The IFSCA's GIFT City framework, which permits Indian companies to access international insurance from GIFT City-licensed entities without triggering FEMA complexities, is an additional avenue for obtaining higher limits from international insurers without the documentation burden of a full London market placement.

The total cost of a INR 50 crore PI programme (INR 25 crore primary Indian layer plus INR 25 crore London or GIFT City excess) for a Series A technology company with strong security posture and clean claims history is approximately INR 15-35 lakh per year. For a company that has secured one or two significant enterprise contracts each with revenue upside of INR 5-10 crore, this cost is typically justifiable and can be factored into the enterprise contract pricing.

Frequently Asked Questions

Can a Series A B2B SaaS company in India obtain INR 50 crore in professional indemnity coverage?
Yes, but not always from a single Indian insurer. The domestic Indian market for technology PI typically offers primary limits of INR 10-25 crore for early-stage companies, with reinsurance support required for higher limits. For a total limit of INR 50 crore, a typical structure would be INR 10-25 crore from an Indian primary insurer and the balance from excess layer capacity, either from Indian reinsurers or from the London market (Lloyd's syndicates) accessed through a IRDAI-licensed Indian broker. The total annual premium for a INR 50 crore programme for a Series A technology company with clean history typically ranges from INR 15-35 lakh. The key prerequisites for accessing excess capacity are: audited financials, a completed technology E&O proposal form disclosing the enterprise contracts and their insurance requirements, and documentation of the company's information security controls.
What happens if a B2B SaaS company signs an enterprise contract with an insurance requirement it cannot meet?
If the company provides a certificate of insurance that misrepresents coverage, this creates insurance fraud risk and voids the policy for the misrepresented items. If the company signs the insurance warranty knowing it cannot fully comply, it accepts uninsured contractual liability for the gap. If a claim occurs that would have been covered had the full required limit been in place, the company bears the uninsured portion personally - which can be devastating for an early-stage company. The correct approach is to disclose the coverage gap to the enterprise client before signing and to negotiate either a reduced insurance requirement, an alternative assurance mechanism (such as a funded escrow), or a phased compliance timeline within which the company will build up to the required limit as its revenue and risk profile allow.
Do DPDP Act Data Processing Agreements create insurance obligations for SaaS vendors?
Indirectly, yes. The DPDP Act does not directly mandate that Data Processors maintain insurance, but the DPAs that enterprise clients (Data Fiduciaries) are now requiring their vendors to sign routinely include insurance provisions as a contractual requirement. These provisions typically require the SaaS vendor to maintain cyber insurance covering data breaches arising from the vendor's systems, with the client named as an additional insured or as a loss payee for breach-related costs. Separately, if the SaaS vendor suffers a breach that triggers DPBI enforcement action against the enterprise client, the vendor's contractual indemnity obligation to the client for the resulting penalties and remediation costs creates a cyber insurance claim. The vendor's cyber policy must explicitly cover contractual indemnity obligations to business clients (as distinct from statutory obligations to regulators), which not all Indian cyber policy wordings address clearly.

Related Glossary Terms

Related Insurance Types

Related Industries

Related Articles

Sarvada

Ready to see Sarvada in action?

Explore the platform workflow or start a product conversation with our underwriting automation team.

Explore the platform