Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›DORA
EU · Regulation 2022/2554

DORA ICT risk and third-party compliance

how financial entities meet Articles 5-30 on resilience, testing and ICT supplier risk

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025. It mandates a documented ICT risk-management framework (Articles 5-6), continuous vulnerability identification (Article 8), digital operational resilience testing including threat-led penetration testing (Articles 24-27), and ICT third-party risk management with a register of information and mandatory contractual provisions (Articles 28-30).

This page explains, article by article, what DORA actually requires and how to build the technical evidence to satisfy supervisors. Governance and contract clauses are the entity's responsibility; this guide stays vendor-neutral and flags where automated application and supply-chain tooling genuinely reduces the work.

Talk to our advisory team Read it on EUR-Lex
At a glance
17 Jan 2025DORA has applied since this date
Art 5-30Core ICT risk, testing and third-party duties
~20Categories of EU financial entities in scope
3 ESAsEBA, ESMA and EIOPA supervise jointly
Regulation (EU) 2022/2554 (Digital Operational Resilience Act)
Why DORA matters

A single rulebook for financial-sector operational resilience

DORA replaces a patchwork of national ICT-risk expectations with one directly applicable EU regulation. It covers roughly 20 categories of financial entity, from banks, insurers and investment firms to payment institutions and crypto-asset service providers, plus the critical ICT third-party providers they depend on. National implementations such as Germany's BAIT have largely been folded into DORA, so the same framework now drives supervisory expectations across the bloc.

The regulation is built on five pillars: ICT risk management (Art 5-16), incident reporting (Art 17-23), digital operational resilience testing (Art 24-27), ICT third-party risk (Art 28-44), and information sharing (Art 45). Much of the detail lives in Regulatory and Implementing Technical Standards adopted by the ESAs, which set out the register of information template, TLPT methodology and incident classification thresholds.

Most of DORA is governance and oversight, which sits with the management body and cannot be bought from a vendor. But several articles demand concrete technical evidence: that vulnerabilities are continuously identified, that systems are tested for resilience, and that the components and suppliers behind ICT services are understood. Those are the points where security tooling does real work.

How O3 helps

Find it before attackers do. Catch it if they try. Fix it fast.

Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.

1 · Find it first

Test like an AI-assisted attacker

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.

2 · Catch it live

Detect and block exploitation at runtime

A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.

3 · Fix it fast

Auto-patch what is reachable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Articles 5-6

How to build a DORA ICT risk-management framework

Articles 5 and 6 require a sound, comprehensive and well-documented ICT risk-management framework, owned and approved by the management body and reviewed at least annually. It must cover strategies, policies, procedures and tools to protect all information and ICT assets.

DORA Art 5DORA Art 6
Assign ultimate accountability for ICT risk to the management body and document its review cadence (Art 5).
Map critical and important business functions to the ICT assets and dependencies that support them (Art 6, Art 8).
Write down the strategies, policies, protocols and tools that protect those assets, and keep them version-controlled and auditable (Art 6).
Allocate an appropriate budget and define a digital operational resilience strategy with measurable risk tolerance levels (Art 6).
Review the framework at least yearly and after major incidents, feeding lessons learned back into policy (Art 6, Art 13).
Article 8

How to continuously identify ICT vulnerabilities under DORA

Article 8 requires entities to identify, classify and document all ICT-supported business functions, the assets behind them, and the sources of ICT risk, including vulnerabilities and threats. Risk assessment must be performed regularly and on any major change.

DORA Art 8(1)DORA Art 8(2)DORA Art 8(7)
Maintain an inventory of ICT assets and the business functions each one supports, kept current as the estate changes (Art 8(1)).
Run continuous vulnerability identification across applications, dependencies and infrastructure rather than point-in-time scans (Art 8(2)).
Classify and prioritise findings by exploitability and business impact so the most material risks surface first (Art 8(2)).
Document risk assessments and refresh them on every major change to ICT systems or supported functions (Art 8(3), Art 8(7)).
Identify and assess legacy ICT systems, which DORA singles out as a specific source of risk (Art 8(7)).
Where O3 helps

O3 maps directly here: SAST with source-to-sink taint analysis, SCA against OSV, and function-level reachability identify and rank which vulnerabilities are actually exploitable, while EPSS and KEV signals prioritise the findings that matter for material business functions.

Articles 9-10

How to meet DORA protection and detection requirements

Article 9 covers protection and prevention, and Article 10 covers detection. Together they require continuous monitoring of ICT systems, mechanisms to detect anomalous activity, and controls that minimise the impact of ICT risk.

DORA Art 9DORA Art 10
Implement and document protective controls: access management, encryption in transit and at rest, and secure configuration baselines (Art 9).
Deploy continuous monitoring that can detect anomalous activity and potential single points of failure (Art 10(1)).
Define multiple layers of detection control and set alert thresholds tied to the incident classification rules (Art 10(2)).
Test detection mechanisms regularly so alerting and escalation actually trigger when needed (Art 10, Art 25).
Where O3 helps

O3's eBPF runtime agent (kayo) builds kernel-level process trees and detects attack chains with no sidecars, and its L7 deep packet inspection (ecapture) baselines egress to flag exfiltration and DNS-tunnel activity, supporting the continuous detection duty in Article 10.

Articles 24-27

How to run DORA digital operational resilience testing and TLPT

Articles 24-27 require a risk-based testing programme. Every entity must test ICT tools and systems regularly; significant entities must additionally undergo threat-led penetration testing (TLPT) at least every three years, following the TIBER-EU-aligned methodology in the regulatory technical standards.

DORA Art 24DORA Art 25DORA Art 26DORA Art 27
Establish a sound and comprehensive testing programme proportionate to size and risk profile (Art 24, Art 25).
Run the baseline test set: vulnerability assessments, scans, open-source analysis, penetration testing and scenario-based tests on production-supporting systems (Art 25(1)).
Fully address and remediate any weaknesses found, with priority on systems supporting critical functions (Art 24(5)).
If in scope, scope and execute TLPT against live production systems at least every three years using qualified testers (Art 26, Art 27).
Engage competent authorities to validate TLPT scope and obtain attestation on completion (Art 26(6), Art 26(7)).
Where O3 helps

O3's agentic DAST and pentest engine covers 50+ vulnerability classes and supports the vulnerability assessment, scanning and penetration-testing components of the Article 25 baseline; full TLPT remains a scoped engagement led by qualified red-team testers.

Articles 28-30

How to manage DORA ICT third-party risk

Articles 28-30 govern ICT third-party risk. Entities must only contract with providers meeting appropriate information-security standards, maintain a register of information on all contractual arrangements (Art 28), assess concentration risk (Art 29), and ensure contracts contain the mandatory provisions (Art 30).

DORA Art 28DORA Art 29DORA Art 30
Adopt and document a strategy for ICT third-party risk as part of the risk-management framework (Art 28(2)).
Maintain and keep current a register of information covering all ICT contractual arrangements, in the ESA template format (Art 28(3)).
Perform pre-contractual due diligence and assess whether the provider supports critical or important functions (Art 28(4)).
Assess ICT concentration risk, including dependence on hard-to-substitute providers and sub-outsourcing chains (Art 29).
Ensure contracts include the mandatory clauses: service descriptions, data location, access and audit rights, exit strategies and incident assistance (Art 30).
Where O3 helps

O3 generates CycloneDX xBOMs (SBOM with deps.dev and VEX, plus CBOM, QBOM, AIBOM and HBOM) and detects malicious dependencies such as typosquats and compromised maintainers, giving evidence of the components inside third-party and self-built ICT services that feeds supplier risk assessment.

Articles 17-23

How to meet DORA ICT incident management and reporting

Articles 17-23 require a process to detect, manage, classify and report ICT-related incidents. Major incidents must be reported to the competent authority following the classification criteria and timelines set in the technical standards.

DORA Art 17DORA Art 18DORA Art 19
Define an ICT-incident management process covering detection, logging, classification and response (Art 17).
Classify incidents against the DORA criteria: clients affected, data losses, duration, geographic spread, economic impact and criticality of services (Art 18).
Report major incidents to the competent authority using initial, intermediate and final notifications on the prescribed timelines (Art 19).
Capture root cause and feed it into the testing and risk-management framework so the same incident does not recur (Art 13, Art 17).
Where O3 helps

O3's eBPF runtime agent and L7 egress monitoring help detect intrusions and exfiltration early and reconstruct the attack chain, supporting the detection and root-cause analysis that incident classification under Article 18 depends on.

Articles 11-12

How to satisfy DORA backup, response and recovery duties

Articles 11 and 12 require ICT business continuity policies, response and recovery plans, and backup and restoration procedures with defined recovery objectives, regularly tested.

DORA Art 11DORA Art 12
Maintain an ICT business continuity policy and response-and-recovery plans tied to critical functions (Art 11(1)).
Set recovery time and recovery point objectives for each function and test restoration against them (Art 11(6), Art 12).
Keep backups physically and logically segregated from source systems to limit blast radius (Art 12).
Test continuity and recovery plans at least yearly and after major changes, and document the results (Art 11(6)).
The whole framework

Every DORA duty, mapped to how you meet it

All 23 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

9Pillar 1
ICT risk management (Art 5-13)
3Pillar 2
Incident management and reporting (Art 17-19)
3Pillar 3
Resilience testing and TLPT (Art 24-27)
8Pillars 4-5
Third-party risk and information sharing (Art 28-45)
Requirement area
ICT risk-management frameworkArt 5Management body owns and approves it
Framework components and reviewArt 6Document policies, tools, review yearly
Asset and function mappingArt 8(1)Inventory ICT assets per business function
Vulnerability and threat identificationArt 8(2)Continuous scanning, classify and prioritise
Legacy system riskArt 8(7)Identify and assess legacy ICT systems
Protection and preventionArt 9Access control, encryption, secure config
Detection and monitoringArt 10Continuous anomaly detection, alert thresholds
Business continuity policyArt 11Response, recovery plans with RTO/RPO
Backup and restorationArt 12Segregated backups, tested restoration
Learning and evolvingArt 13Feed incident lessons back into framework
Incident management processArt 17Detect, log, classify and respond
Incident classificationArt 18Apply DORA materiality criteria
Major incident reportingArt 19Initial, intermediate, final notifications
Testing programmeArt 24-25Risk-based, scans, pentests, scenarios
Remediate test findingsArt 24(5)Prioritise critical-function weaknesses
Threat-led penetration testingArt 26-27TLPT every 3 years, qualified testers
Third-party strategyArt 28(2)Documented ICT outsourcing strategy
Register of informationArt 28(3)All ICT contracts in ESA template
Pre-contract due diligenceArt 28(4)Assess provider security and criticality
Concentration riskArt 29Assess hard-to-substitute providers
Mandatory contract clausesArt 30Audit rights, exit, data location, support
Critical third-party oversightArt 31-44ESA designation and oversight framework
Information sharingArt 45Exchange cyber threat intelligence

Build the technical evidence DORA supervisors ask for

O3 Security covers the testable, technical side of DORA: continuous vulnerability identification with reachability ranking for Article 8, agentic DAST and pentesting for the Article 25 baseline, CycloneDX xBOMs and malicious-dependency detection for ICT third-party assurance under Articles 28-30, and eBPF runtime detection for continuous monitoring under Article 10. Governance and contracts stay yours; we make the evidence defensible.

Read it on EUR-Lex
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. It covers roughly 20 categories of EU financial entity, including banks, insurers, investment firms, payment and e-money institutions and crypto-asset service providers, along with the critical ICT third-party providers that serve them. It is supervised jointly by the EBA, ESMA and EIOPA.
  • Article 8 requires financial entities to identify, classify and document all ICT-supported business functions and the assets behind them, including continuously identifying vulnerabilities and threats. Risk assessment must be performed regularly and on every major change, and legacy systems must be specifically assessed (Art 8(7)). Continuous scanning with exploitability-based prioritisation satisfies this duty.
  • TLPT is an advanced resilience test required by Articles 26-27 for significant financial entities. It must be carried out at least every three years against live production systems, using qualified testers and a methodology aligned with TIBER-EU set out in the regulatory technical standards. Competent authorities validate scope and provide attestation on completion.
  • Article 28(3) requires every financial entity to maintain and keep current a register of information covering all contractual arrangements with ICT third-party providers, using the template defined in the ESA implementing technical standards. It records the service, whether it supports a critical or important function, sub-outsourcing chains and termination conditions, and is reported to competent authorities.
  • Article 30 sets mandatory contract provisions for ICT third-party arrangements: a clear service description and locations of data processing, access and audit rights for the entity and its supervisors, assistance during ICT incidents, defined service levels, and exit strategies. Contracts supporting critical or important functions carry additional requirements such as monitoring and termination rights.
  • DORA is a lex specialis for the EU financial sector and applies directly as a regulation, with deep ICT-risk, resilience-testing and third-party articles. NIS2 is a broader directive covering 18 sectors that member states transpose into national law. Where both could apply, financial entities follow DORA's more specific requirements for ICT risk and incident reporting.
  • DORA does not name a software bill of materials the way the EU Cyber Resilience Act does. However, Articles 8 and 28-30 require entities to identify ICT risk sources and understand the components inside ICT services and third-party arrangements. A CycloneDX SBOM, with malicious-dependency detection, is a practical way to generate that component-level evidence for supplier risk assessment.
  • The consolidated text of Regulation (EU) 2022/2554 is published on EUR-Lex at eur-lex.europa.eu/eli/reg/2022/2554/oj/eng. The accompanying Regulatory and Implementing Technical Standards, including the register of information template and the TLPT methodology, are published by the European Supervisory Authorities (EBA, ESMA and EIOPA).

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.