Who is accountable when an AI-driven ICT incident triggers DORA reporting?

Why This Matters for Security Teams

DORA reporting does not change just because an incident was triggered by an AI-driven service. The institution still owns the risk, the timeline, and the regulatory narrative. That matters because AI services often sit inside a wider chain of NHIs, API keys, service accounts, and delegated tool access. When those identities are poorly governed, the incident is no longer just a technology failure, it becomes a resilience and accountability problem under DORA.

Current guidance also points to a broader pattern: AI-related compromise is rarely isolated. NHIMG research shows that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, and 46% have confirmed one. That is why incident accountability must be mapped before a reportable event, not after it. See The 52 NHI breaches Report for the common failure modes and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives for the governance angle.

In practice, many security teams discover this only after an AI workflow has already moved faster than their approval chain and the notification clock has started.

How It Works in Practice

The management body remains accountable, but operational ownership should be explicit. A mature incident process usually assigns detection, triage, evidence preservation, legal review, and regulator notification to named functions, while reserving final accountability to the board or equivalent governing body. That separation matters because autonomous systems can act faster than human approval cycles, especially when they have tool access, secret access, or delegated privileges.

For AI-driven incidents, the practical question is not only “what broke?” but “which identity was abused, which data was touched, and which controls failed to stop it?” That is where workload identity, short-lived secrets, and least privilege become operationally relevant. In AI-native environments, static RBAC alone is often too blunt. Best practice is evolving toward intent-based authorisation, just-in-time credentialing, and runtime policy checks so an agent can only do what is justified for that task. The Anthropic — first AI-orchestrated cyber espionage campaign report is a useful reminder that AI-enabled abuse can be operationally coordinated, not merely opportunistic.

• Assign a single incident owner who can coordinate DORA reporting, even if the trigger came from a vendor AI service.
• Link alerts to the exact NHI, token, or API key used by the workload.
• Preserve logs showing what the agent attempted, what it was authorised to do, and where escalation occurred.
• Use DeepSeek breach and JetBrains GitHub plugin token exposure as concrete examples of how exposed secrets become incident multipliers.

These controls tend to break down when AI agents are embedded in legacy incident workflows that assume a human clicked first and a machine responded later.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance rapid containment against evidence quality and governance sign-off. That tradeoff is real during AI-triggered incidents, because regulator notification windows do not wait for perfect root cause analysis.

One common edge case is third-party AI SaaS. The provider may generate the alert, but the institution still needs to determine whether the incident affects its own services, data, or ICT continuity. Another is multi-agent orchestration, where one autonomous system triggers another through tool calls or MCP-like integrations. In those environments, there is no universal standard for responsibility handoff yet, so current guidance suggests using a pre-defined accountability matrix, runtime policy logs, and explicit service ownership to keep reporting defensible. See Ultimate Guide to NHIs — Why NHI Security Matters Now for why short-lived secrets and identity hygiene matter under pressure, and EU Digital Operational Resilience Act (DORA) for the regulatory baseline.

In vendor-managed AI incidents, the practical failure is assuming the supplier’s notification process replaces the institution’s own reporting duty.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent triggers a banking error or compliance breach?
• Who is accountable when a customer-facing AI gives harmful or off-topic advice?
• Who is accountable when an AI agent changes prices or processes a refund incorrectly?
• Who is accountable when an AI agent makes a risky decision?