Autovalutazione dei controlli per le evidenze ISO 27001

Il problema degli audit nel 2026 non è la mancanza di controlli, ma la debolezza delle evidenze

La videochiamata si attivò alle 09:10 di un lunedì. Sarah, CISO di una società fintech SaaS in forte crescita, vide sullo schermo tre volti tesi: il responsabile della GRC, il DPO e il responsabile delle operazioni IT.

L’azienda aveva in programma un audit di sorveglianza ISO/IEC 27001:2022. Il consiglio di amministrazione voleva un briefing sulla preparazione a NIS2 entro venerdì. Un cliente del settore finanziario aveva aggiunto domande sui fornitori ICT in stile DORA a un rinnovo contrattuale. Il DPO stava preparando le evidenze per la responsabilizzazione prevista dal GDPR.

Sulla carta, l’organizzazione appariva matura. Esistevano un registro dei rischi, una Dichiarazione di applicabilità, procedure di controllo degli accessi, playbook di risposta agli incidenti, politiche di backup, moduli di due diligence sui fornitori e registrazioni della formazione.

Poi iniziò il riesame delle evidenze.

Il foglio di calcolo del riesame degli accessi non indicava alcun revisore nominativo. Un report di scansione delle vulnerabilità era aggiornato, ma nessuno poteva dimostrare se le risultanze critiche fossero state corrette, accettate o fossero ancora aperte. La due diligence sui fornitori esisteva, ma precedeva una modifica rilevante dell’architettura cloud. Gli screenshot dei test di backup erano sepolti in una conversazione chat. Le note dell’esercitazione da tavolo sugli incidenti erano utili, ma non attribuibili. Gli ingegneri inoltravano screenshot di configurazione senza contesto. I responsabili dei controlli segnavano i controlli trimestrali come “completati”, ma le evidenze erano incoerenti e difficili da riutilizzare.

Sarah capì che il problema non era l’assenza di controlli. Era l’assenza di evidenze difendibili e ripetibili.

Questo è il divario dell’autovalutazione dei controlli nel 2026.

Le organizzazioni dispongono di controlli documentati, dashboard e talvolta strumenti di monitoraggio continuo. Tuttavia, spesso non riescono a dimostrare che i responsabili dei controlli li verificano in modo coerente, che le evidenze sono complete e aggiornate, e che le eccezioni confluiscono in azioni correttive, riesame da parte della direzione e reporting normativo.

L’autovalutazione dei controlli, o CSA, colma questo divario operativo. Se eseguita correttamente, la CSA crea un flusso di lavoro disciplinato in cui i responsabili dei controlli verificano periodicamente la progettazione del controllo e l’efficacia operativa, allegano evidenze conformi a criteri di qualità da audit, registrano le eccezioni, assegnano azioni correttive e forniscono alla direzione una visione affidabile dello stato di salute dei controlli.

In Clarysec, la CSA è trattata come il ponte tra il SGSI, gli obblighi legali e le evidenze di audit. Il Zenith Blueprint: roadmap dell’auditor in 30 passaggi colloca questa disciplina nella fase audit, riesame e miglioramento. Il passaggio 26, esecuzione dell’audit, indica che la raccolta delle evidenze deve includere interviste, riesame della documentazione, osservazione, campionamento e controlli a campione:

✓ Intervistare il personale pertinente: chiedere alle persone responsabili dei processi di spiegare come soddisfano i requisiti.
✓ Riesaminare la documentazione: verificare che documenti e registrazioni esistano e siano aggiornati.
✓ Osservare le pratiche: se possibile, effettuare un’osservazione diretta.
✓ Campionare ed effettuare controlli a campione: non è possibile verificare tutto, quindi utilizzare il campionamento.

Questo approccio non deve attendere l’audit interno formale. La CSA lo anticipa e lo mette nelle mani dei responsabili dei controlli, così l’organizzazione può dimostrare ogni mese o trimestre che i controlli non sono solo scritti, ma operativi.

Perché le autovalutazioni manuali falliscono con NIS2, DORA e GDPR

Il vecchio modello di autovalutazione dei controlli basato su fogli di calcolo ed e-mail è inefficace perché premia il completamento, non la qualità delle evidenze.

Un responsabile del controllo carica uno screenshot. Un altro scrive “confermato secondo la politica”. Un terzo allega un’esportazione di log senza spiegare sistema, periodo, revisore o conclusione. Il team GRC impiega giorni a ricostruire la storia per auditor, clienti e autorità di regolamentazione.

Questo genera quattro carenze ricorrenti:

• Evidenze incoerenti, quando ogni responsabile ha una diversa idea di prova valida.
• Attribuzione debole, quando i file non mostrano chi ha raccolto l’evidenza, quando e da quale fonte.
• Attestazioni formali senza test, quando team sovraccarichi dichiarano che un controllo funziona senza verificarlo.
• Assenza di riutilizzabilità, quando le evidenze raccolte per ISO/IEC 27001:2022 non supportano facilmente NIS2, DORA o GDPR senza reinterpretazioni manuali.

La regolamentazione moderna non consente più questo modello.

NIS2 Article 20 attribuisce la gestione dei rischi di cibersicurezza alla responsabilità dell’organo di gestione. La direzione deve approvare le misure, supervisionarne l’attuazione e seguire la formazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, incluse analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, controllo degli accessi, gestione degli asset e autenticazione.

L’espressione “valutazione dell’efficacia” è il punto in cui la CSA diventa essenziale. Un soggetto NIS2 non può affermare in modo credibile alla direzione che le misure di cibersicurezza sono efficaci se i responsabili dei controlli non le testano e non documentano i risultati.

DORA ha innalzato l’asticella per gli enti finanziari dal 17 gennaio 2025. Introduce un regime di resilienza operativa digitale che copre gestione del rischio ICT, segnalazione degli incidenti, test di resilienza, condivisione delle informazioni e rischio ICT di terze parti. DORA Article 5 richiede la responsabilità dell’organo di gestione per assetti di rischio ICT, politiche, ruoli, strategia, piani di continuità operativa, piani di audit, politiche sulle terze parti e misure correttive. Article 6 richiede un quadro documentato di gestione del rischio ICT, riesame periodico, audit interno per le imprese diverse dalle microimprese e azioni di rimedio per le risultanze critiche degli audit ICT. Articles 24 to 26 rendono i test di resilienza un programma ricorrente di convalida, con indipendenza adeguata e, per alcuni soggetti, test di penetrazione basati sulle minacce.

La CSA non sostituisce i test DORA. È il livello dei responsabili dei controlli che rende sostenibili i test DORA.

GDPR aggiunge una pressione correlata in termini di responsabilizzazione. Article 5(2) richiede ai titolari del trattamento di dimostrare la conformità ai principi di protezione dei dati. Article 32 richiede un’adeguata sicurezza del trattamento, incluse riservatezza, integrità, disponibilità, resilienza, ripristino e test o valutazioni periodiche ove opportuno. Per un DPO, le evidenze CSA sono un modo pratico per dimostrare che riesami degli accessi, cifratura, logging, conservazione, vigilanza sui fornitori e gestione degli incidenti operano effettivamente in relazione ai dati personali.

Il modello CSA di Clarysec, dalla politica alla prova

Un programma CSA difendibile parte da tre domande:

1. Il controllo è progettato correttamente rispetto al rischio e all’obbligo?
2. Il controllo ha operato durante il periodo di valutazione?
3. Le evidenze sono complete, aggiornate, attribuibili e riutilizzabili?

Clarysec fonda questo modello su politiche, flussi di audit e mappatura dei controlli.

La Politica per la sicurezza delle informazioni stabilisce l’aspettativa nella clausola 6.6.1:

Tutti i controlli attuati devono essere verificabili, supportati da procedure documentate e da evidenze conservate del loro funzionamento.

La clausola 6.6.2 aggiunge:

I responsabili dei controlli devono mantenere risultati dei test, log e registrazioni dei riesami a supporto degli audit periodici.

Questo trasforma i controlli da dichiarazioni statiche in processi attivi e misurabili.

La Politica di audit e monitoraggio della conformità - PMI stabilisce la disciplina di riesame:

Questa politica definisce l’approccio dell’organizzazione allo svolgimento di audit interni, riesami dei controlli di sicurezza e monitoraggio della conformità. Garantisce che tutti i controlli, le politiche, i sistemi e i fornitori di servizi siano soggetti a riesame periodico e strutturato.

La clausola 5.2.3 richiede struttura:

Ogni audit deve includere un ambito di applicazione definito, obiettivi, personale responsabile ed evidenze richieste.

Per la CSA, la stessa logica si applica a livello di responsabile del controllo. Ogni autovalutazione deve avere ambito di applicazione, obiettivo, responsabile, periodo, evidenze e conclusione.

Zenith Controls: la guida alla conformità trasversale fornisce quindi la prospettiva di mappatura. Per la CSA, i riferimenti più importanti ai controlli dell’Allegato A di ISO/IEC 27001:2022 includono 5.2, ruoli e responsabilità per la sicurezza delle informazioni, 5.35, riesame indipendente della sicurezza delle informazioni, e 5.36, conformità a politiche, regole e standard per la sicurezza delle informazioni.

Insieme, questi controlli raccontano la storia della CSA. Qualcuno deve essere responsabile del controllo. L’organizzazione deve verificare se politiche e standard sono rispettati. Il riesame indipendente deve mettere alla prova il sistema. La CSA si colloca tra responsabilità del controllo e riesame indipendente. Non è audit interno, ma prepara le evidenze che rendono l’audit interno più rapido e affidabile.

Test di progettazione rispetto a test di efficacia operativa

Un errore comune nella CSA è chiedere ai responsabili dei controlli: “Questo controllo funziona?”, senza definire cosa significhi “funzionare”.

Ogni valutazione credibile deve distinguere il test di progettazione dal test di efficacia operativa.

Un test di progettazione verifica se il controllo, se eseguito come descritto, affronterebbe il rischio o il requisito. Per un riesame degli accessi, il test di progettazione verifica se la procedura definisce ambito di applicazione, ruolo del revisore, frequenza, sistemi coperti, gestione delle eccezioni, conservazione delle evidenze ed escalation.

Un test di efficacia operativa verifica se il controllo ha effettivamente operato durante il periodo. Per lo stesso riesame degli accessi, il test operativo verifica se il riesame si è svolto, chi lo ha eseguito, se tutti i sistemi nell’ambito di applicazione sono stati inclusi, se le eccezioni sono state risolte e se le registrazioni dimostrano il completamento.

Entrambi i test sono importanti. Una politica di backup ben scritta è debole se non sono stati eseguiti test di ripristino. Una scansione di vulnerabilità eseguita settimanalmente è incompleta se le risultanze critiche non confluiscono in azioni di rimedio o in un’accettazione formale del rischio. Un riesame del fornitore effettuato una sola volta non è più affidabile se il fornitore ora supporta un processo critico e ha modificato i subappaltatori.

Questa distinzione supporta direttamente le clausole ISO/IEC 27001:2022 8.1 per pianificazione e controllo operativi, 9.1 per monitoraggio, misurazione, analisi e valutazione, 9.2 per audit interno, 9.3 per riesame da parte della direzione e 10.2 per non conformità e azione correttiva.

Criteri di qualità delle evidenze per gli audit 2026

Le evidenze non sono pronte per l’audit solo perché esistono. Devono essere utilizzabili.

Per la CSA, le evidenze devono essere valutate rispetto a sette criteri.

La politica PMI rafforza la disciplina sui metadati:

I metadati (ad es. chi li ha raccolti, quando e da quale sistema) devono essere documentati.

Per indagini ed evidenze digitali a maggiore integrità, la Politica per la raccolta delle evidenze e l’analisi forense - PMI è più precisa:

Ogni elemento di evidenza digitale deve essere registrato con:
5.2.1.1. Nome del soggetto che l’ha raccolta
5.2.1.2. Sistema/dispositivo sorgente
5.2.1.3. Marcatura temporale della raccolta
5.2.1.4. Ubicazione di archiviazione
5.2.1.5. Cronologia degli accessi (chi l’ha visualizzata o copiata)

Una registrazione CSA di routine non richiede sempre la gestione della catena di custodia forense. Tuttavia, ogni elemento di evidenza deve essere abbastanza tracciabile da consentire a un auditor di comprendere chi l’ha prodotta, quando, da dove e perché dimostra il controllo.

La Politica di conformità legale e normativa aggiunge il requisito di conformità trasversale richiedendo:

Artefatti o registrazioni richiesti per dimostrare la conformità (ad es. log di audit, impostazioni di cifratura, documentazione del consenso)

Questa è la chiave delle evidenze riutilizzabili. Una singola esportazione della configurazione di cifratura può supportare il trattamento del rischio ISO/IEC 27001:2022, le misure di sicurezza di NIS2 Article 21, la protezione degli asset ICT DORA e la sicurezza del trattamento di GDPR Article 32, se la registrazione è completa, attribuibile e mappata.

Un flusso CSA pratico con il toolkit Clarysec

Un responsabile del controllo deve poter svolgere una sessione CSA significativa in modo strutturato e ripetibile. Il flusso seguente può essere applicato ad accesso privilegiato, ripristino dei backup, monitoraggio dei fornitori, preparazione alla risposta agli incidenti, gestione delle vulnerabilità o riesame indipendente.

Passaggio 1, selezionare il controllo e la mappatura degli obblighi

Iniziare dalla Dichiarazione di applicabilità, dal piano di trattamento del rischio e dal registro degli obblighi legali. Scegliere un controllo, ad esempio il riesame degli accessi privilegiati per i sistemi di produzione.

Mapparlo ai controlli pertinenti dell’Allegato A di ISO/IEC 27001:2022, come 5.15 controllo degli accessi, 5.16 gestione delle identità e 5.18 diritti di accesso. In Zenith Controls, collegarlo a 5.2 per ruoli e responsabilità e a 5.36 per conformità a politiche, regole e standard, perché il riesame dimostra che la politica di accesso è rispettata.

Se l’organizzazione rientra in NIS2, mappare le evidenze alle misure di Article 21 per controllo degli accessi, gestione degli asset, sicurezza delle risorse umane e autenticazione. Se è un ente finanziario soggetto a DORA, mapparle alla governance del rischio ICT, alla protezione, al monitoraggio e ai requisiti di terze parti pertinenti. Se sono coinvolti dati personali, mapparle a GDPR Article 5, per integrità e riservatezza, e a Article 32, per la sicurezza del trattamento.

Passaggio 2, definire il test di progettazione

Porre domande pratiche sulla progettazione:

• La procedura identifica tutti i sistemi nell’ambito di applicazione?
• Copre account privilegiati, account di servizio e accessi di emergenza?
• Il revisore è indipendente dal provisioning quotidiano, ove praticabile?
• Frequenza, escalation e regole di eccezione sono definite?
• La conservazione delle evidenze è definita?
• Gli obblighi GDPR, DORA, NIS2 o specifici del cliente sono inclusi ove pertinenti?

Se la risposta è no, registrare un’eccezione di progettazione.

Passaggio 3, eseguire il test di efficacia operativa

Selezionare un campione e verificare il funzionamento effettivo. Per un riesame trimestrale degli accessi privilegiati, campionare l’ultimo riesame completato e gli utenti ad alto rischio nei sistemi critici. Se l’ambiente è piccolo, testare tutti gli account privilegiati. Se è esteso, utilizzare un campionamento basato sul rischio con copertura maggiore per amministratori, sistemi di produzione, sistemi con dati personali e piattaforme esposte all’esterno.

La Politica di audit e monitoraggio della conformità enterprise supporta:

Raccolta delle evidenze tramite interviste, sopralluoghi e campionamento

Richiede inoltre:

Documentazione della strategia di campionamento, dell’ambito dell’audit e delle limitazioni

Non limitarsi ad allegare evidenze. Registrare perché il campione è stato scelto, quale popolazione rappresenta e cosa è stato escluso.

Una dichiarazione di campionamento solida potrebbe essere:

“Popolazione: 42 account di produzione privilegiati tra console cloud, piattaforma CI/CD e amministrazione dei database. Campione: tutti i 7 account di emergenza, tutti i 5 account di amministratore dei database di produzione e 10 account privilegiati di ingegneria selezionati casualmente. Periodo: Q1 2026. Esclusioni: account firewall gestiti da terze parti valutati nell’ambito del riesame degli accessi dei fornitori CSA-TPR-04.”

Questa frase fornisce all’auditor popolazione, logica di rischio, periodo e limitazione.

Passaggio 4, valutare la qualità delle evidenze

Per ogni elemento di evidenza, acquisire:

• ID evidenza
• ID controllo e responsabile del controllo
• Periodo di valutazione
• Sistema sorgente
• Data di raccolta
• Soggetto che ha raccolto l’evidenza
• Revisore o approvatore
• Obbligo collegato
• Ubicazione di archiviazione
• Periodo di conservazione
• Eccezioni rilevate
• Ticket di rimedio o riferimento CAPA

Questo trasforma la CSA da questionario soggettivo a test del controllo basato sulle evidenze.

Passaggio 5, registrare eccezioni e azioni correttive

Se due account privilegiati non hanno una giustificazione aziendale documentata, non nascondere il problema nelle note. Creare una risultanza, assegnare una classificazione di rischio, definire un’azione, indicare un responsabile e concordare una data obiettivo.

La politica PMI richiede:

Tutte le risultanze dell’audit devono essere documentate con classificazioni di rischio e azioni proposte.

Applicare quindi il passaggio 27 di Zenith Blueprint, risultanze dell’audit. Il Blueprint raccomanda le categorie non conformità maggiore, non conformità minore o osservazione, seguite dall’analisi della causa radice. Se gli account di servizio sono stati omessi perché l’inventario delle identità li esclude, la causa radice non è “errore del revisore”. È inventario degli accessi incompleto o ambito della procedura non chiaro.

Passaggio 6, chiudere tramite CAPA e verificarne l’efficacia

Il passaggio 29 di Zenith Blueprint raccomanda l’uso di un registro CAPA con descrizione del problema, causa radice, azione correttiva, responsabile dell’azione, data obiettivo e stato. Sottolinea inoltre la necessità di verificare l’efficacia dopo il completamento.

Se l’azione correttiva è “aggiornare la procedura di riesame degli accessi per includere gli account di servizio”, il metodo di verifica deve essere pratico: riesaminare il ciclo di accesso successivo e confermare che gli account di servizio siano inclusi, che le eccezioni siano risolte e che le evidenze siano conservate.

È così che la CSA diventa miglioramento continuo, non teatro della conformità.

Mappatura di conformità trasversale senza quattro programmi di controllo separati

Il principale guadagno di efficienza è “testare una volta, mappare molte volte”.

Costruire processi di test separati per ISO/IEC 27001:2022, NIS2, DORA e GDPR crea evidenze duplicate, risposte incoerenti e responsabili dei controlli esausti. Un approccio migliore consiste nell’utilizzare ISO/IEC 27001:2022 come sistema di gestione, la CSA come flusso di test e Zenith Controls come guida alla conformità trasversale.

Il NIST Cybersecurity Framework 2.0 è utile come livello di integrazione. La sua funzione GOVERN tratta requisiti legali, normativi e contrattuali, propensione al rischio, responsabilità della leadership, governance delle politiche e supervisione. I suoi profili organizzativi aiutano le organizzazioni a definire gli esiti di cibersicurezza attuali e target, analizzare le lacune e trasformarle in piani d’azione prioritizzati.

COBIT 2019 e l’approccio di assurance in stile ISACA aggiungono un’altra prospettiva utile. Si concentrano su obiettivi di governance, capacità dei processi, responsabilizzazione, metriche e supervisione della direzione. Un auditor orientato a COBIT chiederà se il processo è definito, misurato e migliorato, non solo se esiste un artefatto.

Come auditor diversi esamineranno le tue evidenze CSA

La stessa registrazione CSA sarà interpretata in modo diverso a seconda del background dell’auditor. Progettare le evidenze per queste prospettive rende il programma più resiliente.

Per il riesame indipendente, un auditor ISO/IEC 27001:2022 cercherà il programma di audit interno ai sensi della clausola 9.2, gli input del riesame da parte della direzione ai sensi della clausola 9.3 e l’azione correttiva ai sensi della clausola 10.2. Un auditor DORA cercherà test basati sul rischio, indipendenza, azioni di rimedio e supervisione della direzione. Un’autorità NIS2 si concentrerà sulla capacità della direzione di dimostrare l’efficacia delle misure di cibersicurezza. Un auditor GDPR chiederà se le evidenze mostrano misure tecniche e organizzative adeguate intorno alle attività di trattamento reali.

L’obiettivo non è riscrivere le evidenze per ciascun destinatario. L’obiettivo è raccoglierle una volta con contesto sufficiente a soddisfare più prospettive.

Reporting alla direzione che genera azione, non rumore

I risultati CSA non devono restare nei fogli di calcolo dei responsabili dei controlli. Devono confluire nel riesame da parte della direzione.

Nel passaggio 28, riesame da parte della direzione, Zenith Blueprint raccomanda input su cambiamenti nelle questioni interne ed esterne, cambiamenti nei requisiti delle parti interessate, prestazioni del SGSI, risultati degli audit, monitoraggio e misurazione, incidenti, non conformità, opportunità di miglioramento e necessità di risorse.

È esattamente qui che la CSA deve collocarsi.

Una dashboard CSA utile per i dirigenti deve includere:

• Copertura dei controlli per dominio e processo critico.
• Percentuale di controlli testati nei tempi previsti.
• Punteggio di qualità delle evidenze per responsabile del controllo.
• Eccezioni aperte per classificazione di rischio.
• Azioni correttive scadute.
• Risultanze ripetute e cause radice.
• Mappature ad alto rischio per NIS2, DORA, GDPR e obblighi dei clienti.
• Eccezioni dei controlli relative ai fornitori.
• Risultanze su incidenti, backup e test di resilienza.
• Decisioni sulle risorse richieste alla direzione.

La direzione non ha bisogno di ogni screenshot. Deve sapere se l’ambiente di controllo è affidabile, dove il rischio aumenta, se gli obblighi sono coperti e dove sono richieste decisioni.

Questo supporta la responsabilità della direzione prevista da NIS2 Article 20 e la supervisione dell’organo di gestione prevista da DORA Article 5. Per GDPR, aiuta il titolare del trattamento a dimostrare che la responsabilizzazione non è un documento una tantum, ma un processo di governance vivo.

Errori comuni nella CSA e come evitarli

Il primo errore è la CSA basata solo su questionari. Una risposta sì/no senza evidenze produce rassicurazione, non assurance. Ogni asserzione rilevante deve essere supportata da evidenze.

Il secondo errore è l’evidenza senza contesto del controllo. Un’esportazione di log è priva di significato se non è collegata a obiettivo del controllo, periodo, fonte, responsabile e conclusione.

Il terzo errore è la debole disciplina delle eccezioni. Se le risultanze non hanno classificazioni di rischio, responsabili, date obiettivo e metodi di verifica, la CSA diventa un esercizio di archiviazione. Il passaggio 29 di Zenith Blueprint lo evita collegando le non conformità a causa radice, azione correttiva, responsabile, data obiettivo e verifica dell’efficacia.

Il quarto errore è ignorare i servizi forniti esternamente. ISO/IEC 27001:2022 richiede il controllo su processi, prodotti o servizi forniti esternamente e rilevanti per il SGSI. NIS2 include la sicurezza della catena di fornitura. DORA richiede gestione del rischio ICT di terze parti, registri, due diligence, garanzie contrattuali, valutazione del rischio di concentrazione, diritto di audit e piani di uscita. Gli esiti NIST CSF 2.0 GV.SC coprono analogamente ruoli dei fornitori, due diligence, contratti, monitoraggio, pianificazione degli incidenti e risoluzione. La CSA deve includere evidenze dei fornitori, non solo evidenze IT interne.

Il quinto errore è trattare GDPR come un allegato legale. Se dati personali sono trattati in un sistema, la CSA deve verificare se i controlli di sicurezza supportano integrità, riservatezza, disponibilità, conservazione, limitazione dell’accesso e preparazione alle violazioni.

Checklist 2026 per il responsabile del controllo

Prima di inviare un risultato CSA, ogni responsabile del controllo deve poter confermare quanto segue:

• Conosco l’obiettivo del controllo e i rischi collegati.
• Conosco quali obblighi ISO/IEC 27001:2022, NIS2, DORA, GDPR o contrattuali il controllo supporta.
• Ho testato separatamente progettazione ed efficacia operativa.
• Ho documentato la popolazione e il metodo di campionamento.
• Ho allegato evidenze complete, aggiornate, attribuibili, autentiche, pertinenti, conservate e riutilizzabili.
• Ho registrato i metadati relativi a chi ha raccolto le evidenze, quando e da quale sistema.
• Ho documentato le eccezioni con classificazione di rischio e azioni proposte.
• Ho identificato la causa radice delle eccezioni rilevanti.
• Ho creato o aggiornato le registrazioni CAPA con responsabile, data di scadenza e metodo di verifica.
• Ho sottoposto a escalation le problematiche rilevanti per il riesame da parte della direzione.

Se un responsabile del controllo non riesce a completare questa checklist, il problema non è solo una debolezza della CSA. Potrebbe essere una debolezza del monitoraggio del SGSI, una lacuna nella valutazione dell’efficacia NIS2, una criticità di governance del rischio ICT DORA o una debolezza di responsabilizzazione GDPR.

Integrare la CSA nel modello operativo di assurance

L’autovalutazione dei controlli non sostituisce audit interno, test di penetrazione, test di resilienza DORA o riesame legale GDPR. È il livello operativo che li rende tutti più affidabili.

Nel 2026, le organizzazioni che supereranno gli audit con meno interruzioni non saranno quelle con più politiche. Saranno quelle i cui responsabili dei controlli sapranno dimostrare, con evidenze di qualità, che i controlli sono progettati, operativi, monitorati, corretti e riportati.

Clarysec aiuta le organizzazioni a costruire questa capacità utilizzando Zenith Blueprint, modelli di politiche come la Politica per la sicurezza delle informazioni, la Politica di audit e monitoraggio della conformità, la Politica di audit e monitoraggio della conformità - PMI, la Politica per la raccolta delle evidenze e l’analisi forense - PMI, la Politica di conformità legale e normativa, e la capacità di mappatura della conformità trasversale di Zenith Controls.

Se i tuoi controlli ISO/IEC 27001:2022 sono documentati ma le evidenze sono sparse, incoerenti o non riutilizzabili per NIS2, DORA e GDPR, parti questa settimana da un dominio ad alto rischio. Esegui una CSA su accesso privilegiato, sicurezza dei fornitori, preparazione alla risposta agli incidenti, correzione delle vulnerabilità o ripristino dei backup. Testa la progettazione, testa l’efficacia operativa, valuta la qualità delle evidenze, registra le eccezioni e porta il risultato nel riesame da parte della direzione.

Vuoi trasformare l’autovalutazione dei controlli in assurance pronta per l’audit? Scarica Zenith Blueprint, esplora Zenith Controls oppure richiedi a Clarysec una valutazione della preparazione delle evidenze per capire dove le tue evidenze dei controlli reggeranno e dove devono migliorare.