La policy è approvata, il controllo risulta completato e il file è nella cartella dell'audit. Quando l'auditor chiede chi abbia eseguito la verifica, su quale periodo e con quale versione del documento, però, il team deve ricostruire tutto dalle email. È questo il problema che un compliance management software deve risolvere: rendere verificabile l'esecuzione, non soltanto conservare documenti.
Il taglio è operativo, non costituisce un parere legale. Il riferimento è il lavoro di CISO, responsabili compliance e rischio, internal auditor, DPO, responsabili IT e sicurezza, membri dell'Organismo di Vigilanza e consulenti GRC di PMI e imprese italiane.
Meta descrizione: Compliance management software: criteri, ruoli e campi per collegare controlli, evidenze e remediation e preparare un audit verificabile.
Percorso URL: software-gestione-conformita-prove-audit
Indice
- Cosa rende verificabile un compliance management software
- Dal requisito al rimedio con ruoli separati
- Criteri per scegliere senza delegare la responsabilità
- Campi minimi di registri incidenti fornitori e OdV
- Errori comuni che indeboliscono l'audit
- Sette controlli prima di aprire l'audit
- Domande frequenti su software e prove
Cosa rende verificabile un compliance management software
Un controllo non è dimostrato perché qualcuno ha selezionato lo stato completato. Occorre poter ricostruire oggetto della verifica, periodo coperto, responsabile, risultato e documento esaminato. Se manca uno di questi collegamenti, l'auditor non può distinguere un'attività eseguita da una dichiarazione inserita a posteriori.
La catena da mantenere è requisito → controllo operativo → owner → evidenza datata e verificabile → audit trail immutabile → eccezione o finding → remediation. Il software deve conservare le relazioni tra questi elementi anche quando cambiano le persone, le policy o i sistemi coinvolti.
La prova deve conservare il proprio contesto
Una policy descrive ciò che l'organizzazione intende fare. Il registro di esecuzione dimostra ciò che una persona ha fatto, con quale esito e in quale momento. Un archivio di PDF può contenere entrambi, ma non necessariamente permette di riconoscerne il rapporto.
La relazione del Garante per la protezione dei dati personali indica 2.415 data breach notificati nel 2025, contro 2.204 nel 2024. Per governare questi eventi, organizzazioni pubbliche e private devono collegare rilevazione, decisioni, scadenze e prova della tempestività delle azioni, anche fuori dai grandi intermediari finanziari.
La distinzione tra scostamenti conta quanto quella tra documenti. Un'eccezione è una deroga autorizzata, motivata e a termine; un finding registra una non-conformità rilevata; un incidente descrive un evento operativo o di sicurezza. Possono essere collegati, ma non devono condividere indistintamente stati, approvazioni e criteri di chiusura.
Criterio operativo: una prova è utile quando un verificatore può comprenderla senza chiedere all'autore di ricostruirne oralmente il significato.
Prima della demo, verificare le relazioni
Per coordinare processi e responsabilità, l'approfondimento di Spark sul sistema di gestione integrato offre un riferimento sul piano organizzativo. L'integrazione dei processi, tuttavia, va tradotta in registrazioni verificabili: condividere una procedura non significa aver dimostrato ogni controllo.
L'automazione può raccogliere documenti e assegnare attività. La responsabilità del rischio resta umana, mentre l'interpretazione giuridica richiede competenze distinte dall'amministrazione del software.
Capacità del software e prova minima
| Funzione | Domanda dell'auditor | Evidenza minima |
|---|---|---|
| Mappa dei controlli | Il controllo era solo previsto o risulta eseguito nel periodo? | Requisito collegato, owner, periodo, esito |
| Versione dell'evidenza | Il file esaminato è quello approvato? | Versione, impronta di integrità, data e approvazione riferita al file |
| Audit trail | Chi ha cambiato stato e quando? | Log immutabile di creazione, approvazione e modifica |
| Richiesta al fornitore | La terza parte ha risposto entro il termine? | Link a scadenza, documento, data di ricezione, eventuale gap |
| Finding e remediation | La chiusura è provata o solo dichiarata? | Severità, owner, scadenza, azione, evidenza di chiusura |
| Eccezione al controllo | L'eccezione è autorizzata e a termine? | Richiedente, approvatore diverso, scadenza, controllo compensativo |
Usate questa griglia prima della demo. Una schermata ordinata non compensa l'assenza di owner, data o integrità verificabile.
Dal requisito al rimedio con ruoli separati
Chi esegue un'attività conosce il dettaglio tecnico, ma non dovrebbe essere l'unico a giudicare sufficiente la propria prova. La separazione dei ruoli serve a rendere visibili errori, omissioni e conflitti, non ad aggiungere passaggi formali.
La funzione compliance propone perimetro e calendario; un responsabile di vertice attesta il perimetro; l'owner esegue; un verificatore distinto controlla completezza e coerenza. L'internal audit o l'OdV, nel rispettivo mandato, campiona il processo senza produrre le evidenze al posto del responsabile operativo.
Definire il perimetro prima degli accessi
La disciplina NIS2, recepita con il D.Lgs. 138/2024, trova il proprio riferimento istituzionale nell’Agenzia per la Cybersicurezza Nazionale. Operativamente, occorre collegare entità e servizi interessati ai controlli applicabili, agli owner, agli incidenti, alle scadenze di notifica e alle prove di attuazione.
Una checklist annuale non permette, da sola, di distinguere controllo previsto, esecuzione documentata, finding aperto e piano di rimedio. Il calendario deve generare verifiche riferite a periodi riconoscibili, non un'unica attestazione indistinta.
Il processo può essere rappresentato così:
Nella nostra piattaforma definiamo perimetro, obiettivi, standard e scadenze collegando controlli, sistemi, asset, policy ed evidenze. AuditReady riunisce audit, evidenze, rischi, incidenti, privacy e governance in un ambiente operativo predisposto per il riesame; una policy espone versione, data di approvazione e persona responsabile.
Attribuire decisioni diverse a persone identificabili
Per un controllo condiviso tra IT e privacy, nominare due funzioni come responsabili lascia spesso irrisolta la decisione finale. Conviene individuare chi risponde dell'esecuzione e chi contribuisce, usando una assegnazione esplicita degli owner dei controlli condivisi.
Un'eccezione parte da una richiesta motivata e richiede un approvatore diverso dall'owner, un termine e un controllo compensativo. Alla scadenza si esegue il controllo originario oppure si rivaluta formalmente la situazione: il semplice rinnovo dello stato non costituisce una decisione.
L'automazione può assegnare scadenze e registrare passaggi. La gravità di uno scostamento e l'accettazione del rischio richiedono invece un responsabile identificato; la chiusura deve seguire una verifica della prova.
Flusso, responsabilità ed evidenza minima
| Fase o controllo | Decisione o responsabilità | Evidenza minima verificabile |
|---|---|---|
| Perimetro | Compliance propone, il vertice attesta | Profilo dell'entità, asset, servizi e policy con versione e data |
| Esecuzione | L'owner esegue, un soggetto diverso verifica | Periodo, esito, campione e collegamento al controllo |
| Eccezione | Un approvatore diverso dall'owner autorizza il termine | Motivazione, scadenza, controllo compensativo |
| Finding | Chi verifica apre, l'owner rimedia, un terzo chiude | ID, severità, piano, data prevista e data effettiva di chiusura, prova |
| Incidente | Security classifica, compliance controlla la scadenza | Orari, decisione di gravità, comunicazioni, rimedio |
Nelle organizzazioni piccole, la verifica distinta può essere affidata a un responsabile competente esterno al processo. Prima di configurare i permessi, i ruoli devono avere un nome nell'organigramma operativo.
Criteri per scegliere senza delegare la responsabilità
Una remediation in ritardo mette alla prova il software più di una schermata ordinata: si deve poter ricostruire il controllo, chi ne è responsabile, quale prova è stata raccolta e come viene gestita l'eccezione. In demo, seguite un controllo ricorrente, una richiesta straordinaria e una remediation scaduta. Verificate destinatario, contenuto e periodicità del controllo, responsabilità della risposta e registrazione del ritardo.
Un archivio conserva file; un questionario raccoglie dichiarazioni. Per sostenere una verifica, la catena deve collegare requisito, controllo, owner, evidenza datata, audit trail, eventuale finding e remediation. La responsabilità della valutazione legale resta distinta dal lavoro operativo di raccolta e gestione delle prove.
Il fornitore non si governa contando i questionari
Nell’analisi della Banca d'Italia sui gravi incidenti ICT del 2025, un fornitore o subfornitore era coinvolto nel 56% delle segnalazioni di gravi incidenti ICT. Perciò, valutate se il sistema collega servizio esternalizzato, funzione critica, rischio, controllo, contratto, incidente, test ed evidenza, non soltanto se archivia le risposte.
Archivio, questionario e catena di prove
| Criterio | Archivio documentale | Questionario fornitore | Catena di prove |
|---|---|---|---|
| Owner e periodo | Assenti o solo nel nome del file | Dichiarati dal fornitore | Owner, periodo ed esito collegati al controllo |
| Evidenza e verificabilità | Documento conservato senza collegamento al controllo | Risposta testuale, con o senza allegato | Evidenza associata al controllo, con contesto e tracciabilità delle operazioni critiche |
| Terze parti | Email o cartelle condivise | Account per ogni fornitore | Link a scadenza senza account e data di ricezione |
| Eccezioni e finding | Non tracciati | Non collegati al controllo | Severità del finding, scadenza, intervento e prova di chiusura |
Sono configurazioni da verificare, non limiti inevitabili di archivi o questionari. Anche un sistema semplice può funzionare; nella scelta, considerate il tempo necessario a ricostruire manualmente collegamenti e decisioni.
Modularità e limiti espliciti
AuditReady offre moduli per GDPR Light, GDPR completo, NIS2, DORA e Modello 231 con OdV, con un modello di evidenze condiviso tra obblighi. Molti clienti iniziano con GDPR Light o completo e aggiungono altri moduli quando emerge una nuova esigenza normativa.
La piattaforma riunisce audit, evidenze, rischi, incidenti, privacy e governance. Include richieste documentali sicure ai fornitori, findings con responsabili e scadenze e pacchetti strutturati per le revisioni, incluso l'Audit Day Pack. Le funzionalità DORA sono disponibili con i moduli Resilienza e incidenti ICT, Registro rischi e Inventario di compliance.
Nel Modello 231, le segnalazioni whistleblowing rilevanti possono generare eventi di compliance collegati a processi, protocolli e controlli. Per scegliere, verificate che il flusso mantenga il collegamento tra requisito, controllo, responsabile, evidenza e azione correttiva, senza confondere la gestione operativa con il parere legale.
Campi minimi di registri incidenti fornitori e OdV
Un registro utile permette di ricostruire una decisione. Un elenco di eventi senza responsabile, criteri e documenti collegati costringe invece il verificatore a interrogare chi lo ha compilato.
Per gli incidenti, il Regolamento UE 2022/2554, articolo 19, prevede la segnalazione degli incidenti ICT gravi all'autorità competente; la comunicazione della Banca d'Italia sul DORA indica il canale per gli intermediari vigilati interessati e il passaggio al regime DORA dal 17 gennaio 2025. Conservate quindi anche la motivazione della classificazione, non soltanto il ticket tecnico.
Registrare la decisione e le dipendenze
Nel registro fornitori, il dato decisivo non è soltanto la ragione sociale. Servono servizio sostenuto, materialità, contratto, owner interno, ultimo riesame, gap ed escalation: lo stesso fornitore può sostenere servizi con rilevanza diversa.
Per le funzioni critiche censiamo MTPD, RTO, RPO e owner, collegandoli a sistemi, asset, fornitori e controlli. I valori devono essere approvati dai responsabili del processo e coerenti con le dipendenze effettive, non copiati dai contratti senza verifica.
Registri e campi minimi verificabili
| Registro | Campi minimi audit-ready |
|---|---|
| Incidenti ICT o data breach | ID, classificazione, orari, motivazione della gravità, owner, scadenze di notifica, comunicazioni, evidenza di rimedio |
| Fornitori ICT | ID, fornitore, servizio, funzione critica, materialità, contratto, owner interno, rischio, ultimo e prossimo riesame, evidenze, gap, escalation |
| Funzioni critiche | ID, nome, MTPD, RTO, RPO, owner, sistemi, asset, fornitori, controlli collegati |
| Trattamenti, DPIA e DSAR | ID, owner, finalità, categorie, processo, rischio inerente e residuo, misure, approvazioni, revisione, scadenza e stato della richiesta |
| Whistleblowing verso il Modello 231 | Codice pratica, evento di governance senza testo della segnalazione, esito, decorrenza e termine di conservazione, verbale di cancellazione |
| Non-conformità | ID, origine, severità, owner, processo, rischio residuo, controlli compensativi, azione, scadenza prevista, data effettiva ed evidenza di chiusura |
Privacy e riservatezza richiedono campi distinti
Il Garante sulla DPIA precisa che la valutazione va effettuata prima dei trattamenti che possono comportare un rischio elevato per diritti e libertà degli interessati. La scheda deve conservare finalità, categorie di dati e interessati, minacce, probabilità, impatto, misure, rischio inerente e residuo, approvazioni e data di revisione.
RoPA, DPIA e DSAR non sono intercambiabili. Nel nostro ambiente hanno registrazioni con scadenze, affiancate dal registro fornitori ICT; per le richieste degli interessati occorre anche documentare ricezione, gestione, risposta e relativa prova.
Per il whistleblowing disciplinato dal D.Lgs. 24/2023, le indicazioni operative del Garante+%E2%80%93+INDICAZIONI+OPERATIVE.pdf/0bbf46f9-3a6b-7b58-2e38-a4e190deb40a?version=2.0) richiamano la conservazione per il tempo necessario alla trattazione e comunque non oltre cinque anni dalla comunicazione dell'esito finale, con cancellazione documentata da un verbale riferito esclusivamente al codice della pratica. Gli atti autonomi di procedimenti successivi seguono una gestione distinta.
Il fascicolo riservato della segnalazione e l'evento destinato alla governance non devono diventare copie dello stesso contenuto.
Nel Modello 231 trasferiamo l'evento, non il testo della segnalazione. I finding provenienti da audit, incidenti, test, privacy o inserimento manuale confluiscono invece nel registro delle non-conformità, mantenendo severità, responsabile, scadenza, intervento e prova di chiusura.
Errori comuni che indeboliscono l'audit
Approvare oggi un controllo eseguito mesi prima non dimostra che l'approvazione esistesse allora. L'audit trail rende visibile la data reale: registrate l'approvazione tardiva come tale, valutate il gap e predisponete un passaggio contestuale per le esecuzioni successive.
Anche un documento formalmente corretto può perdere valore se manca il contesto dell'operazione. Per un confronto su un processo documentale diverso, il caso CMR di Evolutio offre uno spunto sulla verifica dei documenti nel trasporto internazionale, senza sostituire l'analisi del proprio processo.
Errori da correggere nel flusso
- Eccezioni rinnovate senza rivalutazione. Il controllo resta di fatto disattivato e nessuno assume una nuova decisione sul rischio. Disabilitate il rinnovo automatico e richiedete motivazione, approvazione e verifica del controllo compensativo.
- Evidenze disperse. Email, chat e fogli separati impediscono di stabilire quale prova sostenga l'esito. Centralizzate il documento e mantenete il collegamento al controllo e al periodo.
- Screenshot privi di metadati. Senza data, sistema e contesto dell'utente non si ricostruisce l'operazione. Acquisite questi elementi e, quando disponibile, preferite un'esportazione verificabile.
- Chiusure autodichiarate. Lo stato completato non dimostra che il problema sia risolto. Affidate a un soggetto diverso la verifica dell'efficacia della remediation.
- Segnalazioni duplicate nel fascicolo di governance. La copia del testo whistleblowing amplia inutilmente l'accesso a contenuti riservati. Trasferite soltanto l'evento pertinente e mantenete distinti autorizzazioni e fascicoli.
Un progetto avviato non equivale a capacità operativa
L’opinione ENISA del 2025 sull'attuazione NIS2 riporta che le aziende destinano mediamente l’11,1% degli equivalenti a tempo pieno IT alla cybersecurity, mentre l’80-90% prevede ulteriore personale per NIS2, CRA, DORA e altri requisiti; richiama inoltre una rilevazione italiana del 2025 secondo cui soltanto il 61% delle imprese con un'iniziativa strutturata avviata risultava in linea con NIS2.
Aprire il programma non assicura quindi tempo disponibile per eseguire test e verificare chiusure. Assegnate un sostituto agli owner, pianificate le raccolte e rendete visibile al vertice l'arretrato: acquistare altri questionari non risolve un calendario senza persone disponibili.
Sette controlli prima di aprire l'audit
Selezionate un campione di controlli del trimestre scorso. Non partite dall'intero archivio: una verifica mirata permette di osservare se il team registra l'esecuzione reale oppure soltanto la previsione.
Le domande devono essere risolte aprendo registrazioni e documenti, non chiedendo conferme verbali agli owner.
- Owner identificato. Il responsabile è una persona nominata oppure una funzione generica alla quale nessuno ha assegnato l'esecuzione?
- Integrità verificabile. L'evidenza riporta data, versione e impronta SHA-256 oppure consiste in uno screenshot senza metadati?
- Ruoli separati. L'approvatore è distinto dall'esecutore e la chiusura del finding è affidata a un verificatore diverso dall'owner della remediation?
- Eccezioni valide. Ogni deroga aperta è ancora autorizzata e nel termine, oppure è stata rinnovata senza nuova motivazione?
- Incidente ricostruibile. Un caso di prova mostra classificazione, orari, decisione sulla gravità e comunicazioni oppure soltanto il ticket tecnico?
- Fornitore collegato. Ogni servizio materiale è associato alla funzione sostenuta e, quando critica, alla relativa funzione critica, con prove ricevute attraverso un canale tracciato?
- Riuso contestualizzato. Il documento utilizzato per GDPR, NIS2 o DORA mantiene il collegamento al requisito, al periodo e alla valutazione pertinente per ciascun obbligo?
Correggere prima di esportare
Come regola interna di preparazione, considerate il fascicolo non pronto quando più risposte sono negative. Anche una sola lacuna sostanziale può richiedere un finding: la checklist non sostituisce il giudizio del verificatore.
Prima dell'esportazione: correggete owner, date e chiusure; lasciate visibili i punti ancora aperti, con responsabile e piano di trattamento.
Con AuditReady, GDPR Light comprende raccolta delle evidenze, gestione degli audit e preparazione dell'Audit Day Pack. Le nostre demo coprono GDPR, NIS2, EU AI Act, Modello 231 e DORA: il campione è una base concreta per verificare il flusso pertinente, invece di limitarsi a osservare schermate.
Domande frequenti su software e prove
Il software sostituisce il legale o l'OdV?
No. Organizza attività, documenti e responsabilità, ma non assume il mandato dell'Organismo di Vigilanza nel Modello 231 né quello del consulente legale. L'OdV conserva autonomia di verifica e iniziativa: accessi e flussi devono consentirgli di esaminare le prove senza trasformarlo nell'esecutore dei controlli.
Un'eccezione rinnovata è sempre un finding?
Il rinnovo non determina da solo la classificazione. Se mancano una nuova approvazione motivata, un termine o il controllo compensativo previsto dalla procedura, il verificatore deve registrare lo scostamento come non-conformità secondo i criteri adottati. Un eventuale incidente resta un evento distinto, anche quando nasce dalla stessa debolezza.
Come raccogliere prove dai fornitori senza creare account?
Utilizziamo collegamenti sicuri a scadenza, associando la richiesta al servizio e all'owner interno. La ricezione deve essere tracciata, ma ricevere un file non equivale ad accettarlo: il verificatore controlla pertinenza, periodo coperto e completezza, registrando eventuali gap o ritardi.
Un inventario AI permette di chiudere un controllo?
No. Ogni sistema AI può condividere controlli, evidenze e incidenti con il resto del perimetro, ma l'inventario non sostituisce una valutazione di conformità ai sensi dell'EU AI Act. Le valutazioni regolamentari rimangono responsabilità del cliente e l'approvazione finale deve essere attribuita a persone identificate.
Per chiudere un controllo servono un criterio di accettazione, un'attività effettivamente svolta e una prova verificata. Nessuna piattaforma garantisce conformità automatica o assenza di rischio.
AuditReady collega controlli, owner, evidenze versionate, finding e piani di remediation, preparando pacchetti strutturati per la revisione. Visitate AuditReady e portate alla demo un controllo ricorrente, una richiesta a un fornitore e una chiusura da verificare: sono casi concreti per valutare la tenuta della vostra catena di prove.
audit-ready evidence pack demo / not legal advice