CRA e NIS2: Dove le Normative di Cybersecurity si Sovrappongono per le Aziende di Prodotto

Produci dispositivi IoT per il settore energetico. Sei soggetto sia alla NIS2 (come operatore di servizi essenziali) che al CRA (come produttore di prodotti). Due normative, requisiti sovrapposti, un budget di conformità.

Questa guida spiega come CRA e NIS2 interagiscono e come gestire la conformità con entrambe.

CRA vs NIS2: Differenza Fondamentale

CRA: Regolamento sui Prodotti

Cosa regola: Prodotti con elementi digitali immessi sul mercato UE

A chi si applica: Fabbricanti, importatori, distributori di prodotti con elementi digitali

Focus: Sicurezza del prodotto durante tutto il ciclo di vita

• Design e sviluppo sicuri
• Gestione vulnerabilità per i prodotti
• Aggiornamenti di sicurezza per i prodotti
• Segnalazione incidenti a livello di prodotto

NIS2: Regolamento Organizzativo

Cosa regola: Cybersecurity di entità essenziali e importanti

A chi si applica: Organizzazioni in settori specificati che soddisfano soglie dimensionali

Focus: Cybersecurity organizzativa

• Governance e gestione del rischio
• Gestione incidenti per i servizi
• Sicurezza della supply chain
• Continuità operativa

La Zona di Sovrapposizione

AMBITO NIS2                           AMBITO CRA
+----------------------+          +----------------------+
| - Sistemi IT         |          | - Prodotti che       |
| - Servizi            |          |   producete          |
| - Operazioni         |          | - Prodotti che       |
| - Catena di          |          |   importate          |
|   fornitura          |          | - Prodotti che       |
|   (come acquirente)  |          |   distribuite        |
+----------+-----------+          +-----------+----------+
            \                                /
             \                              /
              +----------------------------+
              |      SOVRAPPOSIZIONE       |
              |                            |
              | - Gestione vuln.           |
              | - Segnalaz. incidenti      |
              | - Sicurezza catena fourn.  |
              | - Governance sicurezza     |
              +----------------------------+

Chi Affronta Entrambe le Normative?

Scenario 1: Entità Essenziale che Produce Prodotti

Esempio: Azienda energetica che produce componenti smart grid

• Si applica NIS2: Entità del settore energetico sopra soglia
• Si applica CRA: Fabbricante di prodotti con elementi digitali

Entrambe le normative richiedono:

• Gestione del rischio di cybersecurity
• Gestione vulnerabilità
• Segnalazione incidenti (a enti diversi, trigger diversi)
• Sicurezza supply chain

Scenario 2: Entità Importante che Produce IoT

Esempio: Azienda manifatturiera che produce sensori IoT industriali

• Si applica NIS2: Entità del settore manifatturiero sopra soglia
• Si applica CRA: Fabbricante di prodotti con elementi digitali

Scenario 3: Fornitore di Infrastrutture Digitali

Esempio: Provider cloud che vende anche appliance hardware

• Si applica NIS2: Fornitore di infrastrutture digitali
• Si applica CRA: Fabbricante di prodotti hardware

Scenario 4: Produttore di Prodotti Sanitari

Esempio: Azienda di dispositivi medici adiacenti (non dispositivi coperti da MDR)

• Si applica NIS2: Entità del settore sanitario
• Si applica CRA: Prodotti non coperti dall'esclusione MDR

Requisiti Sovrapposti

Gestione Vulnerabilità

Opportunità di coordinamento: Programma di gestione vulnerabilità unificato che copre sia prodotti che sistemi organizzativi.

Segnalazione Incidenti

Distinzione chiave: Una vulnerabilità nel tuo prodotto potrebbe innescare la segnalazione CRA anche se i tuoi servizi non sono colpiti. Un'interruzione di servizio potrebbe innescare la segnalazione NIS2 anche se non esiste vulnerabilità del prodotto.

Sicurezza Supply Chain

Opportunità di coordinamento: Gestione fornitori integrata che copre sia componenti prodotto che fornitori organizzativi.

Confronto Segnalazioni

Percorso di Segnalazione CRA

VULNERABILITÀ PRODOTTO (attivamente sfruttata)
         │
         ▼
    ALLERTA PRECOCE 24 ORE
    A: Piattaforma Singola di Segnalazione ENISA
         │
         ▼
    NOTIFICA DETTAGLIATA 72 ORE
    A: ENISA + CSIRT pertinenti
         │
         ▼
    REPORT FINALE 14 GIORNI (vulnerabilità)
    REPORT FINALE 30 GIORNI (incidente)

Percorso di Segnalazione NIS2

INCIDENTE SIGNIFICATIVO (che colpisce servizi)
         │
         ▼
    ALLERTA PRECOCE 24 ORE
    A: Autorità competente nazionale o CSIRT
         │
         ▼
    NOTIFICA INCIDENTE 72 ORE
    A: Autorità competente nazionale o CSIRT
         │
         ▼
    REPORT FINALE 1 MESE
    A: Autorità competente nazionale o CSIRT

Quando si Applicano Entrambe

Un singolo evento potrebbe innescare entrambe:

Esempio: Zero-day nel tuo prodotto è attivamente sfruttato, colpendo clienti che sono entità essenziali (come aziende energetiche che usano le tue apparecchiature smart grid).

Segnalazione CRA: Tu segnali la vulnerabilità attivamente sfruttata (sei il fabbricante)

Segnalazione NIS2: I tuoi clienti colpiti potrebbero segnalare l'incidente (sono le entità essenziali)

La tua segnalazione interna: Se sei anche un'entità essenziale che usa i propri prodotti, potresti dover segnalare secondo entrambe

Come gestire un programma di sicurezza unificato per CRA e NIS2

Governance di Sicurezza Unificata

Invece di programmi di conformità CRA e NIS2 separati:

GOVERNANCE CYBERSECURITY UNIFICATA

Livello Consiglio:
- Supervisione unica del rischio cybersecurity
- Reporting combinato al management

Livello Operativo:
- Un programma di gestione vulnerabilità
  ├── Vulnerabilità prodotto (focus CRA)
  └── Vulnerabilità sistemi (focus NIS2)

- Una capacità di risposta incidenti
  ├── Incidenti prodotto (segnalazione CRA)
  └── Incidenti servizio (segnalazione NIS2)

- Un programma di sicurezza supply chain
  ├── Componenti prodotto (SBOM, CRA)
  └── Fornitori servizi (NIS2)

Mappatura dei Processi

Efficienza Documentale

Alcune documentazioni possono servire entrambe:

Differenze nell'applicazione di CRA e NIS2

Enforcement CRA

• Autorità di vigilanza del mercato monitorano i prodotti
• Focus sulla conformità del prodotto
• Sanzioni fino a €15M o 2,5% del fatturato globale
• Ritiro/richiamo del prodotto possibile

Enforcement NIS2

• Autorità competenti nazionali supervisionano le entità
• Focus sulla conformità organizzativa
• Sanzioni fino a €10M o 2% del fatturato globale
• Responsabilità personale del management possibile

Doppia Sanzione?

Un singolo fallimento potrebbe teoricamente innescare enforcement sotto entrambe:

Esempio: Scarsa gestione vulnerabilità porta a prodotto non patchato E sistemi interni non patchati.

• CRA: Non conformità con requisiti gestione vulnerabilità
• NIS2: Non conformità con misure di gestione del rischio

In pratica: I regolatori dovrebbero coordinarsi. Dimostrare conformità unificata aiuta.

Interazione delle Timeline di Conformità

Timeline NIS2

• Ottobre 2024: Scadenza recepimento NIS2
• 2024-2025: Implementazione Stati membri
• In corso: Conformità richiesta

Timeline CRA

• Settembre 2026: Iniziano obblighi di segnalazione
• Dicembre 2027: Conformità completa richiesta
• In corso: Obblighi ciclo di vita prodotto

Approccio Coordinato

2024                    2025                    2026                    2027
│                       │                       │                       │
▼                       ▼                       ▼                       ▼
┌───────────────────────────────────────────────────────────────────────┐
│ NIS2: Conformità organizzativa richiesta per tutto il periodo        │
└───────────────────────────────────────────────────────────────────────┘
                                                │                       │
                                                ▼                       ▼
                                        ┌───────────────────────────────┐
                                        │ CRA: Segnalaz. │ CRA: Piena  │
                                        └───────────────────────────────┘

RACCOMANDAZIONE:
Costruire ora un programma di cybersecurity unificato che serva entrambe.
Non costruire programmi di conformità CRA e NIS2 separati.

Checklist di Coordinamento Pratico

Integrazione della Governance

CHECKLIST GOVERNANCE DOPPIA NORMATIVA

ORGANIZZATIVA:
[ ] Struttura di governance cybersecurity unica
[ ] Supervisione a livello consiglio copre sicurezza prodotto e servizio
[ ] Strategia cybersecurity combinata
[ ] Allocazione budget unificata

GESTIONE RISCHIO:
[ ] Valutazione rischio integrata (prodotti + servizi)
[ ] Registro rischi combinato
[ ] Processo trattamento rischio unificato
[ ] Framework di reporting rischio unico

GESTIONE VULNERABILITÀ:
[ ] Un canale di ricezione vulnerabilità
[ ] Processo di triage combinato
[ ] Workflow di remediation integrato
[ ] Metriche e reporting unificati

RISPOSTA INCIDENTI:
[ ] Piano risposta incidenti combinato
[ ] Routing chiaro per segnalazione CRA vs NIS2
[ ] Procedure di comunicazione integrate
[ ] Review post-incidente unificata

Integrazione Segnalazioni

MATRICE SEGNALAZIONE DOPPIA NORMATIVA

Tipo Evento                           Segnalare Sotto
─────────────────────────────────────────────────────────────
Vuln. prodotto (non sfruttata)       Nessuna (solo processo CVD)
Vuln. prodotto (sfruttata)           CRA → ENISA
Incidente servizio (no prodotto)     NIS2 → Autorità nazionale
Entrambi (vuln. prodotto → servizio) Entrambi (coordinare)
─────────────────────────────────────────────────────────────

Escalation Interna:
1. Team sicurezza valuta evento
2. Determinare: Impatto prodotto? Impatto servizio?
3. Instradare verso percorso/i di segnalazione appropriato/i
4. Coordinare se si applicano entrambi

Integrazione Supply Chain

SICUREZZA SUPPLY CHAIN UNIFICATA

Per Componenti Prodotto (focus CRA):
- SBOM mantenuto
- Monitoraggio vulnerabilità componenti
- Questionario sicurezza fornitore
- Due diligence tecnica

Per Fornitori Servizi (focus NIS2):
- Valutazione rischio fornitore
- Requisiti sicurezza nei contratti
- Monitoraggio continuo
- Clausole notifica incidenti

APPROCCIO INTEGRATO:
- Sistema di gestione fornitori unico
- Framework valutazione rischio combinato
- Requisiti sicurezza contrattuali unificati
- Programma di monitoraggio coordinato

Casi limite a doppio ambito che richiedono delimitazione precisa

Sistemi di Controllo Industriale

IACS (Industrial Automation and Control Systems) affrontano particolare complessità:

• CRA: Se fabbrichi IACS per entità essenziali (NIS2), è Important Class II
• NIS2: Se operi IACS come entità essenziale, sono in ambito

Doppio requisito: Il prodotto deve rispettare CRA; l'operatività deve rispettare NIS2.

Servizi Cloud + Prodotti

Provider cloud che vendono appliance hardware:

• NIS2: Operazioni servizio cloud
• CRA: Appliance hardware vendute

Esempio: L'appliance firewall di un provider cloud deve essere conforme al CRA; le sue operazioni di servizio cloud devono essere conformi alla NIS2.

Adiacente al Sanitario

I produttori di dispositivi medici potrebbero avere:

• Alcuni prodotti sotto MDR (esclusi dal CRA)
• Alcuni prodotti sotto CRA (non coperti da MDR)
• Organizzazione sotto NIS2 (entità settore sanitario)

Scoping attento richiesto: Mappare ogni prodotto alla normativa applicabile.

FAQ su CRA e NIS2 per i produttori

Quando un singolo evento attiva sia la segnalazione CRA che NIS2?

Quando una vulnerabilità attivamente sfruttata nel tuo prodotto causa anche un incidente significativo che colpisce i tuoi servizi. La segnalazione CRA è attivata dalla vulnerabilità del prodotto sfruttata: presenti un'allerta precoce di 24 ore a ENISA, poi una notifica di 72 ore. La segnalazione NIS2 è attivata separatamente se i tuoi servizi vengono interrotti: presenti alla tua autorità competente nazionale o CSIRT con lo stesso schema 24/72 ore. Le due segnalazioni riguardano soggetti diversi. Il CRA si concentra sul prodotto e sulla vulnerabilità. La NIS2 si concentra sull'impatto sul servizio e sulla tua risposta. Entrambe possono essere richieste per lo stesso evento originario.

Chi presenta la segnalazione se il produttore è anche un'entità essenziale?

Presenti entrambe, e le presenti separatamente. Come produttore del prodotto, segnali la vulnerabilità sfruttata a ENISA ai sensi del CRA. Come entità essenziale, segnali l'incidente al servizio alla tua autorità competente nazionale o CSIRT ai sensi della NIS2. Le due segnalazioni sono indipendenti: moduli diversi, destinatari diversi, scadenze in alcuni casi diverse. Assegna un responsabile nominato per ciascun percorso di segnalazione prima che si verifichi un incidente. Non presumere che una segnalazione soddisfi l'altra.

Un unico registro dei rischi può servire sia per CRA che per NIS2?

Sì, se separa i rischi di prodotto dai rischi organizzativi. Struttura il registro in modo che i rischi a livello di prodotto (vulnerabilità dei componenti, errori di aggiornamento, lacune di conformità) siano chiaramente distinti dai rischi organizzativi (continuità del servizio, carenze di governance, interruzioni della supply chain). Entrambi gli insiemi di rischi possono essere nello stesso documento e condividere una metodologia di punteggio comune. Ciò che non può essere unificato è il trattamento: il trattamento del rischio CRA porta a controlli di prodotto e aggiornamenti del fascicolo tecnico; il trattamento del rischio NIS2 porta a misure organizzative e modifiche alle policy. Mantieni le voci distinte in modo che ciascun audit possa trovare ciò di cui ha bisogno.

Come deve differire la due diligence sui fornitori tra componenti e fornitori di servizi?

Per i componenti di prodotto ai sensi del CRA, la due diligence è tecnica: hai bisogno di un SBOM che copra il componente, prove del monitoraggio delle vulnerabilità da parte del fornitore e un obbligo contrattuale di notificarti le vulnerabilità sfruttabili entro una finestra definita. Per i fornitori di servizi ai sensi della NIS2, la due diligence è organizzativa: valuti la loro governance della sicurezza, la capacità di risposta agli incidenti, la continuità aziendale e se soddisfano le misure di sicurezza NIS2 applicabili al tuo settore. Entrambi i tipi possono condividere un modello di questionario comune, ma i criteri di valutazione e le clausole contrattuali sono diversi.

Quali prove conservare per dimostrare la conformità coordinata a entrambi i regimi?

Conserva tre elementi. Primo, un documento di mappatura che mostri quali processi interni servono quale obbligo normativo, in modo che un revisore possa risalire da qualsiasi requisito CRA o NIS2 a un controllo specifico. Secondo, registri degli incidenti che dimostrino che entrambi i percorsi di segnalazione sono stati attivati correttamente quando gli eventi lo richiedevano, con timestamp e conferme dei destinatari. Terzo, report al consiglio o al management che coprano sia la sicurezza del prodotto che la sicurezza organizzativa in un'unica struttura di governance, dimostrando che la supervisione è unificata. Se sei sottoposto ad audit sia per CRA che per NIS2 nello stesso anno, queste prove sono ciò che dimostra che gestisci un unico programma, non due disconnessi.

Come influenzano le differenze di recepimento nazionale di NIS2 un produttore che opera in più paesi?

La NIS2 è una direttiva, non un regolamento, il che significa che ogni Stato membro dell'UE la recepisce nel proprio diritto nazionale. Gli obblighi fondamentali (gestione del rischio, segnalazione degli incidenti, sicurezza della supply chain) sono coerenti, ma l'autorità competente, le soglie settoriali e talvolta la struttura sanzionatoria variano da paese a paese. Un produttore che opera in Germania, Francia e Polonia deve identificare quale autorità nazionale supervisiona ciascuna entità, registrarsi presso l'organismo corretto in ciascuna giurisdizione e instradare le segnalazioni di incidenti NIS2 al CSIRT nazionale competente. Il CRA, al contrario, è un regolamento e si applica uniformemente in tutta l'UE. Se vendi un prodotto in qualsiasi paese dell'UE, si applicano gli stessi obblighi CRA.

Prossimi passi

Inizia confermando se la tua azienda è sia un produttore che un'entità essenziale o importante ai sensi della NIS2. Usa la guida alla classificazione dei prodotti per mappare ciascun prodotto alla sua classe CRA. Quindi mappa separatamente i rischi di prodotto e i rischi di servizio in un unico registro che li mantiene distinti. Definisci i trigger interni di segnalazione per CRA rispetto a NIS2 e assegna un responsabile nominato per ciascun percorso. Unifica i flussi di lavoro di gestione dei fornitori e delle vulnerabilità in modo che entrambi i tipi di fornitori transitino attraverso un unico processo. Per una panoramica completa delle scadenze CRA, consulta la timeline di implementazione del CRA. Poi esegui un esercizio tabletop congiunto che simuli un incidente di prodotto che colpisce anche i tuoi servizi: questo rivelerà le lacune nella tua risposta a doppio ambito prima che un evento reale le metta alla prova.

Questo articolo è solo a scopo informativo e non costituisce consulenza legale. Per indicazioni specifiche sulla conformità, consultare un consulente legale qualificato.