Trasformazione organizzativa nell'ambito di NIS2: piano di gestione del cambiamento per integrare sicurezza e governance

La trasformazione organizzativa sotto NIS2 determina in molte imprese meno in base a singoli controlli tecnici che dalla questione se sicurezza e governance siano integrate in modo duraturo nell’organizzazione di linea, nelle operazioni e nei percorsi decisionali. NIS2 unisce obblighi di gestione, pressione di rendicontazione e requisiti di segnalazione. Chi lo considera «progetto di sicurezza dell’IT» finisce tipicamente in due tranelli: le misure vengono avviate ma non gestite; e nell’audit manca una giustificazione coerente del perché le decisioni fossero adeguate.

Questo contributo fornisce un piano di change management tarato su direzione IT, Compliance, responsabili della sicurezza e direzione aziendale. Il focus non sono le discussioni sui framework, ma meccaniche organizzative attuabili: ruoli, organi collegiali, escalation, effetti operativi, Evidence (prove verificabili), logica dei costi e prioritizzazione. L’obiettivo è un modello che RESTi sostenibile nella pratica – anche quando il personale è scarso, i sistemi sono eterogenei e i fornitori non si allineano immediatamente.

Perché NIS2 impone un cambiamento organizzativo (e non solo nuova tecnologia)

NIS2 affronta «misure» e «responsabilità» contemporaneamente. Sul piano tecnico riguarda gestione del rischio, gestione degli incidenti, continuità operativa, catene di fornitura, controllo degli accessi, gestione delle vulnerabilità e altro. Sul piano organizzativo si tratta di rendere questi temi decisionali e dimostrabili: chi stabilisce le priorità? Chi accetta i rischi residui? Chi può decidere in modo vincolante durante un incidente? E chi può dimostrare a posteriori che non è stato un caso ma un sistema?

In pratica questo significa: la sicurezza diventa parte della governance. Per «governance» si intende qui l’insieme di regole, responsabilità, percorsi decisionali e meccanismi di controllo con cui vengono governati IT e organizzazione. Senza governance la sicurezza RESTa reattiva; con la governance diventa pianificabile e verificabile. Il cambiamento organizzativo consiste nel separare questo governo dalla modalità progetto e dalla conoscenza individuale e nel trasferirlo in processi ripetibili.

Punti critici tipici nelle aziende: dove falliscono i progetti NIS2

Prima di definire un piano conviene fare un inventario dei punti critici abituali. Spesso negli audit non si tratta tanto di «strumenti mancanti» quanto dell’assenza di impegno vincolante.

1) Responsabilità poco chiare tra IT, Security, Compliance e aree operative

Quando nessuno prende la decisione finale, nascono processi paralleli: le aree operative incaricano soluzioni vicine all’IT senza valutazione del rischio o della protezione dei dati; la Security richiede controlli che l’operatività non è in grado di implementare; la Compliance redige policy che non vengono operationalizzate. NIS2 non richiede un organigramma perfetto, ma responsabilità chiare.

2) Misure senza gestione operativa: «introdotto» non è «efficace»

Un scanner di vulnerabilità si acquista rapidamente. Diventa efficace solo quando sono definiti proprietari per ogni sistema, esistono finestre di patching, le eccezioni sono documentate e c’è un meccanismo di escalation in caso di violazione degli SLA. Questa differenza è centrale per la prontezza per l’audit.

3) Le evidence vengono generate troppo tardi o per niente

Per ‚evidence‘ si intendono prove verificabili: log, autorizzazioni, ticket, report, decisioni, accettazioni del rischio. Se le evidence vengono create solo «per l’audit», scatta la fretta e l’incoerenza. Meglio: generare le evidence come sottoprodotto dell’operatività.

4) La gestione degli incidenti è tecnica, ma non decisoria

Molte organizzazioni possono isolare sistemi e conservare i log, ma non riescono a decidere abbastanza rapidamente chi, quando segnala, cosa si considera un “incidente rilevante” e come viene gestita la comunicazione. Gli obblighi di notifica NIS2 funzionano solo con ruoli chiari, logica temporale e percorsi di approvazione definiti.

Change-Management-Zielbild: Sicherheit als Managementsystem im Alltag

Un quadro operativo praticabile per la trasformazione organizzativa sotto NIS2 è un sistema di gestione che integri decisioni sul rischio, controlli e evidenze. «Sistema di gestione» non implica necessariamente un pesante programma ISMS, ma: rituali ricorrenti, artefatti definiti, responsabilità chiare e un minimo di punti di misurazione.

Il quadro può essere strutturato su tre livelli:

• Livello strategico: appetito per il rischio, priorità di budget, accettazione dei rischi residui, linea di rendicontazione verso il management.
• Livello tattico: policy e standard, programma di misure, gestione dei fornitori, pianificazione degli audit, KPI/KRI (indicatori/indicatori di rischio).
• Livello operativo: processo di patch e gestione delle vulnerabilità, identità e accessi, logging, test di backup/RESTore, runbook per incidenti, change-control.

Importante: questi livelli devono essere collegati tra loro. Un team operativo può fornire risultati solo se priorità e eccezioni sono decise. Viceversa, il management ha bisogno di informazioni solide dal funzionamento operativo, non soltanto di semafori di stato.

Change-Management-Plan in 6 Phasen (mit klaren Ergebnissen)

Il piano che segue è formulato in modo da funzionare in organizzazioni IT di medie e grandi dimensioni con paesaggi eterogenei. Ogni fase termina con artefatti concreti che potranno in seguito servire come evidence.

Phase 1: Scope, Betroffenheit, Kritikalität – die Landkarte bauen

Il punto di partenza non è il set di controlli, ma lo scope: quali aree di business, servizi, sedi, sistemi e fornitori sono rilevanti? Ciò include una logica di criticità (es. impatti su disponibilità, integrità, riservatezza e continuità operativa). È essenziale che questa logica sia documentata e confermata dal management.

Risultati di questa fase:

• Inventario dei servizi/sistemi con i responsabili (Responsabile del servizio / Responsabile del sistema).
• Classificazione di criticità e dipendenze (inclusi i fornitori).
• Definizione delle evidenze e dei report da generare regolarmente.

Inciampo tipico: l’inventario esiste, ma senza responsabilità assegnata. Senza una responsabilità assegnata non è possibile «mantenere» un rischio né attuare in modo vincolante una misura.

Phase 2: Governance-Setup – Rollen, Gremien, Eskalationswege

In questa fase viene definito il modello di governance. Questo include ruoli (comprese le deleghe), un comitato per sicurezza e rischio e una catena di escalation chiara. Un approccio pragmatico è un Security & Risk Board come organo di governo mensile con escalation ad hoc in caso di incidenti.

Set minimo di ruoli che dovRESTe nominare concretamente:

• Executive Sponsor: responsabilità di management, prioritizza le risorse, approva le accettazioni del rischio oltre soglie prefissate.
• CISO / Security-Verantwortliche Rolle: coordina il programma di sicurezza, è responsabile delle policy e della situazione attuale (non necessariamente come posizione full-time, ma come funzione definita).
• IT-Betrieb: implementa i controlli tecnici, è responsabile della disponibilità, delle finestre di patch, del monitoraggio.
• Compliance/Legal: valuta obblighi di notifica, requisiti di documentazione, clausole contrattuali, conservazione dei dati.
• Incident Manager: conduce la gestione dei casi secondo processo (triage, comunicazione, timeline, preservazione delle prove).
• Service Owner: sostiene il rischio e le conseguenze di budget per un servizio, decide sulle eccezioni entro limiti definiti.

Risultati attesi di questa fase:

• Matrice RACI (Responsible, Accountable, Consulted, Informed) per i processi core.
• Regole di escalation e decisionali (incluse soglie).
• Calendario di governance: board mensile, review di management trimestrale, valutazione del livello di maturità annuale.

Fase 3: Processi operazionalizzare – affinché le policy arrivino in esercizio

Questa fase è il nucleo del cambiamento organizzativo. Le policy sono utili solo se tradotte in processi che i team possano effettivamente eseguire. Operazionalizzare significa: ingressi, uscite, responsabili, logica temporale, integrazione con strumenti, documentazione.

Processi core tipici, vicini a NIS2, che si possono integrare nella quotidianità (senza reinventare tutto):

• Vulnerability- & Patch-Management: individuazione, prioritizzazione, applicazione delle patch, eccezioni, reporting. Un’“eccezione” necessita di data di scadenza e di una misura compensativa.
• Identity & Access Management (IAM): Joiner/Mover/Leaver, account privilegiati, MFA, ricertificazioni periodiche. “Ricertificazione” significa: i permessi vengono attivamente confermati o rimossi, non semplicemente esportati.
• Logging & Monitoring: logging centrale, retention, allerting, integrità dei log. È importante distinguere tra “dati di log disponibili” e “leggibili e protetti contro la manipolazione”.
• Backup/RESTore & Notfalltests: dimostrare la capacità di ripristino (test di RESTore), definire RTO/RPO (tempo di ripristino/punto di ripristino) per ciascun servizio.
• Change-Control: cambiamenti con valutazione del rischio, piano di rollback, autorizzazione. In particolare le modifiche di sicurezza devono essere testate in ambiente operativo.
• Lieferanten- und Drittparteienmanagement: requisiti minimi, allegati di sicurezza, canali di notifica per incidenti, evidenze (es. report, questionari, diritti di audit in base alla classe di rischio).

Risultati attesi di questa fase:

• Descrizioni di processo “light” (1–2 pagine), più runbook per flussi critici.
• Template per ticket/workflow che generano automaticamente evidenze (es. campi obbligatori, passaggi di approvazione).
• Punti di misura: pochi ma solidi KPI/KRI (es. conformità delle patch per criticità, tempo fino al triage, percentuale di RESTore riusciti).

Fase 4: Abilitazione e comunicazione – gestire il rischio del cambiamento

Il cambiamento fallisce spesso a causa di punti di attrito: lavoro aggiuntivo per l’esercizio, paura di «attribuzione della colpa», priorità poco chiare, frustrazione per gli strumenti. Il cambiamento legato a NIS2 richiede quindi un’abilitazione mirata: non una generica awareness, ma la capacità di agire specifica per ruolo.

Componenti consolidati:

• Abilitazione basata sui ruoli: p.es. sessione di 90 minuti per i Service Owner (decisioni sui rischi, eccezioni), 2–3 ore per il team di risposta agli incidenti (runbook, evidenze, matrice di comunicazione), workshop per gli acquisti (classificazione dei fornitori).
• Regole di comunicazione: i security findings come rischio operativo, non come fallimento personale. Questo riduce il «nascondere» e aumenta la propensione alla segnalazione.
• Backlog delle modifiche: raccolta degli ostacoli (p.es. finestre di patch mancanti), prioritizzati nel board, affinché l’operatività non rimanga sola.

Risultati di questa fase:

• Attestati di formazione e verbali di partecipazione (evidenze).
• FAQ e linee guida decisionali per ruolo (p.es. «Quando è consentita un’eccezione?»).
• Criteri di accettazione per i processi (cosa si considera «introdotto»?).

Fase 5: Prontezza per l’audit – motore di evidenze invece del cimitero di documenti

Prontezza per l’audit significa: poter dimostrare in qualsiasi momento in modo plausibile come si gestiscono i rischi, si trattano gli incidenti e si monitorano le misure. Ciò non si ottiene con una grande raccolta di documenti, ma con artefatti coerenti lungo la catena del valore.

Logica pragmatica delle evidenze:

• Decisioni: accettazioni del rischio, priorità, assegnazione del budget, eccezioni – con data, responsabile, motivazione, data di scadenza.
• Esecuzione: ticket, record delle modifiche, report di patch, recertificazioni, test di ripristino, valutazioni dei fornitori.
• Efficacia: indicatori di trend, backlog dei findings, lessons learned dopo gli incidenti, misure di miglioramento e loro chiusura.

È importante un deposito centrale delle evidenze con struttura chiara e controllo degli accessi. Il controllo degli accessi è doppiamente rilevante: i verificatori devono poter ottenere accesso, ma la manipolazione deve essere rilevabile. A seconda degli strumenti, può trattarsi di un DMS, di un sistema GRC o di un deposito strutturato con registrazione conforme alla revisione.

Risultati di questa fase:

• Matrice delle evidenze: controllo/requisito → prova → fonte → conservazione → responsabile.
• Modelli di pacchetto per l’audit: cosa è disponibile in caso di verifica entro 48 ore.
• Prova interna (tabletop o mini-audit) con elenco delle azioni.

Fase 6: Consolidamento – dal progetto alla linea

Il passaggio alla linea operativa è il vero successo del cambiamento organizzativo sotto NIS2. Ciò significa: il budget non è più gestito solo come budget di progetto, ma come budget operativo e di miglioramento; le attività fanno parte delle descrizioni di funzione; il board prende decisioni con regolarità; e il ciclo di miglioramento continua anche senza un responsabile del programma NIS2.

Risultati di questa fase:

• Piano annuale: pianificazione dei rischi e delle misure, verifiche dei fornitori, esercitazioni di emergenza, calendario degli audit.
• Modello di capacità: quote fisse nell’operatività per la gestione della sicurezza (applicazione delle patch, manutenzione dei log, revisioni degli accessi).
• Processo di lessons learned dopo incidenti ed esercitazioni, inclusa la tracciabilità fino alla chiusura.

Artefatti di governance da copiare: RACI, agenda del board, processo di eccezione

Le seguenti template sono volutamente compatte. Potete integrarle in un wiki interno, in uno strumento GRC o in un DMS e adattarle alla vostra organizzazione.

RACI-Matrix (struttura di esempio) per processi core correlati a NIS2

Ruoli (esempio):
- Sponsor esecutivo (Management)
- CISO / funzione di sicurezza
- Operazioni IT
- Responsabile del servizio
- Compliance/Legal
- Acquisti/Vendor Management
- Incident Manager

Processi / attività:
1) Analisi del rischio e trattamento del rischio
2) Accettazione del rischio oltre soglia
3) Vulnerability scanning e prioritizzazione
4) Implementazione delle patch e autorizzazione delle eccezioni
5) IAM: Joiner/Mover/Leaver
6) IAM: Accessi privilegiati e MFA
7) Logging e conservazione
8) Test di backup/RESTore e reporting
9) Incident Response: triage e contenimento
10) Incident Response: decisione di segnalazione e comunicazione
11) Classificazione dei fornitori e appendice di sicurezza
12) Evidence management e predisposizione per audit

RACI per processo:
- Responsible (R): esegue
- Accountable (A): è responsabile del risultato
- Consulted (C): viene coinvolto
- Informed (I): viene informato

Nota: ogni processo richiede esattamente una A.

Security & Risk Board: agenda che collega operatività e governance

Security & Risk Board (mensile, 60–90 minuti)

1) Situazione attuale (10 min)
- Rischi principali (trend)
- Rilevazioni critiche aperte
- Cambiamenti rilevanti nella catena di fornitura/progetti

2) Metriche operative (15 min)
- Conformità delle patch per criticità
- Eccezioni aperte (con data di scadenza)
- Risultati dei test di RESTore (tasso di successo, deviazioni)

3) Blocco decisionale (20–30 min)
- Accettazioni del rischio oltre la soglia
- Prioritizzazione del backlog delle misure (Top 5)
- Conflitti su risorse/budget

4) Incidenti e lezioni apprese (10–15 min)
- Breve cronologia, azioni intraprese, punti aperti

5) Prontezza per audit (5–10 min)
- Prossime evidenze/verifiche
- Lacune nelle evidenze e responsabili

Risultati:
- Delibere (con owner, data, scadenza)
- Lista rischi aggiornata
- Lista eccezioni/misure aggiornata

Processo di eccezione (Policy-Exception) – per evitare che le eccezioni diventino lo stato normale

Le eccezioni sono nella pratica inevitabili (sistemi legacy, RESTrizioni dei fornitori, finestre di produzione). Determinante è la governance che le circonda.

Policy-Exception / Control-Exception – Campi minimi

1) Servizio/Sistema interessato:
2) Control/Anforderung, da cui si deroga:
3) Motivazione (tecnica/aziendale):
4) Valutazione del rischio (impatto + probabilità di occorrenza, breve):
5) Misure di compensazione (es. segmentazione, monitoraggio, RESTrizione temporanea degli accessi):
6) Data di scadenza (obbligatorio) e piano di risoluzione:
7) Owner (Accountable) + sostituto:
8) Approvazione (soglia):
   - fino alla soglia: Service Owner
   - oltre la soglia: Exec Sponsor/Board
9) Link alle evidenze (ticket, change, report):

Regole:
- Ogni deroga ha una data di scadenza.
- Le estensioni devono essere giustificate nuovamente.
- Le deroghe vengono riviste mensilmente dal Board.

Conseguenze operative e costi: cosa „costa“ realisticamente il cambiamento organizzativo

L’implementazione di NIS2 viene spesso fraintesa come un investimento solo in strumenti. Nella pratica i costi si manifestano principalmente in tre categorie:

• Run-Kosten: lavoro ricorrente di esercizio (patch, review, manutenzione dei log, test di RESTore, verifiche sui fornitori).
• Change-Kosten: definizione iniziale dei processi, adattamenti degli strumenti, pulizia dei dati (es. inventario), formazione.
• Governance-Kosten: tempo del Board, reporting, audit interni/verifiche di prova.

Per i decisori è importante: questi costi non sono distribuiti uniformemente. All’inizio aumentano in modo significativo (inventario, ownership, prima classificazione, „pulizia“). Successivamente diminuiscono, quando i workflow sono stabili e le evidenze si generano automaticamente. Un buon piano di change limita la durata della „doppia pressione“ (progetto + esercizio), organizzando pRESTo il passaggio verso routine ripetibili.

Un altro punto è la questione dei costi opportunità: se le misure di sicurezza vengono „pagate“ in modo non pianificato con incidenti (downtime, forense, comunicazione ad hoc), di norma ciò risulta più costoso rispetto a un’operatività pianificabile. NIS2 non impone la perfezione, ma richiede un equilibrio giustificabile tra rischio e sforzo.

Prospettiva d’audit: quali domande dovrete essere in grado di rispondere

Indipendentemente da come sia concretamente configurata la vostra implementazione nazionale: la logica del valutatore segue per lo più gli stessi schemi. Vogliono vedere che conoscete i rischi, prendete decisioni, attuate misure e siete in grado di dimostrarlo.

Domande tipiche d’audit a cui il vostro Change-Management-Plan dovrebbe fornire risposte:

• Come definite la criticità e l’ambito – e chi le ha approvate?
• Come prioritizzate le misure – e come giustificate le deviazioni?
• Come garantite che le vulnerabilità vengano trattate (incl. deroghe)?
• Come vengono controllati e ricertificati gli accessi privilegiati?
• Come testate la capacità di ripristino – e quanto spesso?
• Come rilevate, classificate ed escalate gli incidenti?
• Come gestite i rischi dei fornitori – e quali evidenze avete a riguardo?

Se non vi limitate a „raccontare“ queste risposte, ma potete dimostrarle con artefatti (deliberazioni, ticket, report, verbali), sarete di gran lunga più vicini alla prontezza per l’audit.

Prioritizzazione: cosa implementare prima (quando le risorse sono scarse)

In molte aziende il collo di bottiglia non è la volontà, ma la capacità. La prioritizzazione dovrebbe quindi basarsi su impatto del rischio e operatività. Un ordine pragmatico:

1. Responsabilità & criticità: senza questa base tutte le misure sono prive di direzione.
2. Capacità decisionale per l’Incident Response: ruoli, runbook, escalation, canali di comunicazione.
3. Processo di vulnerability/patching incl. governance delle eccezioni: perché le superfici d’attacco qui agiscono rapidamente.
4. Prova di Backup/RESTore: la capacità di ripristino è spesso la differenza tra „incidente“ e „crisi“.
5. IAM per accessi privilegiati: pochi account, grande impatto.
6. Classificazione dei fornitori: focalizzata sui fornitori critici e sui flussi di dati.

Importante: „Prima“ non significa ignorare tutto il RESTo, ma stabilire un nucleo operativo minimo ed efficace e poi ampliarlo.

Integrazione nelle soluzioni aziendali digitali e nel software aziendale personalizzato

Molti rischi rilevanti per NIS2 non nascono solo nell’infrastruttura, ma nelle soluzioni software legate ai processi: interfacce, identità, modelli di autorizzazione, registrazione degli eventi, conservazione dei dati, passaggi di consegne operativi. Proprio nel caso di software aziendale personalizzato la governance è determinante, perché le ipotesi standard („il vendor lo farà“) non reggono.

Punti di integrazione concreti e vicini all’operatività:

• Processo di release e change: controlli di sicurezza come parte delle approvazioni (es. dipendenze, segreti, concetto di logging).
• Service Ownership: assegnazione chiara di rischio e budget per servizio, non solo per progetto.
• Operational Readiness: monitoring, segnalazione di allarmi, runbook e capacità di ripristino sono parte dell’accettazione.
• Governance delle interfacce: gli accessi alle API (Application Programming Interface, interfaccia di sistema standardizzata) richiedono autenticazione, rate-limits, logging e responsabilità chiare.

Così NIS2 non diventa un „cartello di stop“ per la digitalizzazione, ma un quadro che rende pianificabili operazioni e compliance.

Conclusione: la trasformazione organizzativa sotto NIS2 è realizzabile – se anteponete la governance agli strumenti

La leva più efficace per NIS2 non è il prossimo prodotto di sicurezza, ma un modello di governance solido: ownership, decisioni chiare, eccezioni documentabili, meccaniche di Incident Response consolidate ed evidence che si genera nella pratica quotidiana. Un buon piano di change management riduce l’attrito perché integra operatività e governance: i team sanno cosa fare; il management può prioritizzare; la compliance ottiene evidenze; e gli audit diventano gestibili.

Se volete avviare il piano in modo pragmatico, iniziate con tre artefatti: inventario con ownership, RACI per i processi core e il processo delle eccezioni. Con questo create in breve tempo le condizioni per implementare misure tecniche che abbiano effetto duraturo.

Per questo tema sono importanti anche Nis2 Change Management e Nis2 Governance. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.