Recent Posts
- DPIA e FRIA nei sistemi di IA: cosa cambia e come integrarle
- NIS2 e gestione dei fornitori. Attenzione alla governance della fornitura
- Significato di trasparenza e spiegabilità di un sistema di IA e conseguenze legali
- Determina ACN 9 febbraio 2026: tassonomia degli incidenti e obblighi di segnalazione NIS2
- Cybersicurezza e NIS2: scopri se sei un soggetto obbligato
Recent Comments
Determina ACN 9 febbraio 2026: tassonomia degli incidenti e obblighi di segnalazione NIS2
Determina ACN del 9 febbraio 2026: cosa introduce per la gestione incidenti nis2
Con la Determina del 9 febbraio 2026, l’Agenzia per la Cybersicurezza Nazionale (ACN) ha adottato la tassonomia degli incidenti da segnalare/notificare ai sensi dell’art. 1, comma 1, della Legge 28 giugno 2024, n. 90 .
Il provvedimento è stato pubblicato in Gazzetta Ufficiale il 17 febbraio 2026 e si applica dalla data di pubblicazione. In altre parole: è operativo.
👉 Per le aziende, il punto chiave non è solo “una nuova lista di incidenti”, ma l’impatto pratico su incident response, processi di classificazione, escalation interna e allineamento con gli obblighi NIS2 (se applicabili). Se vuoi impostare un percorso di compliance e governance coerente (NIS2 / Legge 90 / incident handling), Pixlex supporta assessment e implementazione nella practice Privacy & Cybersecurity
Perché questa determina è importante (anche se fai già NIS2)
La Determina ACN:
Definisce una tassonomia “ufficiale” degli incidenti da segnalare ai sensi della Legge 90/2024.
Dichiara la coerenza di questa tassonomia con gli “incidenti significativi di base” già usati nel perimetro NIS (NIS2).
In un’ottica di semplificazione, prevede che prenotifica e notifica effettuate ai sensi dell’art. 25 del decreto NIS (D.Lgs. 138/2024) possano considerarsi idonee ad assolvere anche l’obbligo della Legge 90/2024.
Traduzione operativa: puoi progettare un unico flusso di gestione e reporting incidenti, minimizzando duplicazioni (a patto di classificare correttamente).
Base normativa: Legge 90/2024, Legge 132/2025 e decreto NIS (D.Lgs. 138/2024)
La Determina richiama tre pilastri normativi:
Legge 90/2024: introduce, per i soggetti indicati dall’art. 1, comma 1, un obbligo di segnalazione di specifiche tipologie di incidenti, definite tramite tassonomia.
Legge 132/2025 (IA): modifica l’art. 1, comma 1, della Legge 90/2024 e chiarisce che la tassonomia è adottata con determinazione tecnica del Direttore Generale ACN.
D.Lgs. 138/2024 (decreto NIS / NIS2): regola misure e obblighi NIS2, incluso l’impianto di gestione e notifica incidenti (richiamato dalla Determina in relazione agli adempimenti e alla proporzionalità).
La tassonomia ACN: i codici IS-1, IS-2, IS-3 (Allegato A)
L’Allegato A della Determina elenca tre macro-fattispecie (codici IS). In chiave “incident response”, puoi leggerle come un set minimo che copre:
IS-1 — Perdita di riservatezza (confidentiality)
È il caso in cui il soggetto ha evidenza di una perdita di riservatezza verso l’esterno di dati digitali sotto la sua proprietà o controllo (anche parziale).
Esempi tipici (a livello concettuale): esfiltrazione di dati, accesso non autorizzato con data exposure, leak pubblici.
IS-2 — Perdita di integrità con impatto verso l’esterno (integrity)
Riguarda l’evidenza di perdita di integrità di dati sotto proprietà/controllo (anche parziale), con impatto verso l’esterno.
Esempi concettuali: alterazione di dati trasmessi a terzi, manipolazione di dataset che alimentano servizi esterni, compromissione di dati che impattano utenti/partner.
IS-3 — Violazione dei livelli di servizio attesi (availability / performance)
È l’ipotesi in cui il soggetto ha evidenza della violazione dei livelli di servizio attesi (SL) dei propri servizi/attività, sulla base dei livelli stabiliti dal soggetto. Qui ricadono incidenti che determinano disservizi misurabili rispetto a SLA/SL interni o contrattuali (es. downtime oltre soglia, degrado prolungato, indisponibilità).
Perché IS-3 è “delicato”: richiede che l’organizzazione abbia definito (e mantenga) livelli di servizio attesi e soglie utili alla classificazione. Se non li hai formalizzati, rischi ambiguità in fase di triage.
Punto chiave della Determina: “una notifica (NIS2) può valere anche per la Legge 90/2024”
La Determina afferma, in ottica di semplificazione degli oneri, che in caso di prenotifica e notifica effettuata ai sensi dell’art. 25 del decreto NIS, può considerarsi assolto anche l’obbligo previsto dall’art. 1, comma 1, della Legge 90/2024.
Implicazione pratica
Se sei già dentro processi NIS2 (o li stai implementando), conviene:
mappare le categorie IS-1/2/3 dentro il tuo incident classification model;
verificare che i contenuti della notifica NIS2 coprano correttamente gli elementi richiesti dai tuoi obblighi di segnalazione (tempi, canali, completezza informativa);
evitare “doppioni” progettando un workflow unico, con branching solo dove necessario.
👉 Pixlex può aiutarti a progettare flussi, policy, ruoli e contrattualistica (supply chain inclusa) nella practice Privacy & Cybersecurity.
Cosa fare ora: checklist operativa (7 passi)
Ecco una sequenza “da compliance project” per rendere la Determina azionabile:
Verifica perimetro soggettivo: sei tra i soggetti tenuti agli obblighi dell’art. 1, comma 1, Legge 90/2024? (analisi legale + organizzativa).
Allinea tassonomia: integra IS-1/IS-2/IS-3 nel modello di classificazione incidenti (playbook).
Definisci soglie e SL (per IS-3): quali KPI/SLA determinano “violazione”? chi li valida? dove sono documentati?
Aggiorna escalation e ruoli: RACI, reperibilità, responsabilità del management, legal/IT/security/PR.
Incident evidence & logging: standardizza la raccolta evidenze (per “evidenza della perdita…”), catena di custodia e tracciabilità.
Reporting design: se applicabile NIS2, progetta un single reporting pipeline che copra anche Legge 90/2024 (evitando duplicazioni).
Esercitazioni: tabletop + simulation su 3 scenari (data leak / data tampering / SLA breach) per testare tempi e decisioni.
Errori comuni da evitare (che impattano anche SEO/Brand e rischio operativo)
Non definire SL/SLA interni: rende IS-3 difficilmente classificabile e può far “saltare” i trigger.
Confondere incidente IT con incidente rilevante: serve una tassonomia unica e un triage robusto.
Non collegare fornitori e supply chain: molti incidenti nascono da terze parti (servizi ICT, MSP/MSSP, cloud).
Documentazione frammentata: policy e playbook non allineati → notifica lenta o incompleta.
Come Pixlex supporta aziende e PA su incident reporting e compliance cyber
Se la tua organizzazione deve allinearsi a questi obblighi (Legge 90/2024 e/o NIS2), tipicamente serve un intervento su:
valutazione di applicabilità e perimetro (soggettivo/organizzativo);
incident response program (policy, playbook, RACI, formazione);
governance e reporting (coerenza tra obblighi e flussi, “single pipeline”);
contratti e supply chain (clausole, SLA, audit rights, incident notification).
Approfondisci i servizi Pixlex nella pagina Privacy & Cybersecurity.
FAQ
La Determina ACN è già in vigore?
Sì: si applica dalla data di pubblicazione in Gazzetta Ufficiale (17 febbraio 2026).
Quanti tipi di incidenti contiene la tassonomia?
Nell’Allegato A pubblicato in Gazzetta sono indicati tre codici: IS-1, IS-2, IS-3.
IS-3 dipende dai miei SLA?
Sì: il riferimento è ai “livelli di servizio attesi (SL) stabiliti dal soggetto”. Se non hai soglie documentate, è opportuno definirle.
Se notifico un incidente ai sensi della NIS2, devo fare anche la segnalazione ex Legge 90/2024?
La Determina prevede che, in ottica di semplificazione, prenotifica e notifica fatte ai sensi dell’art. 25 del decreto NIS possano considerarsi idonee ad assolvere anche l’obbligo della Legge 90/2024. In pratica conviene progettare un flusso unico e verificare copertura e coerenza.
Come capisco se sono tra i soggetti obbligati dalla Legge 90/2024?
Serve una verifica sul perimetro soggettivo previsto dall’art. 1, comma 1 (ruolo dell’ente, natura/settore e criteri applicabili). Un assessment iniziale riduce rischi e costi di adeguamento.
Comments are closed.