What Incident Evidence Should You Require Before an AI Vendor Handles Client Work?

Before an AI vendor handles sensitive client work, a professional-services firm should establish who will respond to an incident, what evidence the vendor can provide, how the firm will be notified and who can contain the affected service. A written policy is useful, but it does not by itself show that people can carry out the process.

What incident scenarios should you discuss?

Ask the vendor how its incident process would address AI-related scenarios as well as ordinary security incidents. Examples to discuss may include prompt injection, unexpected agent tool use, attempts to extract model information or AI-assisted activity after an intrusion. Treat these as due-diligence prompts, not evidence that a particular vendor has experienced an incident or can prevent one.

For each scenario, ask what signals the vendor monitors, who assesses severity and what records could be preserved. Relevant evidence may include detection time, affected systems, actions taken and the people responsible. Consider how an event could expose client material, cause an unauthorised action or affect the reliability of work.

How can you assess whether the response process is workable?

Request a representative incident record, a redacted runbook or a summary of a response exercise. Check whether it shows how an event is detected, escalated, contained and reviewed, and whether actions and owners are recorded. Ask when the process was last exercised and what changed as a result.

Confirm that escalation contacts are named, reachable through an agreed channel and backed up when unavailable. If sensitive details cannot be shared, agree what summary or demonstration would let your team assess the process without requesting confidential information.

What should your firm agree with the vendor?

Document the notification timing and channel in the relevant service terms or another binding service document. Agree which suspected or confirmed events trigger notice, what an initial notice should contain and how updates will be handled as facts develop. Do not assume one notification timeline applies to every service or situation.

Clarify who can suspend access, disable an affected feature or tool, isolate data and restore service. Record responsibilities on both sides, including who coordinates the response and who considers client communications where appropriate. Agree what incident evidence can be shared, how it will be protected, and how a written review will capture impact, cause, remediation and follow-up owners.

When should you pause a planned deployment?

Consider pausing sensitive client use while specific gaps are resolved if there is no accountable vendor contact, no workable escalation route, unclear notification arrangements or no agreed way to contain an affected feature. The same applies if your own team does not know who can disable access or preserve relevant records.

Record the open questions, assign owners and agree what evidence will close each gap. This makes the decision and next steps visible without treating a pause as a conclusion about the vendor’s overall security.

Assess your AI vendor controls with Pattrn Data

Pattrn Data’s AI Risk & Efficiency Audit can help professional-services teams review AI use, identify control and evidence gaps, and agree practical next steps before implementation.

Source and provenance

Prepared in response to the question, “What is the vendor’s incident response process for an AI-layer compromise?” The due-diligence scenarios were informed by DeepInspect’s AI vendor security questionnaire article. The scenarios are presented as questions to discuss, not as claims about any specific vendor.