DORA Compliance Romania 2026: Practical Playbook for Banks, Fintechs and ICT Providers

DORA compliance Romania is now a live supervisory priority rather than a theoretical obligation, and 2026 marks the first full supervisory cycle in which Romanian banks, non-bank financial institutions, insurers, investment firms and their ICT providers must produce audit-ready evidence on demand. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied directly across the European Union since 17 January 2025, and the supervisory emphasis has shifted decisively from “do you have a policy? ” to “show me the evidence it works. ” For financial services Romania entities, this means risk registers, incident logs, third-party oversight documentation and resilience test reports must be organised, versioned and defensible.

This playbook translates the regulation into a Romania-specific implementation path, mapping key DORA obligations to the likely expectations of the Banca Naţională a României (BNR) and the Autoritatea de Supraveghere Financiară (ASF).

This article reflects the advisory perspective of a regulatory compliance and internal-audit specialist on operational resilience. It explains the applicable law and rules objectively and provides practitioner guidance; it is not legal advice.

Executive summary, what Romanian financial entities must do in 2026

The core message for 2026 is that supervisors now expect proof of operational capability, not just documented intent. DORA compliance Romania rests on five interlocking pillars under Regulation (EU) 2022/2554: ICT risk management, incident classification and reporting, digital operational resilience testing, ICT third-party risk management, and information-sharing arrangements. Each pillar generates evidence, and it is the quality and traceability of that evidence that determines whether a supervisory review goes smoothly.

The immediate priorities for most Romanian financial entities fall into three areas. First, incident reporting readiness, a defined classification methodology, notification workflows and tested contact lines with national bodies. Second, third-party risk management (TPRM), a complete register of ICT outsourcing arrangements, due diligence files and contractual clauses for critical providers. Third, ICT risk evidence, an enterprise-wide ICT risk register integrated with internal audit and reported to the management body.

The supervisory lens for 2026 is practical and evidence-driven. BNR and ASF, as the competent authorities for their respective sectors, will look for governance ownership at board level, a documented risk-management framework, and the ability to retrieve dated artefacts quickly. Entities that treat DORA as a one-off documentation exercise will struggle; those that embed it into existing risk, audit and procurement processes will find the 2026 cycle manageable.

Quick compliance checklist

• Governance. Board-approved ICT risk management framework with a named accountable owner and a reporting cadence to the management body.
• ICT risk register. Enterprise-wide, current, with control owners, risk ratings and links to internal audit findings.
• Incident process. Classification methodology, internal escalation matrix and tested national reporting channels.
• Outsourcing register. Complete register of all ICT third-party arrangements, flagging those supporting critical or important functions.
• Contractual controls. DORA-aligned clauses in contracts with ICT providers, audit rights, data access, service levels and exit arrangements.
• Resilience testing. A documented testing programme with scope, results and remediation tracking.
• Evidence retention. Versioned, dated artefacts retrievable on short notice for supervisory review.

What is DORA and who must comply in Romania?

The Digital Operational Resilience Act is a directly applicable EU Regulation, Regulation (EU) 2022/2554, designed to consolidate and harmonise ICT risk requirements across the European financial sector. Before DORA, operational resilience expectations were fragmented across sectoral directives and national guidance. DORA creates a single rulebook so that a bank, an insurer and an investment firm are held to comparable standards of digital operational resilience, with proportionality calibrated to size and risk profile. The European Commission has positioned DORA as a cornerstone of the EU’s broader digital finance strategy, and DORA is accompanied by an amending directive, Directive (EU) 2022/2556, that aligns existing sectoral legislation.

DORA in brief, the key articles to know

Four thematic blocks of the Regulation drive most practical work:

• ICT risk management (Chapter II). Requires a sound, comprehensive and well-documented ICT risk management framework, under the responsibility of the management body, covering identification, protection, detection, response and recovery.
• ICT-related incident management, classification and reporting (Chapter III). Requires entities to establish a management process to monitor and log ICT-related incidents, classify them against defined criteria, and report major incidents to the competent authority within the timelines set by the Regulation and the relevant technical standards.
• Digital operational resilience testing (Chapter IV). Requires a testing programme proportionate to the entity, with advanced threat-led penetration testing for certain entities.
• ICT third-party risk (Chapter V). Requires management of ICT third-party risk as an integral part of the ICT risk framework, including a register of information on contractual arrangements and specific contractual requirements, plus an EU-level oversight framework for critical ICT third-party providers.

Entities in Romania covered by DORA

DORA applies to a broad range of financial entities operating in Romania. In the banking and payments sphere, supervised by BNR, this includes credit institutions, payment institutions, electronic money institutions and certain non-bank financial institutions. On the capital markets and insurance side, supervised by ASF, this includes investment firms, insurance and reinsurance undertakings, certain insurance intermediaries and asset managers. Crypto-asset service providers authorised under the EU markets-in-crypto-assets framework also fall within DORA’s scope. Finally, ICT third-party service providers supporting these entities are drawn into the regime indirectly through contractual obligations, and critical ICT third-party providers can be subject to direct EU-level oversight.

For any firm in financial services Romania, the practical first question is not whether DORA applies, but how proportionately its requirements map to the firm’s scale and criticality.

Mapping DORA requirements to Romanian supervisors (BNR and ASF)

Because DORA is a Regulation, its substance applies uniformly. What varies is the supervisory lens through which it is examined. In Romania, two competent authorities carry primary responsibility: Banca Naţională a României (BNR) for credit institutions and payments entities, and Autoritatea de Supraveghere Financiară (ASF) for insurers, investment firms and other capital-markets participants. Both operate within the harmonised framework shaped by the European Supervisory Authorities, the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA) and the European Insurance and Occupational Pensions Authority (EIOPA), whose technical standards and guidelines give practical texture to DORA’s articles.

Effective DORA compliance Romania therefore means reading the Regulation alongside the applicable regulatory technical standards and the expectations each national supervisor signals through its own guidance and inspections.

Banks (BNR), supervisory focus areas

For credit institutions and payment entities, BNR supervision typically emphasises enterprise-wide integration. Supervisors will want to see that the ICT risk management framework is not a standalone IT document but is woven into the institution’s overall risk governance, internal control functions and internal audit plan. Expect attention to the maturity of the ICT risk register, the independence and coverage of internal audit over ICT, the robustness of business continuity and disaster recovery arrangements, and demonstrable board engagement. Incident reporting readiness and the completeness of the outsourcing register are perennial focus points, reflecting the EBA’s long-standing attention to outsourcing and ICT risk in the banking sector.

Insurers and investment firms (ASF), supervisory focus areas

For ASF-supervised entities, the supervisory emphasis follows ESMA’s and EIOPA’s framing of operational resilience in capital markets and insurance. Investment firms should expect scrutiny of resilience testing proportionate to their systemic relevance, the integrity and availability of trading and client-facing systems, and the management of concentration risk in ICT outsourcing. Insurers should anticipate attention to continuity of critical policy-administration and claims systems, data integrity, and the oversight of third parties supporting core insurance functions. Across both, ASF will look for the same evidentiary discipline: dated artefacts, clear ownership and a credible testing and remediation trail.

Building an audit-ready DORA compliance program in Romania

The difference between a firm that passes a 2026 supervisory review comfortably and one that scrambles is almost always organisation, not effort. An audit-ready programme is one where governance, policy, evidence and testing are connected so that any claim made to a supervisor can be substantiated with a dated artefact. Approaching DORA compliance Romania as a programme, with a roadmap, owners and a reporting cadence, avoids the common failure mode of scattered documentation that cannot be retrieved under pressure.

Program structure and a 6–12 month implementation roadmap

Governance comes first. The management body carries ultimate responsibility for the ICT risk framework under DORA, so the programme should begin with a board-approved charter that names accountable executives, commonly spanning the risk, technology and operations functions, and sets a reporting cadence to the board. Internal audit should be positioned to provide independent assurance over ICT risk rather than being the owner of controls.

A pragmatic twelve-month roadmap runs in four phases. In the first phase (months one to three), conduct a gap assessment against each DORA chapter, inventory ICT assets and third-party arrangements, and stand up the ICT risk register. In the second phase (months three to six), finalise policies, build the register of information and begin renegotiating critical contracts. In the third phase (months six to nine), operationalise the incident process end to end and run the first resilience tests. In the final phase (months nine to twelve), remediate findings, assemble the supervisor-ready evidence pack and rehearse a mock supervisory review.

Policies and procedures to prioritise

Not all documentation carries equal weight. The policies most frequently examined, and therefore the ones to prioritise, are:

• ICT risk management policy. The overarching framework document describing identification, protection, detection, response and recovery, with explicit links to the risk register and risk appetite.
• Incident response and reporting procedure. Classification criteria, escalation matrix, notification templates and the national reporting workflow.
• ICT third-party risk and outsourcing policy. Criticality assessment, due-diligence standards, the register process and contractual minimum requirements.
• Change and patch management procedure. Controls over software changes, patching cadence and emergency-change handling, which supervisors increasingly probe as a root cause of incidents.
• Business continuity and ICT recovery plan. Recovery objectives, dependency mapping and tested recovery procedures.

Evidence retention and versioning

Supervisors assess the control as it operated at a point in time, so version control and dating are not administrative niceties, they are evidentiary necessities. Maintain a single evidence repository with clear naming conventions, version histories and approval dates. For each control, keep the policy version in force at the relevant time, the records showing it operated (logs, tickets, minutes), and the independent assurance over it (audit or test reports). When a supervisor asks for “the ICT risk register as at a given quarter,” a mature programme can produce the exact historical export rather than only the current state. This evidentiary discipline is the backbone of credible DORA compliance Romania and the single biggest differentiator in supervisory reviews.

ICT risk management, controls, evidence and testing

ICT risk management Romania practitioners should treat Chapter II of DORA as the foundation on which incident reporting, testing and third-party oversight all rest. The framework must be comprehensive, documented and proportionate to the entity, and it must be reviewed and updated in line with the Regulation’s requirements, including following major incidents. Translating the Regulation into day-to-day controls means operationalising a familiar set of security and resilience capabilities, then generating evidence that each is functioning.

The core controls that supervisors expect to see operating include:

• Asset inventory. A current inventory of ICT assets, their business criticality and their interdependencies, including those supporting critical or important functions.
• Vulnerability and patch management. Regular scanning, risk-based prioritisation and timely remediation, with an auditable patch cadence.
• Access controls. Least-privilege access, strong authentication, privileged-access management and periodic access recertification.
• Logging and monitoring. Centralised logging, anomaly detection and alerting that feed the incident process.
• Backup and recovery. Tested backups, defined recovery time and recovery point objectives, and periodic restoration tests.

Minimum evidence pack for ICT risk

For each control area, assemble a minimum evidence pack that an internal auditor, or a supervisor, could review without additional explanation. This typically includes: the current and historical ICT risk register exports; the asset inventory with criticality ratings; vulnerability scan reports and the remediation tracker; access recertification records; sample system logs demonstrating monitoring; and backup-restoration test results. Each artefact should be dated and attributable to a named owner.

Frequency and sample sizes for testing

DORA requires resilience testing proportionate to the entity’s size, risk profile and criticality. Most entities run a baseline programme of vulnerability assessments and scenario-based tabletop exercises on a regular basis, with larger or more critical entities performing more frequent and more advanced testing, including threat-led penetration testing where the Regulation and national supervisor require it. When documenting tests, record the scope, methodology, sample sizes, findings, severity ratings and the remediation timeline, and retain evidence of the retest that confirms closure. A test without documented remediation is, from a supervisory standpoint, an unresolved finding.

Incident reporting and classification under DORA, practical steps for Romania

Incident reporting is where DORA compliance Romania most often meets real-world pressure, because the clock starts the moment an incident is detected. Under Chapter III, financial entities must classify ICT-related incidents against defined criteria, such as the number of clients affected, data losses, duration, geographical spread and economic impact, and report those meeting the major-incident threshold to the competent authority. The regime contemplates a staged reporting flow: an initial notification, followed by an intermediate report as the situation develops, and a final report with root-cause analysis once the incident is resolved. Entities should also coordinate with national cyber-incident channels; in Romania the national cybersecurity authority is the Directoratul Naţional de Securitate Cibernetică (DNSC).

Incident report template, fields and minimum attachments

An advisory incident report template should capture, at minimum: a unique incident reference; detection date and time; classification against the DORA criteria with the supporting rationale; affected systems, services and clients; data impact; estimated economic impact; chronology of events; actions taken; and current status. Minimum attachments should include the incident timeline, log extracts, the classification worksheet and copies of any notifications sent to the competent authority and to national bodies. Where reporting templates are prescribed by the applicable technical standards, those should be used. This template is an advisory tool and should be reviewed before use; it is not legal advice.

Escalation matrix and communications

Speed depends on knowing who decides what. A clear escalation matrix should define the thresholds at which an incident moves from operational handling to management and board attention, who authorises external notifications, and who owns communications with the supervisor, with the DNSC, with affected customers and, where relevant, with the media. Pre-approved communication templates and a tested contact list reduce decision latency during a live event. Rehearsing this matrix in a tabletop exercise is one of the highest-value preparation activities a firm can undertake before 2026.

Third-party risk, outsourcing registers and contractual clauses

Third-party risk under DORA is one of the most scrutinised areas, reflecting the concentration of financial services on a relatively small set of ICT providers. Chapter V requires entities to manage ICT third-party risk within their overall framework, to maintain a register of information on all contractual arrangements for the use of ICT services, and to ensure contracts contain specified provisions. It also establishes an EU-level oversight framework under which ICT providers designated as critical can be subject to direct oversight by a lead overseer. For outsourcing compliance Romania purposes, the practical work is identifying which arrangements support critical or important functions, documenting due diligence, monitoring performance continuously, and ensuring contracts give the entity the rights it needs.

Register of information, required fields

The register of information should be maintained as structured data so it can be filtered and reported to supervisors in the prescribed format. Recommended fields for a register template include:

• Provider identity. Legal name, identification code (such as LEI where applicable), and group affiliation.
• Service description. Nature of the ICT service and the business function it supports.
• Criticality flag. Whether the arrangement supports a critical or important function.
• Contract references. Contract start date, renewal or end date, and notice periods.
• Data and location. Data categories processed and the country of data storage and processing, including subcontracting chains.
• Risk assessment. Latest due-diligence date, risk rating and concentration-risk notes.
• Exit arrangements. Whether a documented exit strategy exists and when it was last tested.

Draft contractual clauses to require

At a high level and on an advisory basis, contracts with ICT providers supporting critical or important functions should secure: clear service-level descriptions and performance targets; audit and access rights for the entity, its auditors and the competent authority; data access, availability and security obligations; incident-notification obligations aligned to the entity’s own reporting duties; provisions on subcontracting and chain transparency; and robust termination and exit-support arrangements. These points describe what DORA expects a contract to address; they are advisory and should be adapted and reviewed before use, and do not constitute legal advice.

Testing, threat intelligence and cyber resilience exercises

Resilience testing turns paper controls into proven capability. A balanced programme combines tabletop exercises that stress decision-making and communications, technical penetration testing that probes defences, and ICT continuity tests that validate recovery objectives. For entities within scope of advanced testing, threat-led penetration testing simulates realistic adversary behaviour and is a demanding but highly persuasive piece of evidence. Whatever the mix, each exercise should be documented with scope, participants, findings and a remediation plan, and the outcomes should be summarised in board reporting so that the management body can demonstrate oversight. Linking test results to the ICT risk register closes the loop between testing and risk management.

Common supervisory findings in early DORA cycles and a remediation playbook

Early supervisory engagement across the EU has surfaced recurring weaknesses. The most common findings, and quick remediation steps, include:

• Incomplete register of information. Remediate by reconciling the register against procurement and finance records to capture every ICT arrangement, including intra-group services.
• Weak incident evidence. Remediate by standardising the incident template and retaining full timelines, logs and notification copies for every reportable event.
• Policy-practice gap. Remediate by evidencing that documented controls actually operate, tickets, minutes and logs, not just policies.
• Unclear governance ownership. Remediate by formalising accountable owners and the board reporting cadence in a charter.
• Untested continuity plans. Remediate by running and documenting a recovery test with defined objectives.
• Missing contractual rights. Remediate by prioritising renegotiation of critical-provider contracts to secure audit, data and exit rights.

Practical templates and annexes for DORA compliance Romania

To accelerate implementation, this playbook is designed to be accompanied by a set of advisory assets: an incident report template capturing the DORA classification criteria and minimum attachments; a register-of-information template with the required fields set out above; an evidence checklist covering ICT risk, incident reporting and testing; and a sample board report structure for operational resilience. Each asset is an advisory master copy labelled for review before use and should be adapted to the entity’s circumstances and signed off before deployment. They are tools to support implementation, not substitutes for legal or regulatory advice.

Next steps and recommended timeline for Romanian entities

For firms still consolidating their programme, a prioritised timeline keeps momentum. Within 90 days, complete a gap assessment, stand up the ICT risk register and reconcile the register of information. Within 180 days, finalise priority policies, operationalise the incident process and begin renegotiating critical contracts. Within 360 days, complete resilience testing, remediate findings and rehearse a mock supervisory review. Treating DORA compliance Romania as an embedded programme rather than a one-off exercise is the surest route to a confident 2026 supervisory cycle, and specialist advisory support can accelerate the harder steps. For broader support, see the Financial Services, Romania practice area and the GLE adviser directory, Romania, Financial Services.

Sources

1. EUR-Lex, Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554)
2. European Commission, Finance (DORA / digital finance)
3. European Banking Authority (EBA)
4. European Securities and Markets Authority (ESMA)
5. European Insurance and Occupational Pensions Authority (EIOPA)
6. Banca Naţională a României (BNR)
7. Autoritatea de Supraveghere Financiară (ASF)
8. Directoratul Naţional de Securitate Cibernetică (DNSC)