Subprocessor Governance

2. Summary

Subprocessor Governance requires that every organisation deploying AI agents under the Agent Governance Standard maintains a formally governed registry of all subprocessors — downstream third parties that receive, process, store, or can access data or operational instructions flowing through the agent pipeline — and subjects each subprocessor relationship to documented approval, contractual obligation, and ongoing monitoring. AI agent deployments routinely involve multi-layered subprocessor chains: the deploying organisation contracts with a primary vendor, who delegates inference to a cloud compute provider, who routes traffic through a content delivery network, who logs telemetry to a third-party analytics service, each of which may further subcontract. Without governance of these chains, data flows to entities the deploying organisation has never assessed, contractual obligations are diluted at each delegation layer, and regulatory accountability becomes untraceable. This dimension mandates that subprocessor chains are mapped, approved, monitored, and subject to termination when governance requirements are not met.

3. Example

Scenario A — Undisclosed Fourth-Party Inference Routing: A European healthcare organisation deploys a clinical decision-support agent through a vendor domiciled in Ireland. The contract specifies EU-only data processing. The vendor subcontracts inference to a compute provider with EU data centres, satisfying the contractual requirement at the first subprocessor layer. However, the compute provider, under load-balancing pressure during a capacity spike, routes 12% of inference requests to a subsidiary data centre in Singapore for 9 days. The Singapore subsidiary uses a different GPU cluster provider — a fourth party — whose terms of service permit model telemetry retention for performance benchmarking. Over 9 days, 4,200 clinical inference requests containing patient symptoms, medication histories, and provisional diagnoses are processed in Singapore and telemetry is retained by a fourth party the healthcare organisation has never assessed. A patient data breach at the fourth party 5 months later triggers a regulatory investigation that traces data provenance back to the healthcare organisation.

What went wrong: The subprocessor chain extended beyond the contracted first-tier vendor to a compute provider (second tier), a load-balanced subsidiary (third tier), and a GPU cluster operator (fourth tier). No subprocessor registry tracked entities beyond the first tier. No contractual flow-down required the compute provider to notify the vendor of routing changes. The healthcare organisation had no visibility into the chain beyond the entity it directly contracted. Consequence: GDPR Article 28 violation for unauthorised subprocessor engagement, €2.3 million fine, 6-month suspension of the clinical agent deployment, patient notification obligations for 4,200 affected records, and reputational damage quantified at €5.1 million in lost contract value.

Scenario B — Subprocessor Substitution Without Re-Approval: A financial-value agent processes transaction screening through a vendor that subcontracts sanctions-list matching to a specialised compliance data provider. The vendor's contract requires notification before subprocessor changes. The compliance data provider is acquired by a firm domiciled in a jurisdiction subject to international sanctions. The acquisition closes on a Friday; by Monday, the acquiring firm has administrative access to the compliance data provider's systems. The vendor does not notify the deploying organisation for 47 days — the contract requires notification "within a reasonable time," which the vendor interprets as the next quarterly review. During the 47-day gap, the financial-value agent processes 18,000 transaction screenings through a subprocessor now controlled by an entity in a sanctioned jurisdiction. The deploying organisation's sanctions compliance programme is compromised by its own sanctions screening subprocessor.

What went wrong: The subprocessor approval process treated approval as a one-time event rather than a continuous obligation. The contractual notification requirement used vague language ("reasonable time") rather than a specific SLA. No monitoring mechanism detected the change of control at the subprocessor level. The deploying organisation's subprocessor registry showed the original entity, not the acquiring entity. Consequence: Potential sanctions violation for 18,000 transactions, mandatory retrospective screening costing £890,000, regulatory investigation by three financial regulators, and suspension of the transaction screening agent pending full subprocessor chain re-assessment.

Scenario C — Cascading Subprocessor Failure Across Agent Pipeline: A cross-border e-commerce agent relies on a vendor for multi-language translation and localisation. The vendor subcontracts to three regional translation services: one for European languages, one for East Asian languages, and one for Arabic and right-to-left scripts. The East Asian translation subprocessor experiences a catastrophic infrastructure failure and, without notifying the primary vendor, fails over to a consumer-grade machine translation API with no data processing agreement, no data residency guarantees, and a terms-of-service clause granting the API provider a licence to use submitted text for model training. Over 72 hours, 31,000 customer product inquiries containing names, shipping addresses, and order details are processed through the consumer API. The primary vendor discovers the failover only when a customer reports garbled translations on social media.

What went wrong: The subprocessor chain included a second-tier subprocessor (translation services) that itself had an undocumented failover arrangement with a consumer API (third tier). No contractual flow-down prohibited unilateral failover to unapproved processors. The deploying organisation's subprocessor registry listed only the primary vendor. No monitoring detected the quality degradation or data routing change. Consequence: GDPR and local data protection violations across 14 jurisdictions, customer notification obligations for 31,000 records, €1.7 million in regulatory fines across jurisdictions, and permanent termination of the translation vendor relationship.

4. Requirement Statement

Scope: This dimension applies to every AI agent deployment where data, operational instructions, model inputs, model outputs, or telemetry flow through any entity other than the deploying organisation itself. The term "subprocessor" includes any third party, fourth party, or Nth party in the processing chain that receives, processes, stores, transmits, caches, logs, or can access any data or operational artefact originating from or destined for the agent pipeline. This includes inference providers, cloud infrastructure operators, content delivery networks, monitoring and observability services, translation services, data enrichment providers, embedding generation services, vector database hosts, and any other entity in the data path. The scope extends to failover arrangements, disaster recovery sites, and load-balancing targets — any entity that may process data under any operational condition, not only normal operation. Organisations that deploy agents entirely on-premises with no external data flows are exempt, but must re-assess if any external integration is added.

4.1. A conforming system MUST maintain a subprocessor registry that catalogues every entity in the processing chain — from first-tier direct vendors through to the last entity that can access, process, or store agent pipeline data — with each entry recording the entity's legal name, domicile jurisdiction, processing location(s), data categories processed, contractual basis, approval status, and date of last assessment.

4.2. A conforming system MUST require documented, affirmative approval by a designated governance authority before any new subprocessor is engaged or any existing subprocessor relationship is materially changed (including change of control, change of processing location, change of data categories processed, or change of sub-subprocessor arrangements).

4.3. A conforming system MUST enforce contractual flow-down obligations requiring each subprocessor to (a) disclose its own subprocessors to the next entity upstream in the chain, (b) obtain approval before engaging new sub-subprocessors, and (c) maintain data protection, security, and governance standards at least equivalent to those required of the primary vendor.

4.4. A conforming system MUST implement monitoring that detects subprocessor chain changes — including undisclosed substitutions, failover activations, load-balancing routing changes, and changes of control — within the notification SLA defined in the subprocessor agreement (maximum 72 hours from the change event).

4.5. A conforming system MUST conduct periodic reassessment of all subprocessors at a defined cadence (minimum annually for high-risk/critical subprocessors, minimum every 24 months for standard subprocessors), evaluating continued compliance with contractual, regulatory, and governance requirements.

4.6. A conforming system MUST define and enforce a subprocessor termination procedure that can be executed within a defined timeframe (maximum 30 calendar days for high-risk/critical subprocessors) when a subprocessor fails to meet governance requirements, including data retrieval, service migration, and confirmation of data deletion at the terminated subprocessor.

4.7. A conforming system MUST classify each subprocessor relationship by data sensitivity tier (aligned with AG-014) and by jurisdictional risk (aligned with AG-048), applying proportionate governance intensity to each tier.

4.8. A conforming system SHOULD implement automated subprocessor chain discovery that maps the actual data flow path — through network monitoring, API call tracing, or data lineage tracking — and compares the discovered path against the approved subprocessor registry, flagging discrepancies.

4.9. A conforming system SHOULD maintain a subprocessor risk score that aggregates factors including jurisdictional risk, data sensitivity, financial materiality, single-point-of-failure status, and historical compliance record, using this score to prioritise monitoring and reassessment.

4.10. A conforming system SHOULD require subprocessors to provide evidence of their own governance posture — including certifications, audit reports, and incident histories — as a condition of continued approval.

4.11. A conforming system MAY implement real-time subprocessor chain visualisation that displays the current, live processing chain for each agent deployment, updated as routing changes occur.

5. Rationale

The modern AI agent supply chain is not a simple bilateral relationship between a deploying organisation and a single vendor. It is a multi-layered graph of subprocessor relationships that can extend five or more tiers deep. A deploying organisation contracts with a vendor for AI agent capabilities. That vendor uses a large language model hosted by a cloud inference provider. The inference provider runs on GPU clusters leased from a hardware-as-a-service company. Telemetry from the inference provider flows to an observability platform hosted on a different cloud provider. The observability platform stores logs in a data warehouse operated by yet another entity. Each of these entities — and any entity they in turn subcontract — can access, process, or store data that originated from the deploying organisation's agent pipeline.

This multi-layered structure creates three governance risks that cannot be managed without explicit subprocessor governance. First, regulatory accountability dilution. Under GDPR Article 28, the data controller remains accountable for the actions of all processors and sub-processors in the chain. Under the EU AI Act, the deployer of a high-risk AI system must ensure that the system operates within its intended purpose and risk management framework — regardless of how many subprocessors are involved. Regulatory accountability does not dilute as the chain extends; it remains with the deploying organisation. But practical visibility and control do dilute: the deploying organisation may not know who the fourth-tier entity is, let alone whether it complies with applicable requirements.

Second, contractual obligation decay. Contractual protections negotiated with the primary vendor — data residency requirements, deletion obligations, security standards, incident notification timelines — apply only to the parties to the contract. Unless the contract explicitly requires flow-down to subprocessors, these obligations stop at the first tier. A data residency requirement that binds the primary vendor but not the compute provider that actually processes the data is an illusory control. Subprocessor governance requires contractual flow-down that extends governance obligations to every entity in the chain.

Third, change-of-control and substitution risk. Subprocessors are not static entities. They are acquired, merged, restructured, and replaced. A subprocessor that was domiciled in the EU and certified to ISO 27001 at the time of approval may, 18 months later, be acquired by an entity in a different jurisdiction with different governance standards. Without monitoring for change events and a re-approval mechanism, the original assessment becomes stale and the deploying organisation's governance posture is based on outdated information.

The financial sector has long recognised subprocessor risk in the context of cloud outsourcing. The European Banking Authority's Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) explicitly require institutions to assess the entire chain of subcontractors. DORA (Regulation 2022/2554) Articles 28-30 require financial entities to maintain registers of all ICT third-party service providers, including subcontractors. These regulatory requirements reflect the same fundamental risk that AG-493 addresses: you cannot govern what you cannot see, and in a multi-layered subprocessor chain, visibility requires deliberate, structured governance.

For AI agents specifically, subprocessor risk is amplified by the sensitivity and volume of data flowing through the pipeline. Agent inputs may include personal data, financial data, health data, or classified information. Agent outputs may include decisions with legal or financial consequences. Inference telemetry may reveal proprietary business logic, customer behaviour patterns, or competitive intelligence. Every subprocessor in the chain that can access this data represents a potential point of breach, misuse, or regulatory non-compliance. Subprocessor governance is therefore not an administrative overhead — it is a critical control that protects the integrity of the entire agent governance framework.

6. Implementation Guidance

Subprocessor governance requires a combination of registry management, contractual architecture, monitoring infrastructure, and organisational processes. The core principle is end-to-end visibility: the deploying organisation must know every entity that can touch its agent pipeline data, must have contractual authority over that entity's data handling, and must be able to detect and respond to changes in the subprocessor chain.

Recommended patterns:

• Tiered subprocessor registry with automated ingestion. Maintain a registry that is not limited to first-tier vendors but extends to every known entity in the processing chain. Structure the registry in tiers: Tier 1 (direct contractual relationship), Tier 2 (vendor's subprocessors), Tier 3 (sub-subprocessors), and so on. Populate the registry through contractual disclosure requirements, vendor questionnaires, and — where possible — automated discovery. Each registry entry should include: legal entity name, registration number, domicile jurisdiction, data processing locations, data categories processed, contractual basis (direct or flow-down), approval status, approval date, next reassessment date, and risk classification. The registry should be the single source of truth for all subprocessor-related governance decisions.
• Contractual flow-down with explicit sub-subprocessor clauses. Structure vendor contracts to require: (a) disclosure of all subprocessors at contract inception, (b) prior written approval before engaging new subprocessors or materially changing existing subprocessor arrangements, (c) notification within a defined SLA (recommended: 48 hours) of any subprocessor change of control, security incident, or regulatory action, (d) flow-down of equivalent data protection, security, and governance obligations to all sub-subprocessors, and (e) audit rights extending to subprocessors. Use standardised subprocessor addenda that can be appended to vendor contracts rather than negotiating bespoke terms for each relationship.
• Change-of-control monitoring through corporate registry feeds. Subscribe to corporate registry change notifications, beneficial ownership databases, and sanctions list updates for all entities in the subprocessor registry. Automate alerting when a registered subprocessor undergoes a change of control, domicile change, or appears on a sanctions or restricted entity list. This provides an independent detection channel that does not rely on the subprocessor's own notification.
• Data flow tracing with registry reconciliation. Implement technical data flow monitoring — through API gateway logs, network flow analysis, or embedded data lineage tags — that traces the actual path of agent pipeline data through the processing chain. Periodically reconcile the observed data flow path against the approved subprocessor registry. Flag any entity receiving data that is not in the registry (indicating an undisclosed subprocessor) or any registered entity not observed in the data flow (indicating a stale registry entry).
• Subprocessor exit playbook. Pre-plan the exit from every critical subprocessor relationship. The playbook should document: alternative subprocessors or in-house capabilities, data retrieval procedures, migration timelines, service continuity measures during transition, and confirmation procedures for data deletion at the departing subprocessor. Test the exit playbook annually through tabletop exercises.

Anti-patterns to avoid:

• First-tier-only visibility. Governing only the entities with which the organisation has a direct contractual relationship. This leaves the majority of the processing chain — often the riskiest part — ungoverned.
• Point-in-time approval without reassessment. Approving a subprocessor once at contract inception and never reassessing. Subprocessor risk profiles change through acquisitions, regulatory actions, security incidents, and operational changes. Approval without reassessment is approval of a snapshot that becomes stale immediately.
• Reliance on vendor self-attestation without verification. Accepting vendor statements about their subprocessor chain without independent verification. Vendors may not have full visibility into their own subprocessor chains, or may have commercial incentives to understate the complexity of their arrangements.
• Vague contractual notification requirements. Using terms like "reasonable time," "promptly," or "without undue delay" for subprocessor change notification. These terms are ambiguous and unenforceable. Use specific SLAs: 48 hours for critical changes, 5 business days for material changes, next quarterly report for administrative changes.
• Separate registries per vendor or per department. Maintaining fragmented subprocessor registries that cannot be consolidated for cross-vendor analysis. A single subprocessor entity may appear in multiple vendor chains; without a consolidated registry, the organisation cannot assess its aggregate dependency on that entity.

Industry Considerations

Financial Services. Regulatory requirements under DORA, EBA outsourcing guidelines, and national regulators (FCA, BaFin, ACPR) require financial institutions to maintain comprehensive registers of ICT third-party providers and their subcontractors. Financial institutions should align their AG-493 subprocessor registry with the DORA Article 28(3) register format to satisfy both governance and regulatory requirements with a single artefact. The 72-hour notification SLA for critical subprocessor changes aligns with DORA Article 19 incident reporting timelines.

Healthcare. Subprocessors handling protected health information must comply with jurisdiction-specific health data regulations (HIPAA in the US, Article 9 of GDPR in the EU, national health data protection laws). Healthcare organisations should require Business Associate Agreements (US) or equivalent health-data-specific processing agreements at every tier of the subprocessor chain. The sensitivity of health data means that any undisclosed subprocessor engagement is a potential reportable breach.

Public Sector. Government agencies deploying AI agents must comply with government procurement regulations, security clearance requirements, and often national security restrictions on data processing locations and entity nationalities. Subprocessor chains that extend to entities in adversarial jurisdictions or to entities without required security clearances create national security risks beyond data protection concerns.

Crypto/Web3. Decentralised infrastructure complicates subprocessor governance. Node operators, validator networks, and decentralised storage providers may not have formal legal entities. Organisations deploying agents in Web3 environments must determine how decentralised infrastructure participants map to the subprocessor governance model and apply proportionate controls.

Maturity Model

Basic Implementation — The organisation maintains a subprocessor registry covering at least first-tier and second-tier entities for all agent deployments. Each entry includes the required metadata fields. New subprocessors require documented approval before engagement. Vendor contracts include subprocessor disclosure and notification clauses. Reassessment occurs annually for all registered subprocessors. A termination procedure exists and has been documented.

Intermediate Implementation — All basic capabilities plus: the registry extends to all known tiers (third-tier and beyond). Contractual flow-down is standardised across all vendor relationships. Change-of-control monitoring provides automated alerts for registered entities. Data flow tracing validates the actual processing path against the approved registry at least quarterly. Subprocessor risk scores prioritise monitoring intensity. Exit playbooks exist for all critical subprocessor relationships and are tested through tabletop exercises.

Advanced Implementation — All intermediate capabilities plus: real-time subprocessor chain visualisation shows the current processing path for each agent deployment. Automated data flow tracing runs continuously and alerts on registry discrepancies within hours. The subprocessor registry is integrated with the organisation's enterprise risk management system, providing aggregate subprocessor concentration risk analysis. Independent audits of the subprocessor chain are conducted annually. The organisation can demonstrate end-to-end governance visibility from first tier to last entity for every agent deployment.

7. Evidence Requirements

Required artefacts:

• Subprocessor registry. The current registry showing all entities in the processing chain for each agent deployment, with all required metadata fields (legal name, domicile, processing locations, data categories, contractual basis, approval status, risk classification, last assessment date). The registry must distinguish between first-tier, second-tier, and deeper-tier entities.
• Approval records. Documented approval decisions for each subprocessor engagement, including the approver's identity, date of approval, assessment performed, conditions of approval, and any restrictions imposed. Must cover initial approvals and re-approvals following material changes.
• Contractual flow-down evidence. Copies or summaries of contractual clauses requiring subprocessor disclosure, approval, notification, and flow-down in each vendor agreement. Must demonstrate that flow-down extends beyond the first tier.
• Monitoring and detection records. Logs of subprocessor chain monitoring activities, including change-of-control alerts, data flow tracing results, registry reconciliation outputs, and any discrepancies detected with their resolution status.
• Reassessment records. Documentation of periodic subprocessor reassessments, including the reassessment methodology, findings, and any resulting changes to approval status or risk classification.
• Termination procedure documentation. The documented termination procedure for each critical subprocessor, including the exit playbook and records of any termination exercises or actual terminations executed.

Retention requirements:

• Subprocessor registry versions and approval records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Monitoring and detection logs: minimum 3 years for all sectors.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. The subprocessor registry must be producible in machine-readable format (JSON, CSV, or structured export). Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Test 8.1: Subprocessor Registry Completeness

• Stimulus: Select 3 agent deployments at random. For each, perform an independent data flow trace (through API gateway logs, network analysis, or vendor inquiry) to identify all entities in the processing chain. Compare the discovered entities against the subprocessor registry.
• Expected behaviour: Every entity discovered in the data flow trace appears in the subprocessor registry with complete metadata. No undisclosed entities exist in the processing chain.
• Pass criteria: 100% of discovered entities are present in the registry with all required metadata fields populated. Zero undisclosed entities.
• Fail criteria: Any entity in the actual processing chain is missing from the registry, or any registry entry lacks required metadata fields.

Test 8.2: Approval Enforcement for New Subprocessors

• Stimulus: Simulate a vendor notification of a new subprocessor engagement (provide a test notification through the contractual notification channel). Verify that the system prevents the new subprocessor from receiving agent pipeline data until documented approval is granted by the designated governance authority.
• Expected behaviour: The new subprocessor notification is received and logged. A governance review is initiated. No data flows to the new subprocessor until approval is documented.
• Pass criteria: The approval workflow is triggered within the defined SLA. No data flows to the unapproved subprocessor. Approval requires documented assessment and affirmative authorisation by the designated governance authority.
• Fail criteria: Data flows to the new subprocessor before approval, or the approval process does not require documented assessment, or approval is granted without governance authority sign-off.

Test 8.3: Contractual Flow-Down Verification

• Stimulus: Select 5 vendor contracts at random. For each, verify that the contract contains clauses requiring: (a) subprocessor disclosure, (b) prior approval for new subprocessors, (c) notification within the defined SLA for material changes, and (d) flow-down of equivalent obligations to sub-subprocessors. Then select 2 second-tier subprocessor agreements (obtained through audit rights) and verify equivalent clauses exist.
• Expected behaviour: All 5 vendor contracts contain the required clauses. Both second-tier agreements contain equivalent flow-down clauses.
• Pass criteria: 100% of sampled contracts contain all required flow-down clauses. Second-tier agreements demonstrate flow-down is operational, not merely contractual.
• Fail criteria: Any sampled contract lacks a required clause, or second-tier agreements do not contain equivalent obligations.

Test 8.4: Change Detection and Notification Compliance

• Stimulus: Review the last 12 months of subprocessor change events (new subprocessors, changes of control, processing location changes, substitutions). For each event, verify: (a) the event was detected, (b) detection occurred within the defined SLA, (c) the subprocessor registry was updated, and (d) re-approval was obtained where required.
• Expected behaviour: All change events were detected within the SLA. The registry reflects all changes. Re-approval was obtained for material changes.
• Pass criteria: 100% of known change events were detected within the SLA. Registry updates are complete and accurate. Re-approval records exist for all material changes.
• Fail criteria: Any change event was not detected, or detection exceeded the SLA, or the registry was not updated, or material changes lack re-approval records.

Test 8.5: Periodic Reassessment Compliance

• Stimulus: Select all subprocessors classified as high-risk/critical. Verify that each has been reassessed within the required cadence (12 months). Select a sample of standard subprocessors and verify reassessment within 24 months.
• Expected behaviour: All high-risk/critical subprocessors have been reassessed within 12 months. Sampled standard subprocessors have been reassessed within 24 months.
• Pass criteria: 100% of high-risk/critical subprocessors have current reassessments. 100% of sampled standard subprocessors have current reassessments.
• Fail criteria: Any high-risk/critical subprocessor lacks a reassessment within 12 months, or any sampled standard subprocessor lacks a reassessment within 24 months.

Test 8.6: Termination Procedure Executability

• Stimulus: Select one critical subprocessor relationship and execute a tabletop termination exercise. Verify that the exit playbook covers: identification of alternative processing, data retrieval procedures, migration timeline, service continuity measures, and data deletion confirmation. Measure whether the documented termination timeline (maximum 30 calendar days for high-risk/critical) is achievable based on the exercise.
• Expected behaviour: The exit playbook covers all required elements. The tabletop exercise identifies no blocking gaps. The 30-day timeline is assessed as achievable or documented exceptions exist with mitigation plans.
• Pass criteria: Exit playbook covers all required elements. No blocking gaps identified. Timeline is achievable or exceptions are documented with mitigations.
• Fail criteria: The exit playbook is missing required elements, or blocking gaps are identified with no mitigation, or the termination timeline exceeds 30 days with no documented exception.

Test 8.7: Subprocessor Classification Alignment

• Stimulus: Select 10 subprocessor entries from the registry. Verify that each entry's data sensitivity classification aligns with the data categories processed (per AG-014) and that the jurisdictional risk classification aligns with the processing locations (per AG-048). Verify that governance intensity (monitoring frequency, reassessment cadence, contractual protections) is proportionate to the classification.
• Expected behaviour: Classifications are consistent with the data and jurisdictional profile of each subprocessor. Governance intensity is proportionate.
• Pass criteria: All 10 entries have consistent classifications and proportionate governance intensity. No misclassifications detected.
• Fail criteria: Any entry has a classification inconsistent with its data or jurisdictional profile, or governance intensity is not proportionate to the risk classification.

Conformance Scoring

• Score 0: No subprocessor registry exists, or the registry covers only first-tier vendors with no visibility into deeper tiers. No approval process for new subprocessors. Contractual flow-down is absent.
• Score 1: A subprocessor registry exists covering first-tier and some second-tier entities. New subprocessors require approval, but the process is informal or inconsistently applied. Contracts contain subprocessor clauses, but flow-down to deeper tiers is not verified. Reassessment occurs but not at a defined cadence.
• Score 2: The registry covers all known tiers with complete metadata. Approval is formally documented and enforced. Contractual flow-down is verified through audit rights. Reassessment occurs at the defined cadence. Monitoring detects change events within the SLA. Termination procedures exist and have been tested.
• Score 3: Verified through independent testing confirming end-to-end subprocessor chain visibility. Real-time data flow tracing validates the registry continuously. Change-of-control monitoring operates through independent channels (corporate registries, sanctions feeds). Exit playbooks are tested annually. The organisation can demonstrate complete chain governance from first tier to last entity for every agent deployment.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 25 (Obligations of Distributors)	Supports compliance
GDPR	Article 28 (Processor)	Direct requirement
GDPR	Article 44-49 (Transfers to Third Countries)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	8.1 (Outsourcing Requirements)	Direct requirement
NIST AI RMF	GOVERN 5.1, MAP 3.4	Supports compliance
ISO 42001	Clause 8.4 (Externally Provided Processes, Products and Services)	Direct requirement
DORA	Articles 28-30 (ICT Third-Party Risk)	Direct requirement

GDPR — Article 28 (Processor)

Article 28 establishes the foundational legal requirement for subprocessor governance in the context of personal data processing. Article 28(2) requires that a processor shall not engage another processor without prior specific or general written authorisation of the controller. Where general written authorisation is granted, the processor must inform the controller of any intended changes concerning the addition or replacement of other processors, giving the controller the opportunity to object. Article 28(4) requires that where a processor engages another processor, the same data protection obligations as set out in the contract between the controller and processor shall be imposed on that other processor by way of a contract — this is the legal basis for contractual flow-down. AG-493 operationalises Article 28 for AI agent deployments by requiring a registry (visibility), approval (authorisation), flow-down (contractual propagation), and monitoring (ongoing compliance). Organisations that comply with AG-493 will have the governance infrastructure needed to demonstrate Article 28 compliance across the full subprocessor chain.

GDPR — Articles 44-49 (Transfers to Third Countries)

Subprocessor chains that extend across jurisdictions may involve transfers of personal data to third countries that lack an EU adequacy decision. Each entity in the subprocessor chain that is located outside the EU/EEA represents a potential transfer requiring legal basis under Articles 44-49 — Standard Contractual Clauses, Binding Corporate Rules, or an adequacy decision. AG-493's requirement to record processing locations for every entity in the chain (Requirement 4.1) and to classify by jurisdictional risk (Requirement 4.7) provides the visibility necessary to identify all cross-border transfers and ensure each has an appropriate legal basis.

DORA — Articles 28-30 (ICT Third-Party Risk)

DORA imposes direct requirements on financial entities to manage ICT third-party risk, including subcontracting arrangements. Article 28(3) requires financial entities to maintain a register of all contractual arrangements on the use of ICT services provided by ICT third-party service providers, including information on subcontracting chains. Article 29 requires key contractual provisions including: conditions for subcontracting, notification requirements for subcontracting changes, and audit rights extending to subcontractors. Article 30 requires prior approval for subcontracting critical or important functions. AG-493's subprocessor registry, approval process, contractual flow-down, and audit rights requirements directly support DORA compliance.

FCA SYSC — 8.1 (Outsourcing Requirements)

The FCA requires firms to exercise due skill, care, and diligence in entering into, managing, and terminating outsourcing arrangements. SYSC 8.1.8R specifically addresses sub-outsourcing: firms must ensure that the service provider discloses any sub-outsourcing arrangements and that sub-outsourcing does not undermine the firm's ability to comply with regulatory requirements. The FCA's expectation that firms maintain oversight of the entire outsourcing chain aligns directly with AG-493's end-to-end subprocessor governance requirements.

EU AI Act — Article 9 (Risk Management System)

The AI Act requires that risk management systems identify and mitigate risks arising from the AI system's operational context, which includes the supply chain. Subprocessor chains create risks including data sovereignty violations, security exposure through unassessed entities, and loss of governance control. AG-493's systematic approach to subprocessor identification, assessment, and monitoring directly supports the risk management obligations under Article 9.

ISO 42001 — Clause 8.4 (Externally Provided Processes, Products and Services)

ISO 42001 requires that organisations ensure externally provided processes, products, and services that affect the AI management system conform to requirements. This includes determining the controls to apply to external providers and ensuring that the provision of these processes does not adversely affect the organisation's ability to consistently deliver conforming AI systems. AG-493's governance framework for subprocessors directly implements Clause 8.4 for AI agent deployments.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — a subprocessor failure can affect every agent deployment that shares the subprocessor chain, potentially impacting all data subjects, all transactions, and all jurisdictions served by those agents simultaneously

Consequence chain: An ungoverned subprocessor chain begins with invisible exposure — data flowing to entities the deploying organisation has not assessed, approved, or contractually bound. The first-order technical failure is loss of data provenance: the organisation cannot trace where agent pipeline data is processed, stored, or accessible. The second-order governance failure is accountability gap: the organisation remains legally and regulatorily accountable for actions taken by entities it does not know exist. The third-order operational failure is cascading impact: a security breach, regulatory action, or operational failure at any undisclosed entity in the chain propagates to the deploying organisation without warning, because no monitoring or notification channel exists for undisclosed entities. The business consequences include: regulatory fines for unauthorised data transfers (GDPR fines up to 4% of global annual turnover), sanctions violations for processing through entities in restricted jurisdictions (criminal liability for officers), loss of customer trust when data breach notifications reveal that customer data was processed by unknown entities, and operational disruption when critical subprocessors fail or are terminated without exit plans. The cascade is amplified when multiple agent deployments share the same subprocessor chain — a single subprocessor failure can simultaneously affect every agent in the organisation's portfolio that touches that chain, creating a correlated failure scenario with organisation-wide impact.

Cross-references: AG-014 (Data Classification Governance), AG-048 (Cross-Border Data Sovereignty Governance), AG-389 (Topology Inventory Governance), AG-399 (Region Pinning Governance), AG-427 (Mutual Aid and Vendor Coordination Governance), AG-492 (Contractor Access Segregation Governance), AG-494 (Vendor Incident Disclosure Governance), AG-495 (Procurement Security Requirement Governance).