Ce ar trebui sa stie inginerii de software despre GDPR?

Acest subiect este unul urias, astfel incat ne vom concentra exclusiv pe procesul de creare de noi solutii software. Este mult de spus despre asistenta organizatorica si legalitatea sistemelor, dar ele sunt extrem de dependente ca punct de plecare. GDPR nu permite multe exceptii de la reguli, astfel incat atat marile, cat si intreprinderile mici, organizatiile non-profit si toate organizatiile guvernamentale trebuie sa cunoasca principalele puncte cheie.

Un punct cheie al Regulamentului este dat de transparenta prelucrarilor datelor cu caracter personal in raport de persoanele vizate. Cand aveti un registru de exemplu, o baza de date care contine date de identificare personala, GDPR impune transparenta in utilizarea acestora. Acest lucru inseamna ca persoanele ale caror date sunt colectate ar trebui sa fie capabile de a afla ceea ce se colecteza, in ce scop, cine are acces la date si cat timp se vor afla datele cu caracter personal in cadrul sistemelor. Pentru a face fata cu aceasta cerinta, in mod firesc ar trebui sa se cunoasca toate aceste lucruri si sa fie documentate. In paralel cu acest principiu, trebuie sa se ofere un acces facil la datele cu caracter personal. Persoanele vizate ar trebui sa poata verifica, corecta, exporta, muta si sterge datele lor la fel de usor precum incredintarea lor.

Un alt subiect important este reprezentat de privacy by design/default. Privacy by default inseamna o multime de lucruri, dar in esenta, este menit a proteja datele cu caracter personal prin controale adecvate. Acest lucru necesita de obicei, de exemplu, piste de audit clare: cine, ce, cand a facut si mai ales cine are acces la datele cu caracter personal. In plus, ar trebui sa se acorde o atentie sporita atunci cand datele cu caracter personal sunt stocate si atunci cand se afla in tranzit intre diferite straturi si se aplica metode de criptare adecvate pentru a evita scurgerea datelor cu caracter personal din sistem.

Ar trebui sa existe, de asemenea, o baza legala pentru prelucrarea datelor cu caracter personal, ceea ce inseamna mai exact aspectul care va ofera dreptul de a colecta si de a prelucra informatiile. Baza legala pentru prelucrarea datelor cu caracter personal, de exemplu, ar putea fi o dispozitie legala, care impune colectarea si stocarea datelor cu caracter personal pentru o perioada de timp. Baza legala pentru prelucrarea datelor cu caracter personal poate fi un contract, acord sau tranzactie.

Puteti solicita consimtamantul pentru a colecta si prelucra date personale, dar GDPR impune cerinte suplimentare in acest caz. Nu este acceptabila o caseta de selectare verificata deja cu o declaratie ca Accept ca informatiile mele pot fi utilizate in scopuri de marketing. Acordul trebuie sa fie clar, precis si usor de inteles si nu poate fi pre-stabilit. Ar trebui sa fie la fel de usor retragerea/revocarea consimtamantului. Designerii de software nu pot decide niciuna dintre aceste chestiuni pe cont propriu, motiv pentru care trebuie sa discute cu oricine detine cunostinte in domeniu.

In cazul in care membrii echipei care construiesc software-ul au acces la datele personale in timpul procesului, acestia devin persoane imputernicite de operatorul de date cu caracter personal si sunt supusi acelorasi sanctiuni si responsabilitati. Acelasi lucru este valabil si pentru echipa de operatiuni, daca are acces la bazele de date care contin date cu caracter personal. Este insa posibil sa construiti si sa operati de cele mai multe ori sisteme fara accesarea datelor cu caracter personal ale clientului operator de date cu caracter personal.

Recunoasterea informatiilor de identificare personala

GDPR este interesat doar de informatii de identificare personala. GDPR nu se aplica in cazul datelor care nu sunt atasate unei persoane, cum ar fi datele despre produs sau informatiile contabile.

GDPR identifica doua clase de date cu caracter personal. Exista date care pot fi utilizate pentru a identifica o persoana, spre exemplu, CID, adresa de e-mail sau orice identificatori conectati direct la acestea, cum ar fi istoricul achizitiilor. Apoi, exista date cu caracter personal speciale, cum ar fi informatii medicale/sanatate, religie, orientare sexuala etc.

Stiati ca: Potrivit GDPR, combinatii de informatii care nu pot fi unice in mod singular au potential de a identifica un individ. Deci datele cu caracter personal includ, de asemenea, identitati care pot fi deduse din valori cum ar fi codul postal, de calatorie, sau multiple locatii, cum ar fi puncte de cumparare. Seturile mici de date si combinatiile de valori rare pot face ca identificarea sa fie mai usoara.

De vreme ce orice informatii anexate sau colectate de la o persoana vizata sunt protejate in conformitate cu GDPR, cele mai multe baze de date vor contine date cu caracter personal, cu unele exceptii. Nu ar trebui protejate doar numerele de securitate sociala si numerele cardurilor de credit.

Au existat o multime de discutii despre jurnalele de acces sau de auditare etc. care contin adrese IP sau chei surogate. Acestea sunt date cu caracter personal? Sunt ele inregistrate? GDPR se extinde si la acestea? Cat de mult trebuie ele protejate? Acest tip de informatii ar putea si ar trebui sa fie protejate intr-o anumita masura, in functie de cat de multe daune ar provoca o incalcare a datelor.

Proiectarea din momentul conceperii

Cel mai ieftin mod de a avea software conform cu GDPR este de a construi cerintele in interiorul sau. Cat de cuprinzator ar trebui sa se faca acest lucru depinde de nivelul de risc al sistemului special in cauza:

• Sistemul contine date cu caracter special?
• Sistemul contine informatii care nu ating gradul de sensibilitate in sensul GDPR, dar ar fi jenant/periculos daca ar fi publicate?
• Daca cineva a publicat continutul bazei de date, cat de mare este riscul pentru companie?
• Cat de multi utilizatori exista in baza de date?

Daca exista putini utilizatori si informatiile pe care le colecteaza nu se incadreaza in categoria celor sensibile sau daunatoare, ati putea considera sistemul dumneavoastra ca avand un risc mediu/scazut chestiune dublata de efectuarea mai multor controale eficiente pentru a fi protejat. Pe de alta parte, daca sistemul contine date sensibile pentru multi utilizatori, ar fi de dorit sa se aplice un sistem de protectie mai puternic.

Important! Efectuarea unui audit este o cerinta minimala. Acesta evidentiaza nu doar ca ati efectuat controale, ci va ajuta sa limitati daunele in cazul unei incalcari de date. Dupa ce are loc orice incalcare a datelor cu caracter personal, cauzat fie de catre un factor intern sau extern, primul lucru pe care trebuie sa il faceti este de a gasi metoda care sa poata evidentia utilizatorii afectati si datele care au fost accesate. Aceste informatii trebuie sa fie raportate autoritatilor de supraveghere (ANSPDCP). In plus, acestia sunt utilizatorii care ar trebui notificati despre incalcarea datelor cu caracter personal. Daca nu aveti o asemenea metoda, ar insemna sa se presupuna ca o incalcare a datelor cu caracter personal este posibil sa ii fi afectat pe toti utilizatorii, precum si toate inregistrarile existente in sistem.

Un proces bun de auditare ofera, de asemenea, non-repudierea cu alte cuvinte, acesta nu poate fi modificat/deteriorat nici chiar de catre administratorii de sistem. Ati putea dori sa utilizati piste de audit pentru a vedea datele din sistem incalcate, spre exemplu de catre administratorul de sistem. Acest lucru s-a intamplat inainte de, si se va intampla din nou. Pistele de audit sunt, de asemenea, clasificate ca date cu caracter personal/identificatori: au o identitate unica si datele sunt conectate direct la ele.

Important! Dupa traseele de audit, urmatoarea sarcina este limitarea expunerii datelor. Cel mai bun mod de a face acest lucru este de a limita datele care se colecteaza si durata stocarii lor. Prin introducerea unui mecanism de arhivare/stergere in software de la inceput, acest lucru poate fi documentat pentru utilizatori. Daca se produce o incalcare a datelor cu caracter personal, aceasta poate afecta numai datele incluse in sistemul tinta in acel moment. Multe sisteme continua sa colecteze toate datele, dar niciodata nu le elimina din sistem, chiar si atunci cand datele devin invechite. GDPR incurajeaza sa definiti in mod clar ciclurile de viata si documentarea datelor cu caracter personal. De asemenea, ar trebui sa restrictionati accesul la datele cu caracter personal numai la ceea ce este cu adevarat necesar. Acest lucru se impune mai ales pentru datele cu caracter personal sensibile.

Am mentionat deja ca ar trebui sa aveti suficiente mecanisme de protectie pentru datele existente intr-un sistem de baze de date sau fisier si care se misca printr-o retea, in special la alte parti. Criptarea este eficienta, dar are punctele sale slabe. Cea mai puternica tehnologie de criptare: cripteaza devreme, securizeaza cheile si decripteaza tarziu. Din pacate, aceasta este o solutie complexa si costisitoare pentru a o pune in aplicare. La celalalt capat al spectrului se afla serviciile cloud, adesea simple si avantajoase, care pur si simplu cripteaza intreaga baza de date cu o caseta de selectare sau permite gestionarea cheilor si se efectueaza criptarea pentru client. In timp ce este usor, acest mecanism are de asemenea puncte slabe. Trebuie doar sa gasiti ceea ce functioneaza pentru companie, analiza care trebuie sa aiba la baza o abordare bazata pe riscuri si pe sensibilitatea datelor.

Este demn de mentionat faptul ca mecanismele de anonimizare si pseudonimizare, va pot ajuta in legatura cu testarea sau analiza datelor cu caracter personal. Anonimizarea elimina practic toate informatiile identificabile prin stergere sau campuri mascate. Pseudonimizarea inlocuieste informatii de identificare cu pseudonime, care de obicei pastreaza identitatea separata in cuprinsul datelor. Ambele practici, cu toate acestea, sunt dificil de efectuat si pot fi imperfecte. Totusi, acestea sunt instrumente valoroase mentionate in mod expres de GDPR.

Ati putea dori sa revizuiti standardele de logare si liniile directoare. Este mai usor in cazul in care va asigurati ca jurnalele nu contin date cu caracter personal, in caz contrar, ele devin date cu caracter personal si de aici decurg toate implicatiile prevazute de GDPR. Unele jurnale sunt atasate deja unor persoane: jurnale de acces si jurnale de audit, de exemplu. Dar nu includeti in acestea ID-uri de utilizator, nume, sau valori similare. Este bine sa se separe in mod clar jurnalele care pot fi legate de persoane fizice de jurnalele care nu poate fi legate de persoane fizice, dar contin informatii generale ale sistemului.

Documentati-va sistemul

Un aspect important prevazut de Regulament este de a fi in masura sa demonstrati conformitatea. Puteti face acest lucru prin certificate, care la randul lor beneficiaza de documentarea sistemelor sau documentatie folosita pentru furnizare, care poate varia pe baza mai multor factori. Dar exista unele documente suplimentare, care ar fi utile si anume:

• indicati datele cu caracter personal in cadrul sistemului;
• indicati circuitul datelor cu caracter personal colectate;
• indicati toate partile care prelucreaza datele cu caracter personal;
• indicati baza legala de prelucrare;
• informati persoanele vizate cu privire la drepturile lor si explicati-le cum isi pot exercita drepturile prevazute de Regulament in favoarea lor.

Persoana imputernicita sau nu?

Cand lucrati la un proiect de software sub imperiul responsabilitatilor instituite de GDPR, trebuie sa raspundeti la o intrebare importanta: aveti intentia sa fiti o persoana imputernicita de operator sau nu? In mod implicit, ar fi de dorit sa nu fiti o persoana imputernicita de operator, deoarece fiind unul sunteti pasibil a fi raspunzator pentru orice sanctiuni. Pentru a evita regimul sanctionatoriu prevazut de GDPR, pur si simplu asigurati-va sa nu aveti si sa nu puteti accesa niciun fel de date cu caracter personal sau identifictaori ale acestora. Trebuie sa va asigurati ca acest aspect este prevazut in mod clar in orice contract incheiat. Ar putea fi dificil de a evita prelucrarea datelor cu caracter personal, deoarece datele personale pot fi ascunse in fisiere jurnal, medii de testare si orice corectii de urgenta din mediul de productie. Dar daca doriti sa evitati o potentiala raspundere trebuie sa aveti in vedere acest lucru. Protejati-va de datele cu caracter personal. Protejati datele cu caracter personal la care aveti acces.

O alta cale este aceea de a imbratisa statutul de persoana imputernicita de operator. Acest lucru va permite sa aveti acces liber la datele cu caracter personal, atata timp cat va documentati activitatea, aveti o baza legala pentru prelucrare si acest acces este bine definit si delimitat. Acest lucru va face in mod clar responsabil asa ca trebuie sa fiti atent la orice sanctiuni. Dar acesta este traseul de urmat daca aveti absolut nevoie de acces la baza de date ce contine date cu caracter personal.

Cele mai multe proiecte software necesita expunere la datele cu caracter personal si cu siguranta aceasta este calea recomandata de urmat dar in acest caz veti avea nevoie de noi competente si instrumente.