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

Cyber Resilience Act, regulamentul european care impune cerințe de securitate pentru produsele cu elemente digitale, nu devine aplicabil dintr-o singură zi. Cele mai multe obligații încep la 11 decembrie 2027, însă raportarea vulnerabilităților exploatate activ și a incidentelor severe începe mai devreme, la 11 septembrie 2026. Pentru producătorii români, aceasta este prima etapă operațională cu termene foarte scurte și cu efect direct asupra echipelor tehnice, juridice și de management.

Schimbarea privește companiile care introduc pe piața Uniunii produse hardware sau software sub propriul nume ori marcă. Poate fi vorba despre dispozitive conectate, echipamente industriale, aplicații, componente software sau servicii de procesare la distanță fără de care produsul nu își îndeplinește funcțiile. Situația exactă depinde de rolul economic și de arhitectura produsului, nu doar de faptul că firma scrie sau nu cod.

Termenele de 24 și 72 de ore fac imposibilă improvizația după apariția unui incident. O companie care nu știe ce versiuni are pe piață, cine decide severitatea sau ce date trebuie păstrate va pierde timp chiar când presiunea este cea mai mare. Pregătirea pentru septembrie 2026 înseamnă, înainte de toate, o legătură funcțională între inventarul produselor, procesul de răspuns la incidente și raportarea prin platforma unică operată de ENISA.

Cine intră în sfera obligației de raportare

Regulamentul folosește noțiunea de produs cu elemente digitale, care acoperă software și hardware, precum și anumite soluții de procesare la distanță integrate în funcționarea produsului. Un producător nu este numai fabrica ce asamblează un dispozitiv. Poate fi și compania care dezvoltă o aplicație și o oferă sub marca sa, firma care vinde un produs realizat de altcineva sub nume propriu sau operatorul care modifică substanțial un produs existent și îl repune pe piață.

Pentru o companie românească, prima sarcină este clasificarea portofoliului. Lista ar trebui să cuprindă fiecare produs, versiunile aflate în utilizare, componentele principale, perioada de suport, piețele unde este vândut și entitatea juridică responsabilă. Produsele vechi nu trebuie ignorate automat. Dacă sunt încă oferite, susținute ori se află într-o situație acoperită de regulile tranzitorii, poate exista o obligație relevantă. Evaluarea trebuie făcută pe textul regulamentului și pe contractele concrete.

Sunt necesare atenții speciale pentru componente, software cu sursă deschisă și produse complexe. O bibliotecă open-source folosită intern nu transformă automat proiectul într-un produs comercial separat, iar dezvoltarea necomercială are un tratament particular. În schimb, o companie care monetizează, distribuie sau administrează o soluție poate avea un rol care trebuie analizat. Nici eticheta „SaaS” nu rezolvă singură problema: un serviciu online pur poate fi în afara anumitor definiții, dar procesarea la distanță necesară unui produs conectat poate intra în ansamblul reglementat.

Merită stabilit în scris cine este producătorul pentru fiecare ofertă. Contractele cu dezvoltatori, fabrici, distribuitori și furnizori de module trebuie să descrie cine notifică o vulnerabilitate, cine furnizează logurile și cine poate publica o actualizare. Regulamentul pune obligația legală pe anumite roluri, dar răspunsul tehnic depinde aproape întotdeauna de un lanț de furnizori. Dacă responsabilitatea nu este clară înainte de incident, termenul legal nu se prelungește.

Vezi și:

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

NIS2 schimbă regulile pentru companiile din România: securitatea cibernetică ajunge la masa conducerii

Ce trebuie raportat și în ce termene

Prima categorie este vulnerabilitatea exploatată activ. Nu orice eroare descoperită într-un produs trebuie trimisă imediat ca alertă. Elementul esențial este existența unor dovezi credibile că un actor rău intenționat exploatează vulnerabilitatea. Producătorul transmite o avertizare timpurie în cel mult 24 de ore de când ia cunoștință, urmată, în mod normal, de o notificare mai completă în cel mult 72 de ore. După ce remedierea sau măsura de reducere a riscului devine disponibilă, raportul final trebuie depus în cel mult 14 zile.

A doua categorie este incidentul sever care afectează securitatea produsului cu elemente digitale. Și aici există o avertizare timpurie în 24 de ore și o notificare în 72 de ore. Raportul final este transmis, de regulă, în cel mult o lună după notificarea de 72 de ore. Documentele succesive nu sunt duplicate inutile: primul semnal oferă autorităților vizibilitate rapidă, iar etapele următoare adaugă evaluarea impactului, indicatorii disponibili, cauza probabilă și măsurile luate.

Raportarea se face prin platforma unică de raportare administrată de ENISA. Sistemul este construit cu puncte naționale, iar raportul ajunge simultan la ENISA și la CSIRT-ul coordonator relevant. Pentru un producător a cărui stabilire principală și ale cărui decizii de securitate se află în România, punctul românesc este, în mod obișnuit, reperul. Dacă deciziile se iau într-un grup internațional, compania trebuie să verifice din timp ce punct îi corespunde.

Ceasul pornește de la momentul în care producătorul ia cunoștință de situație, nu de la momentul în care investigația este completă. De aceea, procedura internă trebuie să definească cine poate confirma că pragul de raportare a fost atins și cum este documentat momentul. O alertă venită de la un cercetător, un client, un furnizor sau o echipă SOC trebuie să ajungă rapid la persoana care poate decide. O căsuță de e-mail verificată doar în timpul programului nu este suficientă pentru un termen de 24 de ore.

Cum se construiește un flux care încape în 24 de ore

Primul element este un canal permanent de recepție. Producătorul are nevoie de o adresă de securitate, de o politică de divulgare coordonată a vulnerabilităților și de o rotație de gardă care poate escalada semnalele relevante. Nu toate firmele au nevoie de un centru SOC propriu, dar toate au nevoie de o persoană responsabilă și de un înlocuitor. Furnizorul extern poate analiza alerta, însă decizia și obligația nu trebuie lăsate într-o zonă contractuală neclară.

Al doilea element este un inventar tehnic legat de clienți și versiuni. O listă de materiale software, cunoscută drept SBOM, poate ajuta la identificarea produselor care conțin o componentă vulnerabilă. Ea nu rezolvă singură incidentul. Trebuie corelată cu versiunile instalate, configurațiile, expunerea reală și perioada de suport. În absența acestei legături, echipa poate ști că o bibliotecă este vulnerabilă, dar nu poate stabili rapid ce produse și ce utilizatori sunt afectați.

Al treilea element este o matrice de decizie. Vulnerabilitatea este confirmată? Există indicii de exploatare rău intenționată? Incidentul afectează disponibilitatea, integritatea sau confidențialitatea într-un mod sever? Ce date sunt certe și ce rămâne ipoteză? Formularul intern ar trebui să separe faptele de estimări și să permită o avertizare timpurie chiar dacă investigația continuă. Echipele juridice și de comunicare trebuie implicate fără a bloca transmiterea tehnică.

În sfârșit, compania trebuie să păstreze dovezile. Logurile, imaginile de sistem, cronologia, versiunile și comunicările cu furnizorii trebuie colectate într-un spațiu controlat. Accesul trebuie limitat, iar datele personale prelucrate conform regulilor aplicabile. Un raport rapid nu înseamnă expunerea nefiltrată a tuturor informațiilor. Înseamnă furnizarea elementelor necesare prin canalul oficial, cu marcarea clară a informațiilor sensibile și a incertitudinilor.

Ce ar trebui finalizat înainte de septembrie 2026

Producătorul român ar trebui să facă cel puțin un exercițiu complet înainte de termen. Scenariul poate porni de la o componentă exploatată într-un dispozitiv vândut în mai multe țări. Echipa trebuie să identifice produsul, să decidă dacă situația este raportabilă, să pregătească avertizarea în 24 de ore, să simuleze notificarea din 72 de ore și să planifice actualizarea. Exercițiul va arăta unde lipsesc date, aprobări sau competențe.

Este importantă și coordonarea cu alte regimuri. Același eveniment poate declanșa obligații în temeiul NIS2, al GDPR, al DORA sau al contractelor cu clienții. Rapoartele nu sunt interschimbabile, iar termenele pot diferi. O matrice comună cu destinatari, praguri, termene și responsabilități reduce riscul ca echipa să creadă că o notificare o înlocuiește pe alta. Mesajele trebuie să fie coerente, dar adaptate scopului fiecărui cadru.

Contractele cu furnizorii merită revizuite pentru notificare rapidă, acces la informații tehnice, cooperare la investigație și livrarea remedierilor. Un furnizor care anunță producătorul după cinci zile face imposibilă respectarea termenului de 24 de ore. Clauzele nu garantează viteza, însă stabilesc așteptările și permit testarea lor. Pentru componentele critice, este util un canal direct, nu doar sistemul general de suport.

Pregătirea include și accesul efectiv la platforma de raportare. Conturile, rolurile și datele de contact trebuie verificate înainte de incident, iar persoanele de gardă trebuie să știe ce punct național aleg și ce informații pot transmite fără o aprobare suplimentară. Dacă o singură persoană deține accesul, concediul sau indisponibilitatea ei devine un risc de conformitate. Un mecanism de înlocuire și o metodă sigură de autentificare sunt detalii mici care pot decide respectarea termenului.

Mesajele către clienți trebuie pregătite în paralel. Raportarea către autorități nu înlocuiește informarea utilizatorilor atunci când aceștia trebuie să instaleze un patch, să schimbe o configurație sau să limiteze temporar o funcție. Un șablon bun explică produsele și versiunile afectate, riscul, acțiunea recomandată și locul de unde poate fi obținută actualizarea. Limbajul trebuie să fie clar, fără a publica detalii care ar facilita exploatarea înainte ca remedierea să fie disponibilă.

Conducerea are nevoie de indicatori simpli înainte de termen: procentul produselor inventariate, timpul mediu de escaladare, acoperirea logurilor, furnizorii fără obligații de notificare și rezultatele exercițiilor. Aceste măsurători arată dacă procedura există doar pe hârtie. Bugetul pentru suport și actualizări trebuie discutat împreună cu bugetul de dezvoltare, deoarece o vulnerabilitate raportată fără capacitatea de a livra o remediere rapidă rămâne un risc pentru clienți și pentru producător.

Etapa din septembrie 2026 nu trebuie tratată ca un proiect separat care se închide după configurarea unui cont în platformă. Ea este începutul unei discipline care va susține obligațiile mai ample din decembrie 2027: securitate prin proiectare, gestionarea vulnerabilităților și suport pe durata relevantă. Dacă firma folosește lunile rămase pentru inventar, roluri, proceduri și exerciții, raportarea poate deveni rezultatul firesc al răspunsului la incidente. Dacă se limitează la un formular, primele 24 de ore vor scoate la iveală toate golurile organizației.

Se schimbă stimulentul de 1.000 de lei pentru copiii cu dizabilități din București. Cine va primi mai puțin din 2027