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" expressly as a test method.

For boards and managing directors, this means: you bear ultimate personal responsibility for ICT risk management (Art. 5(2a)). This responsibility cannot be delegated — DORA even requires you explicitly to keep your knowledge current, to understand the risks and to oversee the measures. Anyone who knowingly disregards established security duties risks personal liability and their D&O cover. OTTRIA secures your open source dependencies and documents every measure so that you can evidence your diligence to supervisors, auditors and insurers.

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)) comprising, among other things, strategies, policies, procedures and tools (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, you cannot maintain this inventory.

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)).

A binding security testing programme, open source included #

DORA obliges you to run an appropriate security testing programme. Art. 25(1) names open source analyses, source code reviews (where practicable), vulnerability assessments and scans, and penetration tests expressly among its methods. How deeply you apply them follows from your size, business activities and risk profile.

There is a fixed cadence behind this: every financial entity other than a microenterprise must test all ICT systems and applications supporting critical or important functions appropriately at least once a year (Art. 24(6)). If the supervisor selects your institution for threat-led penetration testing (TLPT), those are added at least every three years and involve your ICT third-party service providers (Art. 26).

Central securities depositories and central counterparties additionally screen every application, infrastructure component and ICT service supporting critical or important functions for vulnerabilities before each deployment and redeployment (Art. 25(2)).

For your open source components this means: the annual test has to cover them, and the result has to be documented in an auditable form. OTTRIA handles that part for you.

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)). Where a contract covers critical or important functions, the financial entity must consider whether the provider applies the latest and highest information security quality standards (Art. 28(5)). Exit strategies must be in place for ICT services supporting critical or important functions (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: a knowing breach of duty is normally excluded from cover - check your policy before you rely on it

Fines #

DORA breaches can cost your institution millions. In Germany, banks face fines of up to EUR 5 million for certain breaches — for example missing, incorrect or late incident reports, or the required threat-led penetration testing (TLPT). Further breaches listed there carry a ceiling of EUR 500,000 (Section 56(5e) and (6) KWG). On top of that come supervisory measures to remedy the deficiencies (Art. 50(2-4) DORA). For other financial entities, the ranges follow from the relevant national supervisory legislation.

Public visibility #

Sanction decisions that can no longer be appealed are published on the websites of the supervisory authorities as a matter of principle — only for as long as necessary, and for no more than five years (Art. 54(1-2), (6)). Anonymised or deferred publication is provided for only in exceptional cases; do not plan around it. 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
Annual testing of critical systems (Art. 24(6))	Auditable test evidence for every open source component
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 #

For the financial entities named in Section 28(6) BSIG, DORA takes precedence for certain duties: Sections 30, 31, 32, 35, 36, 38 and 39 BSIG are disapplied — not the entire act. Treat DORA and the BSIG as one programme. Meeting your DORA obligations properly covers the disapplied part; everything else remains a free-standing BSIG duty that you have to evidence.

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)