de avocat Alexandra Ianul,
Managing Partner, IANUL LAW OFFICE
Atacul cibernetic care a afectat, începând cu data de 14 iulie 2026, sistemele informatice ale Agenției Naționale de Cadastru și Publicitate Imobiliară nu a provocat doar cea mai amplă întrerupere a serviciilor informatice din istoria instituției. El a transformat un risc despre care, până acum, se vorbea mai ales în rapoarte, strategii și conferințe într-o realitate economică imediată: o vulnerabilitate informatică poate opri, în câteva ore, funcționarea unui serviciu public esențial și poate bloca exercitarea unor drepturi în întreaga țară.
Indisponibilitatea aplicației e-Terra, a serviciilor de e-mail și a celorlalte aplicații ale ANCPI a afectat activitatea notarilor, avocaților, instituțiilor de credit, dezvoltatorilor imobiliari, profesioniștilor din domeniul cadastrului și, în cele din urmă, a persoanelor care aveau în curs tranzacții imobiliare. Fără extrase de carte funciară, verificări cadastrale și înscrierea drepturilor ori a ipotecilor, numeroase operațiuni juridice nu au mai putut fi finalizate.
Pentru mai multe zile, o parte esențială a circuitului civil a fost, în fapt, blocată. Contracte pregătite pentru semnare au fost amânate, credite aprobate nu au mai putut fi utilizate, ipoteci nu au putut fi înscrise, iar plățile legate de aceste operațiuni au rămas suspendate. Relatările publice indică faptul că aproape toate tranzacțiile imobiliare dependente de sistem au fost puse în așteptare, mii dintre ele riscând să fie amânate.
Efectul economic nu se oprește la vânzător și cumpărător. Pierd bani notarii, agențiile imobiliare, dezvoltatorii, băncile, evaluatorii, avocații, societățile de cadastru și bugetul public. Pentru anumite operațiuni, întârzierea poate însemna pierderea finanțării, expirarea unor termene contractuale, activarea unor penalități sau chiar aplicarea unui regim fiscal mai puțin favorabil. Incidentul demonstrează astfel că securitatea cibernetică nu este o cheltuială tehnică auxiliară, ci o condiție a continuității circuitului juridic și economic.
Aceste consecințe deosebit de grave nu justifică însă identificarea prematură a unui vinovat.
Informațiile făcute publice până în prezent nu cuprind raportul tehnic final privind incidentul. ANCPI a comunicat că bazele sale de date tehnice și juridice nu au fost afectate și că aplicațiile sunt migrate în Cloudul Guvernamental, sub coordonarea Serviciului de Telecomunicații Speciale. În același timp, persoana care pretinde că a realizat atacul susține că ar fi obținut acces la date, la servere și la codul-sursă al unor aplicații. Între poziția oficială a instituției și afirmațiile atribuite atacatorului există, așadar, diferențe semnificative, care nu pot fi înlăturate prin speculații, ci numai printr-o investigație tehnică.
În acest moment poate fi afirmată cu certitudine existența incidentului și indisponibilitatea serviciilor. Nu pot fi însă stabilite, numai din informațiile publice, vectorul inițial al atacului, componenta prin care a fost obținut accesul, amploarea eventualei compromiteri, succesiunea exactă a operațiunilor, măsurile de securitate care funcționau la acel moment și nici conduita concretă care ar fi permis producerea rezultatului.
Or, răspunderea juridică nu se întemeiază pe proximitatea unui nume față de un incident, ci pe fapte, obligații determinate și o legătură de cauzalitate demonstrată.
Un avertisment care depășește cazul ANCPI
Cazul ANCPI trebuie să producă mai mult decât o investigație punctuală. El ridică o întrebare legitimă, care privește întreaga administrație digitală: cât de pregătite sunt instituțiile și autoritățile române pentru un incident care nu mai afectează numai un site de prezentare, ci baza de date și aplicațiile fără de care un serviciu public nu poate funcționa?
Consecințele posibile pot fi ușor înțelese dacă mutăm, ipotetic, același scenariu asupra infrastructurii informatice a ANAF. Indisponibilitatea prelungită a sistemelor fiscale ar putea afecta depunerea declarațiilor, emiterea și comunicarea actelor fiscale, încasarea obligațiilor bugetare, rambursările de TVA, procedurile de executare și activitatea curentă a contribuabililor. O asemenea situație nu ar mai reprezenta o simplă problemă informatică, ci un risc sistemic pentru funcționarea statului și a economiei.
Același raționament este valabil pentru evidența populației, sistemele de sănătate, plățile publice, infrastructura energetică sau orice alt serviciu a cărui funcționare a devenit dependentă de baze de date și platforme digitale. Cu cât digitalizarea avansează, cu atât continuitatea acestor sisteme trebuie tratată ca o obligație esențială, testată în practică, nu doar declarată prin politici și proceduri.
Întrebarea dacă autoritățile sunt pregătite nu poate primi un răspuns credibil numai prin inventarierea produselor achiziționate. Pregătirea reală presupune evaluări periodice ale riscurilor, responsabilități clar delimitate, personal instruit, vulnerabilități remediate la timp, copii de siguranță izolate și testate, planuri de continuitate funcționale, exerciții de răspuns la incidente și mecanisme alternative prin care serviciile esențiale să poată continua. Incidentul ANCPI a demonstrat că riscul nu mai este teoretic. Următorul test poate privi o infrastructură cu efecte și mai ample.
Un sistem informatic nu este un produs unic
Pentru publicul nespecializat, un sistem informatic poate părea o construcție unitară, aflată în responsabilitatea unei singure entități denumite generic „furnizorul IT”. În realitate, infrastructurile informatice de asemenea dimensiuni sunt ecosisteme formate din numeroase componente interdependente.
Aplicațiile software, bazele de date, serverele, stațiile de lucru, echipamentele de rețea, sistemele de autentificare, soluțiile de protecție a terminalelor, serviciile de e-mail, copiile de siguranță, mecanismele de recuperare în caz de dezastru și instrumentele de monitorizare pot fi administrate de departamente diferite sau de furnizori diferiți. Unele componente sunt dezvoltate la comandă, altele sunt produse standard, iar altele aparțin infrastructurii proprii a beneficiarului.
Mai mult decât atât, între operatorii implicați pot exista raporturi de antrepriză, subcontractare, furnizare de licențe, mentenanță software, administrare de infrastructură, suport tehnic, audit, monitorizare ori răspuns la incidente. Fiecare dintre aceste activități are un obiect diferit și presupune alte drepturi de acces, alte obligații și o altă capacitate de intervenție.
De aceea, expresii precum „firma care asigura securitatea” sau „compania care administra sistemul” pot induce o concluzie greșită dacă nu sunt raportate la obiectul exact al contractului. O societate care întreține anumite aplicații nu administrează în mod necesar și rețeaua prin care acestea sunt accesate. Furnizorul unei soluții de protecție a stațiilor de lucru nu gestionează automat identitățile utilizatorilor, copiile de siguranță sau codul-sursă al aplicațiilor. Prestatorul care oferă suport la solicitarea beneficiarului nu asigură, numai prin aceasta, supravegherea umană permanentă a întregii infrastructuri.
Înainte de orice concluzie trebuie stabilit, așadar, nu doar cine avea un contract, ci ce componentă administra, ce obligații își asumase, ce acces avea și ce putea efectiv să controleze.
Externalizarea serviciilor nu înseamnă externalizarea integrală a responsabilității
Un alt punct care trebuie înțeles este rolul beneficiarului. Achiziționarea unei aplicații, a unei licențe sau chiar a unui serviciu specializat de securitate cibernetică nu transformă organizația într-un simplu utilizator pasiv și nu transferă automat asupra furnizorului întreaga răspundere pentru siguranța sistemului.
În funcție de arhitectura tehnică și de repartizarea contractuală a atribuțiilor, beneficiarul poate păstra responsabilitatea pentru administrarea conturilor, acordarea și retragerea drepturilor de acces, stabilirea politicilor de autentificare, instruirea propriului personal, aprobarea operațiunilor, gestionarea activelor informatice, analiza vulnerabilităților semnalate, realizarea copiilor de siguranță, testarea restaurării și asigurarea continuității activității.
Un exemplu aparent banal este parola utilizatorului. De regulă, parola este aleasă de persoana care folosește contul, în timp ce organizația stabilește politica aplicabilă: lungimea minimă, complexitatea, interzicerea parolelor compromise sau reutilizate, autentificarea multifactor și condițiile de blocare a accesului. Dacă o organizație permite folosirea unor parole precum „Parola123”, menține active conturi care nu mai sunt necesare ori nu impune autentificarea multifactor pentru accesarea unor resurse sensibile, simpla existență a unui produs de securitate nu poate compensa integral riscul creat prin aceste practici.
Nici aici nu poate fi formulată însă o regulă absolută. Administrarea identităților și configurarea politicilor de acces pot fi externalizate. Prin urmare, trebuie verificat cine avea, în cazul concret, atribuția de a stabili regula, dreptul tehnic de a o implementa și obligația de a verifica respectarea ei.
Exemplul demonstrează de ce securitatea cibernetică nu poate fi redusă la achiziționarea unui produs și nici la activitatea unei singure companii. Ea presupune tehnologie, proceduri, decizii manageriale și conduita efectivă a persoanelor care utilizează sistemul.
Responsabilitățile rezultă și din lege, nu numai din contract
Această distribuire a responsabilităților nu este doar o regulă de bună practică. Ea rezultă și din noul cadru european și național privind securitatea cibernetică.
Directiva (UE) 2022/2555 – NIS2 și O.U.G. nr. 155/2024 nu tratează securitatea cibernetică drept o problemă care poate fi delegată integral departamentului IT ori transferată unui prestator extern. Reglementarea introduce o abordare de guvernanță a riscului, în care entitatea trebuie să adopte măsuri tehnice, operaționale și organizatorice adecvate și proporționale cu riscurile existente.
Art. 13 din O.U.G. nr. 155/2024 include, între categoriile de măsuri relevante, politicile de analiză a riscurilor și de securitate a sistemelor informatice, gestionarea incidentelor, continuitatea activității, gestionarea copiilor de siguranță și recuperarea în caz de dezastru, securitatea lanțului de aprovizionare, evaluarea eficacității măsurilor adoptate, practicile de igienă cibernetică, securitatea resurselor umane, controlul accesului și gestionarea activelor.
Art. 14 plasează asupra organelor de conducere responsabilitatea aprobării și supravegherii măsurilor de gestionare a riscurilor. La rândul său, art. 20 din Directiva NIS2 consacră implicarea directă a conducerii entităților esențiale și importante în aprobarea și monitorizarea implementării acestor măsuri.
Directiva precizează, de altfel, că obligațiile privind gestionarea riscurilor se aplică entității indiferent dacă aceasta își administrează sistemele prin personalul intern sau externalizează mentenanța lor. În același timp, securitatea lanțului de aprovizionare impune evaluarea furnizorilor și a serviciilor contractate.
Rezultă că legea nu așază întreaga responsabilitate nici asupra beneficiarului, nici asupra furnizorului. Ea recunoaște existența unui ansamblu de obligații proprii, corelate, care trebuie analizate separat. Externalizarea unei activități nu înlătură obligația entității de a-și gestiona riscurile, după cum obligațiile legale ale beneficiarului nu exonerează furnizorul de executarea exactă a prestațiilor asumate.
Un atac reușit nu dovedește, prin el însuși, neexecutarea contractului
Producerea unui incident cibernetic nu demonstrează automat că una dintre părți și-a încălcat obligațiile. Securitatea informatică urmărește reducerea riscurilor la un nivel adecvat, nu promite, în orice situație, imposibilitatea absolută a unui atac.
Natura obligației trebuie stabilită prin interpretarea contractului. Unele prestații pot constitui obligații de rezultat: instalarea unei soluții, livrarea unei actualizări, realizarea unui audit într-un anumit termen ori intervenția în intervalul prevăzut. Altele pot fi obligații de diligență, care impun furnizorului să acționeze cu competența și prudența profesionistului, fără a putea garanta că niciun atacator nu va reuși vreodată să pătrundă în sistem.
Pentru angajarea răspunderii contractuale nu este suficientă existența contractului și nici producerea prejudiciului. Trebuie identificată obligația neexecutată sau executată necorespunzător și trebuie demonstrată legătura de cauzalitate dintre acea neexecutare și rezultatul produs.
Dacă accesul a fost obținut prin compromiterea unor credențiale, analiza va privi administrarea identităților, politicile de autentificare, drepturile acordate contului și mecanismele de detectare a utilizării sale neobișnuite. Dacă a fost exploatată o vulnerabilitate software, trebuie identificată componenta vulnerabilă, persoana care avea obligația actualizării sale și momentul în care remedierea devenise disponibilă. Dacă au fost afectate copiile de siguranță, trebuie verificată arhitectura de backup, separarea copiilor, drepturile de acces și testarea procedurilor de restaurare.
Cauza tehnică determină, în mare măsură, întrebarea juridică relevantă. Fără stabilirea ei, răspunderea nu poate fi decât presupusă.
Ce probe sunt necesare
O concluzie serioasă presupune confruntarea raportului tehnic al incidentului cu documentele care stabilesc responsabilitățile fiecărui participant.
Investigația trebuie să identifice vectorul inițial de acces, conturile și echipamentele utilizate, momentul compromiterii, deplasarea atacatorului în interiorul rețelei, componentele afectate, configurațiile existente și măsurile de securitate active. Jurnalele sistemelor, alertele, rapoartele de audit, istoricul actualizărilor și cronologia intervențiilor sunt esențiale pentru reconstituirea incidentului.
Aceste date trebuie apoi comparate cu contractele, acordurile privind nivelul serviciilor, documentațiile tehnice, matricele de responsabilități, procedurile interne, procesele-verbale de recepție și corespondența dintre părți. Trebuie verificat dacă un risc fusese identificat, cui îi revenea obligația de a-l trata, cine avea dreptul tehnic de a interveni, dacă măsura fusese solicitată sau aprobată și dacă persoana competentă dispunea de informațiile și resursele necesare.
În egală măsură, trebuie analizată reacția la incident: când a fost detectat, când a fost raportat, cine a fost notificat, ce măsuri de izolare au fost adoptate și dacă timpii contractuali de intervenție au fost respectați.
Abia după stabilirea acestor elemente se poate afirma dacă a existat o încălcare, cui îi este imputabilă și dacă aceasta a contribuit efectiv la producerea ori amplificarea prejudiciului.
De la nevoia legitimă de explicații la riscul unui verdict prematur
În cazul unor incidente care afectează servicii publice de importanță majoră, presiunea pentru identificarea rapidă a unui responsabil este firească. Cetățenii și profesioniștii afectați au dreptul la explicații, iar instituțiile au obligația transparenței în limitele permise de investigație și de necesitatea protejării sistemelor.
Dar rapiditatea nu poate înlocui rigoarea.
Numărul angajaților unui furnizor, valoarea unui contract, sediul social, relațiile personale ale asociaților sau simplul fapt că o societate apare într-o procedură de achiziție publică nu identifică vectorul unui atac și nu demonstrează legătura de cauzalitate. Aceste informații pot constitui context jurnalistic, dar nu sunt probe tehnice ale unei neexecutări contractuale.
În același mod, nici beneficiarul nu poate fi considerat responsabil numai pentru că sistemul îi aparține. Trebuie stabilit dacă obligația relevantă îi revenea, dacă avea controlul asupra componentei compromise și dacă o anumită conduită sau omisiune a contribuit la incident.
Echidistanța nu înseamnă distribuirea artificială a culpei între participanți. Înseamnă refuzul de a o atribui înainte de administrarea probelor.
Răspunderea urmează traseul vulnerabilității
Incidentul care a afectat sistemele ANCPI trebuie investigat complet, iar concluziile trebuie formulate numai după stabilirea cauzei tehnice și a responsabilităților concrete. Este posibil ca investigația să identifice deficiențe ale unui furnizor, ale beneficiarului, ale mai multor participanți sau o succesiune de vulnerabilități și decizii care, analizate separat, nu ar fi produs același rezultat. La acest moment, oricare dintre aceste variante este doar o ipoteză.
În securitatea cibernetică, răspunderea nu urmează eticheta contractului, ci traseul vulnerabilității. Trebuie stabilit cine controla componenta compromisă, cine avea obligația și posibilitatea efectivă de a adopta măsura necesară, ce informații deținea fiecare participant și cum a contribuit conduita sa la producerea rezultatului.
Contractul arată obligațiile asumate. Procedurile interne arată modul în care acestea trebuiau corelate cu activitatea beneficiarului. Legea stabilește responsabilitățile care nu pot fi ignorate prin externalizare. Însă numai proba tehnică poate demonstra dacă încălcarea unei obligații determinate a permis sau a amplificat atacul.
Dincolo de stabilirea răspunderii în cazul concret, incidentul trebuie să determine o verificare reală a rezilienței sistemelor publice critice. Întrebarea relevantă nu este numai dacă instituțiile au cumpărat soluții de securitate, ci dacă pot continua să funcționeze atunci când una dintre liniile de apărare este depășită. Pentru cetățean și pentru economie, diferența dintre o procedură existentă pe hârtie și una testată în practică se măsoară în drepturi blocate, contracte amânate și pierderi financiare.
Până la existența acestor dovezi, asocierea publică, coincidența temporală și formulările generale despre „firma care asigura securitatea” nu pot ține locul unei analize juridice. Într-un domeniu în care fiecare componentă poate deschide ori poate închide o cale de acces, concluzia trebuie să vină la finalul investigației, nu înaintea ei.
