Approved procurement does not eliminate DORA risk if the provider uses subcontractors, shared infrastructure, or hidden model dependencies that the contract does not disclose. The compliance issue is whether the institution can demonstrate audit rights, exit paths, and full visibility into the service chain, not whether a purchase order exists.
Why procurement approval does not clear DORA third-party risk
Approved procurement answers the buying decision, not the operational resilience question. Under DORA, the institution still has to understand who actually delivers the service, what dependencies sit behind the vendor, and whether those hidden providers can affect availability, confidentiality, or recoverability. If the service chain is opaque, the risk remains even when purchasing was formally authorised.
A vendor can pass procurement review and still create regulatory exposure if its subcontractors, hosting layer, model providers, or support pathways are outside the institution’s visibility. DORA third-party risk is about control over the ICT service chain, not just contract signature.
That distinction matters because many AI services are assembled from multiple layers, including inference hosting, foundation-model access, logging, observability, data retention, and managed support. Each layer can introduce additional third parties, cross-border dependencies, and failover assumptions that procurement may never surface.
What hidden AI service dependencies change under DORA
The real issue is not whether the vendor is “approved”, but whether the institution can evidence the chain of control it relies on. That includes audit rights, exit rights, subcontractor transparency, resilience testing, incident notification, and a realistic ability to replace the service without business disruption. In other words, the buying process may be complete while the EU Digital Operational Resilience Act (DORA) obligations are still unproven.
AI vendors often bundle models, orchestration, content moderation, telemetry, and cloud infrastructure in ways that are hard to separate. That means the institution may not know which party stores prompts, which party can inspect outputs, or which subcontractor is responsible when an outage, data exposure, or service degradation occurs.
Those hidden dependencies also weaken assurance. If the vendor cannot identify every material subprocessor or cannot explain how data and workloads move through the chain, then the institution cannot confidently assess concentration risk, contingency planning, or the operational impact of vendor failure.
What evidence makes an AI vendor DORA-ready
Practitioners should treat the vendor file as incomplete until the service chain is documented in a way that supports audit, resilience, and exit decisions. Procurement approval should be followed by a check of who the vendor uses, where the service runs, what data flows exist, and whether the institution has enough contractual leverage to test, inspect, and unwind the relationship.
For AI vendors, that usually means asking for clear subcontractor disclosure, a map of critical data and compute dependencies, and evidence that the vendor can support orderly termination. If the vendor relies on downstream providers for model hosting or tooling, those dependencies should be reflected in the institution’s own third-party register and risk assessment, not treated as invisible implementation detail.
Practitioners should also distinguish commercial approval from operational acceptance. A purchase order may confirm budget and legal review, but it does not prove that the vendor can satisfy DORA ICT third-party risk management expectations for oversight, continuity, and exitability.
Risk and Threat Considerations
AI services concentrate dependency risk because the visible vendor may only be one layer in a larger chain. If subcontractors, cloud hosts, or model providers fail, the institution can lose service continuity, lose access to records, or discover too late that contractual remedies do not reach the actual operator of a critical component.
Failure mechanism: Procurement approval can mask undisclosed downstream providers, so the institution cannot verify audit rights, operational control, or a workable exit path across the full ICT service chain.
Impact: The institution may face unresolved third-party concentration risk, weaker incident response, disrupted recovery, and a defensibility gap during supervisory review or audit.
Framework Alignment
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while DORA and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Digital Operational Resilience Act | DORA directly governs ICT third-party risk, oversight, and exitability for financial entities. |
| Recommendation — Map the full AI service chain and verify audit rights, continuity, and exit plans before acceptance. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Strategy | Service-chain opacity is a supply-chain governance problem that affects third-party risk decisions. |
| Recommendation — Document supplier dependencies and assess downstream risk before relying on the vendor. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | AI vendors create supplier-risk exposure when subcontractors and dependencies are undisclosed. |
| A.5.20 — Addressing information security within supplier agreements | Audit, exit, and disclosure rights must be written into the supplier contract. | |
| Recommendation — Require supplier transparency and security obligations for all material downstream providers. Insert contractual rights for audit, disclosure, incident notice, and termination. | ||
| CSA Cloud Controls Matrix | GRC — Governance, Risk and Compliance | Cloud-hosted AI services raise governance and third-party accountability questions. |
| Recommendation — Assess the provider’s governance for subcontractors, resilience, and compliance evidence. | ||
Practitioner Guidance
What to verify: Require a named service-chain map that shows the vendor’s material subcontractors, hosting dependencies, data processing locations, and any model or platform providers that can affect service delivery. If the vendor will not disclose those dependencies, treat that as a risk finding, not a paperwork issue.
Decision rule: If the AI service cannot demonstrate auditability, exitability, and continuity across all material third parties, do not classify it as low-risk just because procurement is approved. Escalate it for ICT risk review before the contract is treated as operationally accepted.
Practitioner takeaway: Under DORA, the control objective is visibility and recoverability across the service chain, not approval of the purchase itself.