Author

GOLD

Razvan Alexandru Olaru

GOLD

How to Prepare for DORA and ICT Outsourcing Review in Romania

By Razvan Alexandru Olaru

– posted 1 week ago

How to Prepare for a DORA ICT Third-Party Review in Romania

If you need to prepare for a DORA ICT third-party review in Romania, three questions should drive the work: has each ICT arrangement been mapped to the business functions it supports, and have those functions been classified correctly as critical or important where applicable? Do the contracts contain the baseline and, where relevant, enhanced provisions required by Regulation (EU) 2022/2554? And can you produce, within the period set by the competent authority, the register, assessments, contracts, testing records and governance evidence that support those conclusions? We advise Romanian financial entities and their technology partners on these operational-resilience challenges, and the pattern I see repeatedly is that organisations underestimate the contract-level and governance-level work DORA requires.

This guide walks through a practical DORA ICT third-party review, from building the register of information and assessing the functions supported by each arrangement through to preparing exit strategies and an inspection-ready evidence package. The implementation periods below are a project-management proposal, not statutory DORA deadlines:

Within 30 days: complete a contracts inventory, map ICT services to functions and identify high-risk gaps.
Within 90 days: validate the register of information, prioritise contract remediation and test incident-reporting workflows.
Within 180 days: test proportionate exit and contingency scenarios and assemble the evidence file.

What DORA Requires and the Current Timeline

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It establishes interconnected requirements concerning ICT risk management, ICT-related incident management and reporting, digital operational-resilience testing, ICT third-party risk management and voluntary cyber-threat information sharing. The regulation is supplemented by delegated and implementing acts developed on the basis of mandates given to the European Supervisory Authorities (ESAs)—the EBA, ESMA and EIOPA.

For Romanian institutions, DORA is already applicable. The first register-of-information collection took place in 2025, the ESAs published the first Union list of designated critical ICT third-party service providers (CTPPs) in November 2025, and the first annual ESA overview of major ICT-related incidents was published in June 2026. At national level, Emergency Ordinance No. 14/2026 established Romanian implementation and enforcement measures, including the allocation of responsibilities between competent authorities. These milestones demonstrate active implementation, but they do not, without a specific public statement from the relevant authority, establish that every Romanian entity is currently subject to a thematic or targeted inspection campaign.

Key DORA provisions for ICT third-party reviews

Articles 1–5: subject matter, scope, definitions, proportionality, governance and organisation.
Articles 6–16: the ICT risk-management framework.
Articles 17–23: ICT-related incident management, classification and reporting.
Articles 24–27: digital operational-resilience testing, including threat-led penetration testing (TLPT) for entities selected under the applicable criteria.
Articles 28–30: ICT third-party risk principles, entity-level concentration-risk assessment and contractual requirements.
Articles 31–44: designation and EU-level oversight of CTPPs.
Articles 45–56: information-sharing arrangements, competent authorities, cooperation and enforcement.

Scope and Who Is Affected in Romania

DORA applies to the categories of financial entities listed in Article 2(1), subject to the exclusions and qualifications in Article 2(3)–(4) and the proportionality principle in Article 4. It should therefore not be described as applying, without exception, to every regulated financial entity. The applicable Romanian competent authority depends on the entity’s legal category and existing sectoral supervision, as further reflected in Article 46 DORA and Emergency Ordinance No. 14/2026.

Entity category	Core DORA implications	Romanian supervisory note
Credit institutions, payment institutions and electronic-money institutions	ICT risk management, incident reporting, resilience testing and ICT third-party oversight, subject to the entity-specific DORA regime.	BNR is generally the relevant national authority for entities within its prudential remit; the exact reporting route and entity category must be confirmed.
Insurers, reinsurers and in-scope pension-sector entities	The applicable DORA pillars, with proportionality and any Article 2 exclusions assessed for the particular entity.	ASF is generally the relevant authority for the insurance and private-pensions sectors.
Investment firms, management companies and alternative investment fund managers	ICT risk management, incident reporting, testing and third-party risk obligations, subject to scope and proportionality.	ASF is generally the relevant national authority for capital-markets entities.
Crypto-asset service providers and other specialised entities	DORA applies where the entity falls within Article 2; the competent authority depends on the entity’s authorisation and legal capacity.	Check the allocation under the Romanian implementation framework rather than assuming that one authority supervises every crypto-related entity.

The contract and evidence language should be agreed with the relevant authority and aligned with generally applicable Romanian record-production rules; DORA itself does not create a universal requirement that every institution maintain every record in both Romanian and English.

When to escalate

Romanian entities should maintain a documented protocol for classifying ICT-related incidents, determining whether a DORA report is required and identifying the competent authority and submission channel. A vendor disruption should not automatically be reported merely because the vendor is internally labelled “critical”; the legal trigger is whether the incident meets the applicable DORA classification criteria and thresholds or another reporting obligation applies. Significant control gaps should be escalated internally to the responsible control functions and management body, while notification to BNR, ASF or another authority should follow the applicable legal trigger, supervisory instruction or established engagement protocol.

Contract Mapping and the Register of Information

Article 28(3) requires financial entities to maintain and update, at entity, sub-consolidated and consolidated levels, a register of information covering all contractual arrangements for ICT services provided by ICT third-party service providers. The standard templates are established by Commission Implementing Regulation (EU) 2024/2956. The register is wider than the subset of arrangements supporting critical or important functions, although DORA applies enhanced requirements to that subset.

An effective contract-mapping exercise should:

Centralise direct ICT arrangements. Collect master agreements, orders, service descriptions, SLAs, data-processing terms and amendments. Separately capture ICT subcontracting-chain information required by the applicable templates and by Commission Delegated Regulation (EU) 2025/532 for services supporting critical or important functions.
Extract key terms. Catalogue service scope, locations, data protections, SLAs, incident assistance, cooperation with authorities, termination, access and return of data, training obligations and, for critical or important functions, enhanced service levels, contingency, audit and exit provisions.
Map dependencies. Link each ICT service to the financial entity’s functions and identify concentration, substitutability, security, location and continuity risks.
Populate and validate the official templates. Use the fields and data relationships in Regulation 2024/2956; a local spreadsheet or the illustrative working table below is not a substitute for those templates.

Illustrative working field	Description	Typical owner
Provider identity	Legal name and the identifier required or permitted by the official template, such as LEI, EUID or another permitted code	Procurement / Legal
ICT service	ICT service type, scope and supplying entity	IT / Architecture
Supported function	Function supported and whether it is assessed as critical or important	Risk / Compliance / Business owner
ICT subcontracting chain	Relevant ICT subcontractors, functions or services subcontracted and locations, to the depth required by the applicable rules	Procurement / Vendor management
Service and data locations	Countries or regions where services are delivered and data is processed or stored	IT Security / DPO / Legal
Service levels and recovery	Contractual service levels, RTO/RPO and continuity dependencies where relevant	IT Operations
Exit information	Termination rights, data return, transition assumptions and exit-plan reference	Legal / Business continuity
Audit and assurance	Contractual access, inspection and audit rights and available independent assurance	Internal Audit / Legal
Contract lifecycle	Effective date, expiry, renewal and notice periods	Procurement
Contacts and ownership	Internal owner and provider operational or escalation contacts	Vendor Management

Critical or important functions: use an internal matrix carefully

An internal scoring model may help prioritise work by considering continuity impact, data sensitivity, substitutability and concentration risk. However, it does not replace the legal assessment under Article 3(22), and it should not be used to create a legally misleading category of “critical vendors.” Under DORA, the financial entity determines whether a function is critical or important and then maps the ICT service supporting it. The separate label “CTPP” applies only when an ICT third-party service provider has been designated at Union level by the ESAs under Article 31 (or accepted through the statutory opt-in mechanism).

Accordingly, a 1-to-5 score may be retained as a supplementary prioritisation tool, provided the methodology separately records: the function assessed; the potential material impairment to financial performance, continuity, soundness of services or regulatory compliance; the supporting evidence; the accountable approver; and the review trigger. Avoid treating the numerical total as the legal conclusion.

CTPP Oversight and Entity-Level Vendor Assessment

Financial entities do not designate CTPPs. The ESAs perform that designation using the Article 31 criteria and the supplementary framework, and they published the first official Union list in November 2025. A financial entity should check whether a provider is on the current list and understand the implications of EU-level oversight, but CTPP status does not replace the entity’s own obligations under Articles 28–30. Conversely, a provider that is not designated as a CTPP may still support a critical or important function and require enhanced due diligence, contractual safeguards, monitoring and an exit strategy.

The Article 31 designation criteria concern, in substance, the potential systemic impact of a large-scale provider failure, the systemic character or importance of the financial entities relying on the provider, their reliance on its services for critical or important functions, and the degree of substitutability. Provider access to sensitive data may be relevant to the entity’s risk assessment, but it should not be presented as a standalone statutory CTPP designation criterion.

Due-diligence steps

Security posture: evaluate relevant certifications, assurance reports, testing evidence and vulnerability-management arrangements. SOC 2 or ISO/IEC 27001 evidence may support the analysis but is not mandated for every provider and does not by itself prove DORA compliance.
Service architecture: map infrastructure dependencies, redundancy, recovery capabilities and alignment between provider commitments and the entity’s own recovery objectives.
ICT subcontracting chain: identify and assess the subcontracting of services supporting critical or important functions in accordance with Regulation 2025/532, including material changes and concentration or location risks.
Financial and operational viability: assess whether the provider can perform the service over the expected term and support continuity and exit obligations.
Contractual gap analysis: compare the contract against Article 30(2) and, where the service supports a critical or important function, Article 30(3). DORA requires location transparency and advance notice of intended changes; it does not impose a universal rule that all processing remain in a particular country.

Auditability, Monitoring, Logging and Incident Reporting

DORA requires mechanisms to detect anomalous activities and ICT-related incidents and to manage, classify and report them. The financial entity must be able to demonstrate that its monitoring arrangements operate in practice. Contracts for ICT services supporting critical or important functions must include the enhanced cooperation, monitoring and audit provisions required by Article 30(3), while all ICT contracts must include the baseline provisions in Article 30(2).

DORA does not prescribe a universal 12-month log-retention period for every operational log, nor does it require unrestricted customer access to every provider log. Logging scope, access method and retention should be set by reference to the entity’s ICT risk framework, incident-investigation needs, sectoral and data-protection rules, contractual audit rights, security constraints and the provider’s multi-customer environment. The contract should nevertheless ensure timely access to information reasonably necessary for monitoring, investigation, audit and supervisory cooperation.

ICT incident reporting: flow, timing and content

An ICT-related incident is, in summary, a single event or series of linked events unplanned by the financial entity that compromises the security of network and information systems and adversely affects the availability, authenticity, integrity or confidentiality of data or the services provided by the financial entity. Reporting is mandatory when the incident is classified as major under Article 18 and Commission Delegated Regulation (EU) 2024/1772.

Under Commission Delegated Regulation (EU) 2025/301, the current reporting sequence for a major ICT-related incident is:

initial notification: as early as possible, within four hours after classification as major and no later than 24 hours after the financial entity became aware of the incident;
intermediate report: no later than 72 hours after the initial notification, even if status or handling has not changed, with updated reports where required; and
final report: no later than one month after the latest updated intermediate report, subject to the detailed rule in Article 5.

The forms and procedures are prescribed by Commission Implementing Regulation (EU) 2025/302. Vendor contracts should therefore require notification and progressive information sharing early enough for the financial entity to meet these deadlines; DORA does not impose a single statutory vendor-to-customer notification period suitable for every contract.

An internal reporting file should capture the incident summary, affected services, classification analysis, impact metrics, timeline, preliminary and final root cause, remediation, communications and lessons learned, using the mandatory regulatory template for the actual submission.

Exit Strategies, Termination, Continuity and Data Portability

Article 28(8) requires exit strategies for ICT services supporting critical or important functions. Exit plans must be comprehensive, documented, sufficiently tested and periodically reviewed, with the frequency calibrated under proportionality. DORA does not require annual service-transfer testing in every case, nor does it mandate source-code escrow for every proprietary service.

A robust exit strategy should address the circumstances in which exit may be required, alternative solutions, transition responsibilities, realistic timing, continuity during migration, data access and return, security, ICT subcontracting dependencies, concentration and substitutability risks, and success criteria for testing. Data formats, configuration materials and cryptographic-key arrangements should be included only where necessary for a feasible exit and where the provider is entitled and technically able to supply them. Escrow may be appropriate for particular proprietary systems but is a negotiated control, not a universal DORA requirement.

Illustrative contract clauses

The following clauses are negotiation starting points, not DORA safe harbours; bracketed periods must be calibrated to the service and exit plan:

Exit assistance: “Upon termination or expiry of this Agreement, Provider shall provide the transition assistance described in the Exit Schedule for up to [period] at the charges agreed in advance, while maintaining the service levels stated in that Schedule and reasonably cooperating with Client and any authorised successor provider.”
Data return: “Within [period] after the applicable termination or migration milestone, Provider shall make Client Data available in the documented machine-readable format and provide the configuration information and keys, if any, identified in the Exit Schedule and lawfully controlled by Provider. Provider shall delete or place remaining copies beyond use in accordance with the agreed retention and backup schedule, subject to applicable law, and shall provide the agreed certification.”
Audit rights: “Client, its designated auditor and each competent or resolution authority shall have the access, inspection and audit rights required by applicable law in relation to the relevant services. Routine Client audits shall be subject to [notice] and proportionate confidentiality, security and non-disruption safeguards; no contractual notice or frequency restriction shall apply to the extent incompatible with a competent authority’s powers or instructions.”

For every arrangement supporting a critical or important function, maintain evidence that the exit strategy has an accountable owner, has been reviewed under the approved governance framework, has been tested to a proportionate extent and has been updated after material changes. DORA places ultimate responsibility for the ICT risk-management framework on the management body, but it does not necessarily require the board to approve every vendor-level exit plan individually.

Governance, Roles and Evidence

Article 5 assigns the management body responsibility for defining, approving, overseeing and being accountable for the ICT risk-management framework. The management body must maintain appropriate knowledge and receive the information necessary to exercise that responsibility. The specific committee structure remains an organisational choice unless another applicable rule requires it.

A dedicated third-party risk committee may be useful for complex institutions, but DORA does not universally require such a committee or quarterly meetings. If established, its mandate should cover onboarding decisions, monitoring, exceptions, remediation, exit readiness and escalation, with reporting to the management body at a frequency proportionate to risk.

Illustrative evidence checklist

The following is an operational checklist, not a statement of the minimum documents BNR or ASF will request in every inspection:

the approved ICT risk-management framework and evidence of review at the legally required frequency;
the current, validated register of information in the official format;
documented critical-or-important-function assessments and dependency mapping;
the contract gap analysis, amendment tracker and approved exceptions;
incident-classification files and submitted reports, where applicable;
resilience-testing results, including TLPT only where the entity is selected or otherwise required to perform it;
exit strategies and proportionate testing evidence for arrangements supporting critical or important functions;
management-body and relevant committee materials demonstrating oversight;
relevant provider assurance and audit reports, without imposing an unsupported universal 24-month look-back; and
training records for personnel with ICT risk and control responsibilities.

Practical Implementation Plan

The following phases are suggested implementation milestones and should be shortened or extended according to the institution’s risk, existing gaps and supervisory commitments.

Phase 1: Days 1–30 — discovery and triage

Inventory all direct ICT contracts and relevant ICT subcontracting-chain information. Owner: Procurement + Legal.
Map ICT services to functions and perform a preliminary critical-or-important-function assessment. Owner: Business + Risk / Compliance.
Identify missing Article 30 clauses and register-data gaps. Owner: Legal + Data owner.
Confirm the competent authority and current reporting channels. Owner: Compliance.

Phase 2: Days 31–90 — remediation and documentation

Populate and validate the register against Regulation 2024/2956. Owner: IT + Compliance.
Prioritise amendments for arrangements supporting critical or important functions. Owner: Legal + Procurement.
Test incident classification and the 4-hour / 24-hour / 72-hour reporting workflow through a tabletop exercise. Owner: IT Security + Compliance.
Report material status, risks and accepted exceptions to the management body. Owner: CISO / CRO.

Phase 3: Days 91–180 — testing and assurance

Test proportionate exit scenarios for ICT services supporting critical or important functions. Owner: IT Operations + Business Continuity + Legal.
Perform the applicable digital operational-resilience testing programme. Owner: IT Security.
Assemble and quality-check the inspection-ready evidence file. Owner: Compliance.
Obtain approval or acknowledgement at the level required by the governance framework. Owner: Board Secretary / CRO.

Red flags requiring prompt internal escalation include an undisclosed material ICT subcontracting change, a provider’s refusal to agree legally required audit or authority-cooperation rights, an unnotified service or data-location change, a register inconsistency that obscures a material dependency, or the absence of a feasible exit route for a service supporting a critical or important function. External notification should occur when a legal reporting threshold, supervisory instruction or established authority-engagement protocol requires it.

Conclusion and Next Steps

The institutions best positioned for DORA review are those that treat the regulation as an ongoing operational discipline rather than a one-time contract-remediation exercise. The most useful immediate actions are to map each ICT arrangement to the functions it supports, document the critical-or-important-function analysis, validate the register against the official templates and perform a tiered Article 30 contract review. Governance, incident workflows, testing, exit strategies and evidence should then be built on that verified data spine.

For Romanian entities navigating these requirements, the Technology practice area and the directory of Romania, Technology lawyers may be starting points for identifying specialist guidance.

Need Legal Advice?

For specialist advice on this topic, contact Razvan Alexandru Olaru at Olawru.

Sources

FAQs

Does DORA apply to every regulated financial entity in Romania?

No. DORA applies to the categories listed in Article 2(1), subject to the express exclusions and qualifications in Article 2(3)–(4), while proportionality under Article 4 affects how certain requirements are implemented. The institution should confirm its precise legal category, any group-level implications, the applicable framework and its competent authority rather than relying on a generic label such as “regulated entity.”

What is the difference between a critical or important function, a high-risk vendor and a CTPP?

A critical or important function is a function of the financial entity whose disruption would materially impair specified aspects of its performance, services or regulatory compliance under Article 3(22). “High-risk vendor” may be a useful internal risk-management label but is not a defined DORA status. A CTPP is an ICT third-party service provider designated at Union level by the ESAs under Article 31. An institution does not create CTPP status through its internal scoring model.

Must the register include only providers supporting critical or important functions?

No. Article 28(3) covers all contractual arrangements for the use of ICT services supplied by ICT third-party service providers. The official structure and data relationships are prescribed by Regulation 2024/2956. The critical-or-important-function classification remains essential because it triggers enhanced due diligence, contractual, monitoring, subcontracting and exit requirements.

Which clauses are required in a DORA ICT contract?

Article 30(2) establishes baseline terms for all in-scope ICT arrangements, including service description, subcontracting conditions, locations, data protections, data access and return, service levels, incident assistance, authority cooperation, termination and training conditions. Article 30(3) adds enhanced terms for services supporting critical or important functions, including detailed service levels, notice and reporting duties, contingency and security measures, participation in testing, monitoring and audit rights, and exit arrangements. The clause set must be calibrated to the actual service; a generic “DORA compliance” warranty is insufficient.

What are the DORA deadlines for reporting a major ICT-related incident?

Under Regulation 2025/301, the initial notification is due as early as possible, within four hours after classification as major and no later than 24 hours after awareness. The intermediate report is due within 72 hours after the initial notification, even if there has been no change. The final report is due within one month after the latest updated intermediate report, subject to the detailed Article 5 rules. These are financial-entity-to-authority deadlines; the vendor contract should set an earlier, workable notification and information-sharing process.

Does DORA require annual exit tests, source-code escrow or a 12-month transition period?

Not universally. Article 28(8) requires comprehensive, documented exit plans for ICT services supporting critical or important functions, sufficiently tested and periodically reviewed under proportionality. It does not impose one annual frequency, universal escrow or a fixed transition period. Those controls may be appropriate for a particular service, but the contract and exit plan should justify them through criticality, substitutability, migration complexity and continuity requirements.

Who supervises DORA compliance in Romania?

The answer depends on the entity category. BNR is generally relevant for institutions within its prudential remit, while ASF generally supervises capital-markets, insurance and private-pensions entities. Article 46 DORA and Emergency Ordinance No. 14/2026 should be checked for the particular entity, including specialised or dual-capacity cases. Incident reports and registers should be submitted through the current channel specified by the competent authority.