Regolamento sulla resilienza informatica: ENISA SRP, sett. 2026

Il Regolamento sulla resilienza informatica (Cyber Resilience Act, regolamento (UE) 2024/2847) trasforma la segnalazione delle vulnerabilità e degli incidenti in un obbligo giuridico vincolante con scadenze precise. Dall'11 settembre 2026, l'Articolo 14 del CRA impone al fabbricante di notificare qualsiasi vulnerabilità attivamente sfruttata e qualsiasi incidente grave entro 24 ore, con un'escalation verso una notifica a 72 ore, una relazione finale entro 14 giorni per le vulnerabilità (dalla disponibilità di una misura correttiva o di attenuazione) e una relazione finale entro un mese per gli incidenti gravi. Il canale di notifica è la piattaforma di segnalazione unica ENISA (SRP), prevista per essere operativa entro l'11 settembre 2026, che instrada la segnalazione simultaneamente al CSIRT coordinatore designato e a ENISA. Il mancato rispetto delle scadenze espone alle sanzioni dell'Articolo 64, fino a 15.000.000 € o al 2,5% del fatturato annuo mondiale (il maggiore tra i due).

La piattaforma SRP di ENISA: ruolo e funzionamento

Il CRA richiedeva un canale unico perché l'Articolo 14, paragrafo 1, impone al fabbricante di notificare «simultaneamente al CSIRT designato come coordinatore, conformemente al paragrafo 7 del presente articolo, e a ENISA». Prima della SRP, questo significava potenzialmente presentare la stessa segnalazione a più CSIRT nazionali. L'Articolo 16 risolve la tensione: ENISA istituisce e gestisce la piattaforma, e «la gestione e la manutenzione quotidiane di tale piattaforma di segnalazione unica sono assicurate da ENISA» (Articolo 16, paragrafo 1).

L'architettura è lineare. Il fabbricante invia una sola notifica tramite il terminale elettronico del CSIRT coordinatore. Sia il CSIRT che ENISA ricevono la notifica simultaneamente. Ai sensi dell'Articolo 16, paragrafo 2, è il CSIRT coordinatore ad essere responsabile della diffusione della notifica ai CSIRT degli altri Stati membri in cui il prodotto è immesso sul mercato. Quella diffusione secondaria è responsabilità del CSIRT, non del fabbricante.

La SRP è prevista per essere operativa entro l'11 settembre 2026, secondo le FAQ ENISA sulla SRP. È atteso un periodo di test prima di tale data; nessuna finestra specifica è stata pubblicata. ENISA ha bandito l'implementazione con la gara ENISA/2025/OP/0001 (contratto quadriennale), chiusa a marzo 2025. Il fornitore non è stato reso pubblico. Nessun URL di registrazione è stato pubblicato. Si raccomanda di monitorare la pagina ENISA SRP per gli aggiornamenti.

Cosa attiva la segnalazione CRA?

Il Regolamento sulla resilienza informatica definisce due categorie che impongono la notifica obbligatoria:

1. Vulnerabilità attivamente sfruttate

Una vulnerabilità nel prodotto che:

• È nota al fabbricante (rilevata internamente o segnalata dall'esterno)
• È stata sfruttata da un attore malevolo
• Colpisce o potrebbe colpire gli utenti del prodotto

2. Incidenti gravi

Incidenti di sicurezza che:

• Compromettono la sicurezza del prodotto
• Intaccano l'ambiente di sviluppo in modi che influenzano la sicurezza del prodotto
• Causano un'interruzione diffusa del servizio agli utenti
• Risultano in una compromissione su vasta scala

Entrambe le categorie attivano lo stesso obbligo di avviso preliminare, ma hanno finestre diverse per la relazione finale.

Cosa significa «attivamente sfruttata» ai sensi del CRA?

Il CRA definisce una vulnerabilità attivamente sfruttata come quella in cui «un attore malevolo fa uso di una falla».

Questo non coincide con:

• Una vulnerabilità divulgata pubblicamente
• Una proof-of-concept pubblicata
• Un ricercatore che dimostra la sfruttabilità

Significa uso malevolo reale.

Scenari da segnalare e scenari non segnalabili

Lo standard della «ragionevole convinzione»

Non è necessaria la prova forense dello sfruttamento. Lo standard è la ragionevole convinzione basata sulle evidenze disponibili:

• Pattern di accesso insoliti coerenti con tecniche di exploit note
• Segnalazioni di clienti di compromissione
• Intelligence sulle minacce che indica che il prodotto è preso di mira
• Rilevamento di codice exploit progettato per il prodotto in esame

In caso di incertezza: meglio segnalare in via prudenziale. Un avviso preliminare anticipato che si rivela infondato è di gran lunga preferibile a una scadenza mancata per uno sfruttamento reale.

Scadenze di segnalazione

Sia le vulnerabilità che gli incidenti seguono un modello di segnalazione a stadi:

Cronologia per vulnerabilità attivamente sfruttata

SCOPERTA → 24 ORE → 72 ORE → MISURA DISPONIBILE → 14 GIORNI
    |           |         |           |                  |
    |           |         |           |                  \-- Relazione finale
    |           |         |           \-- Il conto riprende
    |           |         \-- Notifica dettagliata
    |           \-- Avviso preliminare
    \-- Il conto inizia

Cronologia per incidente grave

SCOPERTA → 24 ORE → 72 ORE → 1 MESE
    |           |         |        |
    |           |         |        \-- Relazione finale
    |           |         \-- Notifica di incidente
    |           \-- Avviso preliminare
    \-- Il conto inizia

Per gli incidenti gravi, il termine di un mese decorre dalla notifica di incidente a 72 ore, non dalla scoperta (Articolo 14, paragrafo 4, lettera c).

Contenuto di ciascuna segnalazione

Avviso preliminare (24 ore)

Informazioni minime per allertare le autorità:

• Identità del fabbricante
• Identificazione del prodotto o dei prodotti interessati
• Breve descrizione della vulnerabilità o dell'incidente
• Valutazione iniziale della gravità
• Se lo sfruttamento è confermato o sospettato
• Indicazione della portata potenziale dell'impatto

Non si tratta di un'analisi completa. È un segnale che qualcosa di grave sta accadendo.

Notifica dettagliata (72 ore)

A 72 ore si applicano due obblighi distinti. La notifica di vulnerabilità a 72 ore (Articolo 14, paragrafo 2, lettera b) riguarda le vulnerabilità attivamente sfruttate; la notifica di incidente a 72 ore (Articolo 14, paragrafo 4, lettera b) riguarda gli incidenti gravi. Dopo la prima menzione, «notifica dettagliata» li comprende entrambi. Informazioni ampliate per la valutazione:

• Dettagli tecnici della vulnerabilità
• Versioni e configurazioni interessate
• Metodo di sfruttamento (se noto)
• Stato attuale della mitigazione
• Stima della timeline di rimedio
• Utenti o portata interessati noti
• Coordinamento con terze parti (altri fabbricanti, CSIRT)

Relazione finale (14 giorni per le vulnerabilità / un mese per gli incidenti)

Per le vulnerabilità attivamente sfruttate, il termine di 14 giorni decorre «al più tardi 14 giorni dopo che una misura correttiva o di attenuazione è disponibile» (Articolo 14, paragrafo 2, lettera c), non dalla scoperta né dalla notifica a 72 ore. Analisi completa a seguito del rimedio:

• Analisi delle cause radice
• Descrizione tecnica integrale
• Azioni di rimedio intraprese
• Insegnamenti tratti
• Misure preventive attuate
• Valutazione dell'impatto (utenti colpiti confermati, esposizione dei dati, ecc.)

Base giuridica CRA: Articoli 14, 16, 64

Articolo 14: l'obbligo di segnalazione

L'Articolo 14 stabilisce l'obbligo di segnalazione e le relative scadenze per tutti i fabbricanti di prodotti con elementi digitali. Il testo recita in parte: «Il fabbricante notifica qualsiasi vulnerabilità attivamente sfruttata contenuta nel prodotto con elementi digitali di cui viene a conoscenza simultaneamente al CSIRT designato come coordinatore, conformemente al paragrafo 7 del presente articolo, e a ENISA.» (Articolo 14, paragrafo 1).

L'Articolo 14, paragrafo 7, fissa la regola di instradamento. La notifica avviene tramite la SRP al CSIRT dello Stato membro in cui l'organizzazione ha il proprio stabilimento principale, inteso come il luogo in cui vengono prese prevalentemente le decisioni in materia di sicurezza informatica dei prodotti. Per i fabbricanti stabiliti fuori dall'UE, la cascata segue questo ordine: lo Stato membro del rappresentante autorizzato, poi dell'importatore, poi del distributore, poi del paese con la maggiore concentrazione di utenti. Se il fabbricante ha più di un rappresentante autorizzato, la cascata seleziona lo Stato membro in cui il rappresentante copre il maggior numero di prodotti.

Articolo 16: il mandato sulla piattaforma

L'Articolo 16, paragrafo 1, impone a ENISA di istituire la SRP e di gestirne le operazioni quotidiane. Gli Stati membri possono istituire terminali nazionali che si interfacciano con la SRP (Articolo 16, paragrafo 1). Ai sensi dell'Articolo 16, paragrafo 2, i CSIRT possono ritardare la diffusione delle notifiche ad altri Stati membri in circostanze particolarmente eccezionali per proteggere operazioni di sicurezza in corso; questa è una prerogativa del CSIRT, non del fabbricante. L'Articolo 16, paragrafo 5, impone a ENISA e alla rete dei CSIRT di sviluppare congiuntamente le specifiche tecniche della SRP. L'Articolo 16, paragrafo 6, riguarda l'interazione con la divulgazione coordinata: la diffusione di una notifica relativa a una vulnerabilità sottoposta a divulgazione coordinata può essere ritardata con il consenso del fabbricante.

Dove si presenta una segnalazione ai sensi dell'Articolo 14 del CRA?

Piattaforma di segnalazione unica ENISA (SRP)

Ad aprile 2026, la SRP non è ancora operativa. La piattaforma è prevista per essere operativa entro l'11 settembre 2026 (secondo le FAQ ENISA). È atteso un periodo di test prima di tale data; nessuna data specifica è stata pubblicata. Nessun URL di registrazione è stato pubblicato. Si raccomanda di monitorare la pagina ENISA SRP per gli aggiornamenti.

Cosa è confermato:

• Piattaforma web per le notifiche
• Moduli di segnalazione standardizzati
• La notifica tramite la SRP raggiunge simultaneamente il CSIRT coordinatore designato e ENISA (Articolo 14, paragrafo 1)

Cosa il fabbricante può fare adesso:

• Predisporre i template di segnalazione usando la struttura riportata di seguito
• Identificare il CSIRT coordinatore (si veda oltre)
• Definire i percorsi di escalation interni e i reporter autorizzati

CSIRT nazionali

Ai sensi dell'Articolo 14, paragrafo 7, del Regolamento (UE) 2024/2847, il fabbricante notifica una sola volta tramite la SRP al CSIRT dello Stato membro in cui la propria organizzazione ha lo stabilimento principale. Stabilimento principale indica il luogo in cui vengono prese prevalentemente le decisioni sulla sicurezza informatica del prodotto.

Se il fabbricante è stabilito al di fuori dell'UE, il CSIRT competente è quello del rappresentante autorizzato UE. In assenza di un rappresentante autorizzato, la cascata ricade sull'importatore, poi sul distributore, poi sul paese con la maggiore concentrazione di utenti.

Non è necessario notificare ogni CSIRT in ogni paese in cui il prodotto è commercializzato. Ai sensi dell'Articolo 16, ENISA instrada la notifica ai CSIRT dei paesi di mercato a valle della notifica del fabbricante. Quel passaggio non è responsabilità del fabbricante.

Per i fabbricanti con stabilimento principale in Italia, il CSIRT competente è CSIRT Italia, operato dall'ACN (Agenzia per la Cybersicurezza Nazionale).

Per prodotti presenti in più Stati membri

Una sola notifica alla SRP copre l'obbligo di segnalazione del fabbricante. Potrebbero arrivare richieste di follow-up da più autorità nazionali, ma il percorso di notifica è unico.

Come prepararsi alla segnalazione ai sensi dell'Articolo 14

Consiglio: Pre-approvare i template di notifica e stabilire percorsi di escalation operativi 24 ore su 24, 7 giorni su 7, adesso. Non si possono redigere template durante una scadenza di 24 ore.

Non si deve attendere settembre 2026. I processi vanno costruiti ora.

1. Canali di ricezione delle vulnerabilità

Stabilire percorsi chiari per le segnalazioni di vulnerabilità:

File security.txt:

# https://ilmioprodotto.com/.well-known/security.txt
Contact: mailto:security@miaazienda.com
Contact: https://miaazienda.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: it
Canonical: https://miaazienda.com/.well-known/security.txt
Policy: https://miaazienda.com/security/policy

Modulo web per segnalazioni strutturate

Indirizzo email dedicato monitorato 24/7 (o con SLA definito)

2. Processo di triage interno

Definire come vengono valutate le segnalazioni:

TRIAGE RICEZIONE VULNERABILITÀ

1. Ricezione iniziale (< 4 ore)
   - Confermare la ricezione
   - Assegnare a un membro del team di sicurezza
   - Verifica iniziale di validità

2. Triage tecnico (< 24 ore)
   - Confermare che la vulnerabilità esiste
   - Determinare le versioni interessate
   - Valutare la sfruttabilità
   - Verificare le evidenze di sfruttamento attivo

3. Valutazione della gravità (< 24 ore)
   - Scoring CVSS (o equivalente)
   - Valutazione dell'impatto sul business
   - Probabilità di sfruttamento

4. Decisione di segnalazione (IMMEDIATA se lo sfruttamento è confermato)
   - Questo richiede una notifica ENISA?
   - In caso affermativo, avviare il conto delle 24 ore

3. Percorsi di escalation

Definire chi può avviare la segnalazione esterna:

Principio chiave: chi scopre un potenziale sfruttamento deve poter fare escalation immediatamente, a qualsiasi ora.

4. Copertura fuori orario

Il conto delle 24 ore non si ferma nei fine settimana né nei giorni festivi.

Opzioni:

• Rotazione di reperibilità per il team di sicurezza
• Servizio di monitoraggio con autorità di escalation
• Catena di contatto fuori orario definita
• Reporter pre-autorizzati abilitati a inviare avvisi preliminari

5. Template di segnalazione

Preparare i template prima di averne bisogno:

Template avviso preliminare:

AVVISO PRELIMINARE CRA ENISA

Fabbricante: [Nome azienda]
Data segnalazione: [Data/Ora UTC]
Tipo segnalazione: [ ] Vulnerabilità attivamente sfruttata [ ] Incidente grave

PRODOTTO/I INTERESSATO/I:
- Nome prodotto:
- Versione/i:
- Categoria prodotto:

SOMMARIO VULNERABILITÀ/INCIDENTE:
[Breve descrizione - 2-3 frasi]

STATO SFRUTTAMENTO:
[ ] Sfruttamento confermato
[ ] Sfruttamento sospettato
Evidenze: [Breve descrizione delle evidenze]

VALUTAZIONE INIZIALE DELLA GRAVITÀ:
[ ] Critica [ ] Alta [ ] Media [ ] Bassa
Base: [Score CVSS o altra motivazione]

PORTATA POTENZIALE DELL'IMPATTO:
- Utenti stimati interessati:
- Portata geografica:
- Dati a rischio:

STATO ATTUALE:
[ ] In corso di indagine
[ ] Mitigazione in corso
[ ] Patch in sviluppo

REFERENTE PER IL FOLLOW-UP:
Nome:
Email:
Telefono:

Questo è un avviso preliminare. Notifica dettagliata a seguire entro 72 ore.

6. Testare il processo

Eseguire esercitazioni tabletop prima di settembre 2026:

Scenario 1: Venerdì ore 17:00 - Un ricercatore di sicurezza segnala una vulnerabilità critica con PoC

• Con quale velocità si riesce a valutare il rischio di sfruttamento?
• Chi prende la decisione di segnalazione nel fine settimana?

Scenario 2: Un cliente segnala attività sospetta che suggerisce che il prodotto sia stato il punto di ingresso

• Come si raccolgono le evidenze per confermare o smentire lo sfruttamento?
• Qual è la soglia per la «ragionevole convinzione»?

Scenario 3: L'intelligence sulle minacce indica che il prodotto è preso di mira da un gruppo APT

• Si ha visibilità sullo sfruttamento effettivo?
• Come ci si coordina con i provider esterni di threat intelligence?

Errori ricorrenti nella segnalazione CRA

Attendere la certezza

Problema: voler disporre di prove forensi prima di segnalare.

Realtà: il conto delle 24 ore parte quando si forma una ragionevole convinzione. Chi attende la certezza mancherà la scadenza.

Soluzione: segnalare in anticipo. Nella notifica dettagliata si può aggiornare con «non più ritenuto sfruttato» se le evidenze non lo confermano.

Confondere CVD e segnalazione

Problema: trattare le segnalazioni dei ricercatori come notifiche ENISA.

Realtà: la divulgazione coordinata delle vulnerabilità (CVD) e la segnalazione ai sensi dell'Articolo 14 del CRA sono processi distinti.

• CVD: gestione delle segnalazioni dei ricercatori e concordato delle timeline di divulgazione
• Segnalazione CRA: notifica obbligatoria quando si verifica lo sfruttamento

Soluzione: il processo CVD deve includere un gate: «Ci sono evidenze di sfruttamento?» In caso affermativo, avviare la segnalazione ai sensi dell'Articolo 14 del CRA in parallelo al CVD.

Punto unico di guasto

Problema: solo una persona può autorizzare le segnalazioni ed è irraggiungibile.

Realtà: lo sfruttamento può essere scoperto in qualsiasi momento: fine settimana, festivi, alle 3 di notte.

Soluzione: più reporter autorizzati, delega chiara, catena di contatto di emergenza.

Nessun rapporto con i CSIRT

Problema: il primo contatto con il CSIRT nazionale avviene durante un incidente.

Realtà: costruire una relazione in anticipo rende più fluida la risposta agli incidenti reali.

Soluzione: contattare CSIRT Italia (ACN) adesso. Comprendere i loro processi. Partecipare a eventuali programmi di outreach per fabbricanti.

Esenzioni per micro e piccole imprese

Le microimprese e le piccole imprese beneficiano di un margine ai sensi dell'Articolo 64, paragrafo 10:

Esenzione dalle scadenze di notifica: esenti dalle sanzioni per il mancato rispetto della scadenza dell'avviso preliminare di 24 ore prevista dall'Articolo 14, paragrafo 2, lettera a, e dall'Articolo 14, paragrafo 4, lettera a. La scadenza della notifica dettagliata a 72 ore (Articolo 14, paragrafo 2, lettera b, e Articolo 14, paragrafo 4, lettera b) non è coperta dall'esenzione. Il mancato rispetto può comportare sanzioni indipendentemente dalle dimensioni dell'impresa.

Obblighi che restano in vigore:

• La segnalazione (l'esenzione riguarda solo la tempistica delle 24 ore)
• Tutti gli altri obblighi CRA
• Le relazioni finali

Definizione: si applica alle microimprese (meno di 10 dipendenti, fatturato annuo o totale di bilancio fino a 2 milioni di EUR) e alle piccole imprese (meno di 50 dipendenti, fatturato annuo o totale di bilancio fino a 10 milioni di EUR). Le medie imprese (fino a 250 dipendenti) non rientrano in questa esenzione.

L'esenzione copre solo la sanzione relativa all'avviso preliminare di 24 ore. Tutti i fabbricanti, comprese le microimprese, devono predisporre le capacità di segnalazione.

Integrazione con i processi esistenti

Se si dispone già di un processo di incident response

Mappare la segnalazione CRA sul processo esistente:

PROCESSO IR ESISTENTE          INTEGRAZIONE CRA
---------------------------------------------
Rilevazione
    |
Triage ------------------→  Verifica: sfruttamento su prodotto CRA?
    |                             |
Contenimento                      +- SÌ: Avviare conto 24 ore
    |                             |       Inviare avviso preliminare
Indagine                          |
    |                             |
Rimedio ------------------→  Notifica dettagliata a 72 ore
    |
Ripristino
    |
Insegnamenti tratti ------→  Relazione finale 14 giorni/1 mese

Se si hanno obblighi ai sensi della NIS 2

Alcune organizzazioni hanno sia obblighi NIS 2 che CRA:

• NIS 2: incidenti a livello di organizzazione o servizio
• CRA: vulnerabilità e incidenti a livello di prodotto

Questi possono sovrapporsi. Un singolo incidente potrebbe richiedere:

• Notifica NIS 2 all'autorità competente
• Notifica CRA a ENISA/CSIRT tramite la SRP

L'interazione tra i canali di segnalazione NIS 2 e CRA Articolo 14 non è stata confermata nella guida definitiva. Qualsiasi affermazione che la SRP gestisca l'instradamento per entrambi i regimi va trattata come non confermata fino alla pubblicazione di una guida definitiva da parte di ENISA o della Commissione (si veda «Questioni ancora aperte» di seguito).

Checklist di preparazione alla segnalazione ENISA

CHECKLIST PREPARAZIONE SEGNALAZIONE ENISA

PRIMA DI SETTEMBRE 2026:

CANALI E CONTATTI
[ ] security.txt pubblicato e aggiornato
[ ] Modulo di segnalazione vulnerabilità disponibile
[ ] Email di sicurezza monitorata (definire SLA: ____ ore)
[ ] Contatto CSIRT nazionale identificato
[ ] Registrazione ENISA SRP (quando disponibile)

PROCESSO INTERNO
[ ] Criteri di triage documentati
[ ] Checklist di valutazione dello sfruttamento creata
[ ] Percorso di escalation definito (nomi, contatti)
[ ] Reporter autorizzati identificati
[ ] Copertura fuori orario stabilita

DOCUMENTAZIONE
[ ] Template avviso preliminare predisposto
[ ] Template notifica dettagliata predisposto
[ ] Template relazione finale predisposto
[ ] Materiali di briefing interno pronti

TEST
[ ] Esercitazione tabletop completata
[ ] Escalation fuori orario testata
[ ] Revisione template completata

QUANDO VIENE RILEVATO LO SFRUTTAMENTO:

IMMEDIATO (entro 4 ore)
[ ] Valutazione iniziale: questo è attivamente sfruttato?
[ ] Ora di avvio del conto documentata: ____________
[ ] Escalation al reporter autorizzato

ENTRO 24 ORE
[ ] Avviso preliminare inviato a ENISA SRP
[ ] Conferma di ricezione ottenuta
[ ] Referenti interni notificati

ENTRO 72 ORE
[ ] Notifica dettagliata inviata
[ ] Stato della mitigazione aggiornato
[ ] Comunicazione ai clienti avviata (se opportuno)

ENTRO 14 GIORNI dalla misura correttiva/di attenuazione (vulnerabilità) / 1 MESE (incidente)
[ ] Relazione finale inviata
[ ] Insegnamenti tratti documentati
[ ] Miglioramenti del processo identificati

Questioni ancora aperte

Alla data di redazione, diverse questioni che incidono sull'applicazione pratica della segnalazione ai sensi dell'Articolo 14 del CRA restano aperte:

Come CRA Evidence gestisce la segnalazione ai sensi dell'Articolo 14

CRA Evidence è costruita intorno alla cadenza di segnalazione dell'Articolo 14. I dati chiave richiesti per le notifiche tramite SRP sono già strutturati nella piattaforma nel momento in cui una vulnerabilità o un incidente viene identificato.

• Timestamp di consapevolezza CRA Articolo 14: ogni vulnerabilità è registrata rispetto a un prodotto con il timestamp di consapevolezza, il trigger che avvia il conto delle 24 ore ai sensi dell'Articolo 14. Il campo discovered_at genera i campi relativi alle scadenze ENISA, in modo che l'avvio del conto venga acquisito nel momento in cui la vulnerabilità entra nel sistema.
• Mappatura delle versioni prodotto collegate all'SBOM: i CVE in ingresso e le evidenze di sfruttamento vengono associati a versioni specifiche del prodotto tramite la pipeline di ingestione dell'SBOM, in modo che il campo «versioni interessate» nella segnalazione CRA Articolo 14 sia pre-popolato dai componenti già presenti nell'SBOM.
• Pre-popolamento dei campi del rapporto CRA: la documentazione tecnica (Allegato VII), i dettagli del fabbricante (ragione sociale, indirizzo, contatto), la classe di prodotto (Default / Classe I Importante e II / Critico) e il periodo di supporto sono già strutturati nel sistema, pronti a popolare i campi dell'avviso preliminare e della notifica a 72 ore della SRP.
• Traccia di audit CRA: ogni passaggio dal triage interno alla notifica esterna CRA è registrato con l'attore e il timestamp, che è esattamente quanto richiedono le verifiche di enforcement. Le transizioni di triage e le notifiche ENISA (avviso preliminare, notifica dettagliata, relazione finale) sono tutte coperte.
• Dati di instradamento CSIRT nel profilo del fabbricante: lo Stato membro del CSIRT e i dettagli del rappresentante autorizzato (nome, indirizzo, Stato membro) sono memorizzati nel profilo del fabbricante, in modo che gli input chiave per l'instradamento CRA Articolo 14 verso il CSIRT e per la rappresentanza dei fabbricanti non UE siano disponibili al momento della notifica.

Per sapere come la piattaforma gestisce le scadenze dell'Articolo 14: CRA Evidence ENISA Reporting.

Prossimi passi

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza legale. Per una consulenza specifica in materia di conformità, rivolgersi a un consulente legale qualificato esperto in regolamentazione dei prodotti dell'Unione europea.