DORA Compliance: What Financial Institutions Need in 2026

DORA organizes its requirements into five areas. Most compliance guides describe these at a high level; the operational implications are more specific.

Walk through how a typical financial operations workflow runs in most institutions. A claims assessor receives an application. It passes through automated checks, eligibility screening, fraud indicators, regulatory watchlist, risk score, and then either auto-approves, routes for manual review, or rejects. The assessor may or may not document why they overrode an automated recommendation. The system logs may or may not capture the full chain of decisions. The audit trail, if it exists, lives across several different systems.

Under DORA, that workflow is an ICT-dependent process that must be documented in the risk framework, tested for failure modes, and auditable end to end. The test question is not just what happens if the server goes down. It is whether, if the automated risk scoring model produces an incorrect output, the institution can trace the error, identify what was affected, and demonstrate the human oversight checkpoint that should have caught it.

Most institutions can answer the infrastructure question. Fewer can answer the process question. The gap sits in the operational workflows that run on top of ICT infrastructure, the ones financial operations teams own but that often were not brought into DORA compliance scope in the first pass.

DORA did not anticipate agentic AI specifically when it was adopted in 2022, but its requirements apply to it directly. Any automated system that makes or influences a decision affecting financial operations, including an AI-driven one, falls within the ICT risk management framework. The resilience testing, incident reporting, and documentation requirements all apply.

Financial institutions deploying AI in operational workflows should also check whether the EU AI Act's transparency obligations apply to the same processes from August 2, 2026 as scheduled, but the deeper human-oversight and documentation requirements specifically for high-risk AI systems were pushed back by the Digital Omnibus on AI, now in force, to December 2, 2027 (standalone systems) or August 2, 2028 (product-embedded systems); the extra runway doesn't remove the requirement, and the two regulations are not mutually exclusive.

The specific challenge with AI systems is explainability. DORA requires that institutions can explain and reconstruct the sequence of events leading to an ICT incident. For a conventional system failure, that is a log analysis exercise.

For an AI system that made a series of decisions across a workflow that led to an incorrect outcome, the explanation needs more: a record of what data the system reviewed, what rules or reasoning it applied, what it concluded, and where a human checkpoint should have caught the error.

An AI system that logs an output but not the reasoning behind it will struggle to satisfy this requirement. An AI system that produces decisions without a human checkpoint at high-stakes steps will struggle to satisfy the resilience requirement either.

Financial institutions deploying AI agents in operational workflows should be asking this question before an examiner does: if this agent produced an incorrect output on a critical decision last week, can we reconstruct exactly what it did, why, and at which point a human should have reviewed it? An uncertain answer is itself a risk management gap worth addressing now.

DORA's ICT risk management requirement includes board-level accountability, which means compliance cannot live exclusively inside the IT department. Operations leaders, heads of claims, heads of financial operations, compliance directors, need to own the process documentation for the workflows their teams run. Three things matter most:

• Map critical processes as ICT-dependent workflows, not just IT infrastructure. The claims workflow, the KYC process, the AML screening chain, and the exception approval sequence all belong in the DORA risk framework; where they involve automated decision systems, that increases the documentation requirement rather than reducing it.
• Verify the audit trail covers process decisions, not just system events. A security operations center logs system events. DORA compliance also requires that business process decisions, automated and human, are logged in a form regulators can inspect.
• Define and test failure scenarios for automated processes: the fallback, who gets alerted, how fast the process can be restored, and whether that has actually been tested. DORA's resilience testing requirements apply to processes, not only infrastructure.

WEM No-Code is an enterprise application platform built for the operational layer DORA requires documentation of. Every step of a workflow is mapped in the Modeler's Flowchart builder, and every function call, state transition, and response inside it is logged by the platform itself, not reconstructed afterward.

A claims process built this way has a visual workflow definition showing each step, each decision point, and each human checkpoint, because that definition is how the workflow was built, not a separate artifact generated for compliance. That kind of structural logging supports the process documentation regulators are asking for, though the specific report format an examiner wants is still something the institution assembles itself.

For the audit trail mechanics behind an AI-driven step specifically, see how WEM No-Code approaches GDPR compliance (draft slug, confirm on publish), which covers the same logging model from a different regulatory angle.

Third-party dependencies are visible directly in the workflow: an external system call, over SOAP, REST/JSON, OData, or RAW HTTP, is explicit in the workflow definition, which supports the ICT third-party register requirement without a separate mapping exercise.

Workflows can also run through WEM No-Code's Staging Runtime environment before going live, giving operations teams a place to exercise failure scenarios ahead of production, though the specific test scenarios and pass criteria are still something the institution defines and documents itself.

The DORA deadline passed in January 2025. The documentation work behind it, for most institutions, has not caught up, particularly for the operational workflows and AI-driven decisions sitting on top of already-secured ICT infrastructure.

Audit activity in 2025 and 2026 is starting to ask process questions, not just infrastructure questions, and the institutions that can answer them are the ones that treated workflow documentation as a structural property of how they build, not a report assembled ahead of an examination.

For the platform mechanics behind that kind of structural audit trail, WEM No-Code's Architecture page covers how logging and governance work, and the Financial Services industry page covers the vertical-specific detail. This article is informational, not legal advice; work with your compliance function or legal counsel on what applies to your institution specifically.