CELE MAI IMPORTANTE GREȘELI CARE SE FAC ÎN PROIECTELE GDPR

A fost o săptămână bogată în evenimente, întâlniri și multe dialoguri, prilejuite de aniversarea unui an de la ”celebrul 25 mai”. Un lucru de toată lauda, ținând cont de acalmia care încearcă să ne descurajeze, în special de prin ianuarie încoace…Iată dar o foarte bună ocazie pentru o recapitulare, la rece, a celor mai frecvente greșeli discutate la evenimentul GDPR Talks din 21 mai sau observate prin proiecte.

Desigur, vorbele din bătrâni ”a greși, e omenește” și  ”numai cine muncește, greșește” sunt perfect adevărate și în cazul nostru, iar o greșeală sesizată nu trebuie arătată cu degetul, căci nimeni nu are de câștigat. Observăm și arătăm cu luciditate greșelile doar cu bunul scop de a le explica și de a oferi soluții pentru demonstrarea responsabilității. Chiar dacă Autoritatea din România nu a apăsat încă pe claxonul amenzilor, emițând doar avertismente și măsuri corective, trebuie să depășim sindromul drobului de sare și să învățăm din greșeli devenind proactivi. Numai așa putem să respectăm cel de-al șaptelea principiu GDPR (așa cum consideră unii) și să devenim responsabili de responsabilitatea noastră.

Iată deci, fără a respecta o anumită ordine, câteva dintre cele mai importante greșeli din care trebuie să învățăm:

Lipsa unui plan de proiect – decizia de ”a face ceva pentru GDPR” s-a făcut de cele mai multe ori sub presiune, pasând responsabilitatea cuiva de la IT sau de la juridic, care s-au apucat de ce credeau că e mai urgent.. Desigur, orice poate conduce o echipă de acțiune, dar fără un proiect de implementare etapizat e greu să vezi capătul drumului și să eficientizezi demersurile de aliniere.

Nu s-a făcut nimic până la numirea unui DPO – asta a întârziat destul de multe ori lucrurile, pierzându-se timp prețios pentru demararea unor măsuri organizatorice, care putea fi luate și în absența unui DPO, acolo unde numirea acestuia e obligatorie.

Dificultăți legate de angajarea unui DPO – multă vreme, cei care aveau nevoie să angajeze un DPO, s-u confruntat cu probleme legate de lipsa unei fișe a postului oficială sau imposibilitatea înregistrării în aplicația Revisal a codului COR 242231 alocat pentru funcția de Responsabil cu protecția datelor cu caracter personal. Deși mulți m-au asigurat că această problemă a fost rezolvată, nu am găsit încă nici o sursă publică oficială de confirmare a acestui lucru.

Înțelegerea incorectă a noțiunii de date personale – definițiile din Art.4, preambulurile și ghidurile WP29 nu au rezolvat problema identificării corecte a datelor personale. Sunt multe site-uri care la Politica de Cookies declară că acestea nu folosesc datele personale. În mod sigur administratorii acestora nu au aflat că IP-ul este luat în considerare ca și data personal, s-au pur și simplu nu și-au bătut capul să își actualizeze politicile…

Dificultatea stabilirii rolului de Operator sau Procesator (Împuternicit…) – simpla analiză a faptului că o organizație determină scopul și mijloacele nu este suficientă pentru asumarea unui rol de Operator. Se fac încă multe confuzii între poziția de Procesator și cea de Operator Asociat sau Operator Independent (B2B). Se omite ideea, că aceeași organizație poate juca roluri diferite în prelucrarea datelor personale, în funcție de procesul de business care este analizat. Dar, așa cum aprecia și Cătălin Giulescu în discuțiile din cadrul evenimentului GDPR Talks: ”nu trebuie să ne cramponăm de asta. Dacă un împuternicit își asumă rol de operator, lăsați-l să și-l asume. În fond, un operator are mult mai multe obligații…”

Excesul de Consimțământ – se pune mult prea mult accentul pe obținerea acordului, în detrimentul celorlalte 5 temeiuri legale care pot justifica prelucrarea datelor personale. Poți evita nevoia obținerii consimțământului prin introducerea unei prevederi suplimentare într-un contract. Mai mult de atât, nu se ține cont de cerința ca un consimțământ să poată fi întotdeauna probat, dovedit, în ideea că el poate fi retras cu aceeași ușurință cu care a fost obținut.

Lipsa de transparență online – Multe dintre organizațiile care au un site web nu dau dovadă de transparență prin nepublicarea unei Politici de confidențialitate sau Notificări de prelucrare a datelor personale. Prezența unei pagini cu politica de Confidențialitate a organizației este o declarație publică de conformitate și o etichetă e încredere pentru modul în car se prelucrează datele cu caracter personal.

Neactualizarea conținutului  – Există îngrijorător de multe dintre site-urile care publică o Politică de Confidențialitate nu și-au actualizat conținutul, făcând referire la Legea 677/ 2001 sau afișând în continuare Numărul de înregistrare ca Operator Național de date personale. Acest lucru poate fi o reflectare a faptului că organizația căreia îi aparține site-ul nu a depus destule eforturi de asigurare a alinierii, omițând să actualizeze singurul conținut vizibil, menit să ateste public conformitatea și asumarea responsabilității pentru datele personale prelucrate.

Carențe ale paginilor de Internet – o mulțime de site-uri publice nu au o pagină de Termeni și Condiții, care să stabilească niște reguli de accesare și navigare online, deși asta nu este o cerință GDPR, ci o regulă de conduită pentru toate organizațiile prezente Internet.

Lipsa barei de cookies – Există multe site-uri care, deși au o pagină dedicată politicii de cookies, nu au o bară de cookies care să solicite acceptarea utilizării acestora înainte de începerea navigării pe site.

Acceptarea inutilă a Politicii de confidențialitate – Sunt multe site-uri care utilizează formulare online de colectare a datelor personale (înscrieri newsletter, pagina de contact, descărcări de documente, etc) și condiționează trimiterea acestor date de bifarea unei casete de acceptare a Politicii de confidențialitate. De ce să solicităm această aprobare? Este Politica mea ca Operator și este publică. Cel mult pot să fac o trimitere de informare a faptului că datele personale colectate prin intermediul formularului sunt procesate doar pentru scopul pentru care au fost colectate, conform Politicii de confidențialitate.

Lipsa de granularitate în solicitarea acordului – există un exces de utilizare a Interesului Legitim, ca bază legală pentru prelucrările de marketing, care în plus implică și terții, fără o abordare granulară a tipurilor de activități care se înscriu în această categorie de activități de procesare.

Abuzul de granularitate – se afișează pagini pop-up granulare, cu posibilitatea stabilirii de opțiuni, dar care apar cu casete de acceptare pre-bifate – o contradicție gravă a regulilor de solicitare/ obținere a consimțământului în spiritual GDPR.

Consimțământ condiționat fără posibilitate de opt-aut – marea majoritate a barelor de cookies oferă doar opțiunea de OK, cu condiționarea navigării în continuare de alegerea acestei opțiuni. Așa cum am subliniat și la prezentarea din cadrul GDPR Talks, nu tot ceea ce vechea lege ePrivacy permite, este acceptabil din punct de vedere GDPR, unde consimțământul de utilizare de cookies nu trebuie să fie condiționat de accesul la conținutul paginii. Desigur că utilizatorul trebuie să știe care sunt consecințele neacceptării de cookies, dar asta trebuie să fie opțiunea lui liber consimțită. Mai mult de atât, GDPR ne învață că un consimțământ obținut printr-un anumit procedeu, trebuie să poată fi retras la fel de simplu. Adică dacă pun pe bara de cookies o casetă de Accept, e absolut recomandabil să ofer și posibilitate de opt-out, prin afișarea unei casete de Reject.

Protecție vs. Securitate – există un grad ridicat de confuzie între securitatea datelor și protecția datelor personale. Protecția datelor implică ansamblul măsurilor ce pot fi luate pentru a le restabili în caz de pierdere sau de corupție. În timp ce securitatea datelor se referă la mecanismul de păstrare a datelor în siguranță, de la accesul și distribuirea neautorizate. Securitatea datelor protejează datele de accesul neautorizat care ar putea duce la corupția sau ștergerea datelor, În cazul în care strategia de securitate a datelor nu reușește, protecția datelor facilitează recuperarea copiilor de date curate.

Incidente vs. Breșe de securitate – În același timp, există confuzia între incidente de Securitate și breșe (sau încălcări ale datelor). Un incident poate fi orice eveniment care încalcă politicile de securitate sau de confidențialitate ale unei organizații și poate fi orice, de la o defectarea unei unități de memorie, la pierderea unui laptop ce conține baze de date personale. O încălcare a datelor, pe de altă parte, este un eveniment care a condus la o pierdere sau un furt de date, gravitatea pierderii fiind cuantificată de volumul și importanța datelor afectate. Prin Art.33 GDPR obligă organizațiile să raporteze o încălcare a datelor în maxim 72 de ore de la conștientizarea breșei, recomandând elaborarea unui plan de breșe și organizarea unei echipe de răspuns la încălcarea datelor. Una dintre îndatoririle acestei echipe este să țină o evidență strictă a incidentelor de Securitate, în ideea de a putea asocia ulterior apariția unei breșe de vulnerabilitatea sistemului care a condus la apariția ei.

Pot fi rezolvate toate aceste probleme? Cu siguranță că da, cu condiția ca toți cei implicați să își înțeleagă și să își asume responsabilitatea. Succesul unui proiect GDPR pe termen lung se bazează pe crearea unei culturi la nivel de organizație, în care oamenii se gândesc în primul rând la modul în care ar dori ca informațiile lor personale să fie procesate. Companiile trebuie să adopte această atitudine atunci când manipulează datele personale ale clienților, ale angajaților și ale altor subiecți. Nu este vorba doar despre amenințarea cu sancțiuni financiare. Este vorba de continuitate în business și de construirea unei atitudini de încredere.

Advertisements