DORA compliance in Romania: what financial entities must do

Unlike NIS2, DORA did not wait for national transposition. The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — has applied directly to financial entities across the EU since 17 January 2025. What Romania added in 2026 is enforcement: Emergency Ordinance no. 14/2026 designates the competent authorities and gives them a sanctioning regime. For Romanian financial entities, DORA is no longer a preparation exercise — it is a supervised obligation with active examiners.

This overview covers who is in scope, what the five pillars require, how supervision works in Romania, and where to focus if your programme has gaps.

What DORA is

DORA consolidates the EU’s requirements for the digital operational resilience of the financial sector into one directly applicable regulation. Its premise is blunt: a financial entity’s soundness now depends on its ICT resilience as much as on its capital, so ICT risk is regulated with the same seriousness — harmonized rules, mandatory reporting, testing obligations, and supervisory consequences.

Who is in scope

DORA covers a deliberately broad set of financial entities: credit institutions, payment institutions and electronic money institutions, investment firms, trading venues, insurers, reinsurers and insurance intermediaries, management companies and fund managers, crypto-asset service providers, and others — together with the ICT third-party service providers that serve them, the critical ones falling under direct EU-level oversight. Proportionality tailors the depth of obligations to size and risk profile, but few regulated financial entities escape the regulation entirely.

The five pillars

1. ICT risk management – a documented framework owned by the management body: identification of critical functions, protection, detection, response and recovery, learning loops, and board-level accountability. The management body must approve the framework and understand it — responsibility cannot be delegated to IT or to vendors.
2. ICT incident reporting – incidents must be classified against defined criteria, and major incidents reported to the competent authority in stages (initial, intermediate, final) within the deadlines set by the technical standards. Significant cyber threats may be reported voluntarily.
3. Digital operational resilience testing – a proportionate annual testing programme for all in-scope entities, and threat-led penetration testing (TLPT) at least every three years for entities designated for it.
4. ICT third-party risk – the pillar most organizations underestimate: a complete register of information covering all contractual arrangements with ICT providers (submitted to supervisors, with the first exercises run in 2025), mandatory contractual provisions, concentration-risk analysis, and exit strategies for critical services.
5. Information sharing – voluntary arrangements for exchanging cyber threat information between financial entities.

Supervision in Romania: OUG no. 14/2026

Romania completed its DORA enforcement framework through Emergency Ordinance no. 14/2026, which assigns competence along existing prudential lines: the National Bank of Romania (BNR) for credit institutions, payment and electronic money institutions, and the Financial Supervisory Authority (ASF) for insurance, investment, and capital-market entities — with cooperation arrangements involving the DNSC on cybersecurity matters. The ordinance establishes administrative fines of up to 10% of annual turnover or RON 23,000,000, whichever is higher, alongside individual liability for board members and senior management.

Two practical consequences follow. First, your DORA supervisor is the authority you already know — expect ICT resilience questions inside ordinary supervisory engagement, not from a new agency. Second, the management-body accountability in DORA is now backed by national sanctions that reach individuals, which tends to concentrate board attention.

DORA and NIS2: which one applies to you?

DORA is lex specialis for financial entities: on ICT risk management and incident reporting it takes precedence over NIS2. In practice, Romanian financial groups often straddle both regimes — the regulated financial entity answers to DORA, while a technology subsidiary, a shared-services company, or another group entity may fall under NIS2 through GEO 155/2024. Mapping which entity answers to which regime, and where obligations overlap or diverge, is the first structural decision of a group compliance programme.

Where programmes typically have gaps

Eighteen months into application, the recurring weak points we see are consistent:

1. The register of information – incomplete provider inventories, missing contractual data points, and no process for keeping the register current between submission exercises.
2. Incident classification discipline – teams that can respond to incidents but cannot classify them against DORA criteria fast enough to hit the staged reporting deadlines.
3. Contract remediation – legacy ICT contracts without the mandatory DORA provisions, particularly audit and access rights, sub-outsourcing transparency, and exit assistance.
4. Testing that proves something – testing programmes that exist on paper but produce neither remediation traction nor evidence a supervisor would accept.
5. Board ownership – frameworks formally approved but not genuinely understood by the management body that now carries personal accountability for them.

A pragmatic path

Start from criticality, not from documents: identify your critical or important functions and the ICT assets and providers behind them; assess the five pillars against that map; fix the register of information and incident-reporting readiness first (they are the most visible to supervisors); remediate contracts on a risk-ranked schedule; and build the testing programme so each cycle produces validated fixes and evidence. Throughout, keep the management body genuinely engaged — trained, deciding, and documented as doing so.

Where Avencyx can help

Avencyx supports Romanian financial entities across the DORA lifecycle: scoping and gap assessment, ICT risk-management frameworks, the register of information and third-party risk, incident classification and reporting readiness, resilience testing — including penetration testing and adversary simulation — and detection and response with incident response capability behind it. The work is anchored in Avencyx GRC and produces what supervision ultimately asks for: evidence that resilience is real. If DORA is on your board’s agenda, talk to us.

Legal disclaimer

This article is a general overview, not legal advice. Obligations depend on your entity type, designation, and circumstances — verify current requirements against the official texts, your competent authority (BNR or ASF), and qualified counsel.