The Digital Operational Resilience Act, DORA, came into application in January 2025 and 2026 is the first full year of operational supervision under the regulation. DORA covers a wide swath of European financial services including banks, insurers, investment firms, payment institutions, crypto-asset service providers, and a long list of other regulated entities. Its provisions on ICT third-party risk management, on incident reporting, and on operational resilience testing have substantially reshaped how covered entities think about software supply chain. The regulation is technical, prescriptive in places, and operationally demanding, and the experience of the first year of supervision has clarified what auditors and competent authorities actually expect.
What does DORA's ICT third-party risk framework actually require?
Articles 28 through 30 of DORA establish the framework for ICT third-party risk management. Covered entities must maintain a register of contractual arrangements with ICT third-party service providers, must classify those providers based on the criticality of the services, must assess concentration risk and substitutability, and must include specific contractual provisions in agreements with critical providers. The register is reportable to the competent authority and the European Supervisory Authorities.
The register requirements are detailed. Each contractual arrangement must be described with information about the service, the provider, the location of data and processing, the criticality classification, and the controls in place. The register is not a one-time deliverable; it is a continuously maintained operational artifact that must reflect changes in the contractual landscape and the underlying ICT services. Covered entities have spent substantial effort through 2025 building tooling to maintain the register from operational telemetry rather than from manual contract reviews.
The contractual provisions required by Article 30 are also detailed. Critical contracts must include service descriptions, locations, security and availability commitments, audit rights, exit and termination provisions, sub-outsourcing controls, and incident notification timelines. The European Supervisory Authorities issued implementing technical standards through 2024 and 2025 that specified the expected content, and contracts that pre-existed DORA have largely been amended or replaced through 2025 and 2026 to comply.
How does the critical ICT third-party provider designation work?
DORA establishes a separate supervisory regime for critical ICT third-party providers, with the European Supervisory Authorities directly supervising designated providers. The criteria for designation include the systemic impact of the provider's failure on financial stability, the criticality of the financial entities relying on the provider, and the substitutability of the services. The first round of designations through 2025 captured several of the largest cloud providers, and additional providers may be designated as the regime matures.
Designated providers are subject to direct oversight, including the right of the lead overseer to conduct investigations, to issue recommendations, and to assess remediation. The compliance burden on designated providers is substantial, but the implication for covered entities is more interesting. A covered entity using a designated provider gets some assurance that the provider is being supervised, but the covered entity remains accountable for its own ICT third-party risk management. The designation is supplementary, not substitutive.
For covered entities, the practical effect of the critical provider regime has been clearer expectations of due diligence. The regulator expects the entity to evaluate whether a service should be sourced from a designated provider, from a non-designated provider, or built internally, and to document the rationale. Concentration risk analysis, which examines exposure to single providers across the entity's portfolio, has become a particularly demanding area where many covered entities have invested heavily.
What does software supply chain visibility actually require under DORA?
DORA does not use the term "software supply chain" extensively, but the substance is distributed across the ICT third-party requirements, the operational resilience testing requirements, and the incident reporting requirements. Covered entities must understand the ICT services they consume, must understand the dependencies of those services, must test the resilience of the dependencies, and must report incidents that affect the dependencies.
In practice, satisfying these requirements demands software supply chain visibility at component level. A bank cannot test the resilience of a critical service without knowing the components that make up the service, including the open-source dependencies, the third-party libraries, and the infrastructure components. The audit and inspection rights granted under Article 30 contracts mean nothing if the covered entity does not know what to ask the provider about. Many covered entities have built component-level software inventories specifically to support DORA-grade due diligence and incident response.
The interaction with the EU Cyber Resilience Act is also relevant. CRA-conforming products carry technical files including SBOMs, and DORA-covered entities increasingly require these artifacts during vendor onboarding. European financial services procurement now expects detailed supply chain documentation as standard.
How are covered entities handling DORA incident reporting?
DORA Article 19 establishes the incident reporting framework. Major ICT-related incidents must be reported to the competent authority following a tiered timeline that includes initial notifications, intermediate updates, and final reports. The thresholds for major incidents are specified in implementing technical standards, and the reporting templates are standardized across the EU.
The first year of operation has produced a substantial volume of incident reports, and the supervisory community has begun to establish patterns of expectations for report quality. Reports that include clear scope description, root cause analysis, impact quantification, and remediation steps are treated more favorably than reports that defer analysis or that under-describe the incident. Covered entities are increasingly investing in incident response capabilities specifically tuned to produce DORA-grade reports under deadline.
Supply chain incidents have been a notable share of major incident reports. When a critical ICT third-party provider experiences an outage or security incident, the downstream impact on covered entities frequently meets the major incident threshold, which generates reports from each affected entity. The pattern produces detailed visibility into supply chain risk concentration that has informed the regulator's broader policy thinking and is likely to drive further refinement of the third-party regime.
What does operational resilience testing actually look like?
DORA requires covered entities to conduct regular operational resilience testing, including threat-led penetration testing for the largest entities. The testing scope must include critical functions, the ICT systems supporting them, and the third-party dependencies. The testing methodology, scope, and findings are documented and shared with the competent authority.
The threat-led penetration testing requirements are particularly demanding. The TIBER-EU framework, which DORA aligns with, prescribes a methodology that includes threat intelligence gathering, red team exercises against production systems, and purple team activities. Several rounds of TIBER-EU-aligned testing have driven substantial investment in supply chain visibility and detection capabilities.
For smaller covered entities, testing requirements are scaled but still demanding. Annual or biennial testing of critical functions is expected, and the testing must include third-party dependency scenarios. Covered entities relying on a small number of critical providers find themselves exercising the substitutability assumptions in their concentration risk analysis.
What changes through 2026 and beyond?
The first full year of supervision is producing patterns that will shape the next phase. Competent authorities have been calibrating their expectations through 2025 and 2026, and the next round of supervisory dialogue is likely to deepen expectations in several areas. The register quality, the contract amendments, and the testing programs that were acceptable in year one are unlikely to remain acceptable in year three without further investment.
Cross-border supervision is also evolving. The European Supervisory Authorities are working to harmonize expectations and coordinate on cross-border matters. The trajectory is toward consistent EU-wide expectations, which simplifies multinational compliance but raises the floor for lowest-burden member states.
A subtle change is in the relationship between covered entities and providers. Article 30 audit rights are increasingly being exercised, producing more direct interaction between financial regulators and ICT providers. The dynamic is reshaping how providers approach their financial sector business.
How Safeguard Helps
Safeguard provides the operational substrate that DORA-compliant ICT third-party risk programs require. The platform maintains a continuously-updated component-level inventory of every ICT service in scope, with provider mapping, service classification, and concentration analysis built in. Lino compliance produces the DORA register content from real telemetry, maintains the contractual evidence trail, and generates competent authority-ready reports. Griffin reachability analysis surfaces the supply chain vulnerabilities that actually affect critical financial services, supporting risk-aware prioritization that holds up under operational resilience testing scrutiny. Incident response workflows align with DORA reporting timelines and produce the structured incident reports that competent authorities expect. The result is a third-party risk program that is operational, current, and supervisable rather than a documentation exercise that fails on first contact with the regulator.