Legea 48/2023: ce obligații de securitate cibernetică ai în Republica Moldova
Primul cadru național obligatoriu de securitate cibernetică din Moldova, construit pe modelul NIS2. Cine intră sub incidența lui, ce măsuri minime impune și de ce testarea tehnică devine singura dovadă acceptabilă.

Mult timp, securitatea cibernetică a fost pentru companiile din Republica Moldova o cerință care venea de la clienți, de la bănci sau de la parteneri externi. Legea nr. 48/2023 schimbă logica: aduce un cadru național obligatoriu, construit pe modelul european NIS2, cu entități desemnate, măsuri minime de gestionare a riscurilor și obligație de raportare a incidentelor în trepte. Pentru o organizație care se întreabă dacă o privește, răspunsul nu mai depinde de bunăvoință, ci de sector, de dimensiune și de relațiile contractuale.
Ce este Legea 48/2023, pe scurt
Legea nr. 48/2023 privind securitatea cibernetică stabilește cadrul juridic și instituțional al domeniului în Republica Moldova. Nu este o reglementare izolată, ci alinierea națională la Directiva europeană NIS2 — aceeași logică de entități esențiale și importante, aceleași categorii de măsuri de gestionare a riscurilor, același model de raportare în trepte a incidentelor. Pentru companiile care lucrau deja cu parteneri din Uniunea Europeană, asta e o veste bună: efortul de conformitate nu se dublează.
Notă: alinierea la NIS2 înseamnă că un program de conformitate construit pentru piața europeană acoperă, în mare parte, și cerințele naționale. Invers este la fel de adevărat — și mult mai des util pentru exportatorii moldoveni care trebuie să demonstreze un singur set de dovezi în fața mai multor clienți.
Diferența importantă față de regimul anterior nu este doar existența unor obligații scrise, ci faptul că ele devin verificabile. Legea nu spune „faceți securitate cibernetică”; spune ce categorii de măsuri trebuie să existe, cum se raportează un incident și cine are dreptul să vină să te controleze. Iar acolo unde există control, există și întrebarea inevitabilă: ce dovadă prezinți?
Cui i se aplică, de fapt
Legea vizează organizațiile care furnizează servicii considerate critice pentru funcționarea societății și a economiei. Sectoarele urmează structura europeană: energie, transport, sector bancar și infrastructuri ale pieței financiare, sănătate, apă potabilă și ape uzate, infrastructură digitală, administrație publică, servicii poștale, gestionarea deșeurilor, producție și distribuție de alimente, industrie, furnizori de servicii digitale și cercetare.
Ca și în NIS2, încadrarea depinde de două variabile simultane: sectorul în care activezi și dimensiunea organizației. De aici decurge și distincția dintre entități esențiale și entități importante, reflectată mai ales în intensitatea supravegherii. Primele sunt supravegheate proactiv, prin evaluări și verificări periodice; celelalte intră în atenția autorității mai ales ca reacție la un incident sau la o sesizare.
| Tip de entitate | Cum se stabilește | Regim de supraveghere |
|---|---|---|
| Esențială | Sector critic + dimensiune mare, sau rol de furnizor unic | Proactiv: evaluări, verificări, solicitări de dovezi |
| Importantă | Sector vizat + dimensiune medie | Reactivi: la incident sau sesizare |
| Furnizor al unei entități desemnate | Prin contract, ca parte a lanțului de aprovizionare | Indirect, dar cu cerințe contractuale ferme |
Există însă un al treilea traseu, mai puțin intuitiv și mult mai frecvent decât se crede. Chiar dacă nu ești entitate desemnată, obligațiile privind lanțul de aprovizionare fac ca cerințele să coboare, prin contract, la furnizorii tăi de IT, găzduire, dezvoltare software și mentenanță. Pentru multe companii din Moldova, legea ajunge pe această cale înainte să ajungă direct: un client din sectorul bancar sau energetic îți cere brusc dovezi de securitate pe care nu le-ai mai furnizat niciodată.
Ce obligații concrete aduce legea
Lista de măsuri minime este structurată pe categorii, iar fiecare categorie are un echivalent tehnic. Legea nu impune un produs sau o metodologie anume, dar impune ca măsurile să existe și să fie eficace. Categoriile sunt:
- Politici de analiză a riscurilor și de securitate a sistemelor informaționale.
- Gestionarea incidentelor: detectare, tratare, raportare în trepte către autoritatea competentă.
- Continuitatea activității: copii de rezervă, recuperare în caz de dezastru, gestionarea crizelor.
- Securitatea lanțului de aprovizionare, inclusiv cerințe către furnizorii direcți.
- Securitatea în achiziția, dezvoltarea și întreținerea sistemelor, cu gestionarea vulnerabilităților.
- Politici de evaluare a eficacității măsurilor — adică testare, nu doar documentare.
- Igienă cibernetică și instruirea personalului.
- Criptografie, controlul accesului, autentificare multifactor și comunicații securizate.
Citită în diagonală, lista pare o colecție de documente. Citită cu atenție, ea conține două obligații care nu se pot închide cu hârtii: evaluarea eficacității măsurilor și gestionarea vulnerabilităților. Prima cere o verificare independentă a faptului că apărarea rezistă în fața unui atac real; a doua cere să știi ce vulnerabilități ai înainte să le găsească altcineva. Ambele sunt, prin natura lor, tehnice.
Raportarea incidentelor, în trei momente
Modelul preluat din NIS2 împarte raportarea în trei momente distincte: o avertizare timpurie foarte rapidă, o notificare cu evaluare inițială în primele zile și un raport final după închiderea incidentului. Termenele exacte și formularele se stabilesc prin actele normative subordonate, dar structura este constantă.
Consecința practică a acestei structuri este mai importantă decât termenele în sine. Procedura internă trebuie să poată produce un mesaj util în ore, nu în săptămâni — ceea ce presupune că cineva din organizație are responsabilitatea clară de a detecta, de a clasifica și de a redacta. Într-o companie fără un proces de gestionare a incidentelor, primele ore se pierd căutând pe cineva care știe ce s-a întâmplat.
Atenție: cea mai frecventă greșeală nu este raportarea tardivă, ci incapacitatea de a raporta deloc. Dacă nu ai un inventar al sistemelor și un minim de logging centralizat, nu vei ști că ai fost atacat, nu vei putea estima impactul și nu vei putea completa nici măcar avertizarea timpurie într-un mod credibil.
Unde intră testarea de securitate
Aici ajungem la partea care interesează cel mai mult practicienii. Legea, ca și NIS2, cere politici de evaluare a eficacității măsurilor de gestionare a riscurilor și gestionarea vulnerabilităților, fără să impună o metodă anume. Nu există un articol care să scrie „test de penetrare obligatoriu”. Există însă două obligații care, în practică, nu se pot demonstra cu documente.
Un test de penetrare le acoperă pe amândouă și produce, în plus, exact formatul de dovadă pe care îl caută un control: perimetru, metodologie, constatări, remediere, re-test. Un scaner rulat o dată, fără urmărirea remedierii, nu închide obligația de gestionare a vulnerabilităților; o politică semnată nu închide obligația de evaluare a eficacității.
| Obligație | Ce nu e suficient | Ce produce testarea |
|---|---|---|
| Evaluarea eficacității măsurilor | O politică semnată și o listă de controale | Verificare practică a apărării, cu rezultat măsurabil |
| Gestionarea vulnerabilităților | Un scaner rulat o dată, fără urmărirea remedierii | Constatări prioritizate pe risc real, plus dovada închiderii lor |
| Securitatea lanțului de aprovizionare | Un chestionar completat de furnizor | Raport independent pe integrarea furnizorului cu sistemele tale |
| Continuitatea activității | Un plan scris, netestat | Scenarii de atac care arată unde se rupe planul |
Din perspectiva unui auditor sau a unei autorități de control, valoarea unui raport de testare nu stă în numărul de vulnerabilități găsite, ci în trasabilitate. Se vede perimetrul testat, se vede metodologia folosită, se vede cum a fost prioritizată fiecare constatare și se vede dovada că problema a fost închisă. Un raport fără re-test este o fotografie; un raport cu re-test este un proces.
De ce testarea externă vine prima
Ordinea contează mai puțin pentru conformitate și mult mai mult pentru risc. Suprafața expusă spre internet este singura pe care un atacator o vede fără să fi obținut deja acces. Un test de penetrare extern la începutul programului dă lista de priorități reale și evită cea mai frecventă greșeală: luni de scris politici, în timp ce o interfață de administrare rămâne publică. Documentația se construiește mai ușor peste o imagine tehnică clară decât invers.
Legătura cu NIS2, GDPR și alte cadre
Legea 48/2023 este alinierea națională la modelul NIS2, deci cerințele se suprapun aproape complet: aceleași categorii de măsuri, aceeași logică de entități, același model de raportare a incidentelor. GDPR este un cadru diferit, care privește protecția datelor personale, dar se intersectează la măsurile tehnice: Articolul 32 cere testarea regulată a eficacității acestora. O singură campanie de testare poate produce dovezi pentru toate trei.
Pentru sectorul financiar, tabloul se completează cu cerințele de reziliență operațională digitală și cu testarea bazată pe amenințări, care merg mai departe decât un pentest clasic. Pentru procesatorii de plăți, PCI DSS 4.0 adaugă cerințe explicite de testare a segmentării și de validare periodică. Iar pentru companiile care vor să vândă în UE, ISO 27001 și SOC 2 rămân limbajul contractual prin care se cer dovezi de testare tehnică. Toate aceste cadre converg spre același tip de artefact: un raport independent, cu metodologie și re-test.
De unde începi dacă nu ai făcut nimic până acum
Din inventar și din perimetru. Mai întâi stabilești ce sisteme susțin serviciul pe care îl furnizezi și cine are acces la ele; apoi verifici tehnic ce e expus spre internet. Această ordine nu este birocratică — este singura care îți permite să prioritizezi. Fără inventar, fiecare vulnerabilitate pare la fel de importantă, iar echipa sfârșește prin a repara lucruri care nu contau.
Pașii practici, în ordinea în care aduc valoare:
- Inventariază sistemele care susțin serviciul critic și cine are acces administrativ la ele.
- Mapează suprafața expusă spre internet și verifică ce interfețe de administrare sunt publice.
- Rulează un test de penetrare extern pentru a obține lista de priorități reale.
- Închide constatările critice și înalte, apoi cere re-test și păstrează dovada.
- Construiește procedura de raportare a incidentelor peste logging-ul deja existent.
- Extinde cerințele către furnizorii direcți, prin contract, cu dovezi verificabile.
- Repetă testarea cel puțin anual și după fiecare schimbare majoră de arhitectură.
Pentru companiile care lucrează deja cu instituții financiare și procesatori de plăți din Republica Moldova, inclusiv în procese de audit și înregistrare la Banca Națională a Moldovei, această ordine este familiară: întâi imaginea tehnică, apoi documentația care o descrie. Diferența adusă de Legea 48/2023 este că acum aceeași ordine devine cerință legală, nu doar bună practică.
Important: legea nu sancționează lipsa unui document anume, ci lipsa unor măsuri eficace. Dacă nu poți demonstra printr-o verificare independentă că apărarea rezistă, ai o problemă de conformitate și o problemă de risc în același timp — iar a doua o vei afla oricum, doar că de la altcineva.
Previziunea noastră, după ce am trecut prin astfel de procese alături de clienți din sectorul financiar, este că presiunea reală nu va veni dinspre controale, ci dinspre contracte. Entitățile desemnate își vor transfera cerințele către furnizori mult mai repede decât vor apărea verificările de conformitate, iar furnizorii care pot prezenta un raport de testare recent vor avea un avantaj comercial concret. Pentru restul, legea va deveni vizibilă exact în momentul cel mai incomod: la primul incident sau la prima cerere de dovezi dintr-un proces de achiziție.
Acest material are caracter informativ și nu constituie consultanță juridică.