DORA and AI agent certification: what financial services firms need

What DORA actually requires

Regulation (EU) 2022/2554, the Digital Operational Resilience Act, has applied across the European Union since 17 January 2025. It replaces a patchwork of sector specific and often informal ICT risk expectations with a single, binding framework built around five pillars: ICT risk management, ICT related incident classification and reporting, digital operational resilience testing, ICT third party risk management, and information sharing arrangements between financial entities on cyber threats.

The first pillar, ICT risk management, requires financial entities to maintain a documented framework covering identification of ICT assets and dependencies, protection and prevention measures, detection capability, response and recovery procedures, and a programme of continuous learning from incidents and tests. This framework sits under the direct responsibility of the entity's management body. DORA is explicit that the management body cannot delegate away accountability for ICT risk simply because the underlying technology is operated by a third party.

The fourth pillar, ICT third party risk management, is the one most directly relevant to AI agents. It requires financial entities to maintain a register of information covering all contractual arrangements with ICT third party service providers, to carry out due diligence before entering into or renewing such an arrangement, to assess concentration risk across the entity's third party dependencies, and to include specific contractual provisions covering service levels, audit rights, exit arrangements and, for certain arrangements, sub-outsourcing transparency. The register of information is not a light touch documentation exercise. Financial entities have had to build and populate it as one of the first concrete compliance deliverables under DORA, and it is the artefact supervisors ask to see first.

The third pillar, digital operational resilience testing, requires financial entities to test their ICT systems and controls on a risk based schedule, ranging from basic testing for most entities to threat led penetration testing for the largest and most systemically significant firms. Testing obligations extend to critical or important functions supported by ICT third parties, which means a financial entity cannot simply assume a vendor's system works as described. It has to build testing or testing assurance into its programme.

The second pillar, incident classification and reporting, requires financial entities to classify ICT related incidents against defined severity criteria and report major incidents to their competent authority within set timeframes. Where an ICT third party provider is the source of the incident, the financial entity remains the party responsible for classification and reporting, which means it needs a contractual and operational path to get incident information out of its vendors quickly enough to meet its own deadlines.

The fifth pillar, oversight of critical ICT third party providers, is the mechanism through which DORA reaches beyond the regulated financial entities themselves. The European Supervisory Authorities, meaning the European Banking Authority, the European Insurance and Occupational Pensions Authority, and the European Securities and Markets Authority, acting jointly, can designate an ICT third party provider as critical based on criteria such as the systemic importance of the financial entities depending on it, the degree to which its service is substitutable, and the number of financial entities relying on it. A provider designated as critical comes under direct oversight, including the possibility of on site inspections and binding recommendations, without needing to be a financial entity itself.

Why AI agents fall inside DORA's third party risk scope

DORA's definition of ICT services is broad and technology neutral. It covers digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis. An AI agent, whether it is a customer facing chatbot handling account queries, a back office agent processing claims documentation, or an autonomous system flagging suspicious transactions, is delivered through ICT systems to users on an ongoing basis. There is no exemption in the regulation for AI. The obligation attaches to the function the service performs for the financial entity, not to the label attached to the underlying technology.

This matters in two directions. First, if a financial entity builds or deploys an AI agent internally, that agent's ICT infrastructure, whether hosted internally or on cloud infrastructure supplied by a third party, sits inside the entity's own ICT risk management framework under the first pillar. Second, and more consequentially for the certification question, if a financial entity procures an AI agent or an AI powered service from an external vendor, that vendor is an ICT third party service provider under the fourth pillar. The financial entity has to register the arrangement, conduct due diligence before signing, assess concentration risk if it or peers rely heavily on the same vendor, and build contractual provisions for audit access, service levels and exit.

For AI vendors selling into the EU financial sector, this means their prospective customers are not asking whether the AI agent is impressive. They are asking whether it fits inside a due diligence file that a supervisor could review during an on site inspection. A vendor that cannot answer basic questions about its own resilience testing, incident notification commitments, and sub-processor chain is not going to clear a financial entity's procurement gate, regardless of the quality of the underlying model.

The evidence gap at board level

DORA places the accountability for ICT risk, including third party risk, squarely on the management body of the financial entity. That body has to be able to demonstrate, not merely assert, that it assessed the resilience of each ICT third party arrangement before entering into it and that it continues to monitor that resilience for the life of the arrangement. This is where a specific and recurring problem shows up in practice.

A board approving the use of an AI agent, whether built internally or procured, typically receives a business case, a data protection assessment, and a security review focused on the entity's own perimeter. What it does not typically receive is an independent, structured assessment of the AI system's own operational resilience: how it is tested, how incidents are detected and escalated, what its autonomy boundaries are, and whether its governance infrastructure would hold up under supervisory scrutiny. That gap is a DORA problem, not a hypothetical one, because the register of information and the third party due diligence file are concrete deliverables supervisors have been checking since DORA's application date.

An independent certification, produced by an assessor with no commercial stake in the outcome and scored against a published methodology, is built to close exactly this gap. It gives a board a single artefact that answers the resilience question in a form that does not require the board itself, or the entity's internal risk function, to re-run a technical assessment of a system they may not have the specialist capacity to evaluate directly. This is the same logic that underpins the use of external audit for financial statements: the board is not expected to audit the accounts personally, but it is expected to have engaged someone qualified who did, and to be able to show that engagement.

How the Agent Certified methodology maps to DORA

The Agent Certified methodology scores an AI agent across seven weighted dimensions: Trust and Safety, Context Integrity, Distribution Control, Product Maturity, Governance, AI Integration, and the Autonomy Envelope. The framework was not built with DORA specifically in mind, since it predates DORA's application date, but its dimensions map onto DORA's pillars with more precision than a generic security certification does, because both frameworks are ultimately asking the same underlying question: can this system be relied upon, and can that reliance be demonstrated to a third party.

The Governance dimension is the most direct mapping. DORA's ICT risk management framework requires documented policies, a named point of accountability, and a risk register that is actively maintained rather than written once and filed. This is precisely what the Governance dimension evaluates: an AI use policy that is operationalized, an incident response plan that has been exercised rather than merely drafted, liability chain documentation, and a quality management system covering the AI's lifecycle. A financial entity's compliance team reviewing a vendor's Governance dimension score is reviewing evidence that maps closely onto what its own DORA first pillar obligations require it to have assessed. For the detailed scoring rubric behind this dimension, see the Governance dimension article.

Product Maturity maps to DORA's digital operational resilience testing pillar. DORA requires financial entities to test ICT systems on a risk based schedule and to have confidence that critical or important functions supported by third parties are resilient under stress. The Product Maturity dimension evaluates measured uptime, versioned models and prompts under change control, regression evaluation on every change, and observability at the reasoning trace level. An AI vendor with a strong Product Maturity score has already built the testing discipline that DORA's resilience testing pillar expects a financial entity to be able to point to for its critical functions.

Trust and Safety and the Autonomy Envelope together map to DORA's incident classification and reporting pillar and to the underlying risk management framework's protection and detection requirements. Trust and Safety evaluates guardrail coverage, red team discipline, and the verifiability of a kill switch, which is the technical capability a financial entity needs in order to contain an AI related incident quickly enough to meet its own DORA reporting clock. The Autonomy Envelope evaluates the explicit boundary between actions the agent may take unsupervised and actions that require human confirmation, which is the control a financial entity's incident response plan needs to reference when deciding whether an AI agent's action was within its authorised bounds or a containment failure.

Distribution Control and AI Integration map to DORA's expectations around identity, authorisation and system of record integrity, which sit inside the ICT risk management framework's protection measures and inside the audit trail requirements that both the incident reporting and resilience testing pillars rely on. An agent that writes to a financial entity's systems under a shared service account, with no role based authorisation and no clean audit trail, is difficult to reconcile with an incident investigation, which is exactly the scenario DORA's framework is designed to prevent.

Context Integrity is the dimension with the least direct DORA mapping but the clearest connection to a financial entity's underlying data governance obligations, which sit alongside DORA in the entity's broader regulatory perimeter. An agent that retrieves stale or unverified data to support a financial decision is a data governance failure before it is an ICT resilience failure, but the two are connected in practice because bad context routinely produces the kind of erroneous output that then has to be classified and reported as an incident.

What a procurement or compliance team should ask an AI vendor to produce

For a financial entity's procurement or compliance function assessing an AI vendor under DORA, the practical output of this mapping is a short list of documents to request before signing, and to review periodically thereafter. First, a description of the AI service sufficient to populate the register of information entry, including any sub-processors or model providers the AI vendor itself relies on, since DORA's transparency expectations extend along the sub-outsourcing chain where the arrangement supports a critical or important function. Second, evidence of the vendor's own resilience testing programme: what is tested, how often, and what the escalation path looks like when a test fails. Third, an incident notification commitment with specific timeframes, because the financial entity's own DORA reporting clock starts running regardless of how quickly its vendor tells it something went wrong. Fourth, governance documentation covering the vendor's AI use policy, its incident response plan, and its liability chain mapping, which is the material a financial entity needs to complete its own due diligence file. Fifth, exit and substitutability information, since concentration risk assessment under DORA's third party risk pillar requires the entity to understand what happens if it needs to move away from the vendor.

An independent certification against a published methodology such as the seven dimension Agent Certified framework does not replace any of these five requests. What it does is package the evidence for several of them, particularly governance, resilience testing discipline, and incident response readiness, into a single scored artefact that a compliance team can attach directly to the register of information entry and the due diligence file, rather than having to extract equivalent assurance piecemeal from marketing material and a security questionnaire the vendor wrote itself.

How this differs from DORA's own regulatory technical standards

DORA is implemented in part through regulatory technical standards developed by the European Supervisory Authorities, covering matters such as the content of the register of information, the criteria for critical ICT third party provider designation, and the detail of the ICT risk management framework. These technical standards are binding regulatory instruments. An AI agent certification such as Agent Certified is not a regulatory technical standard, does not have legal force, and does not substitute for a financial entity's own compliance obligations under DORA or for the specific documentation formats the regulatory technical standards prescribe. It is complementary evidence: a structured, independently produced assessment that a financial entity's compliance and procurement teams can use to accelerate their own due diligence and to have a defensible answer ready when a supervisor or an internal audit asks how a specific AI vendor's resilience was assessed.

The relationship mirrors the one between ISO/IEC 42001 and the EU AI Act described elsewhere on this site: a horizontal, voluntary standard does not replace the binding regulation, but a financial entity or vendor that holds credible independent evidence is in a materially stronger position when the regulator, the auditor or the board asks the question directly. For the parallel treatment of that relationship at the management system level, see the ISO/IEC 42001 implementation guide. For the seven dimension framework in full, including how weights and tier thresholds are set, see the seven dimensions article.

For the insurance side of the same question, meaning how DORA's ICT third party risk provisions interact with the AI liability insurance products now available to European financial entities and their AI vendors, see DORA's implications for AI insurance coverage. Certification evidence and insurance underwriting draw on overlapping documentation, and a financial entity building its DORA compliance file should expect the two workstreams to reinforce each other rather than run in parallel with no connection.