Cum ar trebui gestionate, în practică, incidentele de securitate. Un specialist explică ce trebuie să conțină notificarea către ANSPDCP

• Termenul de notificare de 72 de ore poate fi depășit cu justificare rezonabilă, iar în cazul informațiilor incomplete se pot trimite notificări subsecvente către autoritate.
• Evaluarea nivelului de risc al incidentului este esențială și se recomandă utilizarea combinată a metodologiei ENISA și a Orientărilor EDPB pentru o argumentare solidă.
• Vulnerabilitățile de securitate descoperite dar neexploatate nu necesită notificare conform art. 34 GDPR, dar este recomandabil să se păstreze o analiză documentată a deciziei.

În privința incidentelor de securitate apărute în cadrul organizațiilor, Adriana Radu, avocat partener senior în cadrul Adriana Radu și Asociații SPARL, a explicat, la evenimentul „GDPR în activitatea de zi cu zi: Managementul consimțământului, breșele de securitate și marketingul direct”, organizat de avocatnet.ro, că, în practică, se întâlnesc frecvent două tipuri de situații:

• Echipa IT anunță un incident de securitate, se concentrează să-l gestioneze și consideră că rolul lor în proces a încetat după ce amenințarea a trecut și sistemul a fost resecurizat;
• Echipa IT anunță existența unei vulnerabilități de securitate, dar nu e clar dacă vulnerabilitatea a fost exploatată sau dacă incidentul este unul notificabil potrivit GDPR sau nu.  În acest exemplu apare foarte des întrebarea dacă trebuie notificat sau nu.  

În ipoteza în care este confirmat un incident de securitate, primul pas, din perspectivă juridică, este înțelegerea detaliată a caracteristicilor acestuia, inclusiv a aspectelor tehnice.

„Pentru noi, ca avocați, acesta e un pas destul de dificil. Cel mai bine ar fi, din experiența mea, ca echipa de legal să stea la masă cu echipa tehnică. Echipa tehnică trebuie să explice, într-un mod pe care echipa juridică să îl poată înțelege, inclusiv cu detalii tehnice. Este foarte util, mai ales dacă ulterior va fi nevoie de o notificare”, a explicat Adriana Radu.

Pentru a putea oferi echipei IT un cadru general al tipului de informații necesare pentru analiză, se pot utiliza ca prim pas în solicitarea de informații întrebările 4 -16 din formularul de notificare a breșei de securitate de pe site-ul ANSPDCP. 

Operatorul trebuie să stabilească precis momentul în care a luat cunoștință de incident, în funcție de circumstanțele concrete. De regulă, acest moment este considerat acela în care sunt disponibile suficiente informații privind natura și impactul incidentului, nu momentul în care s-a aflat despre existența unui atac în general.

„În practică, e foarte posibil ca termenul de 72 de ore de la momentul la care s-a luat la cunoștință incidentul să nu poată fi respectat, pentru că operatorul nu reușește să adune toate informațiile relevante într-un interval atât de scurt. Nu am văzut să fi existat sancțiuni atâta timp cât a existat un interval rezonabil de la momentul producerii incidentului și operatorul a putut oferi o explicație justificată. Atâta timp cât există o justificare pentru nerespectarea termenului de 72 de ore, nu apar probleme, dar investigația nu trebuie să dureze nerezonabil de mult”, a subliniat Adriana Radu. 

O opțiune în acest caz ar fi ca operatorul să trimită mai multe notificări subsecvente, dacă există informații suficiente pentru a putea completa notificarea.

Un alt pas important este evaluarea nivelului de risc generat de incident, pentru a stabili dacă este necesară notificarea autorității și/sau a persoanelor vizate.

„În practică e recomandabil sa fie folosită metodologia ENISA pentru nivelul de risc plus Orientările nr. 9/2022 privind notificarea încălcării securității datelor cu caracter personal în temeiul RGPD și Orientările nr. 1/2021 privind exemplele de notificarea încălcării securității datelor cu caracter personal emise de EDPB”, a sugerat Adriana Radu. 

„Problema” cu instrumentul ENISA este că indicele metric de tipul „risc scăzut”, „risc mediu” etc, nu există în GDPR. Totuși „mai sunt orientările, unde sunt tot felul de exemple, recomandări și interpretări care sunt foarte utile în practică. Dacă combinați ENISA cu orientările, sunt șanse mari să aveți o imagine destul de argumentată la nivel de risc”, a completat Adriana Radu.

Odată notificată cu privire la breșă, autoritatea poate solicita explicații cu privire la modul în care a fost cuantificat nivelul de risc.

„Dacă operatorul a descoperit o vulnerabilitate de securitate, dar a investigat și nu are dovezi din care să rezulte că vulnerabilitatea a fost exploatată, în opinia mea nu sunt îndeplinite cerințele art. 34 din GDPR cu privire la luarea la cunoștință despre încălcarea securității (..) În opinia mea, incidentul nu ar trebui inclus în evidențele respective, însă ar trebui păstrată o analiză a situației și a argumentelor care au stat la baza deciziei de a nu considera că ne aflăm în ipoteza unei încălcări a securității datelor”, a subliniat avocata. 

Ce informații ar trebui să conțină notificarea către ANSPDCP

În ipoteza în care operatorul realizează că vulnerabilitatea a fost exploatată, în mod normal, la momentul depunerii notificării la ANSPDCP ar trebui să existe un raport al incidentului, cu următoarea structură (în linii mari): 

• rezumat;
• timeline (n.r. cronologia) precis al întregului eveniment, de la momentul la care s-a produs incidentul, la momentul depistării lui, respectiv finalizarea lui. Mai mult, trebuie detaliat și ce acțiuni de remediere au fost făcute (de exemplu - operatorul a schimbat parolele). 

De asemenea, avocata spune că ar fi bine ca operatorul să aibă și detaliile incidentului, cu focus pe descriere - impact, servicii și sisteme afectate, utilizatori afectați, date afectate, acțiuni imediate de răspuns pentru gestionarea incidentului și reducerea impactului. 

„Cea mai mare parte din aceste informații trebuie să le puneți în notificarea de breșă pe care o veți face însă e bine să aveți toate detaliile pentru că de cele mai multe ori o să primiți întrebări suplimentare de la autoritate și e bine să le anticipați”, a explicat Adriana Radu. 

După finalizarea incidentului, este recomandată efectuarea unei evaluări post-eveniment, cu descrierea cauzelor, a măsurilor adoptate și a celor planificate pentru prevenirea unor situații similare.

„Nu s-a terminat incidentul și gata. Trebuie să-mi dau seama care a fost cauza și ce trebuie să schimb în organizație pentru a preveni incidente viitoare. Toate aceste detalii trebuie incluse în raportul de investigație și urmărite ulterior pentru implementarea planului (..) Acolo unde au existat planuri post-incident, nu am văzut ca autoritatea să întrebe dacă acestea au fost implementate, dar nu poți exclude această posibilitate. Dacă apare o breșă ulterioară pe același sistem, sunt șanse mari să se ceară explicații pentru neimplementarea măsurilor”, a adăugat avocata.

În marea majoritate a situațiilor, în cel mult două luni de la primirea notificării, autoritatea a cerut informații suplimentare. Acestea pot include: 

• cauza exactă a incidentului;
• vulnerabilitatea exploatată, cu focus pe detalii tehnice;
• raportul investigației privind incidentul de securitate notificat;
• evaluarea privind riscul pentru drepturile și libertățile persoanelor;
• politici și proceduri existente la nivelul operatorului relevante pentru cauza incidentului;
• măsurile tehnice și organizatorice implementate de operator (defalcat), atât anterior producerii incidentului de încălcare a securității datelor cu caracter personal, cât și după luarea la cunoștință despre incidentul produs.