Table of Contents
Summarize and analyze this article with
Chat GPT
Perplexity
Grok
Google AI
Claude
Resilience became a hard requirement
For financial firms, the risk that a technology failure, a cyberattack, or a provider outage disrupts critical services is no longer governed only by internal policy and supervisory expectation. In the EU, the Digital Operational Resilience Act (DORA) made operational resilience a binding, structured requirement. DORA has applied since 17 January 2025 and covers a wide range of financial entities, from banks and insurers to investment firms and certain crypto-asset providers, along with the ICT third-party providers that serve them. It reaches US-headquartered firms through their EU operations, and its structure is increasingly a reference point for US institutions as regulators on both sides of the Atlantic press on AI-related resilience and recovery.
This guide explains what DORA demands and why it matters beyond the EU. It is educational and not legal advice, and firms should confirm DORA’s detailed requirements against the regulation and its technical standards at publish.
The four pillars, in brief
| Pillar | What it requires |
|---|---|
| ICT risk management | A documented framework to identify, protect, detect, respond to, and recover from ICT risk, owned by the management body |
| Incident reporting | Classify ICT-related incidents by defined criteria and report major incidents to authorities on set timelines |
| Resilience testing | A testing program including, for significant entities, advanced threat-led penetration testing |
| Third-party ICT risk | Manage and oversee ICT third-party providers, maintain a register of contractual arrangements, meet contract requirements, and account for oversight of critical providers |
Why US financial firms are paying attention
- Extraterritorial reach. A US financial group with EU entities, branches, or in-scope operations has to meet DORA for those operations, which pulls the framework into enterprise resilience planning.
- A concrete template. DORA turns abstract resilience goals into structured, auditable requirements, and many US institutions use it as a model even where it does not directly bind them.
- AI concentration risk. As AI concentrates critical capability in a few model and cloud providers, the third-party-oversight and resilience-testing discipline DORA codifies maps directly onto the concern US and UK supervisors are now voicing about AI-related disruption and recovery.
The third-party pillar is where AI risk lands
DORA’s most distinctive pillar is its treatment of ICT third-party risk: a register of contractual arrangements, specific contract requirements, and a framework for oversight of providers deemed critical. This is precisely where AI risk concentrates, because the models, platforms, and cloud services behind an institution’s AI are third-party ICT services, and a failure or compromise at one provider can propagate across many firms. An institution that already runs a DORA-grade third-party program, with a complete register and contracts that preserve audit, oversight, and exit rights, is far better positioned to answer the AI-provider and resilience questions supervisors are now asking than one relying on scattered vendor arrangements.
Where PiTech fits
PiTech Solutions helps financial firms build the operational-resilience and third-party-oversight capability DORA codifies: an ICT risk-management framework, incident classification and reporting aligned to the required criteria, resilience testing, and a third-party register with the contract and oversight controls DORA demands, extended to the AI model and cloud providers that now carry concentrated risk. It connects resilience to the AI and data governance and vendor-risk work behind it. Delivery runs under CMMI Level 3 and ISO 27001, 9001, and 42001 certifications. See the banking practice, fintech, and insurance hubs. PiTech Solutions Inc. is headquartered in Durham, North Carolina (UEI GNLRY5LNNVH6, CAGE 530K4) and is distinct from similarly named companies.
The bottom line
DORA made operational resilience a binding requirement for EU financial entities across four pillars: ICT risk management, incident reporting, resilience testing, and third-party oversight. It reaches US firms through their EU operations and serves as a template many adopt voluntarily, and its third-party pillar is exactly where concentrated AI risk now lands. Build the resilience and third-party discipline now, because the questions supervisors are asking about AI-related disruption are the questions DORA was written to answer.
Frequently Asked Questions (FAQs)
What is DORA?
DORA, the Digital Operational Resilience Act, is an EU regulation that sets binding requirements for how financial entities manage information and communication technology (ICT) risk and maintain operational resilience. It has applied since 17 January 2025 and covers a broad range of financial entities, including banks, insurers, investment firms, and certain crypto-asset service providers, as well as the ICT third-party providers that serve them. DORA replaces a patchwork of resilience expectations with a single structured framework built on four pillars: ICT risk management, incident reporting, digital operational resilience testing, and management of ICT third-party risk. It is supported by detailed regulatory and implementing technical standards that specify how the high-level requirements are met, which firms should consult for the operative detail.
Does DORA apply to US companies?
It applies to in-scope financial entities and ICT providers operating in the EU, so a US-headquartered financial group reaches DORA through its EU entities, branches, or in-scope EU operations, and US technology providers can be affected where they serve EU financial entities as ICT third parties. DORA does not regulate a purely US operation with no EU nexus. But because many large US financial institutions and technology firms operate in the EU, DORA frequently pulls into enterprise-wide resilience and third-party programs even for US-based groups. Beyond direct applicability, US firms also use DORA as a template, adopting its structured approach to resilience and third-party oversight because it turns abstract goals into auditable requirements that align with where supervisors are heading.
What are the four pillars of DORA?
First, ICT risk management: a documented framework, owned by the management body, to identify, protect against, detect, respond to, and recover from ICT risk. Second, ICT-related incident reporting: classifying incidents against defined criteria and reporting major ones to authorities within set timelines. Third, digital operational resilience testing: a program of testing that, for significant entities, includes advanced threat-led penetration testing. Fourth, ICT third-party risk management: overseeing technology providers, maintaining a register of contractual arrangements, meeting specific contract requirements, and accounting for the oversight framework applied to providers designated as critical. Together these pillars make operational resilience a structured, evidenced discipline rather than a matter of internal policy, and the technical standards under DORA specify how each is implemented in practice.
Why does DORA matter for AI risk?
Because AI concentrates critical capability in a small number of model, platform, and cloud providers, and those are ICT third-party services, which is exactly what DORA’s most distinctive pillar governs. An institution’s AI depends on providers whose failure or compromise can propagate across many firms at once, the kind of systemic, concentrated risk that DORA’s register of arrangements, contract requirements, and critical-provider oversight are designed to manage. Supervisors in the US and UK have begun pressing financial firms on AI-related disruption and recovery, and an institution that already runs a DORA-grade third-party program, with a complete register and contracts preserving audit, oversight, and exit rights, is far better placed to answer those questions than one relying on scattered, inconsistent vendor arrangements.
What is the DORA register of information?
DORA requires in-scope financial entities to maintain a register of their contractual arrangements with ICT third-party service providers, covering all such arrangements and identifying those that support critical or important functions. The register is a structured inventory that supervisors can request and use, among other things, to identify concentration risk across the sector. Maintaining it accurately requires knowing every ICT provider relationship, what function each supports, and how critical it is, which is a significant undertaking for a large institution with many vendors and embedded services. For AI specifically, the register should capture the model, platform, and cloud providers behind AI systems, because those are ICT third parties whose criticality and concentration are precisely what the register is meant to surface.
How does DORA handle incident reporting?
DORA requires financial entities to establish a process for managing ICT-related incidents, to classify incidents against defined criteria (such as the number of clients affected, duration, geographic spread, data losses, and economic impact), and to report major incidents to the relevant competent authorities within set timelines using standardized templates. The aim is consistent, comparable incident information across the sector so authorities can see systemic patterns. For a firm, this means having the detection, classification, and reporting workflow in place before an incident occurs, because the timelines are tight and the classification criteria specific. An AI-related failure that disrupts a critical service could qualify as a major ICT incident, so an institution’s incident process should be able to recognize and classify AI-driven disruptions, not only traditional IT outages.
Is DORA similar to US operational resilience expectations?
They share goals but differ in form. US financial regulators have long-standing operational-resilience and third-party-risk expectations, expressed through guidance, examinations, and interagency statements, and have recently proposed updated third-party risk guidance and pressed firms on AI-related resilience. DORA differs by being a single binding regulation with specific, prescriptive requirements and technical standards, rather than principles-based supervisory guidance. In practice this means a US firm with EU operations faces DORA’s detailed obligations directly, while its US operations are governed by the more principles-based US framework. Many institutions find it efficient to build to DORA’s structured requirements across the enterprise, since doing so generally satisfies the less prescriptive US expectations as well, rather than running two resilience regimes.
How should a firm start building DORA-grade resilience?
Begin with the two pillars that carry the most work and the most AI relevance: the ICT risk-management framework and third-party oversight. Establish or formalize a documented ICT risk framework owned by the management body, then build a complete register of ICT third-party arrangements, identify which support critical functions, and bring contracts up to the required standard on audit, oversight, and exit, including for AI model and cloud providers. In parallel, stand up incident classification and reporting aligned to the required criteria and timelines, and a resilience-testing program scaled to the firm’s significance. Confirm the specific obligations and thresholds against DORA and its technical standards, and sequence the work by criticality so the highest-risk functions and providers are covered first.
What is threat-led penetration testing under DORA?
DORA requires in-scope financial entities to run a digital operational resilience testing program, and for entities identified as significant it requires advanced testing in the form of threat-led penetration testing (TLPT) on a periodic basis. TLPT simulates the tactics, techniques, and procedures of real adversaries against the firm’s live production systems that support critical functions, going well beyond routine vulnerability scanning to test whether the institution can actually withstand and recover from a sophisticated attack. The testing is conducted under defined requirements, can involve critical ICT third-party providers, and produces findings the firm must remediate. For institutions adopting AI in critical functions, resilience testing should increasingly account for AI-specific failure and attack modes, so that the testing program reflects where new operational risk is concentrating.
Does PiTech help with operational resilience and DORA?
Yes. PiTech Solutions helps financial firms build the operational-resilience and third-party-oversight capability DORA codifies: an ICT risk-management framework, incident classification and reporting aligned to the required criteria, resilience testing, and a third-party register with the contract and oversight controls DORA demands, extended to the AI model and cloud providers that now carry concentrated risk. It connects resilience to the AI, data, and vendor-risk governance behind it, so operational resilience and AI governance share one foundation. Delivery runs under CMMI Level 3 and ISO 27001, 9001, and 42001 certifications. PiTech works alongside legal and compliance teams rather than replacing them, and is positioned as a specialist resilience and AI-governance partner for financial services at a mid-market price.