Cybersecurity aziendale: cosa significa essere soggetto Importante NIS2 per un produttore di apparecchiature elettriche

Il brief precedente ha guardato la cybersecurity dal lato del prodotto: requisiti del Cyber Resilience Act, certificazione RED 2014/53, IEC 62443 come anticipazione del quadro tecnico. Quel discorso, per quanto operativo, copre solo metà del problema.

L’altra metà sta nell’organizzazione che il prodotto lo costruisce, lo manda in produzione, lo aggiorna nei dieci anni di vita commerciale. Un capitolato che chiede «firmware sicuro, secure boot, SBOM» pretende implicitamente che dietro quel firmware ci sia un’azienda strutturata per restare un fornitore di fiducia per tutto il ciclo di vita del prodotto. Per questo, dal 2024, il quadro regolatorio europeo non si limita a chiedere requisiti tecnici al prodotto: ha esteso obblighi sostanziali sull’organizzazione del produttore, e individua per nome chi rientra nel perimetro.

Per Herholdt Controls, questo perimetro è una condizione formale.

Soggetto Importante NIS2: cosa è cambiato dal 12 aprile 2025

La Direttiva NIS2 (Direttiva UE 2022/2555) è stata recepita in Italia con il D.Lgs. 138/2024, in vigore dal 16 ottobre 2024. La norma identifica due categorie di soggetti che devono rispettare obblighi specifici di sicurezza informatica: i soggetti Essenziali, tipicamente operatori di infrastrutture critiche (energia, trasporti, sanità, finanza), e i soggetti Importanti, che operano in settori strategici la cui interruzione produrrebbe impatti significativi sull’economia o sulla società

L’Autorità Nazionale Competente NIS, l’Agenzia per la Cybersicurezza Nazionale (ACN), ha condotto fra ottobre 2024 e aprile 2025 il processo di registrazione e classificazione dei soggetti. Le organizzazioni hanno presentato una dichiarazione preliminare, ACN ha valutato in base ai criteri del decreto (settore di attività, dimensione, ruolo nella supply chain di soggetti Essenziali), e ha emesso una determinazione formale di inclusione nell’elenco nazionale.

Con la Determinazione del Direttore Generale ACN del 12 aprile 2025, Herholdt Controls è stata individuata quale soggetto Importante in relazione alla fabbricazione di apparecchiature elettriche strategiche (codice NACE C/27, sezione manifatturiera). La determinazione comporta un perimetro di obblighi sostanziali: misure tecniche, operative e organizzative di gestione del rischio cyber; notifica di incidenti significativi al CSIRT Italia (preallarme entro 24 ore, notifica completa entro 72 ore, relazione finale entro un mese); obbligo di gestione del rischio della propria supply chain; sanzioni amministrative fino a 7 milioni di euro o 1,4% del fatturato annuo globale in caso di non conformità.

Per un fornitore di apparecchiature elettriche destinate a infrastrutture critiche, l’inclusione nell’elenco NIS2 non è una conseguenza burocratica. È la formalizzazione pubblica di un’esposizione al rischio che il decreto considera, di fatto, sistemica.

Cosa cambia per chi acquista da un soggetto NIS2

L’effetto più rilevante, per il mercato, non riguarda direttamente il soggetto registrato. Riguarda i suoi clienti.

NIS2 impone ai soggetti regolati l’obbligo formale di gestire il rischio della propria supply chain. In termini pratici, questo significa che ogni operatore di rete elettrica, ogni gestore di data center, ogni operatore EVSE classificato come Essenziale o Importante deve oggi documentare la postura informatica dei propri fornitori critici, valutare i rischi associati, e, laddove la valutazione lo richieda, qualificare formalmente solo fornitori che soddisfano una baseline di sicurezza dimostrabile.

Un fornitore che oggi non è in grado di rispondere con documenti formali a una domanda come «qual è il vostro perimetro NIS2, e quali misure tecniche e organizzative avete adottato in conseguenza» si trova sistematicamente escluso dalle procurement queue dei clienti regolati. Non per scelta commerciale del cliente, ma per obbligo normativo del cliente stesso.

Per questo, la classificazione ACN di Herholdt Controls come soggetto Importante non è soltanto un fatto interno: è una scheda di qualificazione che i clienti regolati possono allegare ai propri file di rischio supply chain, e che rende il dialogo di onboarding misurabile e documentale, non più discrezionale.

NIST Cybersecurity Framework: la scelta architetturale

Le misure di sicurezza adottate da Herholdt Controls in conseguenza della classificazione NIS2 sono state strutturate sul NIST Cybersecurity Framework 2.0, pubblicato dal National Institute of Standards and Technology degli Stati Uniti nel febbraio 2024.

Il framework NIST non è obbligatorio in Europa e non sostituisce gli adempimenti formali richiesti dal D.Lgs. 138/2024. È però il riferimento internazionale più adottato globalmente per la strutturazione operativa di un programma di cybersecurity aziendale, ed è esplicitamente riconosciuto da ACN fra gli standard accettabili per l’autovalutazione delle misure di gestione del rischio.

La scelta del NIST CSF come framework architetturale risponde a tre criteri di metodo. Il primo è la copertura: le sei funzioni del framework (Govern, Identify, Protect, Detect, Respond, Recover) coprono l’intero ciclo della gestione del rischio cyber, dalla governance alla risposta agli incidenti, senza lacune che richiedano integrazioni con framework separati. Il secondo è la maturità: NIST CSF è in evoluzione continua dal 2014, e la versione 2.0 incorpora dodici anni di lessons learned di organizzazioni di ogni dimensione e settore. Il terzo è la traducibilità: ogni funzione del CSF mappa con precisione ai controlli specifici di standard adiacenti (ISO/IEC 27001, IEC 62443, SOC 2) rendendo il framework un’infrastruttura su cui costruire eventuali certificazioni formali successive senza riprogettare il programma di sicurezza.

Le sei funzioni del CSF, applicate al contesto operativo di un produttore di apparecchiature elettriche, si traducono in domini operativi distinti.

• Govern: definizione delle responsabilità di sicurezza a livello di direzione, politiche aziendali, allocazione di budget.
• Identify: inventario degli asset (hardware, software, dati, processi), analisi delle dipendenze, valutazione del contesto di business.
• Protect: controlli di accesso, gestione delle credenziali, formazione del personale, protezione dei dati, segmentazione della rete.
• Detect: monitoraggio continuo degli eventi e individuazione di anomalie.
• Respond: contenimento di un incidente, comunicazione interna ed esterna, coordinamento con le autorità.
• Recover: ripristino delle funzioni, lessons learned, miglioramento continuo.

Ognuno di questi sei domini non è una buona pratica interna a Herholdt Controls. È un’area di evidenza documentabile davanti a un’autorità di vigilanza.

SOC e SIEM: il livello operativo della detection

Le funzioni Detect e Respond del framework NIST non si soddisfano con policy scritte. Richiedono strumenti operativi che osservino la rete e i sistemi 24 ore al giorno, sette giorni alla settimana, e che riducano il tempo intercorso fra l’inizio di un incidente e la sua identificazione a una finestra compatibile con i requisiti di notifica.

Herholdt Controls ha implementato due strumenti complementari per questa funzione: un SIEM (Security Information and Event Management) e un SOC (Security Operations Center).

Il SIEM è la piattaforma tecnica che raccoglie, normalizza e correla in tempo reale i log generati da ogni sistema dell’infrastruttura aziendale: firewall, server di posta, controller di dominio, endpoint, applicazioni di business, sistemi di automazione di produzione. La normalizzazione consente di trattare in modo uniforme eventi provenienti da fonti eterogenee; la correlazione consente di identificare pattern che, presi singolarmente, sarebbero invisibili. Un singolo tentativo fallito di autenticazione su un account amministrativo è rumore di fondo. Cinquemila tentativi falliti da indirizzi IP geograficamente dispersi nell’arco di sessanta minuti, correlati con un accesso riuscito allo stesso account, sono un attacco di credential stuffing in corso.

Il SOC è il team, interno o in outsourcing qualificato, che lavora sui dati che il SIEM produce. Riceve gli alert generati dalle regole di correlazione, li valuta secondo criteri di priorità prefissati, distingue i falsi positivi dagli incidenti effettivi, attiva il processo di risposta quando un incidente è confermato. Un SIEM senza un SOC è uno strumento senza interpretazione: produce alert che nessuno legge. Un SOC senza un SIEM è un team senza visibilità: deve farsi un’idea di cosa stia succedendo basandosi su segnalazioni ad hoc.

La presenza di entrambi, opportunamente integrati e con regole di correlazione calibrate sul contesto operativo specifico (manifattura elettronica, sviluppo firmware embedded, supply chain di componenti) è la baseline operativa che NIS2 si attende da un soggetto Importante.

Incident Response Plan, Playbook, BIA, Disaster Recovery

La rilevazione di un incidente non è la fine del processo. È l’inizio.

Un incidente di sicurezza informatica, in un’azienda manifatturiera, può presentarsi in molte forme: una compromissione di un account interno, un ransomware su una share di rete di sviluppo, un’esfiltrazione di documentazione tecnica, una manomissione di un binario firmware nella catena di build, un attacco di denial-of-service su un servizio esposto. Ognuna di queste forme richiede una risposta diversa, con tempi, attori e procedure diverse. Improvvisare la risposta nel momento dell’incidente è il modo più rapido per trasformare un incidente contenibile in una crisi sistemica.

Per questo, Herholdt Controls ha formalizzato quattro documenti operativi che insieme costituiscono il piano di risposta:

1. L’Incident Response Plan (IRP) è il documento di vertice. Definisce ruoli e responsabilità durante un incidente, criteri di classificazione di severità, regole di escalation interna, canali di comunicazione con le autorità (CSIRT Italia, ENISA, clienti regolati) e con i media, tempistiche di notifica obbligatorie sotto NIS2. Non descrive come si gestiscano singoli scenari: definisce la cornice procedurale comune.
2. Il Playbook Operativo opera il livello sotto. Per ciascuno scenario plausibile (ransomware, compromissione di un account privilegiato, esfiltrazione di dati, manomissione firmware, intrusione fisica nei sistemi di sviluppo) descrive passo per passo le azioni operative: chi viene contattato per primo, quali sistemi vanno isolati immediatamente, quali evidenze forensi vanno preservate, quale comunicazione esterna è autorizzata. Il Playbook è il documento che il team operativo apre alle tre di notte quando il SIEM ha generato l’alert; è quello che trasforma una procedura scritta in azioni eseguibili sotto pressione.
3. La Business Impact Analysis (BIA) affronta una domanda diversa: nel caso in cui un sistema cada o un servizio sia compromesso, qual è l’impatto sull’attività di business, e in che ordine i sistemi vanno ripristinati? La BIA classifica ogni processo aziendale per criticità e definisce per ognuno un RTO (Recovery Time Objective: quanto tempo possiamo permetterci che il sistema resti down) e un RPO (Recovery Point Objective: quanti dati possiamo permetterci di perdere). I sistemi di configurazione di firmware metrologici hanno un RTO molto più stretto di un sistema di gestione documentale interno; i sistemi di firma del firmware hanno un RPO sostanzialmente zero. La BIA traduce queste differenze in una sequenza operativa di ripristino.
4. Il piano di Disaster Recovery (DR) è il documento tecnico che, per ogni sistema critico identificato nella BIA, descrive l’infrastruttura, le procedure e le risorse necessarie per ripristinarlo entro i parametri stabiliti. Backup automatici, test periodici di restore, infrastruttura ridondata, replica geografica dei dati critici, ambienti di emergenza pre-configurati. Un piano di DR scritto e mai testato non è un piano: è un’intenzione. La validazione periodica dei tempi effettivi di ripristino è parte integrante del documento.

I quattro documenti insieme costituiscono la chiusura del ciclo del framework NIST: Rilevazione → Risposta → Ripristino → Miglioramento. Senza chiusura, una rilevazione precoce di un incidente è un’informazione che non si trasforma in azione.

Cosa significa per un OEM cliente

Per un OEM che oggi sta scrivendo un capitolato per un fornitore di apparecchiature elettriche destinate a un’infrastruttura connessa, le domande relative alla postura informatica aziendale del fornitore sono diventate strutturali quanto quelle sul prodotto.

• Il fornitore è classificato come soggetto NIS2 (Essenziale o Importante) dall’autorità competente nazionale? In quale tipologia, e da quando?
• Quale framework di gestione della sicurezza dell’informazione è adottato (NIST CSF, ISO/IEC 27001, framework settoriale)?
• Esiste un SOC operativo 24/7 (interno o in outsourcing qualificato) integrato con un SIEM? Quali sono le metriche di Mean Time To Detect e Mean Time To Respond dichiarate?
• L’Incident Response Plan e il Playbook Operativo sono documenti formali, periodicamente aggiornati e testati con esercitazioni? Quali scenari coprono?
• Esiste una Business Impact Analysis aggiornata che identifichi i processi critici con i loro RTO/RPO? Il piano di Disaster Recovery è testato con quale frequenza?
• Il fornitore notifica formalmente ai propri clienti gli incidenti di sicurezza significativi che possono avere impatto sulla loro infrastruttura, entro quali tempistiche, e con quale livello di dettaglio?

Un fornitore che risponde a queste domande con riferimenti formali documentabili (codice identificativo NIS2, mappa delle misure NIST, evidenze di esercitazioni, report di test DR) ha integrato la cybersecurity organizzativa nei propri processi. Un fornitore che risponde con generici impegni di principio sta dichiarando un livello di maturità che dovrà costruire dopo la firma del contratto, in un mercato dove i clienti regolati non possono più permettersi di prendere quel rischio.

Per i clienti che oggi valutano Herholdt Controls come fornitore di apparecchiature elettriche destinate a infrastrutture connesse, il punto di partenza della due diligence non è una dichiarazione di intenti. È un atto amministrativo italiano, datato 12 aprile 2025, che lo stabilisce per nome.