The Law Firm AI Incident Response Plan Your Cyber Insurer Now Expects

What counts as an AI incident at a law firm

An AI incident is any event where an AI tool causes or enables a confidentiality, integrity, or professional-responsibility failure. The common types are privileged data entering an unapproved tool, a prompt-injection or manipulation attack, an AI-generated error reaching a court, an agentic tool acting without authorization, and a breach at an AI vendor holding your data. Each triggers a different response, so the plan must name them ^[4].

Defining the incident types in advance is half the plan, because you cannot respond to a category you never named. The list below covers the failures that are specific to AI, on top of the ordinary breaches a firm already plans for.

The response steps, in order

Run six steps in sequence: detect and triage the event, contain it by cutting the tool's access or use, assess whether privileged data was involved, notify the required parties, remediate the cause, and document everything in a record you can later prove. The privilege assessment is the step a generic IT runbook omits, and it drives every decision that follows in a law-firm context ^[1][3].

The sequence matters because acting out of order can make an AI incident worse, for example notifying before you have contained the exposure or assessed privilege. Follow the same ordered steps every time so the response is consistent under pressure.

Detect and triage: confirm what happened and how severe it is. Contain: revoke the tool's access, disable the account, or stop the workflow so the exposure cannot grow. Assess privilege: determine whether privileged or confidential client data was involved, because that governs notification and potential waiver analysis. Notify: inform the parties the situation and your obligations require, in the right order. Remediate: fix the underlying cause, whether a permission gap, an unapproved tool, or a missing control. Document: capture the timeline, decisions, and evidence in a durable record.

This structure follows the widely used incident-handling lifecycle that standards like NIST's incident guidance describe, adapted so the privilege assessment sits where a law firm needs it ^[3]. The written incident-response plan your cyber insurer already expects is the container this AI-specific process fits inside.

What your cyber insurer expects the plan to include

Insurers expect a written plan with defined roles, an incident taxonomy, response steps, notification procedures, and evidence it is tested. A written incident-response plan is already a common condition to bind or renew, and underwriters are extending their questions to AI governance. A plan that names AI incident types and shows a recent test answers those questions and strengthens both your coverage and your response ^[1].

Cyber insurers moved from accepting attestations to expecting proof, and a written incident-response plan sits near the top of most applications. The firms that renew smoothly are the ones that can show the plan exists, assigns roles, and has been exercised, not just drafted.

Extend that plan to AI explicitly. Name the AI incident types, define who leads the response and who makes the notification call, and keep evidence of a recent tabletop exercise. Underwriters increasingly ask about AI use and governance, and a plan that already addresses AI incidents turns a hard application question into a short answer. It also positions the firm better if a claim ever arises, because the insurer can see the controls were real.

Notification and privilege during an AI incident

Notification during an AI incident is governed by the same duties as any data event, plus the privilege dimension. Depending on the facts, you may owe notice to affected clients, to a regulator under a state breach-notification statute, and in some situations to a court or bar. Engage breach counsel early, because whether and how you notify, and how you protect privilege in the investigation, are legal calls, not IT calls.

The notification analysis is where an AI incident becomes a legal matter rather than a technical one. Whether notice is owed, to whom, and on what timeline depends on the data involved and the jurisdictions in play, and getting it wrong carries its own liability.

Several notification paths can apply at once. A client whose confidential information was exposed may be owed notice under your professional duties. A state breach-notification statute may require notice to affected individuals and sometimes a regulator, on a defined timeline that varies by state. In a litigation context, a court order or candor duty may require disclosure. Because these overlap and the timelines differ, engage breach counsel at the start and structure the investigation to protect privilege where possible.

This is one area where you should not improvise. Confirm the specific notification requirements in your jurisdiction with counsel, since state breach-notification statutes and bar reporting duties vary and change, and the right sequence depends on the facts of the incident.

Testing the plan before you need it

Test the plan with a tabletop exercise at least annually, walking a realistic AI incident through every step with the actual responders. Untested plans fail at the first real event because roles are unclear and steps were never rehearsed. A short, scenario-based exercise surfaces the gaps cheaply, satisfies what insurers want to see, and builds the muscle memory that makes the real response fast and consistent.

A plan that has never been exercised is a document, not a capability. The gap between the two shows up at the worst possible time, when a real incident hits and no one is sure who decides whether to notify.

Run a tabletop at least once a year. Pick a realistic scenario, a lawyer pasted a privileged draft into an unapproved consumer AI tool, or an agentic assistant sent something it should not have, and walk the actual responders through detection, containment, the privilege assessment, notification, and documentation. Capture what was unclear and fix the plan. Keep the record of the exercise, both because it improves the response and because it is the evidence insurers and, if it comes to it, courts want that the firm took its obligations seriously.

The incidents nobody reports, and why that is the real gap

Most AI incidents at a firm are never escalated, because the person who caused one does not recognize it as an incident or fears the consequence of saying so. A plan that only works when someone raises their hand is a plan that fires late. The fix is definitional clarity plus a reporting path that does not punish the reporter.

A lawyer who pastes a client document into a consumer chatbot to summarise it has caused a confidentiality incident. Most will not describe it that way. They will describe it as having used a tool to save time, and nothing about the experience signals that a threshold was crossed, because no alert fires and no system objects.

That is why definition does more work here than escalation procedure. If the policy says "report AI incidents" without saying what one is, people apply their own threshold, and their threshold is almost always higher than the firm's. Name the categories concretely: client data entered into an unapproved tool, AI output reaching a filing or a client without verification, output that turned out to be wrong after it was relied on, and any indication that a tool surfaced material the user should not have seen.

The second barrier is consequence. A lawyer weighing whether to report an incident they caused is weighing professional exposure, and if the firm's only experienced response to error is discipline, the rational move is silence. Firms that get reliable reporting tend to have said explicitly, in advance, that prompt self-reporting is treated differently from a concealed problem discovered later.

That distinction is not merely cultural. The duty to correct a false statement of law to a tribunal runs from the moment you know, and a firm cannot discharge a duty it has not been told about. Silence converts a contained technical problem into a candor problem with a longer timeline and a worse record.

A practical test of whether reporting works: ask when the last AI incident was reported. A firm using AI at scale that has never had one reported does not have a clean record, it has a reporting problem.

Who to call, decided before the incident

The most time lost in an incident goes to figuring out who decides. Name the roles in advance: who triages, who makes the notification call, who contacts the carrier, and who speaks to the client. Cyber policies frequently require prompt notice and may direct you to panel counsel and approved vendors, so calling the carrier early protects coverage as well as the response.

Incident plans usually specify what to do and leave who does it implicit. Under pressure, that gap is where hours go: someone has to decide whether this is serious, and if no one owns that decision, it gets escalated sideways until a partner is reached who was not expecting the question.

Four roles cover most of it. A triage owner who makes the initial severity call and can contain the tool or account without seeking approval. A notification decision-maker, which is a legal judgment rather than a technical one, and belongs with someone who can weigh the client, regulatory, and court obligations together. A carrier contact who notifies the insurer. And a client contact, normally the relationship partner, so the client hears about it from the person they know.

The carrier call deserves particular emphasis because it is the one most often made late. Cyber policies commonly require prompt notice as a condition, and many direct the insured to panel counsel and approved forensic vendors. A firm that engages its own vendor first, then notifies the carrier, can find that spend disputed. Calling early costs little and protects the coverage the plan assumes.

Write the names and numbers into the plan itself, including out-of-hours contact, and re-check them on a schedule. A contact list that has not been reviewed since a departure is the failure mode that turns a good plan into a phone tree.

Finally, decide in advance how the response itself will be documented. Notes taken during an incident may be discoverable, and how the investigation is structured can affect what protections apply. That is a legal question worth settling before an incident rather than during one, in consultation with counsel who handles the firm's own exposure.