Pentru multe companii, problema nu este doar dacă detectează un incident de securitate, ci cât de repede reușesc să îl transforme într-o raportare corectă și documentată. Aici apar cele mai multe blocaje: alerte care nu ajung la oamenii potriviți, tichete deschise prea târziu, informații incomplete și confuzie între un simplu semnal tehnic și momentul în care organizația devine, juridic, „conștientă” de incident. Dacă vrei să măsori serios acest interval, ai nevoie de un sistem, nu de un Excel completat după criză.
Primul pas este să definești clar ce înseamnă „început” și „sfârșit” pentru cronometru. În practică, merită să lucrezi cu mai multe momente, nu cu unul singur. De exemplu: prima alertă tehnică, confirmarea de către echipa de securitate, momentul escaladării către responsabilii interni, momentul în care se decide că incidentul intră într-o obligație de notificare și momentul trimiterii efective a raportării. Dacă sari peste această separare, vei obține un indicator frumos pe dashboard, dar inutil în audit sau într-o analiză post-incident.
Pentru incidente care implică date cu caracter personal, articolul 33 din GDPR spune că operatorul trebuie să notifice autoritatea de supraveghere „fără întârzieri nejustificate” și, acolo unde este fezabil, în cel mult 72 de ore după ce a devenit conștient de încălcare. Asta înseamnă că sistemul tău nu trebuie să măsoare doar timpul de la alertă, ci și timpul până la momentul în care organizația poate demonstra că a avut suficiente informații pentru a considera incidentul real și relevant. Pentru organizațiile vizate de NIS2 sau de cerințe sectoriale, logica este similară: nu este suficient să „vezi ceva în loguri”, trebuie să poți arăta cine a evaluat, când a escaladat și când a pornit fluxul de notificare. Termenele și pragurile concrete trebuie verificate în legislația aplicabilă organizației și în procedurile autorității competente.
Arhitectura minimă a unui asemenea sistem are patru componente. Prima este sursa de detecție: SIEM, EDR, monitorizare cloud, alerte de la furnizori sau sesizări interne. A doua este un sistem de ticketing sau case management unde incidentul primește un ID unic. A treia este motorul de workflow: reguli care schimbă automat starea cazului, notifică persoanele responsabile și atașează dovezi. A patra este zona de audit și raportare, unde toate evenimentele sunt salvate cu timestamp, utilizator, sursă și motivul schimbării.
Un model practic este să salvezi automat cel puțin șase repere: t_alert, t_triage, t_confirmed, t_legal_review, t_report_started și t_report_sent. În felul acesta poți calcula atât timpul tehnic până la confirmare, cât și timpul de la confirmare la analiza legală și, separat, timpul până la notificarea efectivă. Asta contează enorm. Dacă vezi că întârzierea apare între confirmare și implicarea echipei juridice sau a DPO-ului, nu ai o problemă de detecție, ci una de guvernanță internă.
Un alt element important este clasificarea automată. Nu orice alertă devine incident raportabil. Sistemul ar trebui să ceară obligatoriu câteva câmpuri standardizate: ce sisteme au fost afectate, dacă există suspiciune de acces neautorizat, dacă pot fi implicate date personale, dacă serviciul a fost întrerupt, impact estimat, jurisdicție și obligații contractuale. Pe baza acestor răspunsuri, workflow-ul poate trimite cazul pe ruta corectă: echipa de securitate, DPO, management, furnizor, asigurator sau consultant extern.
La fel de importantă este integritatea dovezilor. Timestamps-urile trebuie preluate automat din sisteme, nu completate manual la final. Dacă oamenii adaugă retrospectiv orele, măsura devine discutabilă. Ideal, sistemul ar trebui să păstreze jurnal nemodificabil pentru schimbările de stare și să poată exporta rapid o cronologie completă a incidentului. Într-un audit, acesta este adesea documentul care arată dacă organizația a lucrat disciplinat sau improvizat.
Nu în ultimul rând, definește indicatorii pe care îi urmărești lunar. Nu doar „timp mediu până la raportare”, ci și procentul cazurilor cu date lipsă, timpul mediu până la escaladare, procentul incidentelor reclasificate și numărul alertelor care au ratat complet fluxul de notificare. Aceste cifre îți arată unde se rupe procesul înainte să apară un incident major.
Pe scurt, un sistem bun nu cronometrează doar o criză, ci dovedește traseul deciziei. Dacă poți arăta clar când ai detectat, când ai confirmat, când ai înțeles impactul și când ai raportat, ai deja una dintre cele mai importante piese din maturitatea de securitate și conformitate. Pentru implementare reală, merită să validezi împreună cu echipa juridică, DPO-ul și responsabilii tehnici ce înseamnă exact „incident raportabil” în contextul organizației tale.
