DORA ICT risk and third-party code obligations, explained
The Digital Operational Resilience Act (DORA) has applied to EU financial entities since January 2025. It sets a common framework for managing information and communication technology (ICT) risk across banks, insurers, investment firms, payment institutions, crypto-asset service providers, and many of the technology vendors that serve them. If you build or operate software inside that perimeter, the relevant question is not whether DORA applies but which obligations map to which part of your stack.
What DORA expects on ICT risk
DORA organises its requirements around a few pillars. The ones that touch engineering most directly are:
- ICT risk management — entities must identify, classify, and protect ICT assets, including the software and systems that support critical functions, and maintain documented controls.
- ICT-related incident management — incidents must be detected, classified, and reported within defined timelines, which means you need to know what is in your environment before something goes wrong.
- Digital operational resilience testing — controls have to be tested on a recurring basis, not signed off once and forgotten.
- ICT third-party risk — entities remain accountable for risk introduced by their providers and the components those providers ship, including open-source and other third-party code.
Where code security fits
Two of these pillars land squarely on the codebase. ICT risk management expects you to know what your software depends on and what controls protect it. ICT third-party risk expects you to account for the libraries and components you pull in, since a weakness in a dependency is still your exposure to manage.
That is hard to satisfy with a point-in-time review. Dependencies change every sprint, and a control that held last quarter may not hold today. Continuous code-security findings give you a current read: what is in the stack, which components carry known weaknesses, and which controls are present or missing. Treated as evidence rather than a one-off checklist, that maps onto the ongoing nature of what DORA asks for.
Where a scan helps
OLYDI fingerprints the stack and surfaces the controls and gaps that relate to these obligations — dependency exposure, logging, and the boundaries around sensitive components — as findings you can triage in the Security tab. It does not certify you against DORA; it gives you a baseline read of where you stand so the resilience conversation starts from evidence rather than a blank page.
Get your baseline
npx @olydi/cli scan # Scan complete. Findings written to SARIF.
Run the scan, review the findings, and decide what to clear first. The scan is free; clearing findings at volume is paid on Valty tiers.
This article is general information about regulatory developments, not legal advice. Consult qualified counsel for your specific obligations.