The Digital Operational Resilience Act (DORA), formally Regulation (EU) 2022/2554, is the EU's attempt to make the financial sector able to withstand, respond to, and recover from ICT disruptions. Unlike a directive, DORA is a regulation, so it applies directly and uniformly across all Member States without national transposition. It has applied since 17 January 2025. For software and platform teams inside banks, insurers, and the vendors that serve them, DORA reframes operational resilience as an evidenced, tested, and continuously monitored discipline rather than a policy document filed once a year.
What DORA is and who it covers
DORA consolidates and harmonises rules that were previously scattered across sectoral guidance. It applies to a broad set of financial entities — credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and intermediaries, fund managers, trading venues, central counterparties, and more — as well as, crucially, the ICT third-party service providers that supply them. The most systemically important of those providers can be designated critical ICT third-party providers (CTPPs) and placed under direct EU-level oversight by the European Supervisory Authorities (the EBA, ESMA, and EIOPA).
The obligations are elaborated through Regulatory and Implementing Technical Standards (RTS and ITS) drafted by the ESAs. Several of these were finalised across 2024 and 2025, and a few remained subject to phased finalisation, so teams should track the latest RTS text rather than working from the level-1 regulation alone. Proportionality applies: smaller and less interconnected entities face a simplified ICT risk-management framework.
The five pillars
DORA is best understood as five interlocking pillars:
- ICT risk management — a governance framework, owned by the management body, covering identification, protection, detection, response, recovery, and learning. This includes asset inventories and vulnerability management.
- ICT-related incident management, classification, and reporting — a harmonised taxonomy for classifying incidents and deadlines for reporting major incidents to competent authorities.
- Digital operational resilience testing — a programme of testing that, for significant entities, includes threat-led penetration testing (TLPT) at least every three years, aligned with the TIBER-EU framework.
- Management of ICT third-party risk — contractual requirements, exit strategies, concentration-risk analysis, and a mandatory register of information cataloguing every ICT contract.
- Information sharing — voluntary arrangements to exchange cyber threat intelligence.
The software and supply-chain obligations
For engineering teams, pillars one, three, and four do the heavy lifting. The ICT risk-management framework (Articles 5 to 16) requires you to identify and classify ICT assets, maintain them, and run continuous vulnerability management — you cannot protect assets you have not inventoried, and you cannot demonstrate resilience without knowing which components carry known weaknesses. The testing pillar (Articles 24 to 27) pushes vulnerability assessments, source-code reviews where appropriate, and scenario-based testing, escalating to full TLPT for the largest entities.
The third-party pillar (Articles 28 to 44) is where software supply chain meets financial regulation head-on. Every contractual arrangement for the use of ICT services must be entered in the register of information, using the ITS-defined templates, and reported to competent authorities. Contracts must include security, audit, subcontracting, and exit provisions. Because your own software depends on open-source and commercial components, the practical effect is that you must be able to say — for any service supporting an important or critical function — what it is built from, which suppliers are involved, and how you would exit or replace them.
Compliance checklist
- Maintain an ICT asset and component inventory covering software used in important functions.
- Run continuous vulnerability management with documented detection-to-remediation SLAs.
- Classify and report major ICT incidents against the DORA taxonomy and deadlines.
- Operate a resilience testing programme; schedule TLPT every three years if you are a significant entity.
- Populate and keep current the register of information for all ICT contracts.
- Embed security, audit, subcontracting, and exit clauses in ICT third-party contracts.
- Assess concentration risk across critical providers.
- Retain evidence — scans, test results, incident records, board oversight — in a retrievable form.
How Safeguard helps
DORA does not prescribe tools, but its ICT risk-management and third-party pillars are evidence-hungry, and that is where Safeguard fits. SBOM Studio produces a maintained component inventory for each application supporting a financial function, which is the raw material for the asset-identification duty in the risk-management framework and for describing what a third-party service is built from in the register of information. Safeguard's SCA runs continuous vulnerability management against those components and ranks findings by reachability, so the "identify, protect, detect" chain rests on live data with SLA tracking rather than periodic snapshots. Griffin AI turns triaged findings into tested remediations delivered as reviewable pull requests, keeping fixes fast without removing human approval. Every scan, fix, and decision is time-stamped in one record, so when a competent authority or a CTPP oversight team asks how you manage vulnerabilities in a critical function, the answer is a query, not a scramble.
Frequently Asked Questions
Does DORA apply to my company if we only supply software to a bank? Very possibly. DORA reaches ICT third-party service providers through the contractual obligations it forces onto their financial-entity customers, and the most systemically important providers can be designated critical and placed under direct EU oversight. Even if you are not designated, your financial customers will flow DORA requirements down to you through contracts and the register of information.
What is the register of information? It is a structured catalogue of every contractual arrangement a financial entity has for ICT services, maintained using ITS-defined templates and reported to competent authorities. It captures the provider, the function supported, subcontracting chains, and criticality, giving regulators a map of concentration risk across the sector.
Who has to do threat-led penetration testing? TLPT is required for financial entities identified as significant based on their size, risk profile, and systemic importance, and it must be conducted at least every three years on live production systems supporting critical functions. Smaller entities run the broader resilience-testing programme but are generally not obliged to perform full TLPT.
How does DORA relate to NIS2? DORA is lex specialis for the financial sector, meaning that where both could apply, DORA's specific financial-sector rules take precedence for the ICT risk-management, reporting, and testing matters it covers. Entities can still be subject to NIS2 for aspects DORA does not address, so confirm the boundary for your particular activities.
Want to see how continuous supply-chain evidence supports DORA? Explore our compliance mappings or read the integration guides in the Safeguard documentation.