Vendor Incident Disclosure Governance

2. Summary

Vendor Incident Disclosure Governance requires that every organisation deploying AI agents under the Agent Governance Standard establishes and enforces contractual, procedural, and technical mechanisms ensuring that vendors, subprocessors, and upstream service providers disclose security incidents, material operational changes, vulnerability exposures, model behaviour regressions, and compliance failures within defined timeframes and with defined content standards. AI agent pipelines depend on external vendors for inference, data enrichment, embedding generation, tool execution, and numerous other functions — any of which can experience incidents that materially affect the deploying organisation's security posture, data integrity, regulatory compliance, or operational continuity. Without structured disclosure requirements, the deploying organisation operates in an information vacuum: incidents occur at vendor premises, affect the organisation's data and operations, but are never communicated or are communicated too late for effective response. This dimension mandates that vendor incident disclosure is contractually required, technically facilitated, and independently verifiable.

3. Example

Scenario A — Delayed Vendor Breach Disclosure Expands Regulatory Exposure: A customer-facing agent deployed by a European insurance company uses an inference provider for natural language processing of claims submissions. The inference provider experiences a security breach in which an attacker gains read access to the inference API's request and response logs for 11 days. The logs contain 340,000 insurance claims submissions including policyholder names, addresses, claim descriptions (some involving health conditions), and financial amounts. The inference provider discovers the breach on Day 11, patches the vulnerability on Day 12, and begins internal forensic analysis. The inference provider's legal team advises withholding disclosure until the forensic report is complete — a process that takes 38 days. The inference provider notifies the insurance company on Day 50. Under GDPR Article 33, the insurance company as data controller had 72 hours from becoming aware of the breach to notify its supervisory authority. The insurance company notifies the authority on Day 51 — 49 days after the breach was discovered by the entity that experienced it. The supervisory authority determines that the late notification constitutes a GDPR Article 33 violation by the insurance company, which had a contractual obligation to be notified within 24 hours but whose contract with the inference provider specified notification "as soon as reasonably practicable."

What went wrong: The vendor contract used vague disclosure language ("as soon as reasonably practicable") instead of a specific SLA. The inference provider's interpretation of "reasonably practicable" included completing a full forensic investigation before disclosure. No intermediate notification mechanism existed — the inference provider's options were full disclosure or no disclosure, with no provision for preliminary notification. The insurance company had no independent detection capability for vendor-side incidents. Consequence: GDPR Article 33 fine of €1.8 million for late notification, mandatory notification to 340,000 policyholders costing €680,000, reputational damage quantified at €4.2 million in policy cancellations, and termination of the inference provider relationship.

Scenario B — Undisclosed Model Behaviour Regression Causes Systematic Decision Errors: A financial-value agent uses a vendor-provided embedding model for credit risk assessment. The vendor performs a routine model update that introduces a regression: the updated model systematically underweights negative credit signals in borrower applications containing more than 3,000 tokens of supporting documentation. The vendor's internal quality assurance detects a 6% accuracy degradation on its benchmark suite but classifies this as within acceptable drift tolerance and does not disclose the regression to customers. Over 4 months, the financial-value agent approves 2,300 credit applications that would have been declined or flagged under the previous model version. The aggregate exposure from these approvals is £14.7 million. The deploying organisation discovers the regression only when default rates spike 9 months later. A retrospective analysis attributes £8.3 million in losses to the undisclosed model regression.

What went wrong: The vendor disclosure obligation covered security incidents and data breaches but did not extend to model behaviour regressions, accuracy degradation, or material changes to model outputs. The vendor classified the regression as an internal quality issue below its disclosure threshold. No contractual definition existed for what constitutes a "material change" requiring disclosure. The deploying organisation had no independent model performance monitoring that compared vendor model outputs against expected baselines. Consequence: £8.3 million in credit losses, regulatory investigation for inadequate model risk management, £340,000 in remediation costs for retrospective credit review, and mandatory enhancement of vendor model monitoring.

Scenario C — Vendor Suppresses Exploit Disclosure to Avoid Contract Penalties: A safety-critical agent deployed in industrial process control uses a vendor-provided tool execution service for programmable logic controller (PLC) interaction. A security researcher discloses a critical vulnerability to the vendor through a responsible disclosure programme: the tool execution service's API authentication can be bypassed through a crafted header injection, allowing unauthenticated access to PLC command execution. The vendor begins developing a patch but does not notify customers because the vendor contract includes a service-level credit clause that triggers a £50,000 penalty per customer for each disclosed security vulnerability rated "Critical" in any calendar quarter. The vendor has already disclosed one critical vulnerability this quarter. Rather than triggering the financial penalty, the vendor silently patches the vulnerability over 16 days without notifying customers. During the 16-day window, the deploying organisation's safety-critical agent is exposed to an authentication bypass that could allow an attacker to send commands to industrial PLCs. No attack occurs, but the deploying organisation learns of the vulnerability 3 months later through a public CVE disclosure and discovers it was exposed for 16 days without knowledge.

What went wrong: The vendor contract created a perverse incentive — financial penalties for vulnerability disclosure — that directly contradicted the goal of timely incident disclosure. The vendor had a rational economic incentive to suppress disclosure. No contractual safe-harbour provision existed to protect the vendor from penalties when disclosing in good faith. No independent vulnerability monitoring detected the exposure. Consequence: 16-day unmitigated exposure of safety-critical infrastructure, loss of trust in the vendor relationship, mandatory contract restructuring across all vendor agreements, and regulatory inquiry into the deploying organisation's third-party risk management.

4. Requirement Statement

Scope: This dimension applies to every AI agent deployment that depends on any external vendor, service provider, subprocessor, or upstream component provider for inference, model hosting, data processing, tool execution, data enrichment, embedding generation, content filtering, or any other function in the agent pipeline. The term "vendor" in this dimension includes all entities in the processing chain as defined by AG-493 (Subprocessor Governance), including first-tier direct vendors and all deeper-tier subprocessors. The term "incident" encompasses security breaches, data breaches, vulnerability exposures, model behaviour regressions, material operational changes, service degradation events, compliance failures, regulatory actions, and any other event at the vendor that could materially affect the deploying organisation's security posture, data integrity, regulatory compliance, operational continuity, or agent output quality. Organisations that operate AI agents with no external vendor dependencies are exempt, but must re-assess if any external integration is added.

4.1. A conforming system MUST require, through contractual terms, that every vendor in the agent processing chain discloses security incidents, data breaches, and vulnerability exposures within a defined SLA — maximum 24 hours from vendor awareness for Critical severity events, maximum 48 hours for High severity events, and maximum 5 business days for Medium severity events — as classified under the organisation's adverse event severity matrix (aligned with AG-419).

4.2. A conforming system MUST require, through contractual terms, that every vendor discloses material changes to model behaviour, model versions, inference infrastructure, data processing pipelines, or any other component that could alter the quality, accuracy, or characteristics of the service consumed by the agent — with disclosure occurring before the change takes effect for planned changes and within 48 hours for unplanned changes.

4.3. A conforming system MUST define a structured disclosure format specifying the minimum content of a vendor incident notification: incident identifier, date and time of discovery, affected services, affected data categories, estimated scope of impact, root cause (if known), interim mitigations applied, timeline for resolution, and contact details for the vendor incident team.

4.4. A conforming system MUST establish a dedicated, tested intake channel for receiving vendor incident disclosures — separate from general vendor communication channels — that is monitored continuously (24/7 for Critical and High severity) and routes notifications to the appropriate incident response team (aligned with AG-424).

4.5. A conforming system MUST verify vendor disclosure compliance through at least one independent mechanism: vendor incident disclosure audits, threat intelligence monitoring for vendor-related events, or contractual requirements for vendors to provide periodic incident disclosure completeness attestations.

4.6. A conforming system MUST prohibit contractual terms that create disincentives for vendor incident disclosure — including financial penalties triggered by disclosure volume, severity-based penalty escalation that punishes the act of disclosing rather than the act of having an incident, or clauses that allow the deploying organisation to terminate solely because a vendor disclosed an incident. A contractual safe-harbour provision MUST protect vendors from penalties specifically triggered by timely, good-faith disclosure.

4.7. A conforming system MUST maintain an incident disclosure log recording all vendor disclosures received, the time between vendor awareness and disclosure (where determinable), the response actions taken by the deploying organisation, and the resolution status of each disclosed incident.

4.8. A conforming system SHOULD implement automated correlation between vendor incident disclosures and the deploying organisation's own monitoring data, detecting discrepancies between what the vendor reports and what the organisation observes (e.g., the vendor reports no data exposure, but the organisation's data lineage shows that exposed systems processed its data during the incident window).

4.9. A conforming system SHOULD establish bilateral incident disclosure obligations — committing the deploying organisation to disclose to the vendor any incidents at the deploying organisation that could affect the vendor's infrastructure or other customers, creating a mutual disclosure relationship rather than a one-directional requirement.

4.10. A conforming system SHOULD implement vendor incident simulation exercises at least annually, testing the end-to-end disclosure and response workflow: vendor sends a simulated disclosure, the intake channel receives and routes it, the incident response team evaluates and acts, and lessons learned are documented.

4.11. A conforming system MAY implement vendor security posture monitoring — continuous external assessment of vendor security indicators (certificate management, DNS security, public vulnerability disclosures, dark web monitoring for vendor data) — to provide early warning of potential incidents before vendor disclosure.

5. Rationale

The deploying organisation's security perimeter, in the context of AI agent deployments, extends far beyond the organisation's own infrastructure. Every vendor in the agent processing chain is an extension of the deploying organisation's attack surface, data handling environment, and operational infrastructure. An incident at any vendor in the chain can compromise the deploying organisation's data, affect the quality or safety of agent outputs, trigger regulatory obligations, and damage customer trust. The deploying organisation's ability to respond to these incidents depends entirely on whether and when the vendor discloses them.

Three structural factors make vendor incident disclosure governance essential for AI agent deployments specifically — beyond the general case for vendor risk management.

First, the data sensitivity and volume flowing through AI agent pipelines is exceptionally high. Agent inputs routinely include personal data, financial data, health data, and proprietary business information. Agent outputs include decisions, recommendations, and actions with direct consequences for individuals and organisations. Inference telemetry may reveal business logic, customer behaviour patterns, and operational strategies. A security breach at an inference provider is not analogous to a breach at a commodity SaaS tool — it potentially exposes the substance of every interaction processed through that provider. The deploying organisation cannot assess its exposure or discharge its regulatory obligations without timely, detailed disclosure from the vendor.

Second, AI model behaviour is not static, and changes in model behaviour can be as consequential as security breaches. When a vendor updates a model version, changes inference infrastructure, modifies content filtering rules, or alters tokenisation, the outputs consumed by the deploying organisation's agents may change materially. A model regression that systematically underweights negative signals (Scenario B) is not a security incident in the traditional sense, but its financial and regulatory consequences can exceed those of a data breach. Traditional vendor incident disclosure frameworks, designed for security incidents, do not capture model behaviour changes. AG-494 extends the disclosure obligation to cover any material change that could affect agent output quality or characteristics.

Third, the regulatory environment increasingly holds deploying organisations accountable for vendor incidents regardless of whether the deploying organisation knew about the incident. Under GDPR Article 33, the 72-hour notification clock starts from the controller's awareness, but supervisory authorities assess whether the controller had adequate mechanisms to become aware promptly. Under the EU AI Act, deployers of high-risk AI systems must monitor system performance — which requires knowledge of upstream changes that could affect performance. Under DORA, financial entities must manage ICT third-party risk including incident reporting from third-party providers. In each case, the regulatory expectation is that the deploying organisation has established mechanisms to ensure timely vendor disclosure — not merely that it responds promptly when disclosure happens to arrive.

The perverse incentive problem illustrated in Scenario C deserves specific attention. Vendor contracts that penalise disclosure create rational economic incentives for vendors to suppress or delay incident notifications. This is not a theoretical risk — it is a predictable consequence of poorly structured contractual incentives. If a vendor faces a £50,000 penalty for disclosing a critical vulnerability, the vendor's rational calculation is to suppress disclosure if the probability of independent discovery is low and the expected cost of suppression (reputational damage if discovered, contract termination) is less than £50,000. AG-494 requires contractual safe-harbour provisions that eliminate this perverse incentive, ensuring that vendors are never financially worse off for disclosing than for suppressing.

The combination of contractual requirements, structured disclosure formats, dedicated intake channels, independent verification, and safe-harbour provisions creates a disclosure governance framework that addresses the full spectrum of vendor incident risk — from traditional security breaches to model behaviour regressions to perverse incentive structures.

6. Implementation Guidance

Vendor incident disclosure governance requires contractual, procedural, and technical measures working in concert. The contractual layer defines obligations and incentives. The procedural layer defines workflows and responsibilities. The technical layer provides channels, automation, and verification.

Recommended patterns:

• Tiered SLA structure with preliminary notification. Define disclosure SLAs by severity tier (Critical: 24 hours, High: 48 hours, Medium: 5 business days) but also require a preliminary notification mechanism for Critical and High events. The preliminary notification need not contain full forensic details — it should confirm that an incident has occurred, identify the affected service, and provide an estimated scope. Full details follow in a subsequent detailed notification. This two-stage approach eliminates the vendor's excuse that forensic analysis delayed disclosure while ensuring the deploying organisation can initiate its own response promptly. The preliminary notification must be substantive enough to enable the deploying organisation to assess whether its regulatory notification obligations are triggered.
• Structured disclosure format with machine-readable option. Define a disclosure template with mandatory fields: incident identifier, discovery timestamp, affected services (mapped to the deploying organisation's service catalogue), data categories affected, estimated record count, root cause category, interim mitigations, expected resolution timeline, and vendor incident contact. For mature organisations, provide a machine-readable intake option (structured JSON or XML submission to an API endpoint) enabling automated ingestion, routing, and correlation. This eliminates the email-based disclosure pattern where critical incident notifications arrive in a general vendor management inbox and wait for manual routing.
• Safe-harbour clause with good-faith protection. Include in every vendor contract a clause that explicitly states: timely, good-faith incident disclosure in compliance with the contractual SLA shall not, by itself, constitute grounds for financial penalty, service-level credit, or contract termination. The vendor remains liable for the underlying incident and its consequences, but is not additionally penalised for the act of disclosing. This eliminates the perverse incentive to suppress disclosure. If the contract includes severity-based SLA credits, structure them based on the incident itself (duration, impact) rather than on the disclosure.
• Independent verification through threat intelligence correlation. Subscribe to threat intelligence feeds, CVE databases, vendor security advisory aggregators, and dark web monitoring services. Correlate external intelligence about vendor incidents against the vendor disclosure log. If external sources report an incident affecting a vendor in the agent processing chain and no corresponding disclosure has been received, escalate immediately. This provides an independent detection channel that validates vendor disclosure completeness without relying solely on vendor self-reporting.
• Annual vendor incident simulation. Conduct a simulated vendor incident disclosure exercise at least annually for each critical vendor. The simulation should test: the vendor's ability to produce a compliant disclosure within the SLA, the deploying organisation's intake channel monitoring and routing, the incident response team's evaluation and action workflow, and the end-to-end elapsed time from disclosure receipt to response initiation. Document lessons learned and use them to refine the disclosure process.
• Disclosure log with trend analysis. Maintain a centralised disclosure log that records every vendor notification received, regardless of severity. Analyse the log quarterly for patterns: vendors that disclose frequently (potential quality or security concerns), vendors that never disclose (potential suppression), disclosure SLA compliance trends, and correlation between disclosure timing and incident severity. Use trend analysis to inform vendor reassessment (per AG-493) and to identify systemic weaknesses in the disclosure framework.

Anti-patterns to avoid:

• Vague contractual disclosure language. Terms like "promptly," "without undue delay," "as soon as reasonably practicable," or "in a timely manner" are unenforceable and invite interpretation that favours delay. Use specific SLAs with defined hours or business days.
• Penalty-driven disclosure frameworks. Contractual structures that penalise the volume or severity of disclosures incentivise suppression. Penalties should attach to the underlying incident (breach, data loss, service failure), not to the act of disclosing.
• Email-only disclosure channels. Relying on email to a general vendor management address for incident disclosures. Email is asynchronous, unmonitored outside business hours, subject to spam filtering, and cannot be automatically routed or correlated. Use a dedicated intake system with 24/7 monitoring for Critical and High severity.
• Disclosure requirements for first-tier vendors only. Requiring disclosure from direct vendors but not from their subprocessors. A breach at a fourth-tier subprocessor affects the deploying organisation's data just as much as a breach at a first-tier vendor. Contractual flow-down (per AG-493) must extend disclosure obligations to all tiers.
• Absence of independent verification. Relying entirely on vendor self-reporting for incident disclosure. Vendors may not detect incidents, may misclassify severity, or may have incentives to suppress disclosure. Independent verification through threat intelligence and monitoring provides a critical check on vendor disclosure completeness.
• Treating model behaviour changes as non-disclosable events. Traditional vendor incident disclosure frameworks focus exclusively on security incidents and data breaches. For AI agent deployments, model behaviour regressions, accuracy degradation, and infrastructure changes that alter output characteristics are equally material. Disclosure requirements must explicitly cover these categories.

Industry Considerations

Financial Services. DORA Article 19 requires ICT-related incident reporting from financial entities, and Articles 28-30 require contractual provisions for third-party ICT incident notification. Financial institutions should align AG-494 disclosure SLAs with DORA reporting timelines. The 24-hour SLA for Critical events provides the upstream notification needed to meet DORA's initial notification deadline. Financial institutions should also consider the intersection with DORA's direct oversight framework for critical ICT third-party service providers, where regulatory authorities may have independent incident information that can be used for verification.

Healthcare. Vendor incidents involving protected health information trigger notification obligations under HIPAA (US) and equivalent health data breach notification laws. Healthcare organisations should ensure that vendor disclosure content includes sufficient detail to determine whether a HIPAA breach notification is required — specifically, whether unsecured protected health information was accessed, acquired, used, or disclosed. The 24-hour Critical SLA is essential for healthcare deployments, as HIPAA's 60-day notification deadline runs from the date of discovery, and delayed vendor disclosure compresses the healthcare organisation's response timeline.

Public Sector. Government agencies may be subject to mandatory incident reporting to national cybersecurity authorities (e.g., CISA in the US, NCSC in the UK, BSI in Germany) with defined timelines. Vendor incident disclosures must arrive early enough to permit the agency to assess, investigate, and report within these mandatory windows. Agencies deploying agents handling classified information must also consider whether vendor incidents trigger classified incident response protocols.

Crypto/Web3. Vendor incidents in crypto and Web3 contexts can have immediate and irreversible financial consequences — a compromised tool execution service could enable unauthorised transactions that cannot be reversed on-chain. The 24-hour SLA for Critical events may be insufficient; crypto deployments should consider real-time or near-real-time disclosure requirements for incidents that could enable asset theft or unauthorised transaction execution.

Maturity Model

Basic Implementation — The organisation has contractual incident disclosure requirements with all first-tier vendors, including defined SLAs for Critical, High, and Medium severity events. A dedicated intake channel exists and is monitored during business hours (24/7 for Critical). A structured disclosure format specifies minimum notification content. Vendor contracts include safe-harbour provisions protecting good-faith disclosure. An incident disclosure log records all notifications received. This level meets the minimum mandatory requirements.

Intermediate Implementation — All basic capabilities plus: contractual disclosure extends to second-tier and deeper-tier subprocessors through flow-down clauses. The intake channel supports machine-readable submissions with automated routing per AG-424. Independent verification through threat intelligence correlation provides a check on vendor disclosure completeness. Annual vendor incident simulation exercises test the end-to-end workflow. Disclosure trend analysis is conducted quarterly. Disclosure obligations explicitly cover model behaviour changes, not only security incidents. Bilateral disclosure obligations create mutual transparency.

Advanced Implementation — All intermediate capabilities plus: real-time vendor security posture monitoring provides early warning before vendor disclosure. Automated correlation between vendor disclosures and the organisation's own monitoring data detects discrepancies in vendor-reported impact. The disclosure log is integrated with the organisation's enterprise incident management system, enabling cross-incident analysis and pattern detection. Independent audits verify vendor disclosure completeness by comparing the organisation's disclosure log against the vendor's internal incident register (through audit rights). The organisation can demonstrate, through evidence, that every material vendor event affecting its agent deployments was disclosed within the contractual SLA.

7. Evidence Requirements

Required artefacts:

• Contractual disclosure provisions. Copies or summaries of contractual clauses in each vendor agreement specifying disclosure obligations, SLAs, content requirements, and safe-harbour provisions. Must cover first-tier vendors and demonstrate flow-down to deeper tiers.
• Intake channel specification. Documentation of the dedicated vendor incident disclosure intake channel, including monitoring schedule, routing rules, escalation procedures, and test records confirming operational status.
• Incident disclosure log. The complete log of all vendor incident disclosures received, recording: date/time received, vendor identity, incident severity, time from vendor awareness to disclosure (where determinable), affected services, response actions taken, and resolution status.
• Disclosure SLA compliance records. Analysis showing vendor compliance with contractual disclosure SLAs, including: percentage of disclosures received within SLA, instances of SLA breach, and actions taken in response to SLA breaches.
• Independent verification records. Documentation of independent verification activities (threat intelligence correlation, vendor audit results, disclosure completeness attestations) and any discrepancies identified between external intelligence and vendor disclosures.
• Simulation exercise records. Documentation of vendor incident simulation exercises, including exercise design, participating parties, outcomes, identified gaps, and remediation actions.
• Safe-harbour clause evidence. Contractual evidence that safe-harbour provisions exist in vendor agreements, protecting vendors from penalties triggered by the act of disclosing.

Retention requirements:

• Incident disclosure logs and contractual provisions: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Simulation exercise records: minimum 3 years for all sectors.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. The incident disclosure log must be producible in both human-readable and machine-readable formats. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Test 8.1: Contractual Disclosure SLA Presence

• Stimulus: Select 5 vendor contracts at random from the agent processing chain (including at least 2 first-tier and 1 second-tier via flow-down). Review each for contractual incident disclosure provisions specifying: SLA timelines for Critical (maximum 24 hours), High (maximum 48 hours), and Medium (maximum 5 business days) severity events; structured disclosure content requirements; and safe-harbour provisions.
• Expected behaviour: All 5 contracts contain compliant disclosure provisions.
• Pass criteria: 100% of sampled contracts contain disclosure SLAs meeting the required timelines, structured content requirements, and safe-harbour provisions.
• Fail criteria: Any sampled contract lacks a disclosure SLA, specifies timelines exceeding the maximum, omits structured content requirements, or lacks safe-harbour provisions.

Test 8.2: Intake Channel Availability and Monitoring

• Stimulus: Submit a test vendor incident disclosure through the dedicated intake channel at three different times: during business hours, outside business hours on a weekday evening, and on a weekend morning. Measure the time from submission to first human acknowledgement.
• Expected behaviour: Business hours submissions are acknowledged within 1 hour. Outside-business-hours submissions classified as Critical or High are acknowledged within 4 hours (reflecting 24/7 monitoring for Critical/High). Weekend submissions follow the same pattern.
• Pass criteria: All test submissions are received and acknowledged. Critical/High-severity submissions are acknowledged within 4 hours regardless of submission time. No submissions are lost, filtered, or delayed beyond the monitoring SLA.
• Fail criteria: Any submission is not received, or acknowledgement exceeds the monitoring SLA, or the intake channel is non-functional at any tested time.

Test 8.3: Disclosure Content Completeness

• Stimulus: Review the 10 most recent vendor incident disclosures in the incident disclosure log. For each, verify that the disclosure contains all fields required by the structured disclosure format: incident identifier, discovery timestamp, affected services, data categories affected, estimated scope, root cause category, interim mitigations, resolution timeline, and vendor contact.
• Expected behaviour: All 10 disclosures contain all required fields.
• Pass criteria: 100% of sampled disclosures contain all required fields with substantive content (not boilerplate placeholders).
• Fail criteria: Any disclosure is missing a required field, or any field contains only placeholder text without substantive content.

Test 8.4: Disclosure SLA Compliance Measurement

• Stimulus: For all vendor incident disclosures received in the past 12 months, calculate the elapsed time between vendor awareness (as stated in the disclosure or determined through investigation) and receipt by the deploying organisation. Compare each against the applicable severity-tier SLA.
• Expected behaviour: The majority of disclosures comply with the applicable SLA. SLA breaches are documented and addressed through vendor management processes.
• Pass criteria: At least 90% of disclosures comply with the applicable SLA. All SLA breaches are documented in the disclosure log with root cause analysis and corrective action.
• Fail criteria: Fewer than 90% of disclosures comply with the applicable SLA, or SLA breaches are not documented with root cause and corrective action.

Test 8.5: Safe-Harbour Provision Enforcement

• Stimulus: Review the last 12 months of vendor incident disclosures. Identify any instance where a vendor received a financial penalty, service-level credit deduction, or contract termination notice that was triggered by the act of disclosing an incident (as opposed to being triggered by the underlying incident itself). Verify that safe-harbour provisions are operative and that no perverse incentive exists.
• Expected behaviour: No vendor has been penalised for the act of timely, good-faith disclosure. Penalties, if any, are attributed to the underlying incident (duration, impact, negligence) rather than to the disclosure event.
• Pass criteria: Zero instances of penalty triggered by the act of disclosure. Safe-harbour provisions are present in all reviewed contracts and have not been overridden by other contractual mechanisms.
• Fail criteria: Any vendor penalty was triggered by the act of disclosing rather than by the underlying incident, or safe-harbour provisions are absent or overridden in any contract.

Test 8.6: Independent Verification Effectiveness

• Stimulus: Identify 3 vendor security events from the past 12 months that appeared in external threat intelligence feeds, public CVE databases, or vendor security advisories. For each, verify that: (a) a corresponding vendor disclosure was received, (b) the disclosure was received before or contemporaneously with the external intelligence, and (c) any discrepancy between the vendor disclosure and external intelligence was investigated and resolved.
• Expected behaviour: All 3 events have corresponding vendor disclosures. Disclosures arrived within the contractual SLA. Any discrepancies between vendor disclosures and external intelligence were investigated.
• Pass criteria: All externally identified events have corresponding vendor disclosures. No event was identified externally more than 48 hours before the vendor disclosure was received (indicating suppression or excessive delay). Discrepancies were investigated and documented.
• Fail criteria: Any externally identified event lacks a vendor disclosure, or any event was known externally more than 48 hours before vendor disclosure, or discrepancies were not investigated.

Test 8.7: Incident Disclosure Log Completeness and Accuracy

• Stimulus: Cross-reference the incident disclosure log against three independent sources: (a) the vendor's own incident reports (obtained through audit rights or provided during vendor review), (b) the deploying organisation's own incident records that reference vendor involvement, and (c) external threat intelligence regarding vendor events. Identify any events present in these sources but absent from the disclosure log.
• Expected behaviour: The disclosure log is consistent with all three sources. No material vendor events are absent from the log.
• Pass criteria: All material vendor events identified through cross-referencing are present in the disclosure log. Any discrepancies are minor (e.g., classification differences) rather than missing entries.
• Fail criteria: Any material vendor event is absent from the disclosure log, or systematic gaps indicate that certain event categories are not being logged.

Conformance Scoring

• Score 0: No contractual vendor incident disclosure requirements exist, or requirements are limited to vague language without defined SLAs. No dedicated intake channel. No disclosure log. The organisation relies entirely on vendors volunteering information without contractual obligation.
• Score 1: Contractual disclosure requirements exist with defined SLAs for at least first-tier vendors. A dedicated intake channel exists but may not be monitored 24/7 for Critical/High events. A structured disclosure format is defined but compliance is not verified. A disclosure log exists but is incomplete. Safe-harbour provisions are absent or incomplete.
• Score 2: Contractual disclosure requirements with compliant SLAs cover all first-tier vendors and flow-down to deeper tiers. The intake channel is monitored 24/7 for Critical/High events. Structured disclosure format compliance is verified for all notifications. Safe-harbour provisions are universal. Independent verification through threat intelligence correlation operates. Annual simulation exercises test the workflow. Disclosure trend analysis is conducted quarterly.
• Score 3: Verified through independent testing confirming end-to-end disclosure governance. Real-time vendor security posture monitoring provides early warning. Automated correlation between vendor disclosures and the organisation's own monitoring detects discrepancies. Independent audits verify vendor disclosure completeness against vendor internal incident registers. The organisation can demonstrate that every material vendor event affecting its agent deployments was disclosed within the contractual SLA, with no suppressed or unreported events identified through any verification channel.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 62 (Post-Market Monitoring)	Direct requirement
GDPR	Article 33 (Notification of a Personal Data Breach to the Supervisory Authority)	Direct requirement
GDPR	Article 28(3)(f) (Processor Obligations — Breach Notification)	Direct requirement
SOX	Section 302/404 (Internal Controls)	Supports compliance
FCA SYSC	11.1 (Reporting Requirements)	Supports compliance
NIST AI RMF	MANAGE 4.1, MANAGE 4.2, GOVERN 5.2	Supports compliance
ISO 42001	Clause 9.1 (Monitoring, Measurement, Analysis and Evaluation)	Supports compliance
DORA	Article 19 (Reporting of Major ICT-Related Incidents)	Direct requirement

GDPR — Article 33 (Notification of a Personal Data Breach to the Supervisory Authority)

Article 33 requires that the controller notify the supervisory authority of a personal data breach "without undue delay and, where feasible, not later than 72 hours after having become aware of it." The controller's ability to comply with this 72-hour deadline depends directly on when the controller becomes aware of breaches occurring at its vendors and processors. GDPR Article 28(3)(f) explicitly requires that the processor assist the controller in ensuring compliance with Articles 33 and 34, "taking into account the nature of processing and the information available to the processor." AG-494's requirement for 24-hour disclosure of Critical events ensures that the controller receives breach notification from its vendors with sufficient lead time to assess the breach, determine whether the notification threshold under Article 33 is met, and submit the supervisory authority notification within 72 hours. Without AG-494's structured disclosure framework, the controller's 72-hour window begins only when it happens to learn of the breach — which, as Scenario A demonstrates, can be weeks or months after the breach occurred.

DORA — Article 19 (Reporting of Major ICT-Related Incidents)

DORA requires financial entities to report major ICT-related incidents to competent authorities, with an initial notification "without undue delay" and a detailed report within specific timeframes. For financial entities that depend on vendor-provided AI agent infrastructure, the ability to meet DORA reporting timelines depends on vendor disclosure timeliness. AG-494's tiered SLA structure directly supports DORA compliance: the 24-hour Critical disclosure SLA provides upstream notification that enables the financial entity to submit its initial notification to the competent authority within DORA's expected timeframes. DORA Articles 28-30 further require that contractual arrangements with ICT third-party service providers include provisions for incident reporting — AG-494's contractual disclosure requirements fulfil this obligation.

EU AI Act — Article 62 (Post-Market Monitoring)

The AI Act requires providers and deployers of high-risk AI systems to implement post-market monitoring systems that actively and systematically collect, document, and analyse relevant data about the AI system's performance throughout its lifetime. For deployers, this includes monitoring for changes in upstream components that could affect system performance. Vendor incident disclosure — particularly disclosure of model behaviour regressions (Requirement 4.2) — is a critical input to the post-market monitoring system. Without vendor disclosure of material changes, the deployer's monitoring system has a blind spot for upstream changes that affect agent performance. AG-494 ensures that the deployer's post-market monitoring system receives timely information about vendor-side events that could affect the high-risk AI system's performance, accuracy, or safety characteristics.

SOX — Sections 302/404 (Internal Controls)

Financial reporting controls that rely on AI agent pipelines are dependent on the integrity of vendor-provided services in those pipelines. A vendor incident that corrupts data, introduces errors, or compromises the integrity of a financial processing agent directly threatens the reliability of financial reporting. SOX compliance requires that internal controls over financial reporting are effective, which in turn requires that the organisation has timely visibility into vendor incidents that could compromise those controls. AG-494's disclosure framework ensures that financial-value agent deployments have the vendor incident visibility needed to assess the ongoing effectiveness of financial reporting controls.

FCA SYSC — 11.1 (Reporting Requirements)

The FCA expects firms to have adequate systems and controls for identifying, monitoring, and reporting incidents. For firms using AI agents, this includes incidents at vendors that affect the firm's operations. AG-494's incident disclosure governance ensures that vendor incidents are communicated to the firm within timeframes that enable the firm to meet its own reporting obligations to the FCA. The structured disclosure format also ensures that the firm receives sufficient detail to assess materiality and determine whether FCA notification is required.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — delayed or suppressed vendor disclosure affects every agent deployment, data subject, and business process that depends on the affected vendor, with regulatory consequences potentially spanning multiple jurisdictions simultaneously

Consequence chain: The failure sequence begins with an incident occurring at a vendor in the agent processing chain — a security breach, a model regression, a vulnerability exposure, or a material operational change. Without effective disclosure governance, the incident remains invisible to the deploying organisation. The immediate consequence is an unmitigated exposure window: the deploying organisation's agents continue to operate through compromised infrastructure, consuming degraded or corrupted outputs, or processing data through breached systems, without any defensive response. The exposure window continues indefinitely until the incident is discovered through an independent channel — which, as demonstrated across all three scenarios, can take weeks to months. During the exposure window, the accumulation of harm is continuous and compounding: more records are exposed (Scenario A: 340,000 records over 11 days), more erroneous decisions are made (Scenario B: 2,300 faulty credit approvals over 4 months), or more time passes with unmitigated critical vulnerabilities (Scenario C: 16 days of authentication bypass on safety-critical infrastructure). When the incident is eventually discovered, the deploying organisation faces a compressed response timeline: regulatory notifications are already overdue, affected data subjects must be notified retrospectively for a much larger population than would have been affected with timely disclosure, and remediation must address months of accumulated impact rather than hours. The regulatory consequence is multiplicative: not only did the incident occur, but the deploying organisation failed to detect it in a timely manner, failed to notify regulators within mandatory windows, and failed to mitigate impact through prompt response — each failure compounding the regulatory exposure. The ultimate business consequence includes regulatory fines, customer notification costs, remediation expenditure, reputational damage, and — most critically — loss of the organisation's credibility as a responsible deployer of AI agents.

Cross-references: AG-419 (Adverse Event Severity Matrix Governance), AG-423 (Incident Learning Closure Governance), AG-424 (Notification Routing Governance), AG-427 (Mutual Aid and Vendor Coordination Governance), AG-490 (Maintainer Trust and Project Health Governance), AG-491 (Dependency Provenance and SBOM Attestation Governance), AG-493 (Subprocessor Governance), AG-497 (End-of-Support Migration Governance).