Le FAQ aggiornate di ENISA sulla Single Reporting Platform (SRP) prevista dal Cyber Resilience Act (CRA) spiegano come i produttori, inclusi gli operatori del gioco e i fornitori tecnologici, dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi a partire dall’11 settembre 2026, nonché quali misure le aziende, comprese quelle attive nel settore del gambling, devono adottare fin da ora per essere in grado di reagire entro le prime 24 ore.
Questo è il terzo articolo della mia analisi del Cyber Resilience Act.
- Nel primo articolo ho esaminato le linee guida della Commissione europea sull’ambito di applicazione del CRA, sui prodotti interessati e sugli obblighi applicabili.
- Nel secondo articolo ho analizzato specificamente le implicazioni del CRA per gli operatori e i fornitori del settore del gioco, comprese le complesse questioni relative alle applicazioni mobili, alle soluzioni di elaborazione dati da remoto e alle piattaforme di terze parti.
Questo articolo affronta una diversa componente del CRA: cosa accade quando qualcosa va storto e un’azienda deve effettuare una segnalazione, anche alla luce delle FAQ recentemente aggiornate da ENISA sulla piattaforma di reporting.
La tempistica è particolarmente importante. Gli obblighi di segnalazione previsti dal CRA inizieranno ad applicarsi l’11 settembre 2026 sia ai prodotti nuovi sia a quelli già esistenti, mentre il CRA diventerà pienamente applicabile soltanto l’11 dicembre 2027. A partire dall’11 settembre vi saranno situazioni in cui un’azienda avrà soltanto poche ore per comprendere cosa sia successo, determinare se il CRA trovi applicazione e adottare le necessarie misure. Ed è proprio questo l’aspetto su cui molti dei nostri clienti stanno incontrando maggiori difficoltà.
Cosa chiariscono le nuove FAQ di ENISA
La Single Reporting Platform (SRP) di ENISA è il meccanismo attraverso il quale i produttori di prodotti con elementi digitali dovranno segnalare, ai sensi del CRA, le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza di tali prodotti.
Le FAQ aggiornate forniscono informazioni pratiche riguardanti:
- il processo di segnalazione;
- la registrazione alla piattaforma;
- gli Assigned Representatives;
- il CSIRT coordinatore competente;
- il funzionamento della piattaforma.
ENISA ha inoltre pubblicato un dettagliato SRP Glossary, che descrive le informazioni da fornire nelle diverse fasi della notifica.
Le categorie di eventi soggetti a segnalazione obbligatoria sono due:
- Vulnerabilità attivamente sfruttate, ossia vulnerabilità rispetto alle quali esistono prove affidabili dell’effettivo sfruttamento da parte di un soggetto malevolo.
- Incidenti gravi, vale a dire incidenti che producono un impatto significativo sulla sicurezza di un prodotto con elementi digitali.
Le fasi della segnalazione
Il processo di reporting si sviluppa in più fasi:
- una segnalazione preliminare (early warning) deve essere presentata entro 24 ore dal momento in cui il produttore viene a conoscenza dell’evento rilevante;
- una notifica più dettagliata deve seguire entro 72 ore.
Per le vulnerabilità attivamente sfruttate, il rapporto finale deve essere trasmesso entro 14 giorni dalla disponibilità di una misura correttiva.
Per gli incidenti gravi, invece, il rapporto finale deve essere trasmesso entro un mese dalla notifica effettuata entro 72 ore.
Ciò non significa che l’azienda debba aver completato l’intera indagine entro 24 ore. Significa, piuttosto, che deve essere in grado di effettuare una valutazione tecnicamente e giuridicamente informata sulla base delle informazioni disponibili in quel momento.
Tutto ciò richiede una preparazione adeguata ben prima che l’incidente si verifichi.
Quali prodotti rientrano nel CRA? Il caso del settore del gioco
Il settore del gambling rappresenta un esempio particolarmente efficace del motivo per cui la preparazione al CRA non può limitarsi all’adozione di una generica policy di cybersecurity.
L’analisi richiesta dal CRA è infatti specifica per il singolo prodotto.
Ad esempio:
- un’applicazione nativa di scommesse sportive, casinò o poker distribuita tramite app store può rientrare nella definizione di prodotto con elementi digitali;
- una piattaforma di gioco accessibile tramite browser presenta caratteristiche differenti, poiché il semplice accesso remoto al servizio non trasforma automaticamente il servizio in un prodotto con elementi digitali.
Esistono tuttavia componenti che potrebbero qualificarsi come remote data processing solutions, poiché l’assenza di tali elaborazioni impedirebbe al prodotto con elementi digitali di svolgere una delle proprie funzioni.
Pertanto, anche qualora alcuni prodotti non rientrino direttamente nell’ambito di applicazione del CRA, il regime potrebbe comunque estendersi indirettamente ad essi.
Allo stesso modo, nel caso di utilizzo di software sviluppato da terzi, l’operatore potrebbe essere qualificato come produttore ai sensi del CRA qualora commercializzi il prodotto:
- con il proprio nome o marchio;
- oppure apportandovi modifiche sostanziali.
L’analisi relativa ai prodotti che rientrano nell’ambito di applicazione del CRA dovrebbe essere completata prima del verificarsi di un incidente. Quando inizia a decorrere il termine delle 24 ore, non è il momento opportuno per scoprire chi sia il soggetto giuridicamente responsabile del prodotto.
Cosa dovrebbero fare le aziende prima dell’11 settembre
Vi sono diversi passi pratici che produttori e operatori del gioco dovrebbero intraprendere fin d’ora.
1. Individuare i prodotti che potrebbero generare obblighi di segnalazione
Le aziende dovrebbero identificare:
- quali prodotti con elementi digitali producono o immettono sul mercato europeo;
- quali componenti e servizi accessori debbano essere considerati.
L’obiettivo dovrebbe essere quello di fornire una risposta chiara a quattro domande fondamentali:
- Qual è il prodotto?
- Chi è il produttore?
- Quali versioni sono attualmente supportate?
- Quali soggetti terzi sono coinvolti?
In assenza di queste informazioni, la gestione della segnalazione rischia di diventare molto più complessa nel momento in cui si verifica un incidente.
2. Individuare il soggetto responsabile
Un gruppo operante nel settore del gioco potrebbe avere:
- una società che gestisce il business;
- una società che detiene la proprietà intellettuale;
- una società che sviluppa l’applicazione;
- un fornitore tecnologico che gestisce la piattaforma sottostante.
Occorre quindi stabilire quale entità rivesta il ruolo di produttore per ciascun prodotto rilevante.
3. Assicurarsi che le persone competenti possano effettivamente effettuare le segnalazioni
ENISA ha fornito indicazioni specifiche sugli Assigned Representatives che utilizzeranno la SRP.
Le aziende dovrebbero quindi:
- individuare i Primary e Secondary Assigned Representatives;
- verificare che dispongano delle autorizzazioni necessarie;
- assicurarsi che abbiano attivato EU Login e l’autenticazione multifattore (MFA);
- identificare il CSIRT coordinatore competente.
4. Costruire il processo delle prime 24 ore
Una solida incident response policy dovrebbe stabilire chi:
- riceve la prima segnalazione di cybersecurity;
- valuta se l’evento possa essere soggetto a notifica;
- coinvolge il team legale;
- identifica il prodotto e la versione interessati;
- raccoglie le informazioni tecniche;
- registra il momento in cui l’azienda è venuta a conoscenza dell’evento;
- decide quali informazioni possano essere comunicate entro 24 ore;
- presenta la notifica;
- coordina la notifica delle 72 ore;
- prepara il rapporto finale.
L’azienda dovrebbe inoltre mantenere una documentazione delle decisioni adottate e delle informazioni disponibili in ogni fase, da poter esibire alle autorità in caso di verifiche.
Questo aspetto è rilevante perché un’autorità potrebbe successivamente chiedere non solo cosa sia accaduto, ma anche:
- cosa sapesse l’azienda in quel determinato momento;
- perché abbia deciso di agire in un determinato modo.
Ogni caso dovrebbe quindi essere accompagnato da un report che documenti il processo decisionale seguito. È qui che assume particolare rilievo la dimensione difensiva della compliance al CRA.
La SRP non sostituisce i processi interni
La piattaforma di reporting prevista dal CRA costituisce esclusivamente il canale attraverso il quale effettuare la notifica.
Essa non stabilisce se sussista o meno un obbligo di segnalazione e non sostituisce il processo interno necessario per identificare, investigare e classificare un evento.
Le aziende dovranno quindi organizzare autonomamente i propri workflow e database interni, mentre la notifica formale verrà trasmessa attraverso l’interfaccia della piattaforma.
Ciò significa che le aziende dovrebbero valutare la creazione di un workflow interno dedicato al CRA che registri almeno:
- il momento in cui l’azienda è venuta a conoscenza dell’evento;
- il prodotto e la versione interessati;
- la classificazione preliminare;
- le informazioni disponibili entro le prime 24 ore;
- gli elementi ancora oggetto di indagine;
- le misure correttive e di mitigazione adottate;
- il soggetto responsabile di ciascuna attività;
- la scadenza del termine di 72 ore;
- la scadenza prevista per il rapporto finale.
Un workflow adeguatamente progettato può aiutare l’azienda a raccogliere le informazioni rilevanti, monitorare le scadenze applicabili e mantenere una documentazione coerente tra i team di cybersecurity, legale e business.
About the Author: Giulio Coraggio
