Requisiti di audit logging NIS2 in Italia e come soddisfarli

Il controllo

Le tre scadenze sono il punto. Una policy che dichiara di notificare «tempestivamente» non prova nulla: serve un record con riferimento temporale di quando si è avuta conoscenza dell'incidente e di quando ciascuna delle tre comunicazioni è stata depositata, e serve che quel record non sia modificabile a posteriori. La determinazione ACN n. 379907/2025 fissa inoltre 43 misure con 116 requisiti per i soggetti essenziali e 37 con 87 per gli importanti, da adottare entro diciotto mesi dalla comunicazione di inserimento nell'elenco dei soggetti NIS (art. 7, comma 3, del decreto; art. 4 della determinazione): per chi è stato notificato nell'aprile 2025 il termine cade il 31 ottobre 2026, per i soggetti inseriti nel 2026 il 31 luglio 2027.

Cosa chiede un auditor

Un'ispezione ACN non chiede di vedere la procedura di gestione degli incidenti. Chiede, per un incidente determinato, quando è stato rilevato, quando è stata inviata la pre-notifica, quando la notifica, quando la relazione finale, e come si dimostra che quelle date non siano state ricostruite a posteriori. AuditRails registra i quattro momenti come eventi distinti (incident.detected, incident.early_warning, incident.notified, incident.final_report) legati dallo stesso incident_id, e il report calcola per ciascun incidente le ore trascorse e il rispetto delle soglie di 24 e 72 ore.

Requisito di conservazione

AuditRails conserva i log NIS2 per un minimo di 5 anni per impostazione predefinita. La conservazione si estende automaticamente se siete abbonati anche a un framework con un requisito più lungo.

Cosa registra AuditRails

Ogni fase della catena dell'art. 25 è una chiamata di logging. Il campo incident_id è quello che lega la pre-notifica, la notifica e la relazione finale allo stesso incidente, ed è per questo che è obbligatorio.

import { AuditRails } from '@auditrails/node';

const audit = new AuditRails({ apiKey: 'at_live_...' });

await audit.log({
  action: 'incident.early_warning',
  actor_id: '...', // required
  metadata: {
    incident_id: '...', // required
    authority: '...', // required
    suspected_malicious: '...', // optional
    cross_border: '...', // optional
    notification_id: '...', // optional
  }
});

Cosa si consegna all'auditor

Il pacchetto di evidenze generato per la finestra dell'ispezione è un archivio con il report in PDF, il registro completo degli eventi in NDJSON e un manifest con i checksum SHA-256 di entrambi, oltre alla prova della catena di hash. È materiale che si consegna all'ACN, non una dichiarazione da accettare sulla parola.

Errori comuni su questo controllo

• Registrare che l'incidente è stato notificato ma non quando è stato rilevato: senza il momento della conoscenza le 24 ore non sono calcolabili e la pre-notifica non è dimostrabile.
• Tenere le tre comunicazioni in una casella di posta. Le email si cancellano, si riscrivono e non portano una prova di integrità: un'ispezione che chiede "come dimostrate che questa data non è stata cambiata" non ottiene risposta.
• Non collegare le tre fasi allo stesso incidente. Senza un identificativo condiviso il report non può appaiare la notifica alla rilevazione, e la cronologia va ricostruita a mano davanti all'ispettore.
• Log modificabili da chi gestisce l'incidente. Se l'amministratore che ha tardato la notifica può correggere il riferimento temporale, il registro non prova nulla.
• Fermarsi alla notifica delle 72 ore e non registrare la relazione finale, che l'art. 25 richiede entro un mese, o le relazioni intermedie se l'incidente resta aperto.

Domande frequenti

Questa pagina descrive obblighi normativi a fini informativi e non costituisce consulenza legale. Il perimetro di applicazione alla vostra organizzazione va verificato con i vostri consulenti.