DORA: Digital operational resilience in the financial sector

Since 17 January 2025, EU Regulation 2022/2554 — the Digital Operational Resilience Act — applies. DORA obliges financial institutions to secure their entire ICT landscape against cyber risks. This expressly includes open source components: Art. 25(1) DORA names "open source analyses" as a mandatory test.

For boards and managing directors, this means: you bear ultimate personal responsibility for ICT risk management (Art. 5(2a)). This responsibility cannot be delegated — and D&O insurance typically does not cover legal violations.

Who is affected? #

DORA covers 21 categories of undertakings, grouped into six clusters (Art. 2(1)):

Banks and payment services #

Credit institutions (lit. a)
Payment institutions (lit. b)
Account information service providers (lit. c)
Electronic money institutions (lit. d)

Capital markets and securities trading #

Investment firms (lit. e)
Crypto-asset service providers and token issuers (lit. f)
Trading venues (lit. i)
Data reporting service providers (lit. m)

Funds and asset management #

Managers of alternative investment funds (lit. k)
Management companies (lit. l)

Insurance and pensions #

Insurance and reinsurance undertakings (lit. n)
Insurance intermediaries (lit. o)
Institutions for occupational retirement provision (lit. p)

Financial infrastructure and specialist providers #

Central securities depositories (lit. g)
Central counterparties (lit. h)
Trade repositories (lit. j)
Credit rating agencies (lit. q)
Benchmark administrators (lit. r)
Crowdfunding service providers (lit. s)
Securitisation repositories (lit. t)

ICT third-party service providers — indirectly affected #

All IT, software, cloud, and open source suppliers (lit. u). If you provide software or infrastructure to financial institutions, the DORA supply chain requirements affect you directly. Your clients in the financial sector will contractually require compliance with security standards — or must do so (Art. 28(5)).

What does DORA require? #

ICT risk management under board responsibility #

The management body bears ultimate responsibility for managing ICT risks (Art. 5(2a)). It must actively maintain sufficient knowledge and skills (Art. 5(4)) and establish a comprehensive ICT risk management framework (Art. 6(1)) that takes international standards into account (Art. 6(2)).

Complete ICT asset inventory #

You must maintain an inventory of all ICT assets, including configuration and interdependencies (Art. 8(4)). This includes identifying all processes dependent on ICT third-party service providers (Art. 8(5)), regular updates upon any material change (Art. 8(6)), and assessment of ICT legacy systems at least annually (Art. 8(7)). For open source dependencies, this means: a complete, up-to-date SBOM.

Vulnerability management #

DORA requires mechanisms to identify potential material vulnerabilities (Art. 10(1)), capacities and personnel for vulnerability intelligence (Art. 13(1)), documented policies for patches and updates (Art. 9(4f)), and communication plans for the responsible disclosure of vulnerabilities (Art. 14(1)).

Mandatory open source analyses and source code reviews #

Art. 25(1) expressly names as testing methods: open source analyses, source code reviews (where practicable), vulnerability assessments and scans, and penetration tests. All critical systems must be tested at least annually (Art. 24(6)). Before deploying and redeploying components, a vulnerability assessment must be conducted (Art. 25(2)). Every three years, threat-led penetration tests (TLPT) are required, which must also involve ICT third-party service providers (Art. 26).

Management of ICT third-party risks #

Financial institutions remain fully responsible at all times for compliance with ICT requirements — even when outsourcing functions to third parties (Art. 28(1)). The management body must regularly review the strategy for ICT third-party risks (Art. 28(2)). An information register of all ICT third-party arrangements must be maintained (Art. 28(3)). A due diligence obligation applies before concluding contracts with ICT third-party service providers (Art. 28(4)). For critical functions, the highest quality standards are required (Art. 28(5)). Exit strategies must be in place for all ICT third-party service providers (Art. 28(8)).

Reporting obligations #

For severe ICT-related incidents: initial report within 4 hours (Art. 19(4a)) and intermediate report within 72 hours (Art. 19(4b)). These deadlines apply on weekends and public holidays as well.

Consequences of non-compliance #

Personal management liability #

The management body bears ultimate responsibility (Art. 5(2a))
Administrative sanctions can be imposed on members of the management body (Art. 50(5))
Continuing education obligation: knowledge must be actively kept up to date (Art. 5(4))
D&O insurance typically does not cover legal violations

Fines #

For financial institutions, DORA does not specify concrete percentages — the detailed rules are left to the member states (Art. 50(3-4)). Art. 50 expressly permits "any type of measure, including of a financial nature". For critical ICT third-party service providers: 1% of worldwide daily turnover as a periodic penalty payment, daily, for up to six months (Art. 35(8)).

Public visibility #

All sanction decisions are published on the websites of the supervisory authorities — for up to five years (Art. 54(1-2), (6)). Periodic penalty payments against ICT third-party service providers are also published (Art. 35(10)). In addition, the inherently public nature of open source means CVEs, issues, commits, and open bugs are visible to everyone — to auditors and attackers alike.

Further consequences #

Member states may provide for criminal sanctions (Art. 52)

What OTTRIA covers #

DORA obligation	OTTRIA service
ICT asset inventory (Art. 8(4-7))	SBOM evaluation and ongoing monitoring of all open source dependencies
Vulnerability detection (Art. 10(1))	CVE scanning and silent fix detection for all SBOM components
Vulnerability intelligence (Art. 13(1))	Ongoing monitoring, early warnings through steward involvement
Open source analyses (Art. 25(1))	Systematic analysis of all OSS dependencies, source code reviews
Vulnerability assessment before deployment (Art. 25(2))	Risk assessment per component before integration
Patch management (Art. 9(4f))	Coordinate upstream fixes or create them ourselves, including for abandoned projects
Responsible disclosure (Art. 14(1))	Disclosure management as part of the steward role
Due diligence for third-party providers (Art. 28(4))	Documented assessment of OSS projects as "suppliers"
Exit strategies (Art. 28(8))	Assessment of alternative projects, forks, mirrors

What OTTRIA does not cover #

Your decisions: OTTRIA delivers risk assessments and options for action. The decision on which risk you accept is yours.
Your systems: OTTRIA works exclusively in the open source world. We have no access to your systems — this is a deliberate security decision.
Your overall responsibility: Regulatory responsibility remains with the financial institution (Art. 28(1)). OTTRIA reduces your risk and provides evidence, but does not assume your legal obligation.
Non-OSS components: Other service providers are responsible for proprietary software and other ICT third-party risks. OTTRIA focuses exclusively on open source components.
Resolution time guarantees: How long a fix takes in an open source project cannot be predicted. We respond as quickly as possible and document every step.

What do you present to the auditor? #

OTTRIA delivers #

Risk documentation per open source component with criticality assessment
Remediation history: what was done when, by whom, with what result
Closure reports per security incident
SBOM with maintenance status and abandonment probability
Supply chain vitality report
Documented open source analyses in accordance with Art. 25(1)

You add #

Your decision per risk (acceptance, mitigation, avoidance)
The implementation status in your system
The integration into your ICT risk management framework under Art. 6
Your information register of ICT third-party arrangements under Art. 28(3)

Together, this forms an audit-ready evidence package that your supervisory authority expects.

Implementation in Germany #

BaFin as supervisory authority #

In Germany, the Federal Financial Supervisory Authority (BaFin) oversees compliance with DORA. BaFin builds on existing regulation: MaRisk (Minimum Requirements for Risk Management) and BAIT (Supervisory Requirements for IT in Financial Institutions) are not replaced by DORA but supplemented. Companies already implementing MaRisk and BAIT have a foundation — but must additionally meet DORA-specific requirements, particularly regarding open source analyses (Art. 25(1)) and management of ICT third-party risks (Art. 28).

DORA and NIS2 #

DORA-regulated companies are exempt from the German NIS2 transposition (NIS2UmsuCG) (Section 28(6) NIS2UmsuCG). DORA takes precedence as sector-specific regulation.

National implementation #

Since DORA is an EU Regulation, it applies directly in all member states. The national implementation primarily concerns the sanction regimes (Art. 50(3-4)) and the specific supervisory practice. In other EU countries, different supervisory structures and sanction levels may apply.

Want to know how your open source dependencies stand under DORA? Request a free DORA initial analysis of your SBOM.

Schedule an appointment

Download DORA factsheet (PDF)