Navigating DORA Compliance: Software Development Requirements for Financial Services Companies

Note: This blog was originally published in July 2024 and updated on an annual basis. It was most recently updated in April 2026.

Regulatory compliance is a common and critical part of today’s rapidly evolving financial services landscape. One new regulation that EU financial institutions must adhere to is the Digital Operational Resilience Act (DORA), enacted to enhance the operational resilience of digital financial services. The BCI Supply Chain Resilience Report 2024 highlighted that 80% of organizations experienced supply chain disruptions, marking a significant increase from the previous year. This shows the lingering impact of Information and Communications Technology (ICT) resilience issues on operational continuity​​.

DORA compliance entered into application as of January 17, 2025. ICT encompasses a wide array of technological tools and resources employed for communication, content creation, information dissemination, storage, and management. This comprehensive term includes electronic devices, networking components, and software applications that facilitate diverse forms of digital communication and information handling.

In terms of the financial services sector, DORA applies to insurance companies, investment firms, banks, fintech, and ICT vendors, who must understand and adhere to DORA requirements to ensure operational resilience and avoid substantial fines. This blog post discusses the essential software development requirements financial companies should meet to assist in complying with DORA.

DORA is now in full force. While the January 17, 2025 deadline has passed, 2025 was treated as a supervisory transition year in which regulators are reviewing firms’ new frameworks, identifying gaps, and calibrating expectations. Enforcement scrutiny is expected to intensify significantly through 2026. Financial institutions that have not yet achieved full compliance must treat this as a matter of urgency.

What is DORA?

DORA is a regulation enacted by the European Union to enhance the digital operational resilience of financial institutions, to ensure that financial entities can withstand and recover from all types of technology-related disruptions and threats.

The goal of DORA is to enhance operational resilience across the financial sector, even in cases of severe operational disruptions. The regulation emphasizes the need for financial institutions to establish robust capabilities for:

1. Protection: Safeguarding against technology-related incidents
2. Containment: Limiting the impact of disruptions
3. Detection: Identifying incidents promptly
4. Recovery: Restoring services efficiently
5. Repair: Fixing any damage caused by an incident

Who Needs to Comply with DORA?

DORA applies to a wide range of financial organizations operating in the EU. Over 22,000 entities are estimated to be impacted by DORA, making compliance essential for regulatory adherence and business continuity. Financial services companies headquartered across the world, doing business in Europe, must comply with DORA to continue operating.

These five pillars are the key to complying with DORA regulations

The 5 Key Software Development Requirements

DORA compliance covers many areas. Let’s take a closer look at how the wider guidelines specifically affect software development operations and processes. To bring this from theory into practice, we present each of the five core pillars and suggest what steps to take to ensure compliance from a software development perspective.

1. Governance and Robust ICT Risk Management Framework

Financial companies must identify and assess potential vulnerabilities within their software systems while Implementing mitigation strategies to reduce the impact of identified risks.

JFrog AppTrust directly supports this governance pillar by transforming artifacts into business-aware “Application Entities” with defined ownership and criticality metadata, and a continuous, automated policy-enforcement layer. Rather than relying on manual risk assessments that cannot scale with AI-accelerated development, AppTrust enforces evidence-based policy gates that physically block non-compliant software at every stage of the SDLC, providing the automated, auditable ICT risk management framework DORA demands.

2. Information & Intelligence Sharing

This refers to the exchange of cyber threat intelligence among organizations to build collective resilience against cyber threats and enhance the sector’s overall preparedness and response capabilities.

3. Incident Reporting and Response

To comply with procedures for timely incident detection and response, DevOps must implement logging and monitoring solutions that detect anomalies and prevent potential security incidents. In addition, DevSecOps has to establish a clear incident response plan that outlines steps for containment, eradication, recovery, and post-incident analysis.

It is important to note that DORA imposes strict and non-negotiable timelines for major incident reporting. Financial entities must submit an initial notification within 4 hours of detecting a major ICT incident, an intermediate report within 72 hours, and a final report within 30 days. This makes real-time detection and automated alerting capabilities, such as those provided by JFrog Advanced Security and JFrog Xray, operationally critical, not merely best practice.

JFrog AppTrust further strengthens incident response readiness by providing an immutable, cryptographically signed audit trail of every release, so when an incident occurs, teams can instantly identify which specific binary versions are affected, who owns them, and what evidence was collected at the time of release, dramatically accelerating DORA’s mandated 4-hour initial notification window.

4. Digital Operational Resilience Testing and Assessments

Continuous testing is vital to maintain the resilience of financial software systems. This should include penetration testing, vulnerability assessments, and disaster and business recovery planning.

5. Third-Party Risk Management

Financial companies often rely on third-party providers for software and technology-related services. To comply with DORA, it’s essential to perform due diligence on their suppliers’ security practices, stipulate contractual adherence to security and resilience standards, and monitor third-party security practices.

JFrog AppTrust is uniquely positioned to address DORA’s third-party risk requirements at the binary level. Every open-source package, third-party library, or vendor component that enters the software supply chain is governed through JFrog Curation and JFrog AppTrust’s immutable evidence vault, capturing SBOM data, vulnerability assessments, and provenance attestations, and is subject to automated policy gates before it can reach production. This provides financial institutions with a continuously updated, machine-readable record of every third-party dependency in their software real estate, directly supporting DORA’s requirements to maintain and monitor ICT third-party arrangements at scale.

JFrog helps with DORA compliance across the software supply chain (click to enlarge)

Major Update: The CTPP Designated List Is Now Published

A major development occurred on November 18, 2025, when the European Supervisory Authorities (EBA, EIOPA, and ESMA) published their first list of 19 designated Critical ICT Third-Party Providers (CTPPs). These include major cloud hyperscalers such as Amazon Web Services (AWS), Google Cloud, and Microsoft Azure, alongside data providers including Bloomberg and NTT, and telecommunications providers such as Deutsche Telekom and Orange. Enterprise software providers Oracle and SAP are also on the list. These 19 providers are now subject to direct regulatory oversight via Joint Examination Teams (JETs).

Importantly, CTPP designation does not relieve financial entities of their own DORA obligations. Firms remain fully accountable for contractual protections, risk assessments, and contingency plans regardless of whether their vendor is now under direct ESA oversight. Non-designated providers, including software supply chain tools like JFrog, are equally expected to meet the contractual standards DORA imposes. The list will be updated annually.

Coding for DORA: Putting it into Practice

Adhering to other regulations like the Cybersecurity Resilience Act (CRA) in the EU and NIST SP 800-218 Secure Software Development Framework (SSDF), and the U.S. EO 14028 Cybersecurity Executive Order requires security, risk, and compliance practices to be followed in a similar way to DORA. So, how do you translate these DORA pillars into concrete software development practices? Here are some key takeaways on how to do that:

• Secure by Design: Integrate security considerations throughout the SDLC. This could involve threat modeling, secure coding practices, vulnerability scanning, code reviews, static code analysis, secure package curation, and dependency resolution.
• DevSecOps: Break down silos between development, security, and operations teams, while fostering a collaborative environment where security is everyone’s responsibility and you achieve continuous scanning of your software across your supply chain.
• Automate for Efficiency: Utilize automation tools for vulnerability scanning, security testing, package curation, and incident response. This frees up developer time and streamlines the process
• Logging and Monitoring: Implement robust logging and monitoring practices within your applications. This allows for early detection of anomalies and potential security incidents. In addition, teams should look at managing security risks throughout their SDLC to maintain a single system of record.

New Framework: Binding Rules on ICT Subcontracting Chains (EU 2025/532)

Since this article was first published, a critical new piece of the DORA regulatory framework has entered into force: Delegated Regulation (EU) 2025/532, published on 2 July 2025 and applicable from 22 July 2025. This regulation introduces binding Regulatory Technical Standards (RTS) that govern the subcontracting of ICT services supporting critical or important functions within financial entities.

For software teams, this means that reliance on open-source packages, third-party build tools, or cloud-hosted CI/CD platforms now triggers formal due diligence and risk assessment obligations before any subcontracting arrangement is entered into. Financial entities must also ensure continuity of critical ICT services across the entire subcontracting chain, contractually secure audit and access rights, and be notified in advance of any material changes a primary provider makes to its own subcontractors. JFrog’s SBOM capabilities, dependency resolution, and artifact provenance tracking directly support these requirements by giving security teams full visibility into the software supply chain.

JFrog AppTrust extends this subcontracting compliance story further: by binding cryptographic evidence and ownership metadata directly to each binary artifact, AppTrust creates a tamper-proof chain of custody that travels with the software itself. This allows financial entities to prove, at any point in time, that a specific release in production was built with verified components, passed all required policy gates, and is traceable to a responsible business owner… exactly the kind of audit-ready record that Delegated Regulation (EU) 2025/532 demands.

Penalties for Noncompliance

DORA imposes financial penalties that vary based on severity: institutions found in breach may face fines of up to 2% of their total annual worldwide revenue or 1% of their average daily revenue worldwide. For individuals, penalties can reach up to €1,000,000, while critical third-party ICT providers face fines up to €5,000,000, or €500,000 for individuals.

Additionally, there’s a new dimension worth noting: DORA delegates the imposition of penalties to Member States, resulting in considerable divergence across countries. Revenue-based penalty ceilings vary between 5% (Spain) and 10% (Sweden), meaning the actual exposure for a given institution depends heavily on where they’re domiciled.

How JFrog can help EU Financial Institutions comply

JFrog’s security solutions including JFrog Xray, JFrog Advanced Security, and JFrog Curation can help financial services companies comply with DORA software development regulations. JFrog’s security solutions offer financial institutions a holistic suite of software supply chain security and compliance tools, essential for DORA compliance. Compliance is one of the most challenging aspects of doing business for Financial institutions as they adhere to strict regulatory frameworks like OCC, GDPR, PCI DSS, SOX, and NIST which mandate secure and compliant software development practices, data privacy, and corporate governance. The JFrog Software Supply Chain Platform serves as the foundation for these security and compliance practices and is used by the majority of large financial institutions across the world.

The JFrog Platform ensures continuous identification, prioritization, tracking, monitoring, management, and suggestions for remediation of potential vulnerabilities across the software development lifecycle. The solution leverages automated configurable policies, which can be tailored to assist in compliance with DORA or other regulations-specific requirements.

For example, curating vulnerability-free, non-malicious, and non-operationally risky open-source libraries, and packages can help with DORA’s security fundamentals and risk reduction intent. JFrog’s holistic software supply chain approach to security and compliance puts it in a prime position for helping financial institutions with their DORA compliance and can be applied to future financial services or other industry security and compliance regulations in the future.

A Software Bill of Materials (SBOM) is an essential tool for understanding the components included in your production release. JFrog’s automated SBOM generation feature provides release managers, QA, and security teams with a detailed inventory of what is slated for production including any identified security vulnerabilities and license compliance issues. JFrog’s SBOM exports support industry-standard formats such as SPDX and CycloneDX (CDX) and support the recently introduced VEX format.

The JFrog Platform helps break down the silos that can build up between development, security, and operations teams. JFrog can facilitate a collaborative DevSecOps environment where everyone is on the same page and security is top of mind.

JFrog AppTrust is purpose-built for exactly the governance challenge DORA imposes. As the AI-driven code tsunami accelerates software delivery, traditional manual governance—spreadsheets, screenshots, and ad-hoc reviews—simply cannot scale. It acts as an immutable System of Record for Software Supply Chain Governance, automatically collecting cryptographically signed evidence from every pipeline step (including integrations with ServiceNow, GitHub Actions, SonarQube, and others…) and enforcing evidence-based policy gates that physically block non-compliant artifacts from advancing to production.

For DORA specifically, this means financial institutions can demonstrate continuous, audit-ready compliance rather than scrambling to reconstruct proof after the fact, directly addressing DORA’s requirements for ICT risk management, third-party oversight, and incident traceability with a legally defensible audit trail.

With many of the world’s largest cloud providers now formally designated as CTPPs, including platforms that JFrog commonly runs on, such as AWS, Microsoft Azure, and Google Cloud, financial institutions using JFrog in cloud-hosted deployments must ensure their end-to-end ICT chain meets DORA’s contractual and risk management requirements.

JFrog’s platform provides the visibility layer needed to demonstrate compliance across these multi-provider environments: from artifact provenance and SBOM generation through to continuous vulnerability monitoring and policy enforcement. Critically, JFrog’s Register of Information support capabilities can help financial entities meet the annual RoI reporting cycle (reference date: 31 December each year) by maintaining a machine-readable, audit-ready record of ICT supplier and software component relationships.

Conclusion

Complying with DORA is not just about meeting regulatory requirements; it’s about fostering a resilient and secure digital environment for financial operations. DORA emphasizes the operational resilience of financial institutions to ICT disruptions and requires financial institutions to establish and maintain ICT risk management frameworks and regularly test their resilience.

By embedding robust risk management, secure software development practices, and continuous testing into the software development lifecycle, financial companies can ensure they are well-prepared to tackle the challenges of the digital age. Staying informed and proactive is key to maintaining operational resilience and safeguarding the integrity of financial services. DORA is not just about ticking boxes; it’s about building a resilient foundation for the stability of the entire financial services system. Remember, secure code is the key to a secure financial future!

Book a demo or take a product tour to see for yourself how JFrog can help make your software development operations DORA-ready while preparing for emerging standards coming down the road.

Disclaimer: The content provided in this article is for general information purposes only and does not constitute legal advice. The content may not reflect current legal developments, is not guaranteed to be correct, complete, or address your situation, and should not be relied upon.