The Digital Operational Resilience Act (DORA) applies to financial entities from January 17, 2025. If you’re acquiring a bank, insurer, asset manager, investment firm, or any entity operating under an FCA, PRA, or European financial regulator authorization, DORA applies to the target.
DORA creates specific obligations that survive ownership changes. When you acquire a financial entity, you inherit its ICT third-party risk register. And that register has to meet DORA’s standards — including the requirement that it covers all critical ICT third-party dependencies, not just the ones the target has traditionally tracked.
DORA’s Five Pillars
DORA is organized around five operational resilience pillars:
1. ICT Risk Management — The entity must have a comprehensive ICT risk management framework. This includes: asset registers, threat intelligence, vulnerability management, change management, and business continuity testing. The framework must be proportionate to the entity’s risk profile and system criticality.
2. ICT-Related Incident Reporting — Major ICT incidents must be reported to the competent authority within 4 hours of classification (for major incidents that meet DOR thresholds), with a final report within 72 hours. The target must have the classification methodology documented and operational.
3. Digital Operational Resilience Testing — Entities must conduct annual threat-led penetration tests (TLPT) for systems categorized as “critical.” For less critical systems, vulnerability assessments and network security assessments are required. TLPT must be conducted by certified third parties.
4. ICT Third-Party Risk Management — This is the pillar with the most M&A implications. Covers: due diligence on third-party providers, contractual requirements, exit strategies, and concentration risk monitoring.
5. Information Sharing — Entities are encouraged (not required) to share threat intelligence within industry partnerships.
The ICT Third-Party Risk Register: What DORA Requires
Under DORA’s third-party risk requirements, the ICT third-party risk register must include:
- All ICT third-party service providers (CTSPs) — defined as any third party delivering ICT services that supports the entity’s critical functions
- Risk assessments for each CTSP covering: criticality of services provided, concentration risk, contractual protections, sub-contracting chain, and exit provisions
- Evidence of contractual terms that meet DORA’s minimum standards (including audit rights, service level commitments, and data localization requirements)
- Annual review and update of the register
The definition of “ICT third-party service provider” is broader than most organizations traditionally use. It includes: cloud providers (AWS, Azure, GCP), managed service providers, software-as-a-service vendors, data analytics providers, and any third party that provides infrastructure, software, or services that the entity’s critical functions depend on.
The Concentration Risk Problem in M&A
When a PE firm acquires a portfolio company that uses the same cloud provider or managed service provider as another portfolio company, this is a concentration risk — a single provider failure would affect multiple entities simultaneously.
DORA specifically requires that financial entities monitor concentration risk in their ICT third-party dependencies. In M&A, the acquirer of multiple financial entities needs to build a consolidated view of which providers are shared across the portfolio and what the failure impact would be.
For a financial services acquirer, the post-acquisition integration work needs to include:
- Merging the ICT third-party risk registers from both entities
- Identifying providers that appear in both registers (concentration risk)
- Assessing whether combined usage crosses any single-provider concentration thresholds
- Updating the consolidated register to reflect the merged entity’s risk appetite
The TLPT Requirement
Threat-Led Penetration Testing (TLPT) is required for all systems supporting critical functions. The test must:
- Be conducted at least every 3 years (annually for systems classified as most critical)
- Use an authorized red team provider (DORA specifies TIBER-EU framework as the model)
- Cover the full kill chain: reconnaissance, initial access, lateral movement, data exfiltration
- Include testing of the entity’s incident response procedures
For an acquirer who doesn’t have TLPT results from the target, the first post-acquisition year needs to include scheduling and conducting a TLPT — which typically takes 3-6 months to arrange with an authorized provider. This is a direct cost of the acquisition that should be in the integration plan.
M&A Specific Issues Under DORA
Contractual Subordination: DORA requires that ICT contracts allow the financial entity to exit the contract if the CTSP fails to meet DORA requirements. In M&A, this needs to be validated for all critical CTSPs. If the acquired company has contracts without exit provisions that meet DORA standards, those contracts need to be renegotiated post-close.
Subcontracting Chains: If a CTSP uses subcontractors (common with cloud providers and MSPs), the financial entity must have visibility into that subcontracting chain and must contractually require the CTSP to flow down DORA requirements. Cloud providers almost universally fail to meet this requirement through their standard contracts — supplementary schedules or DPAs are needed.
Data Processing Agreements: Under GDPR and DORA combined, the financial entity is responsible for ensuring that all CTSPs processing personal data have appropriate DPAs in place. In M&A, the acquired company’s DPA inventory needs to be reviewed against actual data processing activity.
The Regulatory Examination Reality
DORA competent authorities (FCA in the UK, national regulators in the EU) can examine any financial entity’s ICT third-party risk register and demand evidence of compliance. The examination will ask: “Show me your ICT third-party risk register and demonstrate that it covers all CTSPs supporting your critical functions.”
If the answer is “we don’t have a complete register” — that’s a finding. If the critical CTSP list doesn’t match the actual technology architecture because the register was built from contracts instead of from technical discovery — that’s also a finding.
ACQI’s technology discovery module produces the technical architecture map that validates (or corrects) the ICT third-party risk register. It’s the difference between a register built from contracts and a register built from what actually runs in production.