Condivisione della cyber threat intelligence con ISO 27001 nel 2026

Alle 07:40 di un martedì mattina, Maria, Responsabile della sicurezza delle informazioni (CISO) di una piattaforma europea di pagamenti in rapida crescita, riceve da un ISAC dei servizi finanziari un bollettino ad alta attendibilità. Una campagna di furto di credenziali sta prendendo di mira prestatori di servizi di pagamento che utilizzano una specifica integrazione con un provider di identità. L’avviso include domini command-and-control, nomi sospetti di applicazioni OAuth, stringhe user-agent, tattiche osservate e la raccomandazione di ruotare i segreti per i tenant interessati.

Nel giro di pochi minuti, l’organizzazione inizia a porsi le domande che definiscono la condivisione della cyber threat intelligence nel 2026.

Il SOC vuole inserire immediatamente gli indicatori nel SIEM. La funzione legale chiede se l’azienda possa condividere la propria telemetria con l’ISAC. Il Responsabile della protezione dei dati (DPO) chiede se indirizzi IP, nomi utente, estratti di ticket, log di autenticazione o dettagli degli endpoint includano dati personali. Il direttore operativo (COO) vuole sapere se i clienti debbano essere avvisati. L’amministratore delegato, reduce dalla formazione NIS2 per il management, inoltra l’allerta con due parole: “Il nostro piano?”

Poi il Compliance Manager pone la domanda più importante: “Se l’autorità di supervisione ce lo chiedesse il mese prossimo, potremmo dimostrare che la nostra condivisione della cyber threat intelligence è stata lecita, approvata, utile e controllata?”

Questa è la nuova realtà. DORA è passata dalla scadenza di attuazione alla verifica da parte delle autorità di supervisione. NIS2 è passata dai progetti di preparazione alla cooperazione operativa. GDPR continua ad applicarsi, anche quando i dati sono telemetria di sicurezza. La condivisione della threat intelligence non è più uno scambio informale su Slack tra team di sicurezza. È un’attività governata che coinvolge riservatezza, minimizzazione dei dati personali, approvazioni alla divulgazione, registrazioni, aspettative delle autorità di regolamentazione ed evidenze di audit.

Per CISO, Compliance Manager, auditor e responsabili di business, il punto non è se partecipare ad accordi di condivisione della cyber threat intelligence. Il vero punto è come condividere con rapidità sufficiente ad aiutare i difensori, prevenendo al contempo divulgazioni illecite, violazioni della riservatezza dei clienti, perdite di informazioni concorrenzialmente sensibili, pubblicazione non gestita di vulnerabilità ed evidenze deboli.

ISO/IEC 27001:2022 è la dorsale di governance che rende possibile tutto questo. Non come certificato appeso alla parete, ma come sistema di gestione che trasforma la condivisione della cyber threat intelligence in un modello operativo ripetibile, difendibile e conforme al GDPR.

Perché la condivisione della cyber threat intelligence è cambiata nel 2026

La prima ondata di preparazione a DORA e NIS2 si è concentrata su campo di applicazione, tempistiche di segnalazione degli incidenti, rischio ICT di terze parti, responsabilità dell’organo amministrativo e gap assessment. Quel lavoro era necessario, ma autorità di regolamentazione e clienti stanno ora ponendo domande più operative:

• A quali ISAC, CERT, CSIRT, forum di fornitori o comunità fidate partecipate?
• Chi è autorizzato a rappresentare l’organizzazione verso l’esterno?
• Come decidete cosa può essere condiviso?
• Come impedite la divulgazione di dati personali, segreti dei clienti, dettagli sulle vulnerabilità e architetture sensibili?
• In che modo gli input di threat intelligence aggiornano regole di monitoraggio, priorità di patching, registri dei rischi, playbook di risposta agli incidenti, riesami dei fornitori e test di resilienza?
• Dove sono le evidenze?

DORA è particolarmente diretto per gli enti finanziari. Considera la resilienza operativa digitale come un sistema di gestione del rischio ICT di responsabilità dell’organo amministrativo, non come una checklist IT. DORA si applica dal 17 gennaio 2025; pertanto, nel 2026 molti enti finanziari vengono valutati sulla concreta operatività dei loro processi.

DORA Article 45 consente la condivisione di informazioni e intelligence sulle minacce informatiche tra enti finanziari quando la finalità è rafforzare la resilienza operativa digitale. La condivisione dovrebbe avvenire all’interno di comunità fidate e nell’ambito di accordi che proteggano informazioni aziendali sensibili, dati personali, riservatezza, proprietà intellettuale e limiti del diritto della concorrenza. In termini semplici, DORA non significa “condividere tutto”. Significa “condividere in modo sicuro, deliberato e in condizioni controllate”.

NIS2 crea una pressione analoga al di fuori del settore finanziario. Si applica a molte entità essenziali e importanti in settori ad alta criticità e in altri settori critici, tra cui infrastrutture digitali, prestatori di servizi gestiti, prestatori di servizi di sicurezza gestiti, fornitori di servizi di cloud computing, fornitori di data center, marketplace online, motori di ricerca online, piattaforme di social network, settore bancario e infrastrutture dei mercati finanziari. NIS2 Article 20 rende gli organi di gestione responsabili dell’approvazione delle misure di gestione del rischio di cibersicurezza, della supervisione della loro attuazione e della formazione. 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, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset, MFA e comunicazioni sicure. Article 23 richiede una segnalazione per fasi degli incidenti significativi, inclusi un preallarme entro 24 ore, una notifica dell’incidente entro 72 ore e una relazione finale non oltre un mese dalla notifica dell’incidente.

GDPR aggiunge il vincolo privacy. I dati personali includono qualsiasi informazione relativa a una persona fisica identificata o identificabile. Log di sicurezza, indirizzi IP, nomi utente, indirizzi e-mail, nomi degli endpoint, eventi di autenticazione, ticket di supporto, campioni di malware, screenshot e note di indagini antifrode possono tutti diventare dati personali. GDPR richiede un trattamento lecito, corretto, trasparente, limitato alla finalità, minimizzato, accurato, limitato nella conservazione e sicuro. Richiede inoltre accountability, cioè la capacità dell’organizzazione di dimostrare la conformità.

Il risultato è un problema di governance. La condivisione della threat intelligence deve essere abbastanza rapida da migliorare la difesa, abbastanza controllata da soddisfare le autorità di supervisione e abbastanza disciplinata da evitare violazioni della privacy e della riservatezza.

ISO 27001 come hub di conformità per la condivisione della threat intelligence

ISO/IEC 27001:2022 è particolarmente adatto a questa sfida perché parte da contesto, parti interessate, campo di applicazione, rischio, leadership, controllo operativo, monitoraggio, audit interno, Riesame della direzione e Miglioramento continuo.

Le clausole da 4.1 a 4.4 richiedono alle organizzazioni di comprendere le questioni interne ed esterne, identificare le parti interessate e i loro requisiti, definire il campo di applicazione del SGSI e mantenere il sistema di gestione. Per un’organizzazione soggetta a DORA o NIS2, le parti interessate possono includere autorità competenti, CSIRT, clienti, fornitori ICT, ISAC, gruppi settoriali, responsabili del trattamento, titolari del trattamento, assicuratori, audit interno e organo amministrativo.

Le clausole da 5.1 a 5.3 richiedono impegno della leadership, indirizzo di policy, accountability, risorse e responsabilità assegnate. Questo è importante perché la condivisione della threat intelligence fallisce quando viene lasciata alla discrezionalità tecnica informale. Se l’analista SOC, il consulente legale, il DPO, il CISO, il responsabile della comunicazione e il responsabile di business applicano presupposti diversi, l’organizzazione finirà per condividere troppo, bloccarsi o rispondere troppo tardi.

Le clausole da 6.1.1 a 6.1.3 trasformano la questione regolatoria in valutazione del rischio, trattamento del rischio, selezione dei controlli, decisioni della Dichiarazione di Applicabilità, piani di trattamento del rischio e accettazione del rischio residuo. I rischi tipici della condivisione della threat intelligence includono:

• Dati personali condivisi senza una base giuridica o senza minimizzazione.
• Informazioni riservate dei clienti divulgate in un forum.
• Dettagli sulle vulnerabilità pubblicati prima che sia disponibile una mitigazione.
• Indicatori acquisiti ma mai tradotti in azioni operative.
• Partecipazione a ISAC non riflessa in risposta agli incidenti, logging, Gestione delle vulnerabilità o rischio dei fornitori.
• Mancanza di evidenze su chi ha approvato la divulgazione e perché.
• Rischio in materia di concorrenza derivante dalla condivisione di informazioni di mercato commercialmente sensibili.
• Comunicazioni regolatorie e verso i clienti incoerenti durante un incidente significativo.

La clausola 8.1 richiede poi che i processi pianificati siano attuati e controllati, con informazioni documentate sufficienti a dimostrare che i processi hanno operato come previsto. Le clausole 9 e 10 richiedono monitoraggio, misurazione, audit interno, Riesame della direzione, gestione delle non conformità, azione correttiva e Miglioramento continuo. In sintesi, ISO/IEC 27001:2022 trasforma la condivisione della cyber threat intelligence in un modello operativo verificabile in audit.

I due controlli ISO che rendono efficace la condivisione

La Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint di Clarysec tratta questo tema come parte della fase Controls in Action, Step 22: Controlli organizzativi. Due controlli di ISO/IEC 27002:2022 sono centrali: 5.6, Contatto con gruppi di interesse speciale, e 5.7, Threat intelligence.

La Zenith Blueprint chiarisce che la partecipazione a un ISAC non è networking simbolico:

La partecipazione a tali gruppi non è un gesto simbolico. È un investimento strategico in intelligence, collaborazione e resilienza condivisa.

Per il controllo 5.6, i gruppi di interesse speciale possono includere reti nazionali o settoriali di cyber threat intelligence, ISAC, forum regolatori, gruppi consultivi di sicurezza dei fornitori, comunità open source e gruppi di lavoro accademici. Tuttavia, la condivisione esterna deve essere intenzionale, lecita e autorizzata. La Zenith Blueprint aggiunge l’aspettativa di maturità:

Le implementazioni mature del SGSI trattano la partecipazione ai SIG come un’attività governata, non come un beneficio informale.

Ciò significa mantenere un registro dei gruppi e dei forum a cui si aderisce, designare partecipanti ufficiali, acquisire verbali o sintesi e integrare gli insight nei riesami interni o negli aggiornamenti dei controlli.

Il controllo 5.7 trasforma le informazioni esterne in azione. La Zenith Blueprint afferma:

Un’organizzazione non può difendersi da ciò che non comprende.

Avverte inoltre di non confondere i feed di patch con la threat intelligence. La vera intelligence include profilazione degli attori della minaccia, tattiche, tecniche e procedure, indicatori di compromissione, avvisi specifici di settore, contesto delle vulnerabilità e impatto strategico sul business. Un’intelligence utile combina monitoraggio interno, partnership esterne, rapporti con CERT o ISAC, feed commerciali e fonti open source, ma solo quando qualcuno la riesamina, la prioritizza e la traduce in azione.

La Zenith Controls: The Cross-Compliance Guide Zenith Controls di Clarysec rafforza il valore per la conformità trasversale. Mappa il controllo 5.6 come preventivo e correttivo, a supporto di Riservatezza, Integrità e Disponibilità, con la governance come principale capacità operativa. Collega 5.6 a 5.7 Threat intelligence, 5.5 Contatto con le autorità, 5.31 Requisiti legali, statutari, regolamentari e contrattuali e 8.8 Gestione delle vulnerabilità tecniche. Mappa 5.7 come preventivo, di rilevazione e correttivo, collegato a Identify, Detect e Respond, con capacità operativa nella gestione di minacce e vulnerabilità.

Il messaggio è semplice: un programma maturo di condivisione della cyber threat intelligence ha due componenti. Primo, relazioni controllate. Secondo, uso controllato di ciò che viene ricevuto e condiviso.

Un modello operativo pratico per una condivisione governata

Un modello operativo difendibile nel 2026 dovrebbe rispondere a sei domande prima che venga condiviso il primo indicatore.

Clarysec lo implementa normalmente come flusso di lavoro leggero ma formale:

1. Acquisire e classificare l’intelligence.
2. Validarne la rilevanza rispetto ad asset, fornitori, servizi, aree geografiche e clienti.
3. Convertire l’intelligence in azioni, quali regole di monitoraggio, ticket di vulnerabilità, allerte agli utenti, richieste ai fornitori o aggiornamenti dei rischi.
4. Decidere se la condivisione in uscita sia necessaria, lecita, sicura e consentita dalle regole di adesione.
5. Applicare oscuramento, aggregazione, pseudonimizzazione o anonimizzazione.
6. Ottenere le approvazioni richieste.
7. Condividere tramite un canale approvato.
8. Registrare cosa è stato condiviso, con chi, perché, quando e sotto quale autorità.
9. Riesaminare gli esiti e aggiornare i controlli.

Questo previene i due fallimenti classici: il team di sicurezza riceve intelligence utile ma nulla cambia, oppure il team di sicurezza condivide intelligence utile ma crea esposizione legale, contrattuale o privacy.

DORA Article 45: condivisione controllata senza perdere riservatezza

Per gli enti finanziari, DORA Article 45 dovrebbe essere tradotto in uno standard interno di condivisione della cyber threat intelligence. Un’interpretazione pratica include cinque condizioni.

Primo, la finalità deve essere la resilienza. La condivisione dovrebbe aiutare a prevenire, rilevare, rispondere o ripristinare rispetto alle minacce informatiche. Non dovrebbe sconfinare in prezzi, elenchi clienti, strategie di mercato o intelligence commercialmente sensibile.

Secondo, la comunità deve essere fidata. Ciò significa regole di adesione chiare, obblighi di riservatezza, canali sicuri, controlli di accesso e limiti all’ulteriore divulgazione. ISO/IEC 27010:2015 supporta lo scambio sicuro di informazioni in comunità fidate, incluse regole di riservatezza, reciprocità e canali di comunicazione fidati. ISO/IEC 27032:2023 supporta la condivisione di informazioni di cibersicurezza e la consapevolezza situazionale. ISO/IEC 27035-2:2023 collega la condivisione di informazioni alla pianificazione della risposta agli incidenti, inclusa la partecipazione a CERT e gruppi di settore.

Terzo, le informazioni sensibili devono essere protette. Questo include segreti commerciali, diagrammi architetturali, dettagli sulle vulnerabilità, credenziali, identificativi dei clienti e dati personali. La Politica di classificazione ed etichettatura dei dati per SME di Clarysec Data Classification and Labeling Policy - SME afferma:

La condivisione esterna deve essere esplicitamente autorizzata e registrata.

Questa frase è il principio di controllo alla base di un flusso per DORA Article 45. L’organizzazione deve sapere quale classificazione si applica, chi ha approvato il rilascio e dove è conservata la registrazione.

Quarto, i dati personali devono essere minimizzati. La Politica di protezione dei dati e privacy enterprise Data Protection and Privacy Policy afferma:

Possono essere raccolti e trattati solo i dati necessari per una finalità aziendale specifica e legittima.

L’equivalente SME, Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME, afferma:

Devono essere raccolti e conservati solo i dati personali minimi necessari

Questo è rilevante perché la threat intelligence spesso induce i team a copiare log grezzi in canali esterni. Invece, dovrebbero condividere solo ciò di cui il destinatario ha bisogno, ad esempio un dominio malevolo, un hash, un intervallo temporale, un pattern generale o un riferimento di caso pseudonimizzato.

Quinto, l’organizzazione deve conservare le evidenze. DORA si fonda su gestione documentata del rischio ICT, classificazione degli incidenti, reporting, test, governance delle terze parti e responsabilità del management. Se la condivisione influenza la risposta agli incidenti, uno scenario di test di resilienza o una decisione sul rischio dei fornitori, ciò dovrebbe essere visibile nelle registrazioni del SGSI.

Cooperazione NIS2: dall’ambito legale alle relazioni operative

NIS2 amplia la discussione oltre gli enti finanziari. Si applica in base a settore, dimensione e criticità e può applicarsi, indipendentemente dalla dimensione, anche a determinate entità, quali prestatori di servizi fiduciari, prestatori di servizi DNS, registri TLD, entità critiche e servizi di registrazione dei nomi di dominio.

Per la condivisione della threat intelligence, la lezione chiave è la governance. Article 20 rende gli organi di gestione responsabili dell’approvazione e della supervisione delle misure di gestione del rischio di cibersicurezza. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate. Article 23 richiede una segnalazione per fasi degli incidenti significativi.

La condivisione della threat intelligence interseca tutti questi aspetti. Se un avviso ISAC indica che un servizio gestito di un fornitore è sfruttato, diventano rilevanti le aspettative di Article 21 sulla catena di fornitura. Se l’intelligence indica un incidente significativo in corso, possono attivarsi i flussi di segnalazione di Article 23 e di comunicazione ai clienti. Se una minaccia informatica significativa può interessare i destinatari del servizio, l’organizzazione necessita di un processo di avviso controllato.

La Zenith Blueprint tratta questo tema nella fase ISMS Foundation and Leadership, Step 5, Comunicazione, sensibilizzazione e competenza. Raccomanda una pianificazione delle comunicazioni esterne che identifichi clienti, autorità di regolamentazione, partner e pubblico, quindi definisca cosa viene comunicato, quando, da chi e con quale approvazione. Offre l’esempio pratico di una procedura di comunicazione degli incidenti in cui il CISO redige una comunicazione, la funzione legale la riesamina e l’amministratore delegato la approva prima dell’invio.

La Politica di risposta agli incidenti per SME Incident Response Policy - SME afferma:

Il Direttore generale (GM) è responsabile dell’autorizzazione di tutte le decisioni di escalation degli incidenti, delle notifiche regolatorie e delle comunicazioni esterne.

Per le organizzazioni più grandi, la Politica di risposta agli incidenti enterprise Incident Response Policy stabilisce la base minima delle evidenze:

Tutti gli incidenti devono essere registrati nel sistema di gestione degli incidenti di sicurezza (SIMS), includendo:

Quando la threat intelligence diventa un incidente, un avviso al cliente, una notifica all’autorità di regolamentazione o un avviso esterno, non deve restare soltanto in caselle di posta e chat. Deve essere nel sistema di gestione degli incidenti con classificazione, azioni, approvazioni, evidenze e lezioni apprese.

Divulgazione conforme al GDPR: condividere intelligence, non dati personali non necessari

GDPR consente le operazioni di sicurezza, ma non crea una zona franca per la condivisione incontrollata della telemetria. Molti artefatti di threat intelligence possono contenere dati personali:

• Indirizzi IP collegati ad attività degli utenti.
• Indirizzi e-mail utilizzati in tentativi di phishing.
• Nomi utente, nomi dei dispositivi, ID degli endpoint o ID dei tenant dei clienti.
• Log di autenticazione.
• Ticket di supporto.
• Screenshot.
• Note di indagini antifrode.
• Campioni di malware contenenti documenti o file personali.
• Report di vulnerabilità che includono esposizione dei dati dei clienti.

Nel modello Clarysec, ogni decisione di condivisione in uscita passa attraverso un filtro privacy e riservatezza.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.34, Privacy e protezione delle PII, è mappato come preventivo e collegato a classificazione, inventario degli asset, mascheramento dei dati, sicurezza cloud, trasferimento delle informazioni, controllo degli accessi, Gestione delle identità e riesame di progetto o modifica. È inoltre mappato a GDPR Articles 25 e 32 tramite privacy by design, Sicurezza del trattamento, cifratura, pseudonimizzazione, controllo degli accessi e governance dimostrabile. Gli standard di supporto includono ISO/IEC 27701:2021 per la gestione delle informazioni privacy, ISO/IEC 27018:2019 per la protezione delle PII negli ambienti di responsabili del trattamento in cloud pubblico e ISO/IEC 29100:2011 per i principi privacy.

Per la condivisione della threat intelligence, il DPO e il team di sicurezza non dovrebbero incontrarsi per la prima volta durante una crisi. Dovrebbero pre-approvare pattern, template, regole di oscuramento e soglie di escalation.

Esempio operativo: un’allerta ISAC diventa resilienza basata su evidenze

Torniamo alla piattaforma di pagamenti di Maria. L’avviso ISAC include domini malevoli, nomi sospetti di applicazioni OAuth, stringhe user-agent e una nota secondo cui diversi membri hanno osservato tentativi di compromissione degli account contro utenti delle operazioni finanziarie. Anche l’azienda trova tre tentativi di accesso sospetti nei propri log.

Ecco come Clarysec renderebbe operativa la risposta utilizzando ISO/IEC 27001:2022, Zenith Blueprint, Zenith Controls e il toolkit di policy.

Il messaggio in uscita originariamente include marcature temporali, indirizzi IP sorgente, nomi utente target, ID dei tenant dei clienti e screenshot. Dopo il riesame del DPO e della funzione legale, viene ridotto a:

• Finestra temporale in UTC.
• Pattern di attacco.
• Dominio malevolo osservato.
• Tipologia generale di ruolo interessata, ad esempio utenti delle operazioni finanziarie.
• Nessun nome utente.
• Nessun ID dei tenant dei clienti.
• Nessuno screenshot.
• Nessun nome di cliente.
• Nessun log grezzo salvo richiesta tramite un canale controllato.

Se l’attività diventa un incidente, subentrano i controlli della Politica di risposta agli incidenti. Se vengono raccolti artefatti forensi, si applica la Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME:

Ogni elemento di evidenza digitale deve essere registrato con:

La policy prosegue internamente con i requisiti dei metadati delle evidenze, ma il principio di audit è chiaro: ogni artefatto utilizzato per indagine, condivisione, reporting alle autorità di regolamentazione o comunicazione ai clienti richiede tracciabilità.

La divulgazione delle vulnerabilità non coincide con la condivisione della threat intelligence

Un errore comune è trattare la divulgazione delle vulnerabilità, la notifica degli incidenti e la condivisione della threat intelligence come lo stesso processo. Si sovrappongono, ma non sono identici.

La condivisione della threat intelligence può riguardare indicatori, tattiche, avvisi settoriali, comportamento degli avversari, mitigazioni o tentativi osservati. La divulgazione coordinata delle vulnerabilità riguarda una specifica debolezza in un prodotto o servizio, spesso con un segnalante, una tempistica di correzione, un avviso di sicurezza e una decisione di divulgazione pubblica. La notifica degli incidenti riguarda la segnalazione regolatoria o contrattuale di un evento che interessa servizi, dati o clienti.

Clarysec separa questi flussi mantenendoli connessi tramite il SGSI. La Politica di divulgazione coordinata delle vulnerabilità enterprise Coordinated Vulnerability Disclosure Policy afferma:

Coordinamento e divulgazione: l’organizzazione deve coordinare la divulgazione pubblica con il segnalante. Di default, nessun dettaglio sulle vulnerabilità deve essere reso pubblico finché una correzione o una mitigazione non sia disponibile o almeno in corso. Per problematiche critiche in cui una correzione non possa essere rilasciata rapidamente, l’organizzazione può emettere un avviso di sicurezza con indicazioni sulle soluzioni alternative per avvisare gli utenti, in consultazione con le autorità competenti ove richiesto. Il segnalante è tenuto ad astenersi dalla divulgazione pubblica finché l’organizzazione non fornisce autorizzazione o pubblica un advisory. Come regola generale, l’organizzazione mira a pubblicare un advisory entro 90 giorni dalla ricezione del report, o entro un altro termine concordato reciprocamente, in linea con la pratica di settore, includendo il riconoscimento al segnalante ove sia stato fornito il consenso.

La stessa policy afferma inoltre:

Riservatezza: fino alla divulgazione pubblica, tutte le informazioni relative a una vulnerabilità segnalata devono essere trattate come Altamente Riservate. I dettagli devono essere condivisi internamente solo secondo il principio del need-to-know con il personale necessario a validare o correggere la problematica. L’identità del segnalante deve essere mantenuta riservata ove richiesto. Tutte le comunicazioni con il segnalante dovrebbero essere cifrate, anche tramite l’uso della chiave PGP dell’organizzazione, per proteggere i dettagli sensibili della vulnerabilità.

Questo è cruciale per DORA Article 45 e la cooperazione NIS2. Una comunità fidata può essere il luogo giusto per condividere mitigazioni o indicatori ad alto livello, ma non necessariamente dettagli di exploit, dati specifici dei clienti o informazioni su vulnerabilità non ancora corrette.

Le comunicazioni esterne richiedono la stessa disciplina. La Politica sui social media e sulle comunicazioni esterne enterprise Social Media and External Communications Policy assegna la responsabilità del riesame dei contenuti per garantire la conformità alle leggi che disciplinano riservatezza, divulgazioni interne, proprietà intellettuale e diffamazione. Questo conta quando un avviso tecnico diventa una dichiarazione pubblica, una comunicazione al cliente, un aggiornamento del sito web o un messaggio rivolto all’autorità di regolamentazione.

Mappatura di conformità trasversale: un flusso, molti obblighi

Un flusso solido di condivisione della cyber threat intelligence dovrebbe soddisfare più quadri di riferimento senza creare processi duplicati.

NIST CSF 2.0 è utile come livello organizzativo neutrale perché la sua funzione GOVERN tratta stakeholder, obblighi legali, dipendenze, propensione al rischio, ruoli, policy e supervisione. Le sue funzioni DETECT e RESPOND richiedono monitoraggio, integrazione della threat intelligence, dichiarazione dell’incidente, preservazione delle evidenze, notifica e comunicazione esterna.

COBIT 2019 aggiunge la responsabilità del management. Pratiche quali DSS05.04 Manage security threats, APO12 Manage risk, MEA03 Managed compliance with external requirements e APO13 Managed security aiutano gli auditor a verificare se l’intelligence migliora la prestazione dei controlli e il reporting di governance.

Come gli auditor testeranno il vostro programma di condivisione

Un auditor ISO/IEC 27001:2022 partirà dal sistema di gestione. Chiederà come siano stati identificati i requisiti legali, regolamentari, contrattuali e delle parti interessate ai sensi delle clausole 4.1 e 4.2. Verificherà se la condivisione della threat intelligence rientra nel campo di applicazione, se i rischi sono stati valutati, se i controlli 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15 e 8.16 sono inclusi o giustificati nella Dichiarazione di Applicabilità e se le evidenze dimostrano che il processo ha operato come previsto.

Un auditor o un’autorità di supervisione focalizzati su DORA cercheranno governance, responsabilità dell’organo amministrativo, integrazione del rischio ICT, classificazione degli incidenti, test di resilienza, implicazioni per le terze parti e condizioni di Article 45. Chiederanno se la partecipazione ad accordi di condivisione delle informazioni è documentata, se dati sensibili e personali sono protetti, se l’intelligence aggiorna il quadro di gestione del rischio ICT e se influenza gli scenari di test.

Un valutatore orientato a NIS2 si concentrerà su supervisione dell’organo amministrativo, misure di Article 21, gestione degli incidenti, dipendenze dai fornitori, gestione delle vulnerabilità, comunicazioni verso clienti o destinatari dei servizi e cooperazione con CSIRT o autorità competenti. Testerà se la threat intelligence è collegata alla valutazione degli incidenti significativi e al reporting per fasi.

Un auditor privacy si concentrerà sui principi GDPR. Chiederà se i dati condivisi fossero dati personali, quale base giuridica fosse applicata, se sia stata eseguita la minimizzazione, se fossero possibili pseudonimizzazione o oscuramento, se la conservazione fosse controllata e se l’organizzazione possa dimostrare l’accountability.

Buone evidenze includono:

• Registro ISAC o SIG approvato.
• Partecipanti nominati e sostituti.
• Condizioni di adesione e obblighi di riservatezza.
• Log di acquisizione della threat intelligence.
• Valutazioni di triage e rilevanza.
• Ticket di ingegnerizzazione delle rilevazioni.
• Modifiche alla prioritizzazione delle vulnerabilità.
• Escalation del rischio dei fornitori.
• Registrazioni di approvazione alla divulgazione.
• Note di riesame del DPO o privacy.
• Messaggi in uscita oscurati.
• Registrazioni degli incidenti in SIMS.
• Log della catena di custodia delle evidenze.
• Verbali del Riesame della direzione.
• Risultanze dell’audit interno e azioni correttive.

Errori comuni che Clarysec osserva sul campo

Il fallimento più comune è la partecipazione informale. Un ingegnere di sicurezza entra in un forum privato, riceve intelligence utile e condivide osservazioni interne senza autorizzazione formale. L’intenzione è corretta, ma la traccia delle evidenze è debole e il rischio per la riservatezza è elevato.

Il secondo fallimento è il consumo passivo. L’organizzazione si abbona ai feed, partecipa alle riunioni ISAC e inoltra avvisi, ma nessuno può mostrare come l’intelligence abbia modificato i controlli. La threat intelligence deve aggiornare logiche di rilevazione, priorità di patching, playbook, registri dei rischi, riesami dei fornitori, campagne di sensibilizzazione o test di resilienza.

Il terzo fallimento è la condivisione di log grezzi. I team inviano all’esterno screenshot, esportazioni SIEM, header e-mail o packet capture senza minimizzazione. Ciò può esporre dati personali, identificativi dei clienti, hostname interni, token o architetture riservate.

Il quarto fallimento è confondere le relazioni pubbliche con la comunicazione regolamentata. Un post LinkedIn su una tendenza di attacco non equivale a un avviso al cliente, a una notifica all’autorità di regolamentazione, a un aggiornamento CSIRT o a un avviso coordinato. Clarysec separa questi canali, assegna responsabili delle approvazioni e richiede registrazioni.

Il quinto fallimento è ignorare i fornitori. Molte allerte di intelligence riguardano software di terze parti, piattaforme cloud, prestatori di servizi gestiti o integrazioni di identità. Ai sensi di DORA, NIS2, NIST CSF, COBIT 2019 e dei controlli sui fornitori di ISO/IEC 27002:2022, la threat intelligence deve alimentare la gestione del rischio dei fornitori.

Costruire il pacchetto 2026 per la condivisione della threat intelligence

La maggior parte delle organizzazioni non ha bisogno di una burocrazia autonoma pesante. Ha bisogno di un pacchetto compatto di governance che funzioni durante un incidente reale. Clarysec raccomanda:

• Procedura di condivisione della threat intelligence.
• Registro delle comunità di condivisione approvate.
• Modulo di acquisizione e triage della threat intelligence.
• Modulo di approvazione della divulgazione in uscita.
• Checklist di riesame privacy e riservatezza.
• Matrice di comunicazione esterna.
• Template di sintesi delle riunioni ISAC.
• Regole di collegamento tra evidenze e incidenti.
• Dashboard delle metriche.
• Piano di test dell’audit interno.

La procedura dovrebbe richiamare le clausole di ISO/IEC 27001:2022 relative a gestione del rischio, comunicazioni, controllo operativo, valutazione delle prestazioni, audit interno e Miglioramento continuo. Dovrebbe mappare i controlli ISO/IEC 27002:2022 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, 8.16 e i controlli pertinenti sui fornitori. Dovrebbe inoltre richiamare DORA Article 45, gli obblighi di cooperazione e comunicazione degli incidenti previsti da NIS2 e i principi GDPR.

Soprattutto, deve essere utilizzabile sotto pressione. Se il processo richiede una riunione di 12 persone prima di condividere un dominio malevolo con un ISAC fidato, fallirà. Se consente di incollare log grezzi dei clienti in un portale di comunità, fallirà ugualmente. L’obiettivo è la velocità controllata.

Trasformare la condivisione della threat intelligence in resilienza basata su evidenze

La condivisione della cyber threat intelligence nel 2026 non è solo un badge di maturità della sicurezza. Per gli enti finanziari, è collegata a DORA Article 45 e alla resilienza operativa digitale. Per le entità essenziali e importanti, supporta la cooperazione NIS2, la gestione degli incidenti, la risposta alle vulnerabilità, la sicurezza dei fornitori e l’avviso ai destinatari del servizio. Per qualsiasi organizzazione che tratta dati personali dell’UE, deve essere conforme al GDPR fin dalla progettazione.

Clarysec aiuta le organizzazioni a costruire questo modello operativo senza rallentare i difensori. Colleghiamo la Zenith Blueprint Zenith Blueprint, il toolkit di policy e Zenith Controls Zenith Controls in un processo SGSI operativo: comunità approvate, ruoli chiari, divulgazione conforme alla privacy, collegamento agli incidenti, registrazioni delle evidenze, capacità di dimostrare la conformità in audit e mappatura multi-framework.

Se la vostra organizzazione partecipa a un ISAC, riceve avvisi cyber, condivide indicatori con organizzazioni omologhe, segnala alle autorità o gestisce divulgazioni di vulnerabilità, questo è il momento di formalizzare il flusso. Iniziate con un riesame di un’ora dei vostri attuali accordi di condivisione, quindi mappateli a ISO/IEC 27001:2022, DORA Article 45, NIS2 e GDPR.

Clarysec può aiutarvi a costruire il registro, le clausole di policy, i template di approvazione, il modello di evidenze per l’audit e il pacchetto di reporting alla direzione necessari per rendere la condivisione della cyber threat intelligence rapida, lecita e difendibile.