GDPR aplicat: Zece pași utili la construirea unei politici de gestionare a incidentelor de securitate

Pe scurt, un incident de securitate este definit în traducerea în limba română a GDPR ca fiind acea încălcare a securității care duce, în mod accidental sau ilegal, la:

• distrugerea,
• pierderea,
• modificarea sau divulgarea neautorizată a datelor cu caracter personal transmise, stocate sau prelucrate într-un alt mod, sau la
• accesul neautorizat la acestea.

Ca pași logici in tratarea unui incident de securitate, e de menționat că operatorul trebuie:

1. Să implementeze măsuri de tipul privacy by default, privacy by design atunci când concepe o operațiune de prelucrare, în ideea că mai bine previne incidentele decât să le rezolve după apariția lor.

2. Implementează măsuri de securitate adecvate cu magnitudinea tipului de operațiune de prelucrare și cu riscurile pe care le implică această operațiune. Măsurile pot fi atât organizatorice, cat tehnice.

3. Implementează intern un mecanism care ajută la detecția incidentelor de securitate, pe fluxuri de operațiuni de prelucrare. Dacă este cazul, impune împuterniciților săi astfel de sisteme care ajută la detecția incidentelor de securitate.

4. Implementează un mecanism organizatoric prin intermediul căruia membrii echipei sale știu, în permanență, cine este însărcinat să urmărească apariția unor incidente de securitate, care este echipa ce va analiza incidentele, cine se va ocupa de notificarea acestora (dacă este cazul), cine va lua măsuri de reducere a riscului prelucrării datelor în cazul incidentelor de securitate.

5. Atunci când are bănuieli despre existenta unui incident de securitate, operatorul trebuie să procedeze fără întârziere la analiza acestuia, urmând a decide în ce măsură vorbim, într-adevăr, despre un incident de securitate sau vorbim despre o altă întâmplare fără potențialul de a fi incident de securitate (bug-uri ale software-ului companiei, spre exemplu).

6. Dacă ajungem la concluzia că vorbim despre un incident de securitate, atunci operatorul va trebui să analizeze în ce măsură riscul pentru persoanele ale căror date sunt prelucrate este unul existent sau inexistent.

7. Atunci când ajunge la concluzia ca incidentul generează un risc pentru persoanele vizate ale căror date sunt prelucrate, va fi nevoie să fie notificată Autoritatea de Supraveghere. Aici va fi implicat și responsabilul companiei cu protecția datelor, care va ține ulterior legătura cu Autoritatea în procedura pe care aceasta o va demara pentru investigarea incidentului.

8. Dacă incidentul nu generează un risc pentru persoanele vizate, atunci operatorul va trebui să documenteze (fixeze, în scris) incidentul și argumentația prin intermediul căreia a ajuns la concluzia că incidentul nu implică riscuri. Nu este, însă, nevoie, în acest caz, de notificarea Autorității.

9. În cazul în care incidentul de securitate generează riscuri mari pentru persoanele vizate ale căror date sunt prelucrate, va fi nevoie ca persoanele vizate să fie informate.

10. În toate cazurile, toți pașii amintiți în prezenta schema logică trebuie fixați în scris, alături de argumentația care îi însoțește, pentru ca o ulterioară anchetă a Autorității ori un proces deschis / plângere înregistrată de persoana vizată să poată fi combătută cu argumentele corecte.

Simplist, pașii de mai sus pot constitui un început de politică de securitate pentru compania în cauză. Bineînțeles, e nevoie de detalierea acestor pași, în ideea în care personalul operatorului să înțeleagă exact ce măsuri punctuale de securitate au fost implementate, care sunt drepturile și obligațiile lor în schema de securitate etc.

Notă: Mai multe detalii despre incidentele de securitate și modul în care trebuie tratate și raportate acestea se pot citi în această serie de orientări privind notificările incidentelor de securitate.