COMPLIANCE & RIGHT · TRATTATO
Le vulnerabilità nei software e nei dispositivi in rete non sono state a lungo una semplice questione di servizio al cliente. La Cyber Resilience Act, regolamento (UE) 2024/2847, disciplina i requisiti di sicurezza informatica per alcuni prodotti con elementi digitali. I fabbricanti dovrebbero considerare insieme lo sviluppo dei prodotti, la gestione delle vulnerabilità e la progettazione dei contratti. Chiariamo la portata giuridica e il sostegno nell'assegnazione dei compiti.
Quali prodotti e aziende sono coperti
Il punto di partenza sono i prodotti con elementi digitali il cui uso previsto o ragionevolmente prevedibile include una connessione diretta o indiretta di dati logici o fisici. Oltre all'hardware, il software può essere influenzato. Una soluzione di elaborazione a distanza necessaria per funzionare può far parte del prodotto. D'altra parte, un servizio cloud indipendente non rientra nella CRA perché utilizza software.
Sono esaminati i fabbricanti, gli importatori e i distributori nonché i ruoli speciali nel software libero e open source. Per alcuni prodotti esistono eccezioni settoriali. La delimitazione dello sviluppo open source non commerciale da una disposizione nell'ambito di un'attività imprenditoriale richiede anche una considerazione concreta. Il termine "Open Source" da solo non risponde alla domanda.
Cosa considerare dal settembre 2026
La maggior parte dei requisiti materiali si applicano dal 11 dicembre 2027. Tuttavia, gli obblighi di comunicazione per i fabbricanti di cui all'articolo 14 sono già stati applicabili dal momento in cui la 11 settembre 2026. Si tratta di vulnerabilità attivamente sfruttate e gravi incidenti di sicurezza che incidono sulla sicurezza di un prodotto catturato. Non tutte le vulnerabilità trovate innescano lo stesso requisito di segnalazione.
Per queste notifiche si applicano scadenze graduate: in linea di principio un avviso preventivo entro 24 ore e un'ulteriore notifica entro 72 ore dopo l'ottenimento delle conoscenze. I requisiti per la relazione finale sono diversi. In caso di vulnerabilità attivamente sfruttata, le segnalazioni devono essere comunicate entro 14 giorni dalla disponibilità di un'azione correttiva; in caso di incidente grave, in linea di principio, entro un mese dalla notifica delle 72 ore. I fatti pertinenti devono pertanto essere stabiliti in una fase precoce.
La notifica è effettuata tramite la piattaforma europea prevista a tal fine. Possono esistere anche altri obblighi, ad esempio in base alla legge sulla protezione dei dati o al BSIG. Un piano di allerta interno dovrebbe distinguere e coordinare tali procedure. Gli obblighi specifici degli amministratori di software open source hanno una data di applicazione propria; essi non devono essere equiparati agli obblighi del produttore.
Preparazione di ulteriori obblighi in materia di prodotti
Per l'implementazione è necessario un elenco di prodotti: famiglia di prodotti, funzioni, fornitura, utenti previsti, dipendenze tecniche e persone responsabili. La valutazione del rischio di sicurezza informatica, i requisiti in materia di sviluppo, la documentazione tecnica e l'adeguata procedura di valutazione della conformità si basano su questo punto. La classificazione di prodotti importanti o critici influenza il processo.
Il periodo di sostegno e la fornitura di aggiornamenti in materia di sicurezza devono essere pianificati in modo giuridicamente e tecnicamente sostenibile. Questo vale anche per i componenti acquistati e la questione di come i punti deboli diventano noti nelle dipendenze. Una lista di pezzi software può aiutare in questo, ma non sostituisce il controllo di ruolo legale o l'elaborazione di messaggi di sicurezza concreti.
Ciò che rientra nei trattati
I contratti con sviluppatori e fornitori dovrebbero disciplinare i requisiti di sicurezza, le informazioni sui componenti, gli obblighi di aggiornamento e la cooperazione in caso di incidenti. È necessario stabilire chi prepara la notifica e quali informazioni devono essere fornite entro il termine interno. Gli obblighi del produttore di diritto pubblico non sono in alcun modo trasferiti al prestatore di servizi da una clausola contrattuale.
I contratti con i clienti richiedono anche un confronto con la descrizione del prodotto, gli impegni di supporto e il concetto di aggiornamento. Le esclusioni forfettarie della responsabilità non risolvono una contraddizione tra la vita utile promessa e la sicurezza effettiva.
Monitoraggio giuridico di un progetto CRA
Possiamo riprendere la classificazione dei singoli prodotti, la distribuzione dei dazi in una catena di approvvigionamento o la revisione dei contratti di sviluppo e distribuzione. Una prova tecnica di sicurezza o una necessaria valutazione della conformità è effettuata da organismi specializzati competenti. La documentazione del prodotto, il modello di vendita, i componenti essenziali e le disposizioni di sostegno esistenti dovrebbero essere compilati per l'ingresso. Contatto con l'impresa.
Base giuridica e decisioni: Cyber Resilience Act [53] Regulation (EU) 2024/2847; Commissione europea: obblighi di segnalazione delle CRA; Commissione europea: Calendario di attuazione.
Situazione al 2 novembre 2026.
Per ulteriori informazioni: Sicurezza dei prodotti, marcatura CE e richiami · Imprese di software · Protezione dei dati e sicurezza informatica
Quattro esempi pratici
I seguenti casi fittizi illustrano domande d'esame tipiche. La soluzione concreta dipende dalle circostanze del singolo caso.
01 · Vulnerabilità attivamente sfruttata
Il fabbricante informa senza indugio gli attacchi al suo prodotto. La portata, il tempo di conoscenza e l'obbligo di comunicazione sono esaminati; I canali di riparazione e comunicazione continuano a funzionare in modo coordinato.
02 · Software con componenti open source
Un'applicazione commerciale contiene biblioteche straniere. I ruoli, la panoramica dei componenti e il processo di vulnerabilità sono controllati; l'etichetta open source non libera l'intero prodotto in modo forfettario.
03 · Periodo di sostegno non chiaro
Vendite e sviluppo chiamano diversi periodi di manutenzione. Gli impegni, i requisiti giuridici e le capacità tecniche di consegna saranno coordinati prima della conclusione del contratto.
04 · Prodotto o servizio puro?
Un provider offre un'app con l'elaborazione remota necessaria. La delimitazione del prodotto viene controllata utilizzando le funzioni invece di escludere automaticamente qualsiasi componente cloud.
Il tuo prossimo passo
Vuoi trasferire i requisiti alla tua azienda o avere un processo specifico controllato? Per il primo contatto sono sufficienti una breve descrizione e un riferimento alle scadenze esistenti. Voteremo sulla portata dell'esame e del risarcimento prima della messa in servizio.
