Registri dei contatti regolamentari NIS2 e DORA per ISO 27001

L’incidente delle 02:17: quando l’elenco dei contatti diventa il controllo

Alle 02:17 di un martedì, l’analista SOC rileva lo schema che nessuno vorrebbe vedere. Un account di servizio privilegiato si è autenticato da un’area geografica insolita, i record dei clienti sono stati interrogati in sequenza e un fornitore di servizi MDR ha aperto un ticket ad alta gravità. Nel giro di pochi minuti, il responsabile della gestione dell’incidente conferma la criticità: gli indicatori di ransomware si stanno propagando lateralmente, un servizio critico in produzione è degradato e potrebbero essere coinvolti dati dei clienti.

La risposta tecnica parte rapidamente. Gli endpoint vengono isolati, i log di identità vengono acquisiti, gli snapshot cloud vengono preservati e il fornitore di Managed Security Services si collega al bridge. Poi inizia il panico freddo.

Il CISO chiede: “Chi dobbiamo notificare?”

La funzione legale segnala che potrebbe essere necessario coinvolgere l’autorità di controllo per la protezione dei dati. Il DPO chiede se si tratti di una violazione dei dati personali. Il COO afferma che il fornitore cloud deve essere oggetto di escalation in base alla clausola di supporto enterprise. Il Compliance Manager chiede se l’entità sia un’entità importante ai sensi di NIS2 o se DORA si applichi perché il servizio supporta un soggetto finanziario regolamentato. Il Consiglio di amministrazione vuole sapere che cosa deve accadere nelle prime 24 ore.

Nessuno mette in discussione la necessità di comunicare. Il problema è che recapiti, percorso di approvazione, trigger legali e requisiti probatori sono dispersi tra un vecchio foglio di calcolo per la continuità operativa, contratti con i fornitori, thread e-mail, una wiki di conformità obsoleta e il telefono di una sola persona.

Non è solo un inconveniente operativo. Nel 2026 è una lacuna di conformità.

NIS2 ha trasformato la notifica degli incidenti per fasi in un obbligo di governance, includendo un allarme tempestivo entro 24 ore, una notifica entro 72 ore e una relazione finale entro un mese per gli incidenti significativi. DORA ha istituito un regime dedicato di resilienza operativa digitale per le entità finanziarie, comprendente gestione degli incidenti ICT, classificazione, segnalazioni alle autorità di vigilanza, rischio ICT di terze parti e comunicazione di crisi. GDPR resta rilevante ogni volta che sono coinvolti dati personali. ISO/IEC 27001:2022 trasforma questi obblighi in evidenze verificabili del sistema di gestione.

Un registro dei contatti regolamentari può sembrare amministrativo. Non lo è. È il tessuto connettivo tra risposta agli incidenti, notifica legale, continuità operativa, coordinamento dei fornitori, responsabilità della direzione ed evidenze di audit.

Clarysec considera questo un problema di evidenze, non un esercizio documentale. In Zenith Blueprint: roadmap in 30 passi per auditor Zenith Blueprint, il passo 22 della fase Controls in Action spiega perché il contatto con le autorità deve essere predefinito:

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

Questa è la vera lezione dell’incidente delle 02:17. Il momento per trovare il portale di notifica dell’autorità competente, il numero di reperibilità del CSIRT, il contatto sostitutivo del DPO, il canale di segnalazione dell’autorità di vigilanza finanziaria e il percorso di escalation del fornitore è prima dell’incidente, non quando il termine di segnalazione ha già iniziato a decorrere.

Perché i registri dei contatti regolamentari sono diventati una priorità di conformità nel 2026

Molte organizzazioni dispongono già di elenchi di contatti di emergenza. Il problema è che NIS2 e DORA richiedono qualcosa di più disciplinato di un elenco di nomi e numeri di telefono. Richiedono una governance dei contatti accurata, basata sui ruoli e pronta per l’audit, collegata a trigger legali, autorità di escalation, termini di segnalazione e dipendenze dai fornitori.

NIS2 si applica a un ampio insieme di entità essenziali e importanti in settori quali energia, trasporti, banche, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi ICT, pubblica amministrazione e spazio. Include inoltre molti fornitori digitali, compresi servizi di cloud computing, servizi di data centre, reti di distribuzione dei contenuti, prestatori di servizi gestiti, fornitori di servizi di sicurezza gestiti, marketplace online, motori di ricerca online e piattaforme di social networking. Gli Stati membri erano tenuti a istituire elenchi di entità essenziali e importanti entro il 17 aprile 2025 e ad aggiornarli almeno ogni due anni. Per molti fornitori cloud, SaaS, di servizi gestiti e di piattaforme digitali, l’esposizione normativa è passata da teorica a operativa.

DORA si applica dal 17 gennaio 2025 alle entità finanziarie quali enti creditizi, istituti di pagamento, istituti di moneta elettronica, imprese di investimento, prestatori di servizi per le cripto-attività, sedi di negoziazione, depositari centrali di titoli, controparti centrali, imprese di assicurazione e riassicurazione e altre organizzazioni del settore finanziario rientranti nel perimetro. DORA è molto rilevante anche per l’ecosistema delle terze parti ICT, perché le entità finanziarie devono gestire i fornitori che supportano funzioni essenziali o importanti. DORA Article 17 richiede un processo di gestione degli incidenti connessi all’ICT, Article 18 definisce le aspettative di classificazione e Article 19 disciplina la segnalazione degli incidenti gravi connessi all’ICT all’autorità competente.

GDPR aggiunge la dimensione della tutela della privacy. Un incidente di cibersicurezza può diventare una violazione dei dati personali se comporta distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato a dati personali, in modo accidentale o illecito. Il titolare del trattamento deve essere in grado di dimostrare la propria responsabilizzazione, valutare il rischio per le persone fisiche e, ove richiesto, notificare l’autorità di controllo ed eventualmente gli interessati coinvolti.

Un registro dei contatti regolamentari maturo deve quindi rispondere a cinque domande sotto pressione:

• Quale CSIRT, autorità competente, autorità di vigilanza finanziaria, autorità di controllo per la protezione dei dati e contatto delle forze dell’ordine si applica a questa entità giuridica, giurisdizione e servizio?
• Quale ruolo interno è autorizzato ad avviare il contatto, approvare il testo e inviare le notifiche?
• Quali fornitori devono essere contattati per contenimento, log, ripristino, preservazione delle evidenze o segnalazioni contrattuali?
• Quale percorso di comunicazione verso clienti, controparti o pubblico viene attivato a ciascun livello di gravità?
• Come dimostriamo che il registro è stato riesaminato, testato e usato correttamente?

La risposta non può risiedere solo nella posta in arrivo della funzione legale o nella memoria del CISO. Deve essere una registrazione controllata del SGSI.

Che cosa contiene un registro dei contatti NIS2 e DORA pronto per le evidenze

Un registro dei contatti regolamentari deve essere progettato per l’uso durante un incidente reale. Se il responsabile della gestione dell’incidente deve prendere la prima decisione di escalation in pochi minuti, il registro non può essere un elenco vago di siti web. Deve essere strutturato, verificato e collegato al playbook di risposta.

Un registro completo dovrebbe includere almeno sei famiglie di contatti.

Prima: autorità ufficiali di cibersicurezza, quali CSIRT nazionali, autorità competenti, punti di contatto unici ove applicabili e agenzie settoriali di cibersicurezza.

Seconda: autorità di vigilanza finanziaria per DORA, incluse autorità competenti e canali di segnalazione usati per le segnalazioni iniziali, intermedie e finali degli incidenti gravi connessi all’ICT.

Terza: autorità privacy, incluse autorità di controllo per la protezione dei dati, logica di autorità capofila per i trattamenti transfrontalieri e percorsi di escalation del DPO.

Quarta: forze dell’ordine, incluse unità cybercrime, unità antifrode e contatti di emergenza per estorsione, ransomware, accesso non autorizzato e preservazione delle evidenze.

Quinta: fornitori e terze parti ICT, inclusi fornitori cloud, fornitori di Managed Security Services, prestatori di servizi gestiti, piattaforme di identità, processori di pagamento, fornitori di analisi forense digitale e consulenti legali.

Sesta: ruoli di escalation interni, inclusi responsabile della gestione dell’incidente, CISO, DPO, consulente legale interno, responsabile delle comunicazioni, responsabile della continuità operativa, approvatore esecutivo, referente del Consiglio di amministrazione e proprietario del servizio.

Il registro dovrebbe includere anche gruppi di interesse specialistico, ove pertinenti, come ISAC o community settoriali di condivisione delle informazioni. Non sono autorità regolatorie, ma possono diventare canali importanti per informazioni sulle minacce e risposta coordinata.

Il Zenith Blueprint rende operativo questo approccio al passo 22:

Creare o aggiornare procedure per coinvolgere le autorità durante gli eventi di sicurezza (5.5), includendo i recapiti dei CERT locali, delle autorità regolatorie e delle forze dell’ordine. Mantenere un elenco di contatti analogo per la partecipazione a forum sulla sicurezza o gruppi settoriali (5.6). Conservare queste informazioni in un luogo accessibile ma soggetto a controllo degli accessi e includerle nel runbook di risposta agli incidenti.

Quest’ultima frase è fondamentale. Se il registro non è nel runbook di risposta agli incidenti, difficilmente verrà usato quando la pressione è reale.

Esempio di struttura del registro dei contatti per un fornitore FinTech o SaaS

Immaginiamo un fornitore SaaS fintech che supporta analisi dei pagamenti per clienti dell’UE. Utilizza un fornitore cloud, un fornitore di rilevamento gestito, una piattaforma di identità, una piattaforma di assistenza clienti e un consulente legale esterno. A seconda del suo ruolo, potrebbe essere un’entità finanziaria, un fornitore terzo di servizi ICT, un fornitore digitale nel campo di applicazione di NIS2 oppure un responsabile del trattamento di dati personali ai sensi del GDPR.

Un registro pratico potrebbe iniziare così:

Le voci non devono contenere dati personali non necessari. Utilizzare contatti basati sui ruoli ogni volta che è possibile, proteggere i recapiti sensibili e assicurare disponibilità offline durante una grave indisponibilità. Un registro accessibile solo dagli stessi sistemi colpiti da un incidente ransomware non è resiliente.

Mappatura del registro alle evidenze ISO/IEC 27001:2022

Gli auditor raramente rilevano una carenza perché un’organizzazione non ha un foglio di calcolo. La rilevano perché l’organizzazione non può dimostrare che quel foglio di calcolo sia completo, aggiornato, approvato, protetto, testato e collegato ai processi effettivi.

ISO/IEC 27001:2022 parte dal contesto dell’organizzazione. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere i fattori interni ed esterni, identificare le parti interessate e i loro requisiti, definire il campo di applicazione del SGSI e comprendere interfacce e dipendenze. Un registro dei contatti regolamentari è un’evidenza solida del fatto che requisiti legali, regolamentari, contrattuali e degli stakeholder sono stati tradotti in relazioni operative.

Segue la leadership. Le clausole da 5.1 a 5.3 richiedono all’alta direzione di dimostrare leadership, assegnare responsabilità, assicurare la comunicazione e supportare il SGSI. Se il registro identifica chi è autorizzato a notificare un CSIRT, un’autorità di vigilanza o un’autorità di controllo, chi approva le comunicazioni esterne e chi riferisce lo stato dell’incidente all’alta direzione, supporta le evidenze di leadership.

La pianificazione del rischio trasforma poi gli obblighi in azione. Le clausole da 6.1.1 a 6.1.3 richiedono un processo di valutazione e trattamento del rischio, il confronto con l’Annex A, una Dichiarazione di Applicabilità, un Piano di trattamento del rischio e l’accettazione del rischio residuo. Il registro dovrebbe comparire nel piano di trattamento per rischi quali mancata notifica legale, escalation tardiva degli incidenti, mancata risposta dei fornitori, errore di notifica transfrontaliera e interruzione delle comunicazioni di continuità operativa.

Gli ancoraggi dei controlli dell’Annex A sono chiari:

In Zenith Controls: guida alla conformità trasversale Zenith Controls, il contatto con le autorità è trattato come controllo 5.5 con caratteristiche preventive e correttive. Supporta riservatezza, integrità e disponibilità e si collega ai concetti di cibersicurezza Identify, Protect, Respond e Recover. Zenith Controls lo collega alla pianificazione degli incidenti, alla segnalazione degli eventi, alle informazioni sulle minacce, ai gruppi di interesse specialistico e alla risposta agli incidenti. Spiega inoltre perché contatti prestabiliti con autorità regolatorie, forze dell’ordine, CERT nazionali o autorità di protezione dei dati consentono escalation più rapida e guida durante eventi quali violazioni significative o attacchi ransomware.

Il controllo non è isolato. Zenith Controls mappa anche il controllo 6.8, segnalazione degli eventi di sicurezza delle informazioni, come controllo di rilevamento collegato a pianificazione degli incidenti, valutazione degli eventi, risposta, lezioni apprese, sensibilizzazione, monitoraggio e processo disciplinare. Il controllo 5.24, pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, si collega a valutazione degli eventi, lezioni apprese, logging, monitoraggio, sicurezza durante le interruzioni, continuità e contatto con le autorità. La narrazione di audit diventa più solida quando gli eventi sono segnalati, valutati, oggetto di escalation, comunicati, documentati con evidenze e migliorati.

NIS2, DORA e GDPR: un solo registro, termini legali diversi

Un singolo incidente può attivare diversi flussi legali. Un accesso non autorizzato presso un fornitore SaaS potrebbe essere un incidente significativo NIS2, una violazione dei dati personali GDPR e un evento di notifica contrattuale verso i clienti. Un’indisponibilità presso un’entità finanziaria potrebbe essere un incidente grave connesso all’ICT ai sensi di DORA, richiedendo al contempo analisi GDPR e coordinamento con i fornitori.

NIS2 richiede alle entità essenziali e importanti di notificare senza indebito ritardo al proprio CSIRT o all’autorità competente gli incidenti significativi che incidono sulla fornitura dei servizi. Il modello di segnalazione per fasi comprende un allarme tempestivo senza indebito ritardo ed entro 24 ore dalla conoscenza dell’incidente, una notifica dell’incidente senza indebito ritardo ed entro 72 ore, relazioni intermedie sullo stato su richiesta e una relazione finale entro un mese dalla notifica dell’incidente. Se l’incidente è ancora in corso, può essere richiesta anche una rendicontazione dello stato di avanzamento.

DORA richiede alle entità finanziarie di mantenere un processo di gestione degli incidenti connessi all’ICT che rilevi, gestisca e notifichi gli incidenti, registri incidenti e minacce informatiche significative, classifichi gravità e criticità, assegni ruoli, definisca escalation e comunicazione, segnali gli incidenti gravi all’alta direzione e supporti il ripristino tempestivo. La segnalazione degli incidenti gravi connessi all’ICT segue una logica di report iniziali, intermedi e finali, con classificazione basata su fattori quali clienti interessati, durata, diffusione geografica, perdita di dati, criticità dei servizi e impatto economico.

GDPR aggiunge la valutazione della violazione dei dati personali. Un registro dei contatti non decide da solo se sussista l’obbligo legale di segnalazione. Assicura che le persone giuste possano decidere rapidamente, usando canali aggiornati e criteri documentati.

La libreria di politiche Clarysec rende operativo questo approccio. Nella Politica di risposta agli incidenti per PMI Politica di risposta agli incidenti - PMI, la clausola 5.1.1 stabilisce:

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

La stessa politica per PMI, alla clausola 7.4.1, aggiunge:

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

Per gli ambienti enterprise, la Politica di risposta agli incidenti Politica di risposta agli incidenti, clausola 5.5, stabilisce il quadro di comunicazione:

Tutte le comunicazioni relative agli incidenti devono seguire la matrice di comunicazione ed escalation, assicurando:

La clausola 6.4.2 aggiunge il requisito probatorio:

Tutte le notifiche di violazione devono essere documentate e approvate prima dell’invio e le copie devono essere conservate nel SGSI.

È qui che il registro diventa evidenza ISO. Non riguarda solo sapere chi chiamare. Riguarda dimostrare chi era autorizzato, che cosa è stato valutato, che cosa è stato approvato, che cosa è stato inviato e dove si trova la copia conservata.

Il modello di evidenze Clarysec: quattro artefatti che lavorano insieme

Una solida capacità di gestione dei contatti regolamentari richiede quattro artefatti che funzionano come un’unica catena di evidenze.

Il registro dei contatti regolamentari identifica contatti, canali, trigger e proprietari. La matrice di comunicazione ed escalation definisce chi fa che cosa. Il log decisionale registra classificazione, valutazione di notificabilità, riesame legale e approvazione. Il pacchetto di evidenze di notifica conserva notifiche inviate, ricevute dei portali, e-mail, note di chiamata, feedback dell’autorità, risposte dei fornitori e relazioni finali.

La Politica di conformità legale e normativa di Clarysec Politica di conformità legale e normativa - PMI rende esplicito il concetto di registro. La clausola 5.5.2 stabilisce:

I termini chiave di conformità (ad esempio, tempistiche di notifica delle violazioni e clausole di gestione dei dati) devono essere estratti e tracciati nel Registro di conformità.

Il Registro di conformità dovrebbe alimentare il registro dei contatti regolamentari. Il requisito legale potrebbe indicare “allarme tempestivo NIS2 entro 24 ore”, mentre il registro dei contatti identifica il portale del CSIRT nazionale, il numero di reperibilità alternativo, il soggetto autorizzato all’invio, il revisore legale, le evidenze richieste e il percorso di conservazione.

Le politiche di continuità operativa rafforzano la stessa aspettativa. La Politica di continuità operativa e disaster recovery per PMI Politica di continuità operativa e disaster recovery - PMI, clausola 5.2.1.1, fa riferimento a:

elenchi di contatti e piani di comunicazione alternativi

La Politica di continuità operativa e disaster recovery enterprise Politica di continuità operativa e disaster recovery, clausola 5.3.3, richiede che le soluzioni di continuità siano:

supportate da elenchi di contatti aggiornati e flussi di escalation

Anche la governance dei fornitori rientra nel modello. Nella Politica di sicurezza di terze parti e fornitori per PMI Politica di sicurezza di terze parti e fornitori - PMI, la clausola 5.4.3 richiede una:

persona di contatto assegnata

Per NIS2 e DORA, tale contatto non può essere generico. Se un fornitore cloud critico, un fornitore di servizi di sicurezza gestiti, un provider di identità o un processore di pagamento supporta un servizio regolamentato, il registro dovrebbe identificare il contatto operativo, il contatto per gli incidenti di sicurezza, il canale di comunicazione contrattuale e il percorso di escalation per le richieste di evidenze.

Costruire il registro in una sola sessione operativa

Un registro utile può essere costruito rapidamente se nella stanza sono presenti le persone giuste. Pianificare una sessione di due ore con CISO, DPO, consulente legale, responsabile fornitori, responsabile della continuità operativa, responsabile della gestione degli incidenti e responsabile della conformità.

Partire dal Registro di conformità. Estrarre gli obblighi di segnalazione NIS2, DORA, GDPR, contrattuali e settoriali. Registrare tempistiche, criteri di notificabilità e requisiti probatori.

Aprire il runbook di risposta agli incidenti. Per ciascuna categoria di incidente, come ransomware, accesso non autorizzato, indisponibilità del servizio, esfiltrazione di dati, incidente del fornitore e guasto di una regione cloud, identificare i contatti esterni necessari.

Popolare il registro dei contatti regolamentari con autorità, giurisdizione, trigger, canale primario, canale alternativo, proprietario, approvatore, evidenze necessarie, data dell’ultima validazione e luogo di conservazione.

Collegare i contatti dei fornitori. Per ciascuna funzione essenziale o importante, identificare il contatto del provider per gli incidenti di sicurezza, il canale di comunicazione contrattuale, il contatto di audit e il percorso di escalation di emergenza.

Riesaminare rispetto alle politiche. Confermare che l’autorità di escalation corrisponda alla Politica di risposta agli incidenti, che le evidenze di notifica siano conservate nel SGSI, che gli elenchi di contatti per la continuità operativa siano allineati e che i contatti dei fornitori abbiano proprietari assegnati.

Testare uno scenario. Usare un’esercitazione tabletop mirata: “Esposizione dei dati dei clienti rilevata alle 02:17, che interessa clienti UE ed è forse causata da credenziali di un provider di identità compromesse.” Chiedere al team di identificare se possano essere richieste notifiche a CSIRT, autorità di controllo, autorità di vigilanza finanziaria, fornitore e clienti. L’obiettivo non è imporre una conclusione legale definitiva durante l’esercitazione. L’obiettivo è dimostrare dove si trovano i contatti, chi approva il contatto, quali evidenze sono necessarie e dove vengono registrate le decisioni.

Creare il pacchetto di evidenze. Salvare la versione del registro, i partecipanti alla riunione, le approvazioni, le note di scenario, il log decisionale, le azioni aperte e il riferimento aggiornato al runbook.

È qui che il passo 23 del Zenith Blueprint diventa pratico:

Assicurare la disponibilità di un piano di risposta agli incidenti aggiornato (5.24), che copra preparazione, escalation, risposta e comunicazione. Definire che cosa costituisce un evento di sicurezza soggetto a segnalazione (5.25) e come viene attivato e documentato il processo decisionale. Selezionare un evento recente o condurre un’esercitazione tabletop per validare il piano.

L’esercitazione non deve essere elaborata. Deve dimostrare la capacità di rispondere e fornire evidenze.

Mappatura trasversale della conformità: un registro, molti framework

Il valore di un registro dei contatti regolamentari è che riduce la duplicazione degli sforzi di conformità. Un unico artefatto pronto per le evidenze può supportare ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e aspettative di governance COBIT 2019.

NIST CSF 2.0 è particolarmente utile come livello di integrazione. La sua funzione GOVERN richiede alle organizzazioni di comprendere stakeholder, obblighi legali e normativi, servizi critici, dipendenze, propensione al rischio, ruoli, politiche, supervisione e rischio dei fornitori. I suoi CSF Profile aiutano le organizzazioni a documentare un Current Profile, definire un Target Profile, analizzare le lacune e creare un piano d’azione prioritizzato. Un registro dei contatti regolamentari può essere un’evidenza concreta che chiude la lacuna tra governance degli incidenti attuale e target.

Per la catena di fornitura, NIST CSF 2.0 richiede che fornitori, clienti e partner abbiano ruoli e responsabilità di cibersicurezza definiti, che la criticità dei fornitori sia nota, che i requisiti di cibersicurezza siano incorporati negli accordi, che i rischi dei fornitori siano valutati e che i fornitori rilevanti siano inclusi nella pianificazione, risposta e ripristino degli incidenti. Questo si mappa direttamente al rischio ICT di terze parti DORA e alle aspettative NIS2 sulla catena di fornitura.

Come auditor e autorità di vigilanza testeranno lo stesso registro

Un registro ben mantenuto verrà esaminato in modo diverso a seconda della prospettiva del revisore.

Un auditor ISO/IEC 27001:2022 partirà dal campo di applicazione e dalle parti interessate. Chiederà come l’organizzazione ha identificato autorità applicabili, obblighi legali, obblighi contrattuali di notifica e dipendenze esternalizzate. Poi traccerà il registro fino alla Dichiarazione di Applicabilità, al piano di risposta agli incidenti, al piano di continuità operativa e alla conservazione delle evidenze. Potrebbe campionare un contatto e chiedere prova dell’ultima validazione.

Un assessor NIS2 si concentrerà sul fatto che l’entità abbia identificato il CSIRT o l’autorità competente corretti e che le soglie degli incidenti significativi siano rese operative. Cercherà un processo in grado di supportare l’allarme tempestivo entro 24 ore, la notifica entro 72 ore e la rendicontazione finale. Verificherà anche la supervisione dell’organo di gestione, perché NIS2 Article 20 rende la governance della cibersicurezza una responsabilità della leadership.

Un’autorità di vigilanza DORA o un gruppo di audit interno verificherà se il registro supporta gestione degli incidenti, classificazione, segnalazione degli incidenti gravi connessi all’ICT, comunicazione di crisi, reporting all’alta direzione, coordinamento dei fornitori e ripristino operativo. Potrebbe chiedere se esistano contatti per fornitori terzi di servizi ICT che supportano funzioni essenziali o importanti e se gli obblighi di comunicazione siano riflessi nei contratti.

Un auditor GDPR o un riesame del DPO si concentrerà sulla valutazione della violazione dei dati personali. Chiederà se il DPO e i referenti legali privacy siano coinvolti precocemente, se i ruoli di titolare e responsabile del trattamento siano chiari, se l’autorità di controllo corretta sia identificata e se le decisioni di comunicazione agli interessati siano registrate.

Un assessor NIST CSF tratterà il registro come evidenza per gli esiti GOVERN: aspettative degli stakeholder, obblighi legali, ruoli, politiche, supervisione e rischio della catena di fornitura. Un auditor COBIT 2019 o in stile ISACA esaminerà se le esigenze degli stakeholder siano tradotte in pratiche di governance e gestione, se le responsabilità siano assegnate e se la prestazione del processo sia monitorata.

Lo stesso artefatto deve reggere tutte queste domande. Per questo il registro deve essere controllato, assegnato a un proprietario, riesaminato, protetto mediante controllo degli accessi e testato.

Schemi di errore comuni nella governance dei contatti

Le organizzazioni raramente falliscono perché non hanno alcun contatto. Falliscono perché i contatti non sono affidabili durante un incidente reale.

Ogni problema genera una risultanza di audit prevedibile. La remediation è altrettanto prevedibile: allineare il registro alla politica, integrarlo nella risposta agli incidenti, validare i contatti, testare il flusso e conservare le evidenze.

Responsabilità del Consiglio di amministrazione e della direzione

NIS2 richiede agli organi di gestione di approvare le misure di gestione del rischio di cibersicurezza, sovrintenderne l’attuazione e seguire la formazione. DORA Article 5 rende l’organo di gestione responsabile di definire, approvare, supervisionare e assumere responsabilità per gli assetti di rischio ICT, incluse politiche, ruoli, continuità operativa ICT, piani di risposta e ripristino, politica sulle terze parti ICT, sensibilizzazione e formazione. ISO/IEC 27001:2022 richiede alla leadership di allineare il SGSI alla direzione strategica, fornire risorse, assegnare responsabilità e supportare il miglioramento continuo.

Il Consiglio di amministrazione non deve memorizzare il numero di telefono del CSIRT. Deve però avere assurance che la capacità di notifica esista, abbia un proprietario, sia testata e sia riesaminata.

Un pacchetto trimestrale per la direzione dovrebbe includere:

• Stato del riesame del registro dei contatti regolamentari
• Modifiche ad autorità, autorità di vigilanza o giurisdizioni applicabili
• Lacune aperte nei contatti dei fornitori per gli incidenti
• Esiti delle esercitazioni tabletop e lezioni apprese
• Evidenza del test del flusso di approvazione delle notifiche
• Metriche sul tempo dalla rilevazione alla decisione di escalation
• Aggiornamenti degli obblighi di segnalazione NIS2, DORA, GDPR e contrattuali
• Rischi residui che richiedono accettazione da parte della direzione

Questo sposta il registro da foglio di calcolo operativo a controllo di governance.

Come Clarysec ti aiuta a costruire una governance dei contatti pronta per l’audit

Clarysec collega testo delle politiche, sequenziamento dell’attuazione e mappatura dei controlli cross-framework in un unico percorso di evidenze.

La libreria di politiche definisce responsabilità e registrazioni richieste. La Politica di risposta agli incidenti stabilisce aspettative di escalation, approvazione delle notifiche e conservazione. La Politica di conformità legale e normativa richiede il tracciamento di termini di conformità come le tempistiche di notifica delle violazioni. La Politica di continuità operativa e disaster recovery richiede elenchi di contatti aggiornati e piani di comunicazione alternativi. La Politica di sicurezza di terze parti e fornitori richiede contatti dei fornitori assegnati.

Il Zenith Blueprint fornisce il sequenziamento dell’attuazione. Il passo 5 nella fase ISMS Foundation & Leadership affronta comunicazione, sensibilizzazione e competenza, inclusi stakeholder esterni, tempistiche, ruoli dei comunicatori e piani di comunicazione. Il passo 22 integra i contatti con autorità e gruppi di interesse specialistico nei controlli organizzativi. Il passo 23 valida gestione degli incidenti, decisioni sugli eventi soggetti a segnalazione, preservazione delle evidenze forensi e lezioni apprese.

La guida Zenith Controls fornisce la bussola di conformità trasversale. Mostra come il contatto con le autorità si colleghi a pianificazione degli incidenti, segnalazione degli eventi, informazioni sulle minacce, gruppi di interesse specialistico e risposta agli incidenti. Mostra inoltre perché la segnalazione degli eventi di sicurezza delle informazioni e la preparazione agli incidenti sono componenti necessarie. Un registro dei contatti è efficace solo se gli eventi vengono segnalati e valutati con sufficiente anticipo per attivarlo.

Per le PMI, ciò significa un registro snello ma sostenibile, responsabilità chiare ed evidenze proporzionate. Per le imprese, significa integrazione tra giurisdizioni, entità giuridiche, unità organizzative, fornitori, autorità regolatorie, autorità di vigilanza, CSIRT e reporting al Consiglio di amministrazione.

Prossimi passi: costruire il registro prima che il cronometro parta

Se la tua organizzazione si sta preparando a NIS2, DORA, capacità di notifica delle violazioni GDPR o certificazione ISO/IEC 27001:2022, non aspettare un incidente live per scoprire se la tua governance dei contatti funziona.

Inizia questa settimana con quattro azioni:

1. Crea o aggiorna il registro dei contatti regolamentari per CSIRT, autorità competenti, autorità di vigilanza finanziaria, autorità di controllo per la protezione dei dati, forze dell’ordine, fornitori critici e ruoli interni di escalation.
2. Mappa ciascun contatto a trigger, proprietario, percorso di approvazione, requisito probatorio e luogo di conservazione.
3. Esegui un’esercitazione tabletop focalizzata su decisioni di notifica, contatto con le autorità, coordinamento dei fornitori e conservazione delle evidenze.
4. Aggiorna le registrazioni del SGSI, inclusi Registro di conformità, runbook di risposta agli incidenti, elenchi di contatti per la continuità operativa e registrazioni dei contatti dei fornitori.

Clarysec può aiutarti ad attuarlo rapidamente usando il Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls e le nostre librerie di politiche per PMI e imprese, incluse la Politica di risposta agli incidenti Politica di risposta agli incidenti, la Politica di conformità legale e normativa Politica di conformità legale e normativa - PMI, la Politica di continuità operativa e disaster recovery Politica di continuità operativa e disaster recovery e la Politica di sicurezza di terze parti e fornitori Politica di sicurezza di terze parti e fornitori - PMI.

Il termine di 24 ore non si ferma mentre il team cerca il contatto corretto. Costruisci ora il registro, testalo e rendilo parte delle tue evidenze ISO prima che sia il prossimo incidente a decidere la timeline per te.