Nella compliance it le eccezioni ai controlli non sono un dettaglio amministrativo: sono il punto in cui una misura prevista non viene applicata, viene applicata in modo diverso o resta temporaneamente incompleta. Se non sono governate, diventano non conformità difficili da spiegare durante un audit. Se invece sono tracciate con owner, motivazione, rischio, controlli compensativi e data di chiusura, diventano una parte verificabile del sistema di controllo.
Questo articolo ha un taglio operativo, non legale. L’obiettivo è descrivere un workflow essenziale per dimostrare come un’organizzazione gestisce le eccezioni ai controlli IT, senza sostituire valutazioni legali, privacy o regolamentari quando servono.
Workflow essenziale per gestire eccezioni nella compliance it
Una eccezione ai controlli nasce quando un controllo approvato non può essere eseguito come previsto. Può riguardare una patch non installata entro SLA, una configurazione temporaneamente diversa dallo standard, un account privilegiato mantenuto oltre la scadenza, un test di backup rinviato o una evidenza mancante per un fornitore.
La gestione non deve partire dalla domanda “possiamo fare una deroga?”, ma da una domanda più utile per l’audit: “quale prova dimostra che la deroga è nota, approvata, limitata e monitorata?”. Questa impostazione evita che l’eccezione resti in una mail, in una chat o nella memoria del team IT.
Un workflow minimo dovrebbe coprire cinque passaggi: apertura, classificazione, approvazione, monitoraggio e chiusura. Ogni passaggio produce evidenze. Senza evidenze, anche una decisione ragionevole rischia di apparire non governata.
| Fase | Decisione da documentare | Evidenza minima |
|---|---|---|
| Apertura | Quale controllo non è rispettato e perché | Ticket, richiesta formale, asset o processo coinvolto |
| Classificazione | Impatto, rischio e urgenza | Valutazione rischio, severità, riferimento al requisito |
| Approvazione | Chi accetta l’eccezione e fino a quando | Approvazione owner, data di scadenza, condizioni |
| Monitoraggio | Come si riduce il rischio nel frattempo | Controlli compensativi, check periodici, log |
| Chiusura | Come si torna allo stato conforme | Prova di remediation, verifica finale, audit trail |
Quando una eccezione è accettabile e quando è un finding
Per la compliance it, una eccezione non dovrebbe essere usata per normalizzare un controllo inefficace. È accettabile solo se ha uno scopo preciso, una durata limitata, una responsabilità chiara e un rischio residuo esplicitato. Se manca uno di questi elementi, l’eccezione tende a diventare un finding o una non conformità.
Le norme e i framework non gestiscono tutti le eccezioni con lo stesso linguaggio, ma spingono nella stessa direzione: controlli proporzionati al rischio, responsabilità definite e capacità di dimostrare ciò che è stato fatto. La Direttiva NIS2 su EUR-Lex richiede misure di gestione dei rischi di cibersicurezza per soggetti essenziali e importanti. Il Regolamento DORA su EUR-Lex concentra l’attenzione sulla resilienza operativa digitale nel settore finanziario. Il GDPR su EUR-Lex richiede misure tecniche e organizzative adeguate al rischio del trattamento. ISO pubblica inoltre lo standard ISO/IEC 27001 per i sistemi di gestione della sicurezza delle informazioni.
In pratica, il punto non è citare il framework nel registro, ma collegare l’eccezione al controllo effettivo. Se un controllo esiste per ridurre un rischio, la deroga deve spiegare quale rischio resta aperto e chi lo accetta.
Eccezione, finding e incidente non sono sinonimi
Una eccezione è una deviazione autorizzata e temporanea da un controllo. Un finding è una carenza rilevata da un audit, da un assessment o da una verifica interna. Un incidente è un evento che compromette o può compromettere sicurezza, disponibilità, integrità o riservatezza.
Questa distinzione aiuta a scegliere il workflow corretto. Una patch rinviata con approvazione, rischio valutato e controllo compensativo può essere una eccezione. La stessa patch rinviata senza approvazione può diventare un finding. Se la vulnerabilità viene sfruttata, il caso entra nel processo di incident management.
Il registro delle eccezioni come prova centrale
Nella compliance it il registro delle eccezioni è più importante del singolo documento di deroga. Deve mostrare lo stato complessivo delle deviazioni dai controlli, chi le possiede e quali sono prossime alla scadenza. Un registro fatto bene permette a CISO, DPO, risk manager e auditor interni di capire se le eccezioni sono casi isolati o segnali di debolezza sistemica.
Per essere utile, il registro non deve diventare un archivio descrittivo senza disciplina. Ogni riga dovrebbe essere collegata a un controllo, a un asset o processo, a un rischio e a una data di riesame. Se l’eccezione riguarda trattamenti di dati personali, è opportuno coinvolgere le funzioni privacy competenti. Se riguarda servizi ICT critici o fornitori, va considerato anche l’impatto su resilienza e continuità operativa.
Per costruire una base difendibile, puoi collegare il registro alle prove già raccolte nel processo di gestione delle evidenze di audit, evitando duplicazioni e file scollegati.
Campi minimi da includere
Un registro troppo complesso non viene aggiornato. Uno troppo semplice non regge l’audit. La struttura essenziale dovrebbe includere almeno:
- ID univoco dell’eccezione e data di apertura
- Controllo, requisito o policy interna interessata
- Asset, sistema, processo o fornitore coinvolto
- Motivazione operativa della deviazione
- Owner del controllo e owner della remediation
- Valutazione del rischio e rischio residuo
- Controlli compensativi attivi durante l’eccezione
- Approvazioni richieste e ottenute
- Data di scadenza, stato e prova di chiusura
Questi campi permettono di ricostruire la storia dell’eccezione senza cercare informazioni in strumenti diversi.
Evidenze da raccogliere per ogni eccezione
Un’eccezione non è dimostrabile solo perché è stata approvata. Serve un evidence pack proporzionato alla criticità. In un audit, la domanda tipica non è “avete un registro?”, ma “come sappiamo che questa eccezione è stata gestita davvero?”.
Le evidenze devono coprire decisione, esecuzione e chiusura. Per la compliance it, questo significa conservare prove verificabili e datate, non screenshot casuali senza contesto. Se usi screenshot, devono mostrare sistema, data rilevante e configurazione interessata. Se usi ticket, devono contenere conversazioni, approvazioni e cambi di stato.
| Tipo di evidenza | Cosa dimostra | Esempio operativo |
|---|---|---|
| Richiesta di eccezione | Motivo e ambito | Ticket con controllo interessato e asset coinvolto |
| Risk assessment | Rischio residuo accettato | Valutazione con impatto, probabilità e motivazione |
| Approvazione | Responsabilità della decisione | Approvazione dell’owner e, se necessario, della funzione rischio |
| Controllo compensativo | Riduzione temporanea del rischio | Regole di monitoraggio, segregazione, access review extra |
| Remediation | Rientro nello standard | Evidenza di patch, configurazione corretta o controllo rieseguito |
| Audit trail | Integrità della storia | Log delle modifiche, versioni, timestamp e utenti coinvolti |
Il tema dell’audit trail merita attenzione separata: se approvazioni e modifiche possono essere alterate senza traccia, l’evidenza perde forza. Per questo conviene applicare buone pratiche di audit trail per controlli ed evidenze, soprattutto sui passaggi di approvazione e chiusura.
Workflow operativo end-to-end
Un workflow di eccezione efficace nella compliance it deve essere abbastanza semplice da essere usato dal team IT, ma abbastanza rigoroso da sostenere una verifica esterna. Il principio guida è separare chi segnala, chi approva, chi esegue la remediation e chi verifica la chiusura quando il rischio lo richiede.
Apertura e triage
L’apertura dovrebbe avvenire appena si rileva che un controllo non sarà rispettato nei tempi o nelle modalità previste. Aspettare la scadenza peggiora la qualità della decisione, perché riduce il tempo per valutare alternative e controlli compensativi.
Nel triage si verifica se la richiesta è davvero una eccezione. Se il controllo è sbagliato o non più applicabile, serve una revisione del controllo. Se c’è già una carenza rilevata, si tratta di un finding. Se c’è un evento di sicurezza, il processo corretto è quello degli incidenti.
Approvazione con owner e rischio residuo
L’approvazione non dovrebbe essere lasciata solo al team che subisce il problema operativo. L’owner del controllo deve confermare l’impatto sul presidio, il risk owner deve accettare il rischio residuo e le funzioni competenti devono essere coinvolte quando l’eccezione tocca dati personali, servizi critici o fornitori rilevanti.
La scadenza è parte dell’approvazione, non un campo accessorio. Un’eccezione senza data di fine è una modifica permanente non governata. Anche quando la remediation richiede tempi lunghi, conviene impostare riesami periodici e condizioni di rinnovo esplicite.
Controlli compensativi
I controlli compensativi devono essere concreti, eseguibili e verificabili. Non basta scrivere “monitoraggio rafforzato” se non è chiaro cosa viene monitorato, da chi, con quale frequenza e quale evidenza viene prodotta.
Esempi di controlli compensativi possono includere una revisione accessi più frequente, un alert specifico sui log, una limitazione temporanea dell’esposizione di rete, una segregazione aggiuntiva o una procedura manuale di riconciliazione. Ogni misura deve avere un owner e una prova di esecuzione.
Chiusura e verifica indipendente
La chiusura richiede una prova positiva: il controllo è tornato nello stato previsto o la deviazione è stata assorbita da una modifica approvata del controllo. La verifica dovrebbe essere svolta da una persona diversa da chi ha eseguito la remediation quando il rischio è significativo.
Il verbale o record di chiusura deve includere data, evidenza, risultato della verifica e riferimento all’eccezione originaria. Se durante la remediation emergono ulteriori carenze, non vanno nascoste nella stessa riga: devono diventare nuovi finding o nuove azioni correttive.
Errori comuni che indeboliscono l’audit
La compliance it si indebolisce quando le eccezioni vengono trattate come favore operativo invece che come processo di controllo. Il primo errore è approvare eccezioni retroattive senza spiegare perché non siano state aperte prima. Può capitare, ma deve restare un caso motivato, non una prassi.
Il secondo errore è rinnovare sempre la stessa eccezione. Se una deroga viene prorogata più volte, il problema non è più temporaneo. A quel punto serve una decisione: correggere la causa, cambiare il controllo, accettare formalmente un rischio diverso o aprire un piano strutturale di remediation.
Il terzo errore è conservare evidenze in canali dispersi. Un’approvazione in chat, uno screenshot in una cartella personale e un ticket incompleto non costruiscono una storia coerente. L’auditor deve poter seguire la catena decisionale senza ricostruzioni verbali.
Infine, molte organizzazioni dimenticano di collegare le eccezioni al programma di audit interno. Se stai preparando verifiche periodiche, integrare il registro eccezioni nel software per audit interno aiuta a trasformare le deroghe ricorrenti in segnali di miglioramento del sistema di controllo.
Metriche utili per il reporting
Per rendere la compliance it gestibile nel tempo, il registro delle eccezioni dovrebbe produrre metriche semplici. Non servono dashboard complesse se i dati di base sono incompleti. Meglio poche misure stabili, riesaminate con regolarità.
Metriche utili includono numero di eccezioni aperte per controllo, età media delle eccezioni, percentuale di eccezioni scadute, numero di proroghe, distribuzione per owner, severità del rischio residuo e tempi medi di chiusura. Queste misure mostrano se il processo riduce davvero il rischio o se lo sposta nel tempo.
Il reporting dovrebbe distinguere le eccezioni accettate entro soglia, quelle in scadenza, quelle scadute e quelle da convertire in remediation strutturale. Per i contesti NIS2, può essere utile collegare eccezioni e controlli ai presidi di sicurezza rilevanti, come descritto nell’approccio operativo a controlli ed evidenze per NIS2.
Checklist rapida per una eccezione audit-ready
Prima di presentare una eccezione in audit, verifica che il record risponda a queste domande:
- Il controllo interessato è identificato senza ambiguità?
- La motivazione operativa è comprensibile anche fuori dal team IT?
- Il rischio residuo è stato valutato e accettato da un owner adeguato?
- I controlli compensativi sono descritti con frequenza, owner ed evidenza?
- La scadenza è definita e non dipende da formule vaghe?
- La remediation ha un responsabile e una prova attesa?
- L’audit trail mostra chi ha modificato cosa e quando?
Se manca una risposta, l’eccezione può essere ragionevole dal punto di vista operativo, ma fragile dal punto di vista probatorio.
Domande frequenti
Una eccezione ai controlli è sempre una non conformità? No. Può essere una deviazione temporanea autorizzata, se è documentata, approvata, limitata nel tempo e accompagnata da controlli compensativi. Se manca governance, può diventare un finding.
Chi deve approvare una eccezione IT? Dipende dal rischio e dall’ambito. In genere servono almeno l’owner del controllo e il risk owner. Se l’eccezione impatta dati personali, servizi critici o fornitori rilevanti, vanno coinvolte anche le funzioni competenti.
Quanto deve durare una eccezione? Il meno possibile rispetto alla remediation realistica. La durata deve essere motivata, approvata e riesaminata. Le proroghe ripetute indicano spesso un problema strutturale del controllo o della capacità operativa.
Qual è l’evidenza più importante? Non esiste una sola evidenza sufficiente. Serve una catena: richiesta, valutazione del rischio, approvazione, controlli compensativi, monitoraggio, remediation e verifica di chiusura.
Il registro eccezioni sostituisce il risk register? No. Il registro eccezioni traccia deviazioni temporanee dai controlli. Il risk register descrive rischi, trattamenti e responsabilità in modo più ampio. I due strumenti dovrebbero essere collegati quando l’eccezione modifica il rischio residuo.
Se devi strutturare un evidence pack per controlli, eccezioni e remediation in ambito NIS2, puoi valutare una demo operativa per la gestione delle evidenze NIS2.
audit-ready evidence pack demo / not legal advice