Prioritizzazione delle vulnerabilità basata sul rischio per il 2026

Sono le 08:17 di un martedì di inizio 2026. Lo scanner delle vulnerabilità ha completato l’esecuzione notturna e la dashboard è interamente rossa. Il team infrastrutturale vede 1.842 risultanze. Il responsabile della piattaforma cloud afferma che solo 73 sono raggiungibili da Internet. Il Responsabile della conformità sta preparando le valutazioni NIS2 e DORA. Il responsabile privacy chiede se uno dei sistemi interessati tratta dati personali. Il SOC vuole sapere se qualcuna di queste vulnerabilità è sfruttata in scenari reali. Il CISO ha bisogno di una risposta per l’ingegneria, una per il consiglio di amministrazione e una terza per il prossimo audit ISO 27001.

Poi il consiglio di amministrazione pone la domanda più pericolosa nella gestione delle vulnerabilità:

“Perché abbiamo corretto prima quella?”

Nel 2026, la prioritizzazione delle vulnerabilità non è più un esercizio di ordinamento dello scanner. È una decisione di governance. La gravità CVSS 4.0 conta, ma non indica se un sistema vulnerabile supporta l’autenticazione dei clienti, archivia metadati di pagamento, abilita l’accesso remoto, tratta registrazioni di clienti UE, dipende da un fornitore terzo di servizi ICT o compare in fonti di sfruttamento noto come KEV o in informazioni correlate a EUVD.

EPSS aggiunge la probabilità di exploit, ma la probabilità non equivale all’impatto aziendale. La criticità degli asset aggiunge contesto, ma solo se l’inventario degli asset è affidabile. GDPR cambia il calcolo quando i sistemi vulnerabili trattano dati personali. NIS2 e DORA lo cambiano nuovamente quando un’interruzione potrebbe incidere su servizi essenziali, soggetti importanti, servizi finanziari, funzioni critiche o importanti, dipendenze da terze parti ICT o resilienza operativa regolamentata.

Questa è la lacuna che Clarysec osserva negli audit reali. Molte organizzazioni possono mostrare un report di scansione e un ticket di patch. Meno organizzazioni possono mostrare un modello decisionale sostenibile. Non riescono a dimostrare perché una vulnerabilità sia stata trattata come urgente, perché un’altra sia stata accettata temporaneamente o perché una patch ritardata non abbia generato un’esposizione non gestita.

La risposta di Clarysec consiste nel trasformare la prioritizzazione delle vulnerabilità in evidenze di rischio pronte per l’audit, utilizzando Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, le policy Clarysec e Zenith Controls: The Cross-Compliance Guide Zenith Controls come modello operativo.

Perché la gestione delle vulnerabilità basata prima sul CVSS fallisce nel 2026

La maggior parte dei programmi di gestione delle vulnerabilità parte ancora dalla gravità indicata dallo scanner. È comprensibile. CVSS 4.0 fornisce una base di riferimento strutturata per la gravità tecnica, incluse le dimensioni di sfruttabilità e impatto. È utile, ripetibile e ampiamente supportato.

Ma la sola gravità è incompleta.

Una vulnerabilità critica su un host di laboratorio isolato può essere meno urgente di una vulnerabilità alta su un provider di identità esposto a Internet. Una vulnerabilità media in un’API pubblica che tratta registrazioni di clienti UE può comportare un’esposizione normativa superiore rispetto a una vulnerabilità alta in un sistema di analytics non di produzione. Una vulnerabilità elencata in fonti di sfruttamento noto richiede un trattamento diverso da una vulnerabilità teoricamente grave ma non osservata in sfruttamento attivo.

La Politica di gestione delle vulnerabilità e delle patch Politica di gestione delle vulnerabilità e delle patch Enterprise di Clarysec rende esplicito questo cambiamento. La clausola 4.5.2 stabilisce:

“Mappare le vulnerabilità al contesto del rischio aziendale utilizzando CVSS, sfruttabilità e metriche di esposizione.”

Questa frase segna il confine tra semplice applicazione delle patch e gestione delle vulnerabilità basata sul rischio. La versione per PMI, Vulnerability and Patch Management Policy-sme Politica di gestione delle vulnerabilità e delle patch - PMI, rende ancora più chiara la condizione operativa di attivazione. La clausola 6.5.1 stabilisce:

“I sistemi che trattano dati personali, forniscono accesso remoto o sono esposti esternamente devono avere priorità per le scansioni e gli aggiornamenti.”

È qui che molti programmi si fermano. Scansionano tutto, ma assegnano le priorità come se tutti gli asset fossero uguali. Documentano le date di correzione, ma non il ragionamento. Conoscono il punteggio CVSS, ma non sanno se l’asset supporta un servizio regolamentato, una dipendenza critica da un fornitore o un ambiente di trattamento di dati personali.

Un modello sostenibile per il 2026 combina cinque prospettive:

1. Gravità tecnica, come CVSS 4.0.
2. Probabilità di exploit, come EPSS o informazioni comparabili sulla probabilità di sfruttamento.
3. Sfruttamento noto, incluse KEV, informazioni correlate a EUVD, allerte CERT ed ENISA.
4. Criticità degli asset e dei servizi.
5. Impatto normativo e sui dati, incluse evidenze ISO 27001, NIS2, DORA e GDPR.

Il risultato non è una verità matematica perfetta. È un processo decisionale sul rischio documentato, ripetibile e approvato dalla direzione.

Partire dal SGSI: la prioritizzazione è una decisione di governance

ISO/IEC 27001:2022 non è solo uno standard di certificazione. Se utilizzato correttamente, diventa la struttura portante del sistema di gestione per la prioritizzazione delle vulnerabilità. Le sue clausole richiedono all’organizzazione di comprendere contesto, parti interessate, requisiti legali e contrattuali, ambito di applicazione, leadership, ruoli, valutazione del rischio, trattamento del rischio, informazioni documentate e miglioramento continuo.

Questo è importante perché la prioritizzazione delle vulnerabilità è piena di assunzioni. Che cosa significa “critico”? Quale livello di rischio è inaccettabile? Chi può accettare il rischio residuo? Quando deve essere informata la direzione? Quali evidenze devono essere conservate? Queste non sono impostazioni dello scanner. Sono decisioni del SGSI.

Zenith Blueprint affronta questo tema nella fase di gestione del rischio, Step 10, definizione dei criteri di rischio e della matrice di impatto:

“I criteri di rischio sono le regole e i parametri di riferimento che la tua organizzazione utilizza per valutare la significatività di ciascun rischio. Definire questi criteri in anticipo garantisce che tutti parlino lo stesso linguaggio del rischio.”

Lo Step 10 guida inoltre le organizzazioni nella definizione di probabilità e impatto utilizzando criteri specifici per il business, incluso l’impatto normativo. Una violazione dei dati personali può essere automaticamente classificata come maggiore o grave a causa degli obblighi GDPR. Un’interruzione che interessa un servizio essenziale o importante ai sensi di NIS2 può aumentare l’impatto operativo e legale. Una vulnerabilità che interessa una funzione critica o importante di un’entità finanziaria può attivare considerazioni di resilienza DORA.

Prima di classificare le vulnerabilità, definisci le regole.

Clarysec aiuta normalmente i clienti a istituire un registro decisionale delle vulnerabilità con questi campi:

Questa tabella non è burocrazia. È la differenza tra “lo ha detto lo scanner” e “la direzione ha preso una decisione documentata sul rischio utilizzando criteri approvati”.

La criticità degli asset è il moltiplicatore mancante

I dati di exploit più accurati al mondo non aiutano se non sai che cosa fa l’asset.

Clarysec osserva spesso organizzazioni con scanner maturi e inventari degli asset immaturi. Conoscono hostname, indirizzi IP e CVE, ma non titolari di processo, classificazione dei dati, dipendenze dei servizi, impatto sui clienti, rapporto con i fornitori, priorità di ripristino o ambito normativo. Questo rende impossibile la prioritizzazione delle vulnerabilità basata sul rischio.

La Asset Management Policy-sme Politica di gestione degli asset - PMI recepisce il requisito di base nella clausola 5.3:

“Gli asset devono essere classificati in base alla loro sensibilità o criticità. Ad esempio:”

Questa classificazione è il motore della gestione delle vulnerabilità consapevole del contesto aziendale. L’asset interessato fa parte dell’autenticazione dei clienti? Supporta il trattamento dei pagamenti? È un server di backup? È un gateway API utilizzato da partner esterni? Archivia log contenenti dati personali? È ospitato da un fornitore cloud o gestito da un fornitore terzo di servizi ICT?

Zenith Controls tratta questo elemento come un punto di ancoraggio per la conformità trasversale. Per il controllo ISO/IEC 27002:2022 5.9, inventario delle informazioni e degli altri asset associati, mappa l’inventario degli asset a GDPR Article 30 e Article 32, NIS2 Article 21, DORA Articles 5, 9 e 18, e NIST CSF ID.AM. Collega inoltre l’inventario degli asset alla gestione della configurazione, alle attività di monitoraggio e alla classificazione delle informazioni.

Una regola pratica di Clarysec è semplice: nessuna vulnerabilità può essere prioritizzata correttamente finché l’asset interessato non ha un proprietario, una criticità, una classificazione dei dati e uno stato di esposizione.

Se questi campi mancano, la vulnerabilità può comunque richiedere correzione, ma la lacuna di governance degli asset diventa un rischio separato.

Costruire un modello multifattoriale di priorità delle vulnerabilità

Un modello pratico di priorità non dovrebbe limitarsi a sommare numeri non correlati fingendo che il risultato sia scientifico. CVSS 4.0 ed EPSS misurano aspetti diversi. CVSS è un quadro di riferimento per la gravità. EPSS è un segnale di probabilità di exploit. KEV o le informazioni correlate a EUVD indicano la rilevanza dello sfruttamento noto o emergente. Criticità degli asset e impatto sui dati determinano la conseguenza aziendale.

Un modello Clarysec semplice utilizza questi fattori:

Una formula esemplificativa potrebbe essere:

Punteggio di priorità = valutazione CVSS + valutazione EPSS + sfruttamento noto + esposizione + criticità degli asset + impatto sui dati - riduzione per controlli compensativi

L’organizzazione definisce quindi le soglie:

Questo funziona solo quando il modello è approvato e applicato in modo coerente. Le clausole ISO/IEC 27001:2022 da 6.1.1 a 6.1.3 richiedono una valutazione del rischio per la sicurezza delle informazioni definita, trattamento del rischio, selezione dei controlli, approvazione del rischio residuo e informazioni documentate.

La Politica di gestione del rischio Politica di gestione del rischio Enterprise di Clarysec rafforza questo punto nella clausola 6.2.2:

“L’analisi deve considerare l’efficacia dei controlli esistenti, le informazioni sulle minacce pertinenti, la criticità degli asset e la gravità delle vulnerabilità.”

La Risk Management Policy-sme Politica di gestione del rischio - PMI per PMI fornisce una semplice regola sulle evidenze nella clausola 5.1.2:

“Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, titolare e piano di trattamento del rischio.”

Per la prioritizzazione delle vulnerabilità, ciò significa che ogni correzione rilevante ritardata dovrebbe creare o collegarsi a una voce di rischio. Se una vulnerabilità ad alta gravità viene rinviata perché l’asset è isolato ed esistono controlli compensativi, il Registro dei rischi deve indicare titolare, motivazione, evidenze e data di riesame.

Informazioni sulle minacce: EPSS, KEV, EUVD, ENISA e allerte CERT

Lo sfruttamento noto cambia tutto.

La Politica di gestione delle vulnerabilità e delle patch Enterprise afferma che la governance dovrebbe considerare:

“Exploit noti (ad es. inserimento CISA KEV)”

La policy per PMI amplia le fonti informative nella clausola 6.2.1.3:

“Avvisi attendibili di informazioni sulle minacce (ad es. CISA, ENISA, allerte CERT nazionali)”

Un programma maturo di gestione delle vulnerabilità nel 2026 deve acquisire più fonti: avvisi degli scanner, bollettini di sicurezza dei fornitori, KEV, informazioni sulle vulnerabilità correlate a EUVD, allerte CERT nazionali, avvisi ENISA, ISAC di settore, probabilità EPSS, segnali EDR e telemetria degli incidenti.

Queste fonti non significano tutte la stessa cosa. Le fonti in stile KEV indicano sfruttamento noto. EPSS stima la probabilità. Le fonti EUVD ed ENISA supportano la consapevolezza e il coordinamento europei sulle vulnerabilità. Gli avvisi dei fornitori chiariscono versioni interessate, mitigazioni, condizioni di exploit e disponibilità delle patch.

Zenith Controls descrive il controllo ISO/IEC 27002:2022 5.7, informazioni sulle minacce, come un controllo preventivo, di rilevamento e correttivo a supporto di riservatezza, integrità e disponibilità. Collega direttamente le informazioni sulle minacce al controllo 8.8, gestione delle vulnerabilità tecniche:

“Le informazioni sulle minacce spesso includono dati su vulnerabilità emergenti ed exploit sfruttati in scenari reali, consentendo una prioritizzazione dell’applicazione delle patch e della mitigazione delle vulnerabilità ai sensi di 8.8.”

Questa relazione è critica. Le informazioni sulle minacce non sono un’attività separata del SOC. Sono un input per la prioritizzazione, le decisioni di modifica di emergenza, le notifiche ai fornitori, il triage degli incidenti e la reportistica alla direzione.

GDPR, NIS2 e DORA cambiano il significato di urgenza

Una vulnerabilità su un sistema che tratta dati personali non è solo una debolezza IT. Può diventare un fallimento della sicurezza del trattamento se non sono in atto misure tecniche e organizzative adeguate.

GDPR Article 5 richiede integrità, riservatezza e accountability. Article 32 richiede misure di sicurezza appropriate tenendo conto del rischio. Article 4 definisce ampiamente i dati personali e definisce la violazione dei dati personali come un incidente che porta alla distruzione, perdita, modifica, divulgazione non autorizzata o accesso accidentale o illecito ai dati personali. Article 9 aumenta la rilevanza per categorie particolari di dati come dati biometrici o sanitari.

La Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy Enterprise di Clarysec stabilisce nella clausola 3.3:

“Implementare misure tecniche e organizzative (TOM) che proteggano la riservatezza, l’integrità e la disponibilità delle informazioni personali (PII) durante tutto il loro ciclo di vita.”

Per questo il modello di prioritizzazione necessita di un fattore di impatto sui dati. Se una vulnerabilità interessa registrazioni dei clienti, file di verifica dell’identità, metadati di pagamento, ticket di supporto, dati HR o telemetria che identifica gli utenti, la valutazione dell’impatto dovrebbe aumentare. Se lo sfruttamento potrebbe comportare accesso non autorizzato, modifica o divulgazione, l’evento può richiedere anche una valutazione dell’impatto della violazione e un’analisi di potenziale notifica.

Zenith Controls mappa il controllo ISO/IEC 27002:2022 8.8 a GDPR Articles 32(1), 5(1)(f) e Recital 83, descrivendo come la gestione delle vulnerabilità tecniche supporti misure tecniche e organizzative appropriate e una mitigazione del rischio aggiornata per i sistemi che trattano dati personali.

NIS2 aggiunge un ulteriore livello. Article 21 richiede ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi di cibersicurezza e ridurre al minimo l’impatto degli incidenti. La sua base di riferimento include analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene cyber, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e autenticazione ove appropriato. Article 20 assegna obblighi di governance agli organi di gestione, incluse approvazione e supervisione delle misure di gestione del rischio di cibersicurezza.

DORA è particolarmente importante per le entità finanziarie. Crea un quadro di resilienza operativa digitale che copre gestione dei rischi ICT, segnalazione di gravi incidenti connessi all’ICT, test di resilienza, condivisione delle informazioni e gestione del rischio ICT di terze parti. Articles 5 e 6 richiedono governance interna, gestione dei rischi ICT documentata, policy, procedure, strumenti, riesame, audit, correzione e una strategia di resilienza operativa digitale. Articles 9, 10 e 11 affrontano protezione, prevenzione, rilevamento, risposta e ripristino. Articles 17 to 19 richiedono rilevazione degli incidenti, classificazione, escalation, notifica e reportistica. Article 28 richiede gestione del rischio ICT di terze parti, registri degli accordi contrattuali, valutazioni precontrattuali, diritti di audit e ispezione, diritti di risoluzione e strategie di uscita.

Per le vulnerabilità, questo significa che le entità finanziarie devono sapere se una debolezza interessa una funzione critica o importante, un servizio ICT di terze parti, un carico di lavoro cloud, un processo di pagamento o un obiettivo di resilienza.

Esempio pratico: dalla dashboard rossa alla priorità massima sostenibile

Immagina che un fornitore SaaS scopra CVE-2026-XXXX in un framework web. Lo scanner la contrassegna come alta. EPSS è elevato. Compare in un avviso correlato a ENISA e successivamente in un flusso di sfruttamento noto. L’applicazione interessata è esposta a Internet, supporta il login dei clienti e tratta dati di profilo di clienti UE. L’ingegneria vuole rinviare la patch al fine settimana per il rischio di indisponibilità.

Ecco come Clarysec documenterebbe la decisione.

Primo, confermare il contesto dell’asset. L’inventario mostra che l’applicazione è in produzione, esposta esternamente, di proprietà del team Platform, supporta l’autenticazione, tratta dati personali e ha una valutazione di criticità aziendale alta. Questo è coerente con la clausola 5.3 della Asset Management Policy-sme e con la mappatura del controllo 5.9 di Zenith Controls a inventario degli asset, GDPR ed evidenze DORA.

Secondo, attribuire un punteggio alla vulnerabilità:

Terzo, selezionare il trattamento. La decisione è mitigazione immediata più patch accelerata. La regola WAF viene distribuita entro poche ore, le regole di monitoraggio vengono calibrate e la patch viene applicata con modifica di emergenza. Se il rischio di indisponibilità è significativo, il proprietario del servizio e il Titolare del rischio approvano la modifica di emergenza.

Quarto, registrare le evidenze. La Vulnerability and Patch Management Policy-sme per PMI richiede che i log delle patch includano:

“I log devono includere il nome del dispositivo, l’aggiornamento applicato, la data di applicazione della patch e il motivo di eventuali ritardi.”

La policy Enterprise richiede inoltre:

“Evidenza della prioritizzazione basata sul rischio.”

Il ticket deve includere punteggio, fonte di informazioni sulle minacce, criticità degli asset, impatto sui dati personali, decisione di trattamento, approvazione della modifica, evidenze di test, timestamp della distribuzione, query di rilevamento e dichiarazione del rischio residuo.

Infine, aggiornare il Registro dei rischi e la Dichiarazione di Applicabilità. Zenith Blueprint, fase di gestione del rischio, Step 11, costruzione e documentazione del Registro dei rischi, spiega:

“Il Registro dei rischi è un documento vivo. Durante tutto il ciclo di vita del SGSI, aggiornalo dopo le decisioni di trattamento del rischio, ogni volta che emergono nuovi rischi, quando compaiono nuove informazioni sulle minacce o quando un incidente rivela una vulnerabilità.”

Se questa vulnerabilità crea un rischio inaccettabile, deve rimanere nel Registro dei rischi fino alla correzione. Nello Step 13, pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, Zenith Blueprint raccomanda di aggiungere i riferimenti ai controlli dell’Allegato A al piano di trattamento del rischio e di indicare dove i controlli supportano la conformità a GDPR, NIS2 o DORA. Lo Step 19 collega poi questo modello di governance all’esecuzione della gestione tecnica delle vulnerabilità.

Mappatura di conformità trasversale: una decisione, molti obblighi

Il valore della gestione delle vulnerabilità basata sul rischio è che le stesse evidenze possono servire più quadri di riferimento. Zenith Controls agisce come bussola di conformità trasversale, mostrando come i controlli ISO/IEC 27002:2022 si collegano a normative, quadri di riferimento e aspettative di audit.

ISO/IEC 27005:2024 supporta questo approccio riconoscendo le vulnerabilità non corrette come fattori che contribuiscono al rischio per la sicurezza delle informazioni e supportando la correzione basata sul rischio. ISO/IEC TS 27008:2019 aggiunge la prospettiva dell’auditor: gli auditor valutano se esistono strumenti di scansione, se i risultati delle scansioni sono riesaminati, se le tempistiche di patch sono ragionevoli e se le tracce di audit mostrano rilevamento, valutazione del rischio e correzione.

Che cosa chiederanno gli auditor

Un auditor ISO/IEC 27001:2022 partirà dal SGSI. Chiederà se la gestione delle vulnerabilità rientra nell’ambito di applicazione, se i criteri di rischio sono definiti, se le valutazioni del rischio considerano riservatezza, integrità e disponibilità, se il controllo 8.8 è incluso nella Dichiarazione di Applicabilità, se i Titolari del rischio approvano il trattamento e se il rischio residuo è accettato in modo appropriato.

Un auditor NIS2 chiederà se il processo supporta le misure di Article 21, se il trattamento delle vulnerabilità è proporzionato, se i servizi essenziali o importanti sono protetti, se l’esposizione della catena di fornitura è considerata e se gli organi di gestione supervisionano il rischio di cibersicurezza.

Un’autorità di vigilanza DORA o un gruppo di audit interno chiederà se la prioritizzazione delle vulnerabilità fa parte del quadro di gestione dei rischi ICT, se supporta la resilienza operativa digitale, se copre i servizi ICT di terze parti, se alimenta la classificazione degli incidenti e se le vulnerabilità che interessano funzioni critiche o importanti sono tracciate tramite la governance.

Un revisore GDPR chiederà se i sistemi che trattano dati personali sono stati identificati, se le vulnerabilità che li interessano sono state trattate in base al rischio, se le misure tecniche e organizzative erano appropriate, se il sospetto sfruttamento ha attivato la valutazione della violazione e se esistono evidenze di accountability.

Un valutatore orientato a NIST o COBIT si concentrerà su risultati, governance, titolarità del processo, risposta al rischio, monitoraggio continuo, gestione delle eccezioni e miglioramento misurabile.

La risposta migliore per tutti è un’unica traccia di evidenze coerente: contesto dell’asset, informazioni sulle minacce, punteggio di priorità, decisione di trattamento, approvazione del Titolare del rischio, prova della correzione e mappatura dei controlli.

Schemi di fallimento comuni

Il primo fallimento consiste nel trattare CVSS come unica variabile di prioritizzazione. Questo crea falsa urgenza per sistemi isolati e falso conforto per sistemi esposti e critici per l’attività.

Il secondo fallimento è la mancanza di criticità degli asset. Senza titolarità e classificazione dei dati, il team delle vulnerabilità non può prendere decisioni normative o operative.

Il terzo fallimento è una gestione debole delle eccezioni. Una patch ritardata senza motivazione documentata, controllo compensativo e approvazione del Titolare del rischio non è gestione basata sul rischio. È backlog non gestito.

Il quarto fallimento è separare la gestione delle vulnerabilità dalla risposta agli incidenti. Se una vulnerabilità è sfruttata in modo noto e l’asset interessato mostra attività sospetta, il problema potrebbe non essere più solo gestione delle patch. Potrebbe diventare una questione di classificazione dell’incidente e di segnalazione ai sensi di NIS2, DORA o GDPR.

Il quinto fallimento è la cecità rispetto ai fornitori. DORA Article 28 e le aspettative NIS2 sulla catena di fornitura rendono essenziali le evidenze sulle vulnerabilità delle terze parti. Se un fornitore cloud, un fornitore SaaS o un fornitore di servizi gestiti ospita un componente vulnerabile che interessa il tuo servizio, servono comunque inventario, diritti contrattuali, comunicazione, valutazione del rischio ed evidenze.

Checklist di prioritizzazione delle vulnerabilità pronta per l’audit

Usa questa checklist per verificare se il tuo processo di prioritizzazione delle vulnerabilità è sostenibile:

• Disporre di criteri di rischio approvati dalla direzione per probabilità, impatto, impatto normativo e propensione al rischio.
• Arricchire le vulnerabilità con CVSS 4.0, EPSS, sfruttamento noto, esposizione, criticità degli asset e impatto sui dati.
• Mantenere un inventario degli asset con proprietario, servizio aziendale, criticità, classificazione dei dati e dipendenza dai fornitori.
• Definire soglie di trattamento di emergenza, urgente, pianificato e monitorato.
• Richiedere l’approvazione del Titolare del rischio per violazioni degli SLA, rinvii e accettazioni.
• Collegare le vulnerabilità significative al Registro dei rischi e al piano di trattamento del rischio.
• Mappare i controlli nella Dichiarazione di Applicabilità, in particolare i controlli ISO/IEC 27002:2022 5.7, 5.9 e 8.8.
• Conservare log delle patch, registrazioni delle modifiche, evidenze di test, evidenze di mitigazione e motivazioni dei ritardi.
• Segnalare tempestivamente lo sfruttamento sospetto alla risposta agli incidenti e alla valutazione della violazione.
• Tracciare le vulnerabilità dei fornitori e gli obblighi contrattuali di correzione.
• Riesaminare le metriche nel riesame della direzione, inclusi elementi P1 e P2 scaduti, tendenze delle eccezioni e cause radice ricorrenti.
• Aggiornare le regole di prioritizzazione quando cambiano informazioni sulle minacce, servizi aziendali o ambito normativo.

Questa checklist rispecchia la logica di Zenith Blueprint: definire criteri, costruire il registro, trattare i rischi, mappare i controlli, conservare le evidenze e migliorare continuamente.

Il metodo Clarysec: rendere spiegabile la prioritizzazione prima dell’audit

La prioritizzazione delle vulnerabilità basata sul rischio nel 2026 non riguarda la creazione di un punteggio perfetto. Riguarda la creazione di un modello decisionale che un CISO possa difendere, un ingegnere possa utilizzare, un Titolare del rischio possa approvare e un auditor possa testare.

Clarysec aiuta le organizzazioni ad applicare questo modello tramite:

• Zenith Blueprint Zenith Blueprint, in particolare lo Step 10 di gestione del rischio per i criteri di rischio, lo Step 11 per il Registro dei rischi vivo, lo Step 13 per il trattamento del rischio e la tracciabilità della SoA, e lo Step 19 per la gestione tecnica delle vulnerabilità.
• Le policy Clarysec Enterprise e PMI, incluse Politica di gestione delle vulnerabilità e delle patch Politica di gestione delle vulnerabilità e delle patch, Vulnerability and Patch Management Policy-sme, Politica di gestione del rischio Politica di gestione del rischio, Risk Management Policy-sme Politica di gestione del rischio - PMI, Asset Management Policy-sme Politica di gestione degli asset - PMI e Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy.
• Zenith Controls Zenith Controls, che mappa informazioni sulle minacce, inventario degli asset e gestione delle vulnerabilità tecniche tra ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST SP 800-53, NIST CSF e COBIT 2019.

Se il tuo processo attuale dice ancora “applica prima le patch ai CVSS critici”, il 2026 è l’anno per aggiornarlo. Costruisci ora il modello di evidenze: gravità, probabilità di exploit, sfruttamento noto, esposizione, criticità degli asset, impatto sui dati, controlli compensativi, decisione del Titolare del rischio e mappatura normativa.

Il tuo prossimo audit, la prossima domanda dell’autorità di regolamentazione, il prossimo riesame della sicurezza da parte di un cliente o la prossima riunione del consiglio di amministrazione non chiederanno se lo scanner ha trovato vulnerabilità. Chiederanno se la tua organizzazione ha preso le decisioni corrette, abbastanza rapidamente e con evidenze.

Scarica i template Clarysec, mappa il tuo processo attuale di gestione delle vulnerabilità rispetto a Zenith Controls, oppure prenota una valutazione Clarysec per trasformare la prioritizzazione delle vulnerabilità in una prova pronta per l’audit.