How to Request an Exception to a COI Requirement

Exception preparation

How to Request an Exception to a COI Requirement

A useful exception request identifies the exact written requirement, explains the specific constraint, describes an observable alternative, separates insurance availability from commercial acceptance, and asks an authorized client representative for a written decision.

Reviewed September 2026 · Educational information, not insurance or legal advice

An exception request is not an exception. A proposal, broker comment, portal note, or uploaded alternative does not change the client’s written requirement. Preserve the authorized response, its scope, conditions, effective period, and source.

Separate three different decisions

What the client requires

The client, contracting party, or authorized reviewer identifies the evidence it expects and decides whether its administrative or commercial requirement may be changed, waived, deferred, or satisfied by an alternative. The exact decision authority depends on the contract and organization. A reviewer who can reject a portal item may not necessarily have authority to amend a contract.

What insurance evidence is available

The licensed agent, broker, insurer, or other authorized issuer explains what policy-backed certificate or endorsement evidence can accurately be issued. That professional can identify a limitation, underwriting question, timing issue, or available alternative. Insurance availability is important input, but it is not the client’s acceptance decision.

What the contractor will do next

The contractor or vendor preserves the source, confirms project facts, gathers the issuer’s response, prepares the exception proposal, sends it through the approved route, tracks the decision, and controls the resulting package. Coordinating the process does not authorize the contractor to edit issued evidence or declare its own exception accepted.

Prepare the exception before sending it

  1. Freeze the controlling source. Record the requirement title, version, date, section, project, and exact item. If two sources conflict, resolve which one controls before describing an exception.
  2. Write one requirement per row. Do not combine limits, additional insured status, waiver language, renewal timing, and portal delivery in one general request.
  3. Describe the proposed exception. State precisely what would differ from the written requirement. Avoid vague phrases such as “use current insurance” or “accept as is.”
  4. Explain the constraint factually. Identify whether the issue is availability, timing, underwriting review, cost, contract interpretation, project scope, entity identity, technical delivery, or another operational fact.
  5. Collect professional input. For policy, limit, endorsement, or issued-evidence questions, obtain an accurate response from the licensed insurance professional.
  6. Define the alternative evidence. Name the actual certificate, endorsement, policy excerpt, schedule, letter, renewal evidence, or other document proposed. Do not call a document equivalent unless the authorized decision maker says so.
  7. Identify the decision owner. Ask who can approve the exception and whether legal, procurement, risk, contract, or project management review is required.
  8. Set a response deadline. Connect the request to mobilization, award, renewal, delivery, or another real milestone rather than inventing urgency.

A strong record also includes the request date, current status, supporting source label, requested effective period, conditions, and next action. Use limited neutral identifiers. Do not paste confidential contract pages, policy numbers, personal data, credentials, or entire email threads into a browser tool.

Build the decision record

Keep proposal, availability, decision, and conditions separate.

Track up to ten exception items with sources, dates, decision owners, written outcomes, next actions, copy, print, and private CSV export.

Create an exception record

A seven-part exception request

Part Question it answers Example structure
Project and source Which requirement is being discussed? Project reference, exhibit V04, section 7.2
Requirement What does the current writing say? Exact short paraphrase plus source reference
Requested exception What specific change is proposed? Accept identified alternative evidence through a stated date
Reason Why is the request being made? Issuer confirms requested endorsement is under review
Available evidence What can actually be supplied? Current certificate and named issued endorsement
Decision requested What must the client answer? Accept, decline, request more information, or redirect
Timing and conditions For how long and subject to what? Through mobilization, with replacement evidence due on date

Neutral request template

“For [project], the current written source [title/version/date/section] requests [one item]. The licensed insurance contact has advised [factual availability or review status]. We request the client’s authorized review of [specific exception or alternative]. Available supporting evidence is [document labels]. Please record whether the proposal is accepted, declined, requires more information, or must be reviewed by another authority, including any conditions, effective period, and follow-up date. This request does not represent the exception as approved.”

Do not hide the unresolved gap

The exception record should keep the original requirement visible beside the proposal. Replacing the requirement text with the proposed alternative makes later reviewers unable to see the difference. It can also cause a package to appear complete when the client has not made a decision.

Likewise, do not rewrite an agent’s response. Preserve whether evidence is available, unavailable, pending underwriting, possible only with policy change, or not confirmed. “Agent reviewing” is not “approved,” and “certificate issued” is not “client accepted.” Each event belongs in a separate field or status.

Common exception categories

  • Limit: a requested value differs from the current policy limit.
  • Party or status: an entity, additional-insured request, or certificate-holder instruction needs clarification or alternative treatment.
  • Endorsement or provision: requested evidence is unavailable, pending, or different in form.
  • Evidence format: the underlying evidence exists but the client requests another document or wording.
  • Timing or renewal: evidence will change after a policy renewal, project phase, or underwriting action.
  • Delivery or portal: the issue is technical rather than substantive and may require a temporary route.
  • Contract or legal: enforceability, hierarchy, or risk allocation requires qualified review.

After the client responds

Record the response exactly and link it to its source. If accepted, capture the authorized decision owner, response date, conditions, effective period, affected project or scope, required alternative evidence, and next review date. If declined, preserve the reason if provided and assign the next action. If more information is requested, create focused owner rows rather than treating the whole proposal as pending.

An accepted administrative exception does not modify the insurance policy. It also may not amend the contract unless the authorized contract process says it does. Conversely, an issuer’s ability to provide an endorsement does not automatically mean the client accepts the rest of the package. Keep commercial, legal, insurance, and workflow outcomes separate.

Warnings that deserve attention

  • “Accepted” or “declined” has no response date or decision source.
  • The named decision owner is the agent for a client requirement.
  • A policy-specific feasibility statement lacks licensed issuer review.
  • The request date predates the source or the response predates the request.
  • The record contains broad claims such as “fully compliant” or “coverage guaranteed.”
  • Two identical requirements show inconsistent decisions.
  • An accepted exception has no conditions or effective period even though the proposal is temporary.
  • A pending item is presented in the submission package as resolved.

Frequently asked questions

Can an insurance agent approve an exception?

The agent can explain policy and evidence availability. The client or other authorized contract decision maker determines whether its requirement is accepted, changed, or waived.

Can a portal status approve an exception?

Only if the organization explicitly identifies that status and user as the authorized decision source. A technical upload success is not an exception decision.

Should I call it a waiver?

Use the term the authorized source uses. “Exception request” is safer during review because “waiver” may imply a legal effect that has not occurred.

What if the decision is verbal?

Record it as unconfirmed and request a written source through the approved channel. Do not upgrade a conversation into final approval.

Does acceptance prove coverage?

No. Client acceptance is an administrative or commercial decision; policy terms and actual facts control coverage.

Sources and scope

This exception framework is original administrative guidance. Actual authority, enforceability, insurance availability, and contractual effect depend on the written agreement, policy, jurisdiction, and authorized professionals.