Registro non conformità: campi e prove per la tracciabilità in audit

Questions to Settle Before the Next Audit

Checks Before You Close a Finding

Six Habits and Their Repairs

Errors That Weaken the Audit Trail

Case Three, a 231 Gap, a Report, an AI System

Case Two, a Personal Data Incident

Case One, a Critical ICT Supplier

One Finding Across NIS2 DORA and GDPR

Managing Time-Bound Control Exceptions

Evidence That Supports a Closure

Who Opens Approves Executes and Verifies

Timing Fields for a Data Breach

The Fields That Stay Vague

Fields a Registro Non Conformità Must Hold

Three Objects Teams Collapse Into One Ticket

Why an Unrecorded Nonconformity Fails the Audit

Indice

• Perché una non conformità non registrata crea problemi in audit
  • Tre situazioni che non vanno confuse
• I campi necessari in un registro non conformità
  • I campi che spesso restano vaghi
  • Le date da registrare in caso di violazione dei dati
• Chi apre, approva, esegue e verifica
  • Le evidenze necessarie per chiudere una non conformità
• Come gestire le eccezioni ai controlli con scadenza
• Un rilievo, più requisiti: NIS2, DORA e GDPR
  • Caso 1: un fornitore ICT critico
  • Caso 2: un incidente che coinvolge dati personali
  • Caso 3: una lacuna 231, una segnalazione, un sistema di IA
• Gli errori che indeboliscono la tracciabilità
  • Sei abitudini da correggere
• Sette controlli prima della chiusura
• Le domande da chiarire prima del prossimo audit

Perché una non conformità non registrata crea problemi in audit

Il controllo in discussione è spesso ordinario: una revisione trimestrale degli accessi saltata per un'applicazione, un test di ripristino rinviato, un fornitore che non rispetta una scadenza di remediation. Il team conosce i fatti. Le evidenze, però, si trovano in tre posti diversi e nessuna indica chi abbia accettato il rischio nel frattempo.

Un registro non conformità è la registrazione datata, attribuita a responsabili precisi e verificabile di un rilievo, dalla sua individuazione alla verifica di efficacia. Non è un elenco di lamentele né un documento da sistemare prima della visita dell'auditor. È il registro operativo che permette a chi non era presente di ricostruire ogni decisione.

Queste indicazioni riguardano la gestione operativa per CISO, responsabili compliance e risk management, internal auditor, DPO, responsabili IT e sicurezza, membri dell'OdV e consulenti GRC nelle imprese italiane. Non costituiscono consulenza legale e non sostituiscono il parere dei professionisti competenti. Quando una valutazione giuridica determina una decisione, anche questa distinzione va documentata.

Tre situazioni che non vanno confuse

Il registro perde utilità quando situazioni diverse vengono fatte passare nello stesso flusso senza distinguerle.

• Eccezione a un controllo, autorizzata e limitata nel tempo: il controllo non può funzionare come previsto per un periodo definito; un responsabile del rischio nominato ne è consapevole e un controllo compensativo viene approvato prima della deviazione.
• Rilievo di audit o non conformità: il controllo è mancato, non ha funzionato o non esistono prove della sua esecuzione, senza un'approvazione preventiva di quella situazione.
• Incidente di sicurezza o operativo: si è verificato un evento e la prima priorità è contenerlo e ripristinare l'operatività, prima ancora di completarne la classificazione.

Confonderli ha conseguenze concrete. Un incidente chiuso come ticket generico perde i tempi e la valutazione del rischio. Un'eccezione registrata come rilievo sembra un controllo gestito senza disciplina. Un rilievo rinominato eccezione dopo il fatto suggerisce un'approvazione retroattiva.

La catena di tracciabilità è la stessa in tutti i casi: requisito o policy, controllo operativo, responsabile del controllo, evidenza datata e verificabile, cronologia delle modifiche non sovrascrivibile, rilievo, remediation, verifica di efficacia. Se manca un passaggio, diventa difficile ricostruire i fatti. Una matrice rischi-controlli aiuta a impostare questi collegamenti; la guida di devPulse per i team compliance offre un riferimento per strutturarli prima che i record si moltiplichino.

Il contesto normativo comprende NIS2, recepita con il D.Lgs. 138/2024 e gli adempimenti di competenza dell'ACN; DORA, il Regolamento (UE) 2022/2554; il GDPR e il Garante per la protezione dei dati personali; il D.Lgs. 231/2001 e l'OdV; il D.Lgs. 24/2023 sul whistleblowing; e l'AI Act europeo. Ciascun ambito incide su ciò che va dimostrato e sui soggetti coinvolti, ma non elimina la necessità di un record ricostruibile.

Distinzione essenziale: una policy scritta dimostra l'intenzione. Un'evidenza datata, collegata a un responsabile nominato, dimostra che il controllo è stato eseguito.

Si parte dai campi. Se il record non consente di documentare una decisione, nessun flusso di approvazione potrà compensare quella mancanza durante l'audit.

I campi necessari in un registro non conformità

Aggiungi questi campi al registro che già utilizzi. Non serve necessariamente una nuova piattaforma: servono campi che obblighino a documentare le decisioni quando i fatti sono ancora attuali.

I campi che spesso restano vaghi

Alcuni campi sembrano compilati ma dicono poco. Causa radice è il caso più comune. «Patch non installata» descrive un sintomo. La causa potrebbe essere l'assenza di una finestra di manutenzione, un inventario incompleto o un fornitore che non ha confermato la presa in carico. Se il campo non spiega perché il controllo è mancato, la stessa lacuna tornerà con un altro ID.

Anche rischio iniziale e residuo richiede precisione. Registra scenario, probabilità e impatto, trattamento scelto e, se il rischio viene accettato, motivazione e nome di chi lo accetta. Un'accettazione senza responsabile non è una decisione ricostruibile.

Lo stato merita la stessa attenzione. Con le sole opzioni «aperto» e «chiuso», un record può risultare chiuso mentre la correzione è ancora da verificare. Gli stati intermedi della tabella rendono più fedele la rappresentazione del lavoro.

Le date da registrare in caso di violazione dei dati

Per i rilievi privacy conserva due momenti distinti. Le indicazioni del Garante sulla gestione dei data breach prevedono la documentazione della violazione dei dati personali anche quando non viene notificata all'autorità o comunicata agli interessati. Il record deve riportare circostanze, conseguenze e misure adottate. Quando la violazione presenta un rischio per i diritti e le libertà delle persone, la notifica all'autorità di controllo è richiesta senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui il titolare ne è venuto a conoscenza.

Registra quindi separatamente rilevazione e consapevolezza, insieme a sistemi e categorie di dati interessati, contenimento, valutazione del rischio, decisione sulla notifica con relativa motivazione ed evidenze del ripristino. Ai fini dell'articolo 33 del GDPR, il termine delle 72 ore decorre dalla consapevolezza della violazione da parte del titolare, non automaticamente dal primo sintomo tecnico presente nei log.

Conserva inoltre la cronologia delle versioni delle decisioni. Se emergono nuovi fatti, cambiare una valutazione può essere corretto. Il problema nasce quando la motivazione precedente viene sovrascritta e il registro mostra una sola decisione, formulata come se fosse stata presa fin dall'inizio. Lo stesso vale per i risultati dei test: il metodo descritto in questa guida alla documentazione dei pentest con ThreatExploit AI mostra come trasferire evidenze tecniche nel registro senza ridurle a una generica dicitura «problema di sicurezza».

Chi apre, approva, esegue e verifica

La separazione dei ruoli è un punto debole frequente. Se una sola persona rileva la lacuna, esegue la correzione e chiude il record, la cronologia dimostra soltanto che quella persona ha considerato sufficiente il proprio lavoro.

Il flusso seguente assegna una responsabilità a ogni passaggio e un'evidenza a ogni consegna.

Chi apre il record può essere l'operatore del controllo, un responsabile IT o un auditor interno. Deve riportare origine, ambito, tempi e ciò che è stato osservato, poi passare il rilievo a chi lo valuterà. Non dovrebbe essere anche l'unica persona a dichiarare efficace la soluzione.

La classificazione spetta al responsabile del controllo o della compliance: da quella scelta dipendono percorso, visibilità e scadenze. Il responsabile del rischio approva il trattamento e documenta data e motivazione sullo stesso record. Il responsabile dell'azione esegue l'intervento entro una data che, se cambia, richiede una nuova decisione tracciata.

Il video seguente illustra i passaggi di consegna e può essere utile per allineare i responsabili dei controlli.

Le evidenze necessarie per chiudere una non conformità

Il provvedimento del Garante sulle misure di sicurezza richiama l'adozione di misure tecniche e organizzative adeguate al rischio del trattamento. Nel registro questo significa collegare presidio mancante o insufficiente, scenario di rischio, controllo correttivo ed evidenze oggettive del miglioramento: per esempio revisioni dei log di accesso, risultati dei test di ripristino, modifiche a password e privilegi, registrazioni degli interventi sulle vulnerabilità o procedure aggiornate. La chiusura richiede evidenza dell'attuazione e una verifica del risultato e del rischio residuo.

Ci sono tre confini da mantenere chiari. Quando è coinvolta una violazione dei dati personali, il DPO o il responsabile privacy designato documenta la valutazione sulla notifica separatamente dalla correzione tecnica: riparare il sistema non risolve da solo la questione regolatoria. Per le segnalazioni ai sensi del D.Lgs. 24/2023, l'accesso resta limitato ai soggetti autorizzati; identità del segnalante e contenuto della segnalazione non devono finire nelle normali viste dei ticket né circolare via email aperta. Nel Modello 231, l'OdV verifica protocollo ed evidenze senza diventare il responsabile operativo della correzione.

Un software può smistare attività e conservare evidenze approvate. Non può assumersi un rischio al posto della persona responsabile.

Come gestire le eccezioni ai controlli con scadenza

Un'eccezione è una decisione presa prima che il controllo smetta di funzionare come previsto. È autorizzata quando un responsabile del rischio nominato accetta la deviazione per un periodo definito, documentando sullo stesso ID il controllo compensativo, la motivazione del rischio residuo e la scadenza. Se la mancanza viene scoperta dopo, trattala come rilievo, non come eccezione retroattiva.

Assegna a ogni eccezione un ID, un richiedente, un approvatore diverso dal richiedente e una data di riesame precedente alla scadenza. È proprio il riesame anticipato a impedire che un'eccezione scada inosservata. Il flusso essenziale per le eccezioni ai controlli descrive il ciclo completo quando manca ancora una procedura di scadenza.

Prima della scadenza, il responsabile sceglie fra tre esiti:

• Chiudere: il controllo funziona di nuovo come previsto e le evidenze lo dimostrano.
• Convertire: la lacuna permane e viene gestita come rilievo con un piano di remediation.
• Rinnovare: una nuova decisione datata stabilisce nuova scadenza e nuova motivazione del rischio residuo.

Copiare la vecchia approvazione non equivale a rinnovarla. Produce continuità apparente senza documentare la nuova decisione.

Anche il controllo compensativo richiede evidenze datate e recuperabili: per esempio il log del monitoraggio sostitutivo, non una frase che dichara che il monitoraggio avviene. Se l'eccezione scade senza decisione, segnala la scadenza mancata e apri un rilievo sul processo di gestione del registro.

Per le questioni relative al Modello 231, l'OdV riceve le sintesi delle eccezioni ai fini della verifica, senza approvare le eccezioni operative. Monitora inoltre eccezioni per responsabile e anzianità: quelle che durano troppo devono emergere nel riesame dei rischi, non soltanto davanti all'auditor.

Un rilievo, più requisiti: NIS2, DORA e GDPR

Creare un record distinto per ogni quadro normativo genera duplicati e versioni che possono divergere. Un solo rilievo, con collegamenti pertinenti, può alimentare le evidenze necessarie per NIS2, DORA, GDPR e Modello 231.

Caso 1: un fornitore ICT critico

Supponiamo che un fornitore ICT critico non rispetti la scadenza per correggere una vulnerabilità. Mantieni un solo rilievo, collegato al controllo interno, agli obblighi applicabili sulla catena di fornitura e sulle vulnerabilità nel quadro NIS2 introdotto dal D.Lgs. 138/2024 e, se l'entità rientra nel perimetro, ai requisiti DORA relativi alle terze parti ICT. Un responsabile, una scadenza e le evidenze del fornitore possono sostenere tutti questi collegamenti.

Il monitoraggio del recepimento di NIS2 offre un quadro del recepimento italiano e dei temi relativi a valutazione del rischio, continuità operativa, incidenti, vulnerabilità e catena di fornitura. DORA si applica direttamente alle entità finanziarie interessate, con la vigilanza delle autorità competenti, tra cui Banca d'Italia, Consob, IVASS e COVIP, secondo i rispettivi ambiti.

L'obiettivo non è creare un punteggio di conformità. È permettere a chi verifica di trovare, nello stesso percorso, controllo interno, requisito applicabile, responsabile e prova datata. Per chi sta ancora definendo il perimetro NIS2, questa guida alla preparazione NIS2 con SIX ERP affronta il lavoro preliminare. Nel record condiviso, però, mantieni distinguibili rilievo regolatorio, debolezza del controllo, incidente e carenza del fornitore, con una cronologia delle decisioni non sovrascrivibile.

Caso 2: un incidente che coinvolge dati personali

Distingui evento di sicurezza, violazione accertata dei dati personali e violazione da notificare. Non sono la stessa cosa. Documenta l'evento e aggiorna il record man mano che i fatti consentono di valutarlo. Se è accertata una violazione dei dati personali, documentala anche quando la notifica non è necessaria.

Quando la violazione presenta un rischio per i diritti e le libertà delle persone, notifica il Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla consapevolezza. Se la notifica avviene oltre il termine, registra il motivo del ritardo. Conserva valutazione del rischio e motivazione della decisione: la sola dicitura «rischio basso» non permette di ricostruire il ragionamento mesi dopo.

Caso 3: una lacuna 231, una segnalazione, un sistema di IA

Per una lacuna in un protocollo 231, collega il rilievo al protocollo e alla verifica dell'OdV, lasciando la responsabilità dell'intervento al titolare del processo. Per una segnalazione ai sensi del D.Lgs. 24/2023, registra data di ricezione, soggetto autorizzato alla gestione, stato, aggiornamenti e chiusura motivata in un ambiente non visibile nei normali ticket, tutelando la riservatezza.

Per un sistema di IA cui si applica l'AI Act europeo, documenta il responsabile umano, la voce d'inventario e i limiti del sistema in relazione agli obblighi pertinenti. Lo strumento non decide la conformità né approva da sé i propri risultati. Dalla stessa cronologia puoi poi predisporre pacchetti di evidenze diversi per interlocutori diversi, senza duplicare la gestione del rilievo.

Gli errori che indeboliscono la tracciabilità

Chiudere un rilievo prima di verificare se l'azione correttiva abbia funzionato può creare più difficoltà in audit che lasciarlo aperto. Il record deve mostrare che cosa non funzionava, che cosa è cambiato e come è stato controllato il risultato. Un'attività completata non dimostra, da sola, che la causa sia stata eliminata.

La relazione sugli audit a cascata 2025 riporta 95 audit e 179 osservazioni effettuati dalle autorità regionali e delle province autonome. Le azioni correttive hanno riguardato soprattutto le procedure documentate, in 26 casi; l'efficacia e l'appropriatezza dei controlli ufficiali, in 18; e infrastrutture, attrezzature e ambienti di lavoro, in 16, oltre alla formazione del personale. Sono ambiti diversi, ma tutti richiedono di collegare intervento, prova e verifica del risultato.

Sei abitudini da correggere

• Approvazione retroattiva: la data viene aggiunta solo dopo una richiesta dell'auditor, senza tracce precedenti. Registra la decisione con la data effettiva e apri un rilievo per l'approvazione mancante; non retrodatare.
• Eccezioni senza fine: un controllo compensativo viene rinnovato senza nuova accettazione del rischio né scadenza. Documenta una nuova decisione datata oppure converti la lacuna in rilievo.
• Evidenze sparse: le prove restano in chat, email personali o cartelle senza collegamento con l'ID. Associa al record file con versione e contesto, seguendo le buone pratiche per la tracciabilità in audit.
• Chiusura senza verificatore: chi esegue l'azione la dichiara completata, ma nessuno ne controlla l'efficacia. Se necessario, riapri il record e incarica un'altra persona della verifica.
• Screenshot senza contesto: un'immagine priva di data, nome del sistema o informazioni sull'integrità non si collega in modo affidabile al periodo esaminato. Conserva o rigenera la prova con i metadati pertinenti.
• Descrizione generica: «problema di sicurezza» o «rischio basso» non identificano controllo, scenario e approvatore. Completa questi dati nel record originale.

C'è anche un errore di responsabilità: trattare il suggerimento di un flusso automatico o di un sistema di IA come se fosse una decisione. Indica chi ha accettato o respinto il suggerimento e conserva la motivazione. Lo strumento aiuta il lavoro, ma non sostituisce il giudizio del responsabile.

Regola di correzione: integra la decisione mancante sull'ID originale con data reale, decisore nominato ed evidenze disponibili in quel momento. Se approvazione o evidenza non esistevano, apri un'azione correttiva invece di ricostruirle come se fossero esistite.

Non retrodatare e non sovrascrivere la cronologia. Una lacuna correggibile diventerebbe anche un problema di integrità del registro.

Sette controlli prima della chiusura

Applica queste sette domande a ogni ID aperto o chiuso di recente. Per ciascuna, definisci che cosa costituisce un esito positivo e quale segnale richiede un approfondimento.

Il quinto controllo richiede particolare cura. Il chiarimento del Garante sulla notifica delle violazioni ricorda che la notifica non è richiesta quando è improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone. Questo non elimina l'obbligo di documentare la valutazione. Una decisione di non notificare deve poter essere ricostruita attraverso natura dell'incidente, categorie e volume approssimativo dei dati, numero e tipologia delle persone interessate, possibili conseguenze, misure adottate, motivazione conclusiva, approvatore ed eventuali revisioni. «Rischio basso», da solo, non basta.

Anche il sesto controllo distingue due fatti: l'evidenza di chiusura dimostra che l'azione è stata eseguita; la verifica di efficacia dimostra se ha funzionato. Questa guida alla verifica dell'efficacia della remediation offre un riferimento pratico se oggi i due passaggi coincidono.

Non serve esaminare subito ogni riga. Campiona alcuni record provenienti da audit, privacy, fornitori e processi 231. Il campione non supera il controllo se un record chiuso non ha verifica di efficacia o se la cronologia delle decisioni è stata sovrascritta. Registra questi difetti come nuovi rilievi sul processo di gestione, con responsabile e data propri, invece di modificare il passato per far risultare corretto il campione.

Le domande da chiarire prima del prossimo audit

Ogni evento di sicurezza va notificato al Garante? No. Registra l'evento, verifica se si è verificata una violazione dei dati personali, valuta il rischio per le persone e documenta la motivazione dell'eventuale decisione di non notificare. Il record deve rendere comprensibile la decisione, non mostrare soltanto una casella «rischio basso».

Un unico registro può coprire NIS2 e DORA? Sì, se per ogni rilievo restano identificabili requisiti applicabili, responsabile, scadenza ed evidenze. Prepara estratti per i diversi interlocutori, invece di copiare le righe in fogli separati che possono divergere.

Chi può chiudere un record? Una persona diversa da chi ha eseguito la correzione dovrebbe esaminare le evidenze e verificarne l'efficacia. Se le dimensioni del team non consentono una separazione completa, documenta il limite e affida la revisione a un responsabile esterno all'intervento. Aver completato l'attività non prova che il controllo funzioni.

Quanto può restare aperta un'eccezione? Solo fino alla scadenza approvata. Un rinnovo richiede una nuova decisione e una nuova data finale: riutilizzare la vecchia approvazione lascia indeterminato il rischio attuale.

Che cosa può fare un software? Può raccogliere rilievi provenienti da audit, incidenti, test, privacy e inserimenti manuali, collegandoli a responsabili, scadenze, azioni ed evidenze di chiusura. Può conservare versioni e cronologia non sovrascrivibile, richiedere prove ai fornitori tramite canali sicuri, supportare i flussi relativi al Modello 231 e all'OdV ed esportare un Audit Day Pack. Non può certificare automaticamente la conformità NIS2, sostituire OdV o DPO, né garantire l'eliminazione del rischio. AuditReady non è un punteggio automatico di conformità: supporta il lavoro, mentre valutazioni, obblighi e decisioni restano in capo al cliente.

Da fare nella prima settimana. Verifica alcuni rilievi chiusi di recente usando i sette controlli, riapri quelli privi di verifica di efficacia e trasferisci nel registro i rilievi ancora dispersi tra email e chat. Poi controlla che ogni record aperto abbia un responsabile, una scadenza e una catena di evidenze. Per vedere come AuditReady riunisce rilievi, responsabili ed evidenze versionate, visita AuditReady.

Un registro ordinato non dimostra, da solo, che il controllo sia stato eseguito. Prima del prossimo audit, verifica che ogni record colleghi rilievo iniziale, azione correttiva, prova dell'intervento e decisione separata sulla sua efficacia. Chiudere prima di quest'ultimo controllo può far apparire risolta una debolezza che non lo è.