Il Cyber Resilience Act guarda dietro lo schermo e sotto il cofano. Quando un’app, un dispositivo IoT o una macchina connessa dipendono da software remoto progettato dal fabbricante o sotto la sua responsabilità, quel backend può diventare parte del prodotto con elementi digitali.
Etichette commerciali come “SaaS” e “cloud” spiegano poco: contano le funzioni promesse, l’architettura reale e il soggetto che ne risponde. Per le imprese significa ripensare conformità, contratti e sicurezza sull’intero sistema-prodotto.
Indice degli argomenti
Il prodotto ha un retrobottega, e il CRA vuole visitarne anche il magazzino
Ogni prodotto digitale contemporaneo, dunque, ha una parte che si vede e una che lavora dietro le quinte. Si vede il termostato appeso al muro, lo smartwatch al polso, l’app sul telefono, la console che governa una macchina industriale. Dietro, spesso molto lontano, si muove un piccolo continente: API, database, motori di calcolo, sistemi di identità, code di messaggistica, servizi di aggiornamento. Il cliente compra l’oggetto in vetrina; la funzione, intanto, abita anche nel retrobottega.
Il Regolamento (UE) 2024/2847, il Cyber Resilience Act, prende sul serio questa geografia. La definizione di «prodotto con elementi digitali» comprende un prodotto software o hardware e le sue soluzioni di trattamento remoto dei dati. È una frase corta con conseguenze lunghe. Il perimetro regolatorio può oltrepassare la plastica del dispositivo e il codice installato sul client, seguendo il filo che conduce fino al backend.
Si immagini una serratura intelligente. La chiave meccanica continua a girare, il tastierino locale riconosce un codice, ma l’apertura da remoto, la revoca di un’autorizzazione e il registro degli accessi dipendono dai server del fabbricante. Limitare la valutazione di sicurezza alla serratura sarebbe come certificare la porta di una banca ignorando la stanza dalla quale vengono rilasciati i badge. Il rischio viaggia lungo l’intero percorso della funzione.
Il considerando 11 esplicita la logica: il prodotto deve essere adeguatamente protetto nella sua interezza, che i dati siano trattati sul dispositivo dell’utente oppure a distanza. La norma corregge così un’illusione molto diffusa. Il cloud sembra immateriale soltanto perché i suoi cavi sono altrove. Dal punto di vista della sicurezza, ha porte, corridoi, chiavi e finestre esattamente come qualunque edificio.
La definizione in tre domande: dove, chi e che cosa succede se manca
L’articolo 3, punto 2, offre un test che può essere tradotto in tre domande comprensibili anche fuori da una riunione di giuristi. Il trattamento avviene a distanza? Il relativo software è progettato e sviluppato dal fabbricante, oppure sotto la sua responsabilità? Se quella soluzione sparisse dall’architettura, il prodotto perderebbe una delle sue funzioni? Quando le tre risposte convergono, il backend si avvicina molto al cuore del perimetro CRA.
La prima domanda riguarda il luogo logico del trattamento. Dati, comandi o calcoli escono dall’ambiente locale e raggiungono un sistema remoto. Poco importa che il server si trovi nella stanza accanto, in una regione cloud europea o dall’altra parte dell’oceano: la distanza qui descrive la separazione funzionale tra l’ambiente dell’utente e quello nel quale opera la soluzione.
La seconda domanda cerca il regista. Il software remoto può essere scritto direttamente dal fabbricante, commissionato a una software house oppure sviluppato da un’altra società sotto la sua responsabilità. L’outsourcing cambia le mani sulla tastiera; il soggetto che mette il proprio nome sul prodotto continua a dirigere l’orchestra. Un contratto di sviluppo o di hosting, da solo, non recide questa responsabilità.
La terza domanda è un piccolo esperimento mentale. Togliamo il backend dal disegno e osserviamo il prodotto. Quale funzione resta in piedi? Quale cade? Il legislatore usa un’espressione più ampia di quanto potrebbe sembrare: l’assenza deve impedire al prodotto di svolgere «una delle sue funzioni». Non serve che l’oggetto diventi un fermacarte. Un termostato può ancora accendere la caldaia localmente e perdere, senza cloud, la programmazione da remoto. Quella funzione sopravviveva nelle brochure, nelle schermate dello store e nelle aspettative del cliente; merita quindi di entrare nell’analisi.
Il test controfattuale protegge anche dalla cosmetica contrattuale. Chiamare il backend “servizio accessorio” non lo rende accessorio se il prodotto lo contatta ogni trenta secondi per autenticarsi, elaborare dati o ricevere istruzioni. Manuali, materiali commerciali, user journey, configurazioni predefinite e diagrammi dei flussi raccontano la verità architetturale meglio di una definizione infilata nelle condizioni generali.
“Essenziale” non significa necessariamente “unica funzione vitale”
Nel dibattito sulle remote data processing solutions ricorre spesso la parola «essenziale». È utile maneggiarla con cura. La definizione normativa non richiede che il servizio remoto sostenga la funzione principale o che la sua assenza renda inutilizzabile l’intero prodotto. Chiede che venga meno una funzione. L’essenzialità è quindi relazionale: quel trattamento remoto è necessario rispetto alla specifica funzione che abilita.
Prendiamo una videocamera domestica. La registrazione su scheda locale continua a funzionare durante un’interruzione del cloud. Le notifiche sul telefono, la consultazione delle clip dall’esterno e il riconoscimento di determinati eventi, invece, possono dipendere dal backend del fabbricante. La videocamera conserva una parte della propria utilità, mentre tre funzioni vendute insieme al prodotto evaporano. L’architettura somiglia a una casa con più stanze: il fatto che il soggiorno rimanga illuminato non rende irrilevante il guasto elettrico in cucina.
Lo stesso vale per il software. Un’app di gestione documentale può permettere di aprire localmente un file e affidare al server la sincronizzazione, il controllo delle autorizzazioni e la condivisione. Se il client distribuito e il backend sono progettati come un’unica esperienza, la linea di confine del prodotto segue quei legami. La valutazione deve spiegare quali funzioni vivono sul dispositivo, quali vivono a distanza e quali attraversano entrambi gli ambienti.
Questa granularità evita conclusioni troppo larghe. Il sito istituzionale del fabbricante, il blog, la pagina di assistenza e il sistema di fatturazione non entrano nel prodotto solo perché parlano con il cliente. Il collegamento rilevante è funzionale: la soluzione remota deve contribuire all’esecuzione di una funzione del prodotto. La domanda somiglia a quella che si farebbe davanti a una macchina: questo ingranaggio fa muovere il meccanismo oppure sta semplicemente nello stesso capannone?
Il SaaS davanti alla dogana del CRA
A questo punto il SaaS arriva alla frontiera con molti documenti in mano e una certa confusione allo sportello. Il considerando 12 aiuta a fare ordine. Le soluzioni cloud ricadono nel CRA quando soddisfano la definizione di trattamento remoto. I servizi cloud progettati e sviluppati fuori dalla responsabilità del fabbricante, così come i siti web che non sostengono una funzione del prodotto, restano estranei a questo specifico perimetro. SaaS, PaaS e IaaS trovano inoltre nella NIS2 la disciplina dei servizi cloud, al ricorrere delle condizioni soggettive previste dalla direttiva.
Una piattaforma utilizzata esclusivamente via browser, offerta come servizio autonomo e priva del ruolo di backend di un altro prodotto con elementi digitali, in linea generale non viene attratta nel CRA dalla sola circostanza di essere software. La conclusione va comunque verificata sul modo concreto in cui l’offerta viene messa a disposizione. Nel diritto dei prodotti digitali le etichette commerciali hanno l’affidabilità delle scritte sulle scatole durante un trasloco: aiutano, finché qualcuno non guarda che cosa contengono davvero.
Il considerando 11 propone un esempio nitido. Un’app mobile ha bisogno di accedere a un’API o a una banca dati resa disponibile attraverso un servizio sviluppato dal fabbricante. Quel servizio rientra nel perimetro come soluzione di trattamento remoto. Il telefono ospita il salotto dell’esperienza; API e database ne sono cucina e impianto elettrico.
Anche l’hyperscaler va osservato per strati. L’infrastruttura IaaS general purpose acquistata dal fabbricante non diventa automaticamente parte del suo prodotto. Il software applicativo che il fabbricante progetta, governa e distribuisce sopra quell’infrastruttura può invece costituire la remote data processing solution. Dire «gira su cloud» equivale a dire che un ristorante si trova in un edificio: non ci racconta chi prepara il cibo, chi decide il menu e chi risponde dell’igiene della cucina.
CRA e NIS2 possono dunque abitare la stessa architettura senza contendersi la stessa stanza. Il CRA guarda alla sicurezza del prodotto e della sua soluzione remota integrata. La NIS2 presidia la gestione dei rischi dei sistemi informativi e di rete dell’entità soggetta. Il considerando 11 precisa che il CRA non estende i propri requisiti all’intera organizzazione del fabbricante. Il backend incluso va protetto come parte del prodotto; il resto dell’azienda conserva il proprio diverso perimetro normativo.
Cinque scene quotidiane per capire dove passa il confine
Prima scena: l’e-reader. Il dispositivo utilizza un servizio generico di cloud storage, scelto dall’utente, per conservare copie dei propri documenti. Se il servizio è sviluppato fuori dalla responsabilità del fabbricante, il nesso richiesto dal CRA può mancare. Se lo stesso fabbricante sviluppa una libreria cloud senza la quale l’e-reader non scarica, sincronizza o rende disponibili gli acquisti, il quadro cambia. Il libro digitale arriva attraverso una filiera progettata come parte dell’esperienza del prodotto.
Seconda scena: il braccialetto sportivo. I passi sono contati localmente; il server elabora il punteggio del sonno, costruisce lo storico e invia gli avvisi. L’assenza del backend lascia visibile il numero dei passi e spegne altre funzioni. La soluzione remota può quindi appartenere al prodotto anche se il braccialetto conserva un battito minimo di autonomia.
Terza scena: la pompa industriale con manutenzione predittiva. Il motore continua a girare senza collegamento. Sensori, gateway e piattaforma remota analizzano le vibrazioni e segnalano il rischio di guasto. Se quella capacità è commercializzata come funzione del sistema e il software remoto è sotto la responsabilità del fabbricante, separare il canone della piattaforma dalla fattura della macchina difficilmente cancella l’unità funzionale. Due fatture non generano, per magia contabile, due prodotti indipendenti.
Quarta scena: l’app che apre la porta di un albergo. Il client sul telefono contiene poco più dell’interfaccia; identità, autorizzazioni e generazione della chiave temporanea vivono sul server. Qui il backend assomiglia al cervello remoto dell’app. Un difetto nell’API di autorizzazione può aprire più porte di qualunque vulnerabilità grafica del client.
Quinta scena: il portale di assistenza di un produttore di router. Consente di scaricare manuali e aprire ticket, mentre il router svolge tutte le funzioni senza contattarlo. Quel portale accompagna il prodotto senza azionarlo. Potrà essere rilevante per altri obblighi e rischi, ma il test funzionale del trattamento remoto conduce verso un’esclusione dal perimetro del prodotto.
Gli esempi mostrano perché le risposte binarie offerte a livello di intero “cloud” siano poco utili. In uno stesso ambiente possono convivere microservizi che fanno parte del prodotto, strumenti amministrativi che lo supportano indirettamente e sistemi aziendali del tutto separati. La mappa giuridica deve avere la precisione di quella tecnica.
Quando il backend entra, la conformità attraversa tutto il viaggio del dato
L’articolo 13 impone al fabbricante una valutazione dei rischi di cybersicurezza da utilizzare durante pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione. Con una soluzione remota nel perimetro, il viaggio da esaminare parte dal dispositivo, attraversa rete e API, raggiunge identità, servizi applicativi e dati, poi torna all’utente sotto forma di comando, informazione o aggiornamento. Ogni frontiera è un luogo nel quale il rischio può cambiare passaporto.
I requisiti dell’allegato I diventano immediatamente riconoscibili. La configurazione sicura per impostazione predefinita riguarda anche account, ruoli e tenant. La protezione da accessi non autorizzati conduce verso autenticazione, autorizzazione e gestione dei privilegi. Riservatezza e integrità chiamano in causa cifratura, chiavi e protezione dei comandi. Disponibilità e resilienza fanno entrare nella conversazione rate limiting, ridondanza, backup e difese contro i denial of service. La riduzione della superficie d’attacco obbliga a contare le API esposte, non soltanto le porte aperte sul device.
Consideriamo un sistema di irrigazione connesso. Un attaccante compromette l’account cloud e modifica simultaneamente i programmi di centinaia di installazioni. Il singolo controller locale può essere impeccabile; l’incidente nasce dalla componente che orchestra tutti i controller. Il risk assessment che ignorasse identità e API assomiglierebbe a una polizza antincendio che descrive con cura i mobili e dimentica l’impianto del gas.
La documentazione tecnica deve riflettere questa realtà. Architetture, flussi, asset, minacce, misure e dipendenze vanno descritti con un confine coerente. Anche la procedura di valutazione della conformità deve coprire la soluzione remota. La marcatura CE rimane associata al prodotto secondo le regole applicabili; nessuno andrà nel data center ad apporre un adesivo su ciascun container. Dietro quel marchio, però, le evidenze dovranno comprendere il backend che consente al prodotto di svolgere le sue funzioni.
Qui si apre anche un problema organizzativo. Molte imprese hanno team separati: product security sorveglia firmware e applicazioni, cloud security presidia l’infrastruttura, DevOps gestisce i rilasci, legal scrive i contratti, customer care riceve le lamentele. Il CRA tende un filo tra queste stanze. Quando il prodotto è un sistema distribuito, la responsabilità non può perdersi nei corridoi dell’organigramma.
Vulnerabilità, SBOM e rilasci continui: il prodotto che cambia mentre lo guardiamo
I prodotti tradizionali uscivano dalla fabbrica e cambiavano lentamente. Un backend cloud può ricevere dieci rilasci in una giornata. È un prodotto che si muove mentre il giurista prova a fotografarlo, con il comprensibile rischio di ottenere soltanto immagini mosse.
Il CRA chiede al fabbricante di identificare e documentare vulnerabilità e componenti, predisporre una software bill of materials almeno per le dipendenze di primo livello, svolgere test e revisioni regolari, adottare una policy di coordinated vulnerability disclosure e distribuire gli aggiornamenti di sicurezza senza ritardo. Nel mondo cloud, la conformità deve quindi imparare il ritmo della delivery pipeline.
La SBOM del solo client racconta metà della storia quando la funzione viene eseguita sul server. Librerie applicative, immagini container, componenti open source, servizi gestiti e dipendenze critiche del backend richiedono una tracciabilità proporzionata al rischio e al perimetro effettivamente incluso. Tracciabilità non significa stampare ogni mattina un’enciclopedia di pacchetti. Significa poter ricostruire, davanti a una vulnerabilità, quali versioni del prodotto e quali utenti siano esposti, quali controlli siano presenti e quale intervento serva.
Si pensi a una libreria di autenticazione vulnerabile utilizzata da un servizio remoto condiviso. Una sola patch può proteggere milioni di installazioni; un solo ritardo può lasciarle esposte tutte insieme. Il cloud concentra efficienza e rischio nello stesso punto, come un acquedotto: è molto più pratico di un pozzo per ogni casa, ma la qualità dell’acqua a monte diventa affare di tutti.
Anche il concetto di modifica sostanziale acquista rilievo. Un aggiornamento che aggiunge al backend una nuova interfaccia, amplia le funzioni o modifica significativamente il rischio può richiedere una nuova valutazione della conformità. Ogni deployment non diventa automaticamente una nuova immissione sul mercato; serve però un processo capace di riconoscere il momento nel quale l’evoluzione smette di essere manutenzione ordinaria e cambia identità o rischio del prodotto.
Il support period e la promessa nascosta nel pulsante “connetti”
Il CRA lega la gestione delle vulnerabilità al periodo di supporto, determinato in funzione del tempo durante il quale il prodotto è ragionevolmente atteso in uso. La regola generale fissa almeno cinque anni, salvo che la vita attesa sia più breve. Per un dispositivo con backend, il calendario della sicurezza deve fare i conti con il calendario del servizio.
Un produttore può vendere oggi una telecamera destinata a restare su un muro per otto anni e decidere fra tre anni di spegnere il cloud che invia le notifiche. Il CRA non crea, da solo, una garanzia universale di disponibilità perpetua. Eppure, quando quel cloud appartiene al prodotto, la sua cessazione incide su funzioni, supporto, informazioni rese all’utente e gestione delle vulnerabilità. Il pulsante “connetti” porta con sé una promessa temporale spesso più impegnativa di quanto suggerisca la sua grafica innocente.
La complessità cresce quando un unico backend serve varie generazioni di prodotti. Il modello 2025, quello 2027 e quello 2030 possono condividere identità e API pur avendo periodi di supporto differenti. Disattivare una versione, cambiare un protocollo o rimuovere una funzione richiede di sapere quali popolazioni dipendono ancora da quel pezzo di architettura. In mancanza di una mappa, il fine vita assomiglia allo spegnimento delle luci in un palazzo senza sapere chi sia rimasto dentro.
La Commissione è chiamata dall’articolo 26 a fornire indicazioni sul trattamento remoto, sui periodi di supporto, sull’interazione con altre norme e sulla modifica sostanziale. Il 3 marzo 2026 ha pubblicato una bozza di linee guida per consultazione. Alla data di questo contributo, il documento costituisce un orientamento in formazione: utile per comprendere il cantiere interpretativo, privo della forza necessaria per riscrivere il Regolamento.
Il fabbricante resta al volante, anche se il motore cloud è in leasing
Il fabbricante è il soggetto che sviluppa o fa sviluppare il prodotto e lo commercializza sotto il proprio nome o marchio. La definizione fotografa una responsabilità di regia. Software house, managed service provider e hyperscaler possono fornire pezzi essenziali; chi porta il prodotto sul mercato con il proprio nome resta al volante.
Il contratto di outsourcing dovrebbe quindi diventare una prolunga operativa degli obblighi CRA. Accesso alle evidenze, inventario dei componenti, segnalazione delle vulnerabilità, tempi di remediation, controllo delle modifiche, disponibilità dei log, supporto alle notifiche e cooperazione con le autorità devono scendere dalla clausola generica alla procedura concreta. Scrivere “il fornitore garantisce la sicurezza” equivale a consegnargli un ombrello disegnato su un foglio durante un temporale.
La questione è particolarmente delicata nei gruppi societari. Una società vende il dispositivo, una seconda sviluppa l’app, una terza gestisce il cloud. L’utente vede un solo marchio e una sola esperienza. L’analisi deve ricostruire chi progetta, chi controlla e sotto la responsabilità di chi opera ciascuna soluzione. La frammentazione societaria può distribuire attività e obblighi contrattuali; la funzione promessa al mercato rimane il punto di partenza.
Importatori e distributori devono esercitare le verifiche previste dal CRA e possono diventare fabbricanti quando immettono il prodotto con il proprio nome o marchio o effettuano una modifica sostanziale. Per i prodotti extra-UE, il backend è spesso la parte meno visibile e più difficile da governare. Prima di importare occorre capire chi può fornire documentazione, correggere una vulnerabilità server-side, mantenere il supporto e cooperare in caso di incidente. La scatola può attraversare la dogana in un giorno; la responsabilità del cloud resta con il prodotto per anni.
Le conseguenze economiche danno concretezza al quadro. La violazione dei requisiti essenziali e degli obblighi degli articoli 13 e 14 può essere sanzionata fino a 15 milioni di euro o, per le imprese, fino al 2,5 per cento del fatturato mondiale annuo dell’esercizio precedente, se superiore. L’architettura del prodotto diventa così anche architettura dell’esposizione regolatoria.
L’utilizzatore professionale: cliente oggi, fabbricante domani?
L’impresa che acquista e usa un prodotto con elementi digitali non diventa, per questo solo fatto, un operatore economico soggetto agli obblighi del fabbricante. Il CRA, tuttavia, conosce trasformazioni degne di un romanzo: chi rebrandizza il prodotto, lo modifica sostanzialmente e lo rimette a disposizione sul mercato può ritrovarsi con il cappello del fabbricante.
Accade facilmente nei progetti industriali e nelle piattaforme white label. Un integratore acquista un componente, aggiunge un proprio backend, amplia le funzioni e vende il risultato con il suo marchio. A quel punto la domanda sulla responsabilità deve essere riaperta. Molte integrazioni restano semplici integrazioni; quando la modifica cambia destinazione, funzioni o rischio, il baricentro regolatorio può invece spostarsi.
Anche il cliente che rimane cliente ha ottime ragioni per interessarsi al perimetro. Un soggetto NIS2 o DORA dovrebbe chiedere quali componenti remote siano comprese nella conformità, quale sia il support period, come vengano gestite vulnerabilità e modifiche, chi riceva le segnalazioni e come un incidente del backend raggiunga il proprio processo di risposta. Il considerando 13 ammette espressamente requisiti di procurement più stringenti per esigenze specifiche.
Qui il CRA può migliorare la qualità delle gare e dei contratti. Una marcatura CE non dovrebbe diventare il timbro che chiude ogni conversazione. Il compratore professionale può chiedere di vedere il perimetro: quale parte del cloud accompagna il prodotto? Quali funzioni dipendono da essa? Dove terminano gli obblighi del fabbricante e iniziano quelli del cliente? Una buona domanda di procurement vale spesso più di dieci pagine di dichiarazioni rassicuranti.
La preparazione: disegnare il prodotto prima che lo faccia un incidente
Le principali disposizioni del CRA si applicheranno dall’11 dicembre 2027. Gli obblighi di segnalazione dell’articolo 14 arriveranno prima, l’11 settembre 2026. Le date suggeriscono una priorità: la mappa delle remote data processing solutions va costruita ora, mentre c’è ancora tempo per correggere architetture e contratti.
Il lavoro può iniziare con un inventario delle funzioni, non dei server. Per ciascun prodotto occorre elencare ciò che viene promesso all’utente e seguire ogni funzione lungo il suo percorso tecnico. Quale codice gira localmente? Quale calcolo avviene a distanza? Quale API viene chiamata? Chi sviluppa il servizio? Chi ne approva le modifiche? Che cosa accade quando il collegamento o il servizio scompaiono? Questa sequenza trasforma un diagramma cloud in una mappa giuridica.
Segue la decisione di perimetro. Ogni componente remoto incluso o escluso merita una motivazione documentata. Le esclusioni sono particolarmente importanti: durante un controllo, spiegare perché un sistema aziendale resti fuori dal prodotto sarà più credibile se l’analisi è stata svolta prima dell’incidente e non nella notte precedente all’ispezione.
Poi viene la governance. Serve un owner capace di vedere il prodotto end-to-end e un processo che colleghi product security, cloud security, sviluppo, DevOps, legal, procurement, customer care e incident response. La remote data processing solution vive fra molte squadre; senza un proprietario comune rischia di diventare il pianerottolo sul quale tutti lasciano il problema perché appartiene alla porta accanto.
Infine arrivano le evidenze: risk assessment, threat model, SBOM, test, registri delle modifiche, policy di disclosure, procedure di aggiornamento, istruzioni, decisioni sul support period e clausole dei fornitori. Ricostruirle a posteriori è possibile quanto ricomporre un vaso dopo aver buttato via metà dei cocci. La conformità funziona meglio quando cresce insieme al prodotto.
Conclusioni: seguire il filo della funzione
Le remote data processing solutions sono il punto nel quale il CRA incontra l’architettura reale dei prodotti digitali. Il diritto segue il filo della funzione: parte dall’oggetto o dal software consegnato all’utente, attraversa le interfacce e arriva fino al trattamento remoto che consente a quella funzione di esistere.
Per app, IoT, piattaforme ibride e sistemi industriali, la domanda utile contiene tre passaggi: chi governa il software remoto, quale funzione abilita e che cosa resta del prodotto quando quel software viene tolto dal disegno. Le risposte determinano il perimetro della valutazione, la documentazione tecnica, i contratti, il vulnerability handling, il supporto e la gestione degli incidenti.
Il backend è stato a lungo il domestico invisibile del prodotto digitale: apriva porte, portava messaggi, conservava chiavi, mentre tutta l’attenzione restava sull’eleganza del salotto. Il CRA gli assegna finalmente un ruolo nel copione giuridico. Quando la funzione promessa vive anche nel cloud, la responsabilità deve saperci arrivare.
Riferimenti essenziali
• Regolamento (UE) 2024/2847 — Cyber Resilience Act, testo vigente su EUR-Lex
• Commissione europea, Cyber Resilience Act — pagina di attuazione
• Commissione europea, Cyber Resilience Act — Manufacturers
• Commissione europea, bozza di linee guida sul CRA pubblicata per consultazione il 3 marzo 2026
• Commissione europea, sintesi del testo legislativo del CRA
Nota sullo stato delle fonti: il contributo è aggiornato al 19 luglio 2026. Le linee guida della Commissione citate nel testo risultano pubblicate in bozza per consultazione e non sostituiscono né modificano il Regolamento.
Partecipa alla community