246.000 de înregistrări și 78 de zile până la anunț: ce testează cazul Digital Agency în procesul tău de notificare

• 25 iunie 2026: este detectată o activitate anormală — contul de mentenanță accesa un număr mare de fișiere de pe servere. Începe investigația.
• 9 iulie 2026: se stabilește că un terț pătrunsese în sistem exploatând vulnerabilitatea echipamentului VPN. Contul este suspendat, iar comunicațiile externe ale echipamentului sunt întrerupte.
• 15 iulie 2026: agenția notifică autoritatea japoneză de protecție a datelor, potrivit relatării independente a BleepingComputer.
• 11 septembrie 2026: anunțul public, cu cifre defalcate pe tipuri de date și cu precizarea categoriilor neafectate.

• Confirmat de agenție: vectorul inițial a fost vulnerabilitatea unui echipament VPN, iar accesul la fișiere s-a făcut printr-un cont de mentenanță și operare.
• Confirmat de agenție: volumele pe categorii de date, faptul că My Number, datele bancare și numerele de pensie nu sunt incluse și că nu a fost confirmată nicio utilizare abuzivă până la data anunțului.
• Relatat independent: agenția a descris problema drept de severitate medie și a afirmat că nu era o vulnerabilitate zero-day.
• Necunoscut public: producătorul și modelul echipamentului VPN, identificatorul CVE, momentul exact al primei intruziuni și dacă datele au fost efectiv exfiltrate sau doar accesate. Agenția vorbește despre posibilitatea scurgerii, nu despre o exfiltrare dovedită.

Exercițiul util nu este să judeci o agenție din altă jurisdicție, ci să suprapui datele peste propriile obligații. Pentru entitățile esențiale și importante, NIS2 cere, pentru un incident semnificativ, o avertizare timpurie în cel mult 24 de ore de la momentul în care organizația ia cunoștință, o notificare de incident în cel mult 72 de ore și un raport final în cel mult o lună de la notificare. În România, directiva a fost transpusă prin OUG 155/2024, aprobată prin Legea 124/2025, cu DNSC drept autoritate națională.

Separat, dacă sunt implicate date cu caracter personal, GDPR cere notificarea autorității de supraveghere în cel mult 72 de ore de la momentul luării la cunoștință, iar informarea persoanelor vizate se face fără întârziere nejustificată atunci când există un risc ridicat pentru drepturile lor. Cele două seturi de termene curg în paralel și nu se substituie.

Întrebarea concretă pentru conducere nu este „câte zile au trecut la Tokyo”, ci: în organizația noastră, ce anume ar fi declanșat ceasul? Detectarea din 25 iunie sau confirmarea din 9 iulie? Cine are autoritatea să declare că organizația „a luat cunoștință”? Dacă răspunsul diferă între securitate, juridic și conducere, termenul legal se consumă în timp ce se poartă discuția.

• Rulează cronologia japoneză ca scenariu de masă, înlocuind sistemele lor cu ale voastre. Oprește exercițiul la fiecare dată din calendar și întreabă ce ar fi trebuit trimis, către cine și pe baza cărei informații disponibile în acel moment.
• Numește explicit persoana care declară „am luat cunoștință” și cea care aprobă notificarea. Notează ambele nume și un înlocuitor pentru fiecare, apoi verifică dacă sunt accesibili în weekend și în concediu.
• Scrie dinainte scheletul avertizării de 24 de ore. Nu are nevoie de o cauză rădăcină, ci de ce s-a observat, când, ce sisteme sunt implicate și ce se investighează. Multe organizații pierd termenul încercând să obțină certitudini pe care nimeni nu le are în prima zi.
• Decide cum arată comunicarea către persoanele afectate atunci când nu ai certitudinea exfiltrării. Formularea onestă — ce știm, ce nu știm, ce facem, ce pot face ei — se pregătește la rece, nu sub presiune.
• Verifică dacă logurile voastre ar susține o astfel de cronologie. Dacă retenția este de 30 de zile, o investigație începută în iulie nu ar mai putea reconstitui ce s-a întâmplat în mai.

Partea din acest incident care se repetă cel mai des în alte organizații nu este echipamentul VPN, ci ce a urmat: un cont de mentenanță și operare care putea accesa un volum mare de fișiere, suficient cât accesul anormal să fie vizibil abia după ce s-a produs. Astfel de conturi există în aproape orice organizație, adesea partajate cu un furnizor, rareori incluse în revizuirile periodice de acces și frecvent exceptate de la MFA „pentru că strică automatizările”.

Un pas realist este să inventariezi conturile de mentenanță, să stabilești pentru fiecare un proprietar intern, o limită de acces și o alertă la comportament neobișnuit, apoi să treci exercițiul prin echipele care le folosesc zilnic. Awarely Learning poate transforma acest tip de caz într-un exercițiu repetabil pentru echipele de conducere și operare; decizia privind conturile, termenele și notificarea rămâne a organizației.