Ghid DORA pentru companiile din România

---

DORA (Digital Operational Resilience Act) este Regulamentul (UE) 2022/2554↗ privind reziliența operațională digitală a sectorului financiar. A intrat în vigoare pe 16 ianuarie 2023 și se aplică din 17 ianuarie 2025.

DORA e regulament, nu directivă, așa că nu a avut nevoie de transpunere: se aplică direct, identic, în toate statele membre, de la aceeași dată. În cazul DORA nu merge scuza „așteptăm legea românească”. Legislația națională (la noi, OUG 14/2026, vezi mai jos) stabilește doar autoritățile competente și sancțiunile, nu obligațiile în sine.

Sectorul financiar depinde aproape integral de sisteme informatice, deci un incident TIC major devine risc financiar sistemic. DORA mută discuția de la „ai un firewall și o poliță de asigurare?” la „demonstrează că poți absorbi un incident TIC și poți reveni la normal fără să-ți întrerupi funcțiile critice”.

---

Articolul 2 din regulament↗ enumeră 21 de categorii de entități: instituții de credit, firme de investiții, depozitari centrali de titluri de valoare (CSD), contrapărți centrale (CCP), locuri de tranzacționare, registre de tranzacții, administratori de fonduri, societăți de asigurare și reasigurare, intermediari, fonduri de pensii ocupaționale, agenții de rating, administratori de indici de referință critici, registre de securitizare și altele.

Pentru ecosistemul fintech românesc, categoriile relevante:

• instituțiile de plată (inclusiv cele exceptate parțial în temeiul PSD2);
• instituțiile emitente de monedă electronică;
• furnizorii de servicii de informare cu privire la conturi (AISP);
• furnizorii de servicii de criptoactive (CASP, autorizați conform MiCA) și emitenții de tokenuri raportate la active;
• furnizorii de servicii de finanțare participativă (crowdfunding);
• furnizorii terți de servicii TIC, categoria care surprinde multă lume. Dacă vinzi software, cloud sau procesare de date către entități financiare, DORA ajunge la tine pe două căi: prin clauzele contractuale pe care clienții tăi sunt obligați să ți le impună (Art. 30) și, pentru furnizorii desemnați drept critici, printr-un regim de supraveghere directă la nivel european.

Există și excepții: intermediarii de asigurări care sunt microîntreprinderi nu intră sub incidență, la fel nici fondurile de pensii ocupaționale foarte mici (sub 15 membri). Iar pentru entitățile mici, Art. 16 prevede un cadru simplificat de management al riscului TIC: obligațiile se ajustează în funcție de dimensiune și de profilul de risc, dar nu dispar.

Dacă ești un fintech cu 40 de oameni și o licență de instituție de plată, ești sub incidența DORA.

---

Regulamentul e organizat pe cinci piloni. Îi găsești detaliați, împreună cu standardele tehnice de reglementare (RTS) și ghidurile aferente, pe pagina dedicată DORA a ASF↗.

Art. 30 impune clauze care trebuie să existe în fiecare contract cu un furnizor TIC: descrierea serviciilor, locul unde sunt stocate datele, drepturi de acces și audit, condiții de reziliere, strategii de ieșire pentru funcțiile critice. Pentru majoritatea fintech-urilor, asta înseamnă renegocierea contractelor de cloud, core banking, KYC și procesare de plăți.

---

Spre deosebire de reglementările care cer „măsuri adecvate” și lasă restul interpretării, pilonul 3 impune două niveluri de testare, cu frecvențe explicite.

Răspunsul scurt la „cere DORA un pentest?”

Parțial da, și DORA e mai explicită la acest capitol decât ISO 27001, SOC 2 sau NIS2. Art. 25↗ enumeră testarea de penetrare pe nume ca unul dintre testele potrivite din programul de testare pe care Art. 24 îl cere aproape fiecărei entități financiare. Așa că pentru obligația generală de testare răspunsul este un da direct.

DORA are însă două obligații de testare separate, nu una. O pagină de vânzări care spune „DORA cere un pentest” fără să deosebească testarea generală de TLPT descrie doar jumătate din cadru, și exact jumătatea pe care majoritatea furnizorilor nu o pot acoperi. TLPT de la Art. 26–27 este un exercițiu mult mai avansat, condus de oameni și ghidat de threat intelligence, nu ceva ce un pentest automat poate înlocui. Această confuzie e cea mai comună inexactitate din textul de marketing DORA.

Nivelul 1: programul de testare de bază (Art. 24–25)

Art. 24↗ cere entităților financiare care nu sunt microîntreprinderi să mențină un program de testare a rezilienței operaționale digitale, proporțional cu dimensiunea și riscul lor. Alin. (6) cere ca toate sistemele și aplicațiile TIC care susțin funcții critice sau importante să fie testate cel puțin o dată pe an. Art. 25 enumeră mai multe instrumente posibile: evaluări și scanări de vulnerabilități, analize din surse deschise, evaluări de securitate a rețelelor, analize ale deficiențelor, revizuiri de cod sursă, teste de scenariu, de compatibilitate, de performanță, end-to-end și pentesturi. Microîntreprinderile sunt exceptate de la programul Art. 24, dar rămân supuse cadrului proporțional de management al riscului TIC aplicabil lor.

DORA nu cere un pentest extern anual pentru fiecare sistem. Pentru entitățile care nu sunt microîntreprinderi, cere acoperire anuală, prin teste adecvate, a sistemelor care susțin funcții critice sau importante. Pentestul este una dintre metodele permise și trebuie ales când riscul și scopul testului îl justifică. Programul trebuie documentat, iar problemele identificate trebuie prioritizate și remediate.

Testarea automată poate reduce costul verificărilor tehnice recurente. AISafe Labs poate rula pentesturi și audituri de cod la intervale alese de entitate și poate produce rapoarte cu constatări reproduse și documentate. Aceste rezultate pot contribui la programul prevăzut de Art. 24–25, alături de celelalte teste stabilite prin analiza de risc; nu reprezintă singure o certificare de conformitate DORA. Ghidul despre pentest în România în 2026↗ compară costurile și tipurile de soluții disponibile.

Nivelul 2: TLPT (Art. 26–27), cel puțin o dată la 3 ani

Pentru entitățile desemnate de autoritatea competentă, DORA cere Threat-Led Penetration Testing: un exercițiu de red teaming ghidat de threat intelligence, executat pe sisteme live, în producție, care acoperă funcțiile critice ale entității, inclusiv cele externalizate la furnizori TIC.

Ce deosebește TLPT de un pentest obișnuit:

• Se desfășoară pe producție, nu pe staging, și pune la încercare detecția și răspunsul echipelor tale, dincolo de vulnerabilitățile tehnice.
• Metodologia de referință este TIBER-EU↗, cadrul BCE pentru red teaming bazat pe threat intelligence.
• Poate include purple teaming, în condițiile stabilite de autoritatea TLPT și de standardele tehnice aplicabile; nu este corect să îl prezinți drept etapă obligatorie în orice exercițiu.
• Cerințe stricte pentru echipa de testare: aptitudine și reputație, experiență, competențe adecvate, certificări relevante sau cunoștințe echivalente și asigurare de răspundere profesională. Echipele interne sunt permise numai în condițiile Art. 27.
• La final, entitatea transmite autorității un rezumat al constatărilor și planurile de remediere și obține o atestare a exercițiului.

Microîntreprinderile sunt scutite de TLPT. Pentru celelalte entități, desemnarea se face de autoritatea competentă pe baza criteriilor de proporționalitate din Art. 4 alin. (2)↗ și din Regulamentul delegat (UE) 2025/1190↗: cât de mult impact au serviciile și activitățile entității asupra sectorului financiar, semnificația pentru stabilitatea financiară (inclusiv caracterul sistemic), profilul de risc TIC și nivelul de maturitate TIC. Microîntreprinderile și entitățile din regimul simplificat de la Art. 16↗ alin. (1) sunt excluse prin definiție.

În practică, această delimitare conduce TLPT spre entitățile cele mai mari și mai sistemice: instituțiile de credit semnificative supravegheate direct de BCE, băncile sistemice mondiale și de altă relevanță în sistem (G-SIB și O-SII), asigurătorii și reasigurătorii semnificativi, locurile de tranzacționare relevante sistemic și contrapărțile centrale, instituțiile de plată mari și instituțiile de monedă electronică, și prestatorii de servicii de criptoactive de peste pragurile MiCA. Majoritatea entităților financiare mici sau mijlocii nu vor fi desemnate niciodată pentru TLPT, dar rămân cu obligația generală de testare de la Art. 24–25.

Testare de bază vs. TLPT, pe scurt

O platformă automată nu înlocuiește TLPT: regulamentul cere un exercițiu condus de informații despre amenințări și executat de testeri care îndeplinesc criteriile Art. 27. Testarea automată are un rol complementar: poate identifica și retesta vulnerabilități înaintea exercițiului, fără să înlocuiască scenariile, controlul și atestarea TLPT.

---

Deși DORA se aplică direct, fiecare stat membru trebuia să desemneze autoritățile competente și să stabilească regimul de sancțiuni. România a făcut asta prin OUG nr. 14/2026, publicată în Monitorul Oficial nr. 188 din 11 martie 2026.

Arhitectura instituțională:

• BNR este autoritate competentă pentru instituțiile de credit, instituțiile de plată, emitentele de monedă electronică și AISP-urile, adică pentru grosul fintech-urilor licențiate. Tot BNR este coordonatorul național unic pentru TLPT: desemnează entitățile care intră în regimul de testare avansată și supraveghează exercițiile conform metodologiei TIBER-EU.
• ASF acoperă firmele de investiții, societățile de asigurare și reasigurare, intermediarii, administratorii de fonduri de pensii și furnizorii de crowdfunding, și publică standardele tehnice și ghidurile DORA↗ pentru piețele pe care le supraveghează.

În privința sancțiunilor, o precizare necesară: DORA nu conține amenzi paneuropene pentru entitățile financiare. Cifrele de tipul „amenzi DORA de 10 milioane de euro”, care circulă prin articole de marketing, nu există în regulament. Singurul regim de penalități la nivel UE vizează furnizorii TIC desemnați critici, cărora Supraveghetorul principal le poate aplica penalități periodice de până la 1% din cifra de afaceri zilnică medie mondială, pe zi, până la 6 luni (Art. 35). Pentru entitățile financiare, sancțiunile se stabilesc național. Conform OUG 14/2026, ele includ amenzi care pot ajunge, în funcție de autoritate și de gravitatea faptei, până la milioane de lei sau la procente din cifra de afaceri anuală (până la 10% pentru entitățile supravegheate de BNR, potrivit textului ordonanței). La acestea se adaugă retragerea autorizației și interdicțiile aplicate persoanelor responsabile, pe o perioadă de până la 5 ani. Pentru cifrele exacte aplicabile cazului tău, citește ordonanța sau întreabă un avocat: textul e nou și practica de aplicare abia se formează.

Aceeași ordonanță obligă procesatorii de plăți să notifice BNR în termen de 30 de zile de la începerea activității.

---

Cele două regimuri se confundă des, dar răspund la întrebări diferite:

• NIS2 e o directivă orizontală: 18 sectoare (energie, transport, sănătate, infrastructură digitală etc.), transpusă în România prin OUG 155/2024, cu DNSC ca autoritate. Am scris un ghid NIS2 pentru România↗ separat.
• DORA e regulament sectorial, doar pentru entitățile financiare, cu BNR și ASF ca autorități.

Pentru entitățile financiare, DORA e legislația specifică sectorului, iar cerințele ei se aplică cu prioritate față de cele echivalente din NIS2, deci nu raportezi același incident de două ori, pe două fluxuri. Dubla incidență rămâne însă reală: un furnizor de servicii TIC care deservește și bănci, și clienți din alte sectoare NIS2 poate ajunge simultan sub clauzele contractuale DORA pe care i le impun clienții financiari și sub propriile obligații NIS2. Dacă ești în situația asta, pune cerințele în corespondență o singură dată și tratează cele două regimuri ca perspective diferite asupra aceluiași program de securitate.

---

Cum arată conformarea pentru un fintech licențiat cu 30–150 de oameni, fără o armată de oameni pe conformitate:

1. Gap assessment (2–4 săptămâni). Inventariază funcțiile critice, sistemele care le susțin și furnizorii de care depind. Compară ce ai cu cei cinci piloni. Rezultatul e o listă scurtă de acțiuni prioritizate.
2. Cadrul de management al riscului TIC. Politici scrise, aprobate de organul de conducere (regulamentul îi atribuie explicit responsabilitatea), cu roluri clare: cine răspunde de risc, cine detectează, cine intervine, cine raportează. Dacă ești o entitate mică, folosește cadrul simplificat de la Art. 16 în loc să copiezi programul unei bănci sistemice.
3. Contractele cu furnizorii TIC (Art. 30). Construiește registrul contractelor TIC și verifică fiecare contract critic în raport cu lista de clauze obligatorii. Renegociază ce lipsește: durează mai mult decât crezi, așa că apucă-te din timp.
4. Fluxul de incidente. Clasificare, praguri de „major”, cine transmite raportările către BNR sau ASF, modele de raportare pregătite dinainte. La 4 dimineața, în mijlocul unui incident, nu e momentul să inventezi procesul.
5. Programul de testare (Art. 24–25). Stabilește un calendar și o combinație de teste pentru fiecare sistem critic sau important. Pentru entitățile care nu sunt microîntreprinderi, acoperirea acestor sisteme trebuie să fie cel puțin anuală, dar regulamentul nu cere ca fiecare metodă, precum pentestul sau auditul de cod, să fie repetată anual pe fiecare aplicație. AISafe Labs poate automatiza o parte din aceste verificări și poate păstra rezultatele pentru analiza internă și pentru autoritatea competentă.
6. Pregătirea pentru TLPT. Chiar dacă nu ești desemnat încă, întărește-ți capacitatea de detecție și răspuns, rulează exerciții pe scenarii și redu suprafața de atac. Dacă BNR te desemnează, primul TLPT nu ar trebui să fie prima dată când echipa ta trece printr-un atac simulat.

---

Art. 24–25 cer un program de testare bazat pe risc și remedierea deficiențelor identificate. Pentru entitățile care nu sunt microîntreprinderi, sistemele și aplicațiile care susțin funcții critice sau importante trebuie acoperite cel puțin anual. Putem automatiza o parte din testele tehnice din acest program.

Rulăm audituri de cod sursă și pentesturi, black-box și white-box, cu agenți AI care lucrează în paralel pe aplicațiile din perimetru. Raportăm doar vulnerabilități validate: fiecare posibilă vulnerabilitate trece printr-o etapă de exploatare reală într-un mediu izolat, iar ce nu se reproduce nu ajunge în raport, așa că nu pierzi zile pe fals pozitivi. Rezultatele vin în ore, nu în săptămâni, fără programare cu luni înainte. Rapoartele includ pași de reproducere, severitate justificată și rezumat executiv. Ele pot face parte din documentația programului de testare, alături de analiza de risc, planul de testare, celelalte rezultate și dovezile de remediere cerute de autoritatea competentă.

Între rulările programate, facem review de securitate la fiecare Pull Request, față de modelul de amenințări construit în audit, și monitorizăm continuu endpointurile și permisiunile descoperite. Ne integrăm cu GitHub, GitLab, Jira, Linear și cu pipeline-ul tău CI/CD.

TLPT-ul de la Art. 26–27 rămâne în afara a ce putem face: regulamentul cere testeri care îndeplinesc criterii stricte și un exercițiu controlat pe sisteme live. Rolul nostru este complementar: putem testa aplicațiile și verifica remedierile înaintea exercițiului.

Îți poți face gratuit cont în aplicația AISafe↗, cu audituri de cod pe un singur proiect; restul capabilităților intră în planurile plătite.