Un‘ analisi del rischio ai sensi di NIS2 non è un prodotto cartaceo da riporre in un cassetto. È la collegante tra i rischi aziendali, la realtà tecnica in esercizio e le decisioni dimostrabili. Nella pratica molti programmi non falliscono per l’assenza di contromisure di sicurezza, ma perché priorità, responsabilità e limiti di accettazione (cosa è „accettabile“, cosa no?) non sono definiti in modo chiaro. NIS2 aumenta la pressione: la responsabilità del Management, la capacità di segnalazione in caso di incidenti e la dimostrazione di misure „adeguate e proporzionate“ devono combaciare in modo robusto.
Questo contributo fornisce una metodologia che può essere implementata in paesaggi IT eterogenei, senza impantanarsi nella perfezione del modello. Il focus è su metriche, soglie decisionali e una documentazione auditabile che supporti in egual misura esercizio, Security e Management: cosa viene valutato esattamente? Quali cifre servono al Management? Quando un rischio è „rosso“ e chi è autorizzato ad accettarlo? E come evitare che le analisi del rischio si arenino in workshop infiniti?
Analisi del rischio secondo NIS2: cosa NIS2 richiede praticamente dall’analisi del rischio
NIS2 richiede misure organizzative e tecniche basate sul rischio. Più importante non è un framework specifico, ma la capacità di identificare, valutare, trattare e monitorare i rischi in modo sistematico e continuo. Per le aziende questo significa: l’analisi del rischio deve rappresentare Ambito, Metodologia, Risultati e Decisioni in modo tale da essere spiegabile durante audit e nei confronti di vigilanza/autorità.
Domande tipiche di verifica e dimostrazione a cui la vostra analisi del rischio dovrebbe rispondere:
- Ambito: Quali sistemi, processi, sedi e fornitori sono inclusi – e perché?
- Criteri di rischio: Cosa significa concretamente „alto“ (tempo di inattività, perdita di dati, evento di sicurezza, conseguenze legali)?
- Trattamento: Quali misure riducono quale rischio, entro quando, con quale responsabile?
- Accettazione: Quali rischi sono stati accettati consapevolmente – e a quale livello decisionale?
- Monitoraggio: Quali KRIs (Key Risk Indicators) indicano se il rischio peggiora o le misure non funzionano?
Importante: NIS2 non è un esercizio esclusivamente di sicurezza IT. Se l’analisi del rischio mantiene elenchi IT ma non stabilisce connessioni con la criticità dei processi, le dipendenze della catena di fornitura e gli obiettivi di ripristino (BCM/DR), rimane debole per le decisioni.
Definire l’ambito in modo chiaro: senza delimitazione non ci sono decisioni robuste
L’errore più frequente è un ambito che consiste in una „lista di inventario di sistemi“, senza priorità chiare. Per NIS2 serve un ambito minimo operativo che copra i servizi critici per il business, e un concetto di crescita per estendere in modo iterativo.
Un ambito praticabile in tre livelli
- Livello 1: servizi/processi critici (ad es. produzione, logistica, fatturazione, portale clienti). Questa è la vista del Management.
- Livello 2: servizi IT di supporto (ad es. IAM, E-Mail, rete, virtualizzazione, backup, Monitoring). Questa è la vista operativa.
- Livello 3: asset (applicazioni, database, interfacce, Cloud-Workloads, endpoint, fornitori). Questa è la vista tecnica di dettaglio.
L’analisi del rischio deve collegare i livelli: un guasto di “IAM” non è solo un tema IT, ma può significare «nessun accesso ai sistemi core». La valutazione deve rendere visibile questa catena, altrimenti nascono priorità sbagliate.
Metodologia: un processo snello che rimane verificabile in audit
Per le decisioni di management conta la coerenza. Una metodologia è valida quando team diversi, in situazioni simili, arrivano a risultati comparabili. Lo si ottiene con dimensioni di valutazione fisse e regole chiare, non con il massimo livello di dettaglio.
Passo 1: scenari invece di “rischi per asset”
Valutate i rischi come scenari: “Ransomware cripta file server e dati applicativi centrali”, “Cloud-Identity viene compromessa e i ruoli admin vengono abusati”, “Fornitore viene meno, la catena di patch e supporto si interrompe”. Gli scenari sono più comprensibili per gli stakeholder e si traducono direttamente in controlli (misure).
Passo 2: valutazione lungo CIA più conseguenze operative
Tradizionalmente i rischi sono valutati secondo la CIA: Confidentiality (riservatezza), Integrity (integrità) e Availability (disponibilità). Per NIS2 dovreste estendere questo approccio con una dimensione operativa/governance, ad esempio:
- Impatto da interruzione (interruzione del servizio, RTO/RPO, soluzioni manuali)
- Impatto sui dati (dati personali, segreti commerciali, manipolazione)
- Regolamentazione/Contratto (obblighi di notifica, violazioni SLA, rischi di responsabilità)
- Catena di fornitura (Single Point of Failure presso fornitori/software)
Così evitate che la “disponibilità” venga sottostimata perché “non sono interessati dati sensibili”, anche quando l’arresto operativo sarebbe massiccio.
Passo 3: definire la formula del rischio e le scale
È comune usare la formula rischio = probabilità di occorrenza × impatto. Decisivo è che le scale siano definite per iscritto: che cosa significa “probabilità 3”? Come si motiva “impatto 4”? Senza definizione si ottengono valori arbitrari.
Un approccio pragmatico è una matrice 5×5 con soglie concrete per l’impatto (in ore, intervallo di euro, classi di dati, numero di clienti) e per la probabilità (basata su esposizione, pressione di attacco, storico, maturità dei controlli). Importante: le scale devono adattarsi alla vostra organizzazione e rimanere stabili nel tempo.
Metriche che il management serve davvero (e che l’IT può fornire)
Un’analisi del rischio diventa governabile quando viene ridotta a poche metriche comprensibili. Allo stesso tempo le metriche devono essere tecnicamente collegabili, altrimenti restano “numeri da PowerPoint”.
RTO e RPO: operacionalizzare gli obiettivi di ripristino
RTO (Recovery Time Objective) è il tempo massimo di ripristino tollerabile per un servizio. RPO (Recovery Point Objective) è la perdita massima di dati tollerabile misurata come finestra temporale. Entrambi i parametri collegano la Business Impact Analysis (BIA) con decisioni su backup, RESTore e architettura.
Regola pratica: RTO/RPO non sono desideri, ma requisiti per il funzionamento, l’architettura e il budget. Se un servizio ha RTO=4h, ma i test di ripristino durano regolarmente 12h, si tratta di un rischio documentato e misurabile.
SLE e ALE: monetizzazione senza falsa precisione
Per le decisioni di budget aiuta una monetizzazione approssimativa. SLE (Single Loss Expectancy) descrive il danno di un singolo evento, ALE (Annual Loss Expectancy) la perdita annua attesa (SLE × frequenza annuale degli eventi). Funziona anche con intervalli e ipotesi conservative.
La trasparenza è fondamentale: documentate le ipotesi (p.es. fermo produzione per ora, penali contrattuali, consulenza forense esterna, costi di ripristino). La direzione può così decidere consapevolmente se un controllo è economicamente giustificato.
KRI anziché solo KPI: segnali di allerta precoce per l’aumento del rischio
KRI (Key Risk Indicator) è un indicatore precoce dell’evoluzione del rischio, in contrasto con il KPI (Key Performance Indicator) per le pRESTazioni. Esempi particolarmente utili nei contesti NIS2:
- Backlog delle patch in giorni per criticità (p.es. quota di patch critiche > 14 giorni aperte)
- Copertura MFA per accessi amministrativi e remoti
- Percentuale di sistemi senza una chiara responsabilità dell’asset (proprietario sconosciuto)
- Tasso di successo di backup/RESTore e tempi di RESTore dalle esercitazioni
- Mean Time to Detect (MTTD) e Mean Time to Respond (MTTR) per gli incidenti di sicurezza
- Fornitori: percentuale di fornitori critici senza valutazione aggiornata del rischio/sicurezza
I KRI sono utilizzabili dal management se hanno soglie chiare e conducono direttamente a misure (p.es. sospensione delle modifiche, risorse aggiuntive, deroga autorizzata).
Limiti decisionali: chi può accettare quale rischio?
Il nucleo di una governance compatibile con NIS2 non è la matrice, ma il limite decisionale. In assenza di limiti definiti emergono due modelli di errore tipici: l’IT accetta rischi implicitamente per omissione, oppure tutto viene sistematicamente portato in escalation, bloccando la capacità decisionale.
Un regolamento di rischio praticabile (Risk Appetite & Delegation)
Definite il Risk Appetite (propensione al rischio) come quadro: quali tipi di rischio non sono accettati in linea di principio (p.es. mancanza di recuperabilità di dati critici, accessi amministrativi senza MFA)? Quali rischi possono essere tollerati temporaneamente (con scadenza e piano)?
Successivamente definirete Delegation of Authority: chi è autorizzato ad accettare rischi di quale livello. Un esempio che si è dimostrato efficace in molte organizzazioni:
- Verde: Team-/Service-Owner può accettare, se documentato e se il Monitoring è attivo.
- Giallo: la direzione IT o il CISO responsabile della sicurezza deve approvare, incluso il piano temporale.
- Rosso: la direzione aziendale deve decidere; accettazione solo a termine e con contromisure/piano di emergenza.
Queste regole devono essere compatibili con la realtà di audit e responsabilità legale. Cruciale è la tracciabilità: data, decisione, motivazione, durata dell’accettazione, misure compensative.
Dal rischio alla misura: piano di trattamento del rischio che funziona in esercizio
Un’analisi del rischio è „viva“ solo quando si trasforma in un Risikobehandlungsplan (Risk Treatment Plan). Questo piano dovrebbe contenere per ogni rischio/scenario: stato obiettivo, pacchetti di misure, Owner, stima di massima del budget, dipendenze e evidenze.
Quattro opzioni di trattamento – con ostacoli tipici
- Mitigation (ridurre): introdurre/migliorare i Controls. Errore tipico: misure senza una riduzione del rischio misurabile (p.es. „Awareness“ senza KRI).
- Transfer: p.es. assicurazione o outsourcing. Errore tipico: il trasferimento non sostituisce gli obblighi di controllo; il fornitore deve essere integrato nella governance.
- Avoid (evitare): modificare/disattivare il servizio. Errore tipico: si crea Shadow-IT se manca un’alternativa.
- Accept (accettare): consapevole, temporanea, con Monitoring. Errore tipico: „Accettazione“ come scusa per risorse mancanti.
Famiglie di controlli che nelle analisi di rischio NIS2 sono tipicamente altamente efficaci
Senza dogmi di framework, le misure possono essere raggruppate in poche famiglie di controllo a cui fare riferimento nell’analisi del rischio:
- Identity & Access: MFA, account privilegiati, modelli di ruolo, Joiner/Mover/Leaver-Prozess.
- Vulnerability & Patch: Scan, priorizzazione, finestre di manutenzione, eccezioni, strategia EOL.
- Backup & Recovery: Offline/immutable Backups, esercitazioni di RESTore, evidenza RTO/RPO.
- Monitoring & Detection: log centrali, alerting, Use-Cases, Time-to-Detect.
- Network & Segmentation: zonizzazione, accessi remoti, controlli East-West.
- Supplier Controls: requisiti minimi, evidenze, Exit-Plan, subfornitori.
Il valore operativo aumenta se ogni misura ha un chiaro percorso di evidenze: Ticket, Change, prova di configurazione, protocollo di test, Report.
Prospettiva di audit: quali evidenze i revisori vogliono realmente vedere
Audit-Readiness non significa rispondere in anticipo a ogni domanda tecnica di dettaglio. Significa che le vostre decisioni sono sistematiche e ripetibili. I revisori spesso cercano coerenza: l’analisi del rischio, il piano delle misure, la gestione degli incidenti e la documentazione operativa coincidono?
Pacchetti di evidenza che funzionano in pratica
- Documento metodologico: scale, criteri, ruoli, ciclo di revisione, strumenti.
- Risk Register: scenari, valutazione, Owner, stato, trattamento, accettazioni.
- Evidenze sull’attuazione delle misure: registrazioni delle modifiche, configurazioni di sistema, approvazioni delle policy.
- Test e esercitazioni: test di ripristino, tabletop sugli incidenti, lessons learned, attività successive.
- Documentazione dei fornitori: classificazione del rischio, due diligence, clausole contrattuali, percorsi di escalation.
Un problema ricorrente è «Evidence Drift»: le misure vengono attuate, ma le evidenze non vengono versionate o non sono rintracciabili. Si tratta meno di un problema di sicurezza e più di un problema operativo e di documentazione. Qui aiutano concetti chiari di archiviazione e un collegamento tramite ID dei ticket.
Base dati tecnica: da dove provengono valutazioni e KRI in modo affidabile?
Le valutazioni del rischio diventano più credibili se collegate a dati misurabili. Non è necessario introdurre subito un SIEM o uno strumento ISMS completo. Ciò che conta è una base minima di dati affidabile.
Set minimo di fonti dati (realistico in molti ambienti)
- CMDB/asset-lista: almeno sistema, Owner, criticità, ubicazione/hosting, stato EOL.
- Dati di vulnerabilità e patch: report dei scanner o report di conformità delle patch.
- Report di backup: stato dei job, test di ripristino, tempi di esecuzione.
- Report IAM: stato MFA, gruppi privilegiati, ricertificazioni.
- Dati di incidenti e ticket: MTTD/MTTR, incidenti ricorrenti, tasso di fallimento delle modifiche.
Importante è il mapping: quale fonte dati alimenta quale KRI? Chi è il Data Owner? Con quale frequenza si aggiorna? Questa «data governance» è un fattore di successo sottovalutato, perché riduce le discussioni sulla qualità dei numeri.
Template, checklist e modelli decisionali (per NIS2 particolarmente utili)
Affinché l’analisi del rischio ai sensi di NIS2 funzioni non solo a livello concettuale ma anche nella pratica, è utile un set di template standardizzati. È possibile archiviarli e versionarli nel vostro ISMS (sistema di gestione della sicurezza delle informazioni) o nel management della qualità.
1) Template di scenario di rischio (compatto, ma completo)
Titel:
Betroffener Service/Prozess:
Szenario-Beschreibung (Was passiert?):
Auslöser/Threat (z. B. Phishing, Fehlkonfiguration, Lieferantenausfall):
Schwachstelle/Vulnerability (Warum ist das möglich?):
Betroffene Assets (Systeme, Daten, Schnittstellen):
Auswirkung (CIA + Betriebsfolgen):
RTO/RPO-Anforderung:
Bestehende Controls (Ist-Zustand):
Wahrscheinlichkeit (Skalenwert + Begründung):
Auswirkung (Skalenwert + Begründung):
Risikostufe (Matrix):
Owner:
Behandlungsoption (Mitigate/Transfer/Avoid/Accept):
Maßnahmenpaket + Zieltermin:
Kompensationsmaßnahmen (falls Accept):
Evidenzen/Nachweise:
Review-Datum:2) Logica decisionale per il «rosso» (regole di escalation e Stop/Go)
Per i rischi elevati servono trigger chiari. Una logica pratica è definire il «rosso» non solo tramite la matrice, ma anche tramite requisiti minimi non negoziabili (guardrail). Esempi:
- Servizio critico senza dimostrata capacità di ripristino (nessun test di ripristino riuscito) → automaticamente rosso
- Account privilegiati senza MFA o senza ricertificazione → automaticamente rosso
- Sistemi esposti a internet senza processo di patch o con software fuori supporto (EOL) → automaticamente rosso
Regole vincolanti di questo tipo riducono le discussioni, perché definiscono „linee rosse“ che il management deve stabilire e di cui deve assumersi la responsabilità.
3) Modello decisionale per la direzione (una pagina, idoneo alla decisione)
Tema/Rischio:
Descrizione breve dello scenario:
Servizi aziendali critici interessati:
Livello di rischio attuale e trend (KRI):
Impatto in caso peggiore (tempo, dati, legale/contrattuale):
Opzione consigliata (Mitigate/Transfer/Avoid/Accept):
Quadro costi/risorse (intervallo):
Termine obiettivo e milestone:
Rischio residuo dopo l'implementazione:
Decisione (data, decisore, durata in caso di accettazione):
Condizioni/misure compensative:
Prossima data di revisione:Catene di fornitura e terze parti: l’analisi del rischio non si ferma al firewall
Molti rischi rilevanti per NIS2 dipendono da fornitori: Managed Services, cloud, manutenzione software esterna, data center, fornitori di comunicazione. Un semplice „questionario di valutazione fornitori“ raramente basta sul piano operativo. Serve un collegamento tra il rischio del fornitore e i vostri servizi critici.
Classificazione pragmatica dei fornitori critici
- Criticità: Quali servizi dipendono direttamente da esso? Esiste un piano di exit?
- Modello di accesso: Il fornitore ha accesso privilegiato? Come viene controllato (MFA, jump host, logging)?
- Dipendenze: Subfornitori, single point of failure, interfacce proprietarie.
- Prove: report, penetration test, statistiche di disponibilità, processi di incidente (senza necessariamente richiedere certificati).
Operativamente è importante chiedersi: quanto velocemente si viene informati di interruzioni o incidenti di sicurezza presso il fornitore, e come questo si integra nella vostra logica di notifica ed escalation?
Per approfondire, questo tema si può ben collegare a un programma dedicato per la supply chain; in molte organizzazioni è sensato mettere insieme Procurement, Legal, IT e Security in un ciclo ricorrente di valutazione.
Ciclo di review e gestione operativa: l’analisi del rischio come processo continuo
NIS2 non si aspetta che una volta all’anno venga prodotto un documento. La realtà è dinamica: nuove superfici di attacco, migrazioni di sistema, cambi cloud, nuovi fornitori, turnover del personale. Perché l’analisi del rischio „viva“ serve una cadenza e occasioni chiare per la rivalutazione.
Trigger consolidati per le rivalutazioni
- Modifiche rilevanti: nuove sedi, migrazione al cloud, nuova applicazione core, cambio di data center
- Incidenti di sicurezza: in particolare pattern di ripetizione o nuove tecniche di attacco
- Audit e riscontri: quando mancano prove o i controlli non sono efficaci
- Cambio fornitore: nuovi MSP, nuovi provider SaaS, condizioni contrattuali modificate
RACI e interfacce con i processi ITIL/Change
Affinché le decisioni sul rischio non vengano prese a margine, devono essere integrate nei processi esistenti. Un Change Advisory Board può, per esempio, fungere da punto di controllo in cui i change rilevanti per il rischio vengono approvati solo con valutazione documentata. Ciò che conta non è il nome del gruppo, ma la regola: „Nessun change critico senza verifica del rischio e piano di rollback.“
Logica dei costi e dell’attuazione: come trasformare le priorità di rischio in un programma solido
Il management chiede giustamente informazioni su sforzo, effetti collaterali e ordine di intervento. Una buona analisi del rischio non RESTituisce solo „rosso/giallo/verde“, ma un portafoglio attuabile: Quick Wins, misure strutturali e modernizzazione a lungo termine.
Un modello di portafoglio pragmatico
- Misure immediate (0–6 settimane): Rafforzare i guardrail (MFA per gli admin, hardening dei backup, baseline di logging, stop EOL).
- Stabilizzazione (6 settimane–6 mesi): Processo di patch e gestione delle vulnerabilità, esercitazioni di ripristino, playbook per incidenti, ruoli/ricertificazione.
- Strutturale (6–18 mesi): Segmentazione, modernizzazione dell’identità, centralizzazione dei log, programma fornitori, automazione.
Importante è l’analisi degli effetti collaterali: alcuni controlli aumentano nel breve periodo la complessità (p. es. segmentazione) o richiedono maturità operativa (p. es. allertamento che non sfoci in „Alert Fatigue“). Anche questi rischi devono essere registrati: „Control Risk“ è reale.
Conclusione: un’analisi del rischio NIS2 è valida quando impone decisioni
Un’analisi del rischio ai sensi di NIS2 non ha successo perché è elegantemente modellata, ma perché ha conseguenze: linee rosse chiare, decisioni di accettazione tracciabili, KRIs misurabili e un piano di trattamento del rischio ancorato all’operatività. Se definite con rigore ambito, metodologia e competenze decisionali, si ottiene un sistema che migliora la prontezza all’audit e al contempo sgrava le attività quotidiane dell’IT: meno sorprese, priorità migliori, maggiore trasparenza su debiti tecnici e dipendenze.
Se desiderate approfondire i moduli correlati, è particolarmente efficace strutturare Governance, roadmap di implementazione, logica di budget e gestione della catena di fornitura come una serie di articoli collegati internamente.
Per questo tema sono inoltre importanti anche Gestione del rischio NIS2 e Valutazione dei rischi per la sicurezza IT. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.