Breșe de securitate: ce faci în primele 72 de ore
Evaluarea impactului, decizia de notificare la ANSPDCP, dovezile necesare și ghidul de supraviețuire în caz de incident de securitate.
Ransomware, atacuri de tip phishing, un e-mail trimis din greșeală către sute de clienți, un laptop de serviciu uitat în tren sau o bază de date expusă accidental pe internet.
Indiferent cât de performante sunt soluțiile de securitate ale unei organizații, breșele de securitate nu mai reprezintă o chestiune de „dacă”, ci de „când”.
Când un astfel de incident are loc, ceasul începe să ticăie. Conform Articolului 33 din GDPR, termenul pentru notificarea autorității este de maximum 72 de ore de la momentul în care operatorul a luat cunoștință de breșă, atunci când notificarea este necesară.
O confuzie majoră în practica juridică și IT este legată de momentul în care începe contorizarea celor 72 de ore.
Regulamentul precizează că termenul curge din momentul în care operatorul a „luat cunoștință” (became aware) de existența incidentului.
- Se consideră că ai „luat cunoștință” atunci când există un grad rezonabil de certitudine că s-a produs un incident de securitate care afectează datele cu caracter personal.
- Dacă un angajat sau un furnizor descoperă o suspiciune de atac luni la ora 09:00 și o raportează intern, ora 09:00 reprezintă momentul zero.
- O alertă automată neconfirmată din partea unui firewall nu înseamnă automat că termenul a început, dar impune o investigație imediată.
Pentru a gestiona eficient criza, primele 72 de ore trebuie împărțite în etape clare.
Adevărata urgență este oprirea scurgerii de date. Se izolează serverele sau computerele afectate, se schimbă parolele compromise, se revocă accesul conturilor suspecte și se păstrează copiile de siguranță.
Se convoacă echipa de răspuns la incidente: DPO, Responsabil IT / CISO, Juridic, PR și Management.
Echipa tehnică stabilește natura incidentului. Se identifică datele afectate, numărul persoanelor vizate și modul în care datele au fost accesate, copiate, criptate sau șterse.
Se determină, de asemenea, dacă datele erau criptate sau pseudonimizate.
Se analizează dacă breșa prezintă un risc pentru drepturile și libertățile persoanelor fizice.
Dacă există un astfel de risc, trebuie analizată obligația de notificare către ANSPDCP. Dacă riscul este ridicat, trebuie analizată și informarea directă a persoanelor afectate.
Se completează notificarea către ANSPDCP. Dacă investigația nu este finalizată, informațiile pot fi completate ulterior, conform procedurii aplicabile.
Nu orice incident de securitate trebuie notificat autorității sau persoanelor vizate. Decizia trebuie luată în urma unei evaluări documentate a riscului.
ANSPDCP – Art. 33
Notificarea este necesară atunci când breșa este susceptibilă să genereze un risc pentru drepturile și libertățile persoanelor.
Persoanele vizate – Art. 34
Informarea persoanelor trebuie analizată atunci când incidentul este susceptibil să genereze un risc ridicat.
Exemplu: un dispozitiv pierdut care conține date puternic criptate poate avea un risc mult mai redus decât o bază de date care conține parole necriptate sau date financiare.
Conform Articolului 33 alin. (5) din GDPR, operatorul trebuie să documenteze breșele de securitate, inclusiv raționamentul care a stat la baza deciziei de notificare sau de ne-notificare.
Dosarul incidentului ar trebui să includă:
- Jurnalele de sistem și rapoartele IT – loguri de acces, trafic și alerte de securitate.
- Procesul-verbal al echipei de criză – data, ora, participanții și concluziile.
- Evaluarea scrisă a riscului – justificarea deciziei privind notificarea.
- Dovezile măsurilor de remediere – resetarea parolelor, patch-uri, intervenții IT și măsuri de securizare.
- Copia notificării și comunicărilor transmise autorității și, dacă este cazul, persoanelor vizate.
- Ascunderea incidentului. Încercarea de a ascunde breșa poate amplifica riscurile juridice și reputaționale.
- Depășirea termenului de 72 de ore. Lipsa unei proceduri interne poate întârzia nejustificat evaluarea și notificarea.
- Comunicarea haotică cu clienții. Mesajele trebuie să fie clare, exacte și să ofere instrucțiuni concrete.
- Lipsa unor proceduri clare cu furnizorii IT. Contractele și procedurile trebuie să prevadă obligațiile privind incidentele de securitate.
- Neactualizarea registrului intern al breșelor. Incidentele trebuie evaluate și documentate corespunzător, inclusiv cele care nu sunt notificate.
Exemple orientative pentru evaluarea inițială a unui incident:
| Scenariu | Risc | ANSPDCP? | Persoane? |
|---|---|---|---|
| Laptop furat cu hard disk criptat | REDUS | Depinde de evaluarea riscului | Depinde de evaluarea riscului |
| E-mail cu date trimis accidental unui singur destinatar | REDUS | Poate să nu fie necesară | De regulă, nu |
| Atac ransomware asupra serverului | RIDICAT | DA, dacă există risc | Dacă există risc ridicat |
| Bază de date e-commerce expusă public | CRITIC | DA, dacă există risc | Dacă există risc ridicat |
Pe telefon: tabelul poate fi glisat orizontal pentru a vedea toate coloanele.
Concluzie: Pregătirea face diferența
Cele 72 de ore trec rapid atunci când organizația este pusă sub presiunea unui atac cibernetic sau a unei scurgeri de date.
Cea mai bună protecție este existența unei Proceduri de Răspuns la Incidente (Incident Response Plan), a unei echipe bine instruite și a unei colaborări eficiente între IT, Juridic și DPO.
Pregătirea din timp transformă o situație de criză într-un proces controlat.
