[Note from Laura: One of my goals for the How to Contract webinars is to extract the best and most insightful parts and share them in a usable format. This article is my first effort to do so. Let me know what you think by hitting reply or messaging me on LinkedIn.]
If you see AI incident response provisions in your contract, you’ll need to evaluate what they say, determine what to change, and be able to explain your reasoning to your client and the other side. Do you feel well-prepared to do just that?
How to Contract webinars include asking two contracting experts about specific provisions. We recently asked Aparna Williams and Annmarie Giblin to identify the problems with an AI-drafted version of an AI incident response clause. This article outlines four major problems with the AI-drafted language and ways to fix it. They also shared other eight essentials things to check before you sign off on one of these provisions.
This article has three parts:
4 Problems + 4 Fixes
Here’s the starting draft of an AI incident response provision: “Vendor shall investigate and respond to security incidents in accordance with its standard incident response procedures. Upon confirmation of a security incident affecting customer data, vendor shall take commercially reasonable steps to investigate the cause, mitigate any ongoing harm, and restore affected systems to normal operation. Vendor shall provide customer with periodic updates regarding the status of its investigation and response efforts as vendor deems appropriate. Vendor's incident response obligations shall not require vendor to disclose any information that vendor determines in its sole discretion would compromise its security posture, ongoing investigation, or relationships with law enforcement.”
Let’s break it down and review the issues with each part.
Vendor Must Investigate and Respond
Vendor shall investigate and respond to security incidents in accordance with its standard incident response procedures.
The Problem: You have no idea what these procedures say. They are not published. They may live in an internal document that changes without notice. If this ends up in a dispute, you are hiring experts to argue about what "standard" meant at the time of the incident.
The Fix: Customers may want to attach the vendor's actual incident response plan as an exhibit to the contract. They also may insist on written notice to customer at least 30 days before any material changes take effect. If the vendor resists sharing the plan, request it under NDA. That request itself is informative. A vendor with a mature plan tends to share it. A vendor that refuses may not have one worth seeing.
Vendor Must Mitigate and Restore
Upon confirmation of a security incident affecting customer data, vendor shall take commercially reasonable steps to investigate the cause, mitigate any ongoing harm, and restore affected systems to normal operation.
The Problem: While "commercially reasonable" can work in some settings, many are finding that AI moves too fast. There’s no standard baseline at this point, so this kind of standard is problematic. One speaker noted that "reasonable" may be "one of the first victims of AI speed."
The Fix: Use specific requirements instead. For example, require the vendor to do one or more of the following: (i) initiate and conduct an investigation to identify the cause, (ii) contain and isolate any affected systems, (iii) maintain verified backups and restore customer data from them following the incident, (iv) document steps taken and provide to customer in a written incident summary within [X] days. Focus on precise actions rather than a vague standard subject to different interpretations.
Vendor Must Update Customer
Vendor shall provide customer with periodic updates regarding the status of its investigation and response efforts as vendor deems appropriate.
The Problem: This language gives the vendor a lot of latitude to decide when to notify the customer. Customers can request more detailed or frequent updates, but without more precise requirements in the contract, the vendor isn’t required to do so. This delay could lead to panic, missed regulatory notifications, and failure to meet the customer’s own contractual obligations.
The Fix: Before the fix, I want to first share a warning. It may be tempting, but don’t go to the other extreme with this language. You don’t want to require a vendor to prioritize communication and updates over addressing the problem. That requirement could slow the response and final resolution. Here are the changes suggested by our experts:
Require an initial notice within [X] hours of confirmation.
Use a subjective and objective standard for updates. The subjective standard could be something like what one speaker suggested: provide "meaningful updates on a cadence agreed upon by the parties" to preserve flexibility. The objective standard could be something like “substantive updates no less than every [Y] business days.” The speakers suggested using business days, instead of calendar days. The reason is that attacks frequently occur on Friday evenings or holiday weekends.
Do not require written updates. Instead, require the vendor to deliver updates by phone or video conference call. These written updates during an active incident are problematic. The vendors know that these documents are likely to be used in any litigation so the vendors will share only what is fixed and unchanging, a category that doesn’t include what customers really want to know as the vendor works through its investigation. The reality is that facts could change hourly and getting updated information is more important than creating a written record of the twists and turns that may occur along the way.
Disclosure Exceptions When It Could Compromise an Investigation
Vendor's incident response obligations shall not require vendor to disclose any information that vendor determines in its sole discretion would compromise its security posture, ongoing investigation, or relationships with law enforcement.[
The Problem: The vendor gets to decide unilaterally what information the customer receives about an incident affecting its data. This situation is especially problematic because we are talking about AI. Consider that the decision about what to disclose to the customer may not be made by a human. It may run through the vendor's own AI system or algorithm. Customers have no visibility into that decision and no mechanism to challenge it.
Another Problem: The law enforcement carve-out seems reasonable in theory. Law enforcement does sometimes ask vendors to delay notification. But without tight guardrails, the carve-out could swallow the obligation. The term "ongoing investigation" is broad enough to cover nearly any incident for weeks.
The Fix: Replace sole discretion with narrow, defined carve-outs only. One approach is limit any permitted delay only if (1) law enforcement has an active request in writing directing the vendor to delay notification, or (2) there’s a material risk that disclosure would enable exploitation of an unpatched vulnerability that vendor is actively remediating. In either case, the vendor still has to give the customer written notice that it is withholding information, state the specific basis, and provide a date by which it expects the basis to resolve.
8 Things to Check Before Your Sign
The webinar covering this provision included these eight other strategies for negotiating incident response obligation clauses.
Verify the Plan: Verify what the vendor's incident response plan says before you sign. Any refusal to share the plan should be considered as a potential red flag.
Tabletop Experience: Ask the vendor about any tabletop exercise simulating incidents. If the answer is they haven’t done any, the vendor may not have worked through what a real incident looks like operationally.
Include Incidents That Lock Systems. Confirm the definition of "security incident" covers ransomware that locks vendor systems but has not yet touched your data. If the vendor cannot perform services because their systems are locked, that affects you even if your data is not compromised.
Cover Specific Scenarios. Ensure the definition of “security incident” addresses AI-specific scenarios. An AI agent crossing systems or a model leaking training data may not fit a traditional breach definition.
Know Your Regulatory Requirements. Make sure you are clear about your own regulatory deadlines. Then draft the contract’s deadlines working backward from your own. If you have 72 hours to report, you need vendor notice in 48. If you have 48 hours, you need vendor notice with enough time to develop your own reporting strategy and information.
Name Who Approves Disclosure. Identify a specific role at the vendor who has authority to decide what information gets disclosed. Don’t just say "vendor."
Include as Surviving Provisions. Verify that the provision survives termination. The vendor may not discover the breach until after the contract ends.
Secure Right to Data Return. Make sure there is a right to get a copy of your data back. One speaker called this a "breach bomb": a small provision with enormous practical impact that often gets left out. Without it, vendors may delay or refuse to provide data even when the contract does not explicitly prohibit them from doing so.
A 12-Minute Video Lesson on AI Incident Response Obligations
This 12-minute video clip from How to Contract’s webinar on “Drafting AI Data Security Provisions” discusses how to draft and negotiate incident response obligations in vendor contracts, focusing on what triggers a vendor’s duty to respond and notify, and how AI and supply-chain realities complicate definitions of “security incident.” Aparna Williams and Annmarie Giblin joined Laura Frederick for this webinar in June 2026.
00:00 Incident Response Triggers
00:50 Defining Incidents and Timing
01:49 Vendor Examples and Baselines
02:44 Breach Bombs and Data Return
03:28 Reading the Sample Clause
04:42 Vendor Red Flags and Definitions
06:38 Customer Redlines and Guardrails
09:05 Update Cadence and Practicalities
10:34 Discovery Risks and Flexibility
12:00 Wrap Up Key Takeaways
Everyone: Read this article for the top 10 takeaways from the full webinar.
How to Contract Premium Members: Watch the full webinar recording (included in your membership)
