How to Write an AI Acceptable-Use Policy for Cyber Insurance
Security Intermediate 5 min read

How to Write an AI Acceptable-Use Policy for Cyber Insurance

Write an AI acceptable use policy for cyber insurance renewal: approved tools, banned data, human review, reporting, exceptions and versioned evidence.

Published: October 30, 2026 • Updated: October 30, 2026
AI governancecyber insuranceacceptable use policysecurity policy

An AI acceptable-use policy for cyber insurance renewal is a short, owned, versioned document that tells staff which AI tools are approved, which data must never go into them, when a human must review output, and how to report a mistake. Some insurers and brokers now ask whether such a policy exists, but carrier wording varies. Write the policy for your real risks, then have your broker or counsel check how it maps to the application in front of you.

This guide expands the governance step of our AI questions in cyber insurance renewals checklist. The policy depends on knowing what you run, so build the AI tool inventory first, and pair it with a record of AI data flows and vendor controls.

Why an AI policy comes up at renewal

Advisers report that governance questions are appearing, not that every carrier asks them. Northstar IT Advisory wrote in October 2026 that many 2026 questionnaires ask what AI tools are in use, what data goes into them, and what governance sits around them. ACA Group lists governance policies among the documentation insurers increasingly request, alongside inventories, risk assessments and descriptions of human oversight. Insurance Business reported in August 2026 that there is no standard AI question set, and that the market is working through exclusions and endorsements instead.

The practical reading: a written policy is one of the few AI governance artefacts that is cheap to produce and easy to evidence, and it is useful whether or not your form asks about it. It does not secure a discount, cover or a renewal on its own, and nothing here should be read as a promise of any of those.

What should an AI acceptable-use policy cover?

It should cover approved tools, prohibited data, human review of output, access and accounts, incident reporting, exceptions, training and acknowledgement. Keep it short enough that staff will read it, and put detail in linked procedures.

Scope and approved tools

State who the policy applies to (employees, contractors, anyone using company data) and what counts as an AI tool, including AI features inside software you already use. Then list approved tools by name and account tier, or point to the maintained inventory as the authoritative list. A tool not on the list is not approved until it goes through review.

Prohibited and restricted data

This is the clause underwriters care about most. Daniel Winn of Jensten London Markets told Insurance Business the core concern is staff feeding sensitive or regulated information into public large language models outside the client's environment. Map your existing data classification to three outcomes:

  • Never enter: credentials and secrets, payment card data, health records, and other regulated categories you hold.
  • Approved tools only: customer personal data, contracts, source code, financial records, and only in tools whose contract and settings you have reviewed.
  • Allowed: public information and material you would publish anyway.

Human review of AI output

Say where a person must check output before it is relied on: anything sent to customers, legal or financial statements, code merged to production, and decisions about people. For any tool that can take actions, such as writing to systems or approving workflows, name the human approval step. ACA singles out AI that acts without a traditional breach as a harder coverage question.

Access and accounts

Require company accounts under the business agreement, with SSO where the vendor supports it, and prohibit personal accounts for company work. Removing access when someone leaves should follow your normal joiner, mover and leaver process.

Incident reporting

Tell staff exactly what to report and to whom: prohibited data entered into a tool, an unapproved tool connected to company accounts, or harmful output that reached a customer. Make reporting blame-free for honest mistakes, or you will not hear about them. Route reports into your existing incident process.

Exceptions

Allow exceptions only through a named approver, with a reason, any extra controls, and an expiry date, and keep a register. Northstar's renewal advice is that a "Yes, except for..." answer needs to be written down, not glossed over, and the exception register is where that record comes from.

How do you prove staff follow the AI policy?

Keep evidence that the policy was communicated, understood and enforced: training records, signed or recorded acknowledgements, and logs from any technical control that backs the policy up. A policy with no acknowledgement trail is hard to evidence.

NIST's AI Risk Management Framework, under GOVERN 2.2, describes personnel and partners receiving AI risk management training so they can perform their duties consistent with policies and procedures. In practice that means:

  • Short training at onboarding and when the policy changes, with completion records.
  • An acknowledgement captured in your HR or learning system, tied to the policy version.
  • Technical backing where it exists, such as blocking unapproved AI domains or routing approved use through a data loss prevention control, with exported settings as evidence.

Version control and evidence

Treat the policy like any controlled document:

  • A named owner and an approver.
  • A version number, an approval date and a next review date.
  • A change log stating what changed and why.
  • Retained prior versions, so you can show what was in force on a given date.

That last point matters if a question ever turns on what staff were told at the time of an incident.

Who should review the AI policy before renewal?

Your broker should check how the policy relates to the actual application questions, and counsel should review any legal or regulatory wording. Carrier wording varies, so a policy written to match one insurer's form may not match another's.

Ask specifically whether the application or policy defines "AI" in a way your document should mirror, and whether any AI-related exclusion, sublimit or endorsement depends on controls your policy describes. Disclosure duties also differ by jurisdiction; Northstar points to the UK Insurance Act 2015 duty of fair presentation as one example. This article is not legal advice.

A one-page outline to start from

  1. Purpose and scope
  2. Definitions, including AI features in existing software
  3. Approved tools and account tiers (or a link to the inventory)
  4. Data rules: never, approved tools only, allowed
  5. Human review requirements
  6. Access and account rules
  7. Reporting mistakes and incidents
  8. Exceptions process
  9. Training and acknowledgement
  10. Owner, version, approval date, review date

Sources