DORA compliance gaps widen as AI expands ICT risk scope

At a glance

What this is: This is an analysis of how DORA’s five-pillared control model breaks down when AI tools, models, and agents expand the ICT environment.

Why it matters: It matters because IAM, NHI, PAM, and compliance teams must prove coverage across inventories, third-party records, monitoring, and testing before AI usage outruns governance.

👉 Read WitnessAI's analysis of DORA compliance gaps created by AI adoption

Context

DORA turns ICT governance into a regulated control system, not a paper exercise. For financial institutions in the EU, the issue is whether asset inventories, incident processes, resilience testing, and third-party oversight actually cover the full ICT estate, including AI-enabled tooling and delegated access paths.

The governance gap appears when AI is adopted outside formal procurement and inventory processes. Shadow AI can sit outside access registers, third-party records, and monitoring workflows, which means the organisation may be operating inside the regulation’s scope while still failing to evidence control coverage.

Key questions

Q: How should financial institutions include AI systems in DORA compliance programmes?

A: They should treat AI systems as in-scope ICT assets and connect them to inventory, incident reporting, resilience testing, and third-party governance. The practical step is to identify every AI tool, model, API, and agent, then map ownership, data flows, and contractual dependencies so DORA evidence remains defensible.

Q: Why do AI tools create DORA governance gaps in financial institutions?

A: AI tools often enter through shadow adoption, embedded features, or external APIs, which means they can be active before they are formally inventoried or contracted. That creates blind spots in registers, concentration analysis, and monitoring, so the institution may be compliant on paper but incomplete in practice.

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: Who is accountable when an AI-driven ICT incident triggers DORA reporting?

A: The management body remains accountable for ICT risk governance, even when the incident originates in a third-party AI service. Operational teams can support detection and reporting, but responsibility cannot be delegated away from the institution’s governing body.

Technical breakdown

DORA’s five pillars operate as one control system

DORA is designed so ICT risk management, incident reporting, resilience testing, third-party oversight, and information sharing reinforce each other. In practice, weak inventory discipline affects all five. If an AI tool, model, or agent is omitted from the asset register, it is harder to attach incident thresholds, testing scope, contractual controls, and supervisory evidence to it. That is why DORA should be read as a connected operating model rather than a checklist of separate obligations.

Practical implication: map every AI and ICT component to the five pillars before treating any one control as complete.

Why AI creates DORA visibility gaps

AI changes the control problem because it often enters the environment through APIs, embedded features, or shadow adoption rather than formal procurement. That means existing inventories can miss the tool itself, the third-party service behind it, and the data flows it creates. Once that happens, concentration risk, register accuracy, and contractual coverage all degrade together. The issue is not simply that AI is new, but that it can be operationally active while administratively invisible.

Practical implication: treat AI discovery as a governance dependency, not a technical nice-to-have.

Incident clocks, resilience tests, and AI failure modes

DORA’s reporting and testing obligations assume teams can detect and classify incidents fast enough to start the reporting clock. AI-specific failure modes such as model hallucination, prompt injection, and unauthorized AI-to-AI interaction may evade conventional monitoring, which creates a timing problem as much as a detection problem. If the organisation cannot see the event in time, it cannot defend its reporting timeline or prove that resilience testing covered the relevant failure path.

Practical implication: extend monitoring and test cases to AI failure modes that can affect critical functions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now a DORA evidence problem, not just a technology problem. When AI tools are adopted outside procurement and inventory workflows, the institution loses the ability to prove which ICT assets are in scope. That breaks the evidentiary chain behind Article 8 inventory discipline, Article 28(3) registers, and Article 29 concentration analysis. The implication is that governance programmes must treat discovery coverage as a regulated control surface, not an operational convenience.

AI usage exposes a runtime governance gap inside DORA’s third-party model. DORA assumes third-party relationships can be enumerated, contracted, and monitored. AI systems often distribute those relationships across model providers, APIs, embedded services, and subcontractors, which makes the relationship graph harder to defend. The practitioner conclusion is that AI vendor oversight must be tied to the same register and exit assumptions as other ICT suppliers.

Runtime detection, not policy intent, becomes the limiting factor for incident reporting. DORA’s timelines only work if the organisation can detect and classify major incidents quickly enough to start the clock. AI-specific disruptions such as prompt injection, data poisoning, and unauthorized AI access can sit outside traditional alerting logic. The implication is that institutions need a different detection posture for AI-driven ICT events, because the reporting obligation is only as strong as the earliest signal.

DORA compliance now depends on proving that AI is inside the same control fabric as the rest of the ICT estate. The regulation was written to unify governance, but AI adoption can fragment execution across risk, security, procurement, and legal teams. That fragmentation weakens resilience testing, contract scrutiny, and auditability at the same time. Practitioners should read DORA as a convergence mandate, not a separate AI compliance layer.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows that control gaps tend to recur rather than remain isolated.
• For a broader control lens, see Ultimate Guide to NHIs , Key Challenges and Risks for how visibility and over-privilege failures compound across machine identities.

What this signals

Shadow AI will increasingly be judged as an identity governance failure, not just a procurement lapse. Financial institutions that cannot prove AI inventory coverage will struggle to show that DORA’s control fabric extends across the full ICT estate. That is especially true where third-party dependencies, subcontractors, and runtime access paths are obscured by operational sprawl.

AI-specific monitoring will become a board-level evidence issue. DORA timelines do not bend for slow detection, which means organisations need usable signals before they need policy statements. If prompt injection, model failure, or unauthorized AI access cannot be classified quickly, the governance programme is already behind.

A stronger operating model will converge identity, resilience, and vendor governance around one question: can the institution prove what AI exists, who can access it, and how failure would be detected? The answer will increasingly determine whether DORA evidence is defensible under supervisory review.

For practitioners

• Build a complete AI and ICT inventory Identify every AI tool, model, agent, API integration, and shadow deployment, then tie each item back to DORA scope, ownership, and business purpose. If it is not in the inventory, it is not defensible in a register, an audit, or an incident review.
• Map AI systems to DORA’s five functions Link each AI-related dependency to identify, protect, detect, respond, and learn so control ownership is explicit across the operating model. This makes gaps visible before they show up as reporting failures or testing blind spots.
• Extend third-party governance to AI vendors and subcontractors Update contracts, exit terms, audit rights, data location clauses, and subcontracting visibility for every AI provider in scope. The goal is to make the Article 28(3) register accurate enough to survive supervisory scrutiny.
• Add AI-specific failure modes to monitoring and tests Include prompt injection, model failure, data poisoning, and unauthorized AI access in resilience testing and detection engineering. These scenarios need to be exercised before a major incident classification starts the DORA reporting clock.

Key takeaways

• DORA becomes materially harder when AI sits outside inventory, third-party, and monitoring processes.
• The main compliance risk is not missing a policy statement but failing to prove control coverage across the full ICT estate.
• Financial institutions should expand discovery, monitoring, testing, and contractual evidence before AI adoption outruns governance.

Key terms

• Shadow AI: AI tools, models, or agents used inside an organisation without formal approval, inventory, or governance visibility. In practice, shadow AI creates identity and third-party risk because it can process data, call external services, and consume privileges before security or compliance teams know it exists.
• Article 28(3) register: The DORA register of contractual arrangements with ICT third-party providers. It is more than a list of vendors, because it must support supervisory evidence, distinguish critical services, and stay accurate as subcontracting chains, AI dependencies, and business usage change over time.
• 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.
• Digital operational resilience: An organisation’s ability to withstand, respond to, and recover from ICT disruption while continuing to deliver critical services. Under DORA, this includes technical controls, governance evidence, testing, and supplier oversight, all of which must work together rather than exist as separate compliance tasks.

Deepen your knowledge

DORA compliance for AI systems is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building evidence, inventory, and third-party governance in a regulated environment, it is worth exploring.

This post draws on content published by WitnessAI: DORA compliance gaps widen as AI expands ICT risk scope. Read the original.