DORA și TLPT: ce testare cere reziliența operațională digitală în sectorul financiar
Din 17 ianuarie 2025, supraveghetorul financiar nu mai întreabă dacă ai controale, ci dacă ai demonstrat că serviciul critic supraviețuiește unui atac real. Ghid practic pentru bănci, fintech-uri, asigurători și furnizorii lor de tehnologie.

Din 17 ianuarie 2025, Regulamentul (UE) 2022/2554 privind reziliența operațională digitală — DORA — se aplică direct în toate statele membre, fără transpunere națională. Iar asta schimbă întrebarea pe care și-o pune un supraveghetor financiar: nu mai este „aveți controale de securitate?", ci „ați demonstrat că serviciul critic supraviețuiește unui atac real?". Diferența nu este semantică. Ea are consecințe directe asupra felului în care se planifică testarea, a cine o execută și a ce documente ajung pe masa autorității.
Cui i se aplică DORA, de fapt
DORA acoperă practic tot sectorul financiar european: instituții de credit, instituții de plată și de monedă electronică, firme de investiții, administratori de fonduri, asigurători, furnizori de servicii de criptoactive și infrastructuri de piață. Regulamentul acoperă cinci domenii distincte: gestionarea riscului ICT, raportarea incidentelor, testarea rezilienței digitale, riscul furnizorilor terți de ICT și schimbul de informații despre amenințări.
Dar există un al doilea cerc, adesea ignorat complet în discuțiile despre conformare: furnizorii terți de servicii ICT — găzduire, cloud, software bancar, procesare de tranzacții, mentenanță. Regulamentul nu îi supune direct, însă entitatea financiară are obligația să impună prin contract cerințe de securitate, drepturi de audit și de acces, clauze de reziliență și, pentru furnizorii care susțin funcții critice, participarea la testarea rezilienței — inclusiv la exercițiile TLPT ale clientului.
Pentru companiile din Moldova, DORA ajunge cel mai des exact pe această cale contractuală. Dacă dezvolți sau operezi tehnologie pentru o entitate financiară din UE, clientul tău are obligația de a-ți impune condițiile în contract. Cerința te atinge înainte ca vreo lege locală să o preia, iar refuzul de a semna clauzele de audit sau de participare la testare devine, practic, un motiv de descalificare comercială.
Notă: DORA fiind regulament, nu directivă, nu are nevoie de lege de transpunere. Aplicabilitatea și desemnarea pentru TLPT se stabilesc însă de autoritățile competente, de la caz la caz — nu există o listă publică universală de entități „DORA".
Programul de testare de bază
DORA cere un program de testare a rezilienței digitale aplicat cel puțin anual tuturor sistemelor ICT care susțin funcții critice sau importante. Aici apare prima confuzie frecventă: programul nu este un singur test, ci un set de activități complementare, fiecare cu un scop diferit.
- evaluări de vulnerabilități și scanări de componente open source;
- analize de securitate a rețelei și evaluări de securitate fizică;
- chestionare și revizuiri de cod sursă;
- teste de compatibilitate și teste de performanță;
- teste de penetrare, externe și interne.
Două condiții transversale schimbă însă practica mai mult decât lista în sine. Prima: testarea trebuie făcută de părți independente, interne sau externe, fără conflict de interese cu echipa care a construit sistemul. Un dezvoltator care își testează singur codul nu satisface cerința, oricât de riguros ar fi procesul. A doua: constatările trebuie să intre într-un proces de remediere urmărit, cu prioritizare pe riscul asupra funcțiilor critice — nu pe severitatea brută din scanner.
Această a doua condiție este, în experiența noastră, cea care desparte conformarea reală de cea pe hârtie. Un raport cu 200 de constatări „medii" și zero prioritizare pe funcția de procesare a plăților nu spune nimic unui supraveghetor. Un raport cu 12 constatări, dintre care două ating direct disponibilitatea serviciului critic, însoțit de un plan de remediere cu termene și dovezi de re-test, spune totul.
TLPT: testarea condusă de amenințări
Deasupra programului de bază, DORA introduce testarea avansată pentru entitățile desemnate de autoritățile competente, pe criterii de risc, de dimensiune și de importanță sistemică — în principal instituții a căror indisponibilitate ar afecta stabilitatea financiară. TLPT (threat-led penetration testing) se face cel puțin o dată la trei ani și urmează cadrul european TIBER-EU.
Diferența față de un pentest obișnuit nu este de grad, ci de natură. Sunt trei elemente care schimbă complet exercițiul.
Scenarii construite pe amenințări reale
Un furnizor de threat intelligence construiește scenariile pornind de la grupările care atacă efectiv sectorul tău — nu de la un catalog generic de tehnici. Dacă în ultimele luni un actor cu motivație financiară a vizat procesatori de plăți din regiune folosind spear-phishing pe personalul de operațiuni, scenariul TLPT pornește exact de acolo. Rezultatul nu mai este „am găsit o injecție SQL", ci „am ajuns la sistemul de decontare pe calea pe care o folosește un adversar real".
Execuție pe sistemele de producție
TLPT se execută pe sistemele de producție, nu pe un mediu de test. De aceea are guvernanță strictă: un control team restrâns în interiorul entității, reguli de angajament foarte clare, proceduri de oprire de urgență și un perimetru definit cu precizie. Nu este un exercițiu pe care îl improvizezi într-o săptămână.
Se măsoară și apărarea, nu doar atacul
Aici stă diferența cea mai importantă. Echipa albastră nu știe că testul are loc. Rezultatul nu este doar o listă de vulnerabilități exploatate, ci și o măsură a capacității de detecție și de răspuns: cât timp a trecut până la prima alertă, cine a reacționat, ce s-a escaladat și ce s-a pierdut pe drum.
Un exercițiu TLPT durează, de regulă, câteva luni — faza de pregătire, faza de threat intelligence, faza de testare propriu-zisă și faza de închidere. Se încheie cu un replay: atacatorii și apărătorii trec împreună prin cronologie, minut cu minut, ca să se vadă unde a existat semnal și nu a fost observat. În practică, această fază produce mai multe îmbunătățiri decât lista de vulnerabilități, pentru că transformă un eveniment tehnic într-o lecție organizațională.
Atenție: un TLPT pe o infrastructură netestată produce un raport previzibil și scump. Atacatorii ajung repede la funcțiile critice pe căi banale, iar concluzia utilă — cât de bine detectezi un adversar competent — se pierde în zgomotul unor probleme elementare de igienă.
Bază vs. TLPT: ce, cine, cât de des
Confuzia dintre cele două niveluri de testare este cea mai frecventă eroare de planificare. Tabelul de mai jos sintetizează diferențele care contează operațional.
| Aspect | Program de bază | TLPT |
|---|---|---|
| Cine intră | Toate entitățile în scopul DORA | Doar entitățile desemnate de autoritate |
| Frecvență | Cel puțin anual | Cel puțin o dată la trei ani |
| Mediu | Preproducție sau producție, cu acord | Sisteme de producție în funcțiune |
| Ce se măsoară | Vulnerabilități și configurații | Detecție, răspuns, reziliența funcțiilor critice |
| Cadru de referință | OWASP, PTES, NIST | TIBER-EU, cu autoritatea implicată |
Reține un detaliu care se pierde des: TLPT nu este un „pentest mai scump". Este un exercițiu de reziliență în care atacul este doar instrumentul de măsurare. Dacă îl tratezi ca pe un pentest, vei cumpăra lista greșită de livrabile.
Ce faci înainte să ajungi la TLPT
Ordinea sănătoasă este inversă față de intuiție: mai întâi închizi căile evidente prin testare clasică, apoi măsori detecția și răspunsul. Patru lucruri trebuie să fie deja solide înainte de prima zi de TLPT.
- Inventarul funcțiilor critice și al sistemelor ICT care le susțin. Fără el, perimetrul TLPT nu se poate defini, iar exercițiul fie se lărgește inutil, fie ratează exact sistemul care conta.
- Testare externă și internă clasică, cu remediere dusă până la re-test. Nu rapoarte, ci dovezi că vulnerabilitățile găsite au fost închise.
- Registrul furnizorilor ICT și clauzele contractuale de testare și audit. Dacă furnizorul tău de cloud nu îți permite testare pe infrastructura lui, trebuie să știi asta înainte, nu în timpul exercițiului.
- Capacitate reală de detecție. Dacă nu ai monitorizare centralizată și corelare de evenimente, TLPT-ul va măsura absența ei — ceea ce este o concluzie validă, dar una pe care o puteai afla mult mai ieftin.
Un detaliu practic pe care îl vedem des la clienți: capacitatea de detecție nu se rezolvă în timpul TLPT. Dacă echipa de securitate lucrează în ture de zi și nu are proceduri de escaladare pentru orele 02:00, exercițiul va arăta exact asta — și va arăta că adversarul real ar fi avut la dispoziție șase ore neobservate.
Ce înseamnă pentru furnizorii de tehnologie
Dacă ești furnizor IT pentru o bancă din UE, te privește DORA? Direct, doar dacă ești desemnat furnizor critic de servicii ICT la nivel european — o desemnare care vine cu supraveghere directă din partea autorităților. Indirect, aproape sigur da. Entitatea financiară are obligația să includă în contract cerințe de securitate, drepturi de audit și de acces, clauze de reziliență și, pentru furnizorii care susțin funcții critice, participarea la testarea rezilienței, inclusiv la exercițiile TLPT ale clientului.
Pentru o companie din Moldova, asta înseamnă că cerința ajunge în contract înainte de a exista orice obligație legală locală. Iar clauzele de audit au un efect practic: clientul are dreptul să vină cu un terț independent să te testeze, iar tu trebuie să cooperezi. Firmele care tratează aceste clauze ca formalități descoperă, de obicei, că nu pot răspunde la un chestionar de securitate riguros, că nu au loguri centralizate sau că nu pot demonstra segregarea mediilor.
Important: un exercițiu TLPT complet durează de obicei între trei și șase luni și costă semnificativ mai mult decât un test de penetrare clasic. Motivul nu este comercial, ci structural: threat intelligence, guvernanță, control team, faza de replay. De aceea, pentru majoritatea entităților, TLPT nu ar trebui să fie primul test pe care îl fac vreodată.
Unde se câștigă, de fapt, conformarea
DORA mută centrul de greutate de la controale declarate la dovezi de comportament. Un supraveghetor nu va citi cu atenție politica ta de securitate; va citi raportul de testare, planul de remediere și cronologia unui exercițiu. Iar dacă ești o entitate desemnată pentru TLPT, va citi și modul în care ai reacționat atunci când nimeni nu ți-a spus că ești atacat.
Pentru practicieni, concluzia este simplă și incomodă în același timp: reziliența nu se declară, se măsoară. Iar măsurarea începe cu inventarul funcțiilor critice, continuă cu testare clasică dusă până la re-test și se încheie — o dată la trei ani, pentru cei desemnați — cu un exercițiu care testează nu doar sistemele, ci și oamenii care ar trebui să le apere. Entitățile care înțeleg asta nu tratează DORA ca pe o povară de conformare, ci ca pe prima ocazie reală de a afla dacă serviciul lor critic supraviețuiește unui adversar competent.