What a Year of DORA Reveals About Cyber Resilience
4 minute read time
It's now been a full calendar year since the European Union's Digital Operational Resilience Act (DORA) became enforceable in January 2025, marking a clear shift in how regulators expect organizations to manage digital risk.
In the UK, the proposed Cyber Security and Resilience Bill points in a similar direction. It raises expectations for how organizations prepare for, respond to, and report cyber incidents, signaling that digital resilience is now a regulatory concern, not solely an operational one.
Looking at DORA one year in is useful, not because it offers a perfect model, but because it highlights a recurring challenge in cyber regulation: improving visibility after incidents versus reducing the likelihood and impact of incidents in the first place.
What Is DORA and Who Is in the Crosshairs?
DORA applies specifically to financial entities operating in the EU, but its implications extend beyond those entities, particularly to information and communication technology (ICT) third-party service providers that support critical operations.
The intent is to ensure that organizations can withstand, respond to, and recover from ICT disruptions consistently. Not every technology provider falls directly under DORA, but the regulation makes clear that resilience does not stop at organizational boundaries. At Sonatype, we see this as a necessary step forward. The growing scale and frequency of cyber incidents have exposed the limits of relying on organizations to report issues on their own timelines. Dependencies matter, and regulators are paying much closer attention to the risks they introduce.
Tara Houlden, Director of Product Security Compliance and Risk at Red Hat, recently joined a Sonatype webinar to reflect on DORA's first year, saying, "Mature organizations are the ones that understand its path to deliver products or services and have a plan to support the areas where they have dependencies. A really mature organization is testing its approach regularly and incorporating lessons learned into its plans."
This broader view of risk is increasingly reflected in UK policy thinking, as digital services and supply chains become more interconnected.
The Pillars of DORA Resilience
DORA is structured around several core pillars that define what regulators mean by operational resilience. At the foundation of DORA is the requirement for a comprehensive ICT risk management framework. Financial entities are expected to identify, assess, and mitigate risks across systems, processes, and dependencies. They must embed resilience into governance and day-to-day operations, rather than treating it as a standalone security activity.
DORA requires organizations to classify and report ICT-related incidents within defined timeframes to provide regulators with early awareness and support coordinated responses across the financial system. This approach mirrors the UK Cyber Security and Resilience Bill's proposed 24-hour initial notification, followed by a more detailed report within 72 hours. While faster reporting improves oversight, it does not in itself prevent attacks or reduce underlying risk.
Regular operational testing is another central requirement under DORA. Organizations are required to validate their preparedness through exercises ranging from vulnerability assessments to more advanced threat-led testing, ensuring that controls perform under realistic conditions.
DORA places explicit responsibility on organizations to manage risks arising from ICT third parties, including software vendors and service providers that underpin critical operations. This is likely to be one of the most challenging aspects of compliance. Organizations are increasingly accountable for ensuring their suppliers and managed service providers meet the same expectations they set for themselves, particularly around incident detection and reporting.
Finally, to strengthen collective defense, DORA encourages structured information sharing around cyber threats and vulnerabilities. The aim is to help organizations respond more effectively to emerging risks and reduce duplicated effort across the sector.
Regulation 56, Data Protection, and Software Risk
Regulation 56 of DORA focuses on data protection and reinforces the expectation that organizations manage ICT risks to safeguard the confidentiality, integrity, and availability of information. While the regulation does not prescribe specific tools or techniques, it sits within a broader framework that requires organizations to understand and control the risks present across their digital environments.
For engineering and security teams, this has practical implications. Most modern applications rely heavily on open source components, and unmanaged dependencies are a common source of vulnerabilities and operational risk. Without transparency into those components, it is difficult to assess exposure, respond effectively to incidents, or demonstrate that appropriate controls are in place.
From a DevSecOps perspective, meeting DORA's risk management and resilience expectations typically requires organizations to maintain accurate insight into the software they build and operate, including third-party and open source dependencies. Practices such as automated analysis, policy enforcement, and continuous monitoring are widely used to support this level of oversight and to demonstrate that software-related risk is actively governed over time.
The Critical Role of the SBOM in Compliance
Transparency is a recurring theme throughout DORA, and software is no exception. A software bill of materials (SBOM) provides a structured record of the components that make up an application, forming the foundation for risk assessment, incident response, and third-party oversight. To support DORA's documentation and risk management expectations, many organizations choose to generate and maintain SBOMs for every release, ensuring full insight into an application's components and dependencies. However, compliance doesn't stop at generation. Static SBOMs quickly lose value as new vulnerabilities emerge.
One year after its implementation, DORA has left no question about its importance for operational resilience. It has improved visibility through stronger reporting and oversight, but it has also made clear that transparency alone isn't enough. Real resilience is built long before an incident is reported, upstream in how organizations govern software, assess suppliers, and manage operational risk at the source. As regulators and firms reflect on DORA's first year, the focus must now shift from documenting failures after the fact to preventing them in the first place.
Discover additional resources on DORA and other global regulations by visiting our Regulations Resource Center.
Aaron is a technical writer on Sonatype's Marketing team. He works at a crossroads of technical writing, developer advocacy, software development, and open source. He aims to get developers and non-technical collaborators to work well together via experimentation, feedback, and iteration so they ...
Explore All Posts by Aaron LinskensTags
Comply with SBOM Regulations
Meet regulatory requirements with Sonatype SBOM Manager – a single solution for SBOM monitoring, management, and compliance.