DORA and open-source or self-hosted software

A free licence on its own is not, in itself, the service. DORA defines ICT services as digital and data services provided through ICT systems to users on an ongoing basis. The ESAs' register FAQ states that only ICT services provided on an ongoing basis are in scope, and a single static solution without ongoing maintenance, support or updates is not considered. The Commission's answer on the definition says the definition is intentionally broad and that financial entities must assess for themselves whether the services they rely on fall within it. The question that matters is therefore whether anyone provides an ongoing service around the software, such as hosted operation, maintenance, updates or support. If nobody does, the software is generally outside the register, but the entity still owns the risk of running it.

Paid support does not automatically make the software an ICT service, but it is a strong signal that an ongoing service exists. The test is whether the supplier provides something on an ongoing basis, such as maintenance, security updates, patch delivery, incident assistance or hosted operation. A one-off purchase of a static package with no continuing obligations is treated differently. Check the support contract itself: look for recurring deliverables, service levels, update commitments and named support channels. If any of these apply, record the supplier as an ICT third-party service provider and assess the arrangement under the third-party rules. Ask counsel or your competent authority to confirm the classification in writing where the contract is ambiguous.

Generally no, if the software is a single static solution with no ongoing maintenance, support or updates, because the ESAs' FAQ excludes it from the register. However, a static deployment still needs to be governed. It usually belongs in the ICT asset inventory, it must be covered by your ICT risk management framework, and its vulnerabilities must be tracked. If you later sign a support or update agreement, or the software moves into a hosted model, the classification may change and the register entry must follow. Re-check the classification at each contract change and at each annual review, and keep a dated record of the reasoning so an assessor can see how you reached the decision.

The effort depends on the number of libraries, how often they change, and how critical the supported function is. Delegated Regulation (EU) 2024/1774 requires entities to track third-party and open-source libraries used by ICT services that support critical or important functions, and to analyse third-party and open-source code before it reaches production. Effort rises with:

• the count of direct and transitive dependencies in each build
• the release cadence of upstream projects and the number of security advisories
• the criticality of the function the software supports
• whether builds are automated, which allows scanning in the pipeline rather than by hand

The main one-time costs are setting up the inventory, scanning and review workflow. Recurring costs are triage of new findings and periodic review. Ask any provider to quote these separately, and ask what the quote assumes about dependency counts and update frequency.

Often yes, provided the team has the skills and time to run the work continuously. The obligations are operational rather than exotic: maintain a current software bill of materials, run dependency and code analysis tools, triage findings against your risk criteria, and keep records of decisions and remediation. The hard parts are consistency and capacity, because an annual exercise will not satisfy a continuous duty. Check whether your team can maintain the tooling, respond to critical advisories within your own timelines, and produce evidence on demand. A pilot covering one critical function is a reasonable way to measure the real workload before deciding how much to outsource.

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms in your own infrastructure. For this topic, that can include setting up dependency tracking, code analysis in the build pipeline, the asset and dependency records, and the runbooks that show how findings are handled. A fixed written scope sets out what is delivered. DeployOpen does not decide your classification of any software as an ICT service, does not own your controls, and does not issue audit reports or attestations. Those decisions and sign-offs remain with your management body and your independent auditor or the competent authority.

Supervisors do not certify software, so acceptance depends on whether your evidence shows the decision and the process behind it. DORA sets no certification scheme, and competent authorities assess compliance using their supervisory powers. Good evidence usually includes the written classification reasoning, the software inventory with versions, dependency scan outputs, triage records with dates and owners, remediation tickets, and the policy that governs them. Ask your auditor early which artefacts they expect and in what format. Where a supplier is involved, confirm that its contractual duties to report critical vulnerabilities in a timely way are written into the agreement. Acceptance is a judgement made by the assessor, so confirm expectations with them rather than assuming them.