Un registro delle non conformità serve a trasformare scostamenti, findings e anomalie in lavoro gestibile: owner chiari, azioni correttive, scadenze, evidenze e verifiche di efficacia. Per compliance, DPO, CISO, risk manager e internal auditor non è un file accessorio, ma il punto in cui un problema diventa tracciabile fino alla chiusura.
Questa guida ha un taglio operativo. Non interpreta norme né sostituisce consulenza legale: mostra come strutturare un registro che aiuti a dimostrare cosa è stato rilevato, chi se ne occupa, quali azioni sono state decise e con quali prove verificabili la non conformità può essere considerata risolta.
Perché il registro delle non conformità non è solo un elenco di problemi
Un registro fatto male contiene righe generiche come “policy non aggiornata” o “mancanza evidenze”. Un registro utile, invece, collega ogni rilievo a un requisito, a un controllo, a un rischio e a una remediation verificabile. Questa differenza è decisiva quando un auditor chiede non solo se avete chiuso un finding, ma anche come lo dimostrate.
Nel GDPR, il principio di responsabilizzazione richiede al titolare di poter dimostrare il rispetto dei principi applicabili al trattamento. Il riferimento operativo parte dall’articolo 5, paragrafo 2 del Regolamento UE 2016/679 su EUR-Lex. In ambito NIS2, il tema si sposta sui controlli di sicurezza, sulla gestione del rischio e sulla continuità delle misure, come previsto dalla Direttiva UE 2022/2555. Per DORA, la logica è analoga ma riferita alla resilienza operativa digitale e al rischio ICT, secondo il Regolamento UE 2022/2554.
Il punto non è citare la norma dentro ogni riga. Il punto è rendere il registro delle non conformità capace di rispondere a tre domande pratiche: che cosa non funziona, quale rischio produce e quale evidenza prova che la correzione è stata completata.
Quando aprire una non conformità
Una non conformità va aperta quando c’è uno scostamento verificabile rispetto a un requisito, una procedura approvata, un controllo atteso o un impegno preso verso un auditor, un cliente o un organo interno. Non ogni anomalia deve diventare automaticamente una non conformità formale, ma ogni anomalia rilevante deve avere un criterio di triage.
Il modo più solido è definire soglie prima dell’audit. Per esempio, un controllo eseguito in ritardo può essere registrato come osservazione se non ha impatto sul rischio, ma diventa non conformità se impedisce di dimostrare il presidio previsto. Questo approccio è coerente con una logica di conformità dimostrabile negli audit GDPR, dove la prova conta quanto la procedura.
| Evento rilevato | Aprire una non conformità? | Evidenza iniziale da allegare |
|---|---|---|
| Controllo pianificato non eseguito | Sì, se il controllo è obbligatorio o critico | Piano controlli, calendario, assenza di output |
| Evidenza mancante durante audit interno | Sì, se non recuperabile o non tracciabile | Checklist audit, richiesta auditor, risposta del team |
| Incidente gestito fuori procedura | Sì, se la procedura era applicabile | Ticket, timeline, report incidente |
| Policy scaduta ma processo operativo presidiato | Dipende dalla criticità | Versione policy, approvazioni, controlli alternativi |
| Fornitore senza attestazione richiesta | Sì, se il requisito è contrattuale o di controllo | Richiesta inviata, contratto, risposta fornitore |
Campi minimi da prevedere
Il registro deve essere abbastanza dettagliato da sostenere un audit, ma non così complesso da scoraggiare l’aggiornamento. Se i campi sono troppi, i team li compilano male. Se sono troppo pochi, la tracciabilità non regge.
Identificazione e contesto
Il primo blocco del registro deve descrivere la non conformità in modo verificabile. Evita frasi soggettive come “controllo inadeguato” se non sono accompagnate da un fatto osservabile. Scrivi invece: “Il riesame trimestrale degli accessi privilegiati Q2 non risulta completato entro la data prevista dalla procedura IAM”.
| Campo | Come compilarlo | Errore da evitare |
|---|---|---|
| ID univoco | Codice progressivo, per esempio NC-2026-014 | Usare nomi duplicati o non ordinabili |
| Data rilevazione | Giorno in cui il finding viene formalizzato | Confonderla con la data dell’evento |
| Fonte | Audit interno, audit cliente, controllo automatico, incidente, fornitore | Scrivere “varie” o “segnalazione” senza dettaglio |
| Descrizione | Fatto osservabile, sistema o processo coinvolto | Descrivere opinioni o colpe personali |
| Requisito collegato | Norma, policy, controllo interno o clausola contrattuale | Lasciare il requisito implicito |
| Ambito | GDPR, NIS2, DORA, ISO 27001, 231, AI Act o controllo comune | Aprire record separati se il finding è lo stesso |
In questa fase il registro delle non conformità deve già collegare il finding al controllo interessato, perché la remediation non riguarda solo il sintomo. Se manca il collegamento al controllo, sarà difficile capire se l’azione risolve davvero il problema o produce solo un documento in più.
Owner, rischio e priorità
Ogni record deve avere un owner operativo, non solo una funzione generica. “IT” non è un owner. “Responsabile infrastruttura cloud” o “Process owner gestione accessi” sono assegnazioni molto più utili, perché consentono follow-up e accountability.
La priorità dovrebbe derivare dal rischio, non dalla pressione del momento. Puoi usare una matrice semplice basata su impatto, probabilità e urgenza di audit. Per esempio, una non conformità che impedisce di produrre evidenze su accessi amministrativi ha priorità alta se riguarda sistemi critici, anche se non ha ancora generato un incidente.
| Campo | Scopo operativo | Evidenza utile |
|---|---|---|
| Owner | Persona responsabile della chiusura | Assegnazione approvata o workflow |
| Funzione coinvolta | Team che deve contribuire | RACI, organigramma, procedura |
| Gravità | Impatto potenziale su rischio, dati o servizio | Risk assessment, classificazione asset |
| Priorità | Sequenza di intervento | Piano remediation approvato |
| Scadenza | Data attesa di chiusura | Piano azioni, verbale o ticket |
| Escalation | Soglia oltre cui coinvolgere management o comitato | Regole di governance |
Dalle non conformità alle azioni correttive
Una delle debolezze più frequenti è confondere azione immediata e azione correttiva. L’azione immediata contiene il problema. L’azione correttiva rimuove o riduce la causa che lo ha generato. Se un’evidenza manca, caricarla dopo l’audit può risolvere il vuoto documentale, ma non spiega perché il controllo non l’ha prodotta al momento giusto.
Il percorso dovrebbe separare quattro livelli: contenimento, analisi causa radice, remediation e verifica di efficacia. Questa distinzione rende il registro delle non conformità utile anche per audit successivi, perché mostra che l’organizzazione non si limita a “chiudere righe”, ma migliora il controllo.
| Livello | Domanda operativa | Esempio |
|---|---|---|
| Contenimento | Cosa facciamo subito per ridurre il rischio? | Revoca temporanea di accessi non riesaminati |
| Causa radice | Perché il controllo non ha funzionato? | Mancava un owner per l’estrazione utenti |
| Azione correttiva | Quale modifica impedisce il ripetersi? | Automatizzare report mensile e approvazione owner |
| Verifica di efficacia | Come proviamo che ora funziona? | Campione del riesame successivo, log e approvazione |
Come dimostrare che una non conformità è chiusa
La chiusura non dovrebbe dipendere da una dichiarazione del tipo “attività completata”. Serve un pacchetto minimo di evidenze che consenta a un auditor di ricostruire decisioni, azioni e risultati. Per impostare questo pacchetto conviene ragionare già in termini di evidenze di audit verificabili, non di allegati caricati all’ultimo momento.
Una chiusura robusta contiene almeno quattro elementi. Primo, la prova dell’azione eseguita, per esempio ticket, configurazione, verbale, report o screenshot contestualizzato. Secondo, la prova dell’approvazione da parte dell’owner o del responsabile del controllo. Terzo, la prova della verifica di efficacia. Quarto, la tracciabilità delle modifiche al record.
Il registro delle non conformità dovrebbe conservare anche lo storico: chi ha cambiato lo stato, quando, con quale motivazione e su quale evidenza. Questo è il motivo per cui l’audit trail non è un dettaglio tecnico. È la base per dimostrare integrità, sequenza temporale e responsabilità, come approfondito nelle best practice sull’audit trail.
| Stato | Criterio di ingresso | Criterio di uscita |
|---|---|---|
| Aperta | Finding formalizzato e assegnato | Owner e scadenza confermati |
| In analisi | Causa radice in valutazione | Piano azioni approvato |
| In remediation | Azioni avviate | Evidenze caricate e controllate |
| In verifica | Azione dichiarata completata | Test di efficacia superato |
| Chiusa | Verifica positiva | Chiusura approvata e tracciata |
| Riaperta | Evidenza insufficiente o ricorrenza | Nuova analisi causa radice |
Esempio pratico: accessi privilegiati non riesaminati
Immagina che durante un audit interno emerga che il riesame trimestrale degli accessi privilegiati non è stato completato per un sistema che ospita dati personali e servizi critici. Il finding non va registrato come “mancato controllo accessi” in modo generico. Va circoscritto.
Una descrizione utile potrebbe essere: “Il riesame degli utenti amministratori del sistema X per il trimestre Q2 non risulta completato entro il 30 giugno, come previsto dalla procedura IAM-04. Non sono presenti evidenze di approvazione da parte del system owner”.
Nel registro, il requisito collegato può essere una procedura interna, un controllo ISO 27001 o un controllo NIS2/DORA mappato internamente. La fonte è l’audit interno. L’owner è il system owner o il responsabile IAM, non il team compliance. Il rischio è l’accesso privilegiato non giustificato. L’azione immediata può essere il riesame straordinario degli account. La causa radice potrebbe essere la mancata generazione automatica del report utenti. L’azione correttiva può consistere nell’inserire un’attività ricorrente con evidenza obbligatoria e approvazione tracciata.
In un caso simile, il registro delle non conformità diventa la linea temporale del miglioramento: rilevazione, assegnazione, analisi, azione, evidenza, verifica e chiusura.
Errori comuni da evitare
Il primo errore è aprire record troppo generici. Se la descrizione non permette di capire processo, controllo, requisito e impatto, la non conformità non sarà gestibile. Un auditor non dovrebbe dover intervistare tre persone per capire cosa significa una riga del registro.
Il secondo errore è chiudere senza verifica di efficacia. Se l’azione consiste nell’aggiornare una procedura, serve anche una prova che la procedura sia stata applicata. Altrimenti si produce documentazione, non controllo.
Altri errori ricorrenti sono semplici da prevenire:
- Owner assegnati a funzioni generiche invece che a persone o ruoli responsabili.
- Scadenze modificate senza motivazione e senza approvazione.
- Evidenze caricate senza contesto, data o collegamento al controllo.
- Non conformità ricorrenti trattate come episodi isolati.
- Fornitori coinvolti nella remediation senza tracciamento delle richieste e delle risposte.
Se l’organizzazione gestisce audit interni periodici, il registro dovrebbe alimentare anche il piano di follow-up. In questo modo i findings non restano confinati al report, ma diventano attività controllate dentro un processo di audit interno basato su evidenze.
Collegare il registro ai framework senza duplicare il lavoro
La stessa non conformità può interessare più framework. Un accesso privilegiato non riesaminato può avere impatti su GDPR, NIS2, DORA, ISO 27001 e procedure interne. Aprire cinque record separati crea rumore e aumenta il rischio di aggiornamenti incoerenti.
La soluzione operativa è usare un record principale con mappatura multipla dei requisiti. Il finding resta uno, ma viene collegato ai controlli applicabili. Questo approccio è particolarmente utile quando i controlli sono già organizzati in una matrice comune, come avviene nei programmi che collegano requisiti, owner, rischi ed evidenze.
| Framework | Cosa collegare nel registro | Prova attesa |
|---|---|---|
| GDPR | Principio, misura organizzativa o controllo privacy interno | Evidenza del controllo e accountability |
| NIS2 | Misura di gestione del rischio cyber o controllo operativo | Piano remediation, test, approvazioni |
| DORA | Processo ICT, rischio, incidente o resilienza operativa digitale | Evidenze ICT, timeline, verifica di efficacia |
| ISO 27001 | Controllo del sistema di gestione e relativa registrazione | Record, riesame, azione correttiva |
| Modello 231 | Procedura, controllo organizzativo o flusso verso funzioni competenti | Verbali, follow-up, tracciabilità decisionale |
Per ISO 27001, il riferimento deve restare legato al sistema di gestione e alle registrazioni previste dall’organizzazione; la pagina ufficiale ISO/IEC 27001 descrive lo standard come riferimento per i sistemi di gestione della sicurezza delle informazioni. Per gli altri framework, il collegamento va adattato al perimetro effettivo dell’azienda e validato internamente con le funzioni competenti.
Frequenza di riesame e reporting
Un registro aggiornato solo prima dell’audit perde gran parte del suo valore. La frequenza di riesame dovrebbe dipendere dal livello di rischio e dalla pressione regolatoria o contrattuale. In molte organizzazioni funziona un riesame mensile operativo e un riepilogo trimestrale per il management, ma la frequenza va definita in base al contesto.
Il reporting non dovrebbe limitarsi al numero di record aperti e chiusi. Meglio includere trend, ritardi, ricorrenze, aree con più findings, azioni scadute e non conformità riaperte. Questi dati aiutano a distinguere tra un problema puntuale e una debolezza strutturale del sistema di controllo.
Il registro delle non conformità dovrebbe quindi produrre almeno tre viste: una operativa per gli owner, una di rischio per management e comitati, una di audit pack per auditor interni o esterni. Le informazioni possono essere le stesse, ma il livello di dettaglio cambia.
FAQ
Chi dovrebbe essere owner di una non conformità? L’owner dovrebbe essere il responsabile operativo capace di eseguire o coordinare la remediation. Compliance, DPO o audit possono monitorare il processo, ma non dovrebbero diventare owner di problemi che appartengono a sistemi, processi o fornitori specifici.
Una non conformità deve sempre avere una causa radice? Per i findings rilevanti sì, perché senza causa radice si rischia di correggere solo il sintomo. Per anomalie minori può bastare una classificazione semplificata, purché il criterio sia definito prima e applicato in modo coerente.
Quali evidenze servono per chiudere una non conformità? Servono prove dell’azione svolta, approvazione dell’owner, verifica di efficacia e audit trail della chiusura. La tipologia dipende dal controllo: ticket, log, report, verbali, configurazioni, attestazioni o campioni verificati.
Il registro può coprire più normative insieme? Sì, se il finding è unico e i requisiti vengono mappati in modo trasparente. È preferibile evitare duplicazioni e mantenere un solo record collegato a più controlli, con evidenze riutilizzabili dove coerente.
Il registro delle non conformità è obbligatorio per legge? Dipende dal contesto, dal framework e dagli obblighi applicabili. Questa guida non fornisce un parere legale. Dal punto di vista operativo, un registro strutturato aiuta a dimostrare gestione, follow-up e miglioramento continuo durante audit interni ed esterni.
Preparare remediation ed evidenze senza perdere tracciabilità
Se il tuo team deve gestire findings, azioni correttive ed evidenze in un percorso di conformità NIS2, puoi valutare AuditReady per organizzare controlli e audit pack NIS2 con un approccio centrato su ownership, tracciabilità e prove verificabili.
audit-ready evidence pack demo / not legal advice