Ask any risk manager how their COI process works and you will hear a version of the same story: someone emails a vendor, the vendor sends back a PDF, someone opens it and squints at the numbers, maybe checks a spreadsheet, maybe does not, and then the file lands in a folder that nobody revisits until something goes wrong.

That process fails quietly at first. Then it fails loudly - a subcontractor causes a job-site injury and the umbrella policy turns out not to follow form, or a vendor's GL renewed three weeks ago and nobody caught the new exclusion, or the additional insured endorsement was requested but never actually added to the underlying policy. By the time the claim arrives, the certificate is long since filed.

Industry data consistently shows that 60 to 70 percent of certificates of insurance contain at least one material deficiency on first submission. The deficiencies range from trivial (wrong certificate holder address) to catastrophic (coverage limits below contract minimums). Most organizations only catch the obvious ones. The subtle ones - the umbrella that doesn't follow form, the workers comp with an excluded officer, the AI endorsement issued by the broker but not reflected on the actual policy - those slip through manual review routinely.

This guide covers the specific practices that close those gaps: how to set requirements that vendors can actually meet, how to build a collection process that doesn't rely on heroic effort, what to verify and in what order, and how to build a renewal system that catches expirations before they create exposure.

Set Minimum Requirements Before Vendor Onboarding

The most common compliance failure happens before any certificate is ever requested: the organization has no written, category-specific insurance requirements. Without them, whoever reviews the certificate is making subjective judgment calls - and those calls will be inconsistent across reviewers, projects, and time.

Requirements need to be defined by vendor category, not applied uniformly. A software consultant who never sets foot on your property represents fundamentally different risk than a mechanical contractor working in an occupied building. The coverage requirements should reflect that difference.

A typical tiered requirement structure looks like this:

Vendor Category General Liability Auto Liability Umbrella / Excess Workers Comp Professional / E&O
General Contractor $1M each occ / $2M aggregate $1M CSL $5M follow form Statutory / $1M EL Not required
Trade Subcontractor $1M each occ / $2M aggregate $1M CSL $2M follow form Statutory / $500K EL Not required
Technology Vendor $1M each occ / $2M aggregate Not required Not required Statutory $1M per claim / $2M aggregate
Staffing Agency $1M each occ / $2M aggregate $1M CSL if driving $2M follow form Statutory / $500K EL Not required
Professional Consultant $1M each occ / $1M aggregate Not required Not required Statutory $1M per claim / $2M aggregate

Two things matter here beyond the numbers themselves. First, the requirements need to specify that umbrella or excess policies follow form for the underlying GL. A $5M umbrella that doesn't follow form provides far less protection than it appears to. Second, professional liability (E&O) requirements need a retroactive date specification - a policy with a retroactive date of last year offers no coverage for work performed before that date.

Get the requirements into the contract, not as a separate attachment that gets forgotten. The insurance requirements section of your vendor agreement should reference the specific limits, name your entity as additional insured, require notice of cancellation, and specify that waiver of subrogation applies. When requirements live in the contract, there is no ambiguity about what was agreed.

Practical note: Review your requirements annually against current market rates. GL limits that seemed adequate five years ago may be materially insufficient given construction cost inflation and jury award trends. Your broker can provide benchmark data by industry vertical.

Standardize Your Collection Process

After requirements are defined, the next failure point is collection - specifically, the question of who collects, when, and through what channel. Organizations that handle this ad hoc end up with certificates collected by whoever happened to initiate the vendor relationship, arriving through personal email inboxes, stored in random folder structures, and with no single person accountable for completeness.

Assign ownership clearly. In most organizations, procurement or vendor management owns collection for standard vendors, while project management or operations owns collection for project-specific contractors. Legal or risk management should own the requirements definition and exception approval. The key is that someone specific is accountable for each vendor - not "whoever is working with them."

Collect before work begins. This sounds obvious but breaks down constantly in practice. A contractor starts mobilizing Monday morning and the project manager approves site access because it would cause delays to hold them. The COI request goes out, the vendor says they'll have it by end of day, end of day becomes end of week, and by the time anyone follows up the work is half done. The correct process is to treat certificate collection as a gate - no access granted, no purchase order issued, no statement of work executed until a compliant certificate is on file. Building this into your contracting workflow, not as a checklist item but as a hard system control, is what actually enforces it.

Use a dedicated intake channel. A shared mailbox (something like [email protected]) gives you a single place where all certificates arrive, creates an audit trail, and ensures that certificates aren't lost when an employee leaves. If you're processing significant volume, a vendor portal where vendors self-serve the upload is even better - it reduces the back-and-forth of email requests and gives vendors a direct place to submit renewals.

Require originals. Certificates of insurance should come directly from the vendor's broker, not as screenshots, not as copies of PDFs that were emailed to someone else, and not as photos taken on a phone. A certificate that's been scanned, re-saved, and forwarded three times is more likely to have readable extraction issues and, more importantly, may not reflect the current state of the policy. Require that vendors have their broker send the certificate directly to your intake address.

Know What to Actually Verify

Receiving a certificate and verifying a certificate are not the same thing. Most organizations do the former. Few do the latter systematically. Here is what a rigorous verification looks like, field by field:

Named Insured Must Match the Contracting Entity Exactly

The named insured on the certificate must match the exact legal name of the entity you have a contract with - not the parent company, not a subsidiary, not a DBA unless the DBA is specifically listed. If you contracted with "Apex Mechanical LLC" and the certificate shows "Apex Group Holdings Inc," you have a problem. Claims may be disputed if the covered entity doesn't match the contracting entity. This is one of the most common errors and one of the easiest to miss when reviewing quickly.

Policy Dates Must Cover the Full Scope of Work

Check both the policy effective date and the expiration date. The policy must be in force for the entire duration of work, including any warranty or defect correction period if your contract requires it. For long-term contracts, this means you need to verify renewal certificates annually - a policy that covers the start of a two-year contract doesn't automatically cover year two.

Limits Must Meet Your Minimums for Each Line

Compare each coverage line against your category-specific requirements. Pay attention to which limit applies - "each occurrence" and "aggregate" are different numbers with different meanings. A $1M each occurrence / $1M aggregate policy is materially less protection than $1M/$2M because the aggregate caps total annual exposure. Also verify that umbrella limits are truly excess over all required underlying coverages, not just GL.

Additional Insured Endorsement Must Be on the Policy

This is the most consequential verification failure in COI management. A certificate of insurance is not a guarantee of coverage - it is evidence of insurance at a point in time. The additional insured designation on a certificate is not binding on the insurer. The endorsement must be attached to the actual policy. The best way to verify this is to request a copy of the additional insured endorsement (typically an ISO CG 20 10 or CG 20 37 for completed operations) directly. For high-value contracts, consider requiring confirmation from the insurer rather than just the broker.

Waiver of Subrogation Where Required

If your contract requires a waiver of subrogation - meaning the vendor's insurer waives its right to subrogate against you if it pays a claim - that waiver must be reflected on the certificate and, again, endorsed onto the policy. A waiver of subrogation requested but not actually endorsed creates a false sense of protection.

Certificate Holder Name and Address

Your entity name and address must be correct in the certificate holder field. This matters practically for notice of cancellation purposes - if the address is wrong, you may not receive the cancellation notice required by the policy. It also matters legally in some jurisdictions where certificate holder designation triggers specific rights.

The Most Common Compliance Failures and How to Catch Them

Beyond the field-by-field review, certain failure patterns recur so consistently that they deserve specific attention:

The broker-issued AI, the policy-never-endorsed AI. A broker can issue a certificate showing your organization as additional insured in seconds. That doesn't mean they submitted an endorsement request to the insurer. It doesn't mean the underwriter approved it. For any significant contract, request the actual endorsement document - not just the certificate. If the vendor's broker can't produce it within 24 hours, escalate.

Wrong entity name - subsidiary vs. parent. In complex corporate structures, vendors often have multiple entities and may inadvertently send a certificate for the wrong one. If the vendor operates as a subsidiary but the policy is in the parent's name, and the parent is not listed as a named insured on the project, coverage for work performed by the subsidiary may be disputed. Verify the entity name in the contract against the certificate before signing.

Coverage that expired mid-project. A project that starts in Q1 with a vendor whose annual renewal is in February will need a new certificate in February. Most manual processes catch the initial certificate but miss the mid-project renewal. This is where a systematic renewal tracking calendar matters - not just tracking initial expiration dates, but mapping renewal dates to active project periods.

Umbrella that doesn't follow form for GL. An umbrella or excess policy that follows form provides coverage on the same terms as the underlying policy. An umbrella that doesn't follow form may have its own coverage terms, exclusions, and conditions that differ from the GL it's supposed to be excess of. If your umbrella requirement says "follow form" and the vendor's umbrella has materially different terms, you may not have the protection you believe you have. This requires reading the umbrella policy itself, not just the certificate.

Workers comp excluded for certain operations. In some states and industries, workers compensation policies can exclude specific officers, partners, or classes of operations. A subcontractor whose owner is excluded from workers comp coverage - a common election for small contractors - creates personal injury exposure for your organization if that owner is injured on your site. Look for the workers comp exclusions section and ask questions if anything is excluded.

Build a Renewal Tracking System

The most robust COI verification process provides zero ongoing protection if policies expire and nobody notices. Renewal tracking is where most manual processes completely fall down - because it requires proactive, calendar-driven follow-up across every active vendor relationship, not just reactive response to incoming certificates.

An effective renewal tracking cadence works like this:

The critical piece is defining what happens operationally when a certificate lapses. If the answer is "we send another email," the system won't hold. The answer needs to be "access is revoked, invoices are held, PO authorizations are suspended" - something that creates a real consequence that motivates action. Document this policy and make sure vendors understand it at onboarding.

For notifications, both your team and the vendor (or their broker) should be in the loop. Vendors often don't track their own renewal obligations proactively, especially small contractors who renew one of several policies annually. Sending the renewal request directly to the broker rather than the vendor's operations contact often results in faster certificate issuance.

Automate What You Can

Everything described above can be done manually for a small vendor population. At 20 active vendors with staggered renewal dates, a spreadsheet and a disciplined team can make it work. At 50 vendors it becomes precarious. At 200 vendors it becomes impossible to do well without tooling.

The specific failure modes of manual processes at scale are predictable:

API-based COI extraction solves the transcription and consistency problems by parsing the certificate programmatically. A tool like COI ParseAPI submits a PDF and receives structured JSON back - named insured, each coverage line with limits and dates, certificate holder, additional insured status. That structured output feeds directly into your compliance rules engine without a human reading and re-entering numbers. See our guide on automating COI verification for property managers for a technical walkthrough of what that integration looks like in practice.

Automated compliance scoring goes further - instead of a human applying judgment to a set of coverage lines, the system compares parsed values against your category-specific requirements and produces a compliance score with specific failure flags. This scales to any volume and produces consistent results.

For teams evaluating tools, the comparison between manual, dedicated platform, and API-first approaches is covered in detail in our COI tracking software comparison. The short version: if you're processing more than 50 certificates per year or need to integrate COI data into an existing system, API-first extraction is the highest-leverage investment you can make in your compliance program.

Understanding the specific form types involved also matters for setting up automated rules correctly - the difference between what ACORD 25 and ACORD 28 certificates contain affects what you can and can't verify from the certificate alone. The ACORD 25 vs ACORD 28 breakdown covers the specific fields and their compliance implications.

Conclusion: Compliance Is a System, Not a Review Step

The organizations with the most effective COI compliance programs share one characteristic: they treat compliance as a system with defined inputs, rules, and outputs - not as a review step performed by whoever happens to be available. The system has clear requirements by vendor category, enforced collection gates, field-by-field verification criteria, automated renewal tracking, and defined consequences for non-compliance.

Building that system takes more upfront work than printing a checklist. But the math is straightforward. If your organization processes 200 COIs per year at 20 minutes each, that's 66 hours of staff time - and that's before accounting for the follow-up emails, the re-submissions, the policy endorsement requests. More importantly, a single uncovered claim that traces back to a compliance gap can generate six-figure exposure that no amount of manual review budget could justify.

The practical starting point is usually requirements definition - getting clear on what you actually need by vendor category - followed by collection process standardization. Automation makes the system scale, but the system has to exist first for automation to be useful. Start with the foundation.