Regulation (EU) 2022/2554 has applied directly since 17 January 2025. What Romania lacked was the national frame: who supervises, who sanctions and — for the testing part — who coordinates. Emergency Ordinance nr. 14/2026, published in Monitorul Oficial nr. 188 of 11 March 2026 and in force from publication, settled that.
One element in the ordinance genuinely changes how testing gets planned in the Romanian financial sector: the National Bank of Romania is designated the single national public authority responsible for coordinating threat-led penetration tests. Not only for the entities it supervises. Also for those supervised by ASF.
Supervision runs on two tracks, testing on one
The ordinance splits prudential supervision by entity category:
- BNR — credit institutions, payment institutions, electronic money issuers, development banks, central depositories and administrators of critical benchmarks.
- ASF — investment firms, insurance and reinsurance undertakings, investment fund and occupational pension administrators, insurance intermediaries and crowdfunding service providers.
For TLPT the two tracks merge. An ASF-supervised insurer identified for TLPT coordinates its test through BNR, and BNR issues the attestation. This is exactly the option Article 26(9) of DORA leaves open to Member States: "Member States may designate a single public authority in the financial sector to be responsible for TLPT-related matters at national level." Romania took it.
The practical consequence for a compliance lead at an insurer: your counterpart on test scope is not the authority that supervises your solvency. These are two separate institutional relationships with two separate calendars, and in the first one you are probably an unfamiliar name.
Who actually has to do TLPT
Not everyone. This is where the most wasted effort goes.
TLPT applies to entities identified by the competent authority, not to every financial entity. The criteria in DORA and in the regulatory technical standards track three axes: systemic character (size, market share, interconnectedness), ICT risk profile (threat landscape, detection and response maturity, incident history) and criticality of services — payment, clearing and settlement functions above all. Global systemically important institutions are in automatically. A niche insurer with a simple ICT estate very likely is not.
If you have not been identified, you are not obliged to run a TLPT. You remain obliged to the testing programme in Article 24 — vulnerability assessments, penetration tests, continuity testing — and that is a standing requirement, not an optional one.
Where a penetration test ends and a TLPT begins
The difference is not difficulty. It is scope, target and who knows in advance.
An ordinary penetration test has a perimeter you define, an agreed window, an informed internal team and a technical objective: find the vulnerabilities in the application, network or API in scope.
A TLPT has six properties a classic pentest does not:
- It runs against live production systems. Article 26(2) is explicit — testing is performed on live production systems. No test-environment substitution.
- Scope is built from critical or important functions, not from assets. You start with what you cannot afford to lose and work down to the systems supporting it, including outsourced ones.
- Threat intelligence comes from an independent external provider, which cannot be affiliated with the red team or with the entity being tested. That independence has no exceptions, not even when the red team is internal.
- The blue team does not know. The test measures detection and response, not merely whether a breach is possible. Only the white team — a small, formally named group — is aware.
- ICT providers participate. Article 26(3) requires the entity to take the measures needed to ensure third-party providers take part, while retaining full responsibility for compliance. Paragraph (4) allows pooled testing where direct participation would harm service quality or data confidentiality.
- It closes with a report to the authority and an attestation. Article 26(7) provides that the authority issues the entity an attestation confirming the test was performed in accordance with the requirements — the mechanism that makes mutual recognition between Member States possible.
That last point is also the commercial argument many teams miss: a TLPT done properly in one Member State is not repeated in another. A test done outside the framework is.
Reading the three-year cycle correctly
Article 26(1) requires TLPT at least every three years, with competent authorities able to adjust the frequency according to risk profile.
Three years sounds generous until you count backwards. A full cycle has five phases — scoping, threat intelligence production, red team testing, purple teaming, and closure with remediation — and typically runs for several months. Add negotiating scope with BNR, contracting two separate providers, and securing agreement from the ICT providers who must take part, and the three-year window becomes annual planning rather than a triennial event.
One rule that regularly surprises people: the red team may be internal for at most two of every three cycles — the third test must use an external red team. Threat intelligence must always come from outside, whichever red team you use.
The relationship with TIBER-EU
The regulatory technical standards for TLPT were built to be compatible with the TIBER-EU framework, and the TIBER guides — for the white team, for threat intelligence and for the red team — have been aligned to DORA. In practice: if you ran a TIBER-EU test after 17 January 2025 and it met the RTS requirements, it can satisfy the TLPT obligation.
That matters for groups operating across several Member States. It does not matter much for a Romanian entity facing its first test, where the question is simply whether the providers you contract can work inside the required framework.
Five questions before signing anything
If you have reason to think you fall in the identifiable population for TLPT:
- Has anyone identified us? If not, do not contract a TLPT. Contract the Article 24 testing programme and a serious inventory of critical functions.
- Do we have an approved list of critical or important functions with the systems supporting them? Without it, scoping stalls in the first meeting.
- Who is the white team and who must not know? Decide it in writing before any conversation with providers.
- Do contracts with critical ICT providers permit testing? If the clause is missing, renegotiation takes longer than the test.
- Are the threat intelligence provider and the red team independent of each other? A single vendor offering both does not meet the requirement, however good the proposal looks.
A TLPT is not a more expensive pentest. It is a resilience exercise where the real target is your own detection capability, and the measurable outcome is not a vulnerability count but how far the red team got before anyone noticed. If the answer to question 2 does not exist yet, a risk and compliance assessment is the step to take first — and penetration testing under Article 24 remains mandatory whether or not you ever reach TLPT.
The ICT provider register the ordinance presupposes is a separate subject, covered in the article on the DORA register of information.