DORA — the EU's Digital Operational Resilience Act — became fully applicable on January 17, 2025, and it changed how financial entities are required to treat software supply chain risk. It's not a voluntary framework: banks, insurers, payment processors, trading venues, and crypto-asset service providers across the EU are now legally required to map ICT third-party dependencies, test resilience against real attack scenarios, and report major ICT-related incidents to regulators within tight windows (initial notification within 4 hours of classification, intermediate report within 72 hours). For engineering and security teams, DORA turns "we use a vetted vendor" into "we can prove, on demand, exactly which components — including open-source libraries three layers deep — power a critical function, and what our recovery time is if one fails." This post covers what DORA actually requires of software teams, the deadlines that matter, and how supply chain security tooling closes the gap between policy and evidence.
What is DORA and who does it apply to?
DORA is Regulation (EU) 2022/2554, and it applies to roughly 22,000 financial entities and their critical ICT third-party providers across the EU. It entered into force on January 16, 2023, with a two-year transition period ending January 17, 2025, when full compliance became mandatory. The regulation covers banks, credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, e-money institutions, crypto-asset service providers (aligning with MiCA), trading venues, and — critically — the ICT third-party providers (cloud platforms, SaaS vendors, software suppliers) that these entities depend on. Unlike GDPR, which is data-focused, DORA is explicitly about operational continuity: can the entity keep running, and can it prove it, when an ICT system — including a third-party or open-source component — fails or is compromised.
What does DORA require for software supply chain risk specifically?
DORA requires financial entities to maintain a full register of ICT third-party dependencies and to assess concentration and cascading risk from those dependencies, per Article 28. This extends beyond your direct vendor contracts to the open-source packages, container base images, and CI/CD tooling embedded in the applications those vendors — and your own engineering teams — ship. Article 5 requires a documented ICT risk management framework approved by the management body; Article 24-27 require regular resilience testing, including threat-led penetration testing (TLPT) for entities deemed significant; Article 30 requires contractual provisions with ICT providers covering exit strategies and subcontracting chains. In practice, an auditor asking "what happens if the log4j-style vulnerability shows up in a transitive dependency of your payments gateway" needs an answer backed by an actual dependency inventory, not a vendor questionnaire from 18 months ago.
What counts as a "major ICT-related incident" under DORA, and when must it be reported?
A major ICT-related incident is one that crosses impact thresholds set by the European Supervisory Authorities (EBA, EIOPA, ESMA) covering criteria like clients affected, service downtime, geographic spread, data losses, and reputational impact, and it must be reported to the competent authority in three stages: an initial notification within 4 hours of classifying the incident as major (and no later than 24 hours from detection), an intermediate report within 72 hours, and a final report within one month. This is materially faster than most incident response playbooks were built for. A 2024 ENISA threat landscape review found the finance sector was the second most-targeted industry in Europe for cyber incidents, and software supply chain compromise — a poisoned dependency, a compromised CI pipeline, a vulnerable third-party library — is explicitly called out in DORA's recitals as a systemic risk vector, not a hypothetical one. If your team can't identify, within hours, which production services import an affected package, the 4-hour clock becomes the hard part of compliance, not the reporting itself.
Why does DORA specifically call out ICT third-party and concentration risk?
DORA calls out third-party and concentration risk because regulators concluded that financial entities had outsourced critical technology functions to a small number of providers without adequate resilience oversight — the same handful of cloud and software vendors sit underneath a large share of EU financial infrastructure. Articles 28-30 require entities to classify ICT providers as "critical" based on factors like substitutability and the number of entities relying on them, and the European Supervisory Authorities directly oversee designated Critical ICT Third-Party Providers (CTPPs) under Title V. For software teams, the practical translation is a build materials requirement: you need to know not just "we use vendor X's platform" but which open-source components, container images, and build dependencies vendor X's platform — and your own software — actually pulls in, because concentration risk is invisible without a bill of materials. An SBOM (software bill of materials) is the mechanism regulators and auditors increasingly expect as evidence for this.
What are the penalties for DORA non-compliance?
Penalties under DORA are set by national competent authorities implementing the regulation, and for the Critical ICT Third-Party Providers directly overseen by the ESAs, fines can reach up to 1% of average daily worldwide turnover for each day of continued infringement, for up to six months. Beyond the direct fines, non-compliance findings feed into supervisory actions — including mandated remediation plans, restrictions on new ICT contracts, and in serious cases, requirements to terminate arrangements with non-compliant providers. For a financial entity, failing to produce an accurate ICT asset and dependency register during a supervisory review is itself a finding, independent of whether an actual incident occurred; the audit trail is part of what's being graded, and manual spreadsheets tracking "approved vendors" don't hold up against a regulator asking for a live, component-level view of production systems.
How is DORA different from NIS2 or GDPR for software teams?
DORA is narrower in scope than NIS2 but far more prescriptive on operational testing and ICT third-party oversight, and it applies specifically to the financial sector rather than the broader set of "essential and important entities" NIS2 covers. GDPR governs personal data handling; NIS2 sets baseline cybersecurity risk-management obligations across sectors like energy, health, and digital infrastructure with more general language. DORA, by contrast, mandates specific artifacts: a register of information on ICT third-party arrangements (Article 28, populated via detailed reporting templates from the ESAs' 2024 technical standards), TLPT programs on a minimum three-year cycle for significant entities, and named responsibility at the management-body level for ICT risk. A financial software team already doing NIS2-aligned vulnerability management still has DORA-specific gaps to close — namely, mapping software dependencies to the third-party register and proving testing cadence, which generic vuln management doesn't produce on its own.
How Safeguard Helps
Safeguard turns DORA's evidence requirements into artifacts your team already has, instead of a compliance fire drill every audit cycle. Our SBOM generation and ingest capabilities produce the component-level inventory Article 28's ICT third-party register demands, covering direct and transitive open-source dependencies across your services in minutes, not spreadsheets. Reachability analysis tells you which of those dependencies are actually exploitable in your running code paths, so when a new CVE lands you can answer the "who's affected and how fast can we fix it" question inside DORA's 4-hour incident-classification window instead of days later. Griffin AI correlates that reachability data with exploit context to triage what genuinely needs attention, and auto-fix PRs push the remediation directly into your repos so the fix — and its timestamp — becomes part of your audit trail automatically.