EU DORA Compliance for Financial Firms Using Open Source Infrastructure

DORA and Its Scope

The EU Digital Operational Resilience Act (DORA), which became applicable in January 2025, establishes a comprehensive framework for ICT risk management in the financial sector. DORA applies to a broad range of entities: credit institutions, investment firms, payment institutions, insurance undertakings, and — critically — ICT third-party service providers that supply services to regulated entities. If you are a fintech company, a SaaS platform serving financial institutions, or a financial services firm operating in the EU, DORA applies to your ICT infrastructure — including your open source stack.

The ICT Risk Management Framework (Articles 5–14)

DORA's core requirement is a comprehensive ICT risk management framework that identifies, classifies, and manages ICT risks. Articles 5 through 14 establish specific obligations around ICT risk identification, protection, detection, response, recovery, and learning. For open source infrastructure, the most directly applicable obligations are:

Article 8: Identification of ICT Risks

Financial entities must identify, classify, and document all functions, assets, and ICT third-party service providers that support their operations. For open source components, this means maintaining an accurate inventory of all OSS runtimes, their versions, their EOL status, and the business functions they support. An EOL RabbitMQ cluster handling payment message routing is an ICT asset that must appear in the risk identification documentation with its lifecycle status clearly noted.

Article 9: Protection and Prevention

Article 9 requires that financial entities have in place ICT security policies, procedures, protocols, and tools necessary to protect all relevant ICT assets. Known unpatched CVEs in production ICT assets are a direct finding against this article. The control response — whether third-party patching, compensating controls, or formal risk acceptance — must be documented and defensible.

Article 10: Detection

Detection mechanisms for ICT anomalies and events must be in place, including vulnerability scanning. For open source components, this translates to continuous CVE monitoring with defined alert thresholds. The detection control must be able to surface CVEs against EOL components even when upstream patch notifications are no longer being issued — which requires monitoring that goes beyond subscribing to upstream security advisories.

Third-Party ICT Risk (Articles 28–44)

DORA introduces detailed requirements for managing ICT third-party risk. These requirements apply not only to commercial ICT service providers but, in the spirit of the regulation, to the governance of open source projects used as infrastructure components. While DORA does not directly regulate open source projects, it requires financial entities to assess the resilience and security posture of their critical ICT dependencies — and an EOL open source component is, by definition, one where the supplier (the upstream community) has ceased support activity.

In practice, DORA supervisors have asked financial firms to document: the concentration of their critical infrastructure on specific open source projects, their monitoring for EOL events in those projects, and their plans for managing components that have reached or are approaching EOL.

Operational Resilience Testing (Articles 24–27)

DORA requires threat-led penetration testing (TLPT) for significant financial entities. EOL components with known unpatched CVEs are high-value targets for TLPT scenarios. If an EOL component is in scope for TLPT and a tester exploits a known unpatched CVE to demonstrate impact, the finding must be remediated — which for EOL components means either upgrading or obtaining extended lifecycle patching.

OSSeva's DORA Compliance Documentation

OSSeva's compliance evidence package for DORA-regulated customers includes: ICT asset inventory documentation for covered OSS components, CVE monitoring reports structured for Article 10 detection evidence, patch delivery records for Articles 9 and 10 protection evidence, and risk assessment documentation for EOL components that satisfies Article 8 identification requirements.

Conclusion

DORA is not a conceptual framework — it is an enforceable regulation with supervisory authority. For EU-regulated financial entities, EOL open source infrastructure is an ICT risk that must be identified, documented, managed, and evidenced. Extended lifecycle support with compliance documentation is the most direct path to satisfying DORA's risk management framework for infrastructure that cannot be immediately migrated.