Dacă un incident cibernetic lovește în plin și echipa începe atunci să decidă cine anunță, ce date strânge și ce aprobare mai lipsește, ai deja o problemă de guvernanță, nu doar una tehnică. În România, discuția despre NIS2 nu mai este teorie. Cadrul național a fost construit prin OUG nr. 155/2024, consolidată ulterior prin Legea nr. 124/2025, iar companiile vizate trebuie să trateze raportarea incidentelor ca pe un proces proiectat din timp, nu ca pe un exercițiu de inspirație sub presiune.
Ce înseamnă, practic, „fără improvizație”
NIS2 cere disciplină operațională: măsuri de management al riscului, roluri clare, trasabilitate și raportare. La nivel european, directiva impune obligații de raportare pentru incidente semnificative, iar în România detaliile de conformare trebuie verificate permanent în actele naționale aplicabile și în instrucțiunile DNSC. Asta înseamnă că organizația trebuie să știe dinainte cine declară incidentul, cine validează gravitatea, cine aprobă mesajul extern și unde sunt datele tehnice minime.
Primul pas nu este formularul, ci arhitectura internă. Fără ea, orice termen legal devine greu de respectat.
Borna internă de 6 ore: nu legalism, ci control
Fereastra de 6 ore ar trebui tratată ca un reper intern de comandă și control. Nu ca raport final, nu ca investigație completă, ci ca momentul în care conduci organizația din haos spre structură.
Până la borna de 6 ore, ar trebui să fie gata patru lucruri: confirmarea că există sau nu un incident real, desemnarea unui incident manager, deschiderea jurnalului unic de incident și colectarea primului set de fapte verificabile. Aici intră ora detecției, sistemele afectate, impactul observat, serviciile critice atinse, măsurile de contenție deja aplicate și persoanele care au luat decizii.
Dacă la șase ore încă se caută proprietarul aplicației, accesul la loguri sau modelul de notificare internă, designul procesului este deja defect.
Ce trebuie pregătit pentru fereastra de 24 de ore
Aici nu mai vorbim doar despre tehnic, ci despre capacitatea organizației de a transmite rapid un semnal credibil. Pentru asta, ai nevoie de un pachet minim predefinit: criterii de severitate, matrice de escaladare, listă de contacte, șablon de notificare și reguli de aprobare.
Tehnic, organizația ar trebui să poată extrage imediat cinci categorii de date: ce s-a întâmplat, când a început, ce servicii sunt afectate, ce impact operațional există și ce măsuri imediate au fost luate. Juridic și de management, trebuie să existe o regulă simplă: cine decide dacă incidentul intră pe fluxul NIS2 și cine transmite notificarea către autoritatea competentă.
În România, merită urmărite și instrumentele și fluxurile comunicate de DNSC, inclusiv platformele și formularele dedicate proceselor de înrolare și evaluare, pentru că acestea influențează disciplina administrativă din jurul raportării.
Ce schimbi până la 72 de ore
Dacă primele 24 de ore sunt despre stabilizarea mesajului, primele 72 de ore sunt despre maturizarea imaginii de ansamblu. În acest interval nu ar trebui să mai lucrezi din capturi disparate, mailuri împrăștiate și note din chat. Totul trebuie centralizat într-un dosar unic de incident.
Aici ajută enorm trei componente tehnice: log management coerent, inventar de active actualizat și maparea dependențelor. Fără ele, nu poți răspunde rapid la întrebări esențiale: ce sistem a fost punctul de intrare, ce date au fost atinse, ce furnizori sunt implicați, ce servicii downstream au fost afectate și ce risc rezidual a rămas după măsurile de contenție.
În practică, până la 72 de ore ar trebui să poți livra o versiune mai clară a cauzei probabile, a impactului, a întinderii incidentului și a pașilor următori. Nu perfecțiune, ci consistență verificabilă.
Raportarea finală nu se scrie la finalul crizei, ci înainte de ea
Greșeala clasică este să tratezi raportul final ca pe un document care va fi redactat „când se termină tot”. Corect este să ai șablonul pregătit dinainte și completat incremental. Asta cere un model standard cu secțiuni fixe: rezumat executiv, cronologie, vector probabil, sisteme afectate, impact asupra serviciilor, impact asupra datelor, măsuri aplicate, lecții învățate și acțiuni corective.
În plus, fiecare câmp trebuie să aibă proprietar. SOC-ul sau echipa tehnică nu ar trebui să completeze singură părțile de business impact, iar juridicul nu ar trebui să reconstruiască tehnic incidentul din e-mailuri. Fiecare rol contribuie pe segmentul lui, într-un registru comun.
Concluzia utilă pentru firmele din România
Pentru organizațiile care intră în zona NIS2, cronologia de 6h, 24h, 72h și raportarea finală nu este, în esență, o problemă de viteză, ci una de proiectare. Dacă ai roluri clare, loguri accesibile, șabloane aprobate, contacte actualizate și o regulă simplă de escaladare, termenul nu mai pare imposibil. Dacă nu le ai, incidentul îți va consuma timpul exact când ai mai puțin.
Iar aici este miza reală: conformarea bună nu începe în ziua atacului, ci în ziua în care îți desenezi procesul și îl exersezi. Pentru situația concretă a fiecărei organizații, textul legal aplicabil și instrucțiunile oficiale ale DNSC trebuie verificate direct, pentru că obligațiile pot depinde de încadrarea entității și de normele secundare în vigoare.
Surse
- Comisia Europeană, NIS2 Directive: securing network and information systems
- EUR-Lex, Directive (EU) 2022/2555 (NIS2)
- certSIGN, Implementarea Directivei NIS2 în România: aspecte de conformare stabilite prin ordinele DNSC
- JURIDICE.ro, Implementarea Directivei NIS2 în România. Aspecte legale și tehnice…
