Certificates of insurance aren't the certainty you think they are
23rd September 2026What a COI really tells you, and what it doesn't
Most third-party risk programs treat the certificate of insurance as a finish line. A vendor is onboarded, a contractual insurance requirement is written into the agreement, the vendor produces a certificate showing the required limit, and the file is closed. On paper, that looks like diligence. In practice, it answers a much narrower question than most risk managers realize they're asking.
What a certificate confirms
A certificate of insurance (COI) is a simple document, and it is honest about what it does: it confirms that a named policy exists, that it was in force as of a given date, and that it carries a stated aggregate limit. For many enterprise contracts, it may also confirm they have been added as an additional insured or certificate holder, which can matter for notification purposes.
That is the full extent of what the document verifies. It does not require the carrier, the vendor, or the broker to demonstrate anything beyond those facts, and no standard COI format asks them to.
What it doesn't confirm - but many assume it does
The gap sits entirely in what the certificate is silent on, and the silence is larger than most third-party risk management (TPRM) programs account for.
- Whether the policy responds to the specific harm at issue. Cyber insurance has not yet developed the level of policy standardization common in property or general liability. Carriers differ in how they define a "wrongful act," how they treat supply chain or dependent business interruption events, and how broadly or narrowly they scope notification and remediation costs. Two vendors holding certificates with identical aggregate limits can be covered in materially different ways, and the certificate gives no indication of which is which.
- What's excluded. Exclusions for war, infrastructure failure, acts attributed to nation-states, or specific attack vectors vary by carrier and by policy year. A certificate doesn’t show an exclusions schedule, because it was never designed to.
- How many other customers are relying on the same limit. This is the question almost no TPRM program asks, and it may be the most consequential one. A vendor's cyber policy typically protects that vendor against claims from all its customers collectively, under one aggregate limit. A $10 million cyber limit sounds substantial in isolation. It sounds very different once you learn it could sit behind a customer base measured in the hundreds of other enterprise clients, each of whom holds an identical certificate and each of whom assumes they have meaningful access to that number.
None of this is visible on the document that most vendor risk files treat as complete.
Two jobs that have been quietly conflated
The reason this gap persists is that TPRM programs have merged two distinct questions into a single checkbox.
The first question is whether a vendor carries insurance. That is a question of existence, and a certificate answers it completely.
The second question is whether that insurance would actually respond, for this enterprise specifically, in the scenario this enterprise is most exposed to. That is a question of protection, and nothing in the standard certificate process touches it.
"Risk managers are told to manage vendor exposure," says Josh Ladeau, Managing Director - Strategic Initiatives at Trium Cyber. "Very few of them are given a way to see whether the coverage sitting behind that exposure would actually hold up in a real event. An entire verification process has been built around proving something exists, and called it done, without ever ensuring it actually protects anyone."
Why the gap hasn't closed on its own
This isn't a failure of risk managers. It's a structural feature of how vendor insurance requirements were built, and it’s exacerbated by the inherent 1st party coverages core to any modern cyber policy. Vendors logically purchase cyber policies that serve their own priorities first, often with price as the driving factor. And a vendor's broker has a fiduciary duty to that vendor, not to the enterprise clients relying on the resulting certificate.
Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year over year to 30%, and SecurityScorecard's 2025 Global Third Party Breach Report put the figure at 35.5%. That growing share of exposure is being managed largely through a certificate-verification process that was never designed to assess coverage adequacy.
Reviewing every vendor policy in full, against every plausible loss scenario, is not realistic at the volume most enterprises operate at. That reality is exactly why the current shortcut, "certificate on file equals risk addressed," took hold. It was never meant to be a complete answer. It became one by default.
The question this leaves for TPRM programs
If your vendor risk file can answer, "Does this vendor have cyber insurance?" but not "Would this vendor's cyber insurance respond to the incident we're actually worried about?", those two answers are being treated as the same thing. Except, they aren’t. The difference only becomes visible in the moment it's most expensive to discover - after an incident, not before one.
Verifying that insurance exists and verifying that insurance protects your organization have always been two different jobs. Most programs are still only structured to do the first one.
Sources
Verizon's 2025 Data Breach Investigations Report
SecurityScorecard's 2025 Global Third Party Breach Report
Disclaimer
This content is intended for general informational purposes only and does not constitute legal, regulatory, financial, or insurance advice. It should not be relied upon as a substitute for professional counsel. While efforts have been made to ensure the accuracy of the information presented, no representation or warranty is made as to its completeness or applicability to any specific situation. Readers should consult their own advisors regarding their particular circumstances.