Preparazione al Cyber Solidarity Act dell’UE con ISO 27001

L’incidente delle 03:17 che trasforma la cooperazione UE in un tema di audit

Alle 03:17 di un martedì mattina, Maria, CISO di InnovateCloud, osserva uno schermo pieno di alert. La sua azienda è un fornitore SaaS europeo di medie dimensioni che serve clienti della logistica in Germania, Francia e Polonia. Il primo alert sembra indicare un accesso privilegiato sospetto in un tenant di produzione. Dieci minuti dopo, il fornitore di servizi di sicurezza gestiti segnala attività simili che interessano altri due clienti. Alle 04:00, il SOC rileva chiamate API provenienti da infrastrutture in precedenza associate alla preparazione di attacchi ransomware.

InnovateCloud non era il bersaglio originario. Un fornitore di infrastruttura di base sembra rientrare nel perimetro di impatto. Tuttavia, ora l’impatto è un problema di Maria.

Un cliente coinvolto è una banca tedesca che chiede risposte ai sensi di DORA. Un altro è un fornitore critico del settore energetico già classificato secondo le norme nazionali NIS2. L’ambiente può contenere dati personali, ma l’esfiltrazione non è ancora confermata. Il team di sicurezza vuole contenere immediatamente la minaccia. La funzione legale vuole sapere se sia già decorso il termine di 24 ore per l’allerta precoce NIS2. Il referente privacy chiede se possa essere necessaria una notifica di violazione dei dati personali ai sensi del GDPR. Il consiglio di amministrazione vuole sapere se l’indisponibilità possa propagarsi tra Stati membri.

Nel 2026, questa non è più solo una crisi interna.

Il Cyber Solidarity Act dell’UE cambia la realtà operativa degli incidenti informatici su larga scala e transfrontalieri. Introduce meccanismi di rilevamento, preparazione e risposta a livello UE, tra cui il sistema europeo di allerta per la cibersicurezza, il meccanismo di emergenza per la cibersicurezza e la riserva europea per la cibersicurezza. Anche se un’organizzazione non richiede mai direttamente supporto alla riserva, le sue evidenze, i contatti con le autorità, i contratti con i fornitori, le cronologie degli incidenti e le comunicazioni ai clienti possono diventare parte di una più ampia catena europea di risposta.

La lacuna emerge rapidamente. Molte organizzazioni dispongono di strumenti, ticket e politiche, ma non di evidenze in grado di reggere a un esame regolatorio. Possono dire “abbiamo contattato l’autorità”, ma non possono dimostrare chi fosse autorizzato, quale soglia abbia attivato il contatto, che cosa sia stato comunicato, se i log siano stati preservati, se un fornitore fosse contrattualmente tenuto a prestare assistenza o se un report finale possa essere ricostruito a partire da decisioni assunte contestualmente ai fatti.

La risposta non è un altro fascicolo isolato sul “Cyber Solidarity Act”. La risposta è un Sistema di gestione della sicurezza delle informazioni ISO/IEC 27001:2022 che produca le evidenze una sola volta e le riutilizzi rispetto alle aspettative di NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Quelle evidenze iniziano prima dell’incidente.

Perché il Cyber Solidarity Act dell’UE innalza lo standard delle evidenze

Il Cyber Solidarity Act è progettato per il rilevamento, la preparazione e la risposta alle crisi informatiche a livello UE. Il suo effetto pratico per CISO, auditor e compliance manager è chiaro: il coordinamento di incidenti su larga scala richiede evidenze più rapide, più pulite, più coerenti e più semplici da condividere con parti interessate attendibili.

Quando è possibile un impatto transfrontaliero, un’organizzazione può dover coordinarsi con CSIRT nazionali, autorità competenti, autorità di settore, autorità di controllo per la protezione dei dati, autorità di vigilanza finanziaria, forze dell’ordine, clienti, responsabili del trattamento, fornitori e team esterni di risposta agli incidenti. La riserva europea per la cibersicurezza aggiunge un’ulteriore dimensione, perché fornitori privati preventivamente qualificati possono supportare preparazione, risposta e ripristino. Questo rende ancora più importanti la governance dei fornitori, la legittimazione ad agire, la gestione dei dati e la preservazione delle evidenze.

I soggetti privati sono al centro di questa realtà. Fornitori cloud, data center, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, operatori di infrastrutture digitali, fintech e piattaforme SaaS spesso detengono la telemetria, i log, i dati sull’impatto sui clienti e i fatti tecnici di cui le autorità hanno bisogno per comprendere un incidente rilevante.

NIS2 indica già questa direzione. Si applica a molte entità medie e grandi nei settori degli allegati I e II che forniscono servizi o svolgono attività nell’UE. Include inoltre determinate entità indipendentemente dalla dimensione, tra cui prestatori di servizi fiduciari, fornitori di servizi DNS, registri dei domini di primo livello e prestatori di servizi di registrazione dei nomi di dominio. L’allegato I include infrastrutture digitali quali servizi di cloud computing, servizi di data center, reti di distribuzione dei contenuti, fornitori DNS, prestatori di servizi fiduciari e registri TLD. Include anche la gestione di servizi ICT B2B, compresi fornitori di servizi gestiti e fornitori di servizi di sicurezza gestiti. L’allegato II include fornitori digitali quali mercati online, motori di ricerca online e piattaforme di servizi di social network.

DORA aggiunge un secondo livello per il settore finanziario. Dal 17 gennaio 2025 si applica a un’ampia gamma di entità finanziarie, tra cui enti creditizi, istituti di pagamento, istituti di moneta elettronica, imprese di investimento, prestatori di servizi per le cripto-attività, sedi di negoziazione, imprese di assicurazione e riassicurazione, agenzie di rating del credito, prestatori di servizi di crowdfunding e altri soggetti. Crea inoltre aspettative significative per i fornitori terzi di servizi ICT, perché le entità finanziarie restano responsabili dei servizi ICT esternalizzati.

Un incidente fintech nel 2026 può quindi essere coordinato attraverso i canali di vigilanza DORA, mentre il fornitore SaaS o l’MSSP che supporta quella fintech può rientrare in NIS2. Lo stesso evento tecnico può generare obblighi di segnalazione, aspettative sulle evidenze e obblighi contrattuali diversi per attori diversi.

ISO/IEC 27001:2022 offre alle organizzazioni il sistema operativo per gestire questa complessità. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di definire il SGSI nel proprio contesto aziendale, identificare le parti interessate e i relativi requisiti legali, regolamentari e contrattuali, definire confini e dipendenze e istituire il sistema di gestione. Le clausole da 5.1 a 5.3 attribuiscono alla direzione la responsabilità di politica, risorse, integrazione e assegnazione dei ruoli. Le clausole da 6.1.1 a 6.1.3 richiedono una valutazione del rischio ripetibile, il trattamento del rischio e una Dichiarazione di Applicabilità. La clausola 8.1 richiede il controllo operativo, incluso il controllo di processi, prodotti e servizi forniti esternamente.

Questo è il nucleo della preparazione al Cyber Solidarity Act: dimostrare che la risposta alla crisi è gestita, testata e verificabile in audit, non improvvisata.

Il modello di evidenze Clarysec: un incidente, molti obblighi

Un incidente transfrontaliero non aspetta che i team legali lo classifichino. Le evidenze devono essere acquisite fin dal primo alert e poi indirizzate verso i corretti percorsi di segnalazione e coordinamento.

L’approccio di Clarysec collega tre asset:

1. Zenith Blueprint: percorso in 30 passi per auditor Zenith Blueprint, che trasforma l’attuazione di ISO/IEC 27001:2022 in un percorso sequenziato e pronto per l’audit.
2. Zenith Controls: guida alla conformità trasversale Zenith Controls, che mappa i controlli ISO/IEC 27002:2022 verso controlli correlati, attributi, capacità operative, domini di sicurezza e aspettative sulle evidenze tra quadri di riferimento.
3. Modelli di politiche Clarysec per risposta agli incidenti, raccolta delle evidenze, sicurezza dei fornitori, logging, monitoraggio e continuità operativa, adattati ad ambienti enterprise e PMI.

Nel Zenith Blueprint, fase Controlli in azione, il passo 22 tratta il controllo ISO/IEC 27002:2022 5.5, Contatto con le autorità. Afferma:

Il controllo 5.5 assicura che un’organizzazione sia preparata a interagire con autorità esterne quando necessario, non in modo reattivo o nel panico, ma attraverso canali predefiniti, strutturati e ben compresi.

La stessa sezione pone la domanda a cui ogni CISO dovrebbe rispondere prima della crisi:

se la vostra organizzazione fosse presa di mira da un attacco informatico, coinvolta in una violazione dei dati o sottoposta a indagine, chi effettuerebbe la chiamata alle autorità? Come saprebbe che cosa dire? A quali condizioni verrebbe avviato tale contatto?

Non si tratta di burocrazia amministrativa. In un contesto Cyber Solidarity Act, è la differenza tra un’allerta precoce gestita con calma e messaggi contraddittori tra giurisdizioni.

Zenith Controls considera il controllo ISO/IEC 27002:2022 5.5, Contatto con le autorità, come preventivo e correttivo, collegato a riservatezza, integrità e disponibilità e allineato ai concetti Identify, Protect, Respond e Recover. Collega il 5.5 alla pianificazione e preparazione della gestione degli incidenti, alla segnalazione degli eventi, alle informazioni sulle minacce, ai gruppi di interesse speciale e alla risposta agli incidenti.

La stessa guida tratta il controllo ISO/IEC 27002:2022 5.24, Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, come controllo correttivo collegato a Respond e Recover. I suoi legami con valutazione degli eventi, risposta agli incidenti, lezioni apprese, logging, monitoraggio, sicurezza durante le interruzioni e continuità mostrano ciò che gli auditor spesso verificano: se il piano collega rilevamento, classificazione, escalation, evidenze, ripristino e apprendimento.

Per la gestione delle evidenze, il controllo ISO/IEC 27002:2022 5.28, Raccolta delle evidenze, è particolarmente importante. Zenith Controls lo collega a risposta agli incidenti, logging, monitoraggio e segnalazione degli eventi. In un incidente transfrontaliero grave, è qui che l’indagine tecnica diventa sostenibile.

Mappare la preparazione al Cyber Solidarity Act alle evidenze ISO 27001

Il Cyber Solidarity Act dell’UE crea un ambiente di preparazione e coordinamento. ISO/IEC 27001:2022 fornisce il motore delle evidenze. NIS2, DORA e GDPR definiscono molte aspettative specifiche in materia di segnalazione, governance e protezione.

Si noti ciò che manca: un silo separato di conformità. Le stesse evidenze che supportano la certificazione ISO/IEC 27001:2022 possono supportare la responsabilità della direzione prevista da NIS2, la gestione del rischio ICT prevista da DORA, la responsabilizzazione per la sicurezza prevista dal GDPR, gli esiti di comunicazione del NIST CSF e le aspettative di assurance di COBIT 2019.

NIS2: il conteggio per la segnalazione inizia con la presa di conoscenza

NIS2 è centrale per la preparazione al 2026 perché definisce un flusso di segnalazione degli incidenti articolato per fasi.

Article 23 richiede alle entità essenziali e importanti di notificare al proprio CSIRT o all’autorità competente, senza indebito ritardo, gli incidenti significativi che incidono sulla fornitura dei servizi. L’allerta precoce deve essere trasmessa senza indebito ritardo e comunque entro 24 ore dal momento in cui si viene a conoscenza dell’incidente significativo. Deve indicare, ove applicabile, se si sospettano atti dolosi o illeciti e se è possibile un impatto transfrontaliero.

Segue una notifica dell’incidente senza indebito ritardo e comunque entro 72 ore dalla presa di conoscenza, che aggiorna l’allerta precoce e fornisce una valutazione iniziale di gravità, impatto e indicatori di compromissione disponibili. Il rapporto finale è dovuto entro un mese dalla notifica dell’incidente, con gravità, impatto, probabile tipologia di minaccia o causa radice, misure di mitigazione e impatto transfrontaliero.

Per questo motivo la risposta agli incidenti non può iniziare da un documento vuoto.

La Politica di risposta agli incidenti enterprise Incident Response Policy afferma:

NIS2 Article 23 (notifica entro 24 ore dal momento in cui si viene a conoscenza dell’incidente)

La Politica di risposta agli incidenti - PMI Incident Response Policy - SME porta la stessa logica temporale in una governance pratica:

“Le tempistiche di risposta, compresi il recupero dei dati e gli obblighi di notifica, devono essere documentate e allineate ai requisiti legali, come il requisito GDPR di notifica di una violazione dei dati personali entro 72 ore.”

Da Incident Response Policy - SME, sezione “Requisiti di governance”, clausola 5.3.2.

Inoltre integra nel processo di incidente la valutazione multi-regime:

“Quando sono coinvolti dati dei clienti, il Direttore generale deve valutare gli obblighi legali di notifica in base all’applicabilità di GDPR, NIS2 o DORA.”

Da Incident Response Policy - SME, sezione “Trattamento del rischio ed eccezioni”, clausola 7.4.1.

In uno scenario Cyber Solidarity Act, “è possibile un impatto transfrontaliero” diventa operativamente rilevante. L’allerta precoce può non disporre di tutti i fatti, ma l’organizzazione deve essere in grado di dimostrare perché abbia sospettato, o non abbia sospettato, un impatto transfrontaliero sulla base delle evidenze disponibili.

La registrazione dell’incidente deve acquisire:

• Quando l’organizzazione ne è venuta a conoscenza.
• Chi ha dichiarato l’evento come potenziale incidente.
• Quali servizi, paesi, clienti o settori erano potenzialmente interessati.
• Se si sospettava attività dolosa o illecita.
• Quali indicatori di compromissione erano disponibili.
• Quale percorso di contatto con le autorità è stato utilizzato.
• Se erano richieste comunicazioni ai clienti.
• Quali evidenze sono state preservate prima delle principali attività di bonifica.

Il momento migliore per progettare questi campi è prima delle 03:17.

DORA: quando il cliente è regolamentato ma il fornitore detiene i log

DORA cambia il dialogo con i fornitori. Le entità finanziarie devono gestire il rischio ICT di terze parti come parte del proprio quadro di gestione del rischio ICT. L’esternalizzazione dei servizi ICT non trasferisce la responsabilità regolamentare dall’entità finanziaria.

DORA richiede strategie per il rischio ICT di terze parti, registri dei contratti di servizi ICT, due diligence, pianificazione di audit e ispezioni, diritti di risoluzione e strategie di uscita testate per servizi ICT critici o importanti. Article 30 richiede chiarezza contrattuale, incluse descrizioni dei servizi, ubicazioni, gestione dei dati, riservatezza, integrità, disponibilità, livelli di servizio, assistenza durante incidenti ICT, cooperazione con le autorità e diritti di risoluzione. Per funzioni critiche o importanti si applicano termini più rigorosi.

Torniamo all’incidente di Maria. La banca tedesca è regolamentata da DORA. InnovateCloud fornisce servizi SaaS. L’MSSP rileva attività sospette. Il fornitore di infrastruttura cloud possiede alcuni log di audit fondamentali. Un subappaltatore gestisce parte della pipeline di telemetria. La banca resta responsabile, ma non può classificare e segnalare correttamente senza evidenze dei fornitori.

Clarysec affronta questo aspetto tramite classificazione dei fornitori ed evidenze contrattuali. La Politica di sicurezza delle terze parti e dei fornitori enterprise Third party and supplier security policy richiede:

I contratti con i fornitori devono includere:

La Politica di sicurezza delle terze parti e dei fornitori - PMI Third-Party and Supplier Security Policy - SME applica la stessa logica di conformità in un modello operativo più leggero:

I contratti devono includere clausole obbligatorie relative a:

Il valore si trova nel programma che sta dietro quelle parole: obblighi di notifica degli incidenti, accesso ai log, diritti di audit, riservatezza, localizzazione dei dati, controlli sui subappaltatori, cooperazione con le autorità, supporto al ripristino e obblighi di uscita.

Il Zenith Blueprint, fase Controlli in azione, passo 23, fornisce il percorso di attuazione:

Compilare un elenco completo dei fornitori e prestatori di servizi attuali (5.19) e classificarli in base all’accesso a sistemi, dati o controllo operativo. Per ogni fornitore classificato, verificare che le aspettative di sicurezza siano chiaramente incorporate nei contratti (5.20), incluse riservatezza, accesso, segnalazione degli incidenti e obblighi di conformità.

Prosegue con il rischio a valle:

Per ogni fornitore critico, identificare se utilizza subappaltatori (sub-responsabili) che possono accedere ai vostri dati o sistemi. Documentare come i vostri requisiti di sicurezza delle informazioni siano trasferiti a cascata a tali parti, attraverso i termini contrattuali del fornitore o tramite vostre clausole dirette.

Questa è anche preparazione alla riserva europea per la cibersicurezza. Se un fornitore esterno di risposta entra nel vostro ambiente durante un’emergenza, dovete conoscere base giuridica, ambito di accesso, regole sulle evidenze, obblighi di trattamento dei dati, percorso di coordinamento con le autorità e condizioni di uscita. DORA lo rende esplicito per le entità finanziarie. NIS2 lo rende rilevante per le entità essenziali e importanti. ISO/IEC 27001:2022 lo rende verificabile in audit.

GDPR: la domanda sulla violazione dentro la crisi informatica

Non ogni incidente di cibersicurezza è una violazione dei dati personali, ma ogni incidente grave deve essere valutato rispetto a tale possibilità.

Il GDPR si applica al trattamento nel contesto di uno stabilimento nell’UE, nonché a titolari del trattamento o responsabili del trattamento non stabiliti nell’UE che offrono beni o servizi a persone nell’UE o ne monitorano il comportamento nell’UE. Definisce dati personali, trattamento, titolare del trattamento, responsabile del trattamento e violazione dei dati personali. I suoi principi includono integrità, riservatezza e responsabilizzazione, il che significa che i titolari devono essere in grado di dimostrare la conformità.

Durante l’incidente delle 03:17, il team di Maria deve chiedersi:

• Sono stati consultati, comunicati, alterati, persi o distrutti dati personali?
• InnovateCloud è titolare del trattamento, responsabile del trattamento o entrambi per i dati interessati?
• Sono coinvolte categorie particolari di dati personali?
• Quali clienti o persone fisiche sono interessati?
• I log sono sufficienti per valutare l’ambito?
• Gli obblighi di notifica GDPR decorrono in parallelo agli obblighi NIS2 o DORA?

Per questo motivo il coordinamento privacy deve rientrare nell’escalation dell’incidente, non in un riesame legale tardivo dopo la ricostruzione dei sistemi e la rotazione dei log.

La Politica di logging e monitoraggio - PMI Logging and Monitoring Policy - SME afferma:

Le allerte ad alta priorità devono essere inoltrate in escalation al Direttore generale e al Coordinatore privacy entro 24 ore

Questa clausola è semplice, ma risolve un modello di fallimento reale. I referenti privacy hanno bisogno di evidenze quando sono ancora sufficientemente fresche per determinare se si sia verificata una violazione dei dati personali e se le persone fisiche siano esposte a rischio.

Costruire un pacchetto di evidenze per le prime 24 ore di un incidente transfrontaliero

Un’esercitazione pratica di preparazione deve simulare le prime 24 ore di un incidente transfrontaliero. L’obiettivo non è segnalare in eccesso. L’obiettivo è dimostrare che l’organizzazione può raccogliere i fatti, assumere decisioni sostenibili e mantenere comunicazioni coerenti.

Scenario

Il vostro MSSP rileva un accesso privilegiato sospetto da una regione insolita contro il vostro tenant di produzione. La stessa infrastruttura sorgente compare in alert che interessano due clienti in due Stati membri. Un cliente è un’entità finanziaria. L’ambiente interessato contiene dati personali, ma l’esfiltrazione non è confermata.

Passo 1: aprire la registrazione dell’incidente

Create il ticket di incidente utilizzando campi di classificazione approvati. Includete ora di presa di conoscenza, fonte del rilevamento, asset impattati, servizi impattati, paesi potenzialmente interessati, attività dolosa sospetta, gravità iniziale e responsabile dell’incidente.

Collegate questo ai controlli ISO/IEC 27002:2022 5.24, 5.25 e 5.26 e ai controlli dell’Allegato A ISO/IEC 27001:2022 A.5.24, A.5.25 e A.5.26.

Passo 2: attivare il flusso decisionale verso le autorità

Utilizzate la matrice dei contatti con le autorità richiesta dal passo 22 di Zenith Blueprint. Identificate quali autorità possono essere rilevanti: CSIRT nazionale, autorità di controllo per la protezione dei dati, autorità di vigilanza finanziaria, forze dell’ordine e autorità di settore.

Registrate la decisione e la motivazione. Se non viene effettuata un’allerta precoce NIS2, documentatene il motivo. Se è possibile un impatto transfrontaliero, registrate le evidenze a supporto di tale conclusione.

Passo 3: preservare le evidenze prima delle principali attività di bonifica

La Politica per la raccolta delle evidenze e l’analisi forense enterprise Evidence Collection and Forensics Policy afferma:

Tutte le evidenze raccolte devono essere identificate in modo univoco, etichettate e archiviate in un repository sicuro con:

La Politica per la raccolta delle evidenze e l’analisi forense - PMI Evidence Collection and Forensics Policy - SME applica la stessa disciplina in forma più semplice:

“Ogni elemento di evidenza digitale deve essere registrato con:”

Da Evidence Collection and Forensics Policy - SME, sezione “Requisiti di governance”, clausola 5.2.1.

Per l’esercitazione tabletop, raccogliete voci di evidenza campione: esportazione dell’alert SIEM, log del provider di identità, registrazioni delle sessioni privilegiate, snapshot endpoint, log del firewall, log di audit cloud, note sull’impatto sui clienti e approvazioni delle comunicazioni.

Passo 4: attivare l’assistenza dei fornitori

Verificate il Registro dei fornitori. Identificate l’MSSP, il fornitore cloud e i subappaltatori critici. Confermate clausole di supporto agli incidenti, contatti di escalation, periodi di conservazione dei log, formato delle evidenze e obblighi di cooperazione con le autorità.

Questo supporta direttamente i requisiti DORA sul rischio ICT di terze parti e le aspettative NIS2 sulla sicurezza della catena di fornitura.

Passo 5: redigere tre comunicazioni

Redigete tre comunicazioni a partire dalla stessa base fattuale:

Passo 6: chiudere con le lezioni apprese

Aggiornate il Registro dei rischi, la Dichiarazione di Applicabilità, il Registro dei fornitori e il Piano di risposta agli incidenti. Se l’esercitazione rivela log mancanti, contatti con le autorità non chiari o clausole deboli con i fornitori, aprite azioni correttive.

Il Zenith Blueprint, fase Controlli in azione, passo 23, indica alle organizzazioni di validare le capacità di gestione degli incidenti in questo modo:

Selezionare un evento recente o condurre un’esercitazione tabletop per convalidare il piano. Acquisire e registrare tutte le decisioni, i ruoli e le comunicazioni (5.26) e aggiornare il piano con le lezioni apprese (5.27). Confermare che siano in essere procedure per preservare evidenze forensi (5.28), inclusi snapshot dei log, backup e isolamento sicuro dei sistemi impattati.

Quel paragrafo è un’agenda di esercitazione pronta per l’audit.

Logging: la differenza tra coordinamento e speculazione

Il coordinamento di un incidente transfrontaliero fallisce quando tutti hanno opinioni e nessuno ha marcature temporali.

Il Zenith Blueprint, fase Controlli in azione, passo 19, lo esprime chiaramente:

Il logging è la linfa vitale di qualsiasi ambiente IT sicuro. Senza logging, gli incidenti restano invisibili, la responsabilizzazione svanisce e le relazioni di causa-effetto si dissolvono nel nulla.

Prosegue:

Al centro, il logging riguarda la tracciabilità. Quando qualcosa va storto, che si tratti di un tentativo di accesso non riuscito, della cancellazione di file critici o dell’esecuzione di uno script rogue su un server, i log forniscono il filo forense che aiuta a ricostruire ciò che è realmente accaduto.

Per NIS2, i log supportano la notifica dell’incidente entro 72 ore con gravità iniziale, impatto e indicatori di compromissione. Per DORA, i log supportano la classificazione degli incidenti gravi connessi alle ICT, l’analisi della causa radice, l’impatto operativo e la responsabilità di terze parti. Per GDPR, i log supportano la valutazione dell’eventuale accesso o comunicazione di dati personali. In un contesto Cyber Solidarity Act, i log supportano la consapevolezza situazionale condivisa senza costringere i team di risposta ad affidarsi a ipotesi.

Se la risposta a una qualsiasi domanda è “non siamo sicuri”, il tema deve entrare nel Piano di trattamento del rischio.

Continuità operativa e operazioni di crisi sicure

La discussione sul Cyber Solidarity Act si concentra naturalmente sulla risposta agli incidenti, ma la resilienza significa anche mantenere sicuri i servizi critici durante un’interruzione.

NIS2 Article 21 richiede un approccio multirischio che copra trattamento dell’incidente, continuità operativa, gestione dei backup, disaster recovery, gestione della crisi, sicurezza della catena di fornitura, trattamento delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset, autenticazione a più fattori, comunicazioni sicure e comunicazioni di emergenza protette ove opportuno.

DORA richiede analogamente governance, gestione del rischio ICT, gestione degli incidenti, test di resilienza, gestione del rischio di terze parti, continuità e ripristino. Le entità più piccole possono avere requisiti semplificati, ma necessitano comunque di gestione documentata del rischio ICT, monitoraggio, sistemi resilienti, trattamento dell’incidente, identificazione delle dipendenze da terze parti, backup, ripristino, test, apprendimento post-incidente e formazione.

La Politica di continuità operativa e disaster recovery enterprise Business Continuity Policy and Disaster Recovery Policy parte da un requisito semplice:

I piani devono coprire:

Dietro questa frase si trovano le evidenze di continuità che gli auditor si aspettano: priorità di ripristino, Recovery Time Objective, Recovery Point Objective, piani dei backup, test di ripristino, ruoli di crisi, comunicazioni alternative, dipendenze dai fornitori e azioni di miglioramento successive alle esercitazioni.

I controlli ISO/IEC 27002:2022 5.29 e 5.30 sono centrali in questo ambito. Il controllo 5.29 riguarda la sicurezza delle informazioni durante le interruzioni. Il controllo 5.30 riguarda la prontezza ICT per la continuità operativa. In Zenith Controls, la pianificazione degli incidenti nell’ambito del 5.24 è collegata alla sicurezza durante le interruzioni e alla più ampia pianificazione della continuità. Ciò è particolarmente rilevante quando i canali ordinari non sono disponibili, i sistemi di identità sono degradati o i team di crisi devono coordinarsi con le autorità attraverso comunicazioni di emergenza protette.

Mappa di conformità trasversale: NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019

Un CISO non ha bisogno di cinque programmi separati per gli incidenti. Ha bisogno di un unico modello di evidenze osservabile attraverso cinque lenti.

Il metodo dei profili corrente e target del NIST CSF 2.0 è particolarmente utile per le organizzazioni non ancora abbastanza mature per una piattaforma GRC integrata completa. Incoraggia le organizzazioni a definire l’ambito di un profilo, raccogliere input quali politiche, priorità di rischio aziendale, Business Impact Analysis, requisiti, standard, procedure, misure di sicurezza e ruoli, quindi analizzare le lacune e creare un piano d’azione prioritizzato. Questo è vicino a uno sprint pratico di preparazione al Cyber Solidarity Act: evidenze attuali, obblighi target, piano delle lacune, titolari, date e traccia di audit.

Gli auditor COBIT 2019 e con approccio ISACA tendono a chiedere se gli obiettivi di governance siano assegnati, misurati e monitorati. Non si accontenteranno di “se ne occupa il SOC”. Chiederanno come gli organi di gestione approvano le misure di rischio, come vengono rendicontate le prestazioni, come viene governato il rischio di terze parti, come vengono accettate le eccezioni e come vengono tracciate le azioni correttive.

Come gli auditor testeranno lo stesso incidente

Lo stesso incidente delle 03:17 genera domande di audit diverse a seconda del mandato del valutatore.

Un auditor ISO/IEC 27001:2022 partirà dal SGSI. Chiederà se il processo di gestione degli incidenti rientra nell’ambito, se i requisiti delle parti interessate includono NIS2, DORA, GDPR e contratti, se la valutazione del rischio ha considerato scenari transfrontalieri e legati ai fornitori, se i controlli dell’Allegato A sono stati selezionati nella Dichiarazione di Applicabilità e se le registrazioni operative dimostrano che il processo è stato seguito.

Un’autorità o un valutatore focalizzato su NIS2 si concentrerà sulla responsabilità della direzione, sulle misure di gestione del rischio dell’Article 21 e sulla segnalazione dell’Article 23. Potrebbe chiedere quando l’organizzazione è venuta a conoscenza dell’incidente, perché l’incidente fosse o non fosse significativo, come sia stato valutato l’impatto transfrontaliero, se i clienti siano stati informati e se le misure correttive siano state adottate senza indebito ritardo.

Un’autorità di vigilanza DORA o un team di audit interno chiederà se l’incidente abbia interessato funzioni critiche o importanti, se i fornitori terzi di servizi ICT abbiano supportato la risposta, se l’entità finanziaria abbia mantenuto la responsabilità, se il registro delle informazioni fosse accurato, se l’incidente sia stato classificato correttamente e se le lezioni apprese siano confluite nei test di resilienza e nella supervisione dei fornitori.

Un auditor GDPR o un’autorità di controllo per la protezione dei dati chiederà se l’organizzazione avesse evidenze sufficienti per determinare se i dati personali fossero stati violati, se i ruoli di titolare del trattamento e responsabile del trattamento fossero chiari, se gli interessati fossero esposti a rischio, se i controlli di riservatezza e integrità fossero appropriati e se le registrazioni di responsabilizzazione fossero mantenute.

Un valutatore NIST CSF 2.0 tradurrà l’evento negli esiti Govern, Identify, Protect, Detect, Respond e Recover. Cercherà aspettative degli stakeholder, obblighi legali, propensione al rischio, governance dei fornitori, logging, monitoraggio, esecuzione della risposta, comunicazioni e convalida del ripristino.

Un auditor COBIT 2019 o ISACA si concentrerà sull’efficacia della governance e del sistema di gestione: titolarità, diritti decisionali, metriche, accettazione del rischio, prestazione dei processi, assurance e miglioramento continuo.

Qui Zenith Controls è utile come bussola di conformità trasversale. Non rinomina i controlli ufficiali né crea un quadro di controllo parallelo. Mostra come i controlli ISO/IEC 27002:2022 quali 5.5, 5.24 e 5.28 si collegano a capacità operative, controlli correlati ed evidenze rilevanti per l’audit.

Che cosa devono fare ora i CISO per la preparazione al 2026

Se vi state preparando alla realtà operativa del Cyber Solidarity Act dell’UE, iniziate dalle evidenze, non dagli slogan.

Primo, aggiornate il contesto del vostro SGSI e l’analisi delle parti interessate. Identificate se la vostra organizzazione, i clienti o i fornitori rientrano in NIS2, DORA o GDPR. Includete presenza negli Stati membri, classificazione di settore, clienti critici, dipendenze dai servizi ICT e contatti con le autorità.

Secondo, eseguite un’esercitazione tabletop su un incidente transfrontaliero. Utilizzate uno scenario che includa un fornitore, più di uno Stato membro, una possibile esposizione di dati personali e un cliente finanziario regolamentato. Limitate temporalmente le prime 24 ore.

Terzo, riesaminate i contratti con i fornitori. Confermate obblighi di notifica, accesso ai log, supporto forense, cooperazione con le autorità, obblighi a cascata sui subappaltatori, localizzazione dei dati, diritti di audit, supporto alla continuità e diritti di risoluzione.

Quarto, testate la raccolta delle evidenze. Esportate i log, preservate snapshot, etichettate le evidenze, registrate la catena di custodia e validate l’accesso al repository. Se la vostra politica afferma che le evidenze sono identificate in modo univoco e archiviate in sicurezza, dimostratelo.

Quinto, allineate le comunicazioni sull’incidente. L’allerta precoce NIS2, l’escalation DORA, la valutazione della violazione GDPR e l’avviso al cliente non devono contraddirsi. Possono avere finalità legali diverse, ma devono derivare dalla stessa base fattuale.

Sesto, coinvolgete il consiglio di amministrazione nell’esercitazione. NIS2 e DORA elevano entrambe la responsabilità della direzione. Le clausole sulla leadership di ISO/IEC 27001:2022 rendono questo aspetto verificabile in audit. Un consiglio di amministrazione che non ha mai visto un termine di 24 ore per una notifica cyber non è pronto per una crisi transfrontaliera.

Prossimi passi con Clarysec

Il futuro della cibersicurezza dell’UE è fatto di collaborazione e fiducia dimostrata. Le organizzazioni che trattano NIS2 e DORA come checklist isolate avranno difficoltà durante incidenti transfrontalieri. Le organizzazioni che costruiscono sistemi operativi ISO/IEC 27001:2022 supportati da evidenze saranno in grado di rispondere con sicurezza ad autorità di regolamentazione, clienti, auditor e team di risposta alle crisi.

Clarysec aiuta CISO, compliance manager, auditor e responsabili di business a trasformare la regolamentazione cyber dell’UE in evidenze operative pronte per l’audit attraverso:

• Zenith Blueprint: percorso in 30 passi per auditor per un’attuazione strutturata di ISO/IEC 27001:2022 e la sequenza degli audit.
• Zenith Controls: guida alla conformità trasversale per mappare controlli su incidenti, autorità, fornitori, evidenze, logging e continuità tra quadri di riferimento.
• Modelli di politiche Clarysec, tra cui Politica di risposta agli incidenti, Politica per la raccolta delle evidenze e l’analisi forense, Politica di sicurezza delle terze parti e dei fornitori, Politica di continuità operativa e disaster recovery, oltre alle versioni PMI quando la proporzionalità è rilevante.

Il momento migliore per prepararsi al coordinamento di incidenti transfrontalieri è prima dell’alert delle 03:17. Il secondo momento migliore è oggi.

Iniziate con un riesame di preparazione Clarysec, scaricate il toolkit di politiche pertinente o richiedete una sessione guidata su come Zenith Blueprint e Zenith Controls possono aiutare il vostro SGSI a produrre le evidenze che la resilienza cyber del 2026 richiederà.