Pe 16 octombrie 2026, Depozitarul Central a publicat un comunicat scurt prin care confirma că a fost ținta unui atac cibernetic asupra aplicației „Servicii Online pentru Investitori".
Formularea merită citită în original, pentru că este atent construită: instituția spune că a fost ținta unui atac „care a vizat aplicația Servicii Online pentru Investitori, incident care a fost identificat în ziua producerii".
Ce face cazul instructiv nu este detaliul tehnic — nu a fost publicat aproape niciunul. Este faptul că un singur incident, la o singură entitate financiară, pornește simultan trei ceasuri de reglementare, fiecare cu autoritatea lui, termenul lui și definiția lui pentru ce înseamnă „întârziat".
Ce este confirmat și de cine
Comunicatul public spune că deținerile nu au fost atinse: „nu au fost accesate, modificate și/sau alterate deținerile de instrumente financiare sau informații privind tranzacțiile decontate." Funcțiile de decontare și de registru au funcționat normal.
Lista categoriilor de date personale nu apare în acel comunicat. Ea provine dintr-o notificare transmisă separat utilizatorilor aplicației, citată de mai multe publicații din România: au fost vizualizate numele și prenumele, adresa, codul numeric personal, seria și numărul cărții de identitate, adresa de e-mail, numărul de telefon și codul IBAN, fără ca acestea să fie modificate sau alterate. Aceeași notificare precizează că parolele de acces în aplicație nu au fost accesate.
Două precizări pe care majoritatea relatărilor le-au estompat. Întâi, cuvântul folosit de Depozitarul Central este „vizualizate". Instituția nu a spus că datele au fost copiate sau exfiltrate și nu a publicat un număr de persoane afectate. Apoi, afirmația că deținerile nu au fost afectate aparține instituției; nicio autoritate nu a confirmat-o public.
Bursa de Valori București a confirmat separat, în aceeași zi, că propriile sisteme nu au fost afectate și că tranzacționarea a continuat normal.
Vectorul de atac nu a fost făcut public. Nici atacatorul, nici tipul de atac, nici dacă datele au părăsit infrastructura. O publicație, citând notificarea către utilizatori pe care spune că a văzut-o, plasează atacul pe 8 octombrie — o singură sursă, absentă din orice document primar, de tratat ca neconfirmată.
Trei ceasuri, un singur incident
Aici o entitate financiară din România are nevoie de claritate, pentru că cele trei regimuri nu sunt alternative.
DORA, către ASF. Un depozitar central de titluri de valoare este entitate financiară conform articolului 2 alineatul (1) litera (g) din Regulamentul (UE) 2022/2554, iar conform articolului 46 litera (e) autoritatea competentă este cea desemnată în temeiul CSDR — în România, Autoritatea de Supraveghere Financiară. Depozitarul Central a fost autorizat de ASF în baza CSDR în 2019.
Termenele de raportare pentru un incident major legat de TIC se află în Regulamentul delegat (UE) 2025/301, articolul 5, și sunt mai strânse decât își amintesc cei mai mulți:
- Notificarea inițială — cât mai devreme posibil și, în orice caz, în patru ore de la clasificarea incidentului drept major, dar nu mai târziu de 24 de ore de la momentul în care entitatea a luat cunoștință de el
- Raportul intermediar — cel târziu la 72 de ore de la transmiterea notificării inițiale, și se transmite chiar dacă nimic din starea sau tratarea incidentului nu s-a schimbat, cu un raport intermediar actualizat fără întârzieri nejustificate odată ce activitatea curentă a fost reluată
- Raportul final — nu mai târziu de o lună de la raportul intermediar sau, după caz, de la ultimul raport intermediar actualizat
Termenul de patru ore este cel care surprinde. El nu curge de la incident, ci din momentul în care îl clasifici drept major. Ceea ce înseamnă că decizia de clasificare este ea însăși pe drumul critic — iar dacă nimeni nu are mandatul să o ia la două noaptea, ceasul curge oricum.
GDPR, către ANSPDCP. Articolul 33 cere notificarea autorității de supraveghere fără întârzieri nejustificate și, acolo unde este posibil, în 72 de ore de la luarea la cunoștință, cu excepția cazului în care încălcarea este puțin probabil să genereze un risc pentru persoane. Articolul 34 cere informarea persoanelor vizate doar atunci când încălcarea este susceptibilă să genereze un risc ridicat pentru drepturile și libertățile lor.
Un set care combină numele complet, adresa, CNP-ul, seria și numărul actului de identitate și IBAN-ul este aproape un pachet complet de identitate în context românesc. Depozitarul Central a scris direct utilizatorilor săi, ceea ce este consecvent cu o informare în temeiul articolului 34.
NIS 2, către DNSC. Acolo unde entitatea intră și în sfera națională, OUG nr. 155/2024 aduce propriile termene de avertizare timpurie la 24 de ore și de notificare la 72 de ore. Conform notificării către utilizatori, instituția a informat DNSC și ANSPDCP și a depus plângere penală la DIICOT.
Trei autorități, trei formulare, trei definiții pentru „a luat cunoștință". Răspunsul practic nu este să alegi una, ci să ai un singur declanșator intern care le alimentează pe toate, cu decizia de clasificare luată o dată și consemnată o dată.
Ce nu a fost stabilit
Merită spus explicit, pentru că distanța dintre ce se știe și ce se afirmă online este mare.
Nu a apărut niciun comunicat de la ASF, DNSC sau ANSPDCP. Dacă s-a făcut o notificare DORA de incident major și în ce termen nu este public. Dacă termenul GDPR de 72 de ore a fost respectat nu poate fi evaluat fără data incidentului, care se sprijină pe relatarea unei singure publicații. Numărul persoanelor vizate nu este cunoscut. Dacă datele au fost exfiltrate, nu doar vizualizate, nu este cunoscut.
Nimic din toate acestea nu este o critică la adresa instituției. Divulgarea timpurie este aproape întotdeauna incompletă, iar o organizație care publică înainte să știe tot se comportă mai bine decât una care așteaptă. Dar înseamnă că un cititor ar trebui să privească cu rezervă reconstituirile sigure pe sine care circulă despre cum s-a întâmplat.
Întrebarea pe care o ridică pentru toți ceilalți
Scoate specificul și rămâne o aplicație web destinată clienților, construită pentru self-service, care ține date de înrolare ale unor utilizatori de retail, operată de o entitate ale cărei sisteme principale sunt în altă parte și sunt puternic controlate.
Forma aceasta este extrem de răspândită. Platforma principală — decontarea, registrul, evidența — primește atenția, segregarea, controlul schimbărilor și testarea anuală. Portalul de self-service, construit ca lumea să nu mai sune la telefon, este tratat ca un strat de confort. De regulă stă pe altă tehnologie, adesea cu alt furnizor, și ține exact datele de care are nevoie un autor de fraudă de identitate.
Conform articolelor 24 și 25 din DORA, testarea rezilienței operaționale digitale nu este o formalitate anuală și este menită explicit să acopere sistemele și aplicațiile TIC care susțin funcții critice sau importante. Întrebarea internă este dacă scopul ultimului test a inclus efectiv aplicația destinată clienților sau s-a oprit la sistemul central.
Ce ar acoperi un test pe acest scenariu
Un test de penetrare pe un portal de self-service de acest tip se uită la un set precis de lucruri, iar cele mai multe țin de autorizare, nu de injecție:
- Dacă un utilizator autentificat poate ajunge la fișa de înrolare a altui utilizator schimbând un identificator — cea mai frecventă constatare serioasă în aplicațiile de acest tip
- Dacă fluxurile de înrolare și de recuperare a contului pot fi abuzate pentru a vedea date înainte ca autentificarea să fie completă
- Dacă interfețele administrative sau de suport sunt accesibile din internet și ce expun
- Dacă gestionarea sesiunii, limitarea ratei și protecțiile împotriva enumerării rezistă pe căile de autentificare și de recuperare
- Dacă datele returnate de fiecare punct de API sunt minimul necesar ecranului sau dacă clientul filtrează un răspuns mai bogat
- Ce jurnalizează aplicația, unde ajung jurnalele și dacă o reconstituire criminalistică ar fi posibilă ulterior
Ultima decide dacă poți răspunde deloc întrebărilor autorității. O instituție care nu poate reconstitui ce înregistrări au fost accesate trebuie să presupună ce e mai rău și să notifice pe baza aceea.
Dacă organizația ta intră sub DORA, un audit de conformitate stabilește unde cad obligațiile și ce dovezi se așteaptă. Aplicația în sine este obiectul unei evaluări de securitate web sau al unui test de penetrare pe API, în funcție de cum este construit stratul de self-service — iar la majoritatea instituțiilor este construit ca API cu un client subțire în față.
Surse: Comunicatul Depozitarului Central, 16 octombrie 2026 · Comunicatul Bursei de Valori București · Regulamentul delegat (UE) 2025/301 · Regulamentul (UE) 2022/2554 (DORA) · Economica.net, citând notificarea către utilizatori
Categoriile de date provin dintr-o notificare transmisă utilizatorilor aplicației și citată de presa din România, nu din comunicatul public al Depozitarului Central. Afirmația că deținerile financiare nu au fost afectate aparține instituției și nu a fost confirmată independent. Data de 8 octombrie este raportată de o singură publicație și nu apare în niciun document primar. La momentul redactării nu fusese publicat niciun comunicat din partea ASF, DNSC sau ANSPDCP.
Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.