> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/reference/governance-and-frameworks/g.3-dora-and-ai-resilience-in-financial-services.md).

# G.3 DORA and AI resilience in financial services

ICT risk management, third-party risk, operational resilience testing, and incident reporting applied to AI vendors, agents, and model-hosting platforms under DORA.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
For financial services, AI security is also ICT resilience. If an AI tool can affect a critical or important function, treat the vendor, agent runtime, connectors, telemetry, and incident path as part of the DORA control environment.
{% endhint %}

DORA has applied since January 17, 2025 to the financial entities listed in Article 2 and to their management of ICT risk. It also establishes EU oversight for designated critical ICT third-party providers. AI systems are not a separate DORA category, but enterprise AI commonly depends on ICT services such as model APIs, cloud infrastructure, agent sandboxes, SaaS connectors, identity providers, logging systems, and data stores.

The entity's regulated status and the service provided determine scope. Legal and compliance should confirm whether DORA applies before the team treats this page as a requirements checklist.

Include DORA in the review when an AI workflow could affect an in-scope financial entity's ability to deliver, protect, investigate, or recover a service.

## DORA areas that matter for AI

| DORA area                                     | AI security interpretation                                                                                                             |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| ICT risk management                           | AI systems, agent runtimes, connectors, and model APIs belong in the ICT risk framework when they support financial operations.        |
| ICT-related incident management and reporting | AI incidents may involve data leakage, unavailable AI-supported workflows, compromised connectors, or agent misuse.                    |
| Digital operational resilience testing        | AI controls need testing: prompt injection, tool misuse, fallback process, logging, recovery, and vendor outage scenarios.             |
| ICT third-party risk                          | AI vendors, model platforms, cloud sandboxes, telemetry vendors, and connector providers may be ICT third-party service providers.     |
| Information sharing                           | Threat intelligence for prompt injection, AI supply-chain compromise, and vendor incidents should feed normal cyber sharing processes. |

## Classify the AI workflow

Before approving an AI system in a DORA-regulated environment, record:

* The financial service or business process supported.
* Whether the workflow touches a critical or important function.
* The AI deployment model: chat, coding agent, browser/desktop agent, hosted agent, API app, or low-code builder.
* The vendor and all material ICT dependencies.
* The data classes involved.
* Whether the system can write, transact, notify customers, alter records, or trigger downstream workflows.
* The fallback process if the AI system, model provider, connector, or logging path fails.

## Third-party risk questions for AI vendors

Ask AI vendors and platform owners:

* What services process prompts, files, embeddings, tool calls, logs, and traces?
* Where are those services hosted?
* Which subcontractors or subprocessors are involved?
* What retention settings apply to prompts, files, logs, traces, and abuse-monitoring records?
* How are incidents reported to customers?
* What audit evidence is available?
* Can the organization export logs quickly during an incident?
* How does the vendor support exit, portability, and deletion?
* Which features are excluded from compliance exports or retention controls?
* Which services and subcontractors must appear in the DORA register of information?

The vendor's AI trust documentation is useful, but DORA review needs operational facts: service dependencies, resilience, incident timing, contract terms, audit rights, and exit plans.

## Resilience tests for AI systems

At minimum, test:

* Vendor outage: users can continue the critical process without the AI tool.
* Connector failure: the system fails closed and does not retry into unsafe states.
* Logging failure: the workflow pauses or flags degraded evidence before high-risk actions.
* Prompt injection: untrusted content cannot cause unauthorized disclosure or action.
* Credential exposure: secrets in prompts, files, and agent environments are blocked or detected.
* Agent runaway: approval gates and stop controls work.
* Data residency and retention: evidence matches the approved data class.
* Incident response: security can revoke tokens, disable connectors, preserve evidence, and notify the right parties.

## Incident handling

AI incidents in financial services may look like ordinary ICT incidents, data incidents, or operational resilience events. Do not route them only to the AI program owner.

Examples:

* An agent sends customer data to an unapproved connector.
* A model provider outage breaks a customer-service workflow that depends on AI triage.
* A coding agent commits a credential or changes a payment workflow.
* A prompt-injection chain causes a browser or desktop agent to act in a signed-in session.
* A compliance API gap prevents timely investigation of AI activity.

For each approved AI workflow, document whether an event could meet the DORA criteria for a major ICT-related incident, qualify as a personal data breach, trigger another sector reporting duty, or fall into more than one category.

When an incident is classified as major under DORA, Commission Delegated Regulation (EU) 2025/301 sets the reporting clock: the initial notification is due as early as possible, within four hours after classification and no later than 24 hours after awareness; the intermediate report is due within 72 hours after the initial notification; and the final report is due within one month after the intermediate or latest updated intermediate report. Build these deadlines into the incident runbook rather than relying on the AI vendor's notification process.

## Common DORA and AI resilience in financial services security failures

* The AI vendor is reviewed as a productivity tool even though it supports a critical process.
* The contract covers the SaaS app but not model APIs, sandboxes, telemetry, or connectors.
* The team tests model quality but not operational fallback.
* Incident response cannot retrieve prompt, file, tool, or trace evidence quickly.
* Exit planning ignores prompt history, embeddings, fine-tuning data, agent state, and logs.
* A low-code agent builder lets business teams create new ICT dependencies without DORA review.

## DORA and AI resilience in financial services security controls checklist

* Add AI systems and agent runtimes to the ICT inventory when they support financial operations.
* Mark whether each AI workflow supports a critical or important function.
* Review AI vendors as ICT third parties when applicable.
* Test outage, fallback, logging, connector failure, prompt injection, and credential exposure.
* Define incident classification paths for AI-related events.
* Keep evidence of vendor due diligence, resilience tests, control settings, and review dates.
* Reassess after new connectors, new agent autonomy, new data classes, or vendor feature releases.

## Frequently asked questions about DORA and AI resilience in financial services

### Does DORA apply to every AI tool used by a financial institution?

Not in the same way. First confirm that the organization is an in-scope financial entity. Then assess the function and dependency. Low-risk drafting tools still need normal security controls, while tools supporting critical or important functions require stronger resilience, contract, testing, register, and exit evidence.

### Are AI model providers ICT third-party service providers?

They can be. If the model provider, API, hosted agent platform, or AI SaaS tool supports a regulated financial process, treat it as an ICT dependency and review the contract, resilience, incident, and exit requirements.

### What makes an AI incident a DORA concern?

An event becomes a DORA reporting concern when it is an ICT-related incident and meets the applicable classification criteria for a major incident. Route suspected cases through the ICT incident process promptly so the regulated entity can classify the event and meet the reporting clock.

### Who should own DORA alignment for AI?

The regulated entity owns compliance. Security, operational resilience, procurement, legal, and the AI platform owner should share the evidence. The AI vendor cannot own the regulated entity's resilience program.

## Applicable handbook articles

*This table applies only to a DORA-regulated entity and an AI workflow within its ICT risk environment.*

DORA is technology-neutral and applies across an in-scope entity's ICT risk environment. These links identify practical controls for AI capabilities used in that environment; only the articles for features and surfaces actually present in the system apply. The links are not article-by-article statements of legal equivalence.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                                                                                                  | Why they apply                                                                                                |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.1 SSO & SCIM for AI platforms<br>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.4 Domain claiming: bringing shadow accounts into enterprise<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                                                    | Supports access and identity lifecycle controls for an in-scope ICT environment.                              |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.2 MCP servers: securing the protocol<br>2.3 MCP gateways and allowlisting<br>2.4 Analyzing skills for risk<br>2.5 Plugins and marketplaces<br>2.6 Hooks and lifecycle scripts<br>2.7 The supply-chain review workflow<br>2.8 Signing and packaging<br>2.9 SaaS agent-building supply-chain<br>2.10 Hosted-agent framework dependencies</p> | When these surfaces are used, supports ICT asset, dependency, third-party, acquisition, and change control.   |
| 3. Runtime, sandboxing & autonomy        | <p>3.1 Sandbox and isolation models<br>3.2 Approval policies and least-privilege autonomy<br>3.3 Network egress control<br>3.4 Internet access and browser automation<br>3.5 Computer Use / desktop control risks<br>3.6 Scheduled and background tasks<br>3.7 Remote access, dispatch and SSH<br>3.8 File and filesystem access controls<br>3.9 Central hosted-agent runtime hardening</p>          | When these surfaces are used, supports secure and resilient operation, containment, continuity, and recovery. |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.3 Data residency and regional inference<br>4.4 Retention and Zero Data Retention<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p>                                                                                                                        | Supports confidentiality, integrity, classification, location, retention, data-flow, and secrets controls.    |
| 5. Threats & adversarial testing         | <p>5.1 Prompt injection: the connective risk<br>5.2 Data exfiltration via tools and connectors<br>5.3 Supply chain attacks and notable CVEs<br>5.4 Agent-specific threats: tool poisoning and confused deputy<br>5.5 Red-teaming AI systems<br>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p>                                                                            | Supports cyber-risk assessment, resilience testing, vulnerability handling, and incident response.            |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.2 OpenTelemetry for AI runtime<br>6.3 Compliance APIs by platform<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                                                                                                                             | Supports logging, detection, investigation, audit evidence, and reassessment.                                 |
| 7. Rollout & operations                  | <p>7.1 Roll out by risk: the phased plan<br>7.2 Pilot design and success metrics<br>7.3 The security team checklist<br>7.4 The vendor-neutral control matrix</p>                                                                                                                                                                                                                                     | Supports pre-production approval, testing, controlled change, and operational readiness.                      |

## Further reading

The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.

* [Regulation (EU) 2022/2554, Digital Operational Resilience Act](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)
* [Commission Delegated Regulation (EU) 2025/301 on major ICT-related incident reporting](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng)
* [ESMA DORA implementation and policy requirements](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora)

## Related handbook guidance

* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference.md)
* [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system.md)
* [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence.md)
* [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/reference/governance-and-frameworks/g.3-dora-and-ai-resilience-in-financial-services.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.