Un’organizzazione finanziaria europea con sistemi di intelligenza artificiale in produzione ricade allo stesso tempo sotto GDPR, NIS2, DORA e AI Act. I quattro regimi chiedono in larga parte le stesse attività — gestione del rischio, inventario degli asset, notifica degli incidenti, controllo dei fornitori — ma con definizioni, soglie e tempistiche diverse. Trattarli come quattro progetti distinti duplica l’evidenza e moltiplica i punti in cui le interpretazioni si disallineano. Il problema è costruire un unico modello dati che li serva tutti.

Contesto: quattro regimi entrati in vigore in 14 mesi

Le date di applicazione si sono addensate in poco più di un anno. Il Regolamento DORA (Digital Operational Resilience Act) si applica dal 17 gennaio 2025 a una ventina di tipologie di entità finanziarie e ai loro fornitori ICT (Information and Communication Technology). L’AI Act ha reso applicabili i divieti sulle pratiche proibite e gli obblighi di alfabetizzazione dal 2 febbraio 2025, e gli obblighi per i modelli per finalità generali (GPAI, General-Purpose AI) dal 2 agosto 2025. In Italia la direttiva NIS2 è stata recepita dal Decreto Legislativo 138/2024, in vigore dal 16 ottobre 2024; la finestra di registrazione dei soggetti essenziali e importanti sul portale dell’Agenzia per la Cybersicurezza Nazionale si è chiusa il 28 febbraio 2025, e la classificazione notificata dall’ACN il 15 aprile 2025 fa da riferimento per le scadenze successive. Il GDPR è in vigore dal 2018 e resta il livello base sul trattamento dei dati personali.

Per l’azienda che porta tutti e quattro gli obblighi il calendario non è teorico. Gli obblighi di notifica incidenti per i soggetti NIS2 italiani registrati scattano da gennaio 2026, con la piena conformità alle misure di sicurezza attesa entro ottobre 2026.

Architettura: un grafo controllo-requisito, non quattro liste

La tentazione naturale è scrivere una checklist per regime. Funziona finché i regimi non condividono nulla, e qui condividono parecchio. La gestione del rischio è il cuore comune di ISO/IEC 27001, NIS2 e DORA, e il GDPR la chiede sotto forma di accountability misurata sul rischio. Il controllo dei terzi — la catena di fornitura — è centrale in NIS2 e DORA e si ritrova nell’Annex A di ISO/IEC 27001. Il monitoraggio continuo lo chiedono tutti.

Un modello che eviti la duplicazione tiene separate due entità: il controllo (una misura tecnica o organizzativa davvero in atto: cifratura at-rest, segmentazione di rete, procedura di notifica) e il requisito (la clausola normativa che quel controllo soddisfa). La relazione è molti-a-molti. Una sola procedura di notifica degli incidenti soddisfa l’Articolo 33 GDPR, l’Articolo 23 NIS2 e gli obblighi di reporting ICT di DORA, ognuno con il proprio orologio. Un solo registro dei fornitori ICT alimenta sia il registro contrattuale DORA — la cui prima trasmissione alle autorità di vigilanza europee era fissata al 30 aprile 2025 — sia gli obblighi di sicurezza della catena di fornitura di NIS2.

ISO/IEC 27001 regge bene come ossatura del modello perché è un sistema di gestione costruito sul rischio e non sulle regole: i suoi controlli sono abbastanza granulari da fare da nodi a cui agganciare i requisiti dei singoli regimi. Tre controlli ISO/IEC 27002:2022 tornano come spina dorsale dell’evidenza — 5.1 (politiche di sicurezza), 5.19 (sicurezza nei rapporti con i fornitori), 5.24 (pianificazione e preparazione alla gestione degli incidenti) — più 6.8 (segnalazione degli eventi di sicurezza), che dice se il reporting funziona davvero. Mappare i requisiti di NIS2, DORA e GDPR su questi nodi, invece di tenere quattro alberi paralleli, riduce l’evidenza a una sola raccolta.

Punto critico: le soglie e gli orologi non si fondono

Condividere i controlli non significa fondere i trigger di notifica, ed è qui che il modello dati deve restare esplicito invece di semplificare.

I tempi divergono. Il GDPR impone la notifica di una violazione di dati personali entro 72 ore. NIS2 segue un processo in tre stadi: pre-allerta entro 24 ore, notifica entro 72 ore, relazione finale entro un mese dalla notifica (Articolo 23, dettagliato dal Regolamento di Esecuzione (UE) 2024/2690). Lo stesso incidente può quindi avviare un orologio a 24 ore verso l’autorità di cybersicurezza e uno a 72 ore verso il Garante, con contenuti e destinatari diversi.

Le soglie divergono. Il Regolamento di Esecuzione (UE) 2024/2690 definisce un incidente significativo ai fini NIS2 con criteri precisi — tra cui un impatto finanziario oltre 500.000 euro o il 5% del fatturato annuo, a seconda di quale sia inferiore (Articolo 3) — oltre alle regole per gli incidenti ricorrenti (Articolo 4) e ai criteri per tipo di entità (Articoli 5-14). La soglia di notifica del GDPR è invece il rischio per i diritti e le libertà delle persone fisiche: un parametro qualitativo, non una cifra. Un incidente può superare una soglia e non l’altra.

Per modellarlo bene, un evento di incidente è un’entità singola, collegata a uno o più obblighi di notifica, ognuno con la propria condizione di trigger valutata in modo indipendente e la propria scadenza calcolata dall’istante in cui l’incidente è stato rilevato. Comprimere i due in un’unica regola — “notifica tutto entro 72 ore” — produce sia notifiche tardive verso l’autorità a 24 ore sia notifiche superflue verso il Garante per incidenti che non toccano dati personali.

Implicazioni: l’evidenza si produce una volta, si presenta in molte viste

Se i controlli sono nodi condivisi e i requisiti vi si agganciano, l’artefatto di evidenza — un log, una policy firmata, l’esito di un test — si produce una volta sola e viene richiamato da ogni requisito che dipende da quel controllo. Un report di vulnerability assessment serve nello stesso momento il requisito di gestione del rischio NIS2, il testing di resilienza operativa DORA e il controllo ISO/IEC 27001 corrispondente, senza tre raccolte separate.

La differenza pratica sta nel costo marginale del regime aggiuntivo. Quando l’AI Act aggiunge l’obbligo di inventario dei sistemi di IA, in un grafo è un nuovo tipo di asset agganciato a controlli di governance già esistenti — log di audit, gestione degli accessi, documentazione — non un dodicesimo silo. Il costo di estendere il modello cresce con la quota di requisiti davvero nuovi, non con il numero di regimi.

Su questo modello unificato noze ha costruito DataGovern, piattaforma di compliance on-premise che tiene insieme GDPR, NIS2 e AI Act in un unico strumento; il ragionamento sui costi marginali della conformità integrata è ripreso in un insight pubblicato da noze: https://www.noze.it/insights/compliance-manager-piattaforma-integrata/.

Limiti

Un modello unificato non toglie il giudizio normativo. La mappatura controllo-requisito è un’asserzione da verificare: dire che il controllo 5.24 soddisfa l’Articolo 23 NIS2 vuol dire confrontare ciò che la procedura fa con ciò che la norma chiede, e le due cose divergono — la notifica a 24 ore di NIS2 non ha equivalente in ISO/IEC 27001. La mappatura va rivista a ogni aggiornamento delle norme o degli standard; i regimi citati hanno scadenze ancora aperte nel 2026, e le linee guida delle autorità continuano a precisarne l’interpretazione. Il modello dati riduce la duplicazione dell’evidenza, non la responsabilità di decidere se quell’evidenza basta.

https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/sg https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj https://eur-lex.europa.eu/eli/reg/2022/2554/oj https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai https://www.iso.org/standard/27001 https://www.acn.gov.it/portale/nis

Immagine di copertina: Il palazzo Berlaymont a Bruxelles, sede della Commissione europea, con la sua facciata curva in vetro e acciaio sotto un cielo limpido — foto di Andersen Pecorone, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Berlaymont_building_2015.jpg