La sicurezza informatica non è più solo una questione tecnica, ma una priorità strategica per ogni azienda che opera nell’era digitale. Con l’aumento esponenziale delle minacce informatiche (dai ransomware all’ingegneria sociale), la vulnerabilità dei dati sensibili e la necessità di rispettare normative sempre più stringenti come il GDPR o la NIS2, un approccio frammentato non basta più.

Un piano di sicurezza informatica strutturato è lo strumento fondamentale per proteggere il tuo business, garantire la continuità operativa e preservare la fiducia dei tuoi clienti. Tuttavia, redigerlo da zero può sembrare un compito arduo e complesso.

Questa guida pratica ti accompagnerà passo dopo passo nella creazione del tuo piano, mettendoti a disposizione un Template piano sicurezza informatica aziendale pronto all’uso. Scopriremo insieme come mappare i rischi, definire le policy di sicurezza e implementare le contromisure necessarie per costruire una difesa solida e su misura per la tua realtà.

Continua a leggere per trasformare la complessità in un piano d’azione chiaro e operativo.

Introduzione al Piano di Sicurezza Informatica Aziendale

Cos’è un Piano di Sicurezza e perché non puoi ignorarlo

Un Piano di Sicurezza Informatica è un documento strategico che definisce politiche, procedure e controlli per proteggere le risorse IT e i dati aziendali da minacce interne ed esterne.

Non è un mero adempimento formale, ma il pilastro della resilienza operativa: chi non lo adotta rischia vulnerabilità critiche, interruzioni di servizio, perdita di dati e violazioni normative come GDPR o NIS2, con impatti devastanti su reputazione, fatturato e continuità aziendale.

Differenza tra Politica di Sicurezza e Piano di Sicurezza

Differenza tra Politica di Sicurezza e Piano di Sicurezza

Molti confondono i due documenti, ma svolgono ruoli distinti nella governance della sicurezza. La Politica di Sicurezza è il documento strategico di alto livello: definisce il quadro normativo, gli obiettivi generali, i ruoli di responsabilità e i principi fondamentali che l’azienda intende adottare. È una dichiarazione di intenti, spesso firmata dal top management, che stabilisce le regole del gioco ma non entra nel dettaglio operativo.

Il Piano di Sicurezza, invece, è il documento tattico e operativo: traduce le linee guida della politica in azioni concrete, tempistiche, responsabili e risorse. Descrive misure specifiche (es. aggiornamento firewall, formazione dipendenti, audit), indicatori di performance (KPI) e procedure di monitoraggio. In sintesi: la Politica dice cosa e perché; il Piano dice come, quando e chi. Entrambi sono essenziali: senza Politica manca la visione strategica; senza Piano rimane solo teoria.

Chi dovrebbe leggere questo documento (Target Audience)

Questo piano di sicurezza informatica è rivolto principalmente a Direttori IT, Responsabili della Sicurezza delle Informazioni (CISO), System Administrator e responsabili di PMI e PA. È essenziale per chiunque abbia il compito di proteggere i dati aziendali, garantire la continuità operativa e ottemperare alle normative vigenti (GDPR, NIS2). La guida è strutturata per essere accessibile anche a chi non è un esperto di cybersecurity, ma deve definire una strategia di difesa concreta. Il template fornisce una base solida per sviluppatori di policy, responsabili della compliance e per chi gestisce l’infrastruttura ICT, offrendo un framework per identificare rischi, pianificare controlli e stabilire procedure di emergenza. È un documento operativo per chi deve tradurre le esigenze di sicurezza in azioni concrete.

Quadro Normativo e Standard di Riferimento

Definire un piano di sicurezza informatica senza una chiara mappatura del quadro normativo e degli standard di riferimento è come costruire una casa senza fondamenta: l’intero edificio rischia di crollare al primo controllo o, peggio, al primo incidente di sicurezza. Per un’azienda moderna, che sia una PMI o un ente pubblico, la conformità non è più opzionale; è un requisito strutturale che determina la sopravvivenza operativa e legale.

La normativa di riferimento non è monolitica, ma si compone di un ecosistema di regole che interagiscono tra loro. Un template efficace deve catturare queste interdipendenze, evitando l’errore frequente di trattare la sicurezza come un mero insieme di impostazioni tecniche. È, prima di tutto, un obbligo di diligenza gestionale.

GDPR (Regolamento UE 2016/679)

Il Regolamento Generale sulla Protezione dei Dati (GDPR) è il primo pilastro da considerare nel template. Sebbene spesso percepito solo come una normativa sulla privacy, il suo articolo 32 impone esplicitamente misure tecniche e organizzative “adeguate” per garantire un livello di sicurezza adeguato al rischio.

• Responsabilizzazione (Accountability): Non basta adottare misure; bisogna dimostrarne l’efficacia. Il piano deve includere la valutazione d’impatto (DPIA) per i trattamenti a rischio.
• Violazione dei dati: Il template deve definire procedure chiare per la notifica delle violazioni all’autorità competente (Garante Privacy) entro 72 ore, come richiesto dall’art. 33.
• Dati pseudonimizzati e cifrati: Il documento deve elencare specifiche tecniche (es. AES-256, algoritmi di hashing) adottate per proteggere i dati personali.

Direttiva NIS2 e DORA

Per le organizzazioni che operano in settori critici (energia, trasporti, sanità, servizi digitali) o che sono fornitori essenziali per la Pubblica Amministrazione, la Direttiva NIS2 (UE 2022/2555) rappresenta lo standard obbligatorio. Il suo recepimento nel diritto nazionale impone requisiti stringenti sulla gestione degli incidenti di sicurezza e sulla business continuity.

• Obblighi di reporting: Il template deve strutturare un flusso di escalation per la segnalazione tempestiva di incidenti significativi alle autorità CSIRT nazionali.
• Gestione del rischio della supply chain: La sicurezza non si ferma all’azienda. Il piano deve prevedere la valutazione della sicurezza dei fornitori e dei subappaltatori, obbligo centrale della NIS2.
• DORA (Digital Operational Resilience Act): Specifico per il settore finanziario, DORA impone test di resilienza operativa digitale. Il template deve includere piani per test periodici (penetration testing, simulazioni di attacco) e la gestione del rischio ICT da parte dei fornitori terzi.

ISO/IEC 27001: la struttura managment

Mentre le normative definiscono l’obbligo giuridico, lo standard internazionale ISO/IEC 27001 fornisce il framework di gestione per soddisfarlo. Non è una norma legale, ma diventa spesso contrattualmente obbligatoria, specialmente nelle gare d’appalto.

• Ciclo PDCA (Plan-Do-Check-Act): Il template deve riflettere questo ciclo. La “Pianificazione” include la definizione dello scope e del piano di trattamento del rischio; il “Controllo” richiede misure di monitoraggio e rilevamento.
• Allegato A (Annex A): Uno dei componenti chiave del template è la mappatura dei controlli di sicurezza dell’Annex A (93 controlli divisi in 14 domini). Ad esempio, il dominio A.9 (Gestione degli accessi) richiede politiche formali per l’assegnazione e la revoca dei privilegi.
• Autovalutazione: Prima di certificarsi, l’azienda deve condurre un gap analysis. Il template può fungere da checklist operativa per colmare tali lacune.

Quadro Normativo Nazionale: Codice dell’Amministrazione Digitale (CAD)

Per la Pubblica Amministrazione e le aziende che la supportano, il Codice dell’Amministrazione Digitale (D.Lgs. 82/2005) è imprescindibile. La riforma del 2021 ha introdotto la figura del Responsabile per la Transizione Digitale (RTD) e ha rafforzato gli obblighi di sicurezza informatica.

• Tracciabilità e conservazione: Il template deve integrare le regole per la gestione delle evidenze digitali e la conservazione sostitutiva dei documenti informatici.
• Valutazione della sicurezza degli strumenti: Il CAD impone l’adozione di software e hardware che garantiscano la sicurezza. Il piano deve includere criteri di valutazione per l’acquisto di soluzioni IT.

Standard di settore (PCI DSS e altri)

Alcuni settori hanno standard specifici che completano il quadro generale. Se l’azienda gestisce pagamenti con carte di credito, l’adesione al PCI DSS (Payment Card Industry Data Security Standard) è obbligatoria.

Il template deve prevedere sezioni dedicate a questi standard verticali, definendo controlli specifici come la segmentazione della rete (isola dei sistemi di payment) e la gestione crittografica dei dati del titolo della carta (CHD).

GDPR (Regolamento Generale sulla Protezione dei Dati)

GDPR (Regolamento Generale sulla Protezione dei Dati)

La conformità al GDPR è un pilastro irrinunciabile del piano di sicurezza informatica, poiché protegge i dati personali trattati dall’azienda. Inserisci nel template una sezione dedicata alle misure tecniche e organizzative per la tutela della privacy.

Inizia definendo il registro delle attività di trattamento (art. 30 GDPR), mappando flussi e finalità dei dati. Prevedi policy per la gestione del consenso degli interessati e procedure per il rispetto dei diritti (accesso, portabilità, cancellazione). È fondamentale integrare misure di sicurezza come la pseudonimizzazione, la cifratura dei dati sensibili e il controllo degli accessi basato sui ruoli (RBAC). Includi linee guida per la notifica tempestiva dei data breach alla DPA (Autorità Garante) entro 72 ore, come previsto dall’art. 33.

Assicurati che il piano preveda formazione periodica del personale sull’uso corretto dei dati e la gestione sicura delle password. Per ricevere supporto nella stesura di una policy GDPR allineata alla tua realtà, contattaci oggi per una consulenza dedicata.

ISO/IEC 27001:2022 e gli Annessi A

ISO/IEC 27001:2022 e gli Annessi A

L’ISO/IEC 27001:2022 è lo standard internazionale che definisce i requisiti per un Sistema di Gestione della Sicurezza delle Informazioni (SGSI). Nella redazione del tuo piano di sicurezza, è fondamentale fare riferimento a questo standard per garantire un approccio strutturato e riconosciuto a livello globale.

L’edizione 2022 ha revisionato gli Annessi A, raggruppando i controlli in quattro macro-aree: Organizzativa, Fisica, Tecnologica e sulle Persone. I controlli sono 93, suddivisi in 4 categorie tematiche: organizzativi, tecnici, fisici e sulla sicurezza delle risorse umane. L’obiettivo non è implementare tutti i controlli, ma selezionare quelli rilevanti in base alla valutazione del rischio aziendale.

Questo approccio basato sul rischio è il cuore del tuo piano: identifica i controlli pertinenti dagli Annessi A, giustifica le esclusioni e pianifica l’implementazione. Integrare la norma ISO 27001 nel tuo piano non solo soddisfa i requisiti di compliance, ma fornisce anche una roadmap chiara per proteggere le tue informazioni critiche.

Normative settoriali (NIS 2, PCI-DSS, HIPAA)

Dopo aver definito le basi del piano, è cruciale allinearlo alle normative specifiche del tuo settore. Queste norme non sono opzionali: impattano direttamente i requisiti di sicurezza, le procedure di notifica e le sanzioni in caso di mancata conformità.

Ecco le principali:

• NIS 2 (Network and Information Security 2): Obbligatoria per Pubbliche Amministrazioni e PMI italiane in settori critici (energia, trasporti, sanità, servizi digitali). Impone misure di sicurezza elevate (MFA, crittografia) e segnala obblighi di notifica incidenti entro 24 ore.
• PCI-DSS (Payment Card Industry Data Security Standard): Fondamentale per chi tratta pagamenti con carte di credito. Non è legge italiana, ma contrattuale: il mancato rispetto può portare al blocco dei servizi di pagamento e a sanzioni economiche.
• HIPAA (Health Insurance Portability and Accountability Act): Norma statunitense che riguarda la protezione dei dati sanitari. Se la tua azienda collabora con istituti medici USA o gestisce dati di pazienti americani, il rispetto è obbligatorio per evitare cause legali pesanti.

Integra nella tua checklist di verifica questi standard per coprire i requisiti legali specifici del tuo business.

Struttura del Template: Analisi dei Requisiti

Analisi dei Requisiti e Valutazione dei Rischi

Questa sezione costituisce il cuore del tuo piano di sicurezza, perché definisce cosa proteggere e perché. Un template per un piano di sicurezza informatica non è una lista di compiti, ma un documento strategico. Inizia mappando l’infrastruttura IT: server, reti, database, dispositivi endpoint, software applicativi e servizi cloud. Cataloga ogni asset assegnando un valore critico basato su criteri di confidenzialità, integrità e disponibilità (modello CIA).

Identifica le minacce interne ed esterne. Per le aziende, un esempio comune è il ransomware, ma non trascurare errori umani o vulnerabilità dei fornitori. Valuta il rischio combinando la probabilità di un evento con l’impatto potenziale. La valutazione dei rischi deve essere contestuale: lo stesso livello di rischio ha valenze diverse per una PA (che gestisce dati sensibili dei cittadini) rispetto a una PMI che dipende dalla continuità operativa per fatturare.

Documenta le informazioni raccolte in un foglio di calcolo dedicato (spesso incluso nei template migliori). Ecco un esempio di struttura per l’analisi dei requisiti:

• Asset: Nome specifico (es. “Database Clienti CRM”).
• Valore: Alto, Medio, Basso.
• Minaccia: Tipo (es. Accesso non autorizzato, Perdita dati).
• Vulnerabilità: Debolezza specifica (es. Mancanza di crittografia, Password deboli).
• Rischio: Livello (es. Medio, Alto).
• Mitigazione: Azione preliminare (es. Implementare MFA).

Questa mappatura ti permette di priorizzare le azioni, evitando di sprecare risorse su periferiche a basso rischio mentre trascuri critiche vulnerabilità sui server. Ricorda di coinvolgere i responsabili di reparto: conoscono i processi meglio dell’IT e possono identificare rischi operativi invisibili a prima vista.

Criteri di personalizzazione in base alla taille aziendale

Il template va adattato in base alle dimensioni dell’organizzazione. Per le piccole aziende è sufficiente una versione semplificata che copra i rischi fondamentali: password, backup e controllo degli accessi. Le medie imprese richiedono invece una struttura più articolata, con policy formali, formazione periodica del personale e gestione dei fornitori. Le grandi organizzazioni necessitano di un approccio strategico, integrando il piano di sicurezza con i processi di business, implementando strutture di governance dedicate e gestendo la complessità degli ecosistemi IT. In tutti i casi, l’obiettivo è garantire una copertura dei rischi proporzionata alle risorse disponibili, senza eccedere con misure onerose o sottostimare le minacce. Un piano ben personalizzato è un piano realistico ed efficace.

Ruolo del DPO (Data Protection Officer) e del CISO

Ruolo del DPO (Data Protection Officer) e del CISO

Il piano di sicurezza informatica aziendale deve definire con chiarezza le figure chiave per la governance della sicurezza dei dati e dei sistemi. Sebbene i ruoli possano sovrapporsi in PMI di piccole dimensioni, è fondamentale delinearne le responsabilità distinte.

• CISO (Chief Information Security Officer): Responsabile della sicurezza informatica generale. Si focalizza sulla protezione dell’integrità, confidenzialità e disponibilità dei sistemi IT (cybersecurity), gestisce il rischio tecnologico, implementa controlli tecnici e risponde a incidenti informatici.
• DPO (Data Protection Officer): Responsabile della protezione dei dati personali. Garantisce la conformità al GDPR, gestisce il trattamento dei dati, monitora la DPIA (Valutazione d’Impatto sulla Protezione dei Dati) e funge da punto di contatto con il Garante Privacy. Il suo focus è legale e organizzativo, non solo tecnico.

Nel template, specificare: nominativi o ruoli, canali di contatto, frequenza dei report di sicurezza e procedure di escalation in caso di violazione dei dati.

Sezione 1: Contesto, Scopo e Ambito di Applicazione

La redazione di un piano di sicurezza informatica non è più un esercizio astratto, ma un atto di indirizzo strategico imprescindibile per qualsiasi realtà aziendale, siano PMI o grandi organizzazioni pubbliche. Si parte, naturalmente, dal contesto: un ecosistema digitale sempre più connesso e interdipendente, dove la digitalizzazione dei processi ha ampliato a dismisura la superficie di attacco, rendendo vulnerabili non solo i sistemi informativi tradizionali, ma anche fornitori, partner e, sempre più spesso, l’infrastruttura operativa stessa. In questo scenario, normative come il NIS2, il GDPR e gli standard ISO impongono una postura proattiva verso la sicurezza: non è più questione di “se” si verificherà un incidente informatico, ma di “quando” e con quale impatto.

Lo scopo di questo piano – e del template di sicurezza informatica che andremo a costruire – è duplice e complementare. Da un lato, deve garantire la conformità normativa, proteggendo il patrimonio informativo dell’organizzazione e i dati personali che gestisce; dall’altro, deve assicurare la continuità operativa dell’azienda. Non si tratta solo di difesa passiva, ma di un meccanismo integrato di gestione del rischio che permette di identificare, proteggere, rilevare, rispondere e ripristinare in modo tempestivo ed efficace. L’obiettivo è creare un framework resiliente che trasforma la sicurezza informatica da costo fisso a valore competitivo, garantendo fiducia a clienti, stakeholder e partner commerciali.

L’ambito di applicazione del piano di sicurezza deve essere definito con precisione chirurgica per essere effettivo. Il template propone una struttura modulare che si adatta a realtà di diverse dimensioni e settori. L’applicazione va estesa a tutte le unità organizzative, includendo sistemi hardware, software, reti (sia interne che esterne/cloud), dispositivi mobili e dati, sensibili o meno, che transitano o risiedono nell’infrastruttura. È cruciale definire chiaramente i confini: il piano copre i processi aziendali, ma anche le relazioni con i fornitori (soprattutto quelli critici, come gestori di servizi cloud o di outsourcing ICT). Per le Pubbliche Amministrazioni, l’ambito si estende naturalmente ai servizi erogati ai cittadini, garantendo accessibilità e trasparenza. Per le PMI, il focus deve essere pragmatico: identificare i processi business-critical e proteggerli con risorse adeguate, evitando dispersioni su aree marginali.

Questo capitolo introduttivo serve a stabilire il perimetro decisionale e operativo. Senza una chiara definizione di Contesto, Scopo e Ambito, ogni tentativo di implementare misure di sicurezza rischia di essere frammentario e inefficace. Il template è pensato come una guida dinamica: non è un documento statico, ma una base di partenza che deve essere adattata alla cultura aziendale e all’evoluzione tecnologica. In questa fase preliminare, è fondamentale coinvolgere i responsabili IT, legali e di business per assicurare che la sicurezza sia allineata agli obiettivi strategici dell’organizzazione. Un piano di sicurezza ben definito è il primo, fondamentale passo per costruire una difesa solida e sostenibile.

Definizione dell’Ambito (Scope): Dipartimenti, Sistemi e Dati

Definizione dell’Ambito (Scope): Dipartimenti, Sistemi e Dati

Perché la policy sia efficace e non un semplice elenco di buoni propositi, il template piano sicurezza informatica deve partire da una definizione precisa dell’ambito di applicazione. È il primo passo per delimitare il campo d’azione e stabilire chi è responsabile di cosa. Senza chiarezza su questo punto, la sicurezza diventa opaca e inefficace.

Allo scopo, occore mappare:

• Dipartimenti e Ruoli: identifica tutte le aree coinvolte (IT, HR, Amministrazione, Produzione) e attribuisci chiaramente le responsabilità: chi possiede i dati, chi li gestisce e chi ne autorizza l’accesso.
• Sistemi e Infrastruttura: elenca hardware (server, endpoint), software (SaaS, ERP, CRM) e reti, includendo eventuali ambienti di test o sviluppo che potrebbero esporre dati reali se non protetti.
• Dati Critici: cataloga le informazioni sensibili (anagrafiche clienti, segreti industriali, dati finanziari) basandoti su un’analisi di impatto (DPIA) per capire dove concentrare le misure di difesa più robuste.

Questa mappatura è essenziale per dimensionare correttamente i controlli tecnici e organizzativi.

Hai già definito con precisione il perimetro di sicurezza della tua azienda?
Parla con i nostri esperti →

Obiettivi di Sicurezza Specifici e Misurabili

Obiettivi di Sicurezza Specifici e Misurabili

Dopo aver definito la policy generale, traduci i concetti in azioni concrete. Definisci obiettivi SMART (Specifici, Misurabili, Raggiungibili, Rilevanti, Temporizzati) per ogni area critica.

Esempio pratico: invece di “migliorare la sicurezza”, puntare a “Ridurre del 50% gli incidenti di phishing entro 6 mesi, monitorando i click sui test awareness“.

Altri esempi:

• Autenticazione: Implementare l’autenticazione a due fattori (2FA) per il 100% degli account amministrativi entro il prossimo trimestre.
• Backup: Garantire che il 100% dei dati critici sia coperto da backup criptati testati mensilmente, con un RTO (Tempo di Ripristino) inferiore a 4 ore.
• Patching: Applicare le patch di sicurezza critiche entro 72 ore dalla pubblicazione vendor.

Questi obiettivi fungono da KPI per valutare l’efficacia del tuo piano e giustificare gli investimenti.

Esclusioni e Limiti del Piano

Esclusioni e Limiti del Piano

Il piano di sicurezza informatica non copre tutte le eventualità. È fondamentale delimitarne il perimetro per evitare fraintendimenti e gestire le risorse in modo mirato. Le esclusioni tipiche includono dispositivi non gestiti (BYOD), sistemi legacy non più supportati dal fornitore, o infrastrutture di terze parti non direttamente sotto il controllo aziendale.

Inoltre, il piano non garantisce una sicurezza assoluta, ma mitiga i rischi. Eventuali limitazioni possono derivare da budget, risorse umane specialistiche o vincoli tecnologici. Per chiarezza operativa, è essenziale elencare esplicitamente tutte le voci escluse e i limiti di applicazione, così da definire responsabilità precise e azioni correttive future.

Sezione 2: Analisi del Rischio (Risk Assessment)

Sezione 2: Analisi del Rischio (Risk Assessment)

L’analisi del rischio è il cuore pulsante di qualsiasi piano di sicurezza informatica affidabile. Non si tratta di una mera formalità burocratica, ma del processo che permette di tradurre le minacce astratte in valori concreti, priorità operative e budget motivati. Senza un’analisi del rischio strutturata, ogni investimento in sicurezza diventa un tiro a indovinello, spesso sprecato su aree a basso impatto reale.

Il modello standard internazionale (ISO/IEC 27005 e NIST SP 800-30) suggerisce un approccio basato su tre variabili fondamentali: Minaccia, Vulnerabilità e Impatto. La combinazione di questi elementi determina il livello di rischio.

2.1 La Matrice del Rischio: Definizione e Applicazione Pratica

La base dell’analisi è la matrice del rischio 5×5, che valuta due dimensioni: la Probabilità (o Likelihood) di verificarsi dell’evento e la Gravità (o Impatto) delle conseguenze.

Struttura della matrice:

• Asse X (Probabilità): Da 1 (Molto Rara) a 5 (Molto Probabile/Imminente).
• Asse Y (Impatto): Da 1 (Trascurabile) a 5 (Disastroso/Catastrofico).

Esempio di calcolo: Il rischio di un Ransomware che cripta i dati dei clienti ha probabilità media (3) ma impatto massimo (5). Il rischio calcolato è 3 x 5 = 15 (Rischio Alto).

Questa matrice deve essere adattata al contesto aziendale. Una PMI manifatturiera attribuirà un impatto “5” a un fermo produzione di 24 ore, mentre una società di consulenza digitale lo classificherebbe come “3”. La soglia di rischio accettabile deve essere definita dal consiglio di amministrazione o dai titolari: solitamente, i punteggi superiori a 12 richiedono azioni immediate e investimenti dedicati.

2.2 Identificazione delle Minacce e Vulnerabilità

Prima di calcolare il rischio, è necessario elencare cosa potrebbe andare storto. Non esiste un inventario universale, ma per le aziende italiane (soprattutto quelle che trattano dati personali o operano in settori regolamentati) le minacce più comuni includono:

1. Attacchi Esterni: Phishing avanzato (BEC), DDoS, Compromissione di credenziali tramite furto di sessione.
2. Insider Threats: Dipendenti malintenzionati o errori umani negligenza (es. cancellazione accidentale di database).
3. Failura Tecnica: Guasto hardware critico, interruzione della fornitura elettrica, perdita di dati per corruzione.
4. Eventi Ambientali: Allagamenti, incendi, surriscaldamento delle sale server (sottovalutato nelle PMI).

Il ruolo delle vulnerabilità: Una minaccia si concretizza solo se trova una vulnerabilità. Ad esempio, la minaccia “Ransomware” sfrutta la vulnerabilità “Mancanza di patching sui sistemi Windows” o “Assenza di segmentazione di rete”.

Checklist operativa per l’identificazione:

• Conduci interviste strutturate con i responsabili di reparto (HR, IT, Legal).
• Analizza i log degli ultimi 12 mesi per incidenti passati (anche minori).
• Utilizza tool di scanning automatico delle vulnerabilità (es. Nessus, OpenVAS) per evidenzare punti deboli tecnici noti.
• Consulta fonti informative esterne come gli alert di ENISA o le advisory dei CERT nazionali.

2.3 Valutazione dell’Impatto (Asset Classification)

Il valore del rischio dipende da cosa viene colpito. Non tutti gli asset hanno lo stesso peso. È fondamentale classificarli in tre macro-categorie, come previsto dalla norma ISO 27001:

1. Asset Informatici (Dati):
   • PII (Personal Identifiable Information): Dati anagrafici, sanitari, biometrici. L’impatto è calcolato in base al GDPR (fino al 4% del fatturato globale).
   • Proprietà Intellettuale: Brevetti, codice sorgente, segreti industriali.
   • Dati Finanziari: Bilanci non pubblicati, coordinate bancarie.
2. Asset Fisici: Server, workstation, dispositivi mobili, stampanti di rete.
   • Valutazione: costo di sostituzione + tempi di fermata.
3. Asset Logici e Umani: Licenze software, reputazione del brand, competenze dei dipendenti chiave.
   • Valutazione: costi di reintegro + danno reputazionale (spesso intangibile ma devastante).

Esempio pratico di stima danno economico: Per una PMI con fatturato di 5M€, una violazione GDPR che causa la sospensione del trattamento dati potrebbe costare 200k€ in sanzioni, più una stima di 50k€ in costi legali e di notifica, più una perdita di clienti stimata al 5% (250k€). L’impatto totale è rilevante.

2.4 Analisi Quantitativa vs Qualitativa: Quale Scegliere?

Le PMI devono bilanciare accuratezza e sforzo. Esistono due approcci:

1. Analisi Qualitativa (Consigliata per la maggior parte delle PMI):
Si basa su scale ordinali (Basso, Medio, Alto, Critico). È rapida, intuitiva e sufficiente per la maggior parte dei contesti di rischio standard. È ideale per la prima implementazione del piano di sicurezza.

2. Analisi Quantitativa (Per aziende mature o ad alto rischio):
Si esprime in termini monetari o statistici (es. Probabilità annuale del 10%, Valore Esposizione Equivalente – ALE). Richiede dati storici precisi e modelli complessi (es. FAIR – Factor Analysis of Information Risk).

Esempio di calcolo ALE (Annual Loss Expectancy):
ALE = SLE (Single Loss Expectancy) x ARO (Annual Rate of Occurrence).
Se un server crash (SLE = 10.000€) ha una probabilità dell’1% all’anno (ARO = 0.01), l’ALE è 100€. L’investimento in ridondanza deve essere inferiore a 100€/anno per essere giustificato.

2.5 Prioritizzazione dei Rischi e Piano di Mitigazione

Una volta calcolati i rischi, è necessario agire. Si utilizza la logica del ALARP (As Low As Reasonably Practicable): ridurre il rischio a un livello ragionevolmente basso, considerando i costi di mitigazione rispetto al beneficio ottenuto.

Le 4 strategie di trattamento del rischio:

1. Accettazione: Il rischio è basso o il costo della mitigazione supera il danno potenziale (es. sostituzione di un PC standard da 600€ vs rischio di furto). Documentare sempre la motivazione dell’accettazione.
2. Mitigazione (Trattamento): Ridurre la probabilità o l’impatto. È l’opzione più comune.
   • Esempio: Contro il phishing, implementare filtri email e formazione obbligatoria.
3. Trasferimento: Spostare il rischio su terze parti tramite assicurazioni (Cyber Insurance) o contratti con fornitori (es. cloud provider con SLA vincolanti).
4. Avoidance: Eliminare l’attività che genera il rischio (es. smettere di raccogliere dati sensibili se non strettamente necessari).

2.6 Ruoli e Responsabilità nell’Analisi del Rischio

L’analisi del rischio non è un compito solo IT. Richiede un approccio multidisciplinare:

• Titolari di Processo (Business Unit): Definiscono l’importanza degli asset e l’impatto operativo.
• RUP (Responsabile Unico del Progetto) / CISO: Coordina l’analisi, applica la matrice e propone i controlli.
• RPD (Responsabile della Protezione dei Dati): Verifica la conformità legale (GDPR) degli impatti valutati.
• Management: Approva il livello di rischio accettabile e alloca il budget per le mitigazioni.

Errore comune da evitare: Coinvolgere solo il tecnico informatico. Spesso il tecnico sovrastima i rischi tecnici ma sottovaluta quelli operativi o reputazionali. La visione di business è cruciale per calibrare la matrice.

2.7 Modello di Report dell’Analisi del Rischio (Estratto Template)

Per mantenere l’analisi tracciabile, utilizza una struttura tabellare standard. Ecco un estratto delle colonne che il tuo template dovrebbe includere:

<!-- INIZIO INTESTAZIONE DOCUMENTO -->
<div class="doc-header">
    <h1>Piano Sicurezza Informatica Aziendale</h1>
    <p><strong>Società:</strong> [Nome Azienda S.r.l.]</p>
    <p><strong>Data di creazione:</strong> [gg/mm/aaaa]</p>
    <p><strong>Responsabile del documento (DP):</strong> [Nome Cognome, Ruolo]</p>
    <p><strong>Ultima revisione:</strong> [gg/mm/aaaa]</p>
</div>
<!-- FINE INTESTAZIONE DOCUMENTO -->

<!-- TABELLA VERSIONAMENTO -->
<table>
    <thead>
        <tr>
            <th>Ver.</th>
            <th>Data</th>
            <th>Autore</th>
            <th>Descrizione Modifica</th>
            <th>Approvatore</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.0</td>
            <td>22/01/2026</td>
            <td>Mario Rossi</td>
            <td>Creazione documento base</td>
            <td>Dario Verdi</td>
        </tr>
        <tr>
            <td>1.1</td>
            <td>[Data]</td>
            <td>[Nome]</td>
            <td>[Inserire descrizione modifica]</td>
            <td>[Nome]</td>
        </tr>
    </tbody>
</table>