# Assigned Representative sulla SRP: chi è, e come sceglierlo secondo la dimensione dell'azienda > Le 24 ore per il preallarme corrono anche di sabato, e a farle correre è una persona precisa. Chi è l'Assigned Representative della piattaforma ENISA, perché non coincide con il rappresentante autorizzato del CRA, e come si sceglie dalla microimpresa alla multinazionale. - URL: https://albertoscarpa.com/blog/it/assigned-representative-srp-scelta/ - Lingua / Language: Italiano - Pubblicato: 2026-08-12 - Tag: CRA --- Le 24 ore per il preallarme corrono anche di sabato, e a farle correre è una persona precisa: chi ha l'account sulla piattaforma e l'autorità per notificare. Su questa scelta un'azienda si gioca la differenza tra un adempimento ordinato e una scadenza persa perché l'unico che sapeva farlo era in ferie. Quel ruolo è l'Assigned Representative (AR). Sceglierlo è una decisione di processo, da prendere prima del lancio della piattaforma. Per il quadro completo della piattaforma e delle scadenze, il punto di partenza è la guida [La Single Reporting Platform del CRA](/guide/it/single-reporting-platform-guida/). ## Due rappresentanti da non confondere Il nome trae in inganno. L'Assigned Representative della Single Reporting Platform (SRP) non è il "rappresentante autorizzato" del Cyber Resilience Act (art. 3, punto 15, e art. 18: una persona stabilita nell'Unione con mandato scritto del fabbricante). L'AR della piattaforma è chi opera la SRP e invia le notifiche per conto del fabbricante. Per un fabbricante con sede nell'UE l'AR è una persona interna autorizzata, e la distinzione resta netta. Per un fabbricante extra-UE i due ruoli tendono a coincidere, e la coincidenza ha una conseguenza pratica: la sede del rappresentante autorizzato determina il CSIRT coordinatore competente (art. 14, par. 7, terzo comma, lett. a). Chi vende in Europa dall'estero sceglie, con il rappresentante, anche l'autorità nazionale a cui risponderà. ## Un ruolo, tre funzioni L'AR raccoglie in un solo ruolo tre funzioni che nelle aziende grandi stanno su persone diverse: - Valutare: la segnalazione è uno sfruttamento attivo? è un incidente grave? È un giudizio tecnico. - Decidere: autorizzare la disclosure, marcare il grado di sensibilità o le circostanze eccezionali, impegnare l'azienda. È un giudizio di responsabilità. - Operare: compilare e inviare sulla piattaforma entro i tempi. È esecuzione. Scegliere l'AR significa decidere come distribuire queste tre funzioni. In una struttura piccola stanno sulla stessa persona; man mano che l'azienda cresce si separano, e la scelta diventa una questione di governance, non di nomina di un singolo. ## I quattro criteri, validi a ogni dimensione Autorità: l'AR deve poter decidere sotto scadenza, non solo eseguire. Una notifica coinvolge scelte di disclosure che vanno prese in ore. Conoscenza tecnica del prodotto: i campi delle 72 ore e della relazione finale chiedono la natura della vulnerabilità, dello sfruttamento, delle misure correttive. Chi opera deve capire cosa sta scrivendo. Reperibilità entro 24 ore, weekend compresi: da qui il backup obbligatorio, non facoltativo. Un solo AR è un single point of failure con una scadenza legale attaccata. Continuità: l'AR va definito come ruolo con vice nominato, così che non svanisca quando una persona cambia lavoro. ## Come cambia con la dimensione dell'azienda ### Microimpresa (sotto le 10-15 persone) Le tre funzioni collassano su una o due persone. L'AR primario è il CTO o il titolare tecnico, quello che conosce il firmware e sa dire se un exploit è reale; il backup è il titolare o un secondo ingegnere. Il rischio dominante è il single point of failure: se l'unico che sa notificare è in ferie, le 24 ore corrono lo stesso. Un consulente esterno può supportare la valutazione, mentre l'account resta in capo al fabbricante. Qui la scelta non è "chi", è garantire che almeno due persone possano agire. ### Piccola (15-50 persone) È il primo livello in cui conviene separare il valutare dall'operare. L'AR primario sta sul responsabile prodotto o qualità, il backup su un lead R&D. Serve una mini-escalation scritta: chi stima la gravità tecnica, chi autorizza l'invio, in che ordine si chiamano. Una pagina, non un manuale. ### Media (50-500 persone) L'AR va reso un ruolo formale, tipo Product Security Officer o responsabile di un PSIRT anche leggero, con vice nominato e agganciato al processo di incident response esistente. La governance diventa a matrice: R&D valuta, management o legale autorizza la disclosure e la marcatura delle circostanze eccezionali, l'AR opera la piattaforma. Chi ha già un sistema qualità certificato o un percorso IEC 62443 ha il processo di gestione delle vulnerabilità (art. 13; Allegato I, parte II, punto 5) su cui appoggiare tutto questo. ### Grande e multinazionale Il problema diventa la mappatura delle entità legali. La SRP associa l'AR a un fabbricante, e lo stabilimento principale determina il CSIRT (art. 14, par. 7): un gruppo con più entità produttive in più Stati membri può ritrovarsi con CSIRT coordinatori diversi per entità diverse. Servono più registrazioni fabbricante, ciascuna con AR primario e backup, e un PSIRT centrale che coordina per evitare notifiche duplicate o incoerenti sullo stesso prodotto. Per un quartier generale extra-UE serve il rappresentante autorizzato ex art. 18 stabilito nell'Unione, e la sua sede fissa il CSIRT competente. ## Reperibilità: la copertura deve essere doppia Le tre funzioni vanno coperte tutte nella finestra delle 24 ore: l'intake che allerta, la valutazione tecnica, l'autorità di aprire. Se il tecnico è raggiungibile ma non può autorizzare, o il decisore è raggiungibile ma non sa valutare, il processo si blocca comunque. Coprire solo il tecnico lascia scoperto il punto in cui la notifica si apre davvero. Il meccanismo che rende sostenibile la copertura dell'autorità è la pre-delega. Non serve il titolare reperibile ogni weekend: serve che abbia pre-autorizzato per iscritto l'invio di un early warning da parte dell'AR di turno, su sospetto credibile, senza attendere una firma. L'early warning è minimale, preliminare e correggibile (art. 14, par. 2, lett. a), quindi il suo invio è una decisione a basso rischio e delegabile. Restano al vertice le decisioni pesanti, la marcatura delle circostanze eccezionali e la disclosure pubblica, che vivono nella finestra delle 72 ore e della relazione finale, dove c'è tempo per scalare. La reperibilità dell'autorità si ottiene delegando in anticipo la sola decisione con scadenza a 24 ore, non mettendo il titolare di guardia. Come si arriva alla decisione di aprire, con segnalante silenzioso o AR non tecnico, è in [Da segnalazione a notifica](/blog/it/da-segnalazione-a-notifica-srp/). ## Cosa fare adesso > Nota operativa (mia indicazione, non testo di legge). La nomina dell'AR si chiude prima del lancio della piattaforma, in tre mosse. Definire il ruolo, non la persona: AR primario e backup come funzioni, con nomi intercambiabili. Creare subito i due account EU Login, l'unico passo che non dipende dall'attivazione della SRP. Scrivere una pagina di escalation che dica chi valuta, chi autorizza, chi opera, con quali recapiti raggiungibili nei giorni di chiusura, e la pre-delega scritta dell'early warning all'AR di turno. La scelta dell'AR non misura la maturità dei tuoi prodotti, misura la prontezza del tuo processo. Un'azienda con prodotti ancora acerbi ma con AR, backup ed escalation definiti arriva pronta alla scadenza di settembre 2026; una con prodotti maturi ma senza nessuno che sappia notificare di sabato, no. --- *Riferimenti: Regolamento (UE) 2024/2847 (CRA), art. 3 (punti 15 e 42), art. 13, art. 14 (in particolare par. 7), art. 18 e Allegato I, parte II, punto 5. Guidance non vincolante: pagine ENISA sulla SRP e relativa FAQ (aggiornate al 3 agosto 2026). Le note segnalate come operative sono mie interpretazioni, non testo normativo. Numeri di articolo verificati sul testo ufficiale del CRA in lingua italiana.*