AI Vendor Breach Response Plan Template

If a supplier tells you that business information may have been exposed, it is normal to feel unsure about what happens next. Most small and medium businesses have security procedures for their own systems but no separate process for an incident inside an AI vendor. This guide explains how to organise the first response, gather the facts, make notification decisions with appropriate advice and record what your business did.

The plan is designed for incidents involving an AI supplier, such as a writing assistant, meeting recorder, chatbot, recruitment platform, analytics service or software feature that processes information outside your own systems. It can sit beside your broader cyber incident response plan. The difference is that your business may not control the affected infrastructure, so the quality and speed of the vendor's answers become central to your response.

What an AI vendor breach looks like in a small business

Alex manages a 25-person marketing agency. The agency uses an AI copywriting service to draft campaign ideas and stores client briefs in the vendor's workspace. One morning, the vendor emails to say an unauthorised party accessed part of its environment and some customer content may be involved.

Before the agency had a plan, the first two days would have been spent working out who owned the issue, searching contracts, asking staff what they uploaded and debating whether clients should be contacted. After building the plan, Alex has a ready document naming the response lead, the technical contact, the person responsible for client communications and the adviser who will review notification questions. The team can start checking scope within minutes rather than inventing a process during the incident.

An AI vendor incident may involve more than names and email addresses. The exposed material could include prompts, uploaded documents, meeting transcripts, generated outputs, access tokens, usage logs or confidential business instructions. It may also affect the integrity or availability of the service, even when there is no confirmed disclosure of personal information.

Why a separate vendor response plan matters

Your normal IT response may not cover the main problem. When a laptop is compromised, your team can isolate it, reset credentials and inspect logs. When the incident is inside a supplier, you depend on that supplier to contain the event and explain what happened. Your job is to protect your organisation while testing whether the vendor's information is complete enough for business, contractual and regulatory decisions.

A written plan reduces four common delays:

• Ownership delay: nobody knows who can make decisions or speak to the vendor.
• Scope delay: the business cannot quickly identify which staff, clients, projects or data types used the service.
• Communication delay: staff send inconsistent messages or contact customers before facts are checked.
• Evidence delay: important emails, screenshots, contracts and decision notes are scattered or lost.

The plan should not assume every vendor notice is a reportable breach or that every affected person needs immediate contact. Those questions depend on the facts, the jurisdictions involved, contractual commitments and professional advice. The purpose of the plan is to make sure the right facts reach the right decision-makers quickly.

What regulators and security authorities say

Official guidance generally supports preparing incident roles, preserving information, containing risk, assessing impact and documenting decisions. The details differ by country and by the type of information involved.

For organisations handling data connected with people in the European Economic Area, the European Data Protection Board explains that personal data breaches should be assessed under the General Data Protection Regulation, including whether notification to a supervisory authority or communication to affected people is appropriate. Its guidance also stresses documenting breaches and the reasoning behind notification decisions. See the EDPB personal data breach notification guidance and its small business data breach guide.

In the United States, the Federal Trade Commission's business guidance recommends securing operations, fixing vulnerabilities, preserving evidence, working with relevant specialists and considering notification obligations under applicable laws. See the FTC's Data Breach Response: A Guide for Business.

The US National Institute of Standards and Technology treats incident response as part of ongoing cybersecurity risk management, not a document used only after an event. Its current publication, NIST SP 800-61 Revision 3, describes preparation, detection, response, recovery and improvement as connected activities.

The EU AI Act may create additional incident-related duties for certain providers and deployers of high-risk AI systems, but it does not replace privacy, cybersecurity, sector or contract analysis. The European Commission's official AI Act overview explains the risk-based framework. Businesses should confirm which rules apply to their role and use case rather than treating every AI product as legally identical.

AI vendor breach response plan template

Copy the template into your policy system, shared drive or incident-management platform. Replace the bracketed fields and test the contacts before approving it. Keep a clean master copy so the team can open a fresh incident record whenever a vendor notice arrives.

1. Plan details

Plan owner: [name and role]
Approved by: [name and role]
Effective date: [date]
Review date: [date]
Applies to: [business units, locations and AI services]
Related documents: [cyber incident plan, privacy policy, vendor register, business continuity plan, communications plan]

2. Activation criteria

Activate this plan when an AI vendor, reseller, integration partner, insurer, regulator, customer, employee or security researcher reports a suspected or confirmed event that may affect:

• information entered into, uploaded to or generated by an AI service;
• user accounts, credentials, tokens or integrations connected to the service;
• the confidentiality, integrity or availability of business or customer information;
• the reliability of outputs used in business decisions;
• contractual, regulatory, professional or insurance commitments.

3. Response team and authority

Incident lead: [name, mobile, backup]
Executive decision-maker: [name, mobile, backup]
IT or security contact: [name/provider, contact details]
Privacy or legal adviser: [name/firm, contact details]
Insurance contact: [policy and hotline]
Client or customer communications lead: [name]
Staff communications lead: [name]
Vendor contact: [account manager, security contact, emergency channel]

The incident lead may open the response record, assign actions, request information from the vendor and schedule briefings. Decisions about external notification, public statements, service termination or acceptance of material residual risk require approval from [role].

4. First-hour checklist

1. Record when and how the business first learned of the incident.
2. Save the vendor notice, email headers, portal messages, screenshots and linked documents.
3. Confirm the vendor contact through a known channel before sharing sensitive information.
4. Open a restricted incident folder and decision log.
5. Notify the incident lead, executive decision-maker, IT or security contact and relevant adviser.
6. Identify the affected AI service, accounts, integrations and business teams.
7. Consider temporary protective steps, such as pausing uploads, disabling integrations, rotating credentials or moving urgent work to an approved alternative.
8. Tell staff not to speculate or contact customers unless authorised.
9. Check insurance notice conditions and important contract clauses.
10. Set the time for the next response-team update.

5. Questions to send the vendor

Ask the vendor for written answers and update them as new facts emerge:

• What happened, and when did it begin and end?
• When did the vendor detect the incident and when did it notify us?
• Which tenant, workspace, accounts, regions or systems were affected?
• What data categories were accessed, altered, deleted or made unavailable?
• Were prompts, uploads, outputs, logs, credentials, tokens or model-training data involved?
• Can the vendor identify the specific records or users connected to our account?
• Was information encrypted, and were encryption keys affected?
• Was data copied or only viewed? What evidence supports the answer?
• Which subprocessors or infrastructure providers were involved?
• What containment and remediation steps have been completed?
• Has the vendor engaged independent investigators or notified authorities?
• What actions should our business take now?
• When will the next written update and final incident report be provided?

6. Business impact assessment

Document the information available, including uncertainty. Do not wait for perfect answers before recording the current position.

• People affected: [employees, clients, prospects, suppliers, other individuals]
• Information involved: [contact details, confidential documents, health, financial, employment, identity or authentication data]
• Business material involved: [campaign plans, source code, pricing, contracts, strategy, intellectual property]
• Volume and sensitivity: [known estimate and confidence level]
• Potential harm: [fraud, impersonation, confidentiality loss, discrimination, safety, reputational or operational impact]
• Operational effect: [service outage, corrupted outputs, delayed work, manual workaround]
• Existing protections: [encryption, access controls, redaction, retention settings, contractual controls]
• Jurisdictions and contracts: [locations of affected people, governing law, customer terms, sector rules]

7. Notification decision record

Decision date and time: [date/time]
Decision-makers and advisers: [names]
Authorities considered: [regulators, law enforcement, sector bodies]
People or organisations considered: [clients, customers, staff, partners, insurers]
Decision: [notify now, notify later pending facts, no notification at this stage]
Reasoning: [facts, risk assessment, source guidance and advice relied upon]
Deadline or next review: [date/time]
Approved message and channel: [link or location]

Keep the decision record even when the conclusion is not to notify. A clear record helps show which facts were available, what guidance was reviewed and when the decision will be reconsidered if the vendor's account changes.

8. Communications controls

Use one approved factual summary and update it as evidence improves. Separate confirmed facts from assumptions. Messages should explain what happened, what information may be involved, what the organisation is doing, what the recipient can do and where future updates will appear. Avoid promising that there is no risk while an investigation is incomplete.

Internal holding message: We are assessing a reported security incident involving [vendor/service]. Please stop [specified activity] and preserve any related emails or records. Do not contact clients or post about the incident. Send questions to [contact]. We will provide the next update by [time].

9. Recovery and vendor review

Before normal use resumes, record why the service is considered safe enough for the intended work. Check account security, integrations, retention settings, data exports and any vendor remediation. Decide whether sensitive workflows should remain paused, move to another tool or return with tighter controls.

Complete a vendor review covering the incident timeline, quality of communication, contract performance, root cause, independent assurance, corrective actions and any change to the vendor's risk rating. Update the AI register, vendor register, staff guidance and contract requirements where needed.

10. Post-incident review

Within [number] business days of closure, hold a short review and record:

• what worked and what caused delay;
• which information was hard to find;
• whether roles and authority were clear;
• whether vendor and adviser contacts worked;
• which controls could reduce the likelihood or impact of a repeat event;
• who owns each improvement and its due date.

Close the incident only after improvement actions have owners. A response plan that never changes after a real incident will preserve the same weaknesses for the next one.

How to adapt the template without making it too complicated

For a business with fewer than 50 staff, the named response team may be only three or four people. One person can hold several roles, provided authority and backups are clear. The plan should fit the way the business actually works, not imitate an enterprise structure that nobody will follow.

Start with the AI services that hold the most sensitive or commercially important information. Link each service to an owner, vendor contact, contract, data categories, user list and approved use. This turns the response plan into something the team can use immediately instead of a generic policy with no operational detail.

Test the plan with a 30-minute exercise. Give the team a fictional vendor notice, then ask them to identify the service owner, affected data, first protective action, adviser and next update time. The exercise will usually reveal missing phone numbers, unclear authority or a vendor register that has not been maintained.

Common mistakes to avoid

• Treating the vendor's first email as the final facts. Early notices often change. Maintain a timeline and request written updates.
• Focusing only on personal data. Confidential client material, access tokens, intellectual property and unreliable outputs can create serious business risk even when privacy notification rules do not apply.
• Deleting evidence while trying to clean up. Preserve notices, logs and decision records before changing systems where practical.
• Letting every manager contact the vendor separately. Use a single lead and a consolidated question list.
• Sending reassurance too early. State what is known, what is not yet known and when the next update will arrive.
• Ignoring the contract and insurance policy. Both may contain notice steps, cooperation duties, approved providers or deadlines.
• Resuming the service without a recorded decision. Document the remaining risk, safeguards and approval.

Frequently asked questions

Related reading: our free AI acceptable use policy template and our AI governance by region.

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.

What is an AI vendor breach response plan?

It is a documented process for responding when an external AI service has a suspected or confirmed security, privacy or availability incident. It assigns roles, sets initial checks, organises evidence and supports consistent decisions about containment, communication and recovery.

Is this different from a normal cyber incident response plan?

It is usually a focused part of the broader plan. The main difference is that the affected systems may be controlled by a supplier, so your organisation needs a process for obtaining reliable facts, checking contracts and protecting its own accounts and data while the vendor investigates.

Does every AI vendor breach need to be reported to a regulator?

No universal rule applies to every incident. The answer depends on the information, risk, affected people, jurisdictions, sector rules and your organisation's role. Record when you became aware of the incident and obtain advice from the relevant authority or adviser.

Should we tell customers as soon as the vendor contacts us?

Not automatically, but the question should be assessed promptly. A rushed message based on incomplete facts can mislead people, while an unnecessary delay can also create harm. Use the notification decision record to document the facts, advice, timing and approved message.

What if the vendor will not provide enough information?

Record each request, response and gap. Escalate through security, legal, account-management and contractual channels, while taking protective steps based on the information you do have. The vendor's lack of clarity is itself relevant to the risk and future supplier review.

How often should the plan be tested?

Test it at least whenever major AI services, key staff, contracts or regulatory exposure change, and after any real incident. A short scenario exercise is enough to check contacts, authority, records and the team's ability to identify affected data.