Un aggiornamento disponibile non è ancora un aggiornamento installato. Tra i due momenti ci sono sistemi da censire, dipendenze da comprendere, prove da eseguire, finestre di manutenzione da concordare e risultati da verificare. Nelle PMI, dove l'IT è spesso gestito da poche persone o da un fornitore esterno, basta che una di queste attività resti senza un responsabile perché server, applicazioni, firewall o dispositivi continuino a usare versioni vulnerabili.
Il patch management serve a rendere questo lavoro ripetibile. Non consiste nel premere “aggiorna” su tutti i dispositivi appena arriva una notifica: è il processo con cui l'azienda identifica gli asset, valuta gli aggiornamenti, stabilisce le priorità, prova le modifiche, le distribuisce e controlla che siano andate a buon fine. L'obiettivo è ridurre l'esposizione senza introdurre interruzioni evitabili.
Questa guida, verificata l'11 settembre 2026, spiega come impostare un patch management per PMI proporzionato alla criticità dei sistemi. Le indicazioni sono generali: tempi, responsabilità e misure devono essere adattati all'infrastruttura, ai contratti, ai dati trattati e agli eventuali obblighi applicabili al caso concreto.
Che cos'è il patch management e perché non coincide con gli aggiornamenti automatici
Una patch corregge un difetto, una vulnerabilità o un problema di funzionamento. Il patch management comprende invece l'intero ciclo che permette di applicare quella correzione in modo controllato: individuare i prodotti interessati, capire se la patch è pertinente, valutarne l'urgenza, pianificare l'installazione, predisporre un ritorno alla versione precedente quando possibile e verificare l'esito.
Gli aggiornamenti automatici sono uno strumento utile dentro questo processo, soprattutto per dispositivi standardizzati e applicazioni a basso impatto. Non coprono però necessariamente ogni componente. Apparati di rete, firmware, software specialistici, sistemi industriali, plugin, applicazioni sviluppate su misura e prodotti vicini alla fine del supporto possono richiedere attività manuali o verifiche dedicate.
Anche la responsabilità resta da chiarire. Un servizio cloud può aggiornare la piattaforma di base, mentre configurazioni, integrazioni, dispositivi degli utenti o componenti installati dal cliente rimangono fuori dal perimetro del fornitore. Prima di considerare un sistema “gestito”, conviene documentare chi controlla gli avvisi, chi autorizza gli interventi e chi verifica che la correzione sia stata applicata.
Perché aggiornare tutto subito non è una strategia sostenibile
Installare ogni patch nel momento in cui viene pubblicata sembra la scelta più sicura, ma può creare un altro rischio: incompatibilità con applicazioni essenziali, interruzioni dei servizi, perdita di configurazioni o impossibilità di completare una lavorazione urgente. Rinviare indiscriminatamente, tuttavia, mantiene aperte vulnerabilità note. Il patch management gestisce proprio questo equilibrio.
La priorità non dovrebbe dipendere soltanto dall'etichetta “critica” assegnata dal produttore. Occorre considerare se il prodotto è realmente presente, se il componente vulnerabile è attivo, se il sistema è esposto a Internet, se esistono evidenze di sfruttamento, quali privilegi potrebbe ottenere un attaccante e quale processo aziendale subirebbe l'impatto.
Il catalogo Known Exploited Vulnerabilities della CISA può essere usato come uno degli input per riconoscere vulnerabilità sfruttate nel mondo reale. Non sostituisce l'analisi del contesto: una PMI deve comunque collegare ogni segnalazione ai propri asset e alle proprie dipendenze. Allo stesso modo, un punteggio tecnico elevato non dimostra da solo che quella vulnerabilità sia il rischio più urgente per una specifica azienda.
Il punto di partenza è un inventario che abbia un responsabile
Non si può aggiornare con continuità ciò che non si conosce. L'inventario utile al patch management non è un semplice elenco di computer: deve comprendere sistemi operativi, applicazioni, versioni, server, dispositivi mobili, apparati di rete, firmware, servizi cloud, componenti esposti, plugin e strumenti usati da reparti o singoli utenti.
Per ogni asset servono almeno un proprietario operativo, una funzione aziendale, il livello di criticità, il fornitore, lo stato di supporto e il metodo di aggiornamento. È importante registrare anche le dipendenze. Una patch al database, per esempio, può essere tecnicamente corretta ma richiedere una versione compatibile del gestionale o del connettore che alimenta la reportistica.
L'inventario deve prevedere entrate e uscite. Nuovi dispositivi, software acquistati direttamente da un reparto, servizi in prova e componenti installati per un progetto temporaneo possono diventare zone non presidiate. Quando un prodotto raggiunge la fine del supporto, la risposta non è cercare indefinitamente patch che non arriveranno: occorre pianificare sostituzione, isolamento, migrazione o un'altra misura compensativa motivata.
Come stabilire le priorità delle vulnerabilità
Una coda di aggiornamenti ordinata solo per data di pubblicazione non aiuta a prendere decisioni. È più utile applicare criteri coerenti e comprensibili anche alla direzione. In genere meritano attenzione anticipata i sistemi esposti verso l'esterno, le vulnerabilità con evidenze di sfruttamento, i componenti che proteggono identità e accessi, gli asset che sostengono processi essenziali e le situazioni in cui non esistono controlli compensativi efficaci.
La valutazione dovrebbe rispondere a cinque domande:
- l'asset e la versione vulnerabile sono presenti nel perimetro aziendale?
- la funzione interessata è attiva e raggiungibile da un possibile attaccante?
- esistono sfruttamento noto, istruzioni del produttore o indicatori di minaccia pertinenti?
- che cosa accadrebbe a operatività, dati, clienti e obblighi contrattuali se la vulnerabilità fosse sfruttata?
- quali controlli temporanei possono ridurre l'esposizione fino alla correzione definitiva?
Da queste risposte nasce una classe di priorità con un tempo-obiettivo interno. Non esiste una scadenza universale adatta a ogni impresa e a ogni vulnerabilità. Gli obiettivi devono riflettere rischio, capacità di intervento, indicazioni del produttore ed eventuali requisiti normativi o contrattuali. Le eccezioni vanno approvate, motivate e riesaminate; non devono diventare rinvii senza data.
Testare, distribuire e poter tornare indietro
Prima della distribuzione occorre capire che cosa potrebbe smettere di funzionare. Il test può essere molto semplice in un ambiente piccolo, ma deve comunque coprire le funzioni più importanti: accesso, stampa, integrazioni, autenticazione, scambio dati, procedure di apertura e chiusura o altre attività da cui dipende il lavoro quotidiano.
Quando l'infrastruttura lo consente, conviene partire da un gruppo limitato di dispositivi rappresentativi. L'installazione graduale permette di osservare errori prima di coinvolgere l'intera organizzazione. Per sistemi critici servono una finestra di manutenzione, un referente disponibile, comunicazioni agli utenti interessati e un piano di ripristino realistico. Un backup è utile soltanto se è coerente con il sistema, protetto e già verificato nel recupero.
L'esito non si misura con il solo avvio del comando di aggiornamento. Bisogna controllare che la versione attesa sia presente, che i servizi siano tornati disponibili e che non restino dispositivi esclusi o spenti. Gli errori devono rientrare nella stessa coda operativa, con un responsabile e una nuova decisione: riprovare, correggere la causa, applicare una mitigazione o accettare temporaneamente il rischio.
Cosa fare quando una patch non è disponibile o non può essere installata
Alcune vulnerabilità vengono rese note prima che esista una correzione utilizzabile. In altri casi la patch c'è, ma un'applicazione critica non la supporta ancora. Lasciare il sistema invariato senza altre misure non è l'unica opzione.
In attesa della correzione si possono valutare, secondo le indicazioni del produttore e il contesto tecnico, la disattivazione della funzione vulnerabile, la limitazione degli accessi, l'isolamento del sistema, regole di rete più restrittive, un monitoraggio rafforzato o una diversa modalità operativa. Queste misure riducono l'esposizione ma possono avere limiti e costi: devono essere documentate e rimosse o riviste quando cambia la situazione.
Se l'impedimento deriva da un prodotto obsoleto o da una dipendenza non più mantenuta, il problema diventa anche gestionale. La direzione deve poter vedere il rischio residuo, il costo del rinvio e le alternative. Continuare a usare un sistema fuori supporto può essere una decisione temporanea, non una condizione invisibile affidata all'inerzia.
Ruoli, fornitori e prove: il processo deve restare verificabile
Anche quando il servizio è affidato all'esterno, la PMI ha bisogno di una matrice semplice delle responsabilità. Il contratto o il piano operativo dovrebbe chiarire quali asset sono inclusi, chi riceve gli avvisi, chi decide le urgenze, quali finestre sono autorizzate, come vengono gestite le eccezioni e quale evidenza viene consegnata dopo l'intervento.
Un report utile non deve essere lungo. Può mostrare percentuale di asset inventariati, aggiornamenti completati, sistemi non conformi al tempo-obiettivo, eccezioni aperte, prodotti fuori supporto e verifiche fallite. Questi indicatori hanno senso solo se il perimetro è definito: una percentuale elevata può nascondere proprio il server o il firewall rimasto fuori dal controllo.
Periodicamente conviene verificare il processo con un campione: l'asset esiste nell'inventario, l'avviso è stato ricevuto, la priorità è motivata, l'installazione è tracciata e la versione finale è confermata. Questa catena di evidenze consente di correggere il metodo e rende più solide le decisioni in caso di audit, richiesta di un cliente o incidente.
Come avviare un patch management per PMI in modo proporzionato
Per iniziare non serve costruire subito un sistema complesso. È preferibile scegliere un perimetro importante e completare un primo ciclo: inventario, responsabilità, fonti degli avvisi, criteri di priorità, test, finestra, distribuzione, verifica ed eccezioni. Dopo il primo ciclo il processo può estendersi a dispositivi, sedi e applicazioni rimasti fuori.
Un buon punto di partenza è distinguere tre percorsi: aggiornamenti ordinari e automatizzabili; patch urgenti che richiedono una procedura accelerata; sistemi critici o legacy che hanno bisogno di test e approvazioni dedicate. La distinzione riduce il lavoro manuale dove non aggiunge valore e concentra l'attenzione sulle decisioni che possono influire davvero su rischio e continuità.
Zanettistudios presenta la Gestione Servizi IT come un'area che integra infrastrutture, cybersecurity, protezione dei dati, continuità e supporto proattivo. In questo contesto, il patch management può collegare monitoraggio tecnico e priorità operative, chiarendo perimetro, responsabilità e verifiche. La panoramica delle aree di intervento è disponibile nella pagina Servizi; per valutare un'infrastruttura specifica è disponibile il modulo Contatti.
Domande frequenti
Patch management e vulnerability management sono la stessa cosa? No. Il vulnerability management identifica, valuta e tratta le vulnerabilità; il patch management è uno dei processi con cui vengono applicate e verificate le correzioni. Una vulnerabilità può richiedere anche configurazioni, limitazioni di accesso, sostituzione del prodotto o altre misure.
Gli aggiornamenti automatici sono sempre consigliabili? Sono utili per molti dispositivi e applicazioni standard, se configurati e monitorati. Per sistemi critici, integrazioni complesse o componenti con rischi di incompatibilità può essere necessario un rilascio graduale con test e possibilità di ripristino.
Come si decide quale patch installare prima? Si combinano pertinenza della vulnerabilità, esposizione dell'asset, sfruttamento noto, impatto sul processo, disponibilità di mitigazioni e indicazioni del produttore. La sola gravità tecnica non basta a descrivere il rischio aziendale.
Che cosa succede se una patch blocca il gestionale? Il piano dovrebbe prevedere test delle funzioni essenziali, finestra di manutenzione, referente, backup o altra possibilità di ripristino e criteri per interrompere la distribuzione. Le modalità concrete dipendono dall'architettura e dal prodotto.
Chi controlla gli aggiornamenti dei servizi cloud? Dipende dal modello di servizio e dal contratto. Il fornitore può gestire la piattaforma, mentre dispositivi, identità, configurazioni, integrazioni o componenti aggiunti dal cliente restano sotto altre responsabilità. Il confine deve essere documentato.
Come si gestisce un software che non riceve più aggiornamenti? Occorre valutare sostituzione, migrazione, isolamento o misure compensative temporanee. Il rischio residuo e il piano di uscita devono essere visibili alla direzione; il mancato supporto non dovrebbe restare una scoperta occasionale.