Il piano di gestione delle vulnerabilità è un documento obbligatorio dell’Appendice C e richiede approvazione degli organi ai sensi di ID.RA-08 punto 4. Deve definire come le vulnerabilità vengono rilevate, priorizzate, sanate e tracciate con accountability chiara e tempistiche misurabili.
Punti chiave
- Il piano vulnerabilità è un deliverable di governance soggetto ad approvazione, non solo un artefatto tecnico SOC/IT.
- Il documento deve collegare discovery, rating rischio, remediation e gestione eccezioni.
- I target di tempo alla remediation devono riflettere criticità rischio e impatto business.
- Un piano basato su template migliora coerenza tra asset, fornitori e team tecnici.
Cosa deve mostrare un piano ID.RA-08 approvabile
| Obiettivo | Output minimo | Evidenze |
|---|---|---|
| Copertura rilevamento | Fonti vulnerabilità e perimetro definiti | Inventario fonti scan e mappa copertura |
| Logica priorità | Modello severità + contesto business | Matrice rating rischio |
| Governance remediation | Owner, data target, criteri chiusura | Tracker remediation |
| Controllo eccezioni | Processo formale di rinvio/accettazione | Registro eccezioni con approvazioni |
Struttura pratica del piano vulnerabilità
1. Finalità, perimetro e riferimenti
Definire asset coperti, sistemi, componenti software e dipendenze esterne.
2. Modello detection e intake
Specificare input (scanner, advisory, notifiche vendor, finding interni) e flusso triage.
3. Matrice priorità e SLA
Definire classi rischio e finestre target di remediation.
4. Workflow remediation
Descrivere assegnazione, implementazione, validazione e chiusura.
5. Eccezioni e controlli compensativi
Documentare come i rinvii sono giustificati e quali controlli temporanei si applicano.
6. Reporting e supervisione governance
Definire KPI (ad esempio: critici aperti, breach SLA, backlog aging) e cadenza di riesame.
7. Ciclo di rivalutazione periodica
Impostare review ricorrente per tuning del modello e lessons learned.
Errori frequenti nel piano
- Scansioni presenti ma nessun modello decisionale di priorizzazione.
- Vulnerabilità critiche aperte senza owner e data target.
- Eccezioni concesse informalmente senza controlli compensativi.
- Vulnerabilità lato fornitore escluse dalla vista governance.
- Chiusura marcata senza evidenza di validazione tecnica.
Checklist hardening in 20 giorni
- Consolidare le fonti vulnerabilità in un modello intake unico.
- Definire matrice severità-scadenza allineata alla criticità business.
- Assegnare owner accountable per dominio asset.
- Introdurre workflow formale eccezioni con registro approvativo.
- Definire standard evidenza chiusura e passaggi di verifica.
- Sottoporre il piano ad approvazione organi con reporting periodico.
FAQ
Il piano gestione vulnerabilità è un documento obbligatorio da approvare?
Sì. L’Appendice C lo elenca con riferimento ID.RA-08 punto 4.
La procedura di patch management può sostituire il piano?
No. Le procedure supportano l’esecuzione; il piano definisce governance, priorità, accountability e supervisione.
Le vulnerabilità dei fornitori vanno incluse?
Sì, quando i fornitori impattano la sicurezza dei sistemi e servizi di rete in perimetro.
Conclusione e prossimi passi
Un piano ID.RA-08 robusto trasforma la gestione vulnerabilità in un processo di riduzione rischio governato. La priorità immediata è imporre disciplina su owner/date/chiusura e rendere auditabili le decisioni di eccezione prima che diventino debito operativo.
Letture correlate
- Guida master ai documenti obbligatori NIS2: cosa va approvato dagli organi e cosa preparare subito
- Controlli NIS2 di Rilevamento (DE): Monitoraggio Eventi e Gestione dei Segnali Avversi
- Controlli NIS2 di Protezione (PR): Misure Tecniche e Organizzative in Esecuzione
- Servizio Aegister NIS2 Compliance