Cam asta este reacția managementului cînd conștientizează costurile de conformare (sau cînd va primi o amendă sau o citare în instanța):
Conformarea cu GDPR nu este o activitate care se poate desfășura o singură dată și gata, ai terminat. Chiar dacă nu este menționat explicit în Regulament, din modul în care sînt scrise cerințele rezultă că abordarea conformării trebuie să fie sub forma de „program pentru protecția datelor„.
Puțină teorie:
- program – structură organizatorică flexibilă creată pentru a coordona, conduce și superviza un set de proiecte și activități conexe pentru a oferi rezultate și beneficii legate de obiectivele organizației.
- portfoliu – setul de programe și proiecte independente desfășurate în cadrul organizației.
- proiect – obținerea unor rezultate în timpul, costurile și calitatea agreate.
De ce GDPR ca program? În primul rînd pentru că nu se poate obține conformarea (beneficiile) doar cu implicarea unui singur (hai două) departament/compartiment/unitate funcțională. Asigurarea conformării este:
- transversală – sînt implicate toate unitățile funcționale unde are loc prelucrarea datelor personale (nu doar juridicul și IT-ul)
- multidisciplinară – nu implică doar cunoștințe juridice și securitate IT ci și management riscuri, analiză procese economice, comunicare, managementul schimbării etc.
- influențată de o gamă largă de părți interesate cu grade diferite de angajament și înțelegere
- are impact asupra unei game largi de părți interesate, dintre care unii (managementul, în principal) se vor plînge de „dezavantaje” – costuri
- durează atît timp cît va fi în vigoare regulamentul
Tot teoria managementului programelor ne spune că, pentru a identifica costurile este recomandabil să facem mai întîi un plan/schiță (blueprint): de ce capabilități va fi nevoie pentru a obține rezultatele dorite. Iar aici folosim modelul POTI:
- Processes and function (costuri)
- Organisation (cultură, abilități)
- Technology (echipamente, tehnologie)
- Information and data
În teorie lucrurile sună bine. În practică însă, ne confruntăm cu cea mai dificilă problemă: rezistența la schimbare. În ultimul an și jumătate, într-o proporție covîrșitoare, în discuțiile avute pe tema GDPR, finalul a fost aceleași: „nu se va aplica„ (SIC!) sau „dacă se aplică nu se pot da amenzi așa mari„ și alte variațiuni pe aceeași temă.
Pentru că managementul este direct responsabil de conformarea cu cerințele regulamentului, tot el este cel care trebuie să inițieze și să coordoneze schimbarea: practicilor, atitudinilor și comportamentului angajaților.
Dacă tot scriu acum despre program:
- chiar dacă nu ești obligat să ai DPO/RSD, este bine să îl ai (în echipa programului)
- dacă nu ai făcut inventarul datelor, dacă nu ai desenat fluxul lor și nu știi unde exact se află, nu poți face evaluarea riscurilor și a impactului;
- dacă nu ai făcut evaluarea riscurilor și a impactului nu poți asigura protecția lor „din momentul conceperii„ și „în mod implicit„ și nici nu știi care sînt controalele tehnice și administrative de care ai nevoie
- dacă nu ai implementat măsuri tehnice și administrative nu vei ști dacă respecți drepturile persoanei vizate (de fapt regulamentul)
- dar dacă vei face „ testarea, evaluarea și aprecierea„ acelor măsuri, vei afla că tot trebuie să faci….
Pingback: Recapitulare GDPR – cu exemple | ADRIAN B. MUNTEANU
Pingback: Valoarea datelor personale | ADRIAN B. MUNTEANU