The Digital Operational Resilience Act (DORA) is the EU regulation that made operational resilience — including the security of the technology financial firms depend on — a matter of binding law rather than guidance. It has applied since 17 January 2025, and while much of the discussion centres on incident reporting and third-party oversight, DORA reaches squarely into the software supply chain. This guide explains how, organised around the regulation's five pillars.
What DORA is and who it applies to
DORA, formally Regulation (EU) 2022/2554, establishes uniform requirements for the security of network and information systems supporting the business of financial entities across the EU. Its scope is broad: banks, insurers, investment firms, payment institutions, crypto-asset service providers, trading venues, and many others — around 20 categories of financial entity. Critically, it also reaches ICT third-party service providers that serve those entities, and designates some of them as "critical" for direct oversight at the EU level.
If you are a financial entity operating in the EU, DORA applies to you directly. If you are a technology vendor selling software or services into EU financial firms, DORA applies to you indirectly but powerfully — your customers are contractually obliged to manage the risk you represent, which flows down to you as security and resilience requirements.
The five pillars, through a supply chain lens
DORA is built on five pillars. Each has a software supply chain dimension:
-
ICT risk management. Financial entities must maintain a comprehensive ICT risk-management framework, including identifying and protecting ICT assets and detecting anomalous activity. Knowing the software components that make up your systems — and the vulnerabilities in them — is part of identifying and protecting those assets.
-
ICT-related incident management and reporting. Entities must classify and report major ICT incidents to authorities within defined timeframes. A vulnerability in a widely used component that leads to an incident is exactly the kind of event this pillar governs, so knowing which systems a component touches is essential to timely, accurate reporting.
-
Digital operational resilience testing. Entities must test their ICT systems regularly, ranging from vulnerability assessments to advanced threat-led penetration testing (TLPT) for the most significant entities. Vulnerability scanning of applications and their dependencies is a foundational part of this testing regime.
-
ICT third-party risk management. This is DORA's centre of gravity for vendors. Entities must maintain a register of information on all contractual arrangements with ICT third-party providers, assess concentration risk, and ensure contracts include specific security and audit provisions. Software suppliers are ICT third parties, and their security posture is now something the financial entity must actively manage and document.
-
Information sharing. Entities are encouraged to share cyber threat intelligence, including on vulnerabilities and threats affecting shared technology.
Why the software supply chain is unavoidable under DORA
Two pillars make supply chain visibility non-negotiable. The third-party risk pillar means a financial entity must be able to answer, for any vendor, what software that vendor runs and how it manages vulnerabilities — questions the vendor can only answer with a current component inventory. The testing and incident pillars mean the entity must find vulnerabilities before they cause incidents and, when an incident occurs, rapidly determine which systems and components were involved. Both depend on the same underlying capability: knowing what is in the software and continuously watching it.
DORA is supported by regulatory and implementing technical standards (RTS and ITS) that add detail to these obligations, including the format of the register of information and the criteria for classifying incidents. The direction is consistently toward structured, demonstrable evidence rather than narrative assurances.
DORA supply chain readiness checklist
| Pillar | What to demonstrate |
|---|---|
| ICT risk management | Inventory of software components and their vulnerabilities as ICT assets |
| Incident reporting | Ability to map a vulnerable component to affected systems quickly |
| Resilience testing | Regular vulnerability assessment of applications and dependencies |
| Third-party risk | Register entries and evidence of each vendor's vulnerability management |
| Information sharing | Process to consume and act on threat/vulnerability intelligence |
How Safeguard helps
Safeguard gives both financial entities and their software vendors the supply chain visibility DORA's pillars require. SBOM Studio maintains a current inventory of the components in each application — the ICT asset visibility pillar one expects and the raw material for answering third-party risk questions. Software composition analysis provides the continuous vulnerability assessment that underpins the resilience-testing pillar, watching your dependencies for newly disclosed issues rather than relying on periodic tests alone.
When an incident hits, the ability to map a vulnerable component to every affected system is what makes DORA's reporting timelines achievable — and because the Safeguard CLI ties each SBOM to a specific build and artifact, that mapping is already in place rather than reconstructed under pressure. Griffin AI prioritises findings by exploitability so testing and remediation focus where resilience is genuinely at risk. Our compliance pages map these capabilities to DORA's pillars so a financial entity can evidence third-party diligence and a vendor can answer it.
DORA turned operational resilience into law, and the software supply chain is where a lot of that resilience is won or lost. Make component visibility and continuous vulnerability monitoring standing capabilities, not project work.
Answer DORA third-party questions with evidence, not assurances. Create a free account or read the Safeguard documentation to get started.