Art. 13 din OUG 155/2024 este una dintre zonele centrale pentru pregatirea NIS2, pentru ca listeaza categorii de masuri de securitate cibernetica si management al riscurilor. O companie il poate folosi ca harta de orientare pentru discutii interne, nu ca dovada ca masurile sunt implementate suficient.
Primul pas util nu este sa bifezi rapid o lista. Este sa intelegi ce acopera fiecare categorie, cine o detine intern, ce documente sau intrebari exista si unde trebuie implicate echipe tehnice ori specialisti calificati.
Pe scurt
- Art. 13 listeaza categorii de masuri, nu un certificat de conformitate.
- Categoriile trebuie citite impreuna cu Art. 11, care vorbeste despre masuri proportionale si adecvate riscului.
- Managementul trebuie sa inteleaga ce aproba, ce urmareste si unde are nevoie de specialisti.
- Fiecare categorie are nevoie de proprietar intern, documente si intrebari clare.
- NIS2 Pilot ajuta la organizare interna, nu la audit, implementare, testare sau certificare.
Ce acopera Art. 13, pe intelesul managementului
Art. 13 spune ca masurile prevazute la Art. 11 alin. (1) cuprind cel putin anumite categorii. In limbaj simplu, articolul arata zonele pe care o entitate in sfera NIS2 trebuie sa le ia in calcul cand organizeaza securitatea retelelor si sistemelor informatice.
Nu trebuie extins dincolo de text. Art. 13 nu ofera configuratii tehnice, produse obligatorii sau o reteta universala. Pentru detalii tehnice, compania are nevoie de echipe interne sau specialisti.
Tabel prudent al zonelor din Art. 13
| Zona din Art. 13 | Ce inseamna pe scurt | Ce intrebari interne poti pregati | Ce nu inseamna automat |
|---|---|---|---|
| Analiza riscurilor si securitatea sistemelor informatice | Politici si proceduri despre cum sunt analizate riscurile si cum sunt protejate sistemele informatice. | Ce sisteme sunt relevante? Cine tine lista de riscuri? Cand se revizuiesc politicile? | Nu este o evaluare oficiala de risc si nu este audit tehnic. |
| Gestionarea incidentelor | Modul in care organizatia se pregateste sa observe, gestioneze si documenteze incidente. | Cine este contactul intern? Ce proces exista? Cine decide escaladarea? | Nu este serviciu de incident response si nu explica termene de raportare. |
| Continuitate, backup, redresare si criza | Pregatirea pentru functionare in caz de intreruperi, inclusiv copii de rezerva si redresare. | Ce servicii sunt critice? Exista backup documentat? Cine coordoneaza criza? | Backup existent nu inseamna automat continuitate testata sau conformitate. |
| Securitatea lantului de aprovizionare | Relatia de securitate dintre entitate si furnizorii sau prestatorii sai directi. | Ce furnizori sunt critici? Ce dependente avem? Cine detine contractele si evaluarile? | Lista furnizorilor nu este evaluare completa a securitatii lor. |
| Achizitie, dezvoltare, intretinere si casare | Securitatea pe durata de viata a retelelor si sistemelor informatice, inclusiv vulnerabilitatile. | Cum se aproba sisteme noi? Cine urmareste vulnerabilitatile? Cum se scoate din uz un sistem? | Nu este ghid de dezvoltare securizata sau remediere tehnica. |
| Evaluarea eficacitatii masurilor | Politici si proceduri prin care organizatia verifica daca masurile functioneaza. | Ce se verifica, de catre cine si cu ce frecventa? Ce dovezi exista? | Nu este audit, certificare sau validare independenta. |
| Igiena cibernetica si formare | Practici de baza si instruire pentru oameni, ca parte din cultura de securitate. | Cine primeste instruire? Ce reguli de baza exista? Cum se urmareste participarea? | Un training informal nu dovedeste suficienta masurilor. |
| Criptografie si criptare | Politici si proceduri despre utilizarea criptografiei si, dupa caz, a criptarii. | Unde se foloseste criptare? Cine decide standardele? Ce exceptii exista? | Nu este recomandare tehnica de algoritmi sau configuratii. |
| Securitate HR, control acces si gestionarea activelor | Reguli despre oameni, acces la sisteme si evidenta activelor relevante. | Cine acorda acces? Cum se retrage accesul? Unde este lista de active? | O lista de utilizatori sau active nu este audit de acces. |
| MFA si comunicatii securizate | Utilizarea autentificarii multifactor sau continue si a comunicatiilor securizate, dupa caz. | Unde exista MFA? Unde lipseste? Cine poate confirma configurarea? | MFA pe unele sisteme nu inseamna ca toate controalele sunt implementate suficient. |
Cum se citeste Art. 13 langa Art. 11 si Art. 14
Art. 11 ofera contextul general: masurile trebuie sa fie tehnice, operationale si organizatorice, proportionale si adecvate riscului. Art. 13 listeaza zonele minime de masuri. Art. 14 conecteaza subiectul cu aprobarea si supravegherea de catre conducere.
Ordinea practica de lectura
- 1Citeste Art. 11 pentru contextul de riscArt. 11 stabileste ideea de masuri tehnice, operationale si organizatorice proportionale si adecvate riscului.
- 2Citeste Art. 13 ca lista de zoneArt. 13 enumera categoriile de masuri care trebuie intelese, detinute si discutate intern.
- 3Citeste Art. 14 pentru rolul managementuluiArt. 14 conecteaza masurile cu aprobarea, supravegherea si responsabilitatea conducerii.
Ce poate pregati managementul inainte de o discutie tehnica
Pregatirea inseamna sa aduni informatii si intrebari. Nu inseamna sa alegi solutii tehnice fara specialisti sau sa declari ca masurile sunt suficiente.
Intrebari si materiale de pregatit
- Persoane responsabileCine detine fiecare categorie: management, IT, securitate, HR, juridic, achizitii sau operatiuni.
- Politici de securitate existenteCe documente exista deja si cine le-a aprobat sau revizuit ultima data.
- Contacte si note pentru incidenteCine este anuntat, cine coordoneaza si ce proces intern exista pentru evenimente de securitate.
- Backup si continuitateCe servicii sunt critice, ce copii exista si cine poate explica redresarea in caz de intrerupere.
- Furnizori si dependenteFurnizori cloud, servicii gestionate, software critic si dependente operationale relevante.
- Proprietari de sisteme si aplicatiiCine poate confirma informatii despre sistemele care sustin activitatea relevanta.
- Goluri si incertitudiniCe nu este clar, ce nu este documentat si ce trebuie trimis catre specialisti.
- Training si igiena ciberneticaCe instruire exista, cine participa si ce reguli de baza sunt comunicate intern.
- Acces si proprietateCine acorda, revizuieste si retrage accesul la sistemele importante.
- Intrebari pentru specialistiPunctele care necesita analiza tehnica, juridica sau operationala aplicata situatiei companiei.
Scenarii practice
Exemplele de mai jos arata cum poate incepe discutia. Ele nu stabilesc solutii tehnice si nu decid daca o companie respecta Art. 13.
Nu exista proprietar clar pentru incidente
Managementul poate nota cine raspunde acum, cine trebuie implicat si ce intrebare ramane pentru specialisti.
Backupurile exista, dar nu sunt explicate pentru management
Art. 13 poate declansa o discutie despre servicii critice, redresare si documentare, nu doar despre existenta copiilor.
Dependentele cloud nu sunt mapate
Echipa poate lega furnizorii critici de servicii, contracte si riscuri operationale.
MFA exista doar pe unele sisteme
Lista interna trebuie sa arate unde exista, unde lipseste si cine poate confirma acoperirea.
Trainingul se face informal
Managementul poate cere evidenta minima: cine participa, ce reguli se comunica si ce ramane neclar.
Accesul este gestionat de mai multe echipe
Intrebarea practica este cine detine regulile, revizuirea si retragerea accesului.
Cum se leaga Art. 13 de lista de active si riscuri
Multe zone din Art. 13 devin mai clare cand compania stie ce sisteme, aplicatii, date, furnizori, servicii si dependente are. De aceea, o lista interna de active si riscuri poate fi un punct de pornire util pentru discutii.
Lista de active si riscuri nu este conformitate si nu este audit. Este doar o metoda de a pregati intrebari mai bune. Vezi articolul despre lista de active si riscuri pentru pregatirea NIS2. Pentru partea de furnizori si dependente, articolul despre revizuirea furnizorilor si dependentelor NIS2 trateaza doar rutina interna de verificare, nu audit sau implementare.
Cum se leaga de intrebarile managementului catre IT
Managementul nu trebuie sa devina echipa tehnica. Totusi, trebuie sa puna intrebari informate: cine detine sistemele, ce furnizori sunt critici, unde exista MFA, ce backup este documentat si ce incertitudini trebuie trimise catre specialisti.
Pentru un cadru separat de discutie, citeste si articolul despre intrebarile pe care managementul le pune IT-ului inainte de notificarea NIS2.
Ce poate face NIS2 Pilot si ce nu poate face
NIS2 Pilot poate ajuta compania sa organizeze intern categoriile, proprietarii, notele si intrebarile. Nu este un furnizor de securitate si nu verifica implementarea Art. 13.
| Zona | Poate ajuta | Nu poate face |
|---|---|---|
| Organizare Art. 13 | Grupeaza categoriile Art. 13, proprietarii interni, notele si intrebarile ramase. | Nu proiecteaza controale si nu decide ce implementare tehnica este suficienta. |
| Note si incertitudine | Pastreaza ce este clar, ce lipseste si ce trebuie discutat cu specialisti. | Nu valideaza eficacitatea masurilor si nu auditeaza controale. |
| Dialog management-IT | Ajuta managementul, IT-ul si juridicul sa discute pe aceeasi structura. | Nu ruleaza pentest, scanari, remediere de vulnerabilitati sau SOC/SIEM. |
| Pregatire oficiala | Ajuta la pregatirea interna si la intrebari pentru review specializat. | Nu ofera opinie juridica, certificare, garantie de conformitate sau notificare DNSC. |
Ce sa nu presupui
- Citirea Art. 13 nu inseamna implementareArticolul explica zone de masuri, dar nu proiecteaza controale tehnice.
- Un checklist nu este auditO lista completata intern nu verifica independent daca masurile functioneaza.
- Rezultatul unui tool nu este dovada de conformitatePregatirea interna nu inlocuieste verificarea tehnica, juridica sau oficiala.
- Notele de management nu inlocuiesc validarea tehnicaManagementul poate cere claritate, dar specialistii trebuie implicati pentru detalii tehnice.
- NIS2 Pilot nu implementeaza si nu certifica securitateaProdusul ramane un spatiu de organizare si orientare interna.
Surse oficiale folosite
Sursa principala este OUG 155/2024 Art. 13 lit. a)-j), care enumera categoriile de masuri. Articolul foloseste Art. 11 doar pentru contextul masurilor proportionale si adecvate riscului si Art. 14 pentru contextul aprobarii si supravegherii de catre organele de conducere.
Nu foloseste numerotarea Directivei UE pentru obligatii romanesti, nu foloseste Ordinul DNSC nr. 2/2025 sau nr. 3/2025 si nu interpreteaza Art. 13 ca metodologie tehnica de implementare.
Întrebări frecvente
Art. 13 este o lista de bifat?
Nu. Art. 13 listeaza categorii de masuri, dar articolul de fata nu stabileste implementarea suficienta si nu transforma categoriile intr-un audit sau certificat de conformitate.
Daca avem politici IT, inseamna ca respectam Art. 13?
Nu automat. Politicile pot fi un punct de pornire, dar trebuie verificat continutul, aplicarea, proprietarii, revizuirea si eficacitatea masurilor cu echipe sau specialisti potriviti.
Cine ar trebui sa detina masurile Art. 13 intern?
De regula, responsabilitatea este impartita intre management, IT, securitate, HR, achizitii, juridic si operatiuni. Managementul trebuie sa inteleaga ce aproba si ce urmareste.
NIS2 Pilot verifica implementarea Art. 13?
Nu. NIS2 Pilot poate ajuta la organizarea categoriilor, notelor si intrebarilor interne, dar nu scaneaza, nu auditeaza, nu testeaza, nu implementeaza si nu certifica masuri de securitate.
Verificati orientativ situatia companiei
NIS2 Pilot va ajuta sa organizati categoriile Art. 13, proprietarii si intrebarile interne. Nu implementeaza, nu testeaza si nu certifica masuri de securitate.
Verificați dacă compania dvs. intră în sfera NIS2 →Lista de active si riscuriAcest articol are scop informativ. Nu constituie consultanță juridică sau evaluare tehnică de specialitate. Toate resursele NIS2 Pilot
Surse oficiale și context
Resurse utile
Lista de active si riscuri pentru pregatirea NIS2
Pregătire internăCum pregatesti intern o lista de active si o lista de riscuri pentru NIS2, ca materiale de lucru, nu ca audit sau dovada de conformitate.
Deschideți resursa: Lista de active si riscuri pentru pregatirea NIS2 →Intrebari pe care managementul ar trebui sa le puna IT-ului inainte de notificarea NIS2
Pregătire internăCe intrebari pune managementul echipei IT inainte de notificarea NIS2: sisteme, servicii, furnizori, contacte, riscuri si dovezi interne.
Deschideți resursa: Intrebari pe care managementul ar trebui sa le puna IT-ului inainte de notificarea NIS2 →Responsabilul cu securitatea cibernetică NIS2: ce prevede Art. 14 din GEO 155/2024
Guvernanță și managementCe înseamnă responsabilul cu securitatea cibernetică NIS2, când se desemnează și ce poate pregăti intern managementul potrivit GEO 155/2024.
Deschideți resursa: Responsabilul cu securitatea cibernetică NIS2: ce prevede Art. 14 din GEO 155/2024 →Obligații NIS2 pentru management: ce trebuie să știe conducerea
Guvernanță și managementCe prevede GEO 155/2024 pentru conducerea organizației: desemnarea responsabilului, formarea profesională și aprobarea măsurilor de securitate cibernetică.
Deschideți resursa: Obligații NIS2 pentru management: ce trebuie să știe conducerea →Cum transformi NIS2 într-un plan intern de acțiune
Pregătire internăPași practici pentru transformarea obligațiilor NIS2 din GEO 155/2024 într-un plan intern de acțiune: guvernanță, riscuri, incidente, furnizori și documentare.
Deschideți resursa: Cum transformi NIS2 într-un plan intern de acțiune →