Un incident de securitate gestionat corect în primele ore costă zile de recuperare. Unul gestionat haotic costă săptămâni, uneori luni, plus amenzi, reputație și clienți pierduți.
Acest ghid oferă un plan concret pentru IMM-uri: ce faci, în ce ordine, cine e responsabil și cum comunici.
Ce e un incident de securitate (și ce nu e)
Nu orice problemă IT e un incident de securitate. Diferența contează pentru că determină cine trebuie implicat și ce obligații legale ai.
Este incident de securitate:
- Ransomware sau malware activ în rețea
- Acces neautorizat la sisteme sau date
- Scurgere de date (intenționată sau accidentală)
- Phishing reușit (cineva a dat credențiale)
- Modificări neautorizate ale sistemelor sau datelor
- Indisponibilitate cauzată de atac (DDoS, sabotaj)
Nu este incident de securitate:
- Server căzut din cauza hardware-ului defect
- Eroare de software sau bug
- Problemă de configurare care afectează performanța
- Uitarea unei parole
Distincția e importantă: un incident de securitate poate declanșa obligații de raportare la DNSC (NIS2) sau ANSPDCP (GDPR). O problemă tehnică obișnuită, nu.
Dacă nu ești sigur în ce categorie se încadrează situația, tratează ca incident de securitate până ai dovezi contrare.
De ce primele 24 de ore sunt critice
Trei motive concrete:
1. Dovezile dispar rapid. Logurile din memoria RAM se pierd la restart. Fișierele temporare se suprascriu. Conexiunile de rețea se închid. Fiecare oră care trece reduce șansele de a înțelege ce s-a întâmplat și cum.
2. Atacatorii se mișcă repede. În cazul unui atac activ, primele ore sunt cele în care atacatorul încearcă să se extindă în rețea, să exfiltreze date sau să instaleze backdoor-uri pentru acces ulterior. Răspunsul lent înseamnă damage mai mare.
3. Obligațiile legale nu așteaptă. NIS2 cere raportare în 24 de ore pentru incidente semnificative. GDPR cere raportare în 72 de ore pentru breșe cu date personale. Termenele încep să curgă din momentul în care ai devenit conștient de incident, nu din momentul în care ai terminat investigația.
Cei 5 pași în ordine
Înainte de a declanșa planul complet, verifică rapid dacă situația e ce pare a fi. Un angajat care raportează "ceva ciudat" poate însemna orice, de la un atac activ la o actualizare de Windows care a schimbat interfața.
Întrebări de clarificare:
- Ce anume ai observat? (simptome concrete)
- Când a început?
- Mai sunt și alții afectați?
- Ai făcut ceva între timp? (restart, click pe linkuri, etc.)
Timpul alocat pentru verificare: maxim 15-30 minute. Dacă după verificarea inițială situația rămâne neclară sau confirmă un incident, treci la pașii de mai jos.
Pasul 1: Izolează, nu opri
Instinctul e să închizi tot. Rezistă-i.
Ce faci:
- Deconectează echipamentele afectate de la rețea (scoate cablul sau dezactivează WiFi)
- NU le închide, NU le restarta
- Izolează segmentul de rețea afectat dacă e posibil
- Păstrează sistemele pornite pentru analiză forensică
De ce contează: un restart distruge dovezi din memoria RAM care pot fi singura modalitate de a înțelege vectorul de atac.
Excepție: dacă vezi activ că datele sunt criptate sau exfiltrate și nu ai altă metodă de oprire, închiderea forțată poate fi justificată. Dar e ultimul resort, nu prima opțiune.
Pasul 2: Documentează tot
Începe un log al incidentului. Format simplu, nu contează forma, contează să existe.
Ce notezi:
- Ora exactă a fiecărei observații și acțiuni
- Cine a raportat și ce a observat
- Ce echipamente sunt afectate (nume, IP-uri, locație)
- Ce acțiuni s-au luat și de către cine
- Capturi de ecran cu mesaje de eroare, cereri de răscumpărare, comportament suspect
Acest log va fi esențial pentru: investigația tehnică, raportarea la autorități, discuțiile cu asigurătorul, eventuale proceduri legale.
Pasul 3: Stabilește cine coordonează
Cine trebuie implicat:
- Coordonatorul de incident (un singur om cu autoritate de decizie)
- Responsabilul IT (intern sau furnizor extern)
- Management (director general sau echivalent)
- Responsabil comunicare (dacă există)
- Avocat (pentru incidente majore)
- Furnizor de servicii de securitate (dacă aveți contract)
Regula esențială: un singur om coordonează. Restul primesc instrucțiuni clare și raportează către coordonator. Fără această structură, haosul e garantat.
Pasul 4: Evaluează înainte să comunici
Înainte de a comunica sau raporta, trebuie să înțelegi ce s-a întâmplat. Nu complet, dar suficient.
Întrebări cheie:
- Ce sisteme sunt afectate?
- Ce date au fost accesate/compromise/criptate?
- Sunt date personale implicate? (declanșează obligații GDPR)
- Atacul e încă activ sau a fost contenționat?
- Care e impactul operațional? (ce nu mai funcționează)
- Există backup-uri neafectate?
Răspunsurile la aceste întrebări determină: ce raportezi, cui comunici și care e prioritatea de recuperare.
Pasul 5: Raportează conform obligațiilor legale
Pentru NIS2 (dacă ești entitate esențială sau importantă):
- Termen: 24 de ore de la identificarea incidentului semnificativ
- Către: DNSC (Directoratul Național de Securitate Cibernetică)
- Cum: Prin platforma ATHENA sau https://pnrisc.dnsc.ro/
- Ce raportezi inițial: notificare că a avut loc un incident, impact preliminar
- Actualizare: raport detaliat în 72 de ore, raport final în 30 de zile
Pentru GDPR (dacă sunt date personale implicate):
- Termen: 72 de ore de la identificare
- Către: ANSPDCP
- Ce raportezi: natura breșei, categorii de date afectate, număr aproximativ de persoane, consecințe probabile, măsuri luate
Către persoanele afectate:
- Obligatoriu dacă breșa prezintă risc ridicat pentru drepturile lor
- Fără întârziere nejustificată
- Limbaj clar, nu jargon legal
Cum raportezi la DNSC: instrucțiuni pas cu pas
Dacă ești entitate esențială sau importantă conform OUG 155/2024 și ai un incident semnificativ, ai obligația să raportezi la DNSC în 24 de ore.
Ce pregătești înainte:
- CUI-ul companiei
- Datele persoanei responsabile de securitate cibernetică
- Descrierea incidentului (ce s-a întâmplat, când, ce sisteme)
- Evaluarea preliminară a impactului
- Măsurile luate până în momentul raportării
Pașii concreți:
- Accesează platforma https://pnrisc.dnsc.ro/
- Completează formularul de notificare
- Semnează electronic formularul
- Trimite formularul
Ce urmează după notificarea inițială:
- În 72 de ore: raport actualizat cu evaluare detaliată a impactului și indicatori de compromitere
- În 30 de zile: raport final cu analiza completă, cauza root, măsurile implementate și lecțiile învățate
Important: Notificarea inițială nu trebuie să fie completă. Scopul ei e să informeze DNSC că a avut loc un incident. Detaliile vin în actualizările ulterioare. Nu aștepta să ai toate răspunsurile ca să raportezi, termenul de 24 de ore e ferm.
Cine face ce: matricea de responsabilități
Această matrice trebuie stabilită înainte de incident, nu în timpul lui.
Director General: Decizii finale, aprobare comunicare externă, contact cu autoritățile
Coordonator incident: Coordonare generală, menține logul, asigură că pașii sunt urmați
Responsabil IT: Izolare tehnică, investigație, restaurare sisteme
HR: Comunicare internă către angajați
Juridic/Avocat: Verificare obligații legale, formulare raportări
Comunicare/Marketing: Mesaje către clienți, presă (dacă e cazul)
Template comunicare internă
Subiect: Problemă de securitate IT — ce trebuie să știți
Echipa,
Am identificat o problemă de securitate care afectează [descrie general — ex: serverul de fișiere / sistemul de email / etc.].
Ce facem:
- Echipa IT lucrează la rezolvare
- Am izolat sistemele afectate
- Vom reveni cu actualizări la fiecare [X ore]
Ce vă rugăm să faceți:
- Nu accesați [sistemele afectate]
- Nu discutați situația cu persoane din afara companiei
- Raportați orice comportament suspect la [contact]
- Continuați activitatea normală pe sistemele neafectate
Ce NU trebuie să faceți:
- Nu postați pe rețele sociale despre această situație
- Nu răspundeți la întrebări de la presă (direcționați către [contact])
- Nu încercați să "reparați" singuri ceva
Vom reveni cu informații. Mulțumim pentru înțelegere.
[Nume, funcție]
Template comunicare externă (clienți/parteneri)
Subiect: Informare privind incident de securitate
Stimați parteneri,
Vă informăm că am identificat un incident de securitate care a afectat [descrie general, fără detalii tehnice].
Ce am făcut:
- Am izolat sistemele afectate
- Am inițiat investigația cu [experți externi dacă e cazul]
- Am notificat autoritățile competente conform legislației în vigoare
Impactul asupra dumneavoastră: [Descrie concret — ex: datele dumneavoastră nu au fost afectate / următoarele categorii de date ar putea fi implicate: ... ]
Măsurile pe care le recomandăm: [Dacă e cazul — ex: schimbarea parolelor, monitorizarea conturilor, etc.]
Contact pentru întrebări: [Persoană dedicată, email, telefon]
Ne cerem scuze pentru orice inconveniență și vă asigurăm că tratăm această situație cu maximă seriozitate.
[Semnătură oficială]
Greșeli care agravează situația
1. Oprirea totală fără izolare. Pierzi dovezi și nu rezolvi problema.
2. Plata răscumpărării fără consultare. În afară de faptul că finanțezi infractorii, nu ai nicio garanție că primești datele înapoi. 40% dintre companii care plătesc nu primesc cheia de decriptare funcțională.
3. Comunicarea prematură. Anunțul că "am fost atacați" înainte să știi ce s-a întâmplat creează panică și poate fi folosit împotriva ta.
4. Tăcerea când trebuia să comunici. Dacă datele clienților sunt compromise și nu anunți, încalci legea și pierzi încrederea definitiv când se va afla.
5. Ștergerea "dovezilor". Instinctul de a "curăța" sistemele distruge exact informațiile necesare pentru investigație și pentru a preveni recurența.
6. Investigația fără expertiză. Dacă nu ai intern competențe de forensic IT, nu improviza. Angajează pe cineva sau acceptă că nu vei ști niciodată exact ce s-a întâmplat.
Cum te pregătești înainte să se întâmple
Un plan de răspuns la incidente nu garantează că nu vei fi atacat. Garantează că nu vei pierde timp prețios întrebându-te ce să faci.
Minimum necesar:
- Document scris cu pașii de urmat (poate fi o pagină)
- Lista de contacte pentru urgențe: furnizor IT, firmă de securitate, avocat, asigurător
- Matricea de responsabilități — cine coordonează, cine decide ce
- Template-uri de comunicare pregătite (internă și externă)
- Backup-uri testate — nu e suficient să existe, trebuie să fi verificat că restaurarea funcționează
- Simulare anuală — măcar o dată pe an, parcurgeți scenariul fără presiunea unui incident real
Checklist primele 24 de ore
- ☐ Verifică dacă e incident real sau problemă tehnică obișnuită
- ☐ Izolează echipamentele afectate (fără restart/închidere)
- ☐ Începe logul incidentului (oră, observații, acțiuni)
- ☐ Contactează coordonatorul de incident desemnat
- ☐ Notifică managementul
- ☐ Contactează furnizorul IT / firma de securitate
- ☐ Evaluează: ce sisteme, ce date, ce impact
- ☐ Verifică dacă sunt date personale implicate (GDPR)
- ☐ Verifică dacă ești entitate NIS2 și dacă incidentul e semnificativ
- ☐ Pregătește notificarea DNSC (dacă e cazul) — termen 24h
- ☐ Pregătește comunicarea internă
- ☐ Decide dacă/când comunici extern
- ☐ Documentează toate deciziile și motivele lor
Resurse adiționale
- DNSC — Directoratul Național de Securitate Cibernetică
- ANSPDCP — Autoritatea pentru date personale
- Platforma PNRISC pentru raportări
Concluzie
Incidentele de securitate nu se previn 100%. Se gestionează. Diferența dintre o companie care se recuperează rapid și una care pierde luni stă în pregătire și în execuția primelor ore.
Documentul acesta e un punct de plecare. Adaptează-l la structura și nevoile companiei tale.
Dacă ai nevoie de ajutor pentru implementarea unui plan de răspuns la incidente sau pentru pregătirea echipei, contactează-ne.