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

Why This Matters for Security Teams

DORA testing only proves resilience if the test scope includes AI and the identities, secrets, and contracts that support it. AI systems often sit across cloud, SaaS, model APIs, and automation tooling, so they can be invisible to legacy inventories even while they process regulated data or trigger production actions. That creates a false sense of coverage: controls look mature on paper, but the actual ICT estate is incomplete.

That gap is consistent with broader NHI risk. NHIMG research on Top 10 NHI Issues shows how often non-human access is under-governed, while the Ultimate Guide to NHIs — Regulatory and Audit Perspectives explains why auditors focus on evidence, not intention. For operational teams, the standard should be whether AI-related assets are discoverable, monitored, and contractually controlled in the same way as other critical ICT assets. In practice, many security teams discover AI exposure only after an incident shows the asset was never in scope.

DORA itself is about operational resilience, not box-ticking, so the question is whether testing actually exercises the AI control plane as well as the surrounding infrastructure. That aligns with EU Digital Operational Resilience Act (DORA) and with the broader detection-and-response approach in NIST Cybersecurity Framework 2.0.

How It Works in Practice

Practitioners should test coverage in three places: inventory, contract, and telemetry. First, confirm the AI service, model endpoint, agent, and supporting NHI appear in asset inventories and risk registers. If the environment uses autonomous tooling, the inventory should also show the workload identity, the owning business service, and the data paths the agent can reach. Second, review third-party and internal contracts for audit rights, incident reporting timelines, exit assistance, data handling terms, and access to logs. Third, validate monitoring against AI-specific failure modes, not only generic outages.

That is where NIST AI Risk Management Framework and NIST Cyber AI Profile (IR 8596) become useful: they push teams to map AI risks to governance, measurement, and response rather than treating AI as a generic application tier. For NHI-focused depth, NHIMG’s OWASP NHI Top 10 and Ultimate Guide to NHIs — Standards are useful for checking whether identities, secrets, and privilege pathways are actually governed.

• Verify AI systems are in the authoritative inventory, not just in a vendor register.
• Check whether the contract allows log access, model-change notice, and orderly exit.
• Test whether alerts detect secret misuse, unusual tool calls, prompt injection effects, and privilege escalation.
• Confirm the owner can produce evidence that ties the AI control to a business service and a recovery plan.

These controls tend to break down when AI is delivered through shadow SaaS or rapidly changing agent workflows because the asset list, the actual secrets, and the monitoring stack drift out of sync.

Common Variations and Edge Cases

Tighter evidence requirements often increase operational overhead, so organisations need to balance auditability against delivery speed. That tradeoff is most visible with internal AI platforms, vendor-hosted models, and short-lived agent workflows, where ownership and data flows change quickly.

Best practice is still evolving for multi-agent and autonomous systems, and there is no universal standard for every architecture yet. In those environments, static role-based access reviews are usually insufficient because agents act on intent, context, and tool availability rather than a fixed human schedule. The better pattern is to pair DeepSeek breach-style secret exposure lessons with runtime controls: just-in-time credential issuance, short TTL secrets, workload identity, and policy checks at request time.

Where AI is embedded inside a larger outsourced service, the resilience test should also ask whether the provider can prove who can revoke access, how quickly secrets expire, and which AI-specific incidents are reportable. For agents, current guidance suggests treating identity as a workload property, not a user analogue, and using runtime policy evaluation instead of assuming RBAC alone will contain the blast radius. That is especially important when agents can chain tools or create lateral movement paths that no pre-defined access review will describe in advance.

Related resources from NHI Mgmt Group

• How do organisations know whether AI identity monitoring is actually working?
• How do organisations know if identity risk scoring is actually useful?
• How do organisations know whether identity visibility is actually improving?
• How do teams know whether AI governance is actually working?