SLA di correzione delle vulnerabilità per NIS2 e DORA

Alle 08:17 di un martedì mattina di inizio 2026, Anna, Responsabile della sicurezza delle informazioni di una fintech in rapida crescita, riceve il primo messaggio prima ancora di finire il caffè.

Il SOC ha segnalato conversazioni su uno sfruttamento attivo relative a una vulnerabilità in un gateway API esposto ai clienti. Il team di ingegneria afferma che la patch è disponibile ma rischiosa, perché il gateway si trova davanti ai flussi di pagamento. Il Compliance Manager inoltra una richiesta formale di un’autorità nazionale competente che chiede evidenze del “trattamento e divulgazione delle vulnerabilità” e la prova che il processo sia stato efficace negli ultimi 12 mesi. L’ufficio acquisti aggiunge un terzo problema: il gateway è gestito da un MSP e il contratto si limita a dire che il provider applicherà gli “aggiornamenti di sicurezza tempestivamente”.

Alle 09:00, non si tratta più solo di applicazione delle patch. È un tema di evidenze per ISO/IEC 27001:2022, di igiene informatica NIS2, di gestione del rischio ICT DORA, di governance dei fornitori e potenzialmente di segnalazione degli incidenti se lo sfruttamento incide sulla continuità del servizio o sui dati personali.

Questa è la lacuna pratica di conformità che molte organizzazioni dovranno affrontare nel 2026. Dispongono di strumenti di scansione, dashboard, ticket e strumenti di applicazione delle patch, ma non riescono a rispondere con chiarezza alle domande di audit:

• Chi ha approvato lo SLA di correzione?
• In che modo lo SLA è basato sul rischio?
• Che cosa accade quando una patch critica supera la scadenza?
• Come vengono prioritizzati gli asset esposti a Internet?
• Come vengono vincolati i fornitori alle stesse tempistiche?
• Dov’è la registrazione dell’accettazione del rischio per un sistema non patchato?
• Quale evidenza dimostra che il controllo ha operato, e non solo che esisteva?

La risposta non è un altro foglio di calcolo con date di scadenza. Gli SLA di correzione delle vulnerabilità devono essere gestiti come un sistema di controllo vivo che collega titolarità degli asset, punteggio delle vulnerabilità, threat intelligence, gestione delle modifiche, SLA dei fornitori, gestione delle eccezioni, monitoraggio, risposta agli incidenti e riesame della direzione.

È qui che diventano utili la versione Enterprise della Politica di gestione delle vulnerabilità e delle patch (VPMP) di Clarysec, la Politica di gestione delle vulnerabilità e delle patch per PMI (VPMP-SME), la Politica di sicurezza di terze parti e fornitori per PMI (TPSSP-SME), Zenith Blueprint (ZB) e Zenith Controls (ZC). Insieme, trasformano “applicare le patch più rapidamente” in un processo di governance difendibile, in grado di reggere l’esame di audit secondo ISO, NIS2, DORA, GDPR, NIST e approcci in stile ISACA.

Perché gli SLA di correzione delle vulnerabilità sono diventati evidenze a livello di consiglio di amministrazione

La correzione delle vulnerabilità era trattata in passato come una metrica di igiene IT. Nel 2026 è molto più vicina a un impegno regolamentato di resilienza operativa.

NIS2 rende la cibersicurezza una responsabilità della direzione. I soggetti essenziali e importanti devono prevedere che gli organi di gestione approvino le misure di gestione del rischio di cibersicurezza, ne supervisionino l’attuazione e ricevano formazione per comprendere i rischi e l’impatto delle pratiche di sicurezza sui servizi. NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, trattamento degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, trattamento e divulgazione delle vulnerabilità, igiene informatica, formazione, controllo degli accessi, gestione degli asset e autenticazione.

Per gli enti finanziari, DORA è il regime specialistico di resilienza operativa. Richiede assetti di governance e controllo per il rischio ICT, con l’organo di gestione che definisce, approva, supervisiona e mantiene la responsabilità della gestione del rischio ICT. Richiede inoltre identificazione degli asset ICT e delle dipendenze, controlli di protezione e prevenzione come applicazione delle patch e gestione delle modifiche, gestione degli incidenti connessi all’ICT, test di resilienza operativa digitale e gestione del rischio ICT di terze parti.

L’impatto pratico è rilevante. Una scadenza mancata per una patch può indicare un fallimento di:

• Governance, se la direzione non ha approvato SLA basati sul rischio
• Gestione degli asset, se il proprietario del sistema interessato è sconosciuto
• Gestione delle modifiche, se l’applicazione d’emergenza delle patch non è controllata
• Gestione dei fornitori, se le tempistiche del provider sono vaghe
• Risposta agli incidenti, se gli indicatori di sfruttamento non vengono sottoposti a triage
• Gestione delle evidenze, se ticket e log non possono dimostrare la chiusura
• Trattamento del rischio, se le eccezioni non sono approvate e riesaminate

ISO/IEC 27001:2022 fornisce l’ossatura del sistema di gestione. Le clausole 4.1-4.3 richiedono alle organizzazioni di comprendere le questioni interne ed esterne, i requisiti delle parti interessate, gli obblighi legali e contrattuali e le interfacce con altre organizzazioni. Le clausole 6.1.1-6.1.3 richiedono valutazione del rischio, trattamento del rischio, Dichiarazione di applicabilità e approvazione del rischio residuo da parte del Proprietario del rischio. Le clausole 9.1, 9.2, 9.3, 10.1 e 10.2 richiedono monitoraggio, audit interno, riesame della direzione, miglioramento continuo, azione correttiva ed evidenze conservate.

In termini semplici, se si vuole che gli SLA di correzione delle vulnerabilità siano pronti per l’audit, devono far parte del SGSI, non essere solo una metrica DevOps.

Il modello di SLA che gli auditor si aspettano di vedere

Uno SLA di correzione delle vulnerabilità deve rispondere a tre domande:

1. Quanto rapidamente dobbiamo agire?
2. Chi è responsabile?
3. Quale evidenza dimostra l’esito?

La Politica di gestione delle vulnerabilità e delle patch definisce un punto di partenza pratico per tempistiche di correzione basate sul rischio:

L’organizzazione deve classificare tutte le vulnerabilità rilevate utilizzando una metodologia standardizzata (ad es. CVSS v3.x) e applicare tempistiche di correzione allineate alla criticità aziendale: 5.2.1 Critica (CVSS 9.0-10.0): riesame immediato; scadenza massima per l’applicazione della patch pari a 72 ore. 5.2.2 Alta (7.0-8.9): risposta entro 48 ore; scadenza per l’applicazione della patch pari a 7 giorni di calendario. 5.2.3 Media (4.0-6.9): risposta entro 5 giorni; scadenza per l’applicazione della patch pari a 30 giorni di calendario. 5.2.4 Bassa (<4.0): risposta entro 10 giorni; scadenza per l’applicazione della patch pari a 60 giorni di calendario.

Questa clausola è efficace perché separa il tempo di risposta dalla scadenza per l’applicazione della patch. Una vulnerabilità alta non deve rimanere invisibile per sei giorni e poi essere corretta il settimo giorno. Il tempo di risposta conferma triage, titolarità, valutazione dell’impatto e pianificazione della correzione. La scadenza per l’applicazione della patch conferma la chiusura tecnica o un’eccezione approvata.

Per le organizzazioni più piccole, la Politica di gestione delle vulnerabilità e delle patch per PMI utilizza un linguaggio più semplice ma comunque verificabile in audit:

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

E per il perimetro più ampio delle patch:

Tutte le altre patch devono essere applicate entro 30 giorni, salvo che sia documentata un’eccezione valida

Il punto non è che ogni organizzazione debba usare scadenze identiche. ISO/IEC 27001:2022, NIS2 e DORA supportano tutte il principio di proporzionalità. Il punto è che gli SLA di correzione devono essere definiti, approvati, basati sul rischio, monitorati e supportati da evidenze.

È qui che molte aziende falliscono. Definiscono lo SLA, ma non definiscono le evidenze. Dal punto di vista di un auditor, una politica senza registrazioni operative è una promessa, non un controllo.

La titolarità degli asset è la dipendenza nascosta

Uno strumento di scansione può indicare che una CVE esiste su un server. Non può dire se quel server supporta un processo di pagamento critico, archivia categorie particolari di dati personali, si connette a un provider di regolamento o è programmato per la dismissione.

Quel contesto deriva da gestione degli asset, classificazione dei dati, inventario dei fornitori e valutazione del rischio.

Il controllo 8.8 dell’Appendice A di ISO/IEC 27001:2022, Gestione delle vulnerabilità tecniche, è centrale, ma non opera da solo. Dipende in larga misura da gestione della configurazione, gestione delle modifiche, monitoraggio dei fornitori, governance cloud, logging, monitoraggio e trattamento del rischio.

NIST CSF 2.0 esprime lo stesso problema in termini di outcome. La funzione GOVERN prevede che i requisiti di cibersicurezza legali, normativi e contrattuali siano compresi e gestiti, che propensione al rischio e tolleranza al rischio siano documentate, che ruoli e risorse siano assegnati e che le politiche di cibersicurezza siano stabilite, applicate, riesaminate e aggiornate. Gli outcome IDENTIFY includono inventari di hardware, software, servizi, sistemi, dati e ciclo di vita, insieme a identificazione delle vulnerabilità, analisi dei rischi, gestione delle eccezioni e processi di divulgazione delle vulnerabilità.

Nello scenario del martedì mattina di Anna, la prima domanda tecnica è: “dov’è il componente vulnerabile?” La prima domanda di governance è: “quale servizio e quale rischio impatta?”

Zenith Blueprint, fase di gestione del rischio, Passaggio 13: pianificazione del trattamento del rischio e Dichiarazione di applicabilità, affronta questo punto collegando rischi, controlli, proprietari e tempistiche:

Inoltre, assegna un Proprietario e una Tempistica per ciascuna azione, eventualmente in una colonna separata o nei commenti. Ad es. “Proprietario: responsabile IT, Tempistica: entro il Q3 2025.” Questo lo rende un vero piano.

È esattamente ciò che richiede la correzione delle vulnerabilità. Una risultanza senza proprietario diventa rumore di backlog. Una risultanza con proprietario, tempistica, decisione di trattamento del rischio e traccia di evidenze diventa un controllo verificabile in audit.

Come Zenith Controls mappa le relazioni tra controlli

Zenith Controls tratta il controllo 8.8 di ISO/IEC 27002:2022, Gestione delle vulnerabilità tecniche, come un controllo preventivo a supporto di riservatezza, integrità e disponibilità. Lo collega ai concetti di cibersicurezza Identify e Protect, alla capacità operativa di gestione di minacce e vulnerabilità e ai domini di sicurezza governance, ecosistema, protezione e difesa.

Questo è importante perché gli SLA di correzione non sono solo un meccanismo di protezione. Sono anche un meccanismo di governance e un meccanismo di ecosistema. La vostra esposizione è determinata da fornitori, piattaforme cloud, servizi gestiti, componenti open source e dipendenze esposte a Internet.

Zenith Controls mappa il controllo 8.8 a diversi controlli di supporto:

Zenith Controls collega inoltre la gestione delle vulnerabilità a ISO/IEC 27005:2024, in particolare all’identificazione delle vulnerabilità e agli scenari di rischio che coinvolgono sistemi non patchati. Questo rafforza l’argomento secondo cui le scadenze per l’applicazione delle patch devono essere basate sul rischio, non arbitrarie. Collega inoltre il monitoraggio dei fornitori a ISO/IEC 27036-4:2016 per i livelli di sicurezza negli accordi di servizio cloud e a ISO/IEC 20000-1:2018 per la pianificazione dell’erogazione del servizio e la gestione delle modifiche.

Questa struttura trasversale agli standard conta durante l’audit. Se un’organizzazione dichiara che “le vulnerabilità critiche sono corrette entro 72 ore”, l’auditor verificherà se tale affermazione è supportata da valutazione del rischio, classificazione degli asset, obblighi dei fornitori, registrazioni delle modifiche ed evidenze di monitoraggio.

Igiene informatica NIS2: dal trattamento delle vulnerabilità all’azione correttiva

NIS2 Article 21 richiede un approccio multirischio ai sistemi di rete e informativi. Per gli SLA di correzione delle vulnerabilità, diversi elementi dell’Article 21 sono direttamente rilevanti:

• Analisi dei rischi e politiche di sicurezza dei sistemi informativi
• Trattamento degli incidenti
• Continuità operativa e gestione delle crisi
• Sicurezza della catena di fornitura
• Acquisizione, sviluppo e manutenzione sicuri, incluso trattamento e divulgazione delle vulnerabilità
• Procedure per valutare l’efficacia della cibersicurezza
• Igiene informatica di base e formazione
• Controllo degli accessi e gestione degli asset
• Autenticazione a più fattori o autenticazione continua, ove appropriato

NIS2 Article 20 rende gli organi di gestione responsabili dell’approvazione e della supervisione delle misure di gestione del rischio di cibersicurezza. Ciò significa che le metriche di correzione delle vulnerabilità non possono restare solo dentro una dashboard di ingegneria. Devono comparire nella reportistica alla direzione, nei pacchetti del comitato rischi o nelle registrazioni del riesame della direzione del SGSI.

L’Article 21 si aspetta inoltre che i soggetti che identificano una non conformità rispetto alle misure richieste adottino azioni correttive senza indebito ritardo. Questa espressione è rilevante. Se la dashboard mostra vulnerabilità critiche scadute, l’evidenza di conformità non deve fermarsi a “lo sappiamo”. Deve mostrare escalation, riesame del rischio, visibilità alla direzione, azione correttiva e rivalutazione.

NIS2 Article 23 aggiunge un’altra dimensione. Se lo sfruttamento di una vulnerabilità non corretta causa o è in grado di causare una grave interruzione operativa, perdita finanziaria o danno ad altre persone, può diventare un incidente significativo. Il ciclo di vita della segnalazione include un preallarme entro 24 ore dalla conoscenza dell’incidente significativo, una notifica dell’incidente entro 72 ore, relazioni intermedie su richiesta e una relazione finale entro un mese dalla notifica dell’incidente. Tale relazione finale deve includere gravità, impatto, probabile causa radice, mitigazioni e impatto transfrontaliero, ove applicabile.

Pertanto, il processo SLA deve collegarsi alla risposta agli incidenti. Una vulnerabilità critica con evidenze di sfruttamento attivo deve attivare triage di sicurezza, monitoraggio, conservazione delle evidenze e valutazione degli obblighi di segnalazione, non solo un ticket ordinario di applicazione patch.

Rischio ICT DORA: le tempistiche di correzione come evidenza di resilienza

Per gli enti finanziari, DORA si applica dal 17 gennaio 2025 e crea requisiti uniformi in materia di gestione del rischio ICT, segnalazione degli incidenti gravi connessi all’ICT, test di resilienza operativa digitale, condivisione delle informazioni e gestione del rischio ICT di terze parti. È trattato come l’atto giuridico settoriale specifico dell’UE per gli enti finanziari coperti individuati dalle norme nazionali NIS2.

Il modello operativo di DORA è vicino a un SGSI integrato. Gli Articles 5 e 6 richiedono governance, politiche, procedure, strumenti, riesame annuale o periodico, audit, correzione delle risultanze critiche dell’audit e una strategia di resilienza operativa digitale. L’Article 8 richiede identificazione e inventario di funzioni aziendali supportate dall’ICT, asset informativi, asset ICT, dipendenze, processi di terze parti e rischi ICT legacy. L’Article 9 richiede controlli di protezione e prevenzione, incluse applicazione delle patch e gestione delle modifiche. Gli Articles 11 e 12 richiedono continuità, risposta, ripristino, backup, restore e obiettivi di ripristino.

Gli Articles 17-19 di DORA richiedono un processo di gestione degli incidenti connessi all’ICT che rilevi, gestisca, registri, classifichi, effettui escalation, segnali, comunichi, analizzi la causa radice e ripristini operazioni sicure. Gli Articles 24-26 richiedono test di resilienza operativa digitale, inclusi test appropriati di strumenti e sistemi ICT, valutazioni delle vulnerabilità, valutazioni della sicurezza della rete, analisi delle lacune, riesami del codice sorgente ove fattibile, test di penetrazione e test di penetrazione guidati dalle minacce per determinati enti finanziari. Gli Articles 28 e 30 richiedono gestione del rischio ICT di terze parti, registri dei contratti di servizi ICT, due diligence, diritto di audit e ispezione, livelli di servizio, assistenza del provider durante gli incidenti, diritti di risoluzione e disposizioni di uscita.

Per gli SLA di correzione, DORA modifica le aspettative sulle evidenze in tre modi.

Primo, le risultanze di vulnerabilità derivanti dai test devono alimentare un processo di correzione prioritizzato. Un report di scansione non è sufficiente.

Secondo, la correzione delle risultanze critiche deve essere tracciata attraverso governance e audit. DORA si aspetta la correzione formale delle risultanze critiche dell’audit per le imprese non micro.

Terzo, i fornitori ICT terzi devono essere vincolati a obblighi misurabili. Se il vostro provider cloud, SaaS o MSP controlla la finestra di applicazione patch, il contratto e il registro devono mostrare come le sue tempistiche di correzione supportano i vostri obblighi di resilienza.

La Politica di gestione delle vulnerabilità e delle patch affronta direttamente questo punto:

Applicazione delle patch da parte di terze parti e vigilanza sul rischio SaaS 6.6.1 Tutti i sistemi di terze parti (SaaS, PaaS, gestiti da MSP) devono dimostrare controlli adeguati di gestione delle vulnerabilità e delle patch. 6.6.2 Gli SLA dei fornitori devono includere tempi di correzione equivalenti alle soglie definite internamente e basate sulla criticità.

Questa clausola è spesso il ponte mancante tra le evidenze ISO interne e la vigilanza sui fornitori richiesta da DORA.

GDPR: quando i ritardi nelle patch diventano carenze di accountability sui dati personali

GDPR non è uno standard di gestione delle vulnerabilità, ma modifica le conseguenze di un fallimento nell’applicazione delle patch.

GDPR Article 5 richiede che i dati personali siano trattati in modo sicuro e che il titolare del trattamento sia in grado di dimostrare la conformità. GDPR Article 32 richiede misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio. Quando sistemi non patchati trattano dati personali, in particolare dati di identità, dati finanziari, dati biometrici, dati sanitari, dati relativi al rapporto di lavoro o informazioni KYC, gli SLA di correzione diventano parte dell’accountability sulla sicurezza del trattamento.

Un ritardo nell’applicazione di una patch può essere difendibile se il rischio è stato valutato, sono stati applicati controlli compensativi e il rischio residuo è stato accettato dalla persona corretta. È molto più difficile difenderlo se la vulnerabilità era scaduta, esposta a Internet e senza proprietario.

Zenith Controls mappa la gestione delle vulnerabilità agli Articles 32 e 5(1)(f) del GDPR, perché l’applicazione tempestiva delle patch riduce i rischi per riservatezza e integrità dei dati personali. Mappa inoltre la gestione delle modifiche al GDPR Article 24 e all’Article 32, perché le modifiche ai sistemi che trattano dati personali devono essere valutate in base al rischio, approvate, documentate e riesaminate.

La lezione di conformità è semplice: se sono coinvolti dati personali, le evidenze di applicazione delle patch devono includere il contesto dei dati. Auditor e autorità di regolamentazione non chiederanno solo “è stata applicata la patch?”, ma anche “quali dati sono stati esposti al rischio, per quanto tempo e quali controlli hanno ridotto tale rischio?”

Un flusso di lavoro Clarysec pratico per evidenze SLA pronte per l’audit

Un processo maturo di correzione delle vulnerabilità non inizia quando un auditor chiede le registrazioni. È progettato per produrre registrazioni ogni mese.

Passaggio 1: approvare la politica SLA

Inizia con la Politica di gestione delle vulnerabilità e delle patch o con la Politica di gestione delle vulnerabilità e delle patch per PMI, a seconda del modello operativo. Adatta le soglie SLA alla propensione al rischio, all’ambito normativo, alla criticità dei servizi, alla sensibilità dei dati e ai vincoli tecnici. Assicura l’approvazione da parte del CISO, del comitato rischi o dell’organo di gestione.

Per gli ambienti enterprise, usa CVSS, criticità degli asset, sfruttabilità, esposizione a Internet, sensibilità dei dati e impatto aziendale. Per le PMI, mantieni il modello semplice ma esplicito: patch critiche entro tre giorni, altre patch entro 30 giorni salvo eccezione valida.

Passaggio 2: mappare gli asset a proprietari e servizi critici

Ogni risultanza di vulnerabilità deve ricondursi a:

• Nome dell’asset e identificativo univoco
• Servizio aziendale o applicazione
• Proprietario del sistema
• Proprietario tecnico
• Classificazione dei dati
• Esposizione a Internet
• Dipendenza da fornitore, se applicabile
• Criticità della funzione supportata

Questo supporta la titolarità del rischio secondo ISO/IEC 27001:2022, la gestione degli asset NIS2, l’inventario DORA di asset e dipendenze ICT e gli outcome IDENTIFY di NIST CSF.

Passaggio 3: eseguire il triage della vulnerabilità

Crea un ticket per ciascuna risultanza o gruppo di risultanze. Includi punteggio CVSS, strumento di scansione di origine, asset interessato, stato di exploit, threat intelligence, criticità aziendale e SLA richiesto. Se si sospetta sfruttamento, collega il ticket a una valutazione dell’incidente.

Passaggio 4: eseguire tramite gestione delle modifiche

L’applicazione delle patch è una modifica. Usa la modifica standard per gli aggiornamenti ordinari e la modifica di emergenza per vulnerabilità critiche sfruttate. Includi evidenze di test, approvazione, marcatura temporale dell’attuazione, piano di rollback e convalida post-modifica.

Questo corrisponde alla relazione indicata da Zenith Controls tra 8.8 e 8.32, in cui l’applicazione delle patch è governata tramite gestione delle modifiche per bilanciare urgenza e stabilità operativa.

Passaggio 5: convalidare la chiusura

Non chiudere i ticket solo sulla base di “patch installata”. Richiedi convalida tramite nuova scansione, conferma della versione, verifica della configurazione o conferma dei controlli compensativi. Quando la patch non può essere applicata, apri un’eccezione.

Passaggio 6: registrare eccezioni e rischio residuo

La Politica di gestione delle vulnerabilità e delle patch definisce il contenuto richiesto per le eccezioni:

Le richieste di eccezione devono includere: 7.2.1 giustificazione aziendale del ritardo o della mancata correzione 7.2.2 valutazione del rischio (basata su CVSS, criticità dell’asset, threat intelligence) 7.2.3 controlli compensativi proposti 7.2.4 tempistica per correzione o rivalutazione

Definisce inoltre approvazione e riesame:

Le eccezioni devono essere approvate dal CISO o dal comitato rischi delegato e registrate nel Registro delle eccezioni del SGSI, con un intervallo di riesame non superiore a 90 giorni.

Quel registro delle eccezioni diventa evidenza essenziale per il trattamento del rischio e l’accettazione del rischio residuo ai sensi della Clause 6.1.3 di ISO/IEC 27001:2022, nonché per il riesame della direzione.

Questa registrazione dimostra che l’organizzazione non ha ignorato la vulnerabilità. Ha valutato il rischio, applicato controlli compensativi, approvato il rischio residuo e fissato una data di riesame.

Passaggio 7: costruire il pacchetto mensile di evidenze

Il pacchetto mensile di evidenze per la correzione delle vulnerabilità deve includere:

Per le PMI, le evidenze possono essere più leggere, ma devono comunque essere coerenti. La Politica di gestione delle vulnerabilità e delle patch per PMI richiede log delle patch con tracciabilità:

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

Questa singola clausola ha un valore elevatissimo in audit. Trasforma l’applicazione delle patch da un’affermazione a una registrazione.

Applicazione delle patch da parte dei fornitori: il contratto deve corrispondere al vostro SLA

Se un MSP, un provider SaaS, un provider PaaS o un fornitore di servizi cloud controlla la distribuzione delle patch, gli SLA interni sono inutili se gli obblighi dei fornitori non sono allineati.

La Politica di sicurezza di terze parti e fornitori per PMI include obblighi di sicurezza delle informazioni come requisito di governance. Per la correzione delle vulnerabilità, tali obblighi devono diventare linguaggio contrattuale misurabile:

• Finestre di notifica per vulnerabilità critiche
• Tempistiche di correzione per vulnerabilità critiche, alte, medie e basse
• Processo di modifica di emergenza
• Requisiti di approvazione del cliente per il downtime
• Formato delle evidenze di completamento delle patch
• Processo di divulgazione delle vulnerabilità
• Obblighi di assistenza in caso di incidente
• Diritto di audit o di ricevere report di assurance
• Obblighi di applicazione patch di sub-responsabili o subappaltatori
• Supporto all’uscita e alla transizione per servizi critici

Zenith Blueprint, fase Controlli in azione, Passaggio 20, controllo 8.21 Sicurezza dei servizi di rete, enuncia chiaramente il principio:

Quando i servizi sono forniti esternamente, inclusi ISP, fornitori SD-WAN o provider di cloud privato, i requisiti di sicurezza devono essere inseriti nei contratti e negli SLA. Ciò include garanzie di disponibilità operativa, tempi di risposta agli incidenti, obblighi di applicazione delle patch o di mitigazione delle vulnerabilità e confini chiari per la gestione dei dati. Non si deve mai presumere che un provider soddisfi le aspettative se ciò non è scritto, misurabile e verificabile in audit.

DORA rende questo aspetto particolarmente importante per gli enti finanziari. Gli accordi con terze parti ICT devono includere livelli di servizio, assistenza del provider durante gli incidenti ICT, accesso e ripristino dei dati, cooperazione con le autorità, diritti di risoluzione e disposizioni più stringenti per funzioni critiche o importanti, inclusi monitoraggio, diritti di audit, piani di contingenza e misure di sicurezza.

NIST CSF 2.0 afferma lo stesso principio attraverso gli outcome di rischio della catena di fornitura: i fornitori devono essere noti, prioritizzati in base alla criticità, valutati prima dell’incarico, governati da requisiti contrattuali, monitorati per tutta la durata del rapporto, inclusi nella pianificazione degli incidenti e gestiti alla cessazione.

Che cosa chiederanno davvero gli auditor

La conversazione di audit cambia in funzione del background dell’auditor.

Un auditor ISO/IEC 27001:2022 partirà dal SGSI. Verificherà se la gestione delle vulnerabilità è inclusa nella Dichiarazione di applicabilità, se la valutazione del rischio identifica i sistemi non patchati come rischio, se i piani di trattamento del rischio hanno proprietari e tempistiche, se il controllo 8.8 dell’Appendice A è applicato, se le evidenze sono conservate e se audit interno e riesame della direzione valutano le prestazioni.

Zenith Blueprint, fase Controlli in azione, Passaggio 19, rende esplicita l’aspettativa di audit:

Questo è un controllo ad alta priorità per gli auditor e di norma sarà analizzato in profondità. Aspettati domande sulla frequenza di applicazione delle patch ai sistemi, sul processo seguito quando viene annunciata una zero-day e sui sistemi più difficili da patchare.

Prosegue con aspettative pratiche sulle evidenze:

Gli auditor probabilmente richiederanno i risultati delle scansioni di vulnerabilità. Se si utilizzano strumenti come Nessus, OpenVAS o Qualys, esporta un report che mostri le vulnerabilità recenti rilevate e come sono state affrontate. Idealmente, deve includere classificazioni di rischio (CVSS) e tempistiche di correzione.

Un auditor o un’autorità competente focalizzati su NIS2 cercheranno approvazione del consiglio di amministrazione, proporzionalità, igiene informatica, trattamento delle vulnerabilità, sicurezza dei fornitori, trattamento degli incidenti, valutazione dell’efficacia, azione correttiva senza indebito ritardo e registrazioni delle decisioni di segnalazione se lo sfruttamento ha causato un impatto significativo.

Un supervisore DORA verificherà se le risultanze sulle vulnerabilità sono integrate nella gestione del rischio ICT, nei test di resilienza operativa digitale, nella classificazione degli incidenti, nell’analisi della causa radice, nei registri delle terze parti, negli obblighi contrattuali, nei diritti di audit e nella correzione delle risultanze critiche.

Un valutatore NIST CSF organizzerà probabilmente il riesame intorno a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. Chiederà se i requisiti legali e contrattuali sono compresi, se la tolleranza al rischio è documentata, se le vulnerabilità sono identificate e prioritizzate, se le eccezioni sono gestite, se il monitoraggio rileva lo sfruttamento e se le azioni di risposta e ripristino sono coordinate.

Un auditor COBIT 2019 o in stile ISACA si concentrerà su obiettivi di governance, capacità di processo, prassi di gestione, metriche, titolarità, progettazione dei controlli, operatività dei controlli e sufficienza delle evidenze. Chiederà se la correzione delle vulnerabilità è ripetibile, misurata, soggetta a escalation, migliorata e allineata agli obiettivi aziendali e alla propensione al rischio.

Escalation e metriche: come dimostrare che lo SLA è gestito

Uno SLA senza escalation è solo un obiettivo. Un programma di correzione delle vulnerabilità difendibile richiede escalation prima della violazione, al momento della violazione e dopo fallimenti ripetuti.

Clarysec raccomanda un modello di escalation a quattro livelli:

1. Escalation operativa, il titolare del ticket e il responsabile tecnico sono avvisati prima della violazione.
2. Escalation del rischio, il Proprietario dell’asset e il Proprietario del rischio riesaminano l’impatto quando la violazione è probabile.
3. Escalation della governance della sicurezza, il CISO o il comitato rischi approva l’eccezione o l’azione d’emergenza.
4. Escalation alla direzione, violazioni SLA ripetute o critiche sono riportate nel riesame della direzione con azioni correttive.

La Politica di gestione delle vulnerabilità e delle patch rafforza questa aspettativa di audit:

Devono essere condotti audit periodici dall’audit interno o da una terza parte indipendente per verificare: 5.6.1 Conformità agli SLA 5.6.2 Evidenza della prioritizzazione basata sul rischio 5.6.3 Efficacia delle patch distribuite 5.6.4 Controlli sui sistemi non patchati

Le metriche devono supportare le decisioni, non decorare le dashboard. Le metriche più solide per il 2026 includono:

• Percentuale di conformità allo SLA critico
• Percentuale di conformità allo SLA alto
• Tempo medio di triage
• Tempo medio di correzione per classe di asset
• Numero di vulnerabilità critiche scadute
• Numero di eccezioni accettate per anzianità
• Eccezioni oltre 90 giorni
• Conteggio delle esposizioni critiche rivolte a Internet
• Violazioni degli SLA dei fornitori
• Vulnerabilità riaperte dopo la convalida
• Modifiche di emergenza causate da vulnerabilità sfruttate
• Fallimenti delle patch per piattaforma o unità aziendale

Collega queste metriche alla Clause 9.3 di ISO/IEC 27001:2022 sul riesame della direzione, alla reportistica di governance DORA e alla supervisione della direzione prevista da NIS2. Per NIST CSF 2.0, usale per aggiornare profili attuali e target, analisi delle lacune e piani d’azione.

La checklist Clarysec per gli SLA di correzione

Usa questa checklist per valutare il programma attuale:

• Esiste una politica approvata di gestione delle vulnerabilità e delle patch?
• Gli SLA di correzione sono definiti per gravità e criticità aziendale?
• Le vulnerabilità esposte a Internet e sfruttate sono accelerate?
• Gli asset sono mappati a proprietari, servizi, dati e fornitori?
• Le risultanze degli strumenti di scansione vengono convertite in ticket assegnati?
• Le patch vengono eseguite tramite gestione delle modifiche?
• Le modifiche di emergenza sono documentate e riesaminate?
• I risultati della correzione sono convalidati tramite nuove scansioni o controlli di versione?
• Le eccezioni sono valutate in base al rischio, approvate e riesaminate almeno ogni 90 giorni?
• I controlli compensativi sono documentati per i sistemi non patchabili?
• I contratti con i fornitori sono allineati alle soglie interne di correzione?
• I log delle patch sono sufficientemente completi da dimostrare che cosa è accaduto e quando?
• Le violazioni degli SLA sono soggette a escalation e corrette?
• Le metriche sono riesaminate dalla direzione?
• Incidenti e valutazioni di violazione vengono attivati quando si sospetta sfruttamento?

Se diverse risposte sono “no”, il problema non è lo strumento. È la progettazione del controllo.

Prossimi passi: trasformare le scadenze delle patch in resilienza pronta per l’audit

Gli SLA di correzione delle vulnerabilità nel 2026 devono fare più che soddisfare una dashboard di scansione. Devono dimostrare che l’organizzazione è in grado di identificare l’esposizione, prioritizzare il rischio, agire entro tempistiche approvate, controllare le eccezioni, governare i fornitori e documentare con evidenze le decisioni rispetto alle aspettative di audit di ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Clarysec può aiutarti a passare da ticket di applicazione patch frammentati a un programma integrato di correzione delle vulnerabilità basato sulle evidenze, utilizzando:

• Politica di gestione delle vulnerabilità e delle patch
• Politica di gestione delle vulnerabilità e delle patch per PMI
• Politica di sicurezza di terze parti e fornitori per PMI
• Zenith Blueprint: roadmap in 30 passi per auditor
• Zenith Controls: guida alla conformità trasversale

Inizia da un servizio ad alto rischio. Mappane asset, fornitori, vulnerabilità, ticket, modifiche, eccezioni ed evidenze. Poi applica a quel servizio le domande di audit. Se non riesci a dimostrare lo SLA dalla rilevazione alla chiusura, quello è il primo progetto di correzione.

L’obiettivo non è applicare le patch in modo perfetto. L’obiettivo è una correzione governata, basata sul rischio, misurabile e verificabile in audit. Scarica i template delle politiche Clarysec, esegui una valutazione mirata delle lacune o prenota una demo Clarysec per trasformare la correzione delle vulnerabilità da pressione di audit a resilienza operativa.