Padroneggiare la governance dell'Information Technology nel 2026

Perché così tanti programmi di governance dell'Information Technology sembrano ordinati nelle cartelle delle policy eppure falliscono durante gli audit, nel corso degli incidenti o quando un regolatore pone una semplice domanda sulla titolarità?

La risposta abituale è “mancanza di maturità”. In pratica, però, il problema è spesso più semplice. I team confondono la documentazione con il controllo. Redigono policy, assegnano responsabilità generiche e svolgono revisioni annuali, ma non riescono a mostrare come una decisione sia diventata una salvaguardia applicata, chi l'abbia verificata e quale evidenza dimostri che funzioni ancora.

Quel divario conta più oggi di quanto contasse qualche anno fa. Tra il 62% e il 65% dei leader dei dati ora dà priorità alla governance dei dati rispetto alle iniziative di AI e analytics, spinto dalla pressione normativa e dal costo dei fallimenti, incluse sanzioni che arrivano a €1.2 billion in singoli casi e costi medi annui di compliance pari a $2.7 million per le grandi imprese europee, secondo queste statistiche sulla governance dei dati. In altre parole, la governance è passata da disciplina di sfondo a requisito operativo.

Per un nuovo CISO in un'azienda regolamentata, questo cambia la conversazione. La governance dell'Information Technology non consiste nel produrre più carta. Consiste nel fare in modo che decisioni, controlli, responsabilità ed evidenze restino coerenti sotto pressione.

A Cosa Serve Davvero la Governance dell'Information Technology

La governance dell'Information Technology esiste per rispondere a tre domande operative. Chi decide. Chi è responsabile. Come dimostri che la decisione è stata tradotta nel comportamento del sistema.

Molti team trattano ancora la governance come un livello di approvazione posto sopra l'delivery. Questo modello crolla rapidamente negli ambienti regolamentati. DORA, NIS2 e GDPR non si preoccupano del fatto che un comitato si sia riunito nei tempi previsti. Si preoccupano del fatto che l'organizzazione possa dimostrare il controllo su rischio, cambiamento, accesso, terze parti e risposta.

La governance è architettura delle decisioni

Un modo utile di pensare alla governance è come architettura delle decisioni per il rischio e il valore tecnologico. Definisce i confini entro cui agiscono i team di engineering, operations, security, procurement e legal. Se quei confini sono vaghi, le persone improvvisano. L'improvvisazione è il punto in cui si accumulano eccezioni “temporanee”, strumenti non gestiti e dipendenze non documentate.

Ecco perché la governance deve essere più vicina alle operations di quanto molte organizzazioni si aspettino. Deve influenzare change management, revisioni degli accessi, onboarding dei vendor, gestione dei dati, segnalazione degli incidenti e retention. Se compare solo nelle presentazioni al board e nei raccoglitori di policy, non sta governando nulla.

Per i team che vogliono una sintesi concisa del lato organizzativo, understanding data governance in organizations è una lettura complementare utile perché inquadra la governance come struttura di responsabilità e non come semplice insieme di documenti.

La governance fallisce quando nessuno riesce a tracciare una regola di business fino a un controllo, o un controllo fino a un proprietario nominato.

Il passaggio dal teatro della compliance alla prova operativa

Un modello di governance maturo non chiede: “Abbiamo una policy?” Chiede: “Cosa accade nel sistema perché quella policy esiste?”

Quel passaggio cambia anche il modo in cui dovrebbero lavorare gli organi di leadership. Un comitato di steering non è utile perché si riunisce. È utile se risolve conflitti di titolarità, approva priorità, registra compromessi e lascia una traccia verificabile delle decisioni responsabili. Se fatto bene, un governance steering committee diventa un punto di controllo, non un forum cerimoniale.

Un sistema di governance pratico produce in genere quattro risultati visibili:

• Direzione chiara: I team sanno quali standard si applicano, dove vanno le eccezioni e cosa significhi davvero il risk appetite nel lavoro quotidiano.
• Responsabilità assegnata: Proprietari nominati portano le decisioni fino all'implementazione e alla revisione.
• Applicazione dei controlli: Le salvaguardie sono incorporate in strumenti, workflow e modelli di accesso.
• Evidenza verificabile: L'organizzazione può mostrare cosa è stato deciso, cosa è cambiato e chi ha approvato.

Questo è il vero scopo della governance dell'Information Technology. Ridurre l'ambiguità prima che l'ambiguità diventi rischio.

I Componenti Fondamentali di un Sistema di Governance

Un sistema di governance funziona solo quando quattro parti si collegano in modo pulito: policy, controlli, ruoli e metriche. La maggior parte dei fallimenti avviene nei punti di connessione tra queste parti.

Le policy definiscono l'intento

Le policy stabiliscono ciò che l'organizzazione si aspetta. Definiscono regole per accessi, gestione dei dati, approvazione delle modifiche, escalation degli incidenti, revisione dei fornitori, uso dei modelli, retention e aree analoghe. Ma il testo della policy da solo non cambia il comportamento del sistema.

Le organizzazioni deboli si fermano alla pubblicazione della policy. Quelle forti collegano le dichiarazioni di policy a controlli applicabili, punti di revisione ed evidenze registrate. Un'informativa sulla privacy è un buon esempio di intento reso visibile. Se vuoi vedere come impegni espliciti possano essere scritti in modo chiaro sia per gli utenti sia per gli operatori, la WhatPulse privacy statement è un riferimento utile per struttura e specificità.

I controlli applicano l'intento

I controlli sono i meccanismi che trasformano la governance in azione. Possono essere tecnici, procedurali o una combinazione di entrambi. Controllo degli accessi basato sui ruoli, workflow di approvazione, cifratura, segregazione dei compiti, logging, test dei backup, due diligence sui vendor e gestione delle eccezioni rientrano tutti qui.

Molti sforzi di governance dell'AI sono attualmente deboli. Solo il 25% delle organizzazioni ha implementato completamente programmi di governance dell'AI, e il 13% delle violazioni dei dati nel 2025 ha coinvolto modelli o applicazioni di AI. Di questi incidenti, il 97% mancava di adeguati controlli di accesso all'AI, come riportato in queste statistiche sulla governance dell'AI. La lezione non riguarda solo l'AI. Quando i controlli non corrispondono all'intento della policy, la governance diventa simbolica.

Un modo sensato di valutare i controlli è chiedersi:

• Il controllo può essere applicato in modo coerente
• Qualcuno può aggirarlo senza revisione
• Genera evidenza
• Esiste un proprietario nominato per operatività e revisione

I ruoli creano responsabilità

I ruoli determinano se la governance sopravvive al contatto con il lavoro quotidiano. Se una policy afferma che i dati dei clienti devono essere classificati, qualcuno deve possedere la regola di classificazione, qualcuno deve applicarla e qualcuno deve verificare che il processo funzioni ancora dopo una modifica del sistema.

Ciò significa separare i tipi di responsabilità. Gli organi di governance definiscono la direzione. Il management assegna il lavoro. I proprietari dei controlli mantengono le salvaguardie. I proprietari delle evidenze mantengono le prove. I revisori contestano se il design sia ancora adatto al rischio.

Un modello di governance come COSO for IT environments può aiutare i team a pensare con chiarezza ai livelli di responsabilità, ma la vera verifica è la chiarezza operativa, non il vocabolario del framework.

Regola pratica: Se due team credono entrambi di “supportare” un controllo, c'è una buona probabilità che nessuno dei due lo possieda davvero.

Le metriche mostrano se il sistema funziona

Le metriche sono spesso la parte più debole perché i team raccolgono ciò che è facile, non ciò che è utile. Le metriche di governance dovrebbero mostrare se un controllo è presente, operativo, revisionato e in grado di produrre il risultato atteso.

Buoni esempi includono completezza delle evidenze, stato di revisione dei controlli, anzianità delle eccezioni, chiusura delle recertificazioni degli accessi, stato di assurance dei fornitori e tempo necessario per produrre gli artefatti di audit. Cattivi esempi sono dashboard di facciata che sembrano dettagliate ma non aiutano nessuno a verificare le prestazioni dei controlli.

Un sistema di governance è completo solo quando questi quattro componenti formano un ciclo. La policy dà la direzione. Il controllo la applica. Il ruolo assegna la responsabilità. La metrica conferma se l'assetto regge ancora.

Come Scegliere il Framework di Governance Giusto

La scelta del framework riguarda meno il trovare il modello “migliore” e più il scegliere la lente giusta per il proprio problema operativo. Alcune aziende hanno bisogno di un oversight aziendale più forte. Altre di una disciplina di service management più rigorosa. Alcune hanno bisogno di entrambe, ma in proporzioni diverse.

Cosa cerca di risolvere ciascun framework

COBIT è più forte quando serve un linguaggio di governance che colleghi responsabilità executive, obiettivi di controllo e auditabilità. Dà struttura all'oversight e aiuta le organizzazioni a tradurre aspettative ampie in processi gestiti.

ITIL affronta lo stesso ambiente da un'angolazione diversa. Il suo centro di gravità è il service management. Aiuta i team a stabilizzare le operations, definire le responsabilità di servizio, gestire incidenti e cambiamenti e migliorare la qualità dell'erogazione. Laddove COBIT chiede se l'organizzazione stia governando correttamente informazioni e tecnologia, ITIL chiede se i servizi vengano gestiti in modo affidabile.

ISO/IEC 38500 è utile quando la leadership ha bisogno di un modello di governance ad alto livello piuttosto che di un playbook operativo. Aiuta board ed executive a inquadrare responsabilità, strategia, acquisizione, performance, conformità e comportamento umano senza prescrivere i dettagli di processo.

Confronto della filosofia dei framework

Perché COBIT si adatta spesso agli ambienti regolamentati

COBIT è particolarmente utile quando i controlli devono essere difesi in audit. COBIT 5 integra standard come ITIL e ISO su 37 processi in cinque domini, e le evidenze derivanti dagli audit COBIT mostrano che i reparti possono ottenere cicli di compliance più rapidi del 40% dopo l'implementazione, secondo il Florida Department of Education IT governance framework.

Ciò non significa che ogni team debba implementare COBIT in modo integrale. In pratica, i grandi rollout di framework falliscono quando le organizzazioni copiano la terminologia senza decidere come verranno prese le decisioni. Una piccola azienda regolamentata può usare COBIT per la struttura di governance, prendere in prestito ITIL per change e incident management, e mantenere ISO/IEC 38500 per il linguaggio del reporting al board.

Non scegliere un framework perché è completo. Sceglilo perché aiuta la tua organizzazione a prendere decisioni difendibili.

Un test pratico per la selezione

Quando consiglio un nuovo CISO, valuterei la scelta di un framework con quattro domande:

1. Chiarisce la responsabilità a livello executive, management e control-owner
2. Aiuta a mappare la policy in controlli applicabili
3. Auditor e regolatori ne riconosceranno la logica
4. I tuoi team possono utilizzarlo senza creare governance fatigue

Se la risposta all'ultima domanda è no, il framework è troppo pesante per il tuo attuale modello operativo. La governance deve essere utilizzabile. Se i team non riescono a lavorarci, la aggireranno.

Governance Pratica per DORA e NIS2

DORA e NIS2 spingono le organizzazioni verso lo stesso standard pratico. Devono sapere cosa conta, chi ne è responsabile, come il rischio è controllato e come possono dimostrarlo a una terza parte senza andare nel panico.

Partire dalla titolarità prima degli strumenti

Molti programmi di governance iniziano scegliendo una piattaforma e poi cercando di farvi rientrare le responsabilità. Questa sequenza di solito produce confusione. Inizia prima dalla responsabilità.

Ruoli poco chiari di data ownership e stewardship contribuiscono al 60% delle violazioni di compliance, e formalizzare tali responsabilità in una RACI o in una matrice di ownership è un passaggio critico di implementazione, secondo Secure Data Technologies on IT data governance. Quel dato coincide con ciò che la maggior parte dei team di audit già osserva. I controlli falliscono quando la titolarità è presunta anziché assegnata.

Per DORA e NIS2, la titolarità dovrebbe coprire almeno queste aree:

• Ownership della policy: Chi mantiene la regola e approva le modifiche.
• Ownership del controllo: Chi opera e revisiona la salvaguardia.
• Ownership dell'asset o del servizio: Chi accetta l'impatto di business se il controllo si degrada.
• Ownership dell'evidenza: Chi mantiene le prove aggiornate e recuperabili.
• Ownership di terze parti: Chi fa follow-up quando l'evidenza di un fornitore manca o è debole.

Collegare policy a controllo a evidenza

Questo è il cuore operativo. Se una policy dice che gli accessi privilegiati devono essere limitati, dovresti poter identificare il meccanismo esatto di controllo degli accessi, il proprietario della revisione, il percorso di approvazione delle eccezioni e l'evidenza che dimostra che il controllo ha operato.

Sembra ovvio, ma molte aziende gestiscono ancora questi elementi in silos separati. La policy si trova in un repository, i controlli in spreadsheet, i record degli accessi in un altro sistema, e l'evidenza di audit viene assemblata manualmente poco prima della revisione. Questo assetto è lento e fragile.

Per le aziende regolamentate che stanno costruendo requisiti di resilienza, il lavoro di conformità a DORA di solito diventa più semplice una volta che la catena policy-controllo-evidenza è esplicita. A quel punto, i controlli smettono di essere obblighi astratti e diventano oggetti che possono essere revisionati, testati e documentati.

Ecco una guida utile sul contesto normativo più ampio:

Trattare la governance di terze parti come parte del sistema di controllo

DORA e NIS2 pongono entrambi maggiore attenzione sulle dipendenze. Fornitori, processor, managed service provider, piattaforme cloud e funzioni di security in outsourcing influenzano tutti la tua postura di controllo.

Un modello pratico di governance di terze parti ha bisogno di tre cose:

• Requisiti di evidenza definiti: Non chiedere ai vendor “documenti di sicurezza”. Chiedi artefatti nominati collegati a controlli specifici.
• Criteri di revisione: Decidi in anticipo cosa conta come assurance accettabile, cosa attiva un'escalation e chi approva.
• Logica di refresh: L'assurance esterna invecchia. La governance dovrebbe specificare quando l'evidenza deve essere rinnovata, contestata o integrata.

Se un fornitore critico fallisce un controllo, il regolatore non accetterà come risposta “quello è in capo al procurement”.

Le organizzazioni che gestiscono bene DORA e NIS2 non costruiscono sistemi di governance separati per ogni regolamento. Costruiscono un unico modello operativo tracciabile e poi vi mappano più obblighi.

Costruire un Programma di Governance Pronto per l'Audit

Un programma di governance pronto per l'audit non è una fase progettuale prima di una revisione esterna. È uno stato operativo continuo. O i tuoi controlli producono evidenze mentre il lavoro avviene, oppure il tuo team ricostruisce il passato sotto pressione.

Come appare davvero la readiness all'audit

La maggior parte delle organizzazioni dice di essere “pronta per l'audit” perché ha policy, screenshot, ticket e alcune cartelle condivise. Non basta. La readiness all'audit significa che l'organizzazione può mostrare design, owner, operatività, storico delle revisioni, eccezioni ed evidenze di supporto di un controllo senza iniziare una caccia ai documenti.

Questo richiede un piccolo insieme di capacità che lavorano insieme:

• Evidenze versionate: Devi sapere quali evidenze si applicavano in un dato momento e cosa è cambiato dopo.
• Logging immutabile: Azioni di revisione, approvazioni, upload e modifiche devono lasciare una traccia duratura.
• Collegamento ai controlli: Le evidenze dovrebbero essere legate a un controllo specifico, non riversate in un repository generico.
• Disciplina di revisione: L'evidenza che non viene mai rivista diventa rumore archiviato, non assurance.
• Esportabilità: I team dovrebbero poter produrre un evidence pack coerente senza ricostruzioni manuali.

La stewardship è un controllo di sicurezza, non un compito amministrativo

La stewardship formalizzata viene spesso trattata come semplice amministrazione. Non lo è. Quando la stewardship è debole, le evidenze si deteriorano, i cicli di revisione slittano e le eccezioni smettono di essere visibili.

Ecco perché il segnale economico conta. Le organizzazioni con data stewardship formalizzata registrano in media costi di data breach inferiori del 45%, come validato nel reporting IBM Cost of a Data Breach 2025 citato da Secure Data Technologies. Il punto importante non è solo la riduzione dei costi. È che una migliore ownership e revisione migliorano i risultati di sicurezza perché le persone sanno di cosa sono responsabili.

Cosa funziona e cosa di solito non funziona

I programmi diventano pronti per l'audit quando sono costruiti su flussi di evidenza ripetibili. Falliscono quando si affidano a un lavoro eroico di pulizia poche settimane prima dell'audit.

In pratica, ciò che funziona appare così:

• Evidenze generate durante le operations: Registri di approvazione, log di revisione, note di incidenti, output dei test e attestazioni di accesso vengono raccolti nel punto in cui avviene il lavoro.
• Eccezioni gestite in modo esplicito: Se un controllo non può essere rispettato temporaneamente, l'eccezione ha un proprietario, una motivazione, un limite temporale e una traccia di approvazione.
• Revisione periodica dei controlli: I proprietari non si limitano a confermare che il controllo esiste. Verificano se sia ancora allineato all'architettura e al rischio attuali.
• Validazione per scenari: I team simulano incident response, failure di fornitori e misuse degli accessi per confermare che la governance regga sotto stress.

Ciò che di solito non funziona è altrettanto costante:

• Svuotamento di evidenze su shared drive
• Revisioni annuali della titolarità senza controlli a metà ciclo
• Controlli scritti in modo troppo generico per essere testati
• Pacchetti di audit assemblati manualmente da thread email e screenshot

“Pronto per l'audit” dovrebbe significare che puoi rispondere a una domanda del regolatore partendo dal tuo sistema di record, non dalla memoria.

Un buon programma di governance rende gli audit noiosi. Questo è un segno di controllo, non di mancanza di ambizione.

Conclusione La Governance come Disciplina Ingegneristica

La governance dell'Information Technology viene spesso descritta come oversight. È vero, ma è incompleto. Negli ambienti regolamentati, la governance è più simile all'ingegneria. Definisce come le decisioni vengono tradotte in controlli, come i controlli vengono assegnati alle persone e come queste persone producono evidenze che il sistema sta operando come previsto.

Ecco perché la compliance basata sulla carta continua a fallire. I documenti possono descrivere l'intento, ma non possono applicare accessi, classificare dati, approvare modifiche, valutare fornitori o dimostrare che una revisione sia avvenuta. Solo un sistema funzionante può farlo.

La vera unità di misura della governance è la decisione tracciabile

Un programma di governance diventa credibile quando può mostrare una catena dalla decisione all'azione. Un board o un comitato definisce la direzione. Un manager assegna l'implementazione. Un proprietario del controllo opera la salvaguardia. L'evidenza conferma che la salvaguardia è stata applicata e rivista. Se manca anche un solo anello, l'organizzazione torna nel mondo delle supposizioni.

Per i CISO, questo è importante perché le normative moderne non testano solo l'esistenza delle policy. Testano se le responsabilità sono chiare, se i controlli sono difendibili e se l'azienda sa spiegare cosa è accaduto quando le condizioni sono cambiate. Questo richiede tracciabilità, non volume di policy.

Cosa cambia una governance matura

Quando la governance è progettata bene, diverse cose migliorano contemporaneamente:

• Gli audit diventano esercizi di verifica anziché preparazione d'emergenza
• Le decisioni di sicurezza sono più facili da difendere perché la titolarità è esplicita
• La resilienza operativa migliora perché i controlli sono collegati a servizi e dipendenze reali
• La leadership riceve reporting più chiaro perché le evidenze sono strutturate, non improvvisate

Il cambio di mentalità più utile è semplice. Non trattare la governance come un livello sopra l'ambiente tecnico. Trattala come parte dell'ambiente. Appartiene al design dei sistemi, ai modelli di accesso, alla gestione delle evidenze, al vendor management e alla revisione operativa.

Questo è il significato pratico di padroneggiare la governance dell'Information Technology nel 2026. Non più processo per il gusto del processo. Sistemi migliori, responsabilità più chiare ed evidenze che resistono quando qualcuno indipendente chiede di vedere come funziona davvero l'organizzazione.

Se stai costruendo questo tipo di modello di governance basato sulle evidenze, AuditReady merita un'occhiata. È progettato per team regolamentati che hanno bisogno di ownership chiara, collegamenti tracciabili tra policy e controlli, audit trail immutabili e pacchetti di evidenze esportabili senza trasformare la governance in un esercizio di punteggio.