Cînd am citit prima dată draftul GDPR în aprilie 2015, am zis: „Uau. Fain. În sfîrșit se mai face puțină lumină pe subiectul ăsta„. Articolul 30 din acea versiune descria conținutul minimal al „politicii de securitate„ precum și măsurile tehnice:

• să împiedice accesul persoanelor neautorizate la echipamentele de prelucrare a datelor utilizate pentru prelucrarea datelor cu caracter personal (controlul accesului la echipamente);
• să împiedice orice citire, copiere, modificare sau eliminare neautorizată a suporților de date (controlul suporților de date);
• să împiedice introducerea neautorizată de date și inspectarea, modificarea sau ștergerea neautorizată a datelor cu caracter personal stocate (controlul stocării);
• să împiedice utilizarea sistemelor de prelucrare automată a datelor de către persoane neautorizate cu ajutorul echipamentelor de comunicare a datelor (controlul utilizatorului);
• să asigure faptul că persoanele autorizate să utilizeze un sistem de prelucrare automată a datelor au acces numai la datele pentru care au autorizare (controlul accesului la date);
• să asigure că este posibilă verificarea și identificarea organismelor cărora le-au fost transmise sau puse la dispoziție sau s-ar putea să le fie transmise sau puse la dispoziție date cu caracter personal utilizându-se echipamente de comunicare a datelor (controlul comunicării);
• să asigure că este posibil ulterior să se verifice și să se identifice datele cu caracter personal introduse în sistemele de prelucrare automată a datelor, momentul introducerii acestora și entitatea care le-a introdus (controlul introducerii datelor);
• să împiedice citirea, copierea, modificarea sau ștergerea neautorizată a datelor cu caracter personal în timpul transferurilor de date cu caracter personal sau în timpul transportării suporturilor de date (controlul transportării);
• să asigure posibilitatea recuperării sistemelor instalate în cazul unei întreruperi (recuperarea);
• să asigure funcționarea sistemului, raportarea defecțiunilor de funcționare (fiabilitate) și imposibilitatea coruperii datelor cu caracter personal stocate, din cauza funcționării defectuoase a sistemului (integritate).

Cînd am citit apoi versiunea finală din aprilie 2016, am zis: „OK. S-a renunțat la nominalizarea controalelor și s-a mers pe sintagma „state of the art„. Probabil e mai bine așa. Dar de ce or folosi „data protection„ în loc de „privacy?„

În  cei doi ani care au trecut de atunci, am citit de nenumărate ori GDPR. Am citit cursuri, opinii profesionale, academice (articole), alte materiale, opinii/discuții pe Linkedin (unele grozav de bune, altele banale), inclusiv de natură juridică (chiar și decizii CJEU/ECHR). Am mai citit și următoarele:

• Opinion 4/2007 on the concept of personal data (WP 136)
• Opinion 06/2014 on the notion of legitimate interests of the data controller
• Guidelines on Consent under Regulation 2016/679, wp259
• Guidelines on Transparency under Regulation 2016/679, wp260
• Guidelines on Personal data breach notification under Regulation 2016/679, wp250
• Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679, wp251
• Guidelines on the right to „data portability”, wp242rev.01
• Guidelines on Data Protection Officers (‘DPOs’), wp243rev.01
• Guidelines on The Lead Supervisory Authority, wp244rev.01
• Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is „likely to result in a high risk” for the purposes of Regulation 2016/679, wp248rev.01
• WP 169, Opinion 1/2010 on the concepts of ‘controller’ and ‘processor’.
• Opinion 01/2014 on the application of necessity and proportionality
• concepts and data protection within the law enforcement sector
• Opinion 15/2011 on the definition of consent
• Opinion 2/2010 on online behavioural advertising
• Opinion 5/2004 on unsolicited communications for marketing purposes
• Opinion 13/2011 on Geolocation services on smart mobile devices
• Opinion 05/2012 on Cloud Computing
• Opinion 5/2009 on online social networking WP 163)
• Opinion 02/2013 on apps on smart devices

Nu mi-am propus să devin vreun „expert GDPR„…Mi-am produs singur dileme practice încercînd să „ambalez„ cerințele GDPR în aceeași „cutie„ cu managementul riscurilor și securitatea IT așa după cum înțeleg eu cerințele Regulamentului.

Din perspectiva auditului, subiectele tehnice, cele legate de evaluarea riscurilor,  securitate, guvernare, management proiecte îmi sînt destul de clare: si în teorie și în practică (cred). Cum companiile sînt însă diferite și funcționează în medii economice diferite, cînd m-am apucat propriu zis de treabă, aplicat, am început să descopăr conexiuni sau interpretări la care nu m-am gîndit în timpul lecturilor (am dat un anumit sens iar acum găsesc și altele). Acest tip de „frămîntări„ țin mai ales de latura juridică, dar asta nu înseamnă că pot să fac abstracție de ele: în cazul unei plîngeri se poate ajunge în fața unei instanțe și atunci cuvintele devin foarte importante. Mai importat însă, organizația este obligată să dovedească (adică să existe probe!) că respectă prinicpiile enunțate la Art. 5.

1. GDPR face referire atît la „date personale„ cît și la „categorii speciale de date cu caracter special„ (Art. 9) acestea din urmă fiind identificate: dezvăluie originea rasială sau etnică, opiniile politice, confesiunea religioasă sau convingerile filozofice sau apartenența la sindicate date genetice, date biometrice pentru identificarea unică a unei persoane fizice, date privind sănătatea sau date privind viața sexuală sau orientarea sexuală ale unei persoane fizice.. Alte „categorii de date personale„ însă nu sînt nominalizate. Ar fi fost mult mai clar și mai util dacă ar fi existat o „categorisire„ a datelor personale.

2. Cuvîntul „natură„ apare alăturat astfel:

• „natura datelor personale„(obiective/subiective? vezi mai jos explicațiile de la IAPP)
• „natura, contextul, domeniul de aplicare și scopurile prelucrării„; (probabil tipul prelucrării: manual/automatizat/ambele?)
• „natura datelor personale care trebuie protejate„; (poate fi vorba de „categorii”? sau poate fi vorba de modul cum sînt colectate/prelucrate: letric/digital/ambele?)
• „natura încălcării securității datelor cu caracter personal„

În suportul de curs CIPP/E de la IAPP despre „natură„ se spune:

„Orice tip de declarații despre o persoană, atât obiective, cât și subiective, pot fi considerate date cu caracter personal. De exemplu, înregistrările privind ocuparea forței de muncă deținute de un angajator în legătură cu un angajat pot include diferite tipuri de declarații obiective și subiective. Exemple de declarații obiective sunt: „[angajatul] are o diplomă în domeniul informaticii” sau „[angajat] este șeful IT-ului „. Afirmațiile subiective sunt cele care exprimă opiniile cuiva sau o evaluare. Un exemplu de afirmație subiectivă este că „[angajatul] este un lucrător bun și merită promovarea”. Informațiile nu trebuie să fie valabile pentru a fi considerate date cu caracter personal.„ (traducerea mea)

Recunosc că tot nu am înțeles cum să interpretez „natura„

3. Avem definită „prelucrarea„ ca fiind „operațiune sau set de operațiuni efectuate asupra datelor cu caracter personal sau asupra seturilor de date cu caracter personal….„ dar în textul GDPR se folosește „activități de prelucrare„ care nu sînt definite/explicate/enumerate. Pare a fi o tautologie…

Art. 2 : „Prezentul regulament se aplică prelucrării datelor cu caracter personal, efectuată total sau parțial prin mijloace automatizate, precum și prelucrării prin alte mijloace decât cele automatizate a datelor cu caracter personal care fac parte dintr-un sistem de evidență a datelor sau care sunt destinate să facă parte dintr-un sistem de evidență a datelor.„

Art. 30 „Evidențele activităților de prelucrare„. Din Ghidul WP29 pentru PIA deducem că „operațiuni„ și „activități„ sînt sinonime.

La prima lectură e clar: prelucrare este „inima„ oricărui proces: intrări-prelucrări-ieșiri. Există însă documente (WP29) și exemple în care „prelucrarea„ este descrisă ca fiind de fapt „procesul„ și nu operația/activitatea….

4. Art5 – „Principii legate de prelucrarea datelor cu caracter personal„…vs. Art. 25 – „destinate să pună în aplicare în mod eficient principiile de protecție a datelor” unde se dă ca exemplu „reducerea la minim a datelor„ care apare ca principiu de prelucrare la Art. 5.

Recital 78 ne duce la alt principiu de …protecție: „Pentru a fi în măsură să demonstreze conformitatea cu prezentul regulament, operatorul ar trebui să adopte politici interne și să pună în aplicare măsuri care să respecte în special principiul protecției datelor începând cu momentul conceperii și cel al protecției implicite a datelor.„ Dar același recital consideră că „reducerea la minim a datelor„ nu mai este „principiu„ ci „măsură de securitate„: „Astfel de măsuri ar putea consta, printre altele, în reducerea la minimum a prelucrării datelor cu caracter personal„.

5. În cazul „încălcării măsurilor de securitate„ definiția nu include „lipsa disponibilități/availability„ în această categorie, deși ea figurează ca măsură de securitate. Opinia WP250 este că, de la caz la caz, lipsa disponibilității ar trebui raportată Autorității. Repet: chiar dacă în definiție nu apare. Ghidul WP 29 pentru DPIA  menționează doar trei riscuri pentru drepturile și libertățile persoanei vizate care trebuie gestionate: – acces nelegitim – modificări nedorite – dispariție date

În același ghid (DPIA), versiunea în limba română folosește pentru „envisaged„ același înțeles în două situații diferite: „măsurile deja preconizate„ respectiv „măsurile preconizate pentru a răspunde riscurilor„. În fapt este vorba de măsurile existente, iar dacă riscurile estimate sînt mare, de măsurile preconizate pentru diminuarea riscurilor.

Discutînd unele din cele de mai sus cu un bun prieten, acesta îmi spunea că sînt „prea analitic„ si că ar trebui să mă concentrez doar pe „spiritul GDPR„. Este posibil să fiu prea analitic. Nu spiritul GDPR îmi este neclar ci spiritul unor termeni :). Și asta din următoarele situații practice:

• trebuie să existe acel „proces pentru testarea, evaluarea și aprecierea periodice ale eficacității măsurilor tehnice și organizatorice pentru a garanta securitatea prelucrării.„;
• organizația trebuie să probeze că se respectă principiile de prelucrare;
• este posibil ca organizației (persoanei împuternicită) să i se solicite un „audit de conformitate„ (și DPO are responsabilități legate de audituri).