Fourth-Party and Concentration Risk

Why This Topic Matters

Modern AI systems are rarely built from scratch. An organization that deploys a customer-facing chatbot may license it from a vendor, who in turn relies on a foundation model from one of a handful of frontier model providers, which itself runs on GPU infrastructure hosted by one of three hyperscale cloud providers, trained on data sourced from a small set of web-scale data aggregators. Every link in that chain is a point of failure, and most of those links are invisible to the organization that ultimately owns the business outcome and the regulatory liability.

This is why ISACA's Advanced in AI Risk (AAIR) body of knowledge treats fourth-party risk and concentration risk as core elements of AI risk program management. A risk practitioner who only assesses the vendor they sign a contract with is seeing perhaps 20 percent of the actual exposure. Regulators have noticed: the EU Digital Operational Resilience Act (DORA), the EU AI Act's value-chain obligations, US banking guidance on third-party relationships (OCC/FRB/FDIC 2023 interagency guidance), and the UK's Critical Third Parties regime all explicitly push firms to look beyond their direct suppliers. On the exam, you can expect questions that test whether you understand that accountability cannot be outsourced even when the work is, and that AI supply chains have a structural tendency toward dangerous concentration.

What It Is: Key Definitions

Third party - An external entity with which the organization has a direct contractual relationship: the AI vendor, the SaaS platform, the model API provider, the consulting firm fine-tuning your model.

Fourth party - An entity your third party relies on to deliver its service to you. You typically have no contract with them, no audit rights, and often no visibility. Examples in AI: the foundation model provider behind a vendor's AI feature; the cloud region hosting a vendor's inference servers; the data labeling subcontractor used by your model developer; the open-source library maintainers whose code is embedded in a vendor's product.

Nth party - The chain continues: fifth, sixth and beyond. The practical term nth-party risk acknowledges that the supply chain extends further than anyone can fully map, so the program must prioritize which deeper tiers actually matter.

Concentration risk - The exposure that arises when a significant portion of the organization's AI capability, data, or operations depends on a single provider, technology, location, or component, such that a failure, compromise, price change, or policy change in that one node creates disproportionate, correlated harm. Concentration risk exists at two levels:
- Firm-level concentration: your organization relies too heavily on one supplier or model.
- Systemic or sector-level concentration: many organizations (or an entire industry) depend on the same few providers, so a single outage or incident cascades across the market. Regulators care intensely about this form.

Types of Concentration Relevant to AI

1. Vendor concentration - Multiple business units independently procure AI tools that all turn out to run on the same provider, aggregating exposure nobody planned.
2. Model concentration - Dependence on a single foundation model family. If the provider deprecates a version, changes its acceptable use policy, alters pricing, or the model's behavior drifts after an update, every downstream application is affected simultaneously.
3. Infrastructure concentration - Reliance on a single cloud provider, region, or specialized hardware vendor (GPU/accelerator supply is notoriously concentrated).
4. Data concentration - Training or retrieval data sourced from one aggregator or one geography, creating correlated bias, licensing, and availability risk.
5. Geographic and jurisdictional concentration - Processing concentrated in a single country exposes the organization to local outages, political events, export controls, and data sovereignty conflicts.
6. Skills and personnel concentration - Only one team or one external partner understands how the AI system works; this is a people-based single point of failure.
7. Open-source component concentration - Widely used libraries and model weights (think of the Log4j or xz-utils lessons applied to ML frameworks and model hubs) create hidden shared dependencies.

How It Works: Managing Fourth-Party and Concentration Risk in an AI Risk Program

Step 1 - Discover and map the AI supply chain.
You cannot manage what you cannot see. The program should build and maintain an inventory of AI systems that records not just the direct vendor but the known sub-processors, foundation models, hosting locations, and critical components. Tools and artifacts that support this include a Software Bill of Materials (SBOM) extended into an AI Bill of Materials (AIBOM) covering model weights, training data provenance, fine-tuning datasets, and dependencies; vendor sub-processor lists (often published for GDPR purposes); and model cards and system cards that disclose underlying providers. Mapping should be proportionate: go deepest on the AI systems that are high-risk, customer-facing, or business-critical.

Step 2 - Classify criticality and assess risk.
Apply a tiering model. For each AI system, ask: What happens if this fourth party fails for a day, a week, permanently? Does the fourth party process personal or sensitive data? Could the fourth party's behavior (model updates, content filters, logging practices) change our system's outputs without our knowledge? Risk assessment should weigh likelihood and impact across confidentiality, integrity, availability, fairness, and compliance dimensions. Aggregate the results across the enterprise to reveal concentration: if 14 applications each look low-risk individually but all depend on one model API, the aggregate exposure is high.

Step 3 - Build controls into contracts.
Because you have no direct contract with a fourth party, your leverage comes through the third party. Key contractual mechanisms include:
- Flow-down clauses requiring the vendor to impose equivalent security, privacy, and AI governance obligations on its own suppliers.
- Sub-processor notification and objection rights so you learn when a critical fourth party changes.
- Transparency obligations requiring disclosure of foundation models used, hosting locations, and material changes to model versions.
- Audit and assurance rights including the right to receive SOC 2, ISO 27001, ISO/IEC 42001, or penetration test evidence covering the vendor and, where feasible, its critical subcontractors.
- Service level and incident notification terms that specifically cover upstream outages and upstream security incidents.
- Exit and transition assistance clauses including data portability, model artifact return, and reasonable notice before deprecation.

Step 4 - Reduce concentration deliberately.
Options include multi-vendor or multi-model strategies with abstraction layers that allow switching between model providers; multi-region or multi-cloud deployment for critical inference workloads; maintaining a fallback (even a degraded, rules-based or smaller self-hosted model) for critical functions; diversifying data sources; and documenting an exit strategy for each critical provider. Note the trade-off the exam will expect you to recognize: diversification costs money, adds complexity, and can itself introduce inconsistency risk. The goal is resilience proportionate to criticality, not elimination of all single dependencies.

Step 5 - Monitor continuously.
Point-in-time due diligence is insufficient for AI because models change. Continuous monitoring includes: tracking vendor and fourth-party security incidents, financial health, and regulatory actions; monitoring model behavior for drift that may indicate an upstream change; subscribing to deprecation notices and vulnerability feeds for embedded components; and periodically re-mapping the supply chain because vendors change their own suppliers.

Step 6 - Test resilience.
Scenario analysis and tabletop exercises should explicitly include fourth-party failure scenarios: the foundation model provider suffers a multi-day outage; a cloud region goes down; a key model is withdrawn for legal reasons; an upstream provider is acquired by a competitor; a critical open-source ML library is found to contain a backdoor. Business continuity and disaster recovery plans should name the fallback and the recovery time objective for each critical AI dependency.

Step 7 - Govern and report.
Concentration risk is a board-level topic. The AI risk program should report aggregate dependency metrics (for example, percentage of critical AI workloads on a single provider), key fourth-party incidents, and progress against remediation plans. Risk appetite statements should specify tolerable concentration thresholds. Roles should be clear: procurement, legal, information security, data governance, and the business owner all share responsibility, with the AI risk function coordinating.

Relevant Frameworks and Regulations to Know
- NIST AI RMF - Govern and Map functions call for understanding third-party and supply chain dependencies and for documenting AI components and their sources.
- ISO/IEC 42001 - Requires control of externally provided processes, products, and services relevant to the AI management system, and consideration of the supplier relationship lifecycle.
- ISO/IEC 23894 - AI risk management guidance that incorporates supply chain and context considerations.
- EU AI Act - Imposes obligations across the value chain (providers, deployers, importers, distributors) and includes specific rules for general-purpose AI models that downstream deployers depend on.
- DORA - Requires financial entities to manage ICT third-party risk including concentration risk and sub-outsourcing, and designates critical ICT third-party providers for direct oversight.
- Interagency Guidance on Third-Party Relationships (US, 2023) - Emphasizes that a banking organization's use of third parties does not diminish its responsibility, and highlights subcontractor (fourth-party) risk.
- COBIT and ISACA risk practices - Vendor management, risk aggregation, and the principle that accountability remains with the enterprise.

Common Pitfalls
- Assuming a vendor's SOC 2 report covers their subcontractors (it usually carves them out).
- Treating open-source models and libraries as having no supply chain risk because there is no vendor.
- Allowing shadow AI procurement that silently concentrates on one provider.
- Confusing diversification with resilience: two vendors that both run on the same cloud region are not truly diversified.
- Letting exit strategies exist only on paper, never tested, with no data or prompt portability.

Exam Tips: Answering Questions on Fourth-Party and Concentration Risk

Tip 1 - Accountability never transfers. If an answer option implies that the organization is not responsible because the failure occurred at a subcontractor or foundation model provider, it is wrong. The organization that deploys the AI system retains accountability for outcomes, compliance, and customer impact. ISACA exams consistently reward the answer that keeps ownership with the enterprise.

Tip 2 - Look for the aggregation clue. When a scenario describes several business units, several applications, or several vendors that all turn out to share one underlying provider, the question is testing concentration risk. The best answer usually involves enterprise-wide inventory, aggregation of dependency data, or reporting the concentration to governance bodies, not merely assessing each vendor separately.

Tip 3 - Visibility first, then control. If the scenario says the organization does not know who its fourth parties are, the first step is discovery and mapping (inventory, AIBOM, sub-processor lists), not writing new contract clauses or switching vendors. Questions that ask for the FIRST or MOST IMPORTANT step typically want the foundational visibility action.

Tip 4 - Your lever on a fourth party is the contract with the third party. When asked how to gain assurance over a fourth party, the correct answer typically involves flow-down clauses, sub-processor notification rights, requiring the vendor to provide assurance evidence covering its subcontractors, or right-to-audit provisions, not attempting to contract directly with an entity you have no relationship with.

Tip 5 - Proportionality and risk-based prioritization. Answers that propose mapping every nth party for every AI tool, or requiring full on-site audits of all subcontractors, are usually distractors because they are impractical. Prefer answers that tier by criticality and focus deep diligence on high-risk, business-critical dependencies.

Tip 6 - Recognize the trade-off language. Multi-vendor and multi-model strategies reduce concentration but add cost and complexity. If a question asks about the downside of diversification or why an organization might accept some concentration, the answer will mention cost, integration complexity, inconsistency of outputs, or governance overhead. Risk management is about aligning with risk appetite, not zero risk.

Tip 7 - Continuous, not point-in-time. For AI specifically, a model update by a fourth-party provider can change behavior overnight. Answers involving ongoing monitoring, drift detection, version pinning, and change notification generally beat answers relying solely on annual due diligence questionnaires.

Tip 8 - Exit strategy and resilience testing are hallmarks of maturity. If a question asks what distinguishes an effective program from a basic one, or what a regulator would expect for a critical AI dependency, look for documented and tested exit strategies, identified fallback capabilities, and scenario testing of upstream failure.

Tip 9 - Systemic concentration is a regulatory concern. Questions referencing financial services, DORA, or critical infrastructure may be testing whether you recognize that regulators worry about many firms depending on the same provider. The organization's response should include awareness of sector-wide dependence and engagement with regulatory expectations, not just internal diversification.

Tip 10 - Watch the keyword in the stem. Terms like sub-processor, subcontractor, underlying model provider, hosted on, or built on signal fourth-party risk. Terms like single provider, same cloud region, all applications rely on, or market share signal concentration risk. Identify which concept is being tested before evaluating the options.

Quick Recap
Fourth-party risk is the exposure created by your vendors' vendors; concentration risk is the exposure created when too much depends on too few. In AI, both are amplified because the ecosystem rests on a small number of foundation models, cloud providers, hardware suppliers, and data sources. An effective AI risk program maps the chain, tiers by criticality, embeds flow-down and transparency terms in contracts, deliberately manages concentration against risk appetite, monitors continuously, tests resilience, and reports to governance. On the exam, choose the answer that keeps accountability with the enterprise, starts with visibility, uses contractual leverage, applies proportionality, and treats the problem as ongoing rather than one-time.