Decisioni di budget in ambito NIS2: calcolo degli investimenti in tecnologia, personale e verifiche

Chi oggi prepara decisioni di budget sotto NIS2 si trova raramente davanti alla domanda „Quanto costa la sicurezza?“, ma a tre problemi più precisi: cosa è obbligatorio per normativa, cosa è sensato su base di rischio – e come rappresentarlo in un budget in modo che operation, acquisti, HR, compliance e management condividano la stessa logica. NIS2 non è un tema puramente tecnico. La direttiva mira a misure di gestione del rischio, alla capacità di fornire evidenze e agli obblighi di governance. Per questo il budget non significa solo licenze e hardware, ma soprattutto personale, processi, verifiche e la capacità di segnalare nei tempi previsti e mantenere la capacità di intervento in caso di necessità.

Questo contributo mostra una logica di calcolo solida per investimenti in tecnologia, personale e verifiche – con attenzione a governance, impatti operativi e prospettiva di audit. Riceverete strumenti decisionali, checklist e blocchi di modelli che potete trasferire nella vostra pianificazione (CapEx/OpEx), nel registro dei rischi e nella roadmap delle misure.

Perché la pianificazione del budget sotto NIS2 funziona diversamente rispetto ai „progetti di sicurezza“

Nei programmi di sicurezza classici spesso si budgetta con logica „tool first“: EDR qui, SIEM là, un corso di awareness in più. Con NIS2 questa priorità si inverte. È determinante che la vostra azienda identifichi sistematicamente i rischi, implementi controlli efficaci e possa dimostrare che tali controlli vengono esercitati. „Dimostrare“ significa: decisioni tracciabili, responsabilità documentate, log, report, test, evidenze da esercitazioni sugli incidenti e valutazioni dei fornitori.

Da ciò derivano tre realtà di costo che nei budget sono spesso sottovalutate:

• Costi di esercizio: gestione operativa, manutenzione, tuning, gestione degli allarmi, reporting, formazione, ricertificazione degli accessi.
• Costi per le evidenze: creare, versionare, verificare le evidenze; rispondere alle domande di audit; rendere i controlli testabili.
• Costi di coordinamento: ruoli, comitati, approvazioni, accettazioni del rischio, escalation – in particolare in caso di outsourcing e sedi multiple.

La domanda di budget è quindi: quale combinazione di misure ottiene una riduzione efficace del rischio e la prontezza all’audit, senza sovraccaricare l’operatività IT con ulteriore complessità?

Chiarire lo scope e la rilevanza: senza delimitazione ogni cifra è arbitraria

Prima di procedere alla stima serve una definizione di scope solida. Non è un formalismo, ma la leva che può modificare il vostro budget di ordini di grandezza. Scope qui significa: quali aree di business, sedi, servizi critici, sistemi e fornitori sono soggetti ai requisiti NIS2 e devono essere considerati nelle analisi di rischio, nei controlli e nelle evidenze?

Nella pratica si è dimostrato efficace un approccio allo scope su tre livelli:

• Ambito Core: Sistemi che erogano direttamente il servizio interessato (es. piattaforme centrali, servizi di identità, rete core, software aziendale centrale, IT operativa/di produzione (OT), se pertinente).
• Ambito di supporto: Sistemi la cui indisponibilità compromette significativamente il servizio (es. backup, infrastruttura centrale di logging/monitoring, distribuzione di patch e software, VPN, ticketing).
• Ambito esteso: catena di fornitura, modelli operativi esterni, servizi cloud, fornitori terzi critici, Managed Services.

Rileva ai fini del budget che NIS2 non considera solo l’«ambito core». In particolare i rischi legati alla catena di fornitura (rischi derivanti da fornitori di servizi e dipendenze da software/cloud) costituiscono una voce di costo a sé: clausole contrattuali, due diligence, requisiti di sicurezza per i provider, evidenze e, se necessario, costi di migrazione.

Mini-lista di controllo: dati di ambito necessari per una stima dei costi affidabile

• Inventario dei servizi e dei sistemi (almeno in modo approssimativo): applicazioni, server/VM, account cloud, segmenti di rete, sedi.
• Criticità per servizio: impatto su fatturato, sicurezza, approvvigionamento/produzione, obblighi legali.
• Dipendenze: identità (IAM), DNS, e-mail, storage, backup, monitoring, fornitori terzi.
• Modello operativo attuale: interno/esterno, reperibilità, SLA, punti di consegna.
• Interfacce regolatorie: protezione dei dati, requisiti connessi a KRITIS (se applicabile), standard di settore.

Decisioni di budget sotto NIS2: il quadro dei costi in tre blocchi

Per la pianificazione con la direzione e il controllo di gestione è decisiva una struttura semplice. Si è dimostrata valida la seguente tripartizione, che potete usare come struttura di budget e reporting:

• Tecnica (Controls & piattaforme): strumenti, integrazioni, interventi architetturali.
• Personale (Build & Run): ruoli, oneri operativi, qualifiche, reperibilità.
• Verifiche (Assurance): audit, assessment, penetration test, esercitazioni, verifiche dei fornitori.

Importante: ogni voce di spesa deve poter essere ricondotta a un rischio e a una prova. Altrimenti in seguito si apriranno discussioni sul perché una voce debba essere classificata come «NIS2» e durante l’audit mancherà il filo conduttore.

Calcolare gli investimenti tecnici: meno elenco di strumenti, maggiore efficacia dei controlli

I budget tecnici sotto NIS2 diventano sostenibili se li pianificate come famiglie di controllo. Le famiglie di controllo sono gruppi di misure che coprono insieme un’area di rischio (es. identità, logging, gestione delle vulnerabilità). Questo vi permette di stabilire priorità, anche se non tutto viene finanziato immediatamente.

1) Identità & Accesso: MFA, ruoli, Accesso privilegiato

L’identità è la leva più frequente per limitare i danni. I fattori che spingono il budget non sono tanto i costi delle licenze MFA, quanto i modelli di ruolo, i processi di lifecycle e, se necessario, il PAM (Privileged Access Management: gestione protetta degli account ad alto privilegio con approvazioni, controllo delle sessioni e registrazione).

• Costo una tantum: definire modello dei ruoli, interfaccia delle autorizzazioni, integrazione dei sistemi, accessi di emergenza (Break-Glass).
• Ricorrente: ricertificazione, processo Joiner/Mover/Leaver, revisione dei diritti amministrativi, gestione di token e dispositivi.

2) Gestione degli asset e delle vulnerabilità: inventario, prioritizzazione, realtà delle patch

Senza un inventario attendibile non si possono giustificare in modo solido né i rischi né il budget. Un registro degli asset non deve essere perfetto da subito, ma deve essere verificabile: quali sistemi sono nel perimetro, chi è responsabile, come vengono gestiti gli aggiornamenti e le vulnerabilità.

Voci di budget che in pratica mancano frequentemente:

• Infrastruttura di scansione (on-prem, Cloud, sedi remote) e manutenzione degli scanner.
• Processi di deroga (es. sistemi legacy): valutazione del rischio, controlli compensativi, documentazione.
• Finestre di patch e oneri operativi: test, rollback, change management (CAB), accettazione.

3) Logging, monitoraggio e rilevazione: SIEM, XDR, casi d’uso, operatività

Sotto NIS2 l’obiettivo non è „comprare un SIEM“, ma rilevare, valutare e reagire. SIEM (Security Information and Event Management) raccoglie e correla i log; XDR (Extended Detection and Response) integra la rilevazione su endpoint, identità, rete e cloud. Determinante per il budget è se gestirlo internamente o come Managed Service.

Fattori di costo tipici:

• Volume di log (Storage, Ingestion), conservazione (Retention) e requisiti di protezione dei dati.
• Engineering dei casi d’uso: regole di allarme, correlazione, baseline, messa a punto per contrastare i falsi positivi.
• Reperibilità 24/7 o tempi di risposta definiti, incluse catene di escalation.

Una decisione di budget vincolante richiede uno stato obiettivo: quali eventi dovete vedere in modo affidabile (es. login amministrativi, escalation di privilegi, flussi di dati anomali, modifiche a policy critiche), e in quale tempo dovete essere in grado di reagire?

4) Backup, recovery e continuità operativa: RTO/RPO come parametri di budget

Molti incidenti diventano costosi solo perché il recovery richiede troppo tempo o non funziona in modo affidabile. Qui aiuta una chiara traduzione in RTO (Recovery Time Objective: tempo massimo di ripristino) e RPO (Recovery Point Objective: perdita massima di dati espressa in tempo). Questi due indicatori sono il vostro ‚regolatore‘ di budget.

• Spesa una tantum: architettura (backup immutabili, domini amministrativi separati), test di ripristino, documentazione.
• In corso: validazione regolare del ripristino, rotazione dei supporti, monitoraggio, pianificazione della capacità.

Sotto NIS2 conta anche che non lo possiate solo “avere”, ma che lo eseguiate e possiate dimostrare i risultati. Questo sposta budget verso verifiche e personale (vedi sotto).

5) Segmentazione della rete e hardening: interventi pianificabili invece del ‚Big Bang‘

La segmentazione (separazione delle aree di rete) e l’hardening dei sistemi (configurazione di base sicura) sono spesso più efficaci di strumenti aggiuntivi, ma comportano lavoro di progetto e operativo: regole firewall, processi di eccezione, troubleshooting, documentazione. Se allocate budget qui, prevedete necessariamente un sforzo per le modifiche e il coordinamento con i reparti, perché le modifiche di rete possono rapidamente diventare critiche per la produzione.

Calcolare il personale: ruoli, logica FTE e conseguenze operative

NIS2 rende visibile ciò che in molte organizzazioni IT è già scarso: tempo per un funzionamento ordinato e per una gestione del rischio affidabile. Il budget per il personale non è quindi un „nice to have“, ma la condizione affinché le misure tecniche non RESTino progetti incompiuti.

Modello di ruoli: chi va finanziato, anche se non esisteva un ’security headcount‘?

In base a dimensione e maturità non è detto che servano nuovi ruoli full-time, ma servono porzioni di responsabilità chiaramente definite. Ruoli tipici sotto NIS2:

• CISO/responsabile della sicurezza delle informazioni: gestione, portafoglio di rischi e misure, rendicontazione alla direzione.
• Responsabile ISMS (ISMS = Sistema di gestione della sicurezza delle informazioni: processi e regole per governare la sicurezza in modo sistematico): policy, evidenze, controlli interni.
• Operazioni di sicurezza: monitoraggio, triage, gestione degli incidenti, threat intelligence (a seconda delle necessità).
• Gestione IT/team piattaforma: patch, hardening, backup/recupero, identità, rete – come co-responsabili per i controlli.
• Conformità/Legale: processi di notifica, obblighi di documentazione, catena di fornitura, clausole contrattuali.

Logica di budget: se introducete nuovi strumenti dovete prevedere ore operative (triage, manutenzione, reporting). Senza queste ore l’efficacia cala e nell’audit manca la „prova operativa“.

Stima FTE pragmatica: pacchetti di lavoro invece di cifre arbitrarie

Invece di indicare un numero FTE forfettario, molte organizzazioni lavorano meglio con pacchetti di lavoro che si budgetizzano per trimestre e si scalano in base al livello di maturità:

• Governance e reporting: mantenimento del registro dei rischi, report alla direzione, cicli di revisione delle policy.
• Gestione vulnerabilità e patch: scansioni, valutazione, pianificazione delle modifiche, implementazione, gestione delle eccezioni.
• Rilevamento e risposta: gestione degli allarmi, manutenzione dei casi d’uso, playbook, lezioni apprese.
• Sensibilizzazione ed esercitazioni: pianificazione della formazione, simulazioni di phishing (se utilizzate), esercitazioni tabletop.
• Catena di fornitura: valutazioni di sicurezza, requisiti di evidenza ai provider, revisione dei report.

Questi pacchetti possono essere contabilizzati come OpEx e ridotti proporzionalmente con Managed Services – con la precisazione che controllo e responsabilità RESTano interni.

Formazione e qualificazione: budgetizzate il tempo, non solo i costi della formazione

La sensibilizzazione sotto NIS2 non è un „checkbox“ di e-learning. Rilevante per le decisioni è che i gruppi target siano differenziati: IT-Admin, Service Desk, team di sviluppo (se presenti), management, aree di business con processi critici. Il maggior blocco di costo è spesso tempo di lavoro e coordinazione (appuntamenti, monitoraggio, misurazione dell’efficacia). Per la prontezza all’audit avete bisogno di evidenze: tassi di partecipazione, contenuti, cicli di ripetizione, misure in caso di mancata partecipazione.

Verifiche e evidenze: quanto costa veramente „Assurance“

Le verifiche sotto NIS2 non sono solo audit esterni, ma un continuum di controlli interni, test tecnici e management review. L’obiettivo è che, in caso di controlli o incidenti, possiate dimostrare in modo verificabile ciò che è stato deciso e attuato.

Penetration test, Red Teaming, assessment tecnici: definire chiaramente l’ambito

Un errore di budget frequente è acquistare „un pentest“ senza definire scope e obiettivo. Per offerte affidabili e pianificazione interna dovreste almeno stabilire:

• Oggetti del test: superficie di attacco esterna, applicazioni centrali, identità, configurazione cloud, segmenti di rete.
• Tipologia di test: blackbox/graybox, autenticato/non autenticato, social engineering sì/no.
• Attività successive: re-test, prioritizzazione, tracciamento delle remediation, accettazione del rischio per i risultati.

Prevedete inoltre nel budget il supporto interno: fornitura degli accessi, finestre di manutenzione, coordinamento con il reparto operativo e le business unit, nonché l’attuazione dei risultati (che spesso rappresenta la quota maggiore).

Audit-Readiness: raccolta delle evidenze come processo continuo

La prontezza all’audit non significa raccogliere documenti poco prima di una verifica. Serve un’operatività che produca le evidenze nel normale flusso operativo: protocolli, report, approvazioni, ticket, stati delle configurazioni, verbali delle esercitazioni. Questo richiede struttura.

Minimo pratico di categorie di evidenze:

• Governance: ruoli, responsabilità, organismi decisionali, verbali dei management review.
• Rischio: metodologia, valutazione, accettazioni, piano di azione, stato.
• Controlli tecnici: baseline, report patch, test di backup, copertura dei log, review IAM.
• Incident Response: playbook, esercitazioni, lezioni apprese, canali di comunicazione e di notifica.
• Catena di fornitura: classificazione dei fornitori, requisiti di sicurezza, evidenze/report, eccezioni.

Esercitazioni tabletop e gestione delle crisi: budget per finestre temporali e addestramento alle decisioni

NIS2 è strettamente legato agli obblighi di notifica e alle responsabilità del management. Le esercitazioni tabletop (scenari simulati intorno a un tavolo) sono dunque un modo efficiente per testare le vie di notifica, i poteri decisionali e le routine di comunicazione. I costi principali sono: tempo di preparazione, moderazione, partecipazione dei dirigenti, follow-up e adeguamento dei runbook.

Prioritizzazione: un portafoglio basato sul rischio invece di „tutto contemporaneamente“

Poche aziende possono attuare tutte le misure immediatamente. Decisivo è che la vostra prioritizzazione sia plausibile in sede di audit. Basato sul rischio significa: combinare probabilità di occorrenza, impatto e capacità di rilevamento/risposta in un ordine ricostruibile.

Una griglia di prioritizzazione pratica

• Limitazione del danno prima di tutto: identità (MFA/PAM), backup/recovery, separazione degli account amministrativi, Incident Response.
• Garantire visibilità: copertura dei log, allertamento centralizzato, monitoraggio della baseline, inventario degli asset.
• Ridurre la superficie di attacco: processo di patch e gestione delle vulnerabilità, hardening, segmentazione, configurazioni standard sicure.
• Rafforzare la capacità probatoria: processo delle evidenze, revisioni periodiche, audit/controlli interni, fascicolo fornitori.

Questa sequenza non è volutamente incentrata sugli strumenti. È incentrata sull’operatività: cosa vi aiuta a evitare gli incidenti, a rilevarli più rapidamente e a ripristinare l’operatività – e dimostrarlo?

Build vs. Buy: Managed Services, team interni e i costi nascosti di passaggio

Sotto NIS2 „esternalizzare“ non è una patente di immunità. Potete affidare a fornitori il rilevamento, la gestione dei log o la gestione delle vulnerabilità, ma mantenete la responsabilità e dovete essere in grado di governare. Le decisioni di budget dovrebbero quindi distinguere tre livelli:

• Servizio: cosa fa concretamente il provider (monitoring, triage, supporto alla response)?
• Interfacce: come vengono trasmessi ticket, allarmi e modifiche (ITSM, API, E-Mail)?
• Prove: quali report, protocolli e KPI forniscono evidenze idonee all’audit?

I costi nascosti emergono tipicamente nelle fasi di consegna: catene di escalation poco chiare, responsabilità mancanti, assenza di definizioni condivise di severity e interruzioni di canale tra il tooling del SOC e l’ITSM. Questi costi sono reali, anche se non vengono fatturati: ritardi, falsi allarmi, decisioni poco chiare durante l’incidente.

Modello di calcolo: come costruire un budget NIS2 che soddisfi i requisiti di controlling e audit

Un modello solido è composto da tre tabelle logicamente collegate: rischio → misura → voce di budget. Di seguito uno schema compatto che potete trasferire in Excel/Sheets o nel vostro Portfolio-Tool.

1) Elenco dei rischi e delle misure (livello portafoglio)

Campi (consigliati)
- ID rischio
- Servizio/Sistema (ambito)
- Descrizione del rischio
- Impatto (finanziario/operativo/legale)
- Probabilità di evento (qualitativa o su scala)
- Controlli esistenti
- Controlli pianificati (ID misura)
- Data obiettivo / milestone
- Accettazione del rischio necessaria? (sì/no, da chi)
- Fonte dell'evidenza (quale prova dimostra l'efficacia?)

2) Voci di budget (CapEx/OpEx, tecnologia/personale/verifiche)

Campi (consigliati)
- ID misura
- Blocco di costo (tecnologia / personale / verifiche)
- Tipologia di costo (CapEx / OpEx)
- Una tantum (setup/progetto) / Ricorrente (esercizio)
- Driver di costo (es. volume log, endpoint, sedi, criticità)
- Dipendenze (es. IAM prima di PAM, inventario asset prima del programma di vulnerabilità)
- Conseguenze operative (modifiche aggiuntive, finestre di manutenzione, reperibilità)
- Evidenza/Beneficio (quale prova d'audit o quale riduzione del rischio)
- Responsabile (Owner) + partecipanti

3) Piano delle evidenze (ossatura per la prontezza all’audit)

Campi (consigliati)
- Controllo/Processo (es. Patch management)
- Artefatto di evidenza (report, estratto ticket, registro, documento di esercitazione)
- Frequenza (mensile/trimestrale/annuale/basata su eventi)
- Produttore (ruolo/team)
- Luogo di archiviazione (DMS, GRC-Tool, ticketing, repo)
- Revisione (chi verifica, chi firma)
- Conservazione (retention) e protezione degli accessi

Con questa triade le decisioni di budget sotto NIS2 non sono più basate su „sensazioni“, ma su un portafoglio governabile con logica delle evidenze.

Governance e responsabilità: il budget richiede percorsi decisionali

NIS2 rende il management più direttamente responsabile: le decisioni devono essere prese consapevolmente e documentate. Per il budget questo significa: serve un organismo o un processo stabile che decida accettazioni del rischio, priorità ed eccezioni. Nella pratica spesso si tratta di un Security Steering Committee o di un comitato esteso per il rischio IT.

Set minimo di governance che stabilizza la pianificazione del budget:

• RACI (Responsible, Accountable, Consulted, Informed): chi attua, chi decide, chi viene coinvolto?
• Limiti decisionali: A partire da quale livello di rischio deve decidere la direzione?
• Processo per le eccezioni: Come vengono autorizzate a tempo le deviazioni (es. sistemi legacy non patchati)?
• Cadenza del reporting: report operativo mensile, review di management trimestrale.

Senza questi percorsi il budget viene „sminuzzato“ nel corso dell’anno: i progetti partono, ma i costi di esercizio e le verifiche RESTano non finanziati o vengono scaricati su team già al limite.

Trappole tipiche del budget – e come evitarle nella pianificazione

Falla 1: Strumenti senza concetto di esercizio

Quando le sorgenti di allarme aumentano, cresce l’onere di triage. Pianificate almeno: responsabilità, tempi di risposta, flusso ticket, set di KPI (es. Time to Acknowledge, Time to Contain) e tuning periodico.

Falla 2: Misure di patching e hardening senza capacità di change

Il debito tecnico non si può „comprare via“. Se le vostre finestre di change sono scarse, servono budget per automazione dei test (dove possibile), per finestre di manutenzione aggiuntive o per il phase‑out dei sistemi legacy. Altrimenti i finding RESTano in sospeso e le richieste dell’audit diventano scomode.

Falla 3: Catena di fornitura come voce residuale

NIS2 richiede che gestiate attivamente i rischi dei fornitori. Budgetate la capacità di classificare i fornitori, richiedere evidenze, adeguare i contratti e, in presenza di dipendenze critiche, valutare alternative. È lavoro per Acquisti, IT e Compliance – non solo un allegato contrattuale.

Falla 4: «Un audit e poi basta»

Le evidenze invecchiano. I responsabili cambiano. I sistemi si modificano. Pianificate quindi controlli continui e esercitazioni regolari – altrimenti la prontezza all’audit diventa ogni anno un progetto straordinario con alto attrito.

Aiuto decisionale: quali domande devono essere incluse in ogni proposta di budget NIS2?

• Quali rischi riduciamo concretamente e come lo misuriamo (KPI/evidenze)?
• Quali conseguenze operative ne derivano (Change‑Last, disponibilità, formazione, volume ticket)?
• Da quali dipendenze è condizionata la misura e qual è il calendario realistico?
• Cosa viene deciso internamente, cosa può essere erogato esternamente e come gestiamo il fornitore?
• Quali evidenze serviranno tra 6 e 12 mesi e chi le produrrà?

Conclusione: un buon budget NIS2 è un sistema in esercizio – non una lista della spesa

La trasformazione centrale per la direzione IT e il management è questa: le decisioni di budget sotto NIS2 devono finanziare tecnologia, personale e verifiche come un sistema coerente. Tecnologia senza esercizio genera nuovi rischi. Personale senza una governance chiara si disperde nelle attività quotidiane. Verifiche senza un processo di evidenze si trasformano in sforzi straordinari e concitati. Se delimitate chiaramente l’ambito, priorizzate le misure in base al rischio e collegate ogni spesa al rischio e alle evidenze, si ottiene un budget integrabile internamente – e plausibile in sede di audit.

Quando pianificate i prossimi passi, il punto di partenza più pragmatico è di solito: definire l’ambito, impostare il portafoglio dei rischi, dare priorità a tre‑cinque famiglie di controllo (identità, ripristino, visibilità, patching/hardening, gestione degli incidenti) e contemporaneamente istituire il piano delle evidenze. Solo allora gli investimenti diventano pianificabili – e la NIS2 passa da progetto ad hoc a disciplina operativa controllabile.

Per questo tema sono inoltre importanti il budget NIS2 e i costi di conformità NIS2. Il contributo inquadra questi aspetti in modo comprensibile e mostra su cosa occorre concentrarsi nella pratica quotidiana.