Fără a contesta importanța laturii juridice a GDPR am spus începînd cu 2017, ori de cîte ori am avut ocazia: după ce ne vom lămuri cu „litera și spiritul regulamentului„, aspectele tehnice sînt cele care vor da și mai multe bătăi de cap. Îmi susțin afirmația cu o realitate autohtonă: foarte puține din sistemele/aplicațiile/procesele existente în organizațiile noastre sînt „privacy/security by design„. (Să luăm ca exemplu o parte din spitale care au „ERP„ – uri găzduite și administrate de furnizorul soluției…..)

1. Articole relevante (listă incompletă)

Vom regăsi în GDPR cerințe funcționale și tehnice atît explicite cît și implicite.

• Art. 4 – Definiții 🙂 – prelucrare, creare de profiluri, pseudonimizare,
• Considerent 49, Art. 5-1(f), 32-1(b-d)
• Considerent 83, Art. 6-4(e), 32-1(a)
• Considerent 26, 28, 29, 78 Art 6-4(e), 25-1, 2, 32-1(a)
• Considerent 39, 58, Art. 12-1, 13-2(a-f)
• Considerent 58, 61, 63, Art. 12, 15-1(a, d)
• Considerent 68, Art. 13-2(b), 14-2(c), 20
• Considerent 39, 45, Art. 13-2(a), 14-2(a), 25-2
• Cosniderent 59, 65, Art. 16
• Considerent 66, Art. 19
• Considerent 78
• …

Atunci când elaborează, proiectează, selectează și utilizează aplicații, servicii și produse care se bazează pe prelucrarea datelor cu caracter personal sau care prelucrează date cu caracter personal pentru a-și îndeplini rolul, producătorii acestor produse și furnizorii acestor servicii și aplicații ar trebui să fie încurajați să aibă în vedere dreptul la protecția datelor la momentul elaborării și proiectării unor astfel de produse, servicii și aplicații și, ținând cont de stadiul actual al dezvoltării, să se asigure că operatorii și persoanele împuternicite de operatori sunt în măsură să își îndeplinească obligațiile referitoare la protecția datelor.

2. Front-end, back-end, SDLC

Subiectul poate fi abordat pornind de la cele scrise în titlu. Ar trebui ca punctul de plecare să fie SDLC pentru că așa ne impune Art. 25 din GDPR. Aspectele ce țin de front-back end sînt de fapt „aceeași Mărie cu altă pălărie„.

Nevoia de a lua în considerare integritatea, confidențialitatea și disponibilitatea este un aspect fundamental al dezvoltării aplicațiilor indiferent de metodologia de dezvoltare utilizată (Agile, Scrum, Waterfall, Kanban etc). Momentul optim pentru definirea cerințelor de securitate este în timpul etapei inițiale de proiectare și planificare, deoarece acest lucru permite echipelor de dezvoltare să integreze securitatea în moduri care reduc la minimum riscurile (de conformitate, de securitate etc) dar și costurile ulterioare. Unul din factorii care influențează cerințele de securitate se referă la ….cerințele legale.

Cum mă consider și auditor, consider că SDLC este asimilat activităților de asigurare (assurance) care ajută dezvoltatorii să implementeze „funcționalități sigure” , prin faptul că „funcționalitățile„ sunt bine concepute în ceea ce privește securitatea informațiilor/datelor. În articolul anterior am inclus la final o imagine din Microsoft – Security Development Lifecycle.

„Use case„ -urile din faza de Definire a cerințelor (Requirements) nu ar trebui să omită nimic din ceea ce presupune „datele personale„: aplicațiii asociate, persoane vizate, date personale prelucrate, roluri și responsabili asociați, fluxul datelor, sisteme implicate, controale, servicii etc. Este momentul în care se discută și se iau deciziile cu privire la utilizarea datelor personale și proiectarea sistemului. GDPR face de mai multe ori mențiuni cu privire la obligațiile operatorilor și la „riscuri„.

Eu, utilizatorul – Experiența Front End

• Datele despre mine sînt colectate într-o manieră absolut necesară pentru ceea ce doresc eu să fac?
• În orice moment al interacțiunii mele cu aplicația/pagina/formularul înțeleg ce se întîmplă cu datele și de ce se întîmplă acele lucruri?
• Am suficiente informații astfel încît deciziile pe care le iau cu privire la datele despre mine să fie decizii informate și nu manipulate?
• Sînt forțat să iau o anumită decizie?
• ….

Tu, dezvoltatorul – Funcționalitățile și documentația Back End

• Ți-ai evaluat partenerii cu care lucrezi-dezvolți?
• Folosești doar datele de care ai nevoie pentru a rezolva funcționalitatea cerută?
• Ai documentat tot ce ține de protecția datelor personale în timpul dezvoltării aplicației?
• Accesul neautorizat la date este protejat? Ai asigurat „traseul auditării„?
• Cine poate șterge, corecta, vizualiza etc date și de ce? „Least privilege„+„Need to know„
• Datele personale sînt pseudonimizate, acolo unde este posibil?
• Testarea a avut în vedere și cerințele privind protecția datelor? Folosești date reale (din producție) în mediul de test?
• Criptezi?
• Dacă ai DPO, te-ai consultat cu el? Dacă nu ai, cine te ajută să identifici cerințele?

Deși DPIA este obligatorie doar pentru anumite categorii de activități de prelucrare, consider că în cazul dezvoltatorilor nu ar trebui să lipsească PIA. Ar fi un exercițiu foarte bun prin care cerințele se identifică chiar din faza de analiză.