Vendor AI Incident Notification Requirements
Require AI vendors to notify the organization of incidents affecting their AI systems within defined timeframes and with specified information.
Objective
Ensure the organization receives timely notice of vendor-side AI incidents that may affect its operations, compliance obligations, or customers.
Maturity Levels
Initial
No vendor notification requirements exist; incidents are discovered through service disruption.
Developing
Notification is required in general terms but timeframes and required information are not specified.
Defined
Contracts specify incident notification timeframes, trigger conditions, and required information for all AI vendor relationships.
Managed
Vendor notification compliance is tracked; late or incomplete notifications are escalated.
Optimizing
Notification requirements are reviewed against evolving regulatory obligations; vendors are assessed on historical notification quality.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Vendor contract clauses or SLA terms specifying notification obligations, timelines, and content requirements for AI incidents
- —Actual vendor notification records for incidents that met contractual notification criteria, with timestamp and acknowledgment
- —Escalation records for vendor notifications that were delayed or incomplete, with resolution
- —Vendor incident register tracking notifications received from vendors, status, and follow-up actions
- —Annual contract review records confirming notification obligations remain adequate and consistent with regulatory requirements
Implementation Notes
Key steps
- Define notification trigger conditions specifically: model failures, security breaches, data exposure, discovered bias, regulatory inquiries affecting your data, and material capability changes.
- Set notification timeframes aligned with your own regulatory obligations — if you must notify a regulator within 72 hours of discovering a breach, your vendor must notify you faster than that.
- Require vendors to provide a designated security/incident contact, not just a generic support email.
- Test vendor notification processes: tabletop exercises that include vendor notification scenarios reveal gaps before real incidents.
Example Implementation
Enterprise with 8 AI vendors standardizing incident notification handling
Vendor AI Incident Notification Requirements (Standard Contract Clause)
Notification trigger events (vendor must notify us within specified timeframe):
| Event Type | Notification SLA | Required Information |
|---|---|---|
| Security breach involving our data | 24 hours from discovery | Scope, affected data types, containment steps taken |
| AI model failure at scale (> 5% error rate) | 4 hours from detection | Affected feature/model, estimated impact, ETA to resolution |
| Discovered bias or discriminatory output pattern | 24 hours from confirmation | Affected groups, estimated scope, remediation plan |
| Model change (material capability or behavior change) | 14 days before deployment | Nature of change, expected behavioral impact, changelog |
| Regulatory inquiry involving our data | 24 hours from receipt | Nature of inquiry, regulator, data in scope |
Contact requirements:
- Vendor must provide a named security/AI incident contact and a 24/7 escalation number
- Notifications sent to: security@[company].com + ai-governance@[company].com
- Generic support tickets do not satisfy notification obligations
Compliance tracking: Legal logs all vendor notifications received; late notifications (> SLA) result in formal notice to vendor and are tracked in vendor risk scorecard
Control Details
- Control ID
- PRC-004
- Domain
- Procurement
- Typical owner
- Legal / Procurement / CISO
- Implementation effort
- Low effort
- Agent-relevant
- No