Guida 2026 al registro degli obblighi di conformità in materia di cibersicurezza

Maria, Chief Information Security Officer (CISO) di una piattaforma fintech in rapida crescita, aveva venti minuti prima della chiusura del pacchetto trimestrale per il consiglio di amministrazione. Il messaggio del CEO era breve e scomodo:

“Maria, mi serve una sola slide che dimostri che abbiamo sotto controllo i nostri obblighi legali di cibersicurezza per il 2026. Non solo ISO 27001. Intendo tutto: NIS2, DORA, GDPR, i contratti con i clienti. Siamo conformi? Dov’è la prova? Chi ne è responsabile?”

Alle 08:15 sono arrivate altre tre richieste. La Funzione legale voleva sapere se la società fosse un’entità importante ai sensi delle norme nazionali di recepimento della NIS2 in uno Stato membro. Il DPO voleva capire se un’esportazione sospetta da un database dovesse essere gestita come violazione dei dati personali ai sensi del GDPR, come incidente grave connesso alle TIC ai sensi di DORA, come entrambe le cose o come nessuna delle due. L’Ufficio acquisti chiedeva l’approvazione di un fornitore di analytics antifrode che avrebbe trattato dati personali UE, supportato un servizio critico e utilizzato un sub-responsabile cloud al di fuori dell’UE.

Nessuna di queste domande è insolita nel 2026. Il rischio nasce quando l’organizzazione non è in grado di rispondere partendo da un’unica fonte autorevole, aggiornata e mantenuta nel tempo.

La maggior parte delle aziende dispone di politiche. Molte hanno registri dei rischi, fascicoli dei fornitori, registri privacy, playbook per gli incidenti e una Dichiarazione di applicabilità. La lacuna emerge però quando un membro del consiglio di amministrazione, un auditor, un’autorità di regolamentazione o un grande cliente formula una domanda semplice:

“Mostratemi ciascun obbligo di cibersicurezza legale, normativo e contrattuale applicabile, chi ne è titolare, con quale frequenza viene riesaminato, quale controllo lo attua, quale evidenza lo dimostra e in che modo le eccezioni arrivano alla direzione.”

Questo è il registro degli obblighi di conformità in materia di cibersicurezza.

Per CISO, responsabili della conformità, auditor e responsabili di business, questo registro non è più un foglio di calcolo amministrativo. È il meccanismo operativo che collega obblighi nazionali NIS2, aspettative di vigilanza DORA, accountability GDPR, requisiti ISO/IEC 27001:2022, contratti con i clienti e politiche interne in un sistema di governance funzionante.

Clarysec considera il registro un elemento vivo del SGSI, non un’appendice legale. Nella Politica di conformità legale e normativa, la funzione Compliance:

“Mantiene il Registro di conformità, che elenca tutte le leggi, gli standard, le certificazioni e le clausole contrattuali applicabili.”
Tratto da Politica di conformità legale e normativa, Ruoli e responsabilità, clausola 4.2.1.

La parola chiave è “mantiene”. Un registro creato per la certificazione e ignorato fino all’audit successivo non è un meccanismo di conformità. È evidenza di ottimismo storico.

Cosa deve fare un registro degli obblighi di conformità in materia di cibersicurezza nel 2026

Un registro degli obblighi efficace svolge cinque funzioni.

In primo luogo, identifica gli obblighi. Questi includono leggi, regolamenti, standard, certificazioni e clausole contrattuali. Nel 2026, le fonti comuni includono NIS2 per entità essenziali e importanti, DORA per le entità finanziarie soggette al regolamento e i fornitori terzi di servizi TIC, GDPR per titolari del trattamento e responsabili del trattamento che gestiscono dati personali UE, requisiti ISO/IEC 27001:2022 per il SGSI, impegni di sicurezza cloud, clausole di notifica delle violazioni nei contratti con i clienti, regole di outsourcing e requisiti di sicurezza dei fornitori.

In secondo luogo, classifica l’applicabilità. NIS2 può applicarsi perché l’organizzazione rientra in un settore dell’allegato I o dell’allegato II, fornisce infrastruttura digitale, opera come prestatore di servizi gestiti, eroga servizi di cloud computing o rientra in una categoria indipendente dalle dimensioni, come DNS, TLD o servizi fiduciari. DORA può applicarsi perché l’organizzazione è un’entità finanziaria o un fornitore terzo di servizi TIC che supporta entità finanziarie. GDPR può applicarsi perché l’organizzazione tratta dati personali UE, offre servizi a persone fisiche nell’UE o monitora comportamenti nell’UE.

In terzo luogo, mappa gli obblighi rispetto a controlli interni, politiche, processi e sistemi. È qui che il registro diventa operativo. Le misure di gestione del rischio previste da NIS2 Article 21 si mappano su valutazione del rischio, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, riesami dell’efficacia dei controlli, formazione, crittografia, controllo degli accessi, gestione degli asset e autenticazione a più fattori (MFA), ove appropriato. DORA si mappa su accountability dell’organo di gestione, gestione del rischio TIC, classificazione degli incidenti, test di resilienza, registri delle terze parti e strategie di uscita. GDPR si mappa su registri delle attività di trattamento, base giuridica, minimizzazione dei dati, conservazione, sicurezza del trattamento, valutazione delle violazioni ed evidenze di accountability.

In quarto luogo, assegna titolari e frequenza di riesame. Senza titolarità, la conformità diventa un tema da riunione. Con una titolarità chiara, diventa un processo gestito.

In quinto luogo, definisce le evidenze. Il registro deve rispondere a una domanda: quale evidenza dimostra oggi che questo obbligo è soddisfatto? Le evidenze possono includere verbali del consiglio di amministrazione, registrazioni della valutazione del rischio, ticket di incidente, due diligence sui fornitori, clausole contrattuali, configurazioni di cifratura, report sulle vulnerabilità, riesami degli accessi, registrazioni dei test di backup, informative privacy, DPIA, valutazioni delle violazioni e risultanze di audit interno.

La politica di Clarysec rende esplicita questa tracciabilità:

“Tutti gli obblighi legali e normativi devono essere mappati rispetto a politiche, controlli e titolari specifici nell’ambito del Sistema di gestione della sicurezza delle informazioni (SGSI).”
Tratto da Politica di conformità legale e normativa, Requisiti di applicazione della politica, clausola 6.2.1.

Definisce inoltre le evidenze come parte dello stesso meccanismo:

“Elementi o registrazioni richiesti per dimostrare la conformità (ad esempio, log di audit, impostazioni di cifratura, documentazione del consenso)”
Tratto da Politica di conformità legale e normativa, Requisiti di applicazione della politica, clausola 6.2.2.3.

Questa è la differenza tra consapevolezza della conformità e assurance della conformità.

Perché ISO/IEC 27001:2022 è la dorsale

ISO/IEC 27001:2022 viene spesso trattata come obiettivo di certificazione, ma per la gestione degli obblighi il suo valore è ancora maggiore. Offre al registro una collocazione all’interno del sistema di gestione.

Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere i fattori interni ed esterni, identificare le parti interessate e determinare i requisiti legali, normativi e contrattuali pertinenti al SGSI. Le clausole da 5.1 a 5.3 richiedono impegno della leadership, allineamento delle politiche, risorse e responsabilità assegnate. Le clausole da 6.1 a 6.2 richiedono valutazione del rischio, trattamento del rischio, Dichiarazione di applicabilità e obiettivi misurabili informati dai requisiti applicabili. Le clausole 8, 9 e 10 creano il ciclo operativo: attuare i controlli, rivalutare i rischi, monitorare le prestazioni, svolgere audit interni, effettuare il Riesame della direzione e correggere le non conformità.

In Zenith Blueprint: roadmap in 30 passi per auditor, Clarysec colloca questo tema nelle fasi iniziali di fondazione e leadership del SGSI, Step 2: esigenze delle parti interessate e ambito di applicazione del SGSI. Il Blueprint raccomanda ai team di identificare i requisiti delle parti interessate riesaminando requisiti legali e normativi, estraendo clausole contrattuali di sicurezza, intervistando gli stakeholder e considerando gli standard di settore attesi dai partner.

“La clausola 4.2 non richiede un documento specifico, ma in pratica è utile creare una tabella di analisi degli stakeholder. Può essere una tabella semplice con le colonne: parte interessata, esigenze/aspettative, come le affrontiamo.”
Tratto da Zenith Blueprint, fase Fondazione e leadership del SGSI, Step 2.

Quell’analisi degli stakeholder diventa l’input a monte del registro degli obblighi. Il registro diventa quindi il ponte verso il trattamento del rischio.

Nella fase Gestione del rischio, Step 13, Zenith Blueprint indica ai team di mappare i controlli rispetto a rischi, clausole e normative esterne:

“Effettuare riferimenti incrociati alle normative: se determinati controlli sono implementati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.”
Tratto da Zenith Blueprint, fase Gestione del rischio, Step 13: pianificazione del trattamento del rischio e Dichiarazione di applicabilità.

Questa è la tracciabilità che gli auditor si aspettano. Se GDPR guida controlli di cifratura, conservazione e valutazione delle violazioni, va indicato. Se NIS2 guida escalation per la segnalazione degli incidenti e misure di sicurezza dei fornitori, va indicato. Se DORA guida registri del rischio TIC di terze parti e test di uscita, va indicato.

I tre riferimenti di controllo ISO/IEC 27002:2022

Il controllo ISO/IEC 27002:2022 centrale per la gestione degli obblighi è 5.31, requisiti legali, statutari, normativi e contrattuali. La guida Zenith Controls: guida alla cross-compliance di Clarysec classifica 5.31 come controllo preventivo collegato a riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Identify e operante nella capability Legale e conformità attraverso i domini governance, ecosistema e protezione.

La narrazione di Zenith Controls è diretta:

“La sicurezza non esiste nel vuoto. Opera all’interno di una rete di obblighi, alcuni definiti dalla legge, altri dai contratti e altri ancora da regolamenti settoriali.”
Tratto da Zenith Controls, trattamento del controllo ISO/IEC 27002:2022 5.31.

Il controllo 5.31 non opera da solo. Sono essenziali due controlli di supporto.

Il controllo 5.2, ruoli e responsabilità per la sicurezza delle informazioni, assicura che gli obblighi non siano assegnati in modo astratto “al business” o “all’IT”. La mappatura di Zenith Controls collega 5.2 a titolarità delle politiche, monitoraggio della conformità, gestione degli incidenti, sensibilizzazione, riesame indipendente, gestione delle evidenze e governance degli accessi privilegiati.

Il controllo 5.36, conformità a politiche, regole e standard per la sicurezza delle informazioni, chiude il ciclo. Garantisce che i requisiti documentati siano seguiti, monitorati, segnalati e corretti. La mappatura di Zenith Controls collega 5.36 alle politiche per la sicurezza delle informazioni, al processo disciplinare, al riesame indipendente, a ruoli e responsabilità, alla valutazione degli eventi, alla registrazione, al monitoraggio e alle registrazioni protette.

Insieme, questi controlli rispondono alle domande fondamentali dell’auditor.

Per le organizzazioni più piccole, la stessa struttura può essere più leggera. La Politica di conformità legale e normativa - PMI di Clarysec stabilisce:

“Il Direttore generale deve mantenere un Registro di conformità semplice e strutturato che elenchi:”
Tratto da Politica di conformità legale e normativa - PMI, Requisiti di governance, clausola 5.1.1.

Richiede inoltre un riesame ordinario:

“Il Registro di conformità deve essere riesaminato trimestralmente e aggiornato quando:”
Tratto da Politica di conformità legale e normativa - PMI, Requisiti di governance, clausola 5.1.2.

Per le PMI, il registro può iniziare in modo semplice. Deve comunque includere titolarità, cadenza ed evidenze.

Costruire il registro intorno agli obblighi, non ai framework

L’errore più comune è creare un tracker per NIS2, un altro per DORA, un altro per GDPR, un altro per ISO/IEC 27001:2022 e un altro ancora per i contratti con i clienti. Questo genera richieste di evidenze duplicate, titolari in conflitto e team sovraccarichi.

L’approccio migliore è la mappatura obbligo-controllo. Una singola capability di sicurezza può soddisfare più driver legali se il registro conserva le differenze di trigger, ambito, tempistica e autorità.

Ad esempio, la risposta agli incidenti supporta la segnalazione degli incidenti significativi NIS2, la segnalazione degli incidenti gravi connessi alle TIC ai sensi di DORA e la valutazione delle violazioni dei dati personali ai sensi del GDPR. La due diligence sui fornitori supporta la sicurezza della catena di fornitura NIS2, il rischio TIC di terze parti DORA e la governance dei responsabili del trattamento GDPR. Logging e monitoraggio supportano rilevazione degli incidenti, efficacia dei controlli e accountability. Gli inventari degli asset e dei dati supportano la valutazione del rischio NIS2, DORA, GDPR e ISO/IEC 27001:2022.

L’obiettivo non è nascondere le differenze legali. L’obiettivo è evitare di implementare la stessa capability tre volte.

Un modello pratico di registro da implementare questa settimana

Un registro degli obblighi in stile Clarysec deve essere abbastanza semplice da mantenere e abbastanza dettagliato da reggere un campionamento di audit. I campi minimi sono:

1. ID dell’obbligo.
2. Fonte, ad esempio NIS2, DORA, GDPR, ISO/IEC 27001:2022, contratto con il cliente o politica interna.
3. Articolo, clausola o riferimento contrattuale specifico.
4. Sintesi del requisito.
5. Razionale di applicabilità.
6. Processo aziendale o servizio interessato.
7. Scenario di rischio in caso di mancato adempimento.
8. Mappatura dei controlli, inclusi controlli ISO/IEC 27002:2022 e riferimenti alle politiche interne.
9. Titolare del controllo.
10. Responsabile delle evidenze.
11. Frequenza di riesame.
12. Ubicazione delle evidenze.
13. Eccezioni o lacune aperte.
14. Flag di escalation al Riesame della direzione.
15. Data dell’ultimo riesame e data del prossimo riesame.
16. Stato.

Ecco un esempio pratico per un provider SaaS fintech che opera nell’UE.

Si noti che ogni riga è azionabile. Non si limita a dire “conformarsi a DORA”. Identifica il requisito, la mappatura interna, il titolare, il ritmo di riesame e l’evidenza.

La Politica sui ruoli e sulle responsabilità di governance - PMI di Clarysec rafforza questa disciplina di titolarità:

“Le responsabilità di governance (ad esempio riesame delle politiche, approvazione delle eccezioni, supervisione dei provider) devono essere assegnate a persone o ruoli specifici.”
Tratto da Politica sui ruoli e sulle responsabilità di governance - PMI, Requisiti di governance, clausola 5.3.

Per gli ambienti enterprise, lo stesso concetto deve riflettersi in una matrice RACI, in un registro della titolarità dei controlli e nel pacchetto di reporting alla direzione.

Esempio di segnalazione degli incidenti: un playbook, più obblighi

Un provider SaaS determina che potrebbe rientrare nell’ambito di applicazione NIS2 perché fornisce servizi cloud o servizi gestiti nell’UE e soddisfa i criteri dimensionali o settoriali pertinenti. L’organizzazione dispone già di un Piano di risposta agli incidenti, ma non ha mappato la segnalazione NIS2 nelle procedure di escalation.

La voce del registro deve descrivere l’obbligo con precisione:

• Fonte: NIS2 Article 23.
• Requisito: notificare al CSIRT o all’autorità competente, senza indebito ritardo, gli incidenti significativi, con early warning entro 24 ore, notifica entro 72 ore e rapporto finale entro un mese.
• Applicabilità: potenzialmente applicabile in ragione della categoria di servizio e delle operazioni nello Stato membro.
• Rischio in caso di mancato adempimento: violazione normativa, notifica ritardata agli stakeholder, perdita di fiducia dei clienti.

Quindi occorre mapparlo ai controlli. I controlli ISO/IEC 27002:2022 da 5.24 a 5.28 coprono pianificazione della gestione degli incidenti, valutazione, risposta, apprendimento e raccolta delle evidenze. Il controllo 5.31 copre il tracciamento degli obblighi legali. Il controllo 5.2 copre l’assegnazione dei ruoli. Il controllo 5.36 copre il monitoraggio del rispetto del processo.

La titolarità deve essere esplicita. Il Responsabile degli incidenti è titolare della classificazione e dell’escalation. La Funzione legale o Compliance è titolare dell’interpretazione regolatoria e dell’autorizzazione alla notifica. La funzione Comunicazione è titolare della comunicazione ai clienti. Il responsabile delle evidenze mantiene il fascicolo dell’incidente.

Le evidenze devono includere la registrazione della classificazione dell’incidente, la timeline, l’orario di rilevazione o di acquisita consapevolezza, il tempo di triage, il tempo di escalation, la decisione di notifica, l’invio all’autorità di regolamentazione se applicabile, la decisione di comunicazione al cliente, le lezioni apprese e le azioni correttive.

Un’esercitazione tabletop rende poi il registro reale. Utilizzare uno scenario in cui un’errata configurazione cloud causa potenziale esposizione dei dati dei clienti e interruzione del servizio. Verificare se il team sa individuare il termine NIS2 di 24 ore, determinare se è richiesta la valutazione della violazione GDPR, classificare il potenziale impatto DORA se sono interessati servizi finanziari e produrre un fascicolo evidenziale completo.

È così che il registro degli obblighi diventa un controllo. Modifica il comportamento operativo.

La gestione delle evidenze è il punto in cui gli audit spesso falliscono

Molte organizzazioni possono mostrare un registro. Meno organizzazioni riescono a dimostrare che le evidenze sono complete, aggiornate, protette e collegate.

La Politica di audit e monitoraggio della conformità - PMI di Clarysec fornisce il requisito di base:

“Tutte le evidenze devono essere archiviate in una cartella di audit centralizzata.”
Tratto da Politica di audit e monitoraggio della conformità - PMI, Requisiti di applicazione della politica, clausola 6.2.1.

Questa frase risolve un comune fallimento di audit. Evidenze disperse tra e-mail, ticket Jira, cartelle SharePoint, portali dei fornitori e unità personali non sono pronte per l’audit. La cartella centralizzata non deve necessariamente essere una singola cartella fisica per ogni file, ma deve esistere un repository o indice delle evidenze controllato che indichi all’auditor dove si trova l’elemento autorevole.

Per ciascun obbligo, le evidenze devono essere denominate in modo coerente, mappate all’ID dell’obbligo e all’ID del controllo, assegnate a una persona o a un ruolo nominato, protette da modifiche non autorizzate, conservate in base ai requisiti legali e contrattuali, riesaminate a una cadenza definita e collegate a eccezioni e azioni correttive.

Il trattamento del controllo 5.31 in Zenith Controls collega i requisiti legali alla conservazione delle registrazioni tramite il controllo 5.33, alla privacy e protezione dei PII tramite il controllo 5.34, al riesame indipendente tramite il controllo 5.35 e alla conformità interna tramite il controllo 5.36. Questo è importante perché le evidenze stesse possono contenere informazioni regolamentate, come dati personali, indicatori forensi, log degli accessi privilegiati o dati riservati dei clienti.

La prospettiva dell’audit: come i diversi revisori testeranno il registro

Un registro solido resiste a più prospettive di audit.

Un auditor ISO/IEC 27001:2022 partirà dal contesto, dalle parti interessate, dall’ambito di applicazione, dal trattamento del rischio, dalla Dichiarazione di applicabilità, dal monitoraggio, dall’audit interno e dal Riesame della direzione. Per il controllo 5.31, l’auditor si aspetterà di vedere che i requisiti legali e contrattuali applicabili siano identificati, mantenuti aggiornati e riflessi nei controlli. Per il controllo 5.2, verificherà se le responsabilità sono assegnate e comprese. Per il controllo 5.36, cercherà monitoraggio, non conformità e azioni correttive.

Un valutatore allineato a NIST si concentrerà sugli esiti di governance. NIST Cybersecurity Framework 2.0 GOVERN include GV.OC-03, che si aspetta che i requisiti legali, normativi e contrattuali relativi alla cibersicurezza, inclusi gli obblighi in materia di privacy e libertà civili, siano compresi e gestiti. Il valutatore può richiedere un profilo organizzativo, un’analisi delle lacune e un piano d’azione prioritizzato, quindi campionare se gli obblighi si traducono in gestione degli asset, controllo degli accessi, protezione dei dati, logging, risposta e ripristino.

Un auditor COBIT 2019 o ISACA esaminerà il registro attraverso gli obiettivi di governance e gestione. MEA03, Managed Compliance With External Requirements, è particolarmente rilevante. L’auditor può verificare se i requisiti esterni sono identificati tramite MEA03.01, se le risposte sono ottimizzate tramite MEA03.02, se la conformità è confermata tramite MEA03.03 e se l’assurance è ottenuta tramite MEA03.04.

Un auditor basato su ISACA ITAF darà priorità a evidenze sufficienti e appropriate. Potrebbe selezionare un requisito di notifica delle violazioni GDPR, un requisito di registro dei fornitori DORA e un requisito di segnalazione degli incidenti NIS2, quindi chiedere la traccia evidenziale end-to-end.

Un valutatore tecnico può convalidare il controllo 5.36 tramite evidenze di configurazione. Se il registro afferma che NIS2 e i contratti con i clienti richiedono MFA per accessi privilegiati, potrebbe verificare le impostazioni dell’identity provider. Se afferma che GDPR e contratti richiedono cifratura, potrebbe ispezionare la cifratura dei database, le registrazioni di gestione delle chiavi e i diagrammi dei flussi di dati. Se DORA richiede il monitoraggio dei servizi TIC di terze parti, potrebbe esaminare i riesami dei servizi, i report SLA e le registrazioni dei test di uscita.

Il registro richiede evidenze di governance ed evidenze tecniche.

Il Riesame della direzione chiude il ciclo dell’accountability

Un registro degli obblighi di conformità non deve essere detenuto in silenzio dalla funzione Compliance. Deve arrivare al Riesame della direzione perché NIS2, DORA, GDPR e ISO/IEC 27001:2022 si basano tutti sull’accountability.

NIS2 richiede agli organi di gestione di approvare le misure di gestione del rischio di cibersicurezza e supervisionarne l’attuazione. DORA attribuisce all’organo di gestione la responsabilità ultima della gestione del rischio TIC. GDPR richiede ai titolari del trattamento di dimostrare la conformità. ISO/IEC 27001:2022 richiede che il Riesame della direzione consideri cambiamenti nel contesto, esigenze delle parti interessate, risultati di audit, risultati del monitoraggio, risultati della valutazione del rischio, stato del trattamento e opportunità di miglioramento.

La Politica per la sicurezza delle informazioni di Clarysec è allineata a questa aspettativa:

“Le attività di Riesame della direzione (ai sensi della clausola 9.3 di ISO/IEC 27001) devono essere svolte almeno annualmente e devono includere:”
Tratto da Politica per la sicurezza delle informazioni, Requisiti di governance, clausola 5.3.

La politica di audit per PMI aggiunge il collegamento operativo:

“Le risultanze dell’audit e gli aggiornamenti di stato devono essere inclusi nel processo di Riesame della direzione del SGSI.”
Tratto da Politica di audit e monitoraggio della conformità - PMI, Requisiti di governance, clausola 5.4.3.

Il Riesame della direzione non ha bisogno di ogni singola riga. Ha bisogno di tendenze, decisioni sul rischio, eccezioni, risorse e accountability.

Questo trasforma il registro da fascicolo di conformità a strumento di leadership.

Schemi di fallimento comuni e come evitarli

Il primo schema di fallimento si verifica quando la Funzione legale possiede la legge, la sicurezza possiede i controlli e nessuno possiede la mappatura. Clarysec lo previene richiedendo che gli obblighi siano mappati a politiche, controlli e titolari nel SGSI.

Il secondo è tracciare i framework invece degli obblighi. Una voce del registro che dice “DORA” non è azionabile. Una voce del registro che dice “DORA Article 28 sulla gestione del rischio TIC di terze parti richiede due diligence, previsioni contrattuali, monitoraggio e strategie di uscita” è azionabile.

Il terzo è l’assenza di cadenza. Il riesame trimestrale è una baseline pratica per molte organizzazioni, con aggiornamenti basati su eventi per nuovi servizi, nuovi Paesi, nuovi fornitori, incidenti, audit e modifiche contrattuali.

Il quarto è l’evidenza che esiste ma non si trova. Il principio della cartella di audit centralizzata affronta direttamente questo problema.

Il quinto riguarda eccezioni informali. Se un controllo non può soddisfare temporaneamente un obbligo, l’eccezione deve essere documentata, valutata in termini di rischio, approvata, limitata nel tempo e riesaminata.

Il sesto è il Riesame della direzione puramente formale. Il registro deve guidare decisioni su budget, personale, remediation dei fornitori, negoziazione contrattuale, accettazione del rischio e azioni correttive.

Come Clarysec trasforma il registro in un meccanismo operativo

L’approccio in 30 passi di Clarysec rende pratica la gestione degli obblighi.

In Zenith Blueprint, lo Step 2 identifica esigenze degli stakeholder e requisiti applicabili. Lo Step 13 mappa controlli rispetto a rischi, clausole e Dichiarazione di applicabilità. Lo Step 23 affronta i controlli organizzativi, incluso il requisito di creare e mantenere un registro dei requisiti legali e normativi.

Il Blueprint afferma:

“Collaborare con la Funzione legale, la conformità o consulenti esterni per costruire un registro delle leggi, dei regolamenti e degli obblighi contrattuali applicabili relativi alla sicurezza delle informazioni (5.31). Deve includere le leggi sulla protezione dei dati (ad esempio GDPR), i requisiti settoriali e gli obblighi di certificazione. Assicurarsi che il team SGSI sappia dove consultarlo e che le modifiche siano riesaminate almeno trimestralmente.”
Tratto da Zenith Blueprint, fase Controlli in azione, Step 23.

Le politiche Clarysec forniscono le regole di governance: mantenere il registro, assegnare responsabilità, centralizzare le evidenze, riesaminare le risultanze e includere lo stato nel Riesame della direzione.

Zenith Controls fornisce la bussola di cross-compliance. Per il controllo 5.31, mappa la gestione degli obblighi all’accountability GDPR, ai doveri di cibersicurezza NIS2, alla gestione del rischio TIC DORA, alla governance NIST CSF, alla gestione dei programmi e al monitoraggio continuo NIST SP 800-53 e al monitoraggio della conformità esterna COBIT 2019. Per il controllo 5.2, collega l’accountability dei ruoli a GDPR, NIS2, DORA, NIST e COBIT. Per il controllo 5.36, collega il monitoraggio della conformità alle politiche all’accountability GDPR, all’igiene cyber e alle aspettative di controllo degli accessi NIS2, alla resilienza operativa DORA, al monitoraggio continuo NIST e al monitoraggio della conformità COBIT.

Il valore è semplice: un registro, un’architettura dei controlli, molti risultati di conformità.

Prossimi passi: rendere il registro degli obblighi pronto per l’audit

Le organizzazioni che gestiranno bene la conformità 2026 non saranno quelle con il maggior numero di fogli di calcolo. Saranno quelle con tracciabilità: dall’obbligo al titolare, dal titolare al controllo, dal controllo all’evidenza, dall’evidenza al riesame, dal riesame al miglioramento.

Iniziare con queste azioni:

1. Creare o aggiornare il registro degli obblighi di conformità in materia di cibersicurezza.
2. Aggiungere NIS2, DORA, GDPR, ISO/IEC 27001:2022 e i principali obblighi contrattuali dei clienti.
3. Mappare ciascun obbligo rispetto a politiche, controlli ISO/IEC 27002:2022, titolari, frequenza di riesame ed evidenze.
4. Identificare lacune, eccezioni ed evidenze scadute.
5. Aggiungere lo stato del registro al prossimo Riesame della direzione del SGSI.
6. Utilizzare Zenith Blueprint di Clarysec per collocare il registro nella roadmap SGSI in 30 passi.
7. Utilizzare Zenith Controls per mappare trasversalmente gli obblighi rispetto alle aspettative ISO, NIST, COBIT, GDPR, NIS2 e DORA.
8. Utilizzare la Politica di conformità legale e normativa, la Politica di conformità legale e normativa - PMI, la Politica sui ruoli e sulle responsabilità di governance - PMI, la Politica di audit e monitoraggio della conformità - PMI e la Politica per la sicurezza delle informazioni di Clarysec per formalizzare titolarità, riesame, archiviazione delle evidenze e accountability della direzione.

Clarysec può aiutarti a integrare questa tracciabilità nel tuo SGSI prima che auditor, autorità di regolamentazione, membri del consiglio di amministrazione o clienti la richiedano. Scarica i modelli di policy Clarysec pertinenti, mappa i primi dieci obblighi questa settimana e trasforma la conformità da attività d’emergenza a sistema operativo.