Dalle scansioni alle evidenze: ISO 27001:2022, NIS2, DORA

Sono le 08:16 di lunedì. Una vulnerabilità critica di esecuzione di codice da remoto è appena comparsa nel cruscotto di un server applicativo esposto a Internet. Il team infrastrutturale conferma che la patch del fornitore è disponibile. Il proprietario dell’applicazione segnala che il server supporta un processo cliente critico per i ricavi. La funzione legale chiede se un eventuale sfruttamento possa attivare obblighi di segnalazione ai sensi di NIS2, DORA o GDPR. La CISO, Maria, apre il calendario degli audit e vede il problema reale: l’audit di sorveglianza ISO 27001:2022 inizia la settimana successiva, un riesame di preparazione a NIS2 è già in corso e un importante cliente fintech ha richiesto evidenze DORA.

Lo scanner mostra rosso. Il sistema di ticketing mostra attività. Il foglio di calcolo mostra impegno. Ma niente di tutto questo dimostra automaticamente che il controllo sia efficace.

Questo è il divario che molte organizzazioni scoprono troppo tardi. La scansione delle vulnerabilità non equivale alla preparazione all’audit della gestione delle vulnerabilità. Una scansione indica che qualcosa potrebbe non essere corretto. Le evidenze di audit dimostrano che l’organizzazione sapeva quali asset possedeva, ha valutato il rischio, assegnato la titolarità, agito nel rispetto della policy, controllato la modifica, documentato le eccezioni, verificato i risultati e riesaminato l’esito.

Per ISO/IEC 27001:2022, NIS2 e DORA, questa catena di evidenze conta quanto la correzione tecnica. Lo scanner avvia il percorso. L’inventario degli asset, il registro delle vulnerabilità, il ticket, la decisione sul rischio, la registrazione della modifica, il registro delle patch, le evidenze di convalida, l’approvazione dell’eccezione e il riesame della direzione lo completano.

L’approccio di Clarysec è semplice: non trattare la gestione delle vulnerabilità come un rituale tecnico mensile. Trattala come un flusso di evidenze governato.

Perché i report di scansione non bastano come evidenze di audit

Una scansione di vulnerabilità è un’osservazione tecnica puntuale nel tempo. Può identificare una CVE, una patch mancante, una libreria non supportata, un servizio esposto o una configurazione debole. È utile, ma incompleta.

Un auditor porrà domande diverse:

• L’asset interessato rientrava nel campo di applicazione?
• Chi è il proprietario dell’asset e del servizio aziendale?
• La vulnerabilità è stata valutata considerando esposizione, sfruttabilità, impatto aziendale e sensibilità dei dati?
• La correzione è stata completata entro la tempistica definita?
• Se la correzione è stata rinviata, chi ha accettato il rischio residuo?
• La patch è stata distribuita tramite un processo controllato di gestione delle modifiche?
• La correzione è stata verificata tramite nuova scansione o convalida tecnica?
• Le evidenze sono state conservate e riesaminate dalla direzione?

Una cartella di export dello scanner raramente risponde a queste domande. In un audit ISO 27001:2022, l’auditor verifica se il SGSI opera come previsto. Ai sensi di NIS2, gli organi di gestione devono approvare e presidiare le misure di gestione del rischio di cibersicurezza. Ai sensi di DORA, gli enti finanziari devono disporre di un quadro documentato per la gestione del rischio ICT, di un ciclo di vita degli incidenti, di test di resilienza e di controlli sul rischio ICT delle terze parti. Ai sensi del GDPR, la questione diventa se misure tecniche e organizzative adeguate abbiano protetto i dati personali e se la responsabilizzazione possa essere dimostrata.

Le clausole da 4.1 a 4.4 di ISO/IEC 27001:2022 richiedono all’organizzazione di comprendere il proprio contesto, le parti interessate, i requisiti e il campo di applicazione del SGSI. La gestione delle vulnerabilità e delle patch non può essere progettata in modo isolato. Deve riflettere contratti con i clienti, autorità di regolamentazione, dipendenze cloud, servizi ICT esternalizzati, obblighi di protezione dei dati e servizi critici.

Le clausole da 6.1.1 a 6.1.3 di ISO/IEC 27001:2022 richiedono valutazione del rischio, trattamento del rischio, selezione dei controlli, una Dichiarazione di Applicabilità e l’approvazione del proprietario del rischio per il rischio residuo. Ciò significa che le evidenze sulle vulnerabilità devono collegarsi al Registro dei rischi, al piano di trattamento e alla SoA.

ISO/IEC 27005:2022 rafforza questo modello invitando le organizzazioni a consolidare i requisiti dell’Annex A, gli obblighi settoriali, le normative, i contratti, le regole interne e i controlli esistenti nella baseline di valutazione del rischio. Sottolinea inoltre i criteri relativi a probabilità, conseguenze, obblighi legali, rapporti con i fornitori, impatto sulla privacy e impatto sulle terze parti. In termini pratici, una vulnerabilità non è solo un punteggio CVSS. È un evento di rischio collegato ad asset, obblighi, stakeholder e conseguenze aziendali.

La pressione normativa dietro le evidenze sull’applicazione delle patch

La regolamentazione moderna in materia di cibersicurezza tollera sempre meno l’applicazione informale delle patch.

NIS2 si applica a molte entità medie e grandi in settori ad alta criticità e critici, e può raggiungere anche determinate entità a prescindere dalle dimensioni. Il suo ambito include fornitori di infrastrutture digitali quali servizi di cloud computing, servizi di data centre, reti di distribuzione dei contenuti, fornitori di reti pubbliche di comunicazione elettronica, servizi fiduciari, servizi DNS e TLD, nonché fornitori di gestione dei servizi ICT quali prestatori di servizi gestiti e fornitori di servizi di sicurezza gestiti. Copre inoltre importanti fornitori digitali, come marketplace online, motori di ricerca online e piattaforme di social networking.

NIS2 Article 20 attribuisce la responsabilità della cibersicurezza agli organi di gestione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione sicura, sviluppo sicuro, manutenzione sicura, trattamento e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, controllo degli accessi, gestione degli asset e autenticazione. Article 23 introduce un processo progressivo di notifica degli incidenti significativi, che include un preallarme entro 24 ore, una notifica entro 72 ore e, ove applicabile, una relazione finale entro un mese.

DORA istituisce, dal 17 gennaio 2025, un corpus di regole direttamente applicabile sulla resilienza operativa digitale per gli enti finanziari. Copre la gestione del rischio ICT, la segnalazione degli incidenti ICT rilevanti, i test di resilienza operativa, la condivisione di informazioni sulle minacce informatiche, la gestione del rischio ICT delle terze parti e la vigilanza sui fornitori terzi critici di servizi ICT. Articles 5 e 6 collocano la governance del rischio ICT sotto la responsabilità dell’organo di gestione e richiedono un quadro di gestione del rischio ICT documentato, integrato e riesaminato periodicamente. Article 8 rafforza la necessità di identificare funzioni aziendali supportate dall’ICT, patrimoni informativi, asset ICT e dipendenze. Articles 17 a 20 richiedono rilevazione, registrazione, classificazione, escalation, segnalazione, comunicazione, correzione e apprendimento per gli incidenti connessi all’ICT. Articles 28 a 30 richiedono che il rischio ICT delle terze parti sia controllato tramite registri, due diligence, misure di sicurezza contrattuali, diritto di audit, pianificazione dell’uscita e vigilanza.

Per gli enti finanziari soggetti a DORA, DORA in genere prevale sugli obblighi equivalenti di gestione del rischio e segnalazione previsti da NIS2. Tuttavia NIS2 rimane rilevante per il coordinamento dell’ecosistema e per le entità non coperte da DORA. Per i fornitori SaaS, MSP e MSSP che servono clienti finanziari, la realtà operativa è diretta: i clienti possono richiedere evidenze sulle vulnerabilità per soddisfare i propri obblighi DORA.

GDPR aggiunge un ulteriore livello. Articles 2 e 3 possono applicarsi a organizzazioni stabilite nell’UE e a organizzazioni extra-UE che offrono beni o servizi a persone nell’UE o ne monitorano il comportamento. Article 5 richiede la protezione dei dati personali e la responsabilizzazione in merito alla conformità. Article 4 definisce una violazione dei dati personali come un incidente di sicurezza che comporta perdita, distruzione, alterazione, divulgazione non autorizzata o accesso ai dati personali, in modo accidentale o illecito. Una patch rinviata su un database, una piattaforma di identità o un portale clienti può diventare una questione di accountability privacy.

Dalla policy alla prova

Il primo passo è definire le regole. Una solida policy di gestione delle vulnerabilità e delle patch non è soltanto un documento per l’audit. È la costituzione operativa del controllo.

Per gli ambienti enterprise, la Politica di gestione delle vulnerabilità e delle patch collega esplicitamente l’applicazione delle patch alla conformità trasversale:

Questa politica supporta la conformità al Controllo 8.8 dell’Annex A di ISO/IEC 27001 e alle linee guida ISO/IEC 27002 e affronta i requisiti normativi previsti da DORA Article 8, NIS2 Article 21, GDPR Article 32 e dai domini DSS e APO di COBIT 2019.

Dalla sezione “Finalità”.

La stessa politica definisce l’aspettativa di governance per l’artefatto centrale delle evidenze:

Un Registro della gestione delle vulnerabilità centralizzato deve essere mantenuto dal team delle operazioni di sicurezza e riesaminato mensilmente dal CISO o da un’autorità delegata.

Dalla sezione “Requisiti di governance”, clausola della policy 5.1.

Definisce inoltre la frequenza delle scansioni:

Tutti i sistemi devono essere sottoposti a scansione almeno mensilmente; gli asset ad alto rischio o esposti esternamente devono essere sottoposti a scansione settimanale.

Dalla sezione “Requisiti di applicazione della politica”, clausola della policy 6.1.1.

E impedisce che l’applicazione urgente delle patch diventi un’attività tecnica non controllata:

Tutte le attività di correzione devono essere coordinate tramite il processo di Gestione delle modifiche (secondo P5 - Politica di gestione dei cambiamenti) per assicurare stabilità e preservazione della traccia di audit.

Dalla sezione “Requisiti di governance”, clausola della policy 5.5.

Per le PMI, gli stessi principi di evidenza possono essere applicati in modo più semplice. La Politica di gestione delle vulnerabilità e delle patch per PMI stabilisce:

Mantenere registrazioni accurate delle patch applicate, delle problematiche aperte e delle eccezioni per assicurare la capacità di dimostrare la conformità in sede di audit

Dalla sezione “Obiettivi”, clausola della policy 3.4.

Definisce poi il registro delle patch come evidenza di audit:

Deve essere mantenuto un registro delle patch e riesaminato durante gli audit e le attività di risposta agli incidenti

Dalla sezione “Requisiti di governance”, clausola della policy 5.4.1.

E specifica il contenuto minimo:

I registri devono includere il nome del dispositivo, l’aggiornamento applicato, la data di applicazione della patch e la motivazione di eventuali ritardi

Dalla sezione “Requisiti di governance”, clausola della policy 5.4.2.

Per esposizioni urgenti verso Internet, la policy PMI stabilisce un requisito misurabile:

Le patch critiche devono essere applicate entro 3 giorni dal rilascio, in particolare per i sistemi esposti a Internet

Da Politica di gestione delle vulnerabilità e delle patch per PMI, sezione “Requisiti di applicazione della politica”, clausola della policy 6.1.1.

Queste clausole trasformano il lavoro tecnico in evidenze. La policy definisce le aspettative. Il registro documenta le risultanze. Il ticket assegna il lavoro. La registrazione della modifica controlla il rilascio. Il registro delle patch dimostra l’azione. Il Registro dei rischi registra le eccezioni. I verbali di riesame dimostrano la vigilanza.

Il modello Clarysec basato sulle evidenze

Il modello di Clarysec basato sulle evidenze parte da un principio: ogni risultanza di vulnerabilità deve essere tracciabile dalla scoperta alla decisione.

In Zenith Blueprint: una roadmap in 30 passi per l’auditor, la fase Controlli in azione, Passo 19: Controlli tecnologici I, tratta la gestione delle vulnerabilità come un controllo ripetibile, non come un requisito teorico:

Gestire le vulnerabilità è una delle aree più critiche della moderna igiene informatica. Sebbene firewall e strumenti antivirus forniscano protezione, possono essere aggirati se sistemi non aggiornati con patch o servizi configurati in modo errato restano esposti.

Lo stesso passaggio spiega che le organizzazioni devono utilizzare pianificazioni regolari di applicazione delle patch, scanner di vulnerabilità, triage, assegnazione, tracciamento della correzione, controlli compensativi e accettazione del rischio residuo. Soprattutto, inquadra correttamente la mentalità dell’audit:

Il controllo non riguarda la perfezione, ma l’esistenza di un processo organizzato, trasparente e con responsabilità attribuite.

Per gli auditor, questa distinzione è essenziale. Un’organizzazione matura può avere vulnerabilità aperte e dimostrare comunque il controllo, purché disponga di prioritizzazione basata sul rischio, titolarità documentata, eccezioni approvate, controlli compensativi e correzione verificata.

Il Zenith Blueprint avverte inoltre che gli auditor esamineranno quest’area con particolare attenzione:

Questo è un controllo ad alta priorità per gli auditor, che di norma lo approfondiscono. Aspettati domande sulla frequenza con cui i sistemi vengono aggiornati con patch, sul processo seguito quando viene annunciato uno zero-day e sui sistemi più difficili da aggiornare.

Per questo un CISO non dovrebbe presentarsi a un audit solo con un cruscotto dello scanner. Il pacchetto di evidenze deve mostrare governance, processo, esecuzione, verifica e miglioramento.

Mappare i controlli ISO 27002 alle evidenze di audit

Zenith Controls: la guida alla conformità trasversale agisce come bussola di conformità trasversale, mappando i controlli ISO/IEC 27002:2022 e mostrando il loro rapporto con le aspettative di audit. Per la gestione delle vulnerabilità e delle patch, tre controlli ISO/IEC 27002:2022 formano il triangolo operativo.

Il controllo ISO/IEC 27002:2022 8.8, Gestione delle vulnerabilità tecniche, è il controllo centrale. È preventivo, supporta riservatezza, integrità e disponibilità, si allinea ai concetti di cibersicurezza Identify e Protect e si collega alla gestione di minacce e vulnerabilità.

Il controllo ISO/IEC 27002:2022 8.32, Gestione delle modifiche, è anch’esso preventivo. Collega l’applicazione delle patch a rilascio controllato, test, approvazione, rollback e verificabilità.

Il controllo ISO/IEC 27002:2022 5.36, Conformità a politiche, regole e standard per la sicurezza delle informazioni, assicura che il processo non sia facoltativo né dipendente da iniziative individuali. Collega la gestione delle vulnerabilità alla conformità alle politiche, all’assurance e alla vigilanza.

Questa mappatura evita un fallimento comune in audit. La sicurezza dice: “L’abbiamo corretta”. Le operations dicono: “L’abbiamo distribuita”. La conformità dice: “Non possiamo dimostrare la sequenza”. Una catena di evidenze mappata fornisce ai tre team la stessa narrazione.

La catena di evidenze che gli auditor si aspettano

Una catena di evidenze sostenibile per la gestione delle vulnerabilità ha sette fasi.

La differenza pratica tra “eseguiamo scansioni” e “siamo pronti per l’audit” è la continuità. Se una vulnerabilità non può essere tracciata dalla scoperta alla chiusura, il controllo è debole. Se esistono eccezioni ma nessuno le ha approvate, il processo è debole. Se le patch bypassano la gestione delle modifiche, la traccia di audit è debole. Se vulnerabilità critiche restano aperte senza controlli compensativi, la governance è debole.

La Politica di audit e monitoraggio della conformità supporta l’automazione come parte di questo modello:

Devono essere implementati strumenti automatizzati per monitorare la conformità della configurazione, la gestione delle vulnerabilità, lo stato delle patch e gli accessi privilegiati.

Dalla sezione “Requisiti di applicazione della politica”, clausola della policy 6.4.1.

Per le PMI, la Politica di audit e monitoraggio della conformità per PMI definisce la verifica dei controlli tecnici in termini pratici:

Verifica dei controlli tecnici (ad es. stato dei backup, configurazione del controllo degli accessi, registrazioni delle patch)

Dalla sezione “Requisiti di applicazione della politica”, clausola della policy 6.1.1.2.

Le piccole organizzazioni non hanno bisogno di strumenti di livello enterprise per essere pronte per l’audit. Hanno bisogno di evidenze coerenti. Un registro leggero, un sistema di ticketing, un registro delle patch e un riesame mensile possono essere sufficienti se sono completi, aggiornati e collegati al rischio.

Esempio: una risultanza critica, pienamente pronta per l’audit

La scansione esterna settimanale di Maria identifica CVE-2026-12345 su un gateway API di pagamento esposto a Internet. Lo scanner la classifica come critica. Il servizio tratta identità dei clienti e metadati delle transazioni, quindi sono possibili implicazioni GDPR e DORA. Il gateway è di competenza di Platform Engineering, ma la patch richiede una breve indisponibilità.

Ecco il flusso pronto per l’audit.

1. Creare la voce nel registro delle vulnerabilità

Il team di sicurezza registra la risultanza nel registro centrale:

• ID risultanza: VULN-2026-0142
• Fonte: scansione esterna settimanale
• Data e ora di scoperta
• Asset: api-gw-prod-01
• Proprietario: Platform Engineering
• Esposizione: esposto a Internet
• Contesto dei dati: identità dei clienti e metadati delle transazioni
• Gravità: critica
• SLA: 72 ore o più restrittivo in base alla policy
• Ticket: SEC-4821
• Registrazione della modifica: CHG-10988
• Stato: correzione pianificata

2. Eseguire il triage usando il contesto aziendale e normativo

Il team verifica disponibilità di exploit, superficie di attacco, requisiti di autenticazione, impatto aziendale e sensibilità dei dati. Poiché il sistema è esposto a Internet e supporta un processo cliente, la vulnerabilità resta critica. Il proprietario del rischio è il responsabile della piattaforma e il CISO viene informato per le possibili implicazioni NIS2, DORA e GDPR.

Le clausole da 7.1 a 7.4 di ISO/IEC 27005:2022 supportano identificazione del rischio, titolarità, conseguenze, probabilità e prioritizzazione. Le clausole da 8.2 a 8.6 supportano selezione del trattamento, determinazione dei controlli, collegamento alla SoA, pianificazione del trattamento e approvazione del rischio residuo.

3. Aprire una modifica di emergenza controllata

La patch è pianificata per la stessa sera. La registrazione della modifica include il riferimento del fornitore, i servizi interessati, il piano di test, il piano di rollback, la finestra di manutenzione, la decisione sulla comunicazione ai clienti, le approvazioni e il requisito di convalida post-rilascio.

Questo supporta direttamente il controllo ISO/IEC 27002:2022 8.32 e il requisito della policy enterprise di coordinare la correzione tramite gestione delle modifiche.

4. Applicare la patch e aggiornare il registro delle patch

Il registro delle patch riporta il nome del dispositivo, l’aggiornamento applicato, la data di applicazione della patch e, se presente, la motivazione del ritardo. Se l’applicazione della patch fosse stata rinviata, il team documenterebbe controlli compensativi come regole di Web Application Firewall, restrizioni temporanee di accesso, aumento della registrazione, isolamento o monitoraggio rafforzato.

5. Verificare e chiudere

La sicurezza esegue una nuova scansione del gateway API. La vulnerabilità non compare più. Il ticket viene aggiornato con evidenza della scansione pulita, versione della patch, timestamp del rilascio e collegamento alla registrazione della modifica. Lo stato nel registro delle vulnerabilità passa a “Chiusa, verificata”.

6. Riesaminare l’impatto sulla segnalazione

Se non vi sono stati sfruttamento né interruzione del servizio, la segnalazione di incidenti ai sensi di NIS2 o DORA potrebbe non essere attivata. Se vengono rilevati indicatori di compromissione, il processo di gestione degli incidenti deve classificare impatto ed escalation. Ai sensi di NIS2, un incidente significativo può richiedere preallarme e segnalazione progressiva. Ai sensi di DORA, un incidente rilevante connesso all’ICT richiede classificazione e segnalazione tramite il processo dell’autorità competente applicabile.

7. Inserire le lezioni apprese nel riesame della direzione

A fine mese, il riesame del CISO annota che la vulnerabilità è stata rilevata dalla scansione esterna settimanale, corretta entro lo SLA, verificata tramite nuova scansione e chiusa senza incidente. Se problemi analoghi ricorrono, il piano di trattamento può includere baseline di configurazione sicura, applicazione automatizzata delle patch, escalation al fornitore o modernizzazione applicativa.

Quando un auditor chiede informazioni su CVE-2026-12345, Maria può presentare un pacchetto strutturato invece di email e screenshot.

Questo significa essere pronti per l’audit. Non perché l’organizzazione non avesse vulnerabilità, ma perché aveva il controllo.

Un unico set di evidenze, più obblighi

Un programma ben progettato di gestione delle vulnerabilità e delle patch può soddisfare più quadri di riferimento senza duplicare il lavoro.

Per ISO 27001:2022, le evidenze supportano il SGSI basato sul rischio, l’applicazione dei controlli dell’Annex A, la Dichiarazione di Applicabilità, i piani di trattamento del rischio, l’audit interno e il miglioramento continuo. Se il controllo ISO/IEC 27002:2022 8.8 è applicabile nella SoA, l’organizzazione deve poter mostrare la motivazione legale, normativa, di rischio o aziendale. Tale motivazione include spesso NIS2 Article 21, obblighi DORA relativi al rischio ICT, accountability GDPR, contratti con i clienti ed esigenze di resilienza operativa.

Per NIS2, le stesse evidenze aiutano a dimostrare le misure di Article 21, tra cui analisi dei rischi, trattamento delle vulnerabilità, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, igiene informatica, controllo degli accessi e valutazione dell’efficacia. Article 20 è dimostrato tramite riesame del CISO, reportistica al consiglio di amministrazione, approvazione della direzione e formazione sulla cibersicurezza. Article 23 diventa rilevante se lo sfruttamento causa, o potrebbe causare, grave interruzione operativa, perdita finanziaria o danno a terzi.

Per DORA, le evidenze sulle vulnerabilità e sulle patch supportano il quadro di gestione del rischio ICT, la vigilanza dell’organo di gestione, la strategia di resilienza, la rilevazione e classificazione degli incidenti, i test di resilienza e la vigilanza sulle terze parti ICT. Quando un fornitore ICT ospita o gestisce il sistema interessato, Articles 28 a 30 richiedono due diligence, protezioni contrattuali, diritto di audit, assistenza sugli incidenti e considerazioni di uscita.

Per GDPR, le stesse evidenze supportano l’accountability prevista da Article 5 e il livello di sicurezza atteso ai sensi di Article 32. Se una vulnerabilità determina accesso non autorizzato, alterazione, perdita o divulgazione di dati personali, la cronologia della vulnerabilità, le registrazioni delle patch, i log di monitoraggio e le note di valutazione della violazione diventano essenziali.

Per COBIT 2019 e per l’assurance in stile ISACA, la gestione delle vulnerabilità è valutata attraverso sicurezza operativa, monitoraggio dei controlli, abilitazione delle modifiche e responsabilità di governance. I riferimenti di conformità trasversale del Zenith Blueprint richiamano COBIT 2019 DSS05.04 e BAI09.02, oltre alle aspettative di assurance ITAF su gestione delle vulnerabilità, applicazione delle patch e gestione sicura delle modifiche.

Gli standard ISO di supporto rafforzano il modello operativo. ISO/IEC 27005:2022 supporta valutazione e trattamento del rischio. ISO/IEC 27035:2023 supporta la risposta agli incidenti quando le vulnerabilità vengono sfruttate. ISO/IEC 30111 supporta i processi di trattamento delle vulnerabilità. ISO/IEC 29147 supporta la divulgazione delle vulnerabilità e gli avvisi. ISO/IEC 27017 supporta la gestione delle vulnerabilità nel cloud. ISO 22301 supporta la pianificazione della continuità quando le vulnerabilità tecniche potrebbero interrompere i servizi aziendali.

Come auditor diversi verificano lo stesso processo

Valutatori diversi usano lenti diverse. Le evidenze possono essere le stesse, ma le domande cambiano.

La policy dice cosa deve accadere. Le evidenze operative mostrano cosa è accaduto. Le registrazioni dei riesami mostrano che la direzione sapeva, ha messo in discussione e ha agito.

Motivi comuni per cui la gestione delle patch fallisce un audit

La maggior parte delle risultanze non nasce dall’assenza di uno scanner. Nasce da una tracciabilità interrotta.

L’inventario degli asset è incompleto.
Se uno scanner trova asset assenti dalla CMDB o dal registro degli asset, titolarità e impatto aziendale non possono essere valutati in modo affidabile. Questo compromette campo di applicazione, valutazione del rischio e trattamento in ISO 27001:2022.

Le vulnerabilità sono tracciate solo nello scanner.
I cruscotti degli scanner non sono registri di governance. Spesso non includono approvazione del proprietario del rischio, motivazione dell’eccezione, riferimenti alle modifiche e contesto aziendale.

Le risultanze critiche non hanno evidenze di SLA.
Una policy può stabilire che le vulnerabilità critiche siano corrette entro tre giorni. La domanda in audit è se le registrazioni dimostrano che ciò è avvenuto.

Le eccezioni sono informali.
Sistemi legacy, vincoli di indisponibilità e ritardi dei fornitori accadono. Ma “non abbiamo potuto applicare la patch” deve diventare un’eccezione documentata con controlli compensativi, data di scadenza e approvazione del rischio residuo.

L’applicazione delle patch in emergenza bypassa la gestione delle modifiche.
Le modifiche di emergenza restano modifiche. Se mancano approvazione, test o evidenze di rollback, gli auditor possono concludere che la correzione ha creato rischio operativo.

I sistemi di terze parti sono invisibili.
Ai sensi di NIS2 e DORA, il rischio dei fornitori e delle terze parti ICT è centrale. Se un provider applica patch alla piattaforma, sono comunque necessarie evidenze, diritti contrattuali, reportistica di servizio e percorsi di escalation.

Nessuno riesamina le tendenze.
Vulnerabilità ricorrenti possono indicare debole gestione della configurazione, pratiche di sviluppo sicuro insufficienti, asset non supportati o fallimenti del fornitore. Il riesame mensile trasforma i dati tecnici in azione di governance.

Il pacchetto di audit Clarysec per le vulnerabilità

Per un prossimo riesame di preparazione a ISO 27001:2022, NIS2 o DORA, Clarysec aiuta le organizzazioni ad assemblare un pacchetto di audit per la gestione delle vulnerabilità e delle patch che include:

• Policy di gestione delle vulnerabilità e delle patch, inclusi ambito di applicazione, ruoli, frequenza delle scansioni, SLA delle patch e regole sulle eccezioni
• Estratto dell’inventario degli asset con sistemi in ambito, proprietari, criticità ed esposizione
• Report più recenti delle scansioni di vulnerabilità interne ed esterne
• Registro centrale della gestione delle vulnerabilità con elementi aperti, chiusi e in eccezione
• Registro delle patch che mostra dispositivo, aggiornamento, data della patch e motivazioni dei ritardi
• Registrazioni delle modifiche per campioni di vulnerabilità critiche e alte
• Evidenze di nuove scansioni o di convalida dopo la correzione
• Approvazioni di eccezioni e rischio residuo per sistemi con patch rinviata o non applicabile
• Processo di monitoraggio degli avvisi di sicurezza per fornitori, librerie e servizi cloud
• Verbali mensili di riesame del CISO o della direzione
• Matrice di raccordo verso gli obblighi ISO 27001:2022, NIS2, DORA, GDPR e COBIT 2019
• Risultati dell’audit interno o della verifica dei controlli tecnici

Nel Zenith Blueprint, fase Audit, Riesame e Miglioramento, Passo 24, Clarysec sottolinea la tracciabilità tra Dichiarazione di Applicabilità, Registro dei rischi e piano di trattamento:

La tua SoA deve essere coerente con il Registro dei rischi e il Piano di trattamento del rischio. Verifica che ogni controllo scelto come trattamento del rischio sia contrassegnato come “Applicabile” nella SoA.

Questo è particolarmente importante per la gestione delle vulnerabilità. Se il controllo 8.8 è applicabile, il pacchetto di audit deve dimostrare non solo che le scansioni vengono eseguite, ma che le risultanze sono governate tramite trattamento del rischio e miglioramento continuo.

Uno sprint di preparazione di 30 giorni

Se l’audit è vicino, non iniziare riscrivendo tutto. Inizia costruendo rapidamente le evidenze.

Questo sprint non eliminerà tutto il debito tecnico. Cambierà la conversazione in audit. Invece di difendere un export disordinato dello scanner, potrai mostrare un processo governato con proprietari, tempistiche, azioni, decisioni e vigilanza.

Passare dalle scansioni a evidenze difendibili

La preparazione agli audit per la gestione delle vulnerabilità e delle patch non consiste nel dimostrare di non avere vulnerabilità. Consiste nel dimostrare di saperle individuare, comprendere, prioritizzare, correggere, controllare tramite eccezioni e dimostrare vigilanza.

Zenith Blueprint, Zenith Controls, la Politica di gestione delle vulnerabilità e delle patch, la Politica di gestione delle vulnerabilità e delle patch per PMI, la Politica di audit e monitoraggio della conformità e la Politica di audit e monitoraggio della conformità per PMI di Clarysec forniscono la struttura per costruire quel flusso di evidenze.

Se la tua organizzazione si sta preparando alla certificazione ISO 27001:2022, alla preparazione NIS2, alla resilienza operativa digitale DORA, alla due diligence dei clienti o all’audit interno, parti da una domanda:

Ogni vulnerabilità critica può essere tracciata dalla scansione alla chiusura?

Se la risposta è no, Clarysec può aiutarti a costruire il registro, il set di policy, la mappatura della conformità trasversale, il pacchetto di riesame della direzione e il flusso di evidenze pronto per l’audit che trasforma la scansione tecnica in governance difendibile.