DORA (Regulation (EU) 2022/2554) requires EU financial entities to manage ICT risk under Article 6 and ICT third-party risk under Articles 28 and 30. Open-source dependencies are ICT assets like any other: they belong in your asset register, need a documented vulnerability-management process, and — where a provider supplies the software — need coverage in that provider's contractual security terms.
DORA's text mentions "hardware," "software," and "ICT third-party service providers" repeatedly, but it never says "open-source dependency" or "SBOM." That silence causes real confusion for engineering teams at EU financial entities trying to work out whether their npm, PyPI, or Maven dependencies actually fall under the regulation's ICT risk-management duties — they do, and this piece maps exactly where.
Accuracy note: every article number and requirement below is cross-checked against Regulation (EU) 2022/2554 (DORA) on EUR-Lex. DORA applies alongside sector-specific financial regulation and each competent authority's own supervisory guidance, which can add detail this article doesn't cover. Verify against the current regulation text and your regulator's guidance before making compliance decisions — this is not legal advice.
Who DORA Covers, and Where Dependencies Fit
DORA applies to a broad list of EU financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more — plus, critically, the ICT third-party service providers those entities rely on, regardless of where those providers are headquartered. Article 6 requires every in-scope financial entity to maintain a documented ICT risk-management framework covering all the ICT systems, protocols, and tools it depends on to run its business, including the software components running inside those systems, not merely the systems' external interfaces.
An open-source library isn't a "third party" in the contractual sense — nobody signs a services agreement with the maintainers of a widely-used npm package. But it is unambiguously an ICT asset under Article 6's risk-management scope: code your systems execute, with its own vulnerability surface, that has to appear in your ICT asset inventory the same way a licensed commercial component would. A typical financial-services application can easily carry hundreds of transitive open-source packages beneath the handful its developers chose directly, and Sonatype's State of the Software Supply Chain research finds roughly 6 out of every 7 known open-source vulnerabilities sitting in exactly that transitive layer — the layer an inventory built only from direct dependencies would miss entirely. The European Supervisory Authorities' DORA guidance is explicit that ICT risk management covers the full technology stack a financial entity operates on, not only vendor-contracted systems.
Where open-source software arrives through a third-party ICT provider — a SaaS platform your bank uses that itself bundles open-source components — Article 28's third-party risk provisions apply on top, because now there's a contractual relationship whose security terms need to account for what's inside the product you're buying.
ICT Risk Management vs. Third-Party Risk: Two Different Articles, One Shared Evidence Base
Article 6 governs how a financial entity manages risk in the ICT systems it operates directly; Articles 28 and 30 govern how it manages risk introduced by ICT third-party service providers, including a register of contractual arrangements and mandatory security terms in those contracts. For open-source dependencies, both articles end up pointing at the same underlying evidence: what's actually running, is it currently vulnerable, and what happens when it is.
Article 28's "register of information" requirement is the piece engineering teams most often miss. It requires financial entities to maintain and keep current a register covering all contractual arrangements with ICT third-party providers — and where a vendor's product embeds open-source components material to your risk exposure, that dependency data becomes part of the due diligence supporting the register, not a separate concern you can skip because "it's open source, not a vendor." DORA's Regulatory Technical Standards on the register of information specify the register's structure in detail.
Article 30 then requires the contracts underlying that register to include specific provisions: service levels, data location and protection terms, and — most relevant here — the provider's obligations around vulnerability management, incident notification, and business continuity. A vendor contract that's silent on how the vendor patches its dependencies is a gap Article 30 is designed to close.
Where Open-Source Dependencies Sit in the ICT Risk Picture
Practically, an open-source dependency shows up in DORA compliance in three places: your own ICT asset inventory (Article 6), your due-diligence record if it arrives through a third-party product (Article 28), and your incident-response evidence if a dependency vulnerability ever triggers DORA's major-incident reporting obligations. None of these require treating each of the hundreds of transitive packages in a typical application as an individually contracted vendor — they require you to be able to show what's running and how you're managing its risk.
A software bill of materials is the artifact that makes the Article 6 inventory obligation tractable at the scale modern applications operate at — a typical service can easily carry hundreds of transitive dependencies, and an SBOM generated directly from your lockfile is the only realistic way to keep that inventory both complete and current as dependencies update. GeekWala's free SBOM generator produces one in CycloneDX or SPDX format without requiring a manual audit.
A Practical Scanning Baseline
A defensible DORA ICT-risk baseline for open-source dependencies has four parts: a current inventory, continuous vulnerability scanning, exploitability-informed triage, and an incident-reporting trigger — a GeekWala dependency scan covers the scanning and exploitability-triage stages from your manifest or lockfile, while the incident-reporting threshold is a policy you define yourself. Each part maps to a concrete, auditable artifact:
- Inventory — a current SBOM for every production system, regenerated on every dependency change, not a point-in-time snapshot from last year's audit.
- Continuous scanning — automated vulnerability scanning against the SBOM on a defined cadence (ideally every build), covering both direct and transitive dependencies, since the transitive layer is where most known open-source vulnerabilities actually accumulate.
- Exploitability-informed triage — prioritizing findings using EPSS exploit-probability scoring and the CISA Known Exploited Vulnerabilities catalog. Triage matters because most findings never need urgent action: the FIRST EPSS research team puts the historical share of published CVEs that are ever actually exploited at roughly 5.5-6.4%, and CISA's own KEV catalog — the strictest confirmed-exploitation floor — lists only around 1,700 entries against 355,000+ published CVEs. A documented service-level target for how quickly a KEV-listed dependency gets remediated turns that prioritization into an auditable control rather than a judgment call made differently each time.
- Incident-reporting readiness — a defined internal threshold for when a dependency vulnerability, or its exploitation, escalates to DORA's major ICT-related incident reporting process, so the decision isn't improvised during an active incident.
This baseline doubles as evidence for a related regime: see our NIS2 supply-chain security requirements guide, since a financial entity that is also an NIS2 "essential" or "important" entity (several financial-market-infrastructure categories are) can largely reuse the same inventory-scan-triage-report evidence chain for both regulations.
Frequently Asked Questions
Does DORA apply to a financial entity's internal engineering team, or only to procurement?
Both. Article 6's ICT risk-management framework is an entity-wide obligation that includes internally built and internally operated systems, not just externally procured ones. An engineering team building software in-house at an EU bank is directly implementing Article 6 obligations when it inventories and patches its own dependencies — this isn't solely a procurement or vendor-management function.
Is an open-source maintainer an "ICT third-party service provider" under DORA?
No. DORA's third-party provisions (Articles 28-30) are built around contractual relationships with providers who supply ICT services under an agreement. Most open-source projects have no such contract with their users. The dependency itself is still in scope under Article 6 as part of your own ICT risk management — it's just not subject to the Article 30 contractual-terms requirements unless it arrives bundled inside a contracted vendor's product.
What counts as a "major ICT-related incident" for a dependency vulnerability under DORA?
DORA sets criteria for major-incident classification based on factors like the number of clients or transactions affected, duration, and data loss — not simply "a CVE was found." A vulnerability's presence alone doesn't trigger reporting; its exploitation, if it meets the severity and impact thresholds a financial entity's own DORA incident-classification policy defines, does. Check your national competent authority's incident-reporting guidance for the exact thresholds and templates in force.
When did DORA become applicable?
DORA (Regulation (EU) 2022/2554) applies from January 17, 2025, giving in-scope financial entities and their ICT third-party providers a transition period from the regulation's 2023 entry into force to build the required frameworks. Regulatory Technical Standards under DORA, including the register-of-information format, have been published and refined since — check the current EUR-Lex text and your competent authority's guidance for the latest requirements.
