Câteva considerații practice despre GDPR/ „Privacy by design and by default” în dezvoltarea de software

 

Autor Daniel Suciu

Acest material se adresează în special dezvoltatorilor din firmele mici, fără o structură organizatorică, funcții de suport dedicate sau o metodologie complexă in ajutor.

O să încep menționând că pentru a respecta cu adevărat principul de „Privacy by design and by default” pentru orice aplicție sau sistem not, trebuie avut în vedere scopul pentru care sunt folosite datele (personale), modul de prelucrare, de la acces, la prelucrările interne, stocare și distribuire precum și procesele operaționale, de operare, administrare și de suport, licențiere, actualizările aplicației, instruirea celor ce o operează și administrează…

Mai jos găsiți câteva exemple de cerințe sau doar bune practici, din experiența mea personală – de fost programator, tester, business analyst,  QA, admin, PM, manager… și acum consultant GDPR- care pot ajuta la dezvoltarea unei aplicații în acord cu aceste principii. Nu este o listă exhustivă și nici obligatorie, dar poate fi un punct de plecare pentru analiză. Evident ca lista poate fi mult mai lungă sau mai bine organizată. La final o să incerc să creez și să mențin o listă cu materialele mai formale pe aceasta temă, pe baza recomandărilor si sugestiilor primite.

Câteva considerații generale

  • Atât GDPR-ul cât și recomandările specifice implică necesitatea demonstrării respectării acestor principii din faza de design considerând toata durata de viață a produsului (SLC) nu doar dezvoltarea, iar dezvoltarea ar fi indicat să conțină și partea de analiză, cerințe, design, testare… stiu, pare evident
  • Trebuie să existe documentație – nu doar cea de produs (pentru useri și administrare/mentenanță) ci și pentru proiect/ development, incepând de la cerințe)
  • Cerințele inițiale ale aplicației/serviciului trebuie să conțină referințe la principiile GDPR ce trebuie avute in vedere de la bun început (câteva articole din GDPR ce pot avea legătură și ar merita citite sunt 5,7,11, 12, 15-22, 25,32,35,44…)
  • Trebuie să existe o trasabilitate pentru modul in care acestea sunt implementate in produs… sau proces, prin care să se poata demonstra ce funcțiune implementează o anumită cerință
  • Ar fi bine să existe evidente ca este urmata o metodologie (incluzând toate activitatile de dezvoltare). Se acceptă și Agile și DevOps, dar nu varianta fară arhitectură/design și documentație…

Acum, mai la concret:

–          despre Baze de date

  • Separarea informațiilor despre utilizatori de cele de business, eventual și cu criptarea celor ce pot identifica utilizatorii este utilă;
  • Normalizarea datelor ajută atât la consisten,a datelor, cât și la minimizarea impactului in cazul breșelor de securitate. Posibilitatea de a utiliza datele ca întreg și a identifica subiecții scade;
  • Normalizarea ajută și la implementarea unor măsuri de siguranță sau chiar de acces granular pentru anumite date considerate sensibile;
  • Ar fi indicat să existe un Data dictionary , cu descrierea datelor – ajută la identificare și mapare și este util în definirea scopului acestora de la început și la demonstrarea atât a minimizării datelor cât și a limitării scopului;
  • Stergerea și arhivarea automată a datelor, bazate pe anumite reguli, ar trebui avută in vedere din stadiul de design. Sigur va fi nevoie.

–          despre Managementul utilizatorilor și drepturilor

  • Managementul utilizatorilor ar trebui facut pe baza de roluri, cu drepturi bine definite pentru fiecare rol , luând în cosiderare și datele, nu doar funcțiile;
  • Managementul utilizatorilor și a drepturilor nu ar trebui limitat doar la utilizatorii finali, ci și la cei ce se vor ocupa de administrare, mentenanță…
  • Definirea utilizatorilor de la nivel de sistem de operare, baze de date, aplicație și utilizarea lor de la bun inceput pot face posibile operațiile de mentenanță sau administrare fără drepturi de a acces la continuțul bazelor de date și pot limita riscul de a produce incidente din greșeală (acordâdu-se drepturi doar pentru nevoile funcțiilor respective);
  • Folosind doar conturi de „root”/ „admin” pentru instalare, dezvoltare, administrare și mentenanță face inutile eforturile de „securizare” a aplicației;
  • Nu mai pomenesc de „utilizatorii” la nivel de aplicatie/modul, de care nu se prea știe, care in multe aplicații folosesc tehnologii ce necesită numele de utilizator și parola in clar;
  • Bănuiesc că schimbarea parolelor inițiale ale tuturor produselor COTS folosite este evidentă… nu că nu se uită de multe ori.

–          despre Corectitudinea datelor

  • Validarea tranzacțiilor end2end pentru a preîntâmpina erorile sau inconsistențele în date datorită prelucrărilor incomplete;
  • Ar trebui avute in vedere validări ale acestora (atât ca tip de date, valori căt și ca reguli de business, în relație cu alte date) începând de la colectare, pentru a preveni introducerile greșite;
  • Baza de date ar trebui să conțină informatii atât despre vechimea datelor, cât și a ultimelor operații efectuate pe ele = problema este de a determina pentru ce entități este nevoie și pentru ce operațiuni.

–          despre Securitate

  • Managementul sesiunilor e unul din aspectele de securitate ce poate preveni problemele;
  • Autentificarea utilizatorilor folosind cele mai potrivite metode (acum au apărut multe dar tot username-ul și parola „rules”), dar măcar existența unor politici minime pentru parole (care ar fi chiar indicat să nu se pastreze in clar… evident, nu?) și utilizarea a doi factori pentru autentificare ar fi bune;
  • Managementul licențelor produselor COTS folosite și a update-urilor acestora este un alt aspect de avut in vedere;
  • Nu uitati cerintele de infrastructură (hardware, software, retea) necesare funcționării aplicației, care pot introduce vulnerabilități, oricât de securizată ar fi aplicația;
  • Pentru administrare, pe lângă utilizarea conturilor dedicate, cu permisiuni specifice și limitate, ar fi indicat să fie identificate modalități de lucru la distanță printr-un canal sigur – aspect care mi se pare cel mai neglijat;
  • Auditarea operațiilor efectuate de clienți asupra datelor este un factor ce permite o analiză mult mai ușoară in caz de breșe de securitate, plus responsabilizarea celor ce utilizează aplicația. Pentru cei ce nu fac diferența, spre deosebire de log-urile tehnice, auditarea este un proces similar dar informațiile stocate sunt altele, de genul ce utilizator a efecutuat o anumită operație și când. Salvarea acestor informații la nivel de bază de date face utilizarea lor mai ușoara, dar nu este obligatorie.

–          Back-up & restore

  • In primul rând să nu se uite de procesul de restaurare, nu doar de back-up… ceea ce in general (macar 99%) nu inseamnă doar să pui baza de date veche in locul celei corupte, pierdute…;
  • In cel de-al doilea rând, back-upul ar trebui să nu fie limitat la date, ci și la aplicatie, fișierele de configurare, log-uri… pentru a permite restaurarea SERVICIILOR in caz de probleme și analiza incidentelor atunci cândva fi cazul (sigur va fi);
  • Combinarea mai multor tipuri de back-up pentru diferite tipuri de informații este o alternativă de considerat, de exemplu back-ul frecvent al log-urilor permite obținerea datelor despre tranzacțiile efectuate de la ultimul back-up al datelor (care de multe ori nu se poate face foarte des);
  • Daca datele sunt distribuite sau unele pot fi salvate in dispozitivele clientilor, o metoda de back-up pentru aceasta trebuie luată in considerare.

Alte chestii specifice GDPR

care nu tin neapărat de bune practici generale in dezvolatarea, administrarea și operarea unei aplicatii:

  • Introducerea in aplicație a functiilor ce permit exercitarea drepturilor persoanelor vizate, accesul la informatii (istoricul datelr și tranzactiilor), actualizarea informatiilor, exportul datelor, stergerea datelor- și chiar a contului;
  • Cel mai delicat drept este cel de restrictionare a prelucrării, in care datele trebuie marcate ca restricționate – nu șterse, dar să nu se permita nicio prelucrare. Atentie, accesul la date este o prelucrare. Implementarea drepturilor de acces la date cât mai granular face mai usoara implementarea – datele pentru un anumit client marcat nu vor avea nici dreptul de „view”, permițând doar accesul administratorului pentru taskurile de mentenanță;
  • Pentru a ușura exercitarea drepturilor, sau obținerea consimțământului, acolo unde este nevoie, o metodă ar fi utilizarea unor soluții dedicate, sau introducerea acestora in functionalitățile aplicației, la nivelul customizării preferințelor conturilor, care oricum există în majoritatea aplicațiilor;
  • Un amănunt important este obligativitatea ca retragerea unui consimțământ trebuie să fie la fel de ușoară ca acordarea lui. Pentru aceasta pozitionarea celor două opțiuni în același loc este o metoda bună de a rezolva problema;
  • A nu se uita că toate operațiile de exercitare ale drepturilor clienților, obținerea și retragerea consimțământului, obiecțiile la prelucrare… trebuie să fie salvate pentru a le putea demonstra oricând.

Alte matriale utile

GDPR explicitat (9): Data protection by design and by default – de la Cloudmania

THE CNIL’S GUIDES – 2018 EDITION- SECURITY OF PERSONAL DATA  – de la CNIL –autoritatea Franceză in domeniu ( document în Engleză)

Software development with Data Protection by Design and by Default – de la Datatilsynet

Notă: materialele au fost primite după redactarea articolului, și conțin informații suplimentare utile, ce nu au fost adresate în acest material

Despre autor: Daniel SUCIU este specialist în managementul proceselor, managementul schimbării, managementul riscului, auditul intern, guvernanța și administrarea datelor, dezvoltarea de software, operarea și suportul IT, securitatea informațiilor dar și managementul proiectelor și al echipelor crossfunționale, cu rezultate măsurabile la intersecția sistemelor, tehnologiei, proceselor, oamenilor și datelor. 30 de ani de experiențe de lucru între IT / tehnologie si echipele de business, între clienți, parteneri / furnizori, angajați și conducere. Nu în ultimul rând, certificat ca ofițer cu protecția datelor, fiind implicat în conformarea la GDPR a mai multor organizații, din diferite domenii: învățământ, ONG, turism, medical, servicii IT, afaceri sau comerț online.

Advertisements

Despre GDPR și respectul pentru interlocutor

Articol publicat pe siteul cloud☁mania în data de  10 Iulie 2018. Autor: Anca Crahmaliuc

Anca CRAHMALIUC

 

Anca Crahmaliuc este expert în domeniul Corporate Affairs, PR și Marketing B2B, cu experiență exhaustivă in coordonarea de activități și echipe Marketing & Communications în organizații multinaționale. Este absolventă a programului MBA dezvoltat de Tiffin University în parteneriat cu Universitatea București.

Mai există viață în marketingul B2B după 25 mai 2018?

Cu siguranță. Intrarea în funcțiune a regulamentului european referitor la protecția datelor personale nu numai că nu diminuează valoarea acțiunilor de marketing, ci o crește semnificativ din punct de vedere calitativ. Cum? Prin credibilizare și eficientizare.

Este evident că, mai ales în ultimul deceniu, evoluția amețitoare a mijloacelor electronice de comunicare a condus la o creștere exponențială a mesajelor de marketing. Multe, tot mai multe. Le citește cineva? Nu știm și nu contează. Să fie cât mai multe, adresate cât mai multor persoane. Sunt aceste persoane în grupul nostru țintă? Nu prea știm și nici nu prea contează.

Dacă sunt mulți, poate s-or și nimeri destui care să fie între cei care ne-ar putea fi potențiali clienți. Nu cumva îi spamăm? N-au decât să-și pună filtre… Și dacă nu știu să facă asta? Atunci să șteargă mesajele și gata…

Am consemnat o succesiune de posibile întrebări și răspunsuri schimbate în ultimii ani între oamenii din departamentele de vânzări și marketing dintr-o organizație din orice industrie. Vânzările sunt esențiale pentru supraviețuirea companiei. Deci, să facem cât mai multe vânzări. Eventuale obiecții ridicate timid pot fi interpretate ca o lipsă de interes pentru soarta firmei…deci nu le mai ridicăm. Și totuși….ce șanse sunt ca o persoană complet neinteresată de produsele noastre să le și cumpere? Nu cumva agresând-o cu informații nesolicitate vom genera chiar o reacție de adversitate?

Prevederile GDPR se aplică în orice situație sunt prelucrate „date cu caracter personal”. Acest lucru înseamnă că ele includ toate persoanele identificate în mod direct sau indirect, și chiar dacă ele au alocări profesionale declarate. Pe scurt, dacă dețineți numele și un număr de telefon și/sau o adresă de email ale unui contact de business, ele intră sub incidența regulilor GDPR.

Este nevoie ca orice acțiune de marketing B2B să se bazeze pe consimțământ?

Nu chiar totdeauna. Consimțământul este o bază legală pentru procesarea datelor, dar pot exista situații în care acțiuni de marketing B2B să fie justificate de „interese legitime”. Chiar și în acest caz însă, uneori, e nevoie de consimțământ pentru a respecta prevederile Privacy and Electronic Communications Regulations cunoscut și ca ePrivacy.

Când ne putem baza în acțiunile de marketing B2B pe interesul legitim?

Interesul legitim poate justifica activități de marketing B2B dacă puteți arăta că modul în care folosiți datele personale este proporționat, are impact minim asupra intimității oamenilor, iar probabilitatea ca adresanții mesajelor de marketing să fie surprinși de acțiunile dv sau chiar să obiecteze față de acestea să fie minimă – dar numai cu condiția să nu intrați sub incidența ePrivacy. GDPR nu înlocuiește ePrivacy – trebuie să respectați prevederile ambelor prevederi legislative în activitățile dv. de marketing B2B.

UE este pe cale să înlocuiască actuala lege privind ePrivacy cu noua ePrivacy Regulation (ePR). Cu toate acestea, noul ePR nu este încă aprobat și, în consecință, continuă să se aplice actualele reguli ePrivacy (cu o nouă definiție pentru consimțământ) până când noul ePR va fi finalizat.

Consimțământul implică punerea la dispoziția persoanelor a unor mijloace reale de alegere și control. Un consimțământ autentic responsabilizează persoana care îl oferă, construiește o relație bazată pe încredere și angajament și vă consolidează reputația. Oferirea consimțământului trebuie să fie evidentă și necesită o acțiune pozitivă, manifestată prin opt-in. Solicitarea consimțământului trebuie să fie proeminentă, neîngrădită de alți termeni sau condiționări, formulate concis, ușor de înțeles și utilizat de către adresant. Operatorul care cere consimțământul trebuie să-și comunice numele, scopurile și tipurile de activități de prelucrare a datelor cu caracter personal. Nu în ultimul rând, celui care a oferit consimțământul trebuie să i se garanteze posibilitatea de a-l retrage ușor, în orice moment dorește acest lucru.

Cum și cui trimitem mesaje de marketing B2B?

Comercianții individuali și unii parteneri sunt tratați ca persoane fizice așa că puteți să le trimiteți mesaje de marketing numai pe bază de consimțământ exprimat explicit sau dacă au cumpărat un produs similar de la dv în trecut și nu au activat opțiunea opt-out când le-ați oferit această posibilitate. Trebuie totuși să includeți în mesaj opțiunile de „opt-out” sau „unsubscribe”.

Puteți transmite mesaje de marketing către orice instituție publică sau privată (de exemplu pe adrese de mail de tip office@organizatie.xxx). Este, totuși, recomandabil și uzual în sensul bunelor practici de business să aveți o listă de tip „nu trimite mesaj” cuprinzând organizațiile care obiectează sau își exprimă opțiunea de opt out, și să aveți grijă să verificați că nu se regăsește în nicio campanie de marketing pe care o desfășurați.

Atunci când trimiteți pe mail mesaje de marketing către angajații oricărei organizații care au adrese de business personale (de exemplu prenume.nume@organizație.xxx) se aplică toate prevederile GDPR.

Ce se întâmplă cu telemarketingul?

Puteți apela telefonic orice organizație de la care ați obținut consimțământul în acest sens, de exemplu prin bifarea opțiunii „opt in”. De asemenea, puteți telefona la orice organizație aflată pe liste publice, cu condiția ca acestea să nu se fi opus în trecut să le contactați. Și în acest caz se impune existența unei liste de tip „nu suna”.

Regulile privind apelurile automate sunt mai stricte. Utilizarea sistemelor de apelare automată, cu redarea unui mesaj înregistrat, nu se poate face în absența unui consimțământ explicit referitor la acest tip de abordare. Consimțământul general dat pentru acțiuni de marketing sau chiar pentru apeluri directe nu acoperă apelurile automate.

În mod evident, aceste prevederi sunt de mult bun simț în business. Ce valoare poate avea un mesaj nedorit sau, și mai grav, transmis împotriva dorinței adresantului? Cu siguranță, nu numai că nu ajută vânzările sau notorietatea companiei, ci le ruinează…

…dar cu newsletter-ele?

Trimiterea de newslettere și campaniile de emailing în general sunt asimilate acțiunilor generale de marketing B2B. În consecință, procesarea datelor cu caracter personal implicate necesită acordul explicit. Procesarea este permisă pe bază de consimțământ sau o justificare legală. De exemplu, o astfel de situație se întâlnește când între cei care trimit și cei care primesc mesajele de marketing exista o relație relevantă, proporționată. Comunicarea cu clienții existenți sau persoanele pentru care se prestează anumite servicii ar putea să se desfășoare fără consimțământ.

De asemenea, dacă o companie are un interes justificat pentru a se prezenta pentru prima data în fața unor potențiali clienți (cold acquisition) o poate face prin email marketing fără consimțământ. Aceștia din urmă își pot exprima opțiunea de a nu mai primi informații prin newsletter sau email, respectiv de a nu li se folosi datele pentru scopuri de marketing. Trebuie avut în vedere că prin coroborarea articolului 95 din GDPR cu articolul 13, paragraf 1 din directive ePrivacy 2002/58 reiese că în acest moment, emailingul nu se poate realiza decât pe bază de consimțământ.

Să recapitulăm

Trebuie să le spuneți oamenilor:

  • ce faceți cu datele lor,
  • care sunt scopurile pentru care procesați datele,
  • care este baza legală care permite procesarea informațiilor
  • cât timp doriți să păstrați datele cu caracter personal
  • cu cine partajați informațiile despre ei

Dacă faceți acțiuni de marketing direct în care vă bazați pe interesul legitim, adresanții au în mod absolut dreptul de a obiecta și sunteți obligați să opriți procesarea datelor care îi privesc.

Dacă acțiunile dv de marketing se desfășoară pe bază de consimțământ, persoanele care l-au oferit au dreptul să și-l retragă în orice moment. Atunci, trebuie să opriți procesarea. În fond, GDPR este despre modul în care trebuie să ne purtăm unii cu alții. Ce ție nu-ți place, altuia nu-i face… că aproape sigur nu-i place.

GDPR va implica unele costuri suplimentare și pe partea de marketing. Pe de-altă parte, vor fi mai bine folosiți banii irosiți în construirea de baze de date nerelevante și campanii gândite strict din perspective cantitative. Rata de răspuns infimă a campaniilor de emailing sau dialogurile tensionate purtate de operatorii de telemarketing spun fără echivoc același lucru: și marketingul B2B trebuie făcut cu respect pentru interlocutor.

Acest articol a fost publicat în ”Ghidul GDPR pe Verticale” din cea de-a treia ediție a Catalogului GDPR, Iunie 2018, pag. 47-50.