What is DORA?

The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) is an EU Regulation that has applied to the entire financial sector since January 2025. The objective: financial undertakings must systematically ensure their digital operational resilience — not just on paper but in an operationally demonstrable manner.

Who does DORA affect? #

DORA applies to 21 categories of financial undertakings (Art. 2(1)), including:

Banks and payment service providers
Investment firms and trading venues
Insurance and reinsurance undertakings
Fund managers and management companies
Crypto-asset service providers and credit rating agencies
Institutions for occupational retirement provision

Additionally affected: ICT third-party service providers — i.e. all IT, cloud, and software suppliers working for financial undertakings.

What does DORA specifically require? #

DORA demands comprehensive ICT risk management. For open source components, the following are particularly relevant:

Ultimate responsibility of the management body for ICT risk management (Art. 5(2a))
Inventory of all ICT assets including dependencies (Art. 8(4-6))
Vulnerability detection and remediation with documented processes (Art. 10, Art. 13)
Open source analyses expressly named as a test method (Art. 25(1))
Source code reviews, where feasible (Art. 25(1))
Strategy for ICT third-party risk, regularly reviewed by the management body (Art. 28(2))
Annual tests of the systems supporting critical or important functions, except for microenterprises (Art. 24(6))

For severe incidents, a first notification deadline of 4 hours applies (Art. 19(4a)).

What are the consequences of non-compliance? #

Fines against your institution: for banks in Germany up to EUR 5 million for certain breaches of incident reporting and TLPT duties; up to EUR 500,000 for further breaches expressly listed there (Section 56(5e) and (6) KWG). For other financial entities, the relevant national supervisory legislation applies.
Supervisory intervention: the authority can require deficiencies to be remedied and unlawful practices to cease (Art. 50(2-4)).
Personal liability of management: The management body bears ultimate responsibility (Art. 5(2a)) and can be personally sanctioned (Art. 50(5))
Training obligation: The management body must actively keep its knowledge up to date (Art. 5(4))
Public visibility: Final sanction decisions are published on authority websites as a matter of principle — only for as long as necessary, and for no more than 5 years. Anonymised or deferred publication is provided for only in exceptional cases (Art. 54(1-2), para. 6)
No backstop from the policy: D&O insurance does not respond where a duty was knowingly breached

Implementation in Germany #

DORA is an EU Regulation and applies directly in all Member States — no national transposition is required. In Germany, BaFin is the competent supervisory authority. DORA supplements existing regulation through MaRisk and BAIT and tightens the requirements for ICT risk management and third-party oversight in particular. Financial undertakings already subject to DORA and named in § 28(6) BSIG are exempt from certain BSIG obligations — not from the entire act. Anyone caught by both regimes is better off planning them together. Other EU countries have different supervisory structures.

What does this mean for you? #

If you manage a financial undertaking or provide IT services for the financial sector, you are obliged to know, monitor, and document your entire software supply chain. Open source components in your SBOM are no exception — they are an explicit subject of examination. Responsibility for this cannot be delegated: it lies personally with the management body.

Important: The supply chain does not only include components that end up in your final product. Development dependencies — compilers, build tools, test frameworks, CI/CD pipelines — also fall under the obligations. Art. 25(1) expressly names open source analyses as a test method, Art. 8(4-6) requires the inventory of all ICT assets including dependencies. A compromised build tool can inject malicious code into your final product without a single runtime dependency being affected.