Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- DORA’s register of information lists contracts for technology services provided on an ongoing basis, so a library you download with no contract usually isn’t in it.
- Binding technical standards require tracking open source libraries used by services that support critical or important functions.
- Software within a financial entity’s systems falls under risk management rules, whether or not a vendor contract is in place.
DORA compliance requirements reach open source libraries even when your register of information doesn’t list them. The EU’s Digital Operational Resilience Act (DORA) names them in its technical standards on information and communication technology (ICT) risk management, which sit apart from the vendor contract rules.
The register of information is the list a financial entity keeps of its contracts for ongoing ICT services. Whether a library lands in it depends on whether a contract, such as one for paid support, sits behind it. The risk management rules reach the library either way, as long as it runs in your systems. So it belongs in the inventory of software you use, even when the register leaves it out. A library missing from that inventory is a gap in a record that DORA requires. Supervisors can order you to fix it, and each Member State sets penalties for DORA breaches. Authorities publish final penalty decisions.
Which Organizations Do DORA Compliance Requirements Apply to?
DORA applies to twenty categories of financial entities, among them credit institutions, payment and electronic money institutions, investment firms, insurers, crypto-asset service providers, central counterparties, and trading venues. ICT third-party service providers, companies that supply technology services to those entities, are listed separately and come under direct EU oversight only if they’re designated as critical.
Some entities are out of scope, including certain smaller alternative investment fund managers and insurers, pension institutions with up to 15 members, and post office giro institutions (postal banks that run payment accounts). Member States can also exclude certain entities that the EU banking directive exempts from its own rules.
Small and non-interconnected investment firms, exempted payment and electronic money institutions, small pension institutions (fewer than 100 members), and the exempted banking-directive institutions that Member States keep in scope get a simplified ICT risk management framework with separate rules in the technical standards. If that’s you, start there. Everyone else follows the full framework, scaled to size and risk profile, and so does the rest of this article.
The Register Is Built Around Contracts
DORA’s main text is Regulation (EU) 2022/2554, referred to as the Regulation from here on. Article 3 of the Regulation defines an ICT third-party service provider as an undertaking providing ICT services, and ICT services as digital and data services provided through ICT systems on an ongoing basis. The register, the contract terms, and the exit rules all attach to a provider delivering that kind of service.
Under Article 28(3), you maintain a register of information on all contractual arrangements for those services, separating the ones that support critical or important functions from the rest. Critical or important functions are those whose disruption would materially harm the entity’s finances, its services, or its ability to meet the conditions of its authorization. At least once a year, you report your new contracts to your competent authority, including who provides them and which services and functions they cover. You also hand over the full register on request. The register’s standard templates come from Commission Implementing Regulation 2024/2956.
Article 30 sets minimum contract terms, and Article 28(8) requires exit strategies for services that support critical or important functions. Where a contract for such a service allows subcontracting, Article 29 requires you to weigh the risks, including those of long or complex chains. A regulatory technical standard (RTS), Commission Delegated Regulation 2025/532, specifies the elements you determine and assess when those services are subcontracted. The register’s templates also record each subcontractor that effectively underpins such a service.
Note: The European Supervisory Authorities (ESAs) publish a staff FAQ on reporting the register, hosted on the European Banking Authority (EBA) site. It says a one-time purchase of a static solution, with no ongoing maintenance, support, or updates, isn’t an ICT service. It’s staff guidance, not the ESAs’ official position.
Critical providers fall under a separate oversight regime run by the ESAs: the EBA, the European Insurance and Occupational Pensions Authority, and the European Securities and Markets Authority. They published the first list of designated critical ICT third-party service providers on 18 November 2025 and must update it yearly. The designation applies to undertakings that provide ICT services, so an open source library itself isn’t a candidate. A library you download with no contract falls outside the register, the contract rules, and critical-provider oversight because no provider delivers it to you as an ongoing service. But it still falls under DORA’s ICT risk management rules, which treat it as software the entity uses.
Where Open Source Libraries Show Up in the Rulebook
The DORA compliance requirements that name open source software sit in the ICT risk management standards. The Regulation defines an ICT asset as a software or hardware asset in the network and information systems used by the entity. Article 6 requires protection of ICT assets, including computer software, and Article 8 requires you to identify, classify, and document them, map their interdependencies, and keep inventories.
The table lists the binding requirements with the most direct bearing on libraries. In it, “RTS 2024/1774” means Commission Delegated Regulation 2024/1774, the RTS on ICT risk management.
| Topic | What it requires | Source |
|---|---|---|
| ICT asset inventory | Identify, classify, and document software assets and their interdependencies, and keep inventories up to date | Regulation, Article 8 |
| Library tracking | Track third-party and open source libraries used by services that support critical or important functions, and monitor their versions and updates, with the provider where appropriate | RTS 2024/1774, Article 10 |
| Pre-production testing | Analyze and test open source code, where feasible, before it reaches production, and security-test software packages no later than the integration phase | RTS 2024/1774, Article 16 |
| Malicious code | Set security measures against malicious code and make sure only authorized software is installed | RTS 2024/1774, Article 11 |
| Patch policies | Keep documented policies for patches and updates, with deadlines and escalation when they’re missed | Regulation, Article 9; RTS 2024/1774, Article 10 |
| Legacy systems | Run a specific risk assessment on legacy ICT systems at least yearly | Regulation, Articles 3 and 8 |
From the Regulation: Article 25(1) lists “open source analyses” as one example of appropriate tests in a financial entity’s resilience testing program, alongside vulnerability scans, source code reviews where feasible, and penetration testing.
For off-the-shelf components used in services that don’t support critical or important functions, RTS 2024/1774 Article 10 still requires you to track the third-party and open source libraries they use, to the extent possible.
The Regulation defines a legacy ICT system as one that’s still in use and supports the entity’s functions but has reached end of life, isn’t suitable for upgrades or fixes for technological or commercial reasons, or is no longer supported by its supplier or an ICT third-party service provider. That definition covers whole ICT systems. Each entity has to decide and record whether an unsupported library makes the system that runs it a legacy system. Microenterprises, meaning smaller financial entities with fewer than 10 staff and a turnover or balance sheet total of up to EUR 2 million, are exempt from the annual legacy review.
Whether a Library Is in the Register Depends on How It Reaches You
Every library that runs in your systems counts as software the entity uses, so the risk management rules apply to it. Whether the third-party rules and the register also apply depends on whether the library reaches you through an ICT service.
What counts as an ICT service is the entity’s call. Q&A 2999, an answer from the European Commission published through the ESAs, calls the definition intentionally broad and leaves the assessment to the financial entity. For a library, that means you decide whether a support or distribution arrangement counts as an ICT service and belongs in the register.
| How the library arrives | ICT asset | In the register of information | Basis |
|---|---|---|---|
| Public registry download, no support arrangement | Yes, as software the entity uses | Typically not, since no contract for an ongoing service exists | Regulation, Articles 3 and 28; staff FAQ (guidance) |
| Commercial distribution or support arrangement | Yes | Yes, if the entity assesses it as an ongoing ICT service | Regulation, Articles 3 and 28; Q&A 2999 (guidance) |
| Embedded in a vendor’s product or hosted service | Yes, if it runs in the network and information systems used by the financial entity | The vendor’s arrangement, plus subcontractors that effectively underpin services supporting critical or important functions | Regulation, Articles 28 and 29; Implementing Regulation 2024/2956, Article 3 |
When a library is embedded in a vendor’s product or hosted service, the vendor that ships it usually fits the description of an undertaking providing ICT services, and the library’s maintainer rarely does. The contract rules then apply to the vendor, but a library that runs in the systems you use remains under your risk management rules.
A Short Checklist for the Libraries in Your Critical Functions
Each item in this DORA compliance checklist cites the binding text behind it and assumes you’re under the full framework.
- Inventory. Your inventory covers the software that supports critical or important functions and how it interconnects (Regulation, Article 8).
- Tracking. You track third-party and open source libraries used by services that support those functions, and you monitor their versions and updates, with the provider where appropriate (RTS 2024/1774, Article 10).
- Testing. Open source code is analyzed and tested before production where feasible, and software packages undergo security testing no later than the integration phase (RTS 2024/1774, Article 16).
- Malicious code. Your security procedures include measures against malicious code and allow only authorized software onto your systems (RTS 2024/1774, Article 11).
- Patching. A documented patch and update policy sets deadlines and escalation steps (Regulation, Article 9; RTS 2024/1774, Article 10). Where the only fix is a newer version, upgrading can bring breaking changes of its own, as we explain in why “just upgrade it” is poor security advice.
- Legacy systems. Legacy ICT systems get a specific risk assessment at least yearly, unless you’re a microenterprise (Regulation, Article 8).
- Register. Your register of information lists every contractual arrangement for ICT services, including software arrangements that qualify as ongoing services, and you can say why a given library isn’t in it (Regulation, Article 28).
- Roles. The management body sets clear roles for ICT-related functions and how they coordinate (Regulation, Article 5). Unless you’re a microenterprise, a control function manages and oversees ICT risk, including library risk (Regulation, Article 6). The rules don’t specify which team is responsible for library tracking, so decide whether your ICT risk team or third-party risk team handles it.
Start With One Critical Function
Your register won’t show libraries you downloaded without a contract, so find them in your own systems. Pick one critical or important function and list the libraries underneath it, including the ones pulled in indirectly. Flag any library with no active upstream maintainer or no upstream fix for your version. Then choose a route for each, whether that’s replacing it, upgrading to a fixed release if one exists, or patching the version you run. One function is enough to produce a concrete list of findings and a way to size the rest of your software.
If you take the patching route, SecureChain is one place to look. It scans each open source package’s source code for known malware and suspicious code patterns before the package reaches you, then rebuilds the package from that same source. It fixes newly published CVEs in those packages under the SLA. Each package comes with an SBOM for your inventory and VEX data on which CVEs affect your version. Its SLSA Level 3 provenance shows it was rebuilt from the scanned source. When upstream maintainers stop shipping security fixes, Endless Lifecycle Support (ELS) automatically takes over those packages. SecureChain and ELS are available for JavaScript, Python, Java, Go, and PHP ecosystems.
FAQ
What Is DORA Compliance?
DORA compliance means a financial entity complies with the EU’s Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, and its technical standards. The goal is to keep services running through technology disruptions. The rules have been in effect since 17 January 2025.
What Are the DORA Compliance Requirements?
DORA, the EU’s Digital Operational Resilience Act, covers five areas. These are information and communication technology (ICT) risk management, major ICT incident reporting, resilience testing, ICT third-party risk management, and cyber threat information sharing. Technical standards add detail to many of them.
Who Has to Meet DORA Compliance Requirements?
The Digital Operational Resilience Act (DORA) covers twenty categories of financial entities, including credit institutions, payment institutions, investment firms, insurers, and trading venues. Some entities are excluded, and certain small ones follow a simplified risk management framework. Technology service providers are subject to direct oversight only if designated as critical.
Are Open Source Libraries in the DORA Register of Information?
The Digital Operational Resilience Act (DORA) register of information lists contracts for information and communication technology (ICT) services provided on an ongoing basis. A library from a public registry usually has no such contract, so it isn’t listed. Paid support can change that. Either way, the risk management rules still apply to the library as software used by the entity.
Does DORA Mention Open Source Software?
Yes. A technical standard under the Digital Operational Resilience Act (DORA), Commission Delegated Regulation (EU) 2024/1774, requires financial entities to track the open source libraries used by information and communication technology (ICT) services that support critical or important functions. It also requires testing open source code before production, where feasible.
What Are the Penalties for DORA Non-Compliance?
The Digital Operational Resilience Act (DORA) leaves penalty levels for financial entities to each Member State, which must make them effective, proportionate, and dissuasive. Competent authorities can order an entity to stop a breach and take remedial measures, and they publish final penalty decisions. Critical technology providers face a separate EU-level penalty of up to 1% of their average daily worldwide turnover, charged daily for up to six months.
Who Owns Dependency Risk Under DORA?
The Digital Operational Resilience Act (DORA) requires every financial entity, except a microenterprise, to give a control function responsibility for managing and overseeing information and communication technology (ICT) risk. It doesn’t say which team tracks libraries. The management body sets that role, so each entity decides whether its ICT risk or third-party risk team does the tracking.
