DORA compliance gaps widen as AI expands ICT risk scope

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WitnessAI's blog post: DORA's five pillars break down when AI systems expand the ICT estate and create governance gaps in inventory, reporting, testing, and third-party oversight.

Why it matters: It matters because IAM, IGA, PAM, and security teams in financial institutions now have to prove that AI-related access, vendors, and failure modes are inside the same control system as the rest of the ICT environment.

Context

DORA is a governance problem before it is a compliance checklist. Financial institutions now have to show that ICT risk management, incident reporting, resilience testing, third-party oversight, and information sharing operate as one control system, not as separate policy silos.

AI adoption makes that harder because tools, models, agents, and vendors can appear outside formal procurement and inventory processes while still affecting regulated ICT services. When those dependencies are invisible, DORA evidence becomes fragile even if the written policy looks complete.

Key questions

Q: What breaks when AI tools are outside DORA inventories?

A: When AI tools, models, or agents are missing from inventories, the institution cannot prove which services, vendors, and dependencies are in scope. That weakens third-party oversight, concentration-risk analysis, and incident response because compliance evidence is built on incomplete records. The practical failure is not just undocumented software, but ungoverned regulated exposure.

Q: Why do AI vendors create DORA third-party risk even when procurement is approved?

A: 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.

Q: How do organisations know whether DORA controls are actually covering AI risk?

A: They should test whether AI-related assets appear in the inventory, whether contracts include audit and exit terms, and whether monitoring detects AI-specific failure modes. If those signals are missing, the control environment is not covering the full ICT estate and cannot be relied on for evidence.

Q: What should teams do when AI failure modes do not fit legacy incident workflows?

A: They should expand detection, classification, and escalation logic to include AI-specific failures such as prompt injection, data poisoning, and unauthorized AI access. If those events cannot be recognised early, the institution may miss the DORA reporting clock and lose the ability to explain impact, cause, and scope.

Technical breakdown

Why DORA compliance fails when AI is outside the inventory

DORA depends on a complete view of ICT assets, dependencies, and service relationships. If AI tools are adopted through shadow channels, they can bypass the Article 8 inventory, the Article 28(3) register of information, and concentration-risk analysis under Article 29. That creates a governance blind spot, not just a documentation gap. The technical failure is that the control system cannot assess what it cannot enumerate, so downstream risk decisions are built on incomplete scope.

Practical implication: treat AI discovery as a scope-control problem, not a procurement admin task.

How AI changes incident detection, reporting, and resilience testing

DORA’s incident clock starts once a major incident is classified, so detection quality directly affects compliance. AI-specific failure modes such as prompt injection, model hallucination, data poisoning, and unauthorized AI-to-AI interaction may not fit legacy monitoring rules, which means incidents can remain unclassified until the reporting window is already tight. The same issue affects resilience testing: annual tests and TLPT only help if AI-supported critical functions are actually in scope. Without that, testing measures the wrong estate.

Practical implication: extend detection and test scope to AI failure modes before relying on DORA reporting timelines.

Why third-party risk expands fastest through AI vendors

AI services often sit behind layered subcontracting chains and shared model infrastructure, which makes the third-party control problem more complex than a simple vendor list. Under DORA, the Register of Information, audit rights, exit arrangements, and subcontracting transparency are not optional evidence artifacts; they are the structure that makes oversight defensible. Where one model provider supports multiple internal tools, concentration risk can emerge even when no single business unit sees the full dependency chain.

Practical implication: reconcile AI vendor contracts, subcontracting chains, and the register of information as one governance dataset.

Threat narrative

Attacker objective: The practical objective is to exploit ungoverned AI dependencies so regulated services are disrupted before the institution can document, classify, and report the incident.

1. Entry occurs when AI tools, external models, or agent-based services are adopted outside formal procurement and inventory controls, creating untracked ICT dependencies.
2. Credential or service access is then inherited through API integrations, vendor relationships, or shared model services that were never fully registered under DORA oversight.
3. Impact follows when an AI-related failure or third-party disruption affects a critical function, but the institution lacks the visibility needed to detect, classify, and report it within the DORA clock.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now a DORA scope problem, not just an innovation problem. When AI tools sit outside procurement and asset inventory processes, the institution loses the evidence chain DORA requires across ICT risk, third-party oversight, and resilience. That means compliance can fail even where written policy exists, because the regulated surface area is larger than the governed one. The practitioner conclusion is to treat discovery as the first control.

AI turns DORA’s five pillars into a single evidence system. ICT risk management, incident reporting, resilience testing, third-party management, and information sharing only work when the same asset, vendor, and incident records feed all five. If AI usage is missing from the register of information or the third-party contract set, the rest of the framework becomes partially fictional. The practitioner conclusion is to unify control evidence instead of managing each pillar separately.

Third-party oversight is where AI adoption most quickly exposes governance debt. AI vendors often rely on layered subcontractors and shared infrastructure, which means concentration risk can be hidden behind apparently simple contracts. That is why the article’s key concept is AI governance visibility debt: the gap between AI usage and the records needed to defend oversight. The practitioner conclusion is to close that debt before the next audit cycle.

DORA forces AI risk into the same accountability model as the rest of ICT resilience. Boards cannot treat AI as an experimental overlay when it affects critical services, reporting timelines, and recovery obligations. The important shift is not that AI introduces a new compliance regime, but that it breaks the assumption that regulated ICT is fully knowable from existing inventories. The practitioner conclusion is to align operating ownership, not just policy language.

Financial institutions need defensible scope, not just broader monitoring. More telemetry does not solve missing governance if the institution cannot show where AI sits in the control framework, who owns the vendor relationship, and how that relationship is tested. DORA rewards traceable control boundaries, not generalized visibility claims. The practitioner conclusion is to make AI part of the same governance evidence pack as the rest of the ICT estate.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

AI governance visibility debt: The real risk is not that financial institutions lack DORA language, but that AI usage outruns the inventory, register, and contract evidence needed to prove scope. Once AI sits outside those records, the control system no longer describes the estate it is meant to govern.

A practical DORA programme now needs a single chain from discovery to oversight. That means the same AI asset record should drive third-party review, incident triage, resilience testing scope, and supervisory evidence, or the institution will keep rebuilding the same gap in different places.

For practitioners

• Build a complete AI and ICT asset inventory Identify every AI tool, model, and agent in use, including shadow AI adopted outside formal procurement. Tie each entry to the Article 8 inventory and the Article 28(3) register of information.
• Map AI systems to DORA control functions Connect each AI tool, model, and vendor relationship to identify, protect, detect, respond, and learn. Use the same control structure to track evidence across the ICT estate.
• Extend incident detection to AI failure modes Update monitoring and classification rules for model failures, data poisoning, prompt injection, and unauthorized AI access so incidents can be classified fast enough for DORA reporting.
• Include AI systems in resilience testing Put AI-supported critical functions into annual testing cycles and, where relevant, threat-led penetration testing. Make sure outsourced and internal AI services are both covered.
• Remediate AI provider contracts and records Refresh audit rights, exit strategies, subcontracting transparency, and data-location terms, then reconcile them with the register of information and concentration-risk assessments.

Key takeaways

• DORA compliance becomes fragile when AI systems are adopted faster than inventory, vendor, and incident processes can track them.
• The control failure is not only missing documentation. It is incomplete scope across third-party oversight, reporting, and resilience testing.
• The most effective response is to make AI discovery, contract coverage, and test coverage part of one defensible governance model.

Key terms

• Digital Operational Resilience Act: DORA is an EU regulatory framework that requires financial entities and their critical ICT providers to prove they can withstand, respond to, and recover from disruption. For identity teams, it turns authentication, access, and recovery into evidence-bearing controls rather than background IT functions.
• Register Of Information: A Register of Information is the live record a regulated organisation uses to describe its assets, dependencies, and controls. Under DORA, its value depends on accuracy, completeness, and the ability to reflect changes in the operating environment rather than storing a stale compliance snapshot.
• Concentration risk: The risk that too much operational dependence sits with one ICT provider or one tightly linked provider chain. For AI environments, concentration risk matters when the same model supplier, hosting layer, or API backbone underpins multiple business functions and becomes difficult to replace quickly.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.