Greseli comune in notificarea incalcarilor de date personale pe care echipele SaaS inca le fac

Cele mai comune greseli nu sunt probleme juridice exotice. Sunt esecuri operationale: evaluarea se deschide prea tarziu, nu se confirma daca sunt date personale, se confunda operatorul cu persoana imputernicita, notificarea clientului este tratata ca notificarea autoritatii si dovezile raman imprastiate.

Conform articolului 33 GDPR, operatorul notifica autoritatea competenta fara intarzieri nejustificate si, daca este posibil, in 72 de ore de la luarea la cunostinta, cu exceptia cazului in care este improbabil sa existe risc. Articolul 34 adauga comunicarea catre persoane cand exista risc ridicat probabil. Persoanele imputernicite informeaza operatorul fara intarzieri nejustificate.

De ce gresesc si echipele bune

Echipele SaaS au incident response, security owners, suport, legal review si escalation. Dar aceste piese sunt in instrumente diferite si folosesc ceasuri diferite. Security urmareste detectarea, legal are nevoie de momentul luarii la cunostinta, echipele client verifica contracte, iar engineering stie sistemele.

Fara conexiune inainte, primele ore construiesc modelul.

Greseala 1: asteptarea certitudinii

Registrul ajuta la decizia de notificare. El contine fapte, incertitudini, owneri si urmatorul review. Daca nu exista date personale sau pragul nu este atins, se inchide cu justificare.

Greseala 2: urmarirea ceasului gresit

Cele 72 de ore nu sunt mereu inceputul incidentului, primul alert sau root cause. Intrebarea operationala este cand organizatia a luat cunostinta de o incalcare de date personale. Contractele pot avea termene de client mai scurte.

Greseala 3: un singur rol GDPR

Un SaaS poate fi operator pentru conturi, billing, HR, marketing, analytics sau loguri si persoana imputernicita pentru datele clientilor. Rolurile trebuie stabilite per dataset cu contract, decident si obligatie.

Greseala 4: confundarea riscului cu riscul ridicat

Articolul 33 si articolul 34 au praguri diferite. Notificarea autoritatii si comunicarea catre persoane se evalueaza separat si se documenteaza.

Greseala 5: incredere excesiva in criptare sau izolare

Criptarea si izolarea sunt dovezi, nu scurtaturi. Verifica datele protejate, cheile, metadatele, integritatea, disponibilitatea si riscul rezidual.

Greseala 6: obligatiile clientilor in afara workflow-ului

Contractele enterprise pot defini termene, continut, contacte si cooperare. Ele trebuie sa fie vizibile in procesul de incident.

Greseala 7: pierderea dovezilor

Un raspuns bun trebuie sa poata fi dovedit. Timeline, scope, aprobari, notificari, confirmari de furnizori si remediere trebuie conectate intr-un pachet de dovezi.

Greseala 8: inchiderea dupa notificare

Notificarea nu inchide incidentul. Inchiderea arata problema, izolarea, decizia, remedierea, ownerul, termenul, verificarea si imbunatatirea controlului.

Exemplu

Un bug de permisiuni expune atasamente de support intre doua workspace-uri de clienti. Security repara rapid. Un workflow matur deschide registrul, verifica atasamente si loguri, confirma rolurile per dataset, verifica DPA, evalueaza risc si risc ridicat, pastreaza dovezi si urmareste remedierea.

FAQ

Ce trebuie sa inteleaga echipele?

Ca notificarea este un workflow sensibil la timp cu fapte security, privacy, roluri, decizii juridice, obligatii fata de clienti, dovezi si remediere.

De ce conteaza?

Pentru ca o incalcare devine rapid o problema de incredere client, audit, legal, security si leadership.

Care este cea mai mare greseala?

Tratarea notificarii ca interpretare juridica unica, nu ca workflow repetabil cu owneri, triggeri, dovezi si escaladare.

Surse

• European Union, General Data Protection Regulation.
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR.
• Information Commissioner's Office, Personal data breaches - a guide.
• Information Commissioner's Office, 72 hours - how to respond to a personal data breach.