AI Vendor Breach Response Plan: The Plan, the First Hour, and When It Becomes Your Notification

Once a business has accepted that an AI supplier incident can affect its own data, the harder question is where the supplier’s response ends and the customer’s begins. This reference separates three matters that are often blurred together: an operational response plan, a first-hour record and the jurisdiction-specific test for external notification.

The plan records ownership, evidence and unresolved decisions

The plan is an operational practice document, not a statement of legal duties. Its purpose is to prevent missing facts, unclear ownership and premature public claims while technical investigation and jurisdictional assessment proceed.

A usable plan can contain these fields:

The AI data map matters because an incident may extend beyond chat history. A compromised integration token, retrieval connector or administrator account can connect the vendor incident to systems outside the AI service. The record therefore distinguishes data confirmed as affected from data that was merely accessible in the same environment.

The plan does not create a safe harbour or demonstrate compliance by itself. It is a record structure that can support technical investigation, regulator-facing assessment and later review.

The first hour is for facts and reversible containment

The first-hour checklist is operational practice. It does not replace a contractual procedure, insurer condition, regulator direction or advice for the specific incident.

Containment can create its own operational risk. Switching off an AI service may interrupt customer support, document handling or an automated approval flow, so the log records both the security reason and the business consequence. Reversible actions are easier to review as evidence changes.

A vendor breach becomes the customer’s notification question when its data and legal role are engaged

A vendor announcement alone does not answer whether the customer business has a reportable incident. The common decision sequence is factual: whether the customer’s information was affected, whether the business held, controlled, owned or licensed that information under the applicable framework, and whether the jurisdiction’s notification threshold was reached.

That sequence is a cross-jurisdiction synthesis, not a universal legal test. The formal threshold and the party responsible for assessment or notice differ by region.

Australia: jointly held information can engage both entities

The Australian Information Commissioner’s NDB guidance says an eligible data breach involves unauthorised access, disclosure or loss of personal information, likely serious harm, and no successful remedial action preventing that likely harm. The guidance also says that where entities jointly hold affected information, both may have responsibilities, but one assessment and one notification can cover the group. Crucially, the scheme does not prescribe which entity assesses or notifies, although the Commissioner suggests the entity with the closest relationship to affected individuals may be best placed to notify. OAIC, Part 4 of Data breach preparation and response

The same OAIC guidance states that a suspected eligible breach is assessed reasonably and expeditiously, with all reasonable steps taken to complete the assessment within 30 calendar days. Once reasonable grounds establish an eligible breach, statements and individual notices are addressed as soon as practicable. Those rules do not allow this page to decide whether a particular AI vendor and customer jointly held the information.

European Union: the controller assesses after the processor reports

Under GDPR Article 33, a processor reports a personal data breach to the controller without undue delay. The controller reports to the competent supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to people’s rights and freedoms. Article 34 uses a higher, likely high-risk threshold for communication to affected people. GDPR Articles 33 and 34 on EUR-Lex

The European Data Protection Board says the processor does not first decide the risk threshold for the controller. In principle, the controller becomes aware when the processor informs it, then determines whether regulator or individual notification is engaged. EDPB Guidelines 9/2022

United Kingdom: vendor notice starts the controller’s assessment

The UK Information Commissioner’s Office says a processor informs its controller without undue delay after becoming aware of a personal data breach. The controller then determines whether the breach meets the reporting threshold. For a notifiable breach, the ICO describes notification without undue delay and no later than 72 hours after awareness, with reasons supplied for delay and phased information permitted where the investigation is incomplete. ICO personal data breach guide

This means a supplier’s incident message can start the customer’s assessment clock without proving that notification is required. The roles, affected personal data and risk remain incident-specific.

Canada: control and real risk of significant harm are central

PIPEDA section 10.1 addresses breaches involving personal information under an organisation’s control. It sets a real risk of significant harm threshold and identifies the information’s sensitivity and probability of misuse as assessment factors. Reports to the Commissioner and notifications to affected individuals are made as soon as feasible after the organisation determines that the breach occurred. PIPEDA section 10.1

For outsourced processing, the Office of the Privacy Commissioner says an organisation remains accountable for information transferred to a third-party processor. That makes the customer’s control and outsourcing arrangement relevant even when the technical compromise occurred at the AI vendor. OPC finding on third-party processing accountability

United States: the answer depends on state and sector rules

The United States does not provide one general notification threshold or deadline for every business breach. The Federal Trade Commission’s business guide directs organisations to examine applicable state and federal rules, noting that state laws define notice content and that sector-specific requirements may also apply. FTC Data Breach Response guide

Vendor and customer roles can also be expressed differently by state. California Civil Code section 1798.82, for example, distinguishes a business that owns or licenses covered data from a person or business that merely maintains it, with the maintainer notifying the owner or licensee after discovery. California Civil Code section 1798.82 This example does not determine the position in another state or under a sector-specific federal rule.

The sources do not resolve the business’s particular incident

The cited authorities define roles, thresholds and timing language, but they do not establish which records an attacker accessed in a specific AI environment. They also do not settle disputed contract roles, the residence of every affected person, whether encryption remained effective or how several overlapping laws interact.

Those gaps belong in the incident log as unresolved facts. A regulator, privacy professional or lawyer may be needed where the applicable jurisdiction, controller relationship, harm assessment or deadline remains unclear. The plan supports that assessment but does not make it.

Questions for the vendor and the business’s adviser

A structured question set keeps the inquiry focused on facts rather than reassurance:

• Which tenant, workspace, account, model, plug-in or integration was affected?
• Which prompts, files, retrieval sources, outputs, logs, credentials or metadata were accessed, altered, lost or unavailable?
• Is the scope confirmed by logs, inferred from architecture or still under investigation?
• When did the incident begin, when was it detected and when did the vendor first consider each customer affected?
• Did any subcontractor or subprocessor handle the affected information?
• What containment has been completed, and what customer-side containment remains available?
• Which entity is described as controller, processor, holder, owner, licensee or maintainer in the contract and applicable law?
• Which countries or states are connected to the affected people and business operations?
• Has the vendor contacted any authority, and does that notice include or exclude the customer business?
• Which facts are still missing for the applicable risk or harm test?

Related reading: free AI acceptable use policy template, free AI register template, shadow AI audit checklist, guide to assessing AI risk, AI data residency comparison, guide to liability for AI-generated content, and AI governance by region.

Related reading: Claude AI Review: Pricing, Features, and Business Verdict and Is Claude Pro Worth It? An Honest Assessment for Business Users.

Free tools: AI Privacy Risk Scorer to score your current AI tool setup against data-privacy best practice | AI Compliance Checker to check whether your AI tools meet your compliance obligations.

Try our free AI Policy Generator to generate a customised AI policy for your business.

Methodology and source date

Need to Know AI reviewed primary legislation and guidance from the OAIC, EUR-Lex, EDPB, ICO, Canada’s Justice Laws service, the Office of the Privacy Commissioner of Canada, the FTC and the California Legislature on 4 September 2026. The operational plan and first-hour checklist are editorial practice, clearly separated from attributed regulatory summaries. No vendor pricing, product capability or incident claim was assessed.

Next reference