Notificarea la DNSC pas cu pas: înregistrare, termene, greșeli frecvente

Când oamenii spun „notificarea la DNSC”, se referă de obicei la unul din două lucruri diferite, care se confundă des. Primul este înregistrarea entității: odată ce organizația constată că intră sub NIS2 în România, trebuie să se facă cunoscută autorității. Al doilea este raportarea incidentelor semnificative, care are propriile termene, măsurate în ore.

În România, Directiva (UE) 2022/2555 a fost transpusă prin OUG 155/2024, aprobată cu modificări prin Legea 124/2025. Autoritatea națională competentă și CSIRT-ul național este DNSC (Directoratul Național de Securitate Cibernetică). Pentru unele sectoare există și autorități sectoriale, așa că primul pas este să verificați cui raportați, nu doar cum.

Obligația de înregistrare pornește de la încadrare: o entitate care constată că este esențială sau importantă trebuie să se înregistreze la DNSC în termenul stabilit de legea națională — 30 de zile de la încadrare, conform reglementării naționale. Formularul oficial și platforma de depunere sunt publicate de DNSC; nu vă bazați pe modele copiate din alte surse.

Articolul 27 din directivă stabilește setul minim de informații pe care entitățile le furnizează autorității. Pregătiți-le înainte să deschideți formularul:

• denumirea entității;
• adresa și datele de contact actualizate, inclusiv adrese de email, intervale de IP și numere de telefon;
• sectorul și subsectorul relevant din anexele directivei;
• lista statelor membre în care entitatea furnizează servicii, dacă e cazul.

Datele nu sunt statice. Un interval de IP schimbat, un nou punct de contact sau extinderea serviciilor într-un alt stat membru înseamnă că informațiile depuse trebuie actualizate. Tratați înregistrarea ca pe un registru viu, nu ca pe un formular depus o dată.

Formularul în sine se completează repede. Timpul se pierde pe întrebările interne la care nu are nimeni răspuns pe loc. O listă de pregătire care funcționează în practică:

1. Analiza de încadrare scrisă: sectorul, subsectorul, mărimea entității și motivul pentru care sunteți esențiali sau importanți.
2. Inventarul de rețea public: intervalele de IP alocate, domeniile și serviciile expuse — exact ce vede un atacator.
3. Persoanele de contact pentru securitate, cu înlocuitori, disponibile și în afara programului.
4. Aprobarea conducerii pentru depunere — Art. 20 pune răspunderea pe organul de conducere, deci decizia trebuie să existe în scris.
5. Un responsabil care ține datele la zi după depunere.

Articolul 23 stabilește un calendar în trepte pentru incidentele semnificative. Ideea de bază: autoritatea vrea un semnal rapid, chiar incomplet, și abia apoi detalii.

Dacă incidentul nu este încheiat la termenul raportului final, directiva prevede un raport de progres la acel moment și un raport final într-o lună de la gestionarea incidentului. În plus, acolo unde e cazul, entitatea trebuie să-și informeze destinatarii serviciilor despre amenințări cibernetice semnificative care îi pot afecta.

Nu orice alertă se raportează. Directiva consideră semnificativ un incident care a cauzat sau poate cauza perturbări operaționale grave ale serviciilor sau pierderi financiare pentru entitate, ori care a afectat sau poate afecta alte persoane fizice sau juridice prin prejudicii materiale sau morale considerabile.

În practică, decizia „raportăm sau nu” trebuie luată după criterii stabilite dinainte, nu în timpul crizei. Documentați pragurile interne (durată de indisponibilitate, număr de utilizatori afectați, date compromise) și cine are autoritatea să decidă. Dacă ezitați, o avertizare timpurie prudentă costă mai puțin decât un termen ratat.

• Confuzia dintre cele două notificări. Înregistrarea nu ține loc de procedură de raportare, iar o procedură de raportare nu vă înregistrează.
• Ceasuri pe fusul orar greșit. Un incident descoperit la 23:30 într-un fus orar și consemnat în alt fus în altul poate „pierde” o oră din cele 24. Țineți marcajele de timp în UTC și convertiți doar la afișare.
• Datele de contact învechite. DNSC nu vă poate contacta pe adresa unui angajat plecat.
• Nimeni desemnat. Procedura spune „echipa de securitate notifică”, dar în noaptea incidentului nu e clar cine are acces la platformă.
• Raportul final scris din memorie. Fără un registru de incident ținut pe parcurs, cauza și cronologia se reconstruiesc greu după o lună.
• Ignorarea clienților. Obligația de a informa destinatarii serviciilor, acolo unde se aplică, se uită ușor sub presiune.

Termenele de 24h și 72h se respectă atunci când sunt pregătite înainte: o procedură scrisă, un șablon de avertizare și un registru de incidente care pornește ceasul în momentul în care incidentul e consemnat. Exercițiile periodice (tabletop) arată rapid unde se blochează procesul.

Un șablon minimal de avertizare timpurie, pregătit dinainte, ar trebui să aibă deja completate câmpurile care nu depind de incident:

1. datele de identificare ale entității și persoana de contact disponibilă în următoarele 72 de ore;
2. momentul luării la cunoștință, în UTC, și cine l-a constatat;
3. serviciile afectate și o estimare a impactului, chiar și aproximativă;
4. dacă se suspectează o acțiune rău intenționată și dacă sunt afectați clienți sau parteneri din alte state membre;
5. pașii de izolare deja făcuți și următoarea actualizare promisă.

Pentru măsurile tehnice pe care DNSC le poate verifica după un incident, citiți și Art. 21 NIS2 tradus în controale tehnice.