NIS2, DORA și Cyber Resilience Act în aceeași companie: protecție coerentă sau labirint de raportări?

O companie poate avea un singur incident și mai multe întrebări juridice. Un produs este exploatat, un client financiar rămâne fără un serviciu important, iar infrastructura furnizorului este afectată în același timp. Echipa tehnică vede o problemă care trebuie limitată, în timp ce departamentul juridic încearcă să stabilească cine raportează, către ce autoritate și de când începe calculul termenului.

NIS2, DORA și Cyber Resilience Act apar frecvent în aceeași discuție deoarece urmăresc securitatea digitală, dar privesc obiecte diferite. NIS2 se concentrează asupra organizațiilor și serviciilor din domeniul său de aplicare, DORA asupra rezilienței operaționale digitale a sectorului financiar, iar Cyber Resilience Act asupra produselor cu elemente digitale. Asemănarea obiectivului nu face identice obligațiile.

Pentru firmele românești, provocarea este să transforme aceste reguli într-un sistem de lucru care poate funcționa și în timpul unei crize. Trei dosare de conformitate, ținute separat, pot descrie trei versiuni ale aceleiași infrastructuri. În schimb, o evidență comună a sistemelor, furnizorilor și incidentelor poate susține obligații diferite, cu condiția să nu ascundă diferențele dintre rolurile și termenele prevăzute de fiecare act.

Prima întrebare este ce rol are compania, nu câte acronime apar în prezentare

NIS2 privește entități din sectoare precum energia, apa, sănătatea, transporturile, infrastructura digitală și anumite activități industriale. Încadrarea depinde de sector, dimensiune și criteriile legale, inclusiv de situațiile în care mărimea nu exclude aplicarea. Directiva nu transformă automat orice firmă cu un site într-o entitate reglementată, dar nici nu poate fi ignorată doar pentru că organizația nu se consideră „infrastructură critică”.

În România, cadrul de transpunere este construit prin OUG nr. 155/2024, aprobată cu modificări prin Legea nr. 124/2025, împreună cu regulile naționale aplicabile. Pentru o companie, evaluarea trebuie făcută pe activitatea și structura reală, nu doar pe descrierea comercială. O societate care oferă servicii administrate poate avea o poziție diferită de cea a unui simplu revânzător de echipamente.

DORA se aplică din 17 ianuarie 2025 entităților financiare aflate în domeniul său, inclusiv unor categorii de bănci, asigurători și furnizori de servicii financiare. Reglementează riscul informatic, incidentele, testarea rezilienței și relația cu furnizorii de tehnologie. O firmă IT care lucrează cu o bancă nu devine automat bancă și nici entitate financiară supusă tuturor obligațiilor DORA.

Totuși, furnizorul poate primi cerințe contractuale privind securitatea, accesul la informații, cooperarea la incidente și continuitatea serviciilor. Pentru furnizorii terți desemnați drept critici există și un cadru european de supraveghere. Trebuie separate obligațiile legale directe de cele asumate față de client; ambele pot avea efecte importante, dar nu au aceeași origine și nu se raportează automat în același mod.

Vezi și:

Dispozitive conectate abandonate de producător: cine răspunde pentru camerele și routerele rămase fără actualizări?

Cyber Resilience Act intră în etapa raportării: ce trebuie să facă producătorii români din septembrie 2026?

Cyber Resilience Act, prescurtat CRA, privește produse hardware și software cu elemente digitale puse la dispoziție pe piața europeană în condițiile prevăzute de regulament. Producătorul, importatorul și distribuitorul au roluri diferite. O companie care doar folosește un produs nu preia automat obligațiile producătorului, iar un serviciu cloud nu intră în CRA numai pentru că este digital. Contează definițiile, legătura cu produsul și excluderile aplicabile.

Regulile se pot întâlni fără să impună automat trei raportări identice

Un exemplu ipotetic ajută mai mult decât o listă de acronime. O firmă românească dezvoltă un produs software comercial, oferă servicii administrate și lucrează cu o instituție financiară. Activitatea de furnizare a serviciilor poate necesita o evaluare NIS2, produsul poate intra în CRA, iar relația cu banca poate presupune cerințe contractuale rezultate din DORA. Nu toate acestea înseamnă că firma are, ea însăși, trei obligații directe identice.

În sectorul financiar există o regulă importantă împotriva duplicării. Pentru entitățile financiare acoperite, DORA funcționează ca act sectorial european în raport cu NIS2, în privința cerințelor relevante de gestionare a riscului și raportare. Prin urmare, nu este corect să aduni mecanic obligațiile celor două texte și să concluzionezi că banca trebuie să trimită același raport de două ori numai fiindcă este menționată în ambele cadre.

Această relație nu elimină însă orice posibilă suprapunere în grup sau în lanțul de furnizare. O filială tehnologică, un prestator extern și o entitate financiară pot avea încadrări distincte. Dacă produsul exploatat este comercializat de altă societate din grup, rolul de producător trebuie analizat separat. Denumirea comună de pe clădire nu transformă toate persoanele juridice într-un singur destinatar al obligațiilor.

Același eveniment poate produce efecte diferite: furnizorul are un incident în propriile servicii, banca are un incident major informatic, iar producătorul identifică o vulnerabilitate exploatată activ în produs. Fiecare evaluare urmărește altă întrebare. Cauza comună poate fi investigată împreună, fără ca pragul de raportare, autoritatea competentă sau informațiile cerute să devină identice.

De aceea, o companie are nevoie de o hartă a responsabilităților pe entitate, serviciu și produs. Dacă gestionezi conformitatea, stabilește cine deține obligația, cine furnizează datele și cine aprobă notificarea. Include și relația cu clienții, pentru că un contract poate cere informarea lor mai devreme decât termenul unei raportări legale. Un e-mail trimis clientului nu înlocuiește, de la sine, notificarea autorității.

Contractele pot crea un blocaj dacă furnizorul promite să informeze banca doar după finalizarea investigației, în timp ce banca trebuie să evalueze și să raporteze incidentul mult mai devreme. Informarea inițială trebuie să distingă faptele confirmate de ipoteze și să permită actualizări. Așteptarea unui diagnostic complet poate lăsa clientul fără datele necesare pentru propria obligație, chiar dacă echipa furnizorului lucrează intens la remediere.

Termenele seamănă, dar ceasurile nu pornesc întotdeauna din același moment

În NIS2, pentru incidentele semnificative, schema generală prevede avertizare timpurie în cel mult 24 de ore de la luarea la cunoștință, notificare în cel mult 72 de ore și raport final, în principiu, într-o lună de la notificarea incidentului. Există particularități, inclusiv pentru anumite servicii. Pragul de semnificație trebuie evaluat; fiecare alertă a unui antivirus nu devine automat un incident raportabil.

În DORA, regulile detaliate prevăd notificarea inițială cât mai repede, de regulă în cel mult patru ore de la clasificarea incidentului ca major și nu mai târziu de 24 de ore de la luarea la cunoștință. Dacă clasificarea ca major are loc după acest interval de 24 de ore, se aplică regula specifică a notificării în patru ore de la clasificare. Momentele trebuie consemnate, nu reconstruite aproximativ după criză.

Raportul intermediar DORA este, în general, datorat în cel mult 72 de ore de la transmiterea notificării inițiale. Raportul final urmează în cel mult o lună după raportul intermediar sau, după caz, după ultimul raport intermediar actualizat. Diferența față de un termen calculat direct de la detectare poate conta. Calendarul intern trebuie să reflecte textul aplicabil, inclusiv regulile speciale, nu o formulă memorată dintr-o prezentare.

Pentru producătorii vizați de CRA, obligațiile de raportare se aplică din 11 septembrie 2026, înaintea principalelor cerințe care devin aplicabile din 11 decembrie 2027. Ele privesc vulnerabilități exploatate activ și incidente grave care afectează securitatea produsului. Schema include avertizare în 24 de ore și notificare în 72 de ore de la luarea la cunoștință, prin platforma unică de raportare stabilită de ENISA.

Raportul final CRA are termene diferite după situație: pentru vulnerabilitatea exploatată activ, cel mult 14 zile după disponibilitatea măsurii corective; pentru incidentul grav, într-o lună de la notificarea de 72 de ore. O vulnerabilitate descoperită la un test nu este automat una exploatată activ. În același timp, raportarea nu poate fi amânată până când echipa cunoaște toate detaliile sau are remedierea completă.

Un proces comun poate susține obligații diferite dacă păstrează dovezile și responsabilitățile

Coerența începe cu o evidență comună a incidentului. Orele detectării, luării la cunoștință, clasificării și notificării trebuie înregistrate distinct, împreună cu informațiile disponibile atunci. Echipa poate afla ulterior că impactul a fost mai mare decât părea inițial. Actualizarea evaluării este normală, însă o cronologie rescrisă ca să pară mai convenabilă creează probleme de credibilitate și de conformitate.

Inventarul infrastructurii și al produselor trebuie să permită identificarea rapidă a serviciilor afectate, clienților și furnizorilor relevanți. O listă de servere ajută puțin dacă nu arată ce activitate depinde de ele. Pentru produse, versiunile și componentele pot conta în delimitarea expunerii. Pentru servicii financiare, contează și dependențele externe, precum și capacitatea de a continua ori de a recupera operațiunile.

Responsabilitatea nu poate rămâne exclusiv la persoana care completează formularul. Conducerea trebuie să înțeleagă riscul, echipa tehnică să furnizeze date verificabile, iar funcțiile juridice și de conformitate să stabilească traseul aplicabil. Dacă ai un furnizor extern pentru securitate, clarifică ce informații transmite și în ce interval. Externalizarea unei activități nu elimină automat responsabilitatea legală a organizației.

Trebuie prevăzut și înlocuitorul persoanei responsabile, inclusiv în afara programului obișnuit. Un plan care depinde de un singur angajat aflat în concediu poate întârzia clasificarea și notificarea. Accesul la platformele necesare, datele autorităților și modelele de raportare trebuie pregătite înainte. În timpul incidentului, echipa ar trebui să adune informații, fără să descopere atunci cine are dreptul să trimită formularul.

Un exercițiu comun poate arăta dacă procedura funcționează: același scenariu este analizat pentru impactul asupra serviciului, produsului și clienților, iar echipa verifică termenele și destinatarii. Pot exista și alte obligații, inclusiv în cazul unei încălcări privind datele personale. Acestea trebuie evaluate separat, fără presupunerea că o notificare de securitate acoperă automat orice obligație legală sau contractuală.

NIS2, DORA și CRA pot susține o protecție coerentă dacă organizația pornește de la realitatea operațională și construiește peste ea traseele de conformitate. Labirintul apare când fiecare regulă produce un inventar separat și un responsabil care nu vorbește cu ceilalți. Compania are nevoie să știe ce protejează, ce s-a întâmplat și cine trebuie informat; formularele devin utile când descriu aceeași realitate, cu diferențele cerute de fiecare cadru.

Cum activezi subtitrările automate în Windows 11. Funcția care transformă vorbirea în text direct pe ecran