An Actionable DORA Regulation Requirements Guide Covering ICT Risk, Third-Party Oversight, and Incident Reporting for US-Headquartered Firms with EU Exposure

Executive Summary

The Digital Operational Resilience Act (DORA) became fully applicable on January 17, 2025. If your US-headquartered firm operates an EU-licensed bank, investment firm, insurance company, payment institution, or asset manager, DORA applies to you now — not eventually.

This guide gives you a practical DORA compliance checklist organized across the five pillars of the regulation: ICT risk management, incident reporting, resilience testing, third-party risk, and governance.

It also maps DORA requirements against familiar US frameworks (NIST CSF, OCC Third-Party Risk Guidance, CIRCIA) so you can identify gaps without starting from scratch. The 90-day roadmap at the end gives your team a sequenced action plan with owners and outputs.

1. What Is DORA and Why Does It Matter to US Firms?

DORA — Regulation (EU) 2022/2554 — is a horizontal EU regulation that establishes binding ICT risk management, incident reporting, resilience testing, and third-party oversight requirements for financial entities operating within the European Union.

Unlike a directive, it does not require national transposition: it applies directly and uniformly across all 27 EU member states. The European Banking Authority (EBA), European Insurance and Occupational Pensions Authority (EIOPA), and European Securities and Markets Authority (ESMA) — collectively the European Supervisory Authorities (ESAs) — published the final regulatory technical standards (RTS) and implementing technical standards (ITS) in 2024, giving firms the detailed specifications needed for full implementation.

For US firms, the key insight is this: DORA does not care where your headquarters are. If your EU subsidiary, branch, or licensed entity uses your US parent’s ICT infrastructure, cloud services, or shared technology platforms, those systems and the contracts supporting them must meet DORA standards.

This creates compliance obligations that cascade upstream from the EU entity to the US parent’s ICT, procurement, legal, and risk functions.

The regulation covers roughly 22,000 financial entities across the EU. Non-compliance carries administrative sanctions up to EUR 10 million or 5% of global annual turnover for financial entities, and supervisory oversight by EU competent authorities including the possibility of on-site inspections.

For ICT providers designated as Critical Third-Party Providers (CTPPs) by the ESAs, EU Lead Overseers have direct supervisory powers. The ESA DORA Oversight Framework published in 2024 outlines how this will operate in practice.

2. Does DORA Apply to Your Organization? Scope Determination

The first step in any DORA compliance program is confirming whether and how DORA applies to your specific operations. The table below covers the most common configurations for US firms with EU exposure.

Table 1: DORA Scope Determination for US-Headquartered Organizations

One critical nuance: DORA applies to the EU-licensed entity, but the obligations frequently require action by the US parent.

For example, if the EU subsidiary relies on a US parent-negotiated cloud contract with AWS or Microsoft Azure, that contract must now include DORA-mandated clauses (Article 30).

The US parent’s procurement and legal teams must update master service agreements accordingly. This is not optional and is not mitigated by the fact that the contract was signed in New York under New York law.

For firms unsure whether their specific EU activity triggers DORA, the EBA’s list of financial entities subject to DORA Article 2 provides a definitive reference.

Payment institutions, e-money institutions, and crypto-asset service providers (CASPs) under MiCA are all included.

3. The Five Pillars of DORA: What Each One Requires

DORA is organized around five substantive pillars. Understanding what each pillar requires before you work through the checklist will help you prioritize effort correctly.

Pillar 1: ICT Risk Management (Articles 5-16)

This is the foundational pillar. DORA requires every in-scope financial entity to maintain a documented, Board-approved ICT risk management framework that covers the full risk lifecycle:

identification of ICT assets and threats, protection and prevention controls, detection systems, response protocols, recovery capabilities, and continuous learning. The framework must be reviewed at least annually and after every major incident.

For US firms, the closest analog is the NIST Cybersecurity Framework (CSF 2.0) or the FFIEC Cybersecurity Assessment Tool. The critical difference is that DORA is mandatory, prescriptive, and subject to EU regulatory inspection.

A firm that has implemented NIST CSF rigorously will have a significant head start, but will still need to document DORA article-by-article mapping and address specific requirements around Board accountability and ICT business continuity that are more detailed than the NIST voluntary guidance.

Our post on ICT risk management frameworks covers the technical architecture of a DORA-compliant ICT risk program, including the asset inventory and control design requirements under Articles 7–9.

Pillar 2: ICT-Related Incident Reporting (Articles 17-23)

DORA establishes a three-stage reporting regime for major ICT incidents. Stage one is an initial notification to the National Competent Authority (NCA) within four hours of classifying an incident as major.

Stage two is an intermediate report within 72 hours of the initial notification. Stage three is a final report within one month of resolving the incident, including root cause analysis and corrective actions.

The incident classification methodology is defined in RTS under Article 18, covering criteria including client impact, duration, geographic spread, data loss, and financial impact.

For US firms, this timeline is materially tighter than the OCC’s 36-hour notification requirement (OCC Bulletin 2021-35) and requires a separate reporting track to EU NCAs that most US compliance teams have not previously operated.

Pillar 3: Digital Operational Resilience Testing (Articles 24-27)

All in-scope entities must conduct annual basic resilience testing including vulnerability assessments and network security tests.

Significant financial entities — determined by size, systemic importance, and risk profile — must additionally conduct Threat-Led Penetration Testing (TLPT) every three years, aligned to the TIBER-EU framework. TLPT is a structured, intelligence-led red team exercise that tests critical systems and people simultaneously.

For US firms already conducting CBEST (UK) or CORIE (Australia) testing, TIBER-EU follows similar methodology.

The European Central Bank has published the TIBER-EU Framework Implementation Guide which provides the detailed test lifecycle. All TLPT findings must be remediated and tested again before the cycle closes.

Pillar 4: ICT Third-Party Risk Management (Articles 28-30)

This is the pillar most likely to require immediate action from US parent entities. DORA requires financial entities to maintain a register of all ICT third-party service providers, classify them by criticality, conduct pre-contract due diligence, include mandatory contract clauses (detailed in Section 6 below), monitor ongoing performance, manage concentration risk, and maintain documented exit strategies.

These requirements apply to the full vendor chain including material subcontractors.

US firms that rely on group-level contracts negotiated by the US parent for shared cloud, data center, network, or software services need to review every such contract for DORA clause compliance immediately.

Article 30 requires specific provisions that many US-standard technology contracts do not include.

Pillar 5: Information Sharing and Governance

DORA encourages — but does not mandate — participation in cyber threat intelligence sharing arrangements (Article 45).

On governance, Article 5 requires a named Board member to be accountable for ICT risk oversight, and the Board must approve the ICT risk framework, review it annually, and receive regular ICT risk reporting.

This Board-level named accountability is more explicit than most US frameworks outside of OCC Heightened Standards for large banks.

4. DORA Compliance Checklist: 30 Requirements Across Five Pillars

Use this checklist as your working compliance inventory. For each item, assign a status and an owner. Priority ratings: Critical = regulatory breach risk if not addressed; High = material gap; Medium = best practice gap. Update the status column as you complete each requirement.

Table 2: DORA Compliance Checklist — 30 Requirements with Priority, Status Tracker, and Owner

5. Incident Classification: When Does the 4-Hour Clock Start?

The incident reporting timeline under DORA Article 19 starts running from the moment you classify an incident as ‘major’ — not from when the incident actually began. This means your classification methodology is itself a compliance control.

Classify too slowly, and you have missed the notification deadline. Classify incorrectly, and you face supervisory scrutiny over your methodology.

The table below summarizes the seven classification criteria from the Article 18 RTS. You should build these criteria into your incident response playbook as a mandatory decision gate.

Table 3: DORA Major Incident Classification Criteria (Article 18 RTS)

Practical tip: build a simple two-step classification triage into your incident response process. Step one is a 30-minute initial assessment within one hour of detecting a significant ICT event, using the criteria above.

Step two is a 90-minute detailed classification review. This gives you time to correctly classify while still meeting the four-hour notification window, which runs from classification, not detection.

For a comprehensive incident response framework that integrates DORA notification requirements with your existing business continuity management program and IT disaster recovery plan, see our dedicated BCM guides.

6. ICT Third-Party Contracts: The Nine Mandatory DORA Clauses

Article 30 of DORA specifies a minimum set of provisions that must appear in every contract between a financial entity and an ICT third-party service provider.

For US firms, the most common gap is the audit rights clause and the exit strategy provisions, which many standard US technology contracts exclude or limit. The table below covers all nine required elements with implementation guidance.

Table 4: DORA Article 30 Mandatory Contract Clauses with Implementation Guidance

One clause that deserves special attention for US firms is the data location requirement. DORA Article 30(2)(b) requires the contract to specify where data will be processed and stored.

If your EU entity’s data is processed in US data centers under a US parent agreement, you need to document this clearly and assess whether it is consistent with GDPR cross-border transfer requirements (Standard Contractual Clauses under Article 46 GDPR).

This is a DORA and GDPR intersection point that many US firms have not yet addressed.

For a detailed template on vendor risk due diligence that maps to DORA Article 28, see our guide on third-party risk management frameworks. For concentration risk analysis across your ICT vendor portfolio, see our post on operational risk management.

7. DORA vs. US Frameworks: Where the Gaps Actually Are

US financial institutions are not starting from zero. Most firms subject to NIST CSF, FFIEC guidance, OCC Third-Party Risk Management, or CIRCIA already have substantial ICT risk infrastructure.

The question is not whether you have controls — it is whether those controls meet DORA’s specific requirements. The table below identifies the five most important gap areas.

Table 5: DORA vs. US Framework Comparison — Gap Areas for US Firms

The most commonly underestimated gap in practice is incident reporting to EU NCAs. US firms have existing relationships with the OCC, Federal Reserve, FDIC, and CISA for US incident reporting.

DORA creates a parallel track to EU supervisors — different authorities, different timelines, different report formats, and different escalation chains. You need a DORA-specific incident reporting protocol that sits alongside your US reporting process, not inside it.

For broader context on how DORA fits into global operational resilience regulation alongside the UK’s PS21/3, Australia’s CPS 230, and the US’s own evolving cyber rules, see our post on operational resilience frameworks.

8. Critical Third-Party Providers: What US Tech Firms Need to Know

DORA Article 31 empowers the ESAs to designate ICT providers as Critical Third-Party Providers (CTPPs) and subject them to direct EU supervision. This is unprecedented: it gives EU regulators supervisory reach over US technology companies that provide services to EU financial entities, regardless of where those companies are domiciled.

The ESAs have identified initial criteria for CTPP designation including systemic importance (how many EU financial entities rely on the provider), substitutability (how difficult it would be to switch), and cross-border impact.

Major US cloud providers — AWS, Microsoft Azure, Google Cloud — and critical SaaS providers are the most likely candidates for CTPP designation.

If your US firm is a technology provider to EU financial entities, you should monitor the ESA CTPP designation process closely.

Designated CTPPs must cooperate with an EU Lead Overseer, participate in oversight activities, and remediate identified vulnerabilities. The EBA DORA CTPP oversight portal provides updates on designation decisions.

9. Five DORA Implementation Mistakes US Firms Make

Mistake 1: Treating DORA as an IT Department Project

DORA is a legal compliance obligation with Board accountability requirements, contractual implications, and regulatory reporting obligations. It belongs jointly to Legal, Compliance, Risk, and IT — with Board sponsorship.

Firms that assign it solely to the CISO or IT security team routinely miss the contract review, incident reporting, and governance requirements.

Mistake 2: Assuming US Regulatory Compliance Covers EU Requirements

Meeting OCC Third-Party Risk Guidance does not mean your ICT vendor contracts meet DORA Article 30. Meeting CIRCIA incident reporting timelines does not mean you have a DORA-compliant NCA notification process.

These frameworks share goals but have different requirements, timelines, and recipients. Run a dedicated DORA gap assessment — do not rely on a US compliance certification to stand in for it.

Mistake 3: Missing the Group-Level Contract Problem

US parent entities often negotiate enterprise-wide technology contracts that EU subsidiaries then use.

Under DORA, the EU subsidiary is the financial entity with the compliance obligation, but the contract is held by the US parent. You need either to renegotiate master agreements to include DORA clauses or to enter addenda that apply DORA terms to the EU entity’s use of the services. This requires legal and procurement engagement at the parent level.

Mistake 4: Underbuilding the Incident Classification Engine

The four-hour initial notification window is unforgiving.

Firms that do not have a pre-built, tested incident classification process with clear criteria, designated decision-makers, and pre-drafted notification templates will miss this deadline in a real incident. Build and test the classification process before an incident forces you to use it.

Mistake 5: Forgetting Proportionality

DORA Article 16 provides a simplified ICT risk management regime for microenterprises and small non-complex entities.

US firms with small EU operations sometimes over-engineer their DORA response. Check whether your EU entity qualifies for the proportionate regime before building a full Pillar 1 framework — it could save significant compliance effort.

10. 90-Day DORA Readiness Roadmap

DORA has been applicable since January 17, 2025. If your firm has not yet completed a structured readiness assessment, the priority is to close the most critical gaps as quickly as possible. The roadmap below is sequenced to address regulatory breach risk first, then build the structural foundations.

Table 6: DORA 90-Day Readiness Roadmap

A practical tip on resourcing: most US firms that have been through this process report that the legal contract review (Pillar 4, Article 30 clauses) is the longest-lead-time workstream.

If you have more than 20 critical ICT vendors, start the contract review in Month 1 even if other workstreams are still in scoping. Contract renegotiations with major technology providers can take 60 to 90 days on their own.

11. What Comes Next: DORA Supervisory Priorities for 2025-2026

EU supervisors have indicated that their initial DORA enforcement focus will be on the largest and most systemic firms — the same institutions subject to EBA stress testing and ECB SREP. However, the supervisory perimeter will expand.

The EBA’s DORA supervisory convergence work program for 2025 includes developing common supervisory methodologies, harmonizing incident classification across member states, and progressing CTPP designation.

Three developments US firms should track: first, the CTPP designation list when published by ESAs — this will determine which of your US technology vendors are subject to EU oversight.

Second, the harmonized incident reporting template under DORA Article 20 implementing technical standards — this will standardize the format of notifications to NCAs. Third, the TLPT mutual recognition framework — the ESAs are working to allow TLPT results performed in one EU member state to be recognized by NCAs in other member states, reducing testing duplication. The EBA DORA implementation timeline provides the current supervisory calendar.

For firms also navigating the EU AI Act, NIS2 Directive, and GDPR alongside DORA, see our post on AI and machine learning risk management and our enterprise risk management framework guide for an integrated compliance architecture approach.

Key External References and Regulatory Sources

• European Parliament. (2022). Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA). Official Journal of the EU.
• European Banking Authority (EBA). DORA Final RTS and ITS Package — eba.europa.eu/regulation-and-policy/operational-resilience
• European Central Bank. TIBER-EU Framework Implementation Guide — ecb.europa.eu
• ESMA. DORA Oversight Framework for Critical ICT Third-Party Providers — esma.europa.eu
• OCC Bulletin 2021-35: Computer-Security Incident Notification Requirements — occ.gov
• OCC Third-Party Risk Management Guidance (2023) — occ.gov
• NIST Cybersecurity Framework 2.0 — nvlpubs.nist.gov
• FFIEC Cybersecurity Assessment Tool — ffiec.gov
• CIRCIA: Cyber Incident Reporting for Critical Infrastructure Act (2022) — cisa.gov
• Federal Reserve SR 13-19: Supervisory Guidance on Managing Outsourcing Risk — federalreserve.gov
• ISO/IEC 27001:2022 Information Security Management Systems — iso.org
• ISO 22301:2019 Business Continuity Management Systems — iso.org
• Basel Committee on Banking Supervision. Principles on Operational Resilience (2021) — bis.org

Ready to Start Your DORA Compliance Program?

Start with the 30-item checklist in Section 4. Work through scoping first, then prioritize the Critical items — these carry the most significant regulatory breach risk. Assign a single senior owner for DORA program coordination (typically the CRO or General Counsel for EU operations) and report progress to the Board quarterly.

Browse our full library of practitioner-ready templates at riskpublishing.com, including BCM templates, ICT risk frameworks, third-party risk registers, and KRI dashboards designed for compliance professionals who need to move quickly.

Related Resources on RiskPublishing.com

ICT Risk Management Framework Guide | DORA Pillar 1 technical architecture and control design

Business Continuity Management (ISO 22301) | BCP templates integrating DORA ICT continuity requirements

IT Disaster Recovery Plan Guide | DRP templates with RTO/RPO aligned to DORA Article 11

Third-Party Risk Management Framework | Vendor register and due diligence templates for DORA Article 28-30

Operational Risk Management | ICT concentration risk identification and monitoring

Operational Resilience Frameworks | DORA, UK PS21/3, and global resilience regulation comparison

Key Risk Indicators: Complete Framework | KRI design for ICT and cyber risk monitoring

Enterprise Risk Management Framework | Integrating DORA into your ERM architecture

AI and Machine Learning Risk Management | KRIs for algorithmic systems subject to DORA and EU AI Act

Risk Quantification for Boards | Translating DORA compliance gaps into financial exposure for board reporting

Three Lines Model Implementation Guide | Assigning DORA ownership across first, second, and third lines

Project Risk Assessment Templates | Risk tools for DORA implementation projects

Risk Appetite Statement Development | Setting ICT risk appetite thresholds under DORA governance requirements

COSO ERM Framework Guide | Aligning DORA ICT risk framework to COSO ERM architecture

ESG Key Risk Indicators Framework | For firms navigating DORA alongside EU sustainability disclosure requirements

References

1. European Parliament and Council. (2022). Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector (DORA). Official Journal of the European Union.

2. European Banking Authority. (2024). Final Report: Draft RTS on ICT Risk Management Framework under DORA Articles 15 and 16. EBA.

3. European Central Bank. (2018). TIBER-EU: Framework for Threat Intelligence-Based Ethical Red Teaming. ECB.

4. ESAs Joint Committee. (2024). Final Report on DORA Oversight Framework for Critical ICT Third-Party Providers. ESMA.

5. Office of the Comptroller of the Currency. (2021). OCC Bulletin 2021-35: Computer-Security Incident Notification Requirements. OCC.

6. OCC, Federal Reserve, FDIC. (2023). Interagency Guidance on Third-Party Relationships: Risk Management. OCC.

7. NIST. (2024). Cybersecurity Framework 2.0. National Institute of Standards and Technology.

8. CISA. (2022). Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). CISA.

9. Basel Committee on Banking Supervision. (2021). Principles for Operational Resilience. BIS.

10. ISO. (2022). ISO/IEC 27001:2022 Information Security Management Systems — Requirements. ISO.

11. ISO. (2019). ISO 22301:2019 Security and Resilience — Business Continuity Management Systems. ISO.

12. Federal Reserve. (2013). SR 13-19: Guidance on Managing Outsourcing Risk. Board of Governors.

13. FFIEC. (2015). Cybersecurity Assessment Tool. Federal Financial Institutions Examination Council.

Chris Ekai

Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.