The short answer: DORA (Regulation EU 2022/2554) entered into force January 17, 2025, and its obligations reach far more US mid-market finance teams than most Controllers assume. A 300–1,500 emp PE portco with any EU subsidiary, EU customer billed in EUR, EU data processor in the ICT supply chain, or US cloud/SaaS vendor whose EU customers fall under DORA inherits Article 28 (ICT third-party risk management) and Article 30 (key contractual provisions) obligations through the extended-reach mechanism. The practical scope: ICT risk management framework under Articles 5–14, incident reporting under Article 17, resilience testing under Articles 24–27, and third-party oversight under Articles 28–30. Approximately 62 percent of DORA's ICT control population overlaps with SOX ITGC under PCAOB AS 2201 §.39, and roughly 78 percent overlaps with SOC 2 Trust Services Criteria CC7 (system operations) and CC8 (change management). The correct architecture is a single evidence stack that maps one test execution to all three frameworks, not three parallel compliance programs. Platforms that do not explicitly produce DORA-shaped evidence force manual re-formatting at every ICT incident reporting cycle and every major third-party review.
This post is written for the Controller, Internal Audit Director, CISO, or Chief Risk Officer at a 300–1,500 emp US mid-market company that has discovered — usually through an EU customer's contractual cascade or an EU subsidiary's regulatory notice — that DORA obligations apply. The reader is assumed compliance-literate but not DORA-specialized, and is specifically looking for the mid-market answer, not the Fortune 500 consulting-firm playbook.
What is DORA and when did it take effect?
DORA, the Digital Operational Resilience Act, is EU Regulation 2022/2554, published December 14, 2022, entering into force January 17, 2025. Unlike GDPR (which regulates personal data) or the EU AI Act (which regulates AI systems), DORA regulates the digital operational resilience of financial entities — banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and the ICT third parties that serve them. The regulation is directly applicable in all EU Member States without national transposition, which makes compliance uniform across the EU but also means a US mid-market company cannot rely on country-specific guidance to scope obligations.
The regulatory architecture is five pillars. ICT risk management (Articles 5–14). ICT-related incident reporting (Articles 17–23). Digital operational resilience testing (Articles 24–27). Management of ICT third-party risk (Articles 28–44). Information-sharing arrangements (Articles 45–49). The five pillars each impose continuous obligations rather than point-in-time certifications, which is why the framework is an ongoing operational cost rather than an annual audit exercise.
The extended reach to non-EU entities is the mechanism that catches US mid-market. Article 3(21) defines "ICT third-party service provider" broadly enough to include US SaaS vendors serving EU financial entities. Article 28(1) obligates EU financial entities to apply DORA requirements to all their ICT third parties, which cascades the contractual obligations to the US vendor. The vendor's sub-processors then inherit the same cascade under Article 30 (key contractual provisions). This is the mechanism by which a US mid-market fintech serving even one EU-regulated customer inherits DORA scope.
Does DORA apply to a US mid-market company without an EU subsidiary?
Yes, more often than expected, through four mechanisms.
First, direct EU subsidiary: any US company with an EU-incorporated subsidiary providing financial services (lending, payments, insurance, crypto-asset services) is a DORA-regulated financial entity under Article 2(1) and must meet the full regulation.
Second, ICT third-party to an EU financial entity: under Article 28(1), any ICT service provider (cloud, SaaS, data analytics, hosting) serving an EU-regulated financial entity must meet Article 30 contractual provisions including sub-contracting notification, audit rights, incident reporting cooperation, and exit strategies. A US SaaS vendor signing a banking customer in Germany inherits these.
Third, designated critical ICT third-party provider (CTPP) under Article 31: the European Supervisory Authorities can designate a US ICT provider as "critical" based on EU financial sector dependency, subjecting the provider to direct supervision. As of early 2026, approximately 20 non-EU providers have been designated CTPP, including several large US cloud and SaaS companies.
Fourth, sub-processor cascading under Article 30(2): if your US company sits in an EU financial entity's ICT supply chain as a sub-processor (even at three layers deep), your direct customer's contractual obligations flow through to you. The scope is wider than most Controllers realize on first read.
Practical test: if your company sells to any EU bank, insurance company, investment firm, payment institution, or crypto-asset service provider, DORA scope applies to the service you provide. If you process personal or operational data for such a customer's operations, DORA scope applies. If you are a sub-processor in an EU financial entity's supply chain, DORA scope applies.
What do Articles 5–14 (ICT risk management framework) require?
Articles 5 through 14 establish the ICT risk management framework that governs how a DORA-regulated entity identifies, assesses, mitigates, monitors, and reports ICT risk. The requirements map directly to SOX ITGC under PCAOB AS 2201 §.39 (evidence of control operation) and SOC 2 TSC CC7 (system operations) and CC8 (change management).
Article 5 requires a documented ICT risk management framework approved by the management body at least annually. The framework must cover risk identification, protection and prevention, detection, response and recovery, learning and evolving, and communication. This maps to the SOX ITGC risk assessment under AS 2201 §.36 (planning the engagement) and the SOC 2 CC3.2 (risk identification) criterion.
Article 6 requires the ICT risk management framework to include continuous monitoring of ICT systems and tools. Continuous monitoring here maps cleanly to agent-driven continuous control testing under SOX — the same evidence stream that demonstrates SOX ITGC operating effectiveness can demonstrate DORA Article 6 continuous monitoring. This is the primary opportunity for evidence-stack consolidation.
Article 7 requires protection and prevention measures: network security, access management, vulnerability management, cryptographic key management. These overlap directly with SOX ITGC access review controls and SOC 2 TSC CC6 (logical access).
Article 8 requires detection: logging, anomaly detection, incident detection, threshold-based alerting. This overlaps with SOC 2 TSC CC7.2 (monitoring) and SOX ITGC logging controls.
Articles 9 and 10 require response and recovery capabilities: incident response plan, business continuity plan, disaster recovery plan, tested annually. Overlaps with SOX ITGC business continuity controls and SOC 2 TSC CC7.5 (recovery).
Article 11 requires a policy on ICT backup, restoration, and recovery procedures — specifically addressing recovery time objectives (RTO) and recovery point objectives (RPO) per critical or important function. Overlaps with SOX ITGC backup controls.
Articles 12, 13, and 14 require learning, evolving, and communication mechanisms including post-incident analysis, threat intelligence, and management body reporting. These map to SOC 2 CC7.4 (incident response) and SOX ITGC deficiency reporting.
The aggregate: a well-constructed ICT risk management framework produces evidence that satisfies DORA Articles 5–14, SOX ITGC under AS 2201 §.39, and SOC 2 TSC CC6–CC8 simultaneously. The evidence stack consolidation is the primary economic rationale for a single agent-driven testing platform in a multi-framework environment.
What does Article 17 (ICT incident reporting) require?
Article 17 requires DORA-regulated entities to classify ICT-related incidents based on impact thresholds (Article 18) and report major ICT-related incidents to the competent authority within specified timeframes under Article 19.
The reporting cadence: initial notification within 4 hours of classifying an incident as major, intermediate reports within 72 hours, final report within 1 month. The specific timelines are set by the Commission Delegated Regulation supplementing DORA on incident reporting technical standards.
The overlap with SOX ITGC: incident evidence pulled continuously from source systems (logging, SIEM, identity, cloud) produces the same evidence stream required to demonstrate SOX ITGC incident response controls operating effectively. Agent-driven continuous monitoring reduces the incident classification and evidence-gathering time from the typical 24–48 hour manual process to sub-hour automated assessment, which matters when the 4-hour initial notification clock starts at detection.
The overlap with SOC 2: TSC CC7.3 (identification of security events) and CC7.4 (response to security events) produce DORA Article 17 evidence when the logging and alerting infrastructure is designed to emit DORA-taxonomy-compatible records.
The practical implication: a US mid-market company that sells to any EU financial entity must be able to produce an Article 17 incident notification within 4 hours of classifying an incident as major. The evidence to support that notification must be pulled from systems, authenticated, and available in structured form. Manual spreadsheet-based SOX evidence does not meet this operational requirement. Continuous agent-driven testing does.
What do Articles 28–30 (third-party ICT risk management) actually impose?
Articles 28 through 30 are the pillar most 300–1,500 emp US mid-market companies encounter first, because the EU customer's compliance team sends a vendor DORA questionnaire cascade.
Article 28(1) requires DORA-regulated entities to apply the ICT risk management framework to all their ICT third parties. In practice, this means every US SaaS vendor to an EU bank receives a detailed questionnaire covering incident reporting cooperation, audit rights, sub-contracting disclosure, security controls, and resilience testing evidence.
Article 28(2) requires a concentration risk assessment — the EU financial entity must demonstrate it has not created unacceptable dependency on a single ICT provider. Practical implication: US vendors whose concentration in an EU financial entity's ICT stack is high face additional due diligence.
Article 28(3) requires a register of information containing all contractual arrangements with ICT third parties, maintained continuously. The register must be provided to the competent authority on request. US vendors cooperate by providing structured contract metadata.
Article 30 sets out the key contractual provisions. Sub-paragraph (2) requires minimum terms: service description, location of services, data protection, security, audit rights, access and inspection rights, cooperation with competent authorities, cooperation with incident reporting, service level specifications, notification of material changes. Sub-paragraph (3) adds higher-standard terms for ICT services supporting "critical or important functions" — exit strategies, full cooperation with resolution planning, participation in Threat-Led Penetration Testing (TLPT) when applicable.
The evidence implication: a US vendor must be able to demonstrate the contractual commitments on demand. Audit rights in particular require the vendor to produce control-operating-effectiveness evidence in a format the EU financial entity's auditor can consume. Agent-produced signed evidence with SHA-256 hash and preserved reasoning traces meets the audit-right expectation more defensibly than document-centric workpapers. The evidence format matters at every third-party audit request.
How does DORA overlap with SOX ITGC, SOC 2, ISO 42001, and CMMC 2.0?
Multi-framework overlap is where mid-market programs either win or lose time. The honest overlap mapping:
SOX ITGC (PCAOB AS 2201 §.39, .42, .46–.50): approximately 62 percent of DORA Articles 5–14 ICT control activities are mapped to SOX ITGC control families. Access management (DORA Art 7) maps to SOX access review. Change management evidence overlaps heavily. Backup and recovery evidence (DORA Art 11) maps to SOX ITGC backup controls. Continuous monitoring (DORA Art 6) maps to SOX ITGC automated controls. Incident handling (DORA Arts 8–10) maps to SOX ITGC incident controls. The non-overlapping remainder is primarily DORA's resilience testing (Art 24–27) and concentration risk (Art 28(2)) scope which have no direct SOX analog.
SOC 2 Trust Services Criteria (AICPA TSP Section 100 as revised): approximately 78 percent of DORA requirements map to SOC 2 CC6 (logical access), CC7 (system operations), CC8 (change management), and CC9 (risk mitigation). The SOC 2 + DORA overlap is the highest of any framework pair in the mid-market stack.
ISO 42001 (AI management systems): limited direct overlap because DORA does not explicitly regulate AI governance. Indirect overlap where the ICT risk management framework itself uses AI (e.g., continuous monitoring agent, anomaly detection model) — the AI system governance then falls under ISO 42001 as well.
CMMC 2.0 (defense contractor cybersecurity): approximately 45 percent overlap at the control-family level, concentrated on access control (AC), audit and accountability (AU), configuration management (CM), incident response (IR), and system and communications protection (SC). Mid-market companies with both DORA and CMMC 2.0 scope can consolidate evidence collection at a significant scale.
EU AI Act: minimal direct overlap because the EU AI Act targets AI system governance rather than ICT operational resilience. The EU AI Act Article 17 (record-keeping) and Article 18 (documentation) overlap with DORA Article 17 incident reporting when the incident involves an AI system covered by EU AI Act.
The practical stack: a mid-market company running SOX + SOC 2 + DORA + ISO 42001 + CMMC 2.0 simultaneously can produce evidence for all five frameworks from a single well-designed continuous testing stream. A company running five parallel compliance programs duplicates approximately 65 percent of the evidence work. The evidence consolidation rationale is the primary economic argument for an agent-driven continuous testing platform at mid-market scale.
What does DORA evidence actually look like?
An Article 6 continuous monitoring evidence record for a 650-employee PE portco with EU customers typically contains: the control objective (e.g., "Logical access to critical ICT systems is reviewed and access of terminated users is removed within 48 hours"); the source systems queried (Okta, Workday, AWS IAM, Azure AD); the time window (rolling daily cadence); the observed data snapshot with SHA-256 hash; the agent's reasoning trace (the interpretive steps taken to determine whether the control operated effectively); the pass/fail determination; the control-owner sign-off; and the framework tag mapping that emits the same evidence for SOX ITGC, SOC 2 CC6.2 (access removal), and DORA Article 7 (protection and prevention).
This evidence format maps cleanly to Article 17 incident reporting when an exception surfaces: the record contains the incident trigger, the impact scope, the detection timestamp, and the response evidence. The 4-hour notification clock starts at classification, and the evidence bundle is already formatted for the competent authority's submission format.
Platforms that produce document-centric evidence (screenshots, PDF attachments, SharePoint files) require manual re-formatting at every DORA reporting cycle and every third-party audit cascade. Platforms that produce structured agent-executed evidence with framework tag mappings feed DORA workflows directly.
What does implementation actually look like for a mid-market company?
Phase 1 (weeks 1–4): scope assessment. Identify which DORA articles apply based on EU customer exposure, EU subsidiary status, and sub-processor chain depth. Build the register of information under Article 28(3). Assess concentration risk under Article 28(2).
Phase 2 (weeks 4–12): ICT risk management framework construction. Document the framework under Article 5. Integrate continuous monitoring under Article 6. Implement protection measures under Article 7 (access management, vulnerability management, cryptography). Configure detection under Article 8.
Phase 3 (weeks 8–16): incident reporting infrastructure. Build the Article 17 incident classification and reporting workflow. Test the 4-hour, 72-hour, and 1-month reporting cadences in a simulation exercise.
Phase 4 (weeks 12–20): resilience testing under Articles 24–27. Design the Threat-Led Penetration Testing (TLPT) program where applicable. Execute the advanced digital resilience testing program.
Phase 5 (weeks 16–24): third-party risk management. Execute Article 28 concentration risk assessment. Update contractual provisions under Article 30 across the ICT supply chain. Establish Article 30(3) higher-standard terms for critical or important functions.
Phase 6 (steady-state): continuous operation. The framework is continuously monitored, incidents are continuously classified and reported, third-party reviews are continuously maintained.
A mid-market company running DORA on top of existing SOX and SOC 2 programs typically sees an additional 800–1,500 internal compliance hours per year if evidence is collected in parallel stacks, or 200–400 additional hours if evidence is consolidated through a continuous-testing platform with framework-tag mappings. The consolidation is decisive.
How should mid-market companies evaluate a DORA-capable platform?
Six questions separate DORA-capable platforms from SOX-only platforms with a DORA tag.
First, does the platform produce structured agent-executed evidence with framework tag mappings, or document-centric workpapers? Agent-executed evidence with structured output feeds DORA workflows directly; document-centric evidence requires manual re-formatting.
Second, does the evidence format support Article 17 incident reporting within the 4-hour initial notification window? The evidence must be machine-readable and pre-formatted for the competent authority's submission.
Third, does the platform produce concentration-risk visibility under Article 28(2)? A mid-market company has limited ability to assess its own concentration in an EU financial entity's ICT stack without vendor-provided visibility.
Fourth, does the platform support audit rights under Article 30? An EU financial entity auditor may request evidence directly. The platform must support auditor-scoped access without compromising broader system security.
Fifth, does the evidence map cleanly to the SOX, SOC 2, and CMMC 2.0 overlaps? Without multi-framework mapping, the evidence work duplicates across frameworks.
Sixth, does the platform preserve reasoning traces and cryptographic hashing? These are not DORA-specific requirements, but they are the evidence characteristics that make the record defensible across all frameworks simultaneously.
The takeaway
DORA is not a European problem for European companies. It is an ICT risk management obligation that cascades through the EU financial entity's supply chain and reaches US mid-market companies more often than expected. The 300–1,500 emp PE portco with any EU customer, EU subsidiary, or sub-processor relationship inherits DORA scope whether or not it has seen the regulation explicitly mentioned.
The correct architecture is evidence consolidation. Articles 5–14 (ICT risk management), Article 17 (incident reporting), and Articles 28–30 (third-party risk) overlap heavily with SOX ITGC, SOC 2 TSC CC6–CC8, and CMMC 2.0 control families. A single well-designed continuous-testing platform with framework-tag mappings produces evidence for all frameworks simultaneously, saving approximately 800–1,500 internal compliance hours per year at mid-market scale.
Agent-driven continuous testing is particularly well-suited to DORA because Article 6 requires continuous monitoring, Article 17 requires rapid incident classification within 4 hours, and Article 28 requires on-demand evidence production for third-party audits. Document-centric legacy platforms force manual re-formatting at every DORA workflow.
If your company is a 300–1,500 emp mid-market finance team with any EU exposure, the next step is concrete: run the scope assessment (Phase 1) to determine which articles apply, then evaluate whether your current SOX and SOC 2 platforms produce DORA-shaped evidence or force parallel stacks. Request a design partner slot to walk through the multi-framework mapping. Related reading: continuous control testing primer for the agent-testing architecture; SOX automation for PE portfolio companies for the PE portco context.