The insurance requirements buried in your enterprise customer contracts: certificates, limits, and additional insureds

Enterprise software contracts have a habit of burying their most operationally consequential requirements in the boilerplate. Nowhere is this more true than in the insurance provisions, where a single line about "additional insured status" or "waiver of subrogation" can take weeks to satisfy and, if missed, put the entire deal at risk.
What the Contract Actually Says (And Why You Should Read It Before Legal Does)
Most founders and sales leads hand insurance sections directly to counsel without reading them first. That is understandable. It is also a reliable way to get surprised two days before a contract is supposed to execute.
Insurance provisions in enterprise agreements generally cluster around four requirements: minimum coverage types and limits, certificate of insurance (COI) delivery, additional insured endorsements, and subrogation waivers. Each of these is mechanical on the surface and genuinely complicated underneath.
Why exactly does the order matter? Because the sequence of discovery shapes how much leverage you have. Surfacing a requirement during negotiation gives you room to push back or ask your broker to adjust. Discovering it during legal review means the counterparty's procurement team already considers the deal closed, and your sudden inability to comply reads as negligence.
Coverage Types and Limits: The Numbers You Will Encounter
Enterprise customers, especially in financial services, healthcare, and government-adjacent software, ask for specific figures. The most common pattern you will see in SaaS vendor agreements looks something like this: $1 million per-occurrence and $2 million aggregate for Commercial General Liability, $1 million per-occurrence for Professional Liability (also called Errors and Omissions), and $1 million for Cyber Liability. Larger enterprises, particularly those running Fortune 500 procurement playbooks, push those numbers to $2 million per-occurrence CGL and $5 million in umbrella or excess coverage sitting above it.
Those limits sound arbitrary because they largely are. The $1 million/$2 million CGL structure has been the de facto standard in American commercial contracts for long enough that most procurement teams no longer know why they ask for it; they inherited it from the template. But what that means practically is that if your current policy is sitting at $500K per-occurrence, you have a real gap, not a theoretical one, and your broker needs to know before the contract drops.
Professional Liability is where early-stage software vendors get caught most often. General Liability covers bodily injury and property damage. Errors and Omissions covers the financial harm your product causes when it fails or behaves incorrectly. If you are selling software that influences decisions (pricing, compliance, lending, healthcare workflows), an enterprise customer asking for $2 million in E&O is not being aggressive; they are being reasonable. The coverage gap between those two policies is exactly where software liability actually lives.
Certificates of Insurance: A Document That Is Simultaneously Simple and a Logistical Nightmare
A COI is, on its face, a one-page summary of your active coverage issued by your insurer. Your broker generates it. You send it. Deal proceeds.
Except: the certificate has to list the correct additional insured, name the right entities, reflect the correct limits, and sometimes include language from endorsements that your broker has to attach separately. The customer's procurement team will reject a COI that does not match their contract language, even if the underlying policy is compliant. This happens regularly, and it typically wastes five to ten business days on administrative back-and-forth that nobody budgeted for.
What makes this worse at scale is that every enterprise customer wants their own COI, often with their specific legal entity name (not the trade name you know them by), renewed annually, and sent directly to a procurement inbox that may or may not be monitored by anyone who can make decisions. If you have twelve enterprise customers, you have twelve annual certificate renewal events, each with its own quirks.
The Additional Insured Problem
An additional insured endorsement does something specific: it extends your CGL policy's coverage to include the customer as a protected party, so that if a third party sues them for something your product caused, your policy responds on their behalf. Customers ask for this because it protects them from liability that traces back to a vendor relationship. Makes sense from their seat.
From your seat, adding additional insureds is not free. Most insurers will do it, but the endorsement has to be formally issued, it affects your policy, and your broker needs to be in the loop. Some policies limit how many additional insureds you can carry; others require underwriter approval for customers above a certain revenue threshold. The contract clause that says "Vendor shall name Customer as additional insured on all applicable policies" sounds clean. Actually executing it takes coordination between your legal team, broker, and the insurer's endorsement processing desk.
It is also worth considering what "all applicable policies" actually means when you read that language carefully. CGL, sure. Umbrella? Probably. Cyber? Sometimes. Workers' Comp and Professional Liability do not actually support additional insured status in the traditional sense, which surprises a lot of procurement teams who wrote that clause without knowing it. A good broker will help you push back on overbroad additional insured demands with accurate, non-confrontational language.
Waiver of Subrogation: The Clause Nobody Explains at Signing
Subrogation is the right of your insurer to recover money from a third party after paying your claim. If your product causes a data breach at a customer site, your insurer pays the claim, and then goes after the responsible party to recoup the loss. Logical enough.
A waiver of subrogation means your insurer gives up that right in advance, specifically toward the customer. The customer wants this because it prevents your insurer from suing them after a covered incident, even if they were partially at fault. It is, in effect, a promise that your insurer will not turn around and litigate against the customer after settling your claim.
But what if your insurer never agreed to waive that right? That is the crux of the problem. Your contract can say "Vendor agrees to waive subrogation rights" all day long; if your actual policy does not include a waiver of subrogation endorsement, the clause is contractually binding on you but operationally unenforceable by the customer. Which is worse: the false security the customer has, or the breach of contract exposure you carry? The answer is probably both.
How to Actually Manage This
The practical workflow here is not glamorous. You review the insurance exhibit before redline exchange. You send it to your broker alongside the coverage specifications. Your broker tells you where you are compliant, where you have gaps, and what endorsements need to be issued. You go back to legal with a clear list of what you can and cannot agree to as written, and you negotiate from there.
The mistake most growth-stage companies make is treating insurance compliance as a post-signature checklist item. By then, you have already agreed to terms you may not be able to fulfill. That mistake lands differently when it is day three of a delayed contract.
The better approach is building a standard insurance exhibit your broker has pre-approved, knowing in advance what your policy actually covers, and using that document proactively in negotiation rather than reacting to whatever the customer's legal team sends. That is not sophisticated risk management; it is just operational hygiene applied to a part of the business most companies ignore until it bites them.
Navigating the Broker Relationship in an Enterprise Context
Most small and mid-size software companies work with a commercial broker who handles their business owner's policy and maybe a cyber rider. That arrangement works fine until you start selling to enterprises, at which point you need a broker who has actually read an enterprise software vendor agreement and knows what a waiver of subrogation endorsement looks like.
The question worth asking your broker: have they issued certificates for SaaS vendors with additional insured requirements before? If the answer is hesitant, or if they have to look up what an E&O policy is, that is useful data. Brokers who specialize in technology companies understand that coverage requirements are not static; they escalate as your contract values grow, and the policy structure needs to grow with them.
There is a meaningful difference between a broker who renews your policy annually and one who helps you read an insurance exhibit and structure a response. The former is a commodity service. The latter is a strategic relationship, and it is worth paying for if you are actively selling into enterprise.
Why This Section of the Contract Deserves a First-Class Seat at Negotiation
The insurance provisions in enterprise agreements are not boilerplate in the dismissive sense of the word. They carry real operational and financial consequences, they take real time to comply with, and they surface real gaps in a vendor's coverage structure if nobody reads them carefully.
Procurement teams at large enterprises have seen enough vendors scramble at signature time to know that a vendor who comes prepared, with a pre-approved insurance exhibit and a broker on standby, is a vendor who has their operational house in order. That signal matters. Deals close on trust as much as capability, and showing up to an insurance conversation without a COI in hand is a small but visible form of disorganization.
Read the exhibit. Call your broker. Don't wait for legal to forward it to you with a note that says "can you handle this?" You can handle it better if you see it first.