Evidenze di logging ISO 27001 per NIS2, DORA e GDPR

L’alert è arrivato nel canale SOC alle 02:17 di un martedì: più tentativi di accesso non riusciti per l’utente privilegiato admin da un nuovo indirizzo IP. I tentativi si sono interrotti dopo pochi minuti. Un analista junior ha preso nota dell’alert, ha ipotizzato che si trattasse di uno script configurato in modo errato o di un amministratore di sistema al lavoro fuori orario, ed è passato oltre.

Due giorni dopo, Maria, Responsabile della sicurezza delle informazioni di una società FinTech in rapida crescita, era in una riunione di direzione quando il telefono ha vibrato. Il team di ingegneria aveva rilevato un utilizzo anomalo e molto elevato della CPU su un’istanza di database di produzione. Era stato creato un nuovo account utente non autorizzato. L’alert delle 02:17 non era un falso positivo. Era il primo segnale visibile di un tentativo di intrusione.

L’incidente è stato contenuto, ma l’indagine ha messo in luce un problema più ampio. I log dei firewall erano in un sistema. I log Kubernetes in un altro. I log di audit del database erano archiviati separatamente. Diverse marcature temporali erano disallineate di alcuni minuti. Il team disponeva dei dati, ma non riusciva a ricostruire rapidamente una sequenza difendibile su rilevamento, riesame, escalation, contenimento e valutazione della violazione.

L’audit di sorveglianza ISO/IEC 27001:2022 di Maria si era concluso con esito positivo, ma l’auditor aveva lasciato un’avvertenza: l’organizzazione disponeva di controlli di registrazione e monitoraggio, ma avrebbe avuto difficoltà a produrre evidenze tempestive e correlate per le decisioni di segnalazione ai fini di NIS2, DORA e GDPR.

Questa è la realtà che molte organizzazioni affrontano nel 2026. Non hanno un problema di logging. Hanno un problema di evidenze.

Un SIEM, una piattaforma EDR, una traccia di audit cloud o un log del firewall non costituiscono, da soli, evidenze pronte per l’audit. Le evidenze diventano difendibili solo quando sono disciplinate da una policy, protette dalla manomissione, riesaminate con una cadenza definita, collegate alle decisioni sugli incidenti e conservate abbastanza a lungo da ricostruire gli eventi.

Per ISO/IEC 27001:2022, NIS2, DORA e GDPR, la domanda chiave non è più: “Raccogliamo i log?”. La domanda è: “Siamo in grado di dimostrare che cosa è accaduto, chi lo ha riesaminato, come è stato classificato, se era richiesta una segnalazione e se la direzione ha esercitato supervisione?”.

Perché registrazione e monitoraggio sono diventati un tema di evidenze di conformità

NIS2, DORA e GDPR hanno modificato il significato operativo dei log di sicurezza.

Ai sensi di NIS2, i soggetti essenziali e importanti devono attuare misure adeguate e proporzionate di gestione dei rischi di cibersicurezza. Article 21 include gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset, MFA e comunicazioni sicure. Article 23 crea un modello di segnalazione per fasi, che comprende un preallarme entro 24 ore, la notifica dell’incidente entro 72 ore, aggiornamenti intermedi ove pertinenti e una relazione finale non oltre un mese dalla notifica dell’incidente.

Questo modello dipende da registrazione e monitoraggio. Non è possibile inviare un preallarme credibile se non si può dimostrare quando l’evento è stato rilevato. Non è possibile classificare un incidente significativo se non si possono ricostruire i sistemi interessati, l’attività degli utenti, l’impatto sui servizi e le azioni di contenimento.

DORA esercita una pressione analoga sugli enti finanziari. Articles 5 to 14 stabiliscono aspettative di governance e di gestione del rischio ICT, incluse responsabilità dell’organo di gestione, identificazione degli asset ICT, protezione e prevenzione, rilevamento, risposta e ripristino, backup, ripristino, apprendimento e comunicazione. Articles 17 to 23 richiedono un processo di gestione degli incidenti connessi all’ICT che comprenda rilevamento, registrazione, classificazione, escalation, notifica e follow-up. Articles 24 to 27 riguardano i test di resilienza operativa digitale. Articles 28 to 31 introducono obblighi di gestione del rischio ICT di terze parti.

GDPR aggiunge il livello di accountability privacy. Article 32 richiede una sicurezza del trattamento adeguata. Article 33 richiede la notifica della violazione dei dati personali all’autorità di controllo senza ingiustificato ritardo e, ove possibile, non oltre 72 ore dal momento in cui se ne è venuti a conoscenza, salvo che sia improbabile che la violazione comporti un rischio per le persone fisiche. Article 34 può richiedere la comunicazione agli interessati quando il rischio è elevato. I log aiutano a determinare se dati personali siano stati consultati, alterati, esfiltrati o esposti, ma possono anche contenere dati personali e devono quindi essere governati di conseguenza.

ISO/IEC 27001:2022 fornisce l’ossatura del sistema di gestione. Le clausole 4.1 to 4.4 richiedono all’organizzazione di comprendere contesto, parti interessate, requisiti e campo di applicazione del SGSI. Le clausole 5.1 to 5.3 richiedono leadership, allineamento della policy, ruoli, responsabilità e autorità. Le clausole 6.1.1 to 6.1.3 richiedono un processo ripetibile di valutazione del rischio e trattamento del rischio, inclusi criteri di rischio, titolari del rischio, opzioni di trattamento, confronto con i controlli dell’Annex A, Dichiarazione di Applicabilità e accettazione del rischio residuo. La clausola 6.2 richiede obiettivi misurabili per la sicurezza delle informazioni.

Per questo motivo le evidenze di registrazione e monitoraggio non possono risiedere solo nel SOC. Devono far parte del SGSI, del Registro dei rischi, della Dichiarazione di Applicabilità, del processo di risposta agli incidenti, del flusso di gestione delle violazioni privacy, della governance dei fornitori e della reportistica alla direzione.

I controlli di logging ISO 27001 che gli auditor collegano per primi

In Zenith Blueprint: roadmap in 30 passi per auditor Zenith Blueprint, la fase Controls in Action, Step 19: Controlli tecnologici I, tratta registrazione, monitoraggio e sincronizzazione dell’orario come un’unica catena di evidenze.

A.8.15 – Registrazione: “I log che registrano attività, eccezioni, guasti e altri eventi rilevanti
devono essere prodotti, archiviati, protetti e analizzati.”

A.8.16 – Attività di monitoraggio: “Reti, sistemi e applicazioni devono essere monitorati per
comportamenti anomali e devono essere intraprese azioni appropriate per valutare potenziali
incidenti di sicurezza delle informazioni”

A.8.17 – Sincronizzazione dell’orologio: “Gli orologi dei sistemi di elaborazione delle informazioni utilizzati
dall’organizzazione devono essere sincronizzati con fonti temporali approvate.”

Questi controlli rispondono a tre domande di audit:

Zenith Controls: guida alla conformità trasversale Zenith Controls rende esplicita la relazione:

“La registrazione costituisce il livello dati fondamentale per il monitoraggio. Il controllo 8.16 dipende dai log generati ai sensi del controllo 8.15 per analizzare gli eventi di sicurezza, rilevare anomalie e identificare potenziali violazioni. Senza una registrazione completa, i sistemi di monitoraggio sono inefficaci.”

Zenith Controls classifica il controllo ISO/IEC 27002:2022 8.15, Registrazione, come controllo di rilevamento a supporto di riservatezza, integrità e disponibilità. Lo mappa al concetto di cibersicurezza Detect e alla gestione degli eventi di sicurezza delle informazioni. Collega inoltre la Registrazione alle Attività di monitoraggio, alla Valutazione e decisione sugli eventi di sicurezza delle informazioni e alla Sincronizzazione dell’orologio.

Per il controllo 8.16, Attività di monitoraggio, Zenith Controls lo classifica come controllo di rilevamento e correttivo, mappato a Detect e Respond. Collega il monitoraggio al monitoraggio dei servizi dei fornitori e alla valutazione degli eventi, aspetti essenziali per ambienti cloud, SaaS, servizi gestiti e outsourcing.

Il messaggio operativo è semplice. I log forniscono i fatti. Il monitoraggio identifica le anomalie. La sincronizzazione dell’orario rende i fatti affidabili tra sistemi diversi. La valutazione degli eventi trasforma gli alert in decisioni.

Come si presenta realmente un’evidenza di logging pronta per l’audit

Un’evidenza pronta per l’audit non è una cartella di screenshot. È una traccia coerente che dimostra progettazione del controllo, funzionamento del controllo e processo decisionale.

Un fascicolo maturo di evidenze di registrazione e monitoraggio contiene di norma quanto segue:

La Politica di registrazione e monitoraggio Enterprise di Clarysec Politica di registrazione e monitoraggio inquadra direttamente questo aspetto:

“Questa politica è essenziale per supportare la clausola 8.1 di ISO/IEC 27001 e i controlli Annex A 8.15 (Registrazione), 8.16 (Monitoraggio) e 8.17 (Sincronizzazione dell’orologio), ed è mappata direttamente agli obblighi normativi previsti da GDPR, NIS2, DORA e COBIT 2019.”

Dalla sezione “Finalità”, clausola di policy 1.3.

La stessa policy definisce l’aspettativa operativa:

“Stabilire sistemi centralizzati di registrazione e allertamento (ad es. SIEM) per aggregare, correlare ed escalare attività sospette quasi in tempo reale.”

Dalla sezione “Obiettivi”, clausola di policy 3.4.

Per le organizzazioni più piccole, la Politica di registrazione e monitoraggio per PMI di Clarysec Politica di registrazione e monitoraggio - PMI traduce lo stesso principio in requisiti proporzionati:

“Il fornitore di supporto IT deve definire e seguire un piano regolare per il riesame dei log:”

Dalla sezione “Requisiti di governance”, clausola di policy 5.1.1.

Definisce inoltre conservazione e protezione:

“I log devono essere conservati per almeno 12 mesi, salvo che un periodo di conservazione più lungo sia richiesto dalla legge o da un contratto, oppure sia giustificato nell’ambito di un incidente attivo o di un contenzioso.”

Dalla sezione “Requisiti di governance”, clausola di policy 5.2.1.

“I log devono essere archiviati in posizioni protette da scrittura e l’accesso deve essere limitato esclusivamente al personale autorizzato”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.1.

Per NIS2 e DORA, una baseline di evidenze di 12 mesi può fare la differenza tra una ricostruzione credibile e un’indagine fallita. Per GDPR, supporta l’accountability, pur richiedendo minimizzazione, controllo degli accessi e disciplina della conservazione.

Il collegamento mancante: valutazione degli eventi e soglie di segnalazione

Molte organizzazioni raccolgono log e generano alert sulle anomalie, ma falliscono nel punto decisionale.

L’alert era solo un evento di sicurezza, oppure è diventato un incidente di sicurezza delle informazioni? Era significativo ai sensi di NIS2? Era un incidente ICT grave ai sensi di DORA? Erano coinvolti dati personali? È richiesta un’analisi di notifica della violazione ai sensi del GDPR?

Questo punto decisionale si mappa al controllo ISO/IEC 27002:2022 5.25, Valutazione e decisione sugli eventi di sicurezza delle informazioni. Zenith Controls descrive il controllo 5.25 come la funzione di triage tra gli alert grezzi di monitoraggio e la gestione formale degli incidenti. Collega il controllo 5.25 alla pianificazione della gestione degli incidenti, alle attività di monitoraggio, alla risposta agli incidenti di sicurezza delle informazioni e alla registrazione. Mappa inoltre il controllo 5.25 agli Articles 33 and 34 del GDPR per notifica delle violazioni e valutazione del rischio, alla notifica e ai criteri di classificazione degli incidenti NIS2 e alla classificazione degli incidenti ICT gravi prevista da DORA.

La Politica di risposta agli incidenti di Clarysec Politica di risposta agli incidenti supporta questo punto di escalation:

“Se un incidente comporta l’esposizione confermata o probabile di dati personali o altri dati regolamentati, la Funzione legale e il DPO devono valutare l’applicabilità di:”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.4.1.

Per le PMI, la Politica di risposta agli incidenti per PMI Politica di risposta agli incidenti - PMI stabilisce il requisito tecnico delle evidenze:

“I sistemi di registrazione devono essere configurati per acquisire dettagli sufficienti a supportare l’indagine.”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.4.1.

È qui che GDPR Article 33 diventa operativo. La domanda non è solo se dati personali siano stati consultati. La domanda è se log, alert di monitoraggio e registrazioni degli incidenti consentano al DPO di effettuare una valutazione della violazione tempestiva e difendibile.

NIS2 Article 23 e DORA Articles 17 to 23 creano una pressione analoga. Le tempistiche di segnalazione dipendono dalla consapevolezza, dalla classificazione e dalla valutazione della materialità. L’organizzazione deve poter dimostrare quando l’alert è stato generato, quando è stato riesaminato, chi lo ha valutato, quale decisione è stata presa e quando è avvenuta l’escalation.

Esercitazione di 60 minuti sulle evidenze per un’indagine su accesso privilegiato

Un modo utile per testare la preparazione delle evidenze consiste nel provare uno scenario reale prima dell’audit o dell’incidente.

Scenario: un account amministratore privilegiato effettua l’accesso da un Paese insolito alle 02:13 UTC. Cinque minuti dopo, l’account tenta di accedere a una funzione di esportazione dei dati dei clienti. L’accesso condizionale blocca la sessione e viene generato un alert.

Obiettivo: produrre in 60 minuti un pacchetto di evidenze che dimostri rilevamento, riesame, escalation, valutazione e chiusura.

Passo 1: confermare che l’evento esista nei log

Utilizzare la Politica di registrazione e monitoraggio per identificare le fonti di log richieste: log del provider di identità, log amministrativi cloud, log applicativi, log dei database, log degli endpoint e log dei firewall o degli accessi sicuri.

Esportare la registrazione dell’evento con marcatura temporale, ID utente, IP sorgente, dispositivo, azione, risultato e ID di correlazione. Se l’evento esiste solo in una console e non nel SIEM o nel collettore di log, registrarlo come lacuna di controllo.

Zenith Blueprint Step 19 raccomanda di garantire che i sistemi critici inoltrino i log al SIEM o al collettore di log centrale e di validare che la conservazione sia allineata alla policy.

Passo 2: dimostrare che il monitoraggio lo ha rilevato

Mostrare l’alert SIEM, l’alert EDR o l’alert di protezione dell’identità. Includere nome della regola, gravità, marcatura temporale, condizione attivata e canale di notifica. Se l’organizzazione utilizza un riesame manuale, mostrare il report giornaliero e l’approvazione del revisore.

La Politica di registrazione e monitoraggio Enterprise rende questo aspetto una responsabilità di ruolo:

“Riesamina i report giornalieri e assicura che le anomalie siano analizzate, documentate ed escalate secondo necessità.”

Dalla sezione “Ruoli e responsabilità”, clausola di policy 4.2.3.

Passo 3: dimostrare che l’escalation è avvenuta entro i termini previsti dalla policy

Per le PMI, il requisito di escalation è esplicito:

“Gli alert ad alta priorità devono essere escalati al GM e al Coordinatore privacy entro 24 ore”

Dalla sezione “Applicazione e conformità”, clausola di policy 8.1.2.

Per i team enterprise, le evidenze possono includere un ticket di incidente, una registrazione di escalation su Teams o Slack, un log di paging, una notifica e-mail, una nota di handover del SOC o una registrazione nel sistema di gestione dei casi.

Passo 4: classificare l’evento

Utilizzare la logica di valutazione degli eventi del controllo 5.25 di Zenith Controls. Acquisire se l’alert è un evento di sicurezza, un incidente di sicurezza delle informazioni, una violazione dei dati personali, un incidente significativo NIS2 o un incidente ICT grave DORA.

La nota di classificazione deve rispondere a queste domande:

• L’autenticazione è riuscita o è stata bloccata?
• È stato utilizzato accesso privilegiato?
• I dati dei clienti sono stati consultati, alterati o esfiltrati?
• I servizi regolamentati sono stati interrotti?
• Sono stati interessati asset ICT critici?
• Sono coinvolti fornitori o responsabili del trattamento?
• L’evento soddisfa le soglie interne di segnalazione?
• È richiesta la notifica a DPO, Funzione legale, autorità di regolamentazione o clienti?

Passo 5: costruire una cronologia affidabile

La sincronizzazione dell’orologio viene spesso ignorata finché un’indagine non fallisce. Zenith Blueprint Step 19 afferma che l’orario sincronizzato è fondamentale per la correlazione degli eventi, perché i log provenienti da sistemi diversi devono allinearsi durante l’analisi dell’incidente.

Includere evidenze della configurazione NTP per piattaforme di identità, servizi cloud, server, endpoint, database, firewall e SIEM. Normalizzare le marcature temporali in UTC ove possibile.

Passo 6: chiudere o sottoporre a escalation

Se l’evento è contenuto e non è stato effettuato alcun accesso ai dati, documentare chiusura, lezioni apprese e azione preventiva. Se diventa un incidente, collegarlo alla risposta agli incidenti, al riesame legale e a eventuali flussi di segnalazione NIS2, DORA o GDPR.

Infine, proteggere le evidenze. La Politica di audit e monitoraggio della conformità di Clarysec Politica di audit e monitoraggio della conformità stabilisce:

“Tutti i log di audit, le risultanze e i report di remediation devono essere conservati, cifrati e protetti dalla manomissione.”

Dalla sezione “Applicazione e conformità”, clausola di policy 8.5.1.

Questa singola esercitazione produce evidenze per Annex A.8.15, A.8.16, A.8.17, controllo ISO/IEC 27002:2022 5.25, accountability delle violazioni GDPR, gestione degli incidenti NIS2 e classificazione degli incidenti ICT DORA.

Mappa delle evidenze di conformità trasversale per ISO 27001, NIS2, DORA e GDPR

I programmi di conformità più solidi non costruiscono set di evidenze separati per ciascun quadro di riferimento. Costruiscono un unico sistema di evidenze osservabile attraverso più lenti di audit.

NIST Cybersecurity Framework 2.0 può aiutare a rendere operativo questo aspetto come livello di comunicazione. Le sue sei funzioni, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER, mostrano che registrazione e monitoraggio ricadono principalmente in DETECT e RESPOND, ma dipendono da governance, comprensione degli asset e priorità di rischio.

I profili NIST CSF 2.0 possono inoltre supportare una roadmap 2026. Un Current Profile può mostrare la copertura di logging e la maturità degli alert attuali. Un Target Profile può definire la copertura richiesta per sistemi regolamentati, attività privilegiate, piattaforme dei fornitori e ambienti con dati personali. Il divario tra i due diventa il piano di remediation.

Log dei fornitori e del cloud: la lacuna di evidenze che gli auditor testano sempre più spesso

Negli audit moderni, le domande più difficili sul logging riguardano spesso piattaforme esternalizzate.

Potete accedere ai log di autenticazione del vostro fornitore di servizi cloud? Le azioni amministrative SaaS sono registrate? I log di audit dei database sono abilitati nei servizi gestiti? Il vostro MSSP conserva gli alert abbastanza a lungo? I contratti richiedono cooperazione in caso di incidente? I fornitori possono fornire log abbastanza rapidamente per le tempistiche di segnalazione NIS2 o DORA? I log del responsabile del trattamento sono disponibili per la valutazione delle violazioni GDPR?

Zenith Controls collega le Attività di monitoraggio, controllo 8.16, al Monitoraggio dei servizi dei fornitori, controllo 5.22. Mappa inoltre il monitoraggio alla clausola 10.5 di ISO/IEC 27005:2024, che enfatizza il monitoraggio e il riesame dei piani di trattamento del rischio e dei controlli, e alla clausola 7.3 di ISO/IEC 27035-2:2023, in cui meccanismi di monitoraggio continuo rilevano eventi di sicurezza delle informazioni e attivano la gestione degli incidenti.

DORA rende il logging dei fornitori particolarmente importante per gli enti finanziari, perché la gestione del rischio ICT di terze parti include registri dei fornitori, accordi contrattuali, rischio di subappalto, rischio di concentrazione e strategie di uscita. NIS2 Article 21 colloca la sicurezza della catena di fornitura tra le misure di gestione dei rischi di cibersicurezza. GDPR può rendere determinanti i log dei fornitori quando un incidente presso un responsabile del trattamento può diventare una violazione dei dati personali notificabile dal titolare del trattamento.

Una clausola pratica di logging dei fornitori deve richiedere:

• Log di audit rilevanti per la sicurezza relativi ad autenticazione, modifiche dei privilegi, azioni amministrative, accesso API, esportazione dei dati e modifiche di configurazione.
• Conservazione dei log allineata a policy, obblighi regolamentari e rischio contrattuale.
• Sincronizzazione dell’orario e normalizzazione dei fusi orari.
• Protezione dalla manomissione e accesso ristretto ai log.
• Cooperazione in caso di incidente entro tempi definiti.
• Consegna di evidenze per audit, indagini e richieste dell’autorità di regolamentazione.
• Trigger di notifica per accessi sospetti, compromissione del servizio o esposizione dei dati.
• Obblighi di logging ed escalation per i sub-responsabili, ove pertinenti.

Il logging dei fornitori deve essere gestito prima di un incidente, non negoziato durante l’incidente.

Come auditor diversi testano lo stesso controllo di logging

Un buon pacchetto di evidenze deve resistere a prospettive professionali diverse. Un auditor ISO, un revisore NIS2, un supervisore DORA, un revisore GDPR e un auditor orientato a COBIT 2019 o ISACA possono osservare la stessa dashboard SIEM, ma porranno domande diverse.

Zenith Blueprint Step 19 prepara le organizzazioni a queste domande. Per la Registrazione, gli auditor si concentrano sul fatto che gli eventi di sicurezza chiave siano registrati e che i log siano conservati, protetti e utilizzabili. Per le Attività di monitoraggio, chiedono come l’attività insolita o non autorizzata sia rilevata, valutata ed escalata. Per la Sincronizzazione dell’orologio, possono confrontare le marcature temporali tra sistemi e segnalare disallineamenti.

Anche lo Step 16: Controlli relativi al personale II, controllo 6.8, è rilevante perché i meccanismi di segnalazione degli incidenti collegano la segnalazione umana al rilevamento tecnico. GDPR Article 33, NIS2 Article 23 e gli obblighi DORA di segnalazione degli incidenti dipendono tutti da un’escalation interna tempestiva.

Risultanze di audit comuni e correzioni pratiche

La maggior parte delle risultanze relative a registrazione e monitoraggio è prevedibile. Il problema è che spesso le organizzazioni le scoprono durante l’audit anziché durante i test interni.

Per le organizzazioni con risorse limitate, l’approccio della policy per PMI è realistico. Non richiede un SOC completo dal primo giorno. Richiede piani di riesame definiti, conservazione di 12 mesi salvo necessità di un periodo più lungo, archiviazione protetta da scrittura, accesso ristretto ed escalation degli alert ad alta priorità. Questo crea una baseline difendibile mentre l’organizzazione matura verso SIEM centralizzato, correlazione automatizzata e rilevamento gestito.

Metriche che rendono il logging credibile per la direzione

Consigli di amministrazione e dirigenti non hanno bisogno di eventi SIEM grezzi. Hanno bisogno di assurance rilevante per il rischio. Poiché NIS2 Article 20 e i requisiti di governance DORA attribuiscono responsabilità agli organi di gestione, le metriche di registrazione e monitoraggio devono comparire nella reportistica di governance della sicurezza.

Metriche utili includono:

• Percentuale di asset critici che inoltrano log al SIEM o al collettore di log.
• Percentuale di eventi di accesso privilegiato coperti da allertamento.
• Numero di alert ad alta priorità riesaminati entro SLA.
• Tempo medio dalla generazione dell’alert al riesame dell’analista.
• Tempo medio dal rilevamento all’escalation.
• Numero di eventi classificati nell’ambito del processo di risposta agli incidenti.
• Numero di eventi che richiedono riesame da parte del DPO o della Funzione legale.
• Conformità della conservazione dei log per categoria di sistema.
• Numero di piattaforme dei fornitori con accesso contrattuale ai log.
• Numero di sistemi che non superano i controlli di sincronizzazione dell’orologio.
• Azioni di remediation aperte su registrazione e monitoraggio per livello di rischio.

Queste metriche supportano la clausola 6.2 di ISO/IEC 27001:2022 sugli obiettivi misurabili per la sicurezza delle informazioni. Rafforzano inoltre la vigilanza della direzione richiesta da NIS2 e DORA e l’accountability GDPR.

Costruire il pacchetto di evidenze di registrazione e monitoraggio per il 2026

Un solido pacchetto di evidenze 2026 deve essere preparato prima dell’audit o dell’incidente. Clarysec raccomanda normalmente una cartella strutturata o un oggetto di evidenze in piattaforma GRC con queste sezioni:

1. Governance e ambito di applicazione: campo di applicazione del SGSI, parti interessate, applicabilità normativa, approvazione della direzione e assegnazione dei ruoli.
2. Policy: Politica di registrazione e monitoraggio, Politica di risposta agli incidenti, Politica di audit e monitoraggio della conformità, requisiti di conservazione e requisiti di escalation.
3. Rischio e SoA: valutazione del rischio, piano di trattamento del rischio, razionale della Dichiarazione di Applicabilità per A.8.15, A.8.16, A.8.17 e controlli correlati.
4. Architettura: diagramma del SIEM o del collettore di log, inventario delle fonti di log, impostazioni di logging cloud e dipendenze dai log dei fornitori.
5. Funzionamento dei controlli: registrazioni dei riesami, alert, ticket, log di escalation, evidenze di chiusura ed eccezioni.
6. Collegamento agli incidenti: foglio di lavoro per la classificazione degli eventi, registro degli incidenti, registrazione della valutazione DPO e log decisionale di segnalazione.
7. Integrità e conservazione: controlli di accesso, cifratura, protezione in scrittura, impostazioni di archivio, controlli di cancellazione ed evidenze di conservazione.
8. Sincronizzazione dell’orario: configurazione NTP, baseline sicura, monitoraggio della deriva dell’orologio e approccio di normalizzazione UTC.
9. Evidenze dei fornitori: clausole contrattuali, report di assurance dei fornitori, disponibilità dei log di audit cloud e procedure di cooperazione in caso di incidente.
10. Miglioramento: risultanze dell’audit interno, tracker di remediation, risultati delle esercitazioni tabletop, registrazioni di tuning degli alert e report alla direzione.

Lo scopo non è sommergere gli auditor con il volume. Lo scopo è dimostrare che registrazione e monitoraggio operano come un processo controllato, dalla governance al rilevamento, valutazione, escalation, segnalazione e miglioramento.

Trasformare i log in evidenze di conformità difendibili

Il team di Maria non ha risolto il problema acquistando un’altra dashboard. Lo ha risolto trasformando registrazione e monitoraggio in un motore di evidenze. Le policy hanno definito i requisiti. Le regole SIEM e i log cloud hanno fornito segnali. I flussi di gestione degli incidenti hanno acquisito le decisioni. La sincronizzazione dell’orario ha reso credibile la cronologia. La reportistica alla direzione ha reso visibile il rischio.

Questo è lo standard di cui le organizzazioni hanno bisogno per ISO/IEC 27001:2022, NIS2, DORA e GDPR nel 2026.

Iniziate con un test pratico: prendete un alert reale degli ultimi 30 giorni e dimostrate, end-to-end, come è stato registrato, rilevato, riesaminato, sottoposto a escalation, classificato, conservato e segnalato.

Se la risposta non è solida, Clarysec può aiutarvi a colmare la lacuna.

Utilizzate Zenith Blueprint: roadmap in 30 passi per auditor Zenith Blueprint per implementare lo Step 19 relativo a registrazione, monitoraggio e sincronizzazione dell’orario, e lo Step 16 relativo ai meccanismi di segnalazione degli incidenti. Utilizzate Zenith Controls: guida alla conformità trasversale Zenith Controls per mappare Annex A.8.15, A.8.16, A.8.17 e il controllo ISO/IEC 27002:2022 5.25 nelle prospettive NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Quindi rendete operativi i requisiti tramite la Politica di registrazione e monitoraggio di Clarysec Politica di registrazione e monitoraggio, la Politica di registrazione e monitoraggio per PMI Politica di registrazione e monitoraggio - PMI, la Politica di risposta agli incidenti Politica di risposta agli incidenti, la Politica di risposta agli incidenti per PMI Politica di risposta agli incidenti - PMI e la Politica di audit e monitoraggio della conformità Politica di audit e monitoraggio della conformità.

I log non sono evidenze finché non sono governati, protetti, riesaminati e collegati alle decisioni. Le organizzazioni che sanno dimostrare questa catena supereranno gli audit più rapidamente, risponderanno meglio agli incidenti e daranno alla direzione fiducia quando arriverà il prossimo alert delle 02:17.