Comisia Europeană publică ghidul CRA: ce trebuie să clarifice producătorii de software înainte de raportarea din septembrie

Comisia Europeană a publicat pe 27 iulie 2026 primul set de ghiduri practice pentru aplicarea Cyber Resilience Act (CRA). Materialul tratează, între altele, produsele aflate în domeniul regulamentului, modificările substanțiale, perioadele de suport, evaluarea riscului și obligațiile de raportare. Pentru producătorii de software și produse cu elemente digitale vândute în UE, inclusiv cei din România, momentul este util pentru a transforma cerințele generale într-un inventar concret de produs, vulnerabilități, proprietari și fluxuri de decizie.

Ce a publicat Comisia și de ce contează acum

Conform Comisiei, ghidul explică aplicarea practică a CRA, inclusiv ce produse intră în domeniu, ce poate fi o modificare substanțială, cum trebuie înțelese perioadele de suport și cum se abordează evaluarea riscului și raportarea. CRA se aplică produselor cu elemente digitale de-a lungul ciclului lor de viață. Calendarul publicat de Comisie indică data de 11 septembrie 2026 pentru aplicarea obligațiilor de raportare și 11 decembrie 2027 pentru aplicarea deplină a obligațiilor principale. Nu este prudent să aștepți până în septembrie pentru a afla ce produs, componentă sau proces intră în aceste fluxuri.

Întrebarea de pornire: ce produs livrezi, de fapt?

Într-o organizație software, răspunsul nu este întotdeauna evident. Un produs poate include aplicația principală, biblioteci open-source, agenți, pluginuri, clienți desktop, imagini de container, firmware, documentație de instalare și servicii care continuă să fie întreținute după vânzare. Înainte de a proiecta o procedură de conformitate, echipa trebuie să poată identifica versiunea, owner-ul, canalul de distribuție, dependențele și perioada de suport pentru fiecare element relevant.

Un plan practic pentru următoarele săptămâni

• Fă un inventar versionat al produselor, componentelor, dependențelor și canalelor prin care ajung la clienți sau utilizatori.
• Stabilește cine decide dacă o vulnerabilitate, un incident sau o modificare de produs necesită analiză, remediere, comunicare ori raportare.
• Leagă managementul vulnerabilităților de dezvoltare: recepție, triere, severitate, remediere, testare, publicare de advisory și urmărirea versiunilor afectate.
• Documentează perioada de suport, update-urile de securitate și modul în care utilizatorii află despre remedieri; nu lăsa aceste informații doar în conversații sau ticket-uri izolate.
• Testează fluxul cu un exercițiu: o vulnerabilitate critică într-o dependență, un release afectat și o echipă care trebuie să decidă ce comunică, cui și când.

De ce awareness-ul rămâne relevant

CRA nu se rezolvă printr-un curs anual. Totuși, oamenii din dezvoltare, product management, suport, achiziții și management trebuie să înțeleagă de ce evidențele de produs, raportarea vulnerabilităților și respectarea procesului contează. Trainingul poate susține acest comportament, iar un program repetabil oferă dovadă de participare; nu înlocuiește însă controalele tehnice, guvernanța produsului sau interpretarea cerințelor legale.