The EU's Digital Operational Resilience Act (Regulation (EU) 2022/2554) entered into force on 16 January 2023 and became fully applicable on 17 January 2025 — with no transition period and no grandfathering for entities still catching up. It reaches roughly 22,000 financial entities across the EU, per European Commission estimates, plus every "critical" ICT third-party provider that serves them, meaning a US or UK SaaS vendor with EU bank customers can fall in scope even without an EU headquarters. DORA is built on five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information/threat-intel sharing. For AppSec and vulnerability management teams, the pillar that matters most day-to-day is the first one — Articles 5 through 15 — which reads less like financial regulation and more like a checklist for an existing SAST/SCA/DAST program: asset inventory, vulnerability identification, protective controls, detection, response, and continuous reassessment. The European Supervisory Authorities (EBA, EIOPA, and ESMA) finalized the Regulatory Technical Standards and Implementing Technical Standards that flesh out these articles, and most became applicable on that same 17 January 2025 date. This piece breaks down what the ICT risk-management framework actually requires and where a typical vulnerability program already covers it — and where it doesn't.
What does DORA's ICT risk-management framework actually require?
Articles 5 through 15 require financial entities to maintain a documented, board-owned ICT risk-management framework, not just a security tool stack. Article 5 puts ultimate accountability on the management body — the board must approve the ICT risk strategy and can't delegate that sign-off to a CISO alone. Article 8 requires identification of all ICT assets and their dependencies, kept current on an ongoing basis rather than refreshed annually. Article 9 requires protection and prevention measures proportionate to risk. Article 10 requires detection mechanisms that flag anomalous activity "without undue delay." Articles 11 and 12 require documented response, recovery, and backup procedures. None of this is exotic to a mature AppSec program — it is the same asset-inventory-to-remediation lifecycle most teams already run — but DORA makes board-level ownership and continuous (not periodic) reassessment into explicit legal requirements rather than best practice.
How does DORA's incident-reporting pillar intersect with vulnerability findings?
DORA's incident-reporting pillar (Articles 17-23) intersects with vulnerability management wherever an unpatched, reachable vulnerability turns into an actual exploitation event, because a "major ICT-related incident" under DORA triggers a formal notification obligation to national competent authorities on a defined timeline. The RTS on incident classification, finalized by the ESAs alongside the other DORA technical standards, sets materiality thresholds — covering factors like affected clients, downtime, and geographic spread — that determine whether an event needs initial, intermediate, and final reports. The practical link back to AppSec: a vulnerability management program that can show when a flaw was identified, how it was triaged, and when it was remediated becomes the evidentiary backbone of an incident report if that same flaw is ever exploited. Regulators reviewing an incident will ask what the entity knew about the underlying weakness beforehand, not just what happened during the breach itself.
What does digital operational resilience testing add beyond routine scanning?
Digital operational resilience testing, covered in Articles 24-27, requires financial entities to go beyond routine vulnerability scanning into structured, adversarial testing — and for the largest entities, that means threat-led penetration testing (TLPT) under Article 26, modeled on frameworks like TIBER-EU. Article 24 sets a general testing obligation covering vulnerability assessments, scenario-based testing, and source-code reviews as part of a broader testing programme, generally expected at least yearly for most ICT systems supporting critical functions. Article 26 layers TLPT on top for entities the competent authority designates as significant, requiring red-team-style tests against production systems using real threat intelligence, at a cadence of every three years. For an AppSec team, this pillar is where SAST/SCA/DAST output stops being sufficient on its own — regulators expect evidence that findings were validated against exploitability in a live-fire exercise, not just flagged by a scanner and left in a backlog.
Why does the "register of information" on ICT third-party providers matter for software supply chain risk?
The register of information matters because DORA treats a financial entity's software and cloud suppliers as part of its own risk surface, and Article 28 requires a maintained, structured register covering every ICT third-party arrangement — including which providers support critical or important functions, sub-outsourcing chains, and contractual termination rights. National competent authorities set their own 2025 deadlines for entities to submit the first registers (most fell in the first half of the year, with authorities then consolidating and forwarding them to the ESAs by 30 April 2025), forcing entities to have this documentation ready well before those dates rather than compiling it retroactively. For software supply chain risk in particular, this is where SBOM practices and vendor vulnerability disclosures stop being a nice-to-have: an entity that can't produce a current list of its critical software dependencies and their upstream providers has a gap the register of information is explicitly designed to close.
Where does a standard vulnerability management program fall short of DORA?
A standard vulnerability management program typically falls short of DORA in three places: continuous (not periodic) asset and risk reassessment under Article 8, board-level reporting cadence under Article 5, and the register of information under Article 28, which most security tools were never built to produce. Scanner output — a list of CVEs by severity — answers "what's vulnerable" but not "which of these map to a critical function, and can we show a regulator the full lineage of that dependency and every remediation decision tied to it." DORA's enforcement runs through each member state's national competent authority rather than a single EU-wide penalty schedule, so the practical risk of a documentation gap varies by jurisdiction — but the underlying requirement, a living, board-visible record connecting assets, findings, and third-party relationships, is consistent across all of them.
How Safeguard helps
Safeguard's compliance engine lists DORA among its supported EU frameworks, with support specifically scoped to ICT third-party risk evidence and the register of information required under Article 28 — generating the structured record of critical software providers and dependencies that Article 28 calls for, rather than leaving teams to assemble it manually in a spreadsheet. That register draws on the same dependency and SBOM data Safeguard already tracks for SCA and supply-chain scanning, so the third-party inventory a DORA examiner asks for and the vulnerability inventory an AppSec team already maintains stay in sync instead of drifting apart across two separate systems.