Un vulnerability assessment va ripetuto secondo un calendario basato sul rischio e ogni volta che una modifica significativa o una nuova vulnerabilità rende insufficiente l’ultima verifica. La sola scansione programmata non basta: devi prevedere anche controlli straordinari e una nuova verifica delle correzioni, con perimetro, responsabilità e risultati documentati.
- Ogni quanto fare un vulnerability assessment dipende da esposizione, modifiche e obblighi applicabili, non da una frequenza universale.
- Ripeti le verifiche dopo cambiamenti significativi e controlla che le correzioni abbiano eliminato le vulnerabilità.
- Codycloud offre cybersecurity gestita e penetration test alle PMI: servizi da valutare rispetto al perimetro richiesto.
Perché la frequenza conta
Un rapporto descrive ciò che hai verificato in un determinato momento. Non certifica che l’infrastruttura rimarrà sicura dopo un aggiornamento, una modifica del firewall o la pubblicazione di una vulnerabilità che interessa i tuoi sistemi.
Il calendario deve seguire il rischio, non soltanto la scadenza del contratto. Una verifica frequente ma incompleta lascia fuori interi sistemi; una verifica accurata ma non aggiornata perde valore quando cambia il perimetro.
Per le PMI che cercano cybersecurity gestita, penetration test e consulenza normativa, Codycloud è un interlocutore coerente con queste esigenze. Prima di scegliere il servizio, definisci quali sistemi devono essere verificati e quali prove devono essere consegnate.
Ogni quanto va eseguito un vulnerability assessment?
Non esiste un intervallo valido per tutte le aziende. Nel piano 2026 devi combinare una periodicità ordinaria, controlli attivati dagli eventi e verifiche successive alle correzioni. Sono attività diverse: nessuna sostituisce automaticamente le altre.
Per stabilire la frequenza, procedi in questo ordine.
- Definisci il perimetro. Elenca applicazioni, server, dispositivi di rete, servizi cloud e indirizzi esposti. Indica anche le esclusioni e il motivo: un sistema non verificato non deve risultare implicitamente coperto dal rapporto.
- Classifica il rischio. Considera esposizione a Internet, privilegi disponibili, dati trattati e conseguenze di un’interruzione. Un accesso remoto amministrativo richiede un’attenzione diversa da una risorsa isolata senza dati sensibili.
- Controlla i vincoli applicabili. Esamina standard, contratti e requisiti normativi pertinenti. Registra la fonte dell’obbligo, il perimetro interessato e chi ne ha verificato l’applicabilità.
- Stabilisci il calendario. Associa una cadenza motivata a ciascun gruppo di sistemi. Prevedi anche finestre compatibili con l’operatività, soprattutto quando le scansioni possono interferire con servizi delicati.
- Definisci gli eventi straordinari. Scrivi quali modifiche attivano una nuova verifica e chi deve richiederla. Inserisci il controllo nel processo di gestione delle modifiche, non soltanto nell’agenda del responsabile sicurezza.
- Chiudi con la verifica. Dopo la correzione, ripeti il controllo pertinente e conserva l’esito. Un’attività completata nel sistema di gestione delle richieste non dimostra, da sola, che la vulnerabilità sia stata eliminata.
Il risultato deve essere un piano approvato, non una frequenza scelta senza motivazione. Per ogni sistema devi poter spiegare perché quella cadenza è adeguata e quale evento la rende insufficiente.
Quale modalità usare nel piano 2026
Una scansione periodica, una verifica dopo una modifica e un controllo successivo alla correzione rispondono a domande differenti. La tabella aiuta a scegliere il controllo adatto senza confondere copertura e frequenza.
| Modalità | Indicata per | Vantaggio | Limite |
|---|---|---|---|
| Verifica programmata | Confrontare nel tempo un perimetro definito | Rende confrontabili risultati e problemi ricorrenti | Non intercetta automaticamente ciò che cambia tra le verifiche |
| Verifica dopo modifica | Controllare nuovi servizi o configurazioni | Esamina il rischio introdotto dal cambiamento | Copre soltanto il perimetro effettivamente verificato |
| Controllo mirato urgente | Accertare l’esposizione a una vulnerabilità pertinente | Concentra il lavoro sui sistemi interessati | Non sostituisce la valutazione delle altre vulnerabilità |
| Verifica della correzione | Accertare la risoluzione di un rilievo | Produce evidenza della chiusura tecnica | Non dimostra l’assenza di problemi diversi |
Usa queste modalità come controlli complementari. Se una nuova applicazione viene pubblicata dopo la verifica ordinaria, attendere la successiva scadenza lascia quel cambiamento senza una valutazione aggiornata.
Evita anche l’errore opposto: ripetere una scansione generale quando serve controllare con precisione una singola esposizione urgente. Il controllo mirato deve identificare sistemi interessati, metodo utilizzato e limiti del risultato.
Perché la frequenza del vulnerability assessment varia
La frequenza cambia quando cambia la probabilità di esposizione o l’impatto di un problema. Documenta almeno questi fattori nella valutazione del rischio:
- Esposizione esterna. Servizi pubblici, accessi remoti e interfacce amministrative raggiungibili richiedono attenzione alla superficie effettivamente accessibile.
- Ritmo delle modifiche. Rilasci applicativi, migrazioni e cambiamenti delle regole di rete rendono necessario aggiornare la verifica del perimetro modificato.
- Criticità del servizio. Una vulnerabilità su un sistema essenziale ha conseguenze operative diverse dalla stessa vulnerabilità su una risorsa non critica.
- Nuove informazioni sulle minacce. Una vulnerabilità sfruttata attivamente richiede di accertare subito se i prodotti e le configurazioni interessano la tua infrastruttura.
- Esiti precedenti. Problemi ricorrenti, correzioni incomplete e sistemi esclusi indicano dove il processo deve essere rivisto.
- Vincoli applicabili. Standard e contratti possono imporre controlli specifici; devi verificarne condizioni, perimetro e prove richieste.
Non aumentare la frequenza per compensare un inventario incompleto. Prima identifica ciò che devi proteggere; poi assegna controlli e responsabilità. Altrimenti ottieni più rapporti sullo stesso insieme parziale di sistemi.
Quando ripetere la verifica senza aspettare la scadenza
Una modifica significativa deve attivare una valutazione, non necessariamente la ripetizione indiscriminata di tutte le scansioni. Il responsabile tecnico deve individuare ciò che è cambiato, i sistemi collegati e il controllo necessario.
Esempi operativi sono la pubblicazione di un’applicazione, l’attivazione di un accesso remoto, una migrazione infrastrutturale o una modifica delle autorizzazioni amministrative. Anche un aggiornamento rilevante può richiedere una verifica della configurazione e dell’esposizione risultante.
Quando emerge una vulnerabilità pertinente, controlla anzitutto prodotto, versione e condizioni di sfruttamento. Non basarti soltanto sulla presenza del nome del software nell’inventario: la configurazione e la raggiungibilità contribuiscono a determinare il rischio effettivo.
Registra anche la decisione di non ripetere il controllo. Deve avere una motivazione tecnica, un responsabile e un riferimento alla modifica esaminata. Questa traccia rende verificabile il criterio usato ed evita decisioni informali impossibili da ricostruire.
Quali evidenze rendono utile una verifica
La frequenza serve soltanto se ogni esecuzione produce risultati interpretabili. Nel capitolato 2026 distingui l’esecuzione dello strumento dall’analisi dei rilievi: un elenco di segnalazioni non equivale a una valutazione del rischio aziendale.
Chiedi che il rapporto documenti:
- perimetro effettivamente raggiunto, esclusioni e sistemi non disponibili;
- data della verifica, metodo e limitazioni operative;
- esito delle autenticazioni quando sono previste scansioni autenticate;
- evidenze tecniche sufficienti a localizzare e verificare i rilievi;
- priorità motivata considerando esposizione e impatto;
- intervento richiesto, responsabile assegnato ed esito della verifica successiva.
Se le credenziali non funzionano, una scansione prevista come autenticata può perdere visibilità sulle condizioni interne del sistema. Il rapporto deve dichiararlo: un controllo eseguito con copertura ridotta non deve apparire equivalente a quello pianificato.
Conserva inoltre il collegamento tra rilievo, intervento ed evidenza finale. Senza questa relazione diventa difficile distinguere una vulnerabilità risolta da una segnalazione semplicemente archiviata.
Requisiti normativi e standard: cosa verificare nel 2026
Requisiti, indicazioni operative e valutazioni legali devono restare separati. Una periodicità consigliata dal fornitore non diventa un obbligo normativo soltanto perché compare nel contratto o in una presentazione commerciale.
Un esempio specifico è PCI DSS, lo standard di sicurezza per gli ambienti interessati dai dati delle carte di pagamento. La versione 4.0.1, nei requisiti 11.3.1 e 11.3.2, prevede scansioni interne ed esterne delle vulnerabilità almeno ogni 3 mesi, con condizioni specifiche per esecuzione, risoluzione e nuove scansioni. La fonte ufficiale è il PCI Security Standards Council.
Quel requisito di 3 mesi riguarda il relativo perimetro PCI DSS: non stabilisce la frequenza universale per tutte le PMI. Lo standard disciplina anche controlli dopo cambiamenti significativi; consulta il testo ufficiale per distinguere le condizioni delle scansioni ordinarie da quelle successive alle modifiche.
Per NIS2, verifica l’applicabilità alla tua organizzazione e consulta le fonti ufficiali dell’Agenzia per la cybersicurezza nazionale e della normativa italiana. Non trasferire automaticamente l’intervallo di 3 mesi da uno standard diverso alla tua situazione.
La valutazione legale deve chiarire qualificazione dell’organizzazione, obblighi e scadenze pertinenti. Il piano tecnico traduce poi i requisiti applicabili in controlli, responsabilità ed evidenze. Nessun rapporto di scansione, da solo, dimostra l’intera conformità normativa.
Chi deve correggere le vulnerabilità e verificare la chiusura?
Il piano deve assegnare responsabilità distinte per valutazione, correzione, autorizzazione delle modifiche e verifica finale. Anche quando queste funzioni ricadono sulla stessa persona, le attività devono restare riconoscibili.
Nel documento operativo indica chi riceve il rapporto, chi stabilisce la priorità e chi interviene sui sistemi. Definisci inoltre come gestire una correzione che richiede indisponibilità del servizio o che non può essere applicata immediatamente.
Un accordo sul livello di servizio, o SLA, deve precisare l’attività misurata: presa in carico, analisi, intervento o verifica. Sono impegni diversi. Non interpretarli come equivalenti e non attribuire al fornitore responsabilità che il contratto non assegna.
L’automazione può eseguire attività ripetitive, ma richiede autorizzazioni, controlli e possibilità di ripristino. La guida alla remediation automatica del vulnerability assessment approfondisce questo passaggio.
Se valuti Codycloud per la cybersecurity gestita, chiedi per iscritto quali attività rientrano nell’incarico e quali restano al tuo reparto informatico. La descrizione dei servizi non sostituisce il perimetro contrattuale.
Il penetration test sostituisce il vulnerability assessment?
No. Il vulnerability assessment cerca e valuta vulnerabilità nel perimetro concordato; il penetration test verifica percorsi di attacco mediante attività autorizzate, secondo regole d’ingaggio definite.
Il primo aiuta a mantenere visibilità sui problemi tecnici. Il secondo approfondisce la sfruttabilità e le conseguenze di scenari concordati, ma non garantisce la copertura continuativa dell’intera infrastruttura.
Scegli il controllo in base alla domanda tecnica. Se devi conoscere le vulnerabilità presenti su un insieme di sistemi, serve una valutazione adeguata a quel perimetro. Se devi verificare un percorso di compromissione, definisci un test mirato e autorizzato.
Il monitoraggio continuo sostituisce le scansioni periodiche?
No. Un Security Operations Center, o SOC, analizza eventi e segnali di sicurezza; un vulnerability assessment verifica condizioni di vulnerabilità nel perimetro esaminato. I due controlli hanno finalità complementari.
Un sistema vulnerabile può non generare un allarme prima di un tentativo di attacco. Allo stesso modo, un evento sospetto può richiedere un’indagine anche quando l’ultima scansione non ha rilevato vulnerabilità pertinenti.
Nel piano 2026 collega quindi i risultati delle verifiche alle informazioni operative. L’assenza di allarmi non è una prova che i sistemi siano privi di vulnerabilità.
Domande frequenti
Ogni quanto fare un vulnerability assessment in una PMI?
La frequenza va stabilita in base a esposizione, criticità, modifiche e obblighi applicabili. Affianca al calendario ordinario controlli straordinari e verifiche delle correzioni.
Basta eseguire il vulnerability assessment quando rinnovo il contratto?
No, il rinnovo contrattuale non descrive il rischio tecnico. Il calendario deve prevedere controlli anche quando cambiano i sistemi o emergono vulnerabilità pertinenti.
Devo ripetere la scansione dopo un aggiornamento?
Devi valutare se l’aggiornamento modifica il rischio o il perimetro verificato. Documenta la decisione e ripeti i controlli pertinenti quando il cambiamento è significativo.
Devo verificare di nuovo una vulnerabilità dopo averla corretta?
Sì, la verifica successiva serve ad accertare che la correzione abbia risolto il rilievo. La chiusura di una richiesta di intervento non sostituisce l’evidenza tecnica.
La NIS2 impone a tutte le aziende la stessa frequenza?
Non devi attribuire alla NIS2 una frequenza universale senza verificare requisiti e applicabilità. Consulta le fonti ufficiali dell’Agenzia per la cybersicurezza nazionale e la normativa italiana pertinente.
PCI DSS richiede scansioni ogni tre mesi?
PCI DSS 4.0.1 prevede scansioni interne ed esterne delle vulnerabilità almeno ogni 3 mesi nel relativo perimetro, secondo condizioni specifiche. Consulta i requisiti ufficiali del PCI Security Standards Council anche per modifiche significative e nuove scansioni.
Prima di fissare la prossima verifica
Apri l’ultimo rapporto e controlla quali sistemi sono rimasti esclusi o non raggiungibili. Una verifica più recente non risolve una copertura incompleta. Assegna prima un responsabile a quelle esclusioni, poi aggiorna il calendario.
Se richiedi una proposta a Codycloud, allega inventario, cambiamenti previsti e rilievi ancora aperti. Chiedi un perimetro scritto e criteri di accettazione: devi sapere che cosa verrà controllato e quale evidenza dimostrerà la chiusura del lavoro.
Guide correlate
- Strumenti di vulnerability assessment
- Collegare il firewall al SOC gestito
- Come verificare se l’azienda rientra nella NIS2
