Antonio Point of View

3,136 subscribersSubscribed

Implementare una soluzione di Data Security? Ecco cosa verificare prima ancora di iniziare una DPIA

Antonio Ieranò

Information & Cybersecurity Strategist | Digital Sovereignty • AI Governance • Complex Systems | Author, Researcher & Occasional Philosopher | Views stubbornly my own. 🧠

October 12, 2026

Dalla frammentazione degli assessment a una governance tecnologica basata sul rischio: perché forse abbiamo bisogno di condividere le informazioni prima ancora di moltiplicare le valutazioni.

Il problema non è la mancanza di questionari. È che ne abbiamo troppi.

Immaginiamo una situazione piuttosto comune.

Un’organizzazione decide di introdurre una nuova piattaforma di Data Security.

Potrebbe trattarsi di una soluzione Data Loss Prevention (DLP), Endpoint DLP, Cloud Access Security Broker (CASB), Data Security Posture Management (DSPM), Insider Risk Management oppure di una qualsiasi altra tecnologia destinata a proteggere le informazioni aziendali.

Il progetto nasce da un’esigenza concreta: ridurre il rischio di perdita dei dati, migliorare la visibilità sulle informazioni sensibili, prevenire accessi non autorizzati oppure soddisfare determinati requisiti di sicurezza.

• Il CISO identifica una possibile soluzione.
• Il team tecnico avvia la valutazione.
• Il vendor presenta le funzionalità.
• Si organizza una dimostrazione.
• Si discute di architettura, integrazioni, prestazioni e costi.

Fin qui, tutto normale.

Poi comincia qualcosa che chi lavora in una grande organizzazione conosce piuttosto bene.

Il Procurement invia il proprio questionario di valutazione del fornitore.

Il team Security richiede documentazione sulle certificazioni, sulle vulnerabilità, sulla cifratura e sui controlli di accesso.

Il DPO vuole comprendere quali dati personali vengono trattati, dove vengono conservati e se sia necessario effettuare una Data Protection Impact Assessment (DPIA).

L’ufficio legale chiede informazioni sulle responsabilità contrattuali, sui subprocessori, sui trasferimenti internazionali e sulle condizioni di utilizzo.

Le risorse umane iniziano a interrogarsi sulle possibili implicazioni relative al monitoraggio dei lavoratori.

La funzione Compliance deve verificare gli obblighi applicabili in relazione a GDPR, NIS2, DORA, Cyber Resilience Act, AI Act e alle altre discipline pertinenti.

L’IT Operations vuole conoscere le modalità di backup, disaster recovery, supporto e gestione degli aggiornamenti.

Il Risk Management chiede una valutazione dei rischi.

L’Internal Audit vuole sapere quali evidenze saranno disponibili per dimostrare l’efficacia dei controlli.

Tutte richieste legittime.

Tutte attività potenzialmente necessarie.

Eppure, osservando il processo nel suo insieme, emerge un problema.

Molte di queste funzioni stanno cercando di ottenere le stesse informazioni, ma lo fanno separatamente, con linguaggi differenti, attraverso questionari diversi e spesso senza condividere le risposte.

• La retention viene richiesta dal DPO.
• Poi dal Security Team.
• Poi dal Procurement.
• Poi dall’Internal Audit.
• La localizzazione dei dati viene verificata dal Legal, dalla Privacy e dalla Security.
• Le modalità di accesso del supporto tecnico vengono richieste durante il Vendor Risk Assessment e nuovamente durante la Security Architecture Review.
• La gestione delle vulnerabilità viene analizzata dal team Security, dal Risk Management e, in determinati contesti, anche nell’ambito delle verifiche sulla supply chain.

Il risultato?

Una proliferazione di documenti che non necessariamente produce una maggiore comprensione del rischio.

Anzi, talvolta produce l’effetto opposto.

Informazioni duplicate.

Risposte non perfettamente coerenti.

Versioni differenti della stessa documentazione.

Tempi di valutazione più lunghi.

Responsabilità poco chiare.

E, soprattutto, una visione frammentata della tecnologia che l’organizzazione sta per introdurre.

Mi chiedo quindi se il problema non sia proprio il punto di partenza.

Forse non abbiamo bisogno di un altro questionario.

Forse abbiamo bisogno di una base informativa comune da cui far partire tutte le valutazioni successive.

La traiettoria europea: normative diverse, una crescente centralità del rischio

C’è un elemento che rende questa riflessione particolarmente attuale.

Se osserviamo l’evoluzione della normativa europea in materia di protezione dei dati, cybersecurity, resilienza digitale e intelligenza artificiale, possiamo individuare una traiettoria interessante.

Sempre più discipline attribuiscono un ruolo centrale alla valutazione del rischio, alla proporzionalità delle misure, alla documentazione delle decisioni e alla verifica continua della loro efficacia.

Naturalmente sarebbe scorretto sostenere che tutte le normative europee adottino lo stesso modello.

Non è così.

• Cambiano gli obiettivi.
• Cambiano i soggetti obbligati.
• Cambiano le definizioni di rischio.
• Cambiano gli interessi da proteggere.
• Cambiano le responsabilità e i meccanismi di vigilanza.

Ma esistono elementi metodologici ricorrenti che meritano attenzione.

Pensiamo al GDPR.

Il suo approccio è profondamente legato alla responsabilizzazione del titolare del trattamento e alla valutazione dei rischi per i diritti e le libertà delle persone fisiche.

La DPIA prevista dall’articolo 35 rappresenta uno degli strumenti attraverso cui questo approccio trova applicazione.

Il titolare deve comprendere il trattamento, valutarne necessità e proporzionalità, identificare i rischi e individuare misure adeguate.

Consideriamo poi la direttiva NIS2.

Qui l’attenzione si concentra sulla gestione dei rischi per la sicurezza dei sistemi informativi e delle reti, sulla continuità operativa, sulla gestione degli incidenti e sulla sicurezza della supply chain.

Non si tratta dello stesso rischio considerato dal GDPR.

Ma anche in questo caso diventa necessario conoscere i sistemi, le dipendenze, i fornitori, le vulnerabilità e le misure di protezione.

DORA, nel settore finanziario, introduce un quadro articolato per la gestione del rischio ICT, la resilienza operativa digitale e la gestione dei rischi derivanti dai fornitori terzi di servizi ICT.

Il Cyber Resilience Act affronta invece la cybersecurity dei prodotti con elementi digitali, introducendo obblighi che riguardano, tra l’altro, la valutazione dei rischi di cybersecurity da parte dei fabbricanti e la gestione delle vulnerabilità lungo il ciclo di vita del prodotto.

L’AI Act introduce, per i sistemi di intelligenza artificiale classificati ad alto rischio, requisiti specifici di gestione del rischio, documentazione, supervisione umana e controllo.

Anche la direttiva CER, dedicata alla resilienza dei soggetti critici, attribuisce un ruolo importante alla valutazione dei rischi e alla capacità di prevenire, resistere e reagire agli eventi che possono compromettere i servizi essenziali.

Queste discipline non sono intercambiabili.

Non tutte si applicano a ogni organizzazione o tecnologia.

E non tutte richiedono lo stesso tipo di assessment.

Il Cyber Resilience Act, per esempio, pone obblighi specifici sui soggetti che rientrano nel suo ambito di applicazione, in particolare lungo la catena di produzione e commercializzazione dei prodotti con elementi digitali. Non trasforma automaticamente ogni cliente che acquista software in un fabbricante soggetto ai medesimi obblighi.

Analogamente, gli obblighi previsti dall’AI Act dipendono dal ruolo dell’organizzazione, dalla tipologia di sistema e dalla sua classificazione.

Tuttavia, osservando questi strumenti da una prospettiva di governance, emerge una struttura ricorrente.

Comprendere il contesto.

Identificare gli elementi rilevanti.

Valutare i rischi.

Definire misure adeguate.

Documentare le decisioni.

Verificare l’efficacia delle misure.

Riesaminare le valutazioni quando cambiano le condizioni.

Ed è proprio qui che nasce la mia domanda.

Se una parte crescente della governance europea richiede valutazioni strutturate del rischio, perché continuiamo a raccogliere le informazioni necessarie attraverso processi completamente indipendenti?

Non sto suggerendo di unificare gli obblighi normativi.

Sto suggerendo di valutare se sia possibile condividere meglio le informazioni che permettono di rispettarli.

Perché una cosa è avere valutazioni differenti.

Un’altra è dover riscoprire ogni volta come funziona la stessa tecnologia.

Prima di valutare il rischio, bisogna conoscere ciò che stiamo valutando

Prendiamo un esempio concreto.

Un’organizzazione vuole implementare una piattaforma Endpoint DLP.

L’obiettivo è impedire che informazioni riservate vengano copiate su dispositivi USB non autorizzati oppure trasferite verso servizi cloud personali.

Dal punto di vista della cybersecurity, la finalità è chiara.

Ridurre il rischio di esfiltrazione dei dati.

Ma cosa sappiamo realmente della tecnologia?

Quali informazioni raccoglie?

Registra soltanto gli eventi che violano una policy oppure tutte le operazioni effettuate sui file?

Memorizza il nome del documento?

Il percorso?

Il contenuto?

L’identità dell’utente?

L’applicazione utilizzata?

L’indirizzo IP?

Il dispositivo di destinazione?

Può acquisire screenshot?

Può ricostruire sequenze di attività?

Può correlare eventi differenti?

Per quanto tempo conserva queste informazioni?

Chi può visualizzarle?

Chi può esportarle?

Il supporto tecnico del fornitore può accedervi?

Le informazioni vengono trasferite verso altri sistemi?

Quali funzionalità sono abilitate per impostazione predefinita?

Quali possono essere disattivate?

Quali sono obbligatorie per il funzionamento del prodotto?

La risposta a queste domande è rilevante per il CISO.

Ma è altrettanto rilevante per il DPO.

Per il Legal.

Per l’HR.

Per il Risk Management.

Per l’Internal Audit.

E per chiunque debba valutare le conseguenze dell’introduzione di quella tecnologia.

Non abbiamo quindi cinque problemi informativi differenti.

Abbiamo un insieme di informazioni tecniche e organizzative che può essere utilizzato per affrontare cinque problemi differenti.

Questa distinzione mi sembra fondamentale.

Il rischio non è una proprietà immutabile del prodotto. Dipende anche dal contesto, dalle finalità, dalla configurazione e dalle modalità di utilizzo.

Due organizzazioni possono utilizzare la stessa piattaforma ottenendo risultati molto diversi.

La prima può limitarsi a bloccare trasferimenti non autorizzati di documenti classificati.

La seconda può raccogliere informazioni dettagliate sulle attività individuali, conservarle per lunghi periodi e correlarle con altre fonti.

La tecnologia può essere identica.

Il trattamento dei dati personali no.

Il rischio di sicurezza può essere differente.

Le implicazioni giuridiche possono essere differenti.

E le misure necessarie possono cambiare significativamente.

Per questo motivo non basta sapere che cosa un prodotto può fare.

Bisogna sapere anche che cosa l’organizzazione ha deciso di fargli fare.

Una proposta: Technology Governance Assessment

Da queste considerazioni nasce un’idea sulla quale sto ragionando e che vorrei condividere.

Per il momento la chiamerò Technology Governance Assessment, o TGA.

Il nome è provvisorio.

E non pretendo che rappresenti una metodologia nuova in ogni sua componente.

Esistono già modelli consolidati di Third Party Risk Management, Vendor Assessment, Privacy Impact Assessment, Security Architecture Review e Governance, Risk & Compliance.

Esistono standard e framework che affrontano molti degli aspetti di cui sto parlando.

L’obiettivo non sarebbe sostituirli.

E nemmeno aggiungere un nuovo livello burocratico.

L’idea è introdurre una fase metodologica comune, destinata a raccogliere e mantenere le informazioni necessarie per comprendere una tecnologia prima di sottoporla alle valutazioni specialistiche.

In pratica, separare due attività che oggi vengono spesso confuse.

La prima consiste nel descrivere la tecnologia e il suo utilizzo.

La seconda consiste nel valutarne rischi, obblighi, adeguatezza e conseguenze.

Sono attività collegate.

Ma non sono la stessa cosa.

Un Technology Governance Assessment dovrebbe aiutare a rispondere a domande fondamentali.

Che cosa stiamo introducendo?

Per quale finalità?

Quali processi aziendali coinvolge?

Quali informazioni tratta?

Quali sistemi utilizza?

Da quali fornitori dipende?

Quali funzionalità possiede?

Quali configurazioni sono disponibili?

Quali sono le impostazioni predefinite?

Quali decisioni deve prendere il cliente?

Quali rischi potrebbero derivare dalle diverse configurazioni?

Quali evidenze sono disponibili?

Quali informazioni devono essere ancora verificate?

L’obiettivo sarebbe costruire una rappresentazione condivisa della tecnologia, sufficientemente dettagliata da supportare valutazioni differenti.

Una sorta di Single Source of Governance Truth.

Non una singola valutazione del rischio.

Non un’unica decisione di conformità.

Ma una base informativa comune, verificabile e mantenuta aggiornata.

Il punto di partenza: distinguere le capacità del prodotto dalle decisioni del cliente

Uno degli aspetti che considero più importanti riguarda la configurabilità.

Spesso, durante una valutazione, viene chiesto al vendor se una determinata funzionalità sia disponibile.

La risposta è sì.

E la verifica termina lì.

Ma sapere che una funzione esiste non significa sapere come verrà utilizzata.

Prendiamo la conservazione dei dati.

Una domanda tradizionale potrebbe essere:

“Qual è la retention del prodotto?”

Una risposta potrebbe indicare un periodo massimo di conservazione.

Ma questa informazione, da sola, non è sufficiente.

Bisognerebbe conoscere almeno cinque elementi.

Il valore minimo supportato.

Il valore massimo supportato.

Il valore predefinito.

Il valore effettivamente configurato.

La motivazione della configurazione scelta.

A questi aggiungerei la possibilità di differenziare la retention per categoria di dato e le modalità con cui viene eseguita la cancellazione.

Per esempio, una piattaforma potrebbe permettere di conservare determinati eventi per 30, 90, 180 oppure 365 giorni.

Ma quale valore viene applicato quando il sistema viene installato?

Il cliente può modificarlo?

La modifica è retroattiva?

La retention riguarda soltanto gli eventi oppure anche le copie dei documenti?

I dati esportati seguono le stesse regole?

Che cosa accade ai backup?

Esistono eccezioni per le investigazioni?

Quando inizia il conteggio del periodo di conservazione?

Alla generazione dell’evento?

Alla creazione dell’alert?

Alla chiusura dell’incidente?

Sono dettagli tecnici.

Ma possono avere conseguenze importanti sulla privacy, sulla sicurezza, sui costi, sulle investigazioni e sulla gestione del rischio.

E, soprattutto, sono informazioni che possono essere riutilizzate in numerose valutazioni.

Il DPO le utilizzerà per verificare la limitazione della conservazione.

Il CISO per valutare le esigenze investigative e la protezione delle evidenze.

Il Legal per verificare eventuali obblighi di conservazione e cancellazione.

L’IT Operations per comprendere il comportamento di backup e archivi.

L’Internal Audit per verificare la corrispondenza tra policy e configurazioni.

La stessa informazione.

Cinque prospettive differenti.

Perché raccoglierla cinque volte?

I dati: non basta sapere che vengono protetti

Le tecnologie di Data Security rappresentano un esempio particolarmente interessante perché, per proteggere le informazioni, possono avere bisogno di analizzarle.

Una soluzione DLP può esaminare documenti e allegati.

Una piattaforma DSPM può individuare dati personali e informazioni sensibili all’interno di repository aziendali.

Un CASB può analizzare le attività svolte nei servizi cloud.

Una piattaforma di Insider Risk può correlare eventi associati a identità individuali.

Un sistema SIEM può aggregare informazioni provenienti da decine di sorgenti.

Un EDR può raccogliere telemetria dettagliata sugli endpoint.

Tutte queste tecnologie possono contribuire alla sicurezza.

Ma introducono anche trattamenti che devono essere compresi e governati.

La prima attività dovrebbe quindi consistere nell’identificare le categorie di dati effettivamente coinvolte.

Identificativi degli utenti.

Informazioni sui dispositivi.

Indirizzi IP.

Nomi e percorsi dei file.

Metadati.

Contenuti.

Eventi di accesso.

Operazioni sui documenti.

Informazioni sulle applicazioni.

Attività di rete.

Classificazioni.

Alert.

Evidenze investigative.

Eventuali informazioni derivate da correlazioni o analisi comportamentali.

Non tutte queste categorie saranno presenti in ogni prodotto.

Ed è proprio questo il punto.

Non dovremmo presumere che una tecnologia raccolga determinati dati soltanto perché appartiene a una specifica categoria commerciale.

Dovremmo verificarlo.

Inoltre, sarebbe opportuno distinguere tra dati semplicemente analizzati, dati conservati, dati esportabili e dati trasferiti verso sistemi esterni.

Una soluzione che analizza temporaneamente un documento senza conservarne il contenuto presenta caratteristiche differenti rispetto a una che mantiene una copia completa del file associata a un alert.

Anche la classificazione automatica può introdurre informazioni nuove.

Un sistema potrebbe non conservare il documento originale, ma memorizzare che un determinato utente ha tentato di trasferire un file contenente informazioni sanitarie, finanziarie o altre categorie di dati sensibili.

Questa informazione derivata potrebbe essere essa stessa un dato personale.

La valutazione deve quindi considerare non soltanto ciò che viene raccolto, ma anche ciò che viene prodotto attraverso l’elaborazione.

Data residency: una risposta geografica non basta

Un’altra domanda ricorrente riguarda la localizzazione dei dati.

“Dove vengono conservate le informazioni?”

La risposta più frequente è il nome di una regione cloud oppure di un Paese.

Ma anche in questo caso la questione è più articolata.

Dove vengono conservati i dati principali?

Dove vengono elaborati?

Dove si trovano i backup?

Da quali Paesi può operare il supporto tecnico?

Esistono subprocessori che possono accedere alle informazioni?

Quali dati vengono trasferiti attraverso le integrazioni?

I metadati seguono gli stessi percorsi dei contenuti?

Gli ambienti di sviluppo, test e supporto utilizzano dati reali?

Una piattaforma può conservare i dati in Europa e prevedere comunque accessi o trattamenti che richiedono ulteriori verifiche.

La localizzazione dello storage è importante.

Ma non descrive, da sola, l’intero ciclo di vita del dato.

Per questo motivo un assessment tecnico dovrebbe ricostruire i flussi informativi, identificando sorgenti, destinazioni, categorie di dati e soggetti coinvolti.

Queste informazioni saranno poi utilizzate dal Legal e dal DPO per valutare gli eventuali trasferimenti internazionali e le garanzie applicabili.

Ancora una volta, la raccolta tecnica è comune.

La valutazione giuridica rimane specialistica.

Access Control: chi può vedere cosa?

Un altro esempio riguarda il controllo degli accessi.

Molti questionari chiedono semplicemente:

“Il prodotto supporta RBAC?”

Se la risposta è positiva, il requisito viene considerato soddisfatto.

Ma il supporto al Role-Based Access Control non dimostra automaticamente che gli accessi siano configurati in modo adeguato.

Bisogna comprendere quali ruoli esistono.

Quali dati possono visualizzare.

Se possono accedere ai contenuti oppure soltanto ai metadati.

Se possono esportare informazioni.

Se possono modificare le configurazioni.

Se possono eliminare evidenze.

Se esistono meccanismi di segregazione delle responsabilità.

Se gli accessi privilegiati vengono registrati.

Se è disponibile un controllo temporaneo dei privilegi.

Se il supporto del vendor può accedere all’ambiente.

Se l’accesso richiede un’autorizzazione esplicita del cliente.

Se è possibile verificare successivamente quali operazioni sono state effettuate.

Queste informazioni sono importanti per la cybersecurity.

Ma anche per la privacy, per la governance delle investigazioni e per la protezione delle informazioni aziendali.

Un sistema può essere tecnicamente sicuro e contemporaneamente consentire a un numero eccessivo di persone di visualizzare informazioni che non dovrebbero conoscere.

La presenza di un controllo non equivale alla sua corretta applicazione.

La governance non dovrebbe limitarsi a verificare l’esistenza delle funzionalità. Dovrebbe verificare le decisioni che ne determinano l’utilizzo.

Il vendor assessment non può fermarsi alle certificazioni

Le certificazioni sono importanti.

Possono fornire evidenze utili sull’esistenza di sistemi di gestione, processi e controlli.

Ma non sostituiscono la comprensione della tecnologia.

Un’organizzazione dovrebbe sapere come il fornitore gestisce le vulnerabilità, quali processi di sviluppo sicuro adotta, come vengono distribuiti gli aggiornamenti e per quanto tempo viene garantito il supporto.

Dovrebbe conoscere le dipendenze tecnologiche rilevanti.

Comprendere la catena di fornitura.

Verificare la disponibilità di documentazione tecnica.

Conoscere le procedure di incident response.

Comprendere come vengono comunicate le vulnerabilità.

Valutare i processi di gestione degli incidenti che coinvolgono il servizio.

Verificare quali impegni contrattuali siano effettivamente previsti.

E distinguere tra dichiarazioni commerciali, documentazione tecnica, attestazioni indipendenti ed evidenze verificate.

Un aspetto che inserirei nel framework riguarda proprio la qualità delle evidenze.

Non tutte le risposte hanno lo stesso valore.

Una dichiarazione generica del vendor non equivale a una configurazione verificata.

Una certificazione non equivale a una verifica puntuale di tutte le funzionalità.

Una documentazione pubblicata tre anni prima potrebbe non descrivere correttamente la versione attualmente utilizzata.

Per ogni informazione sarebbe quindi utile registrare la fonte, la data di verifica, il perimetro di validità e il soggetto responsabile dell’aggiornamento.

Questo permetterebbe di trasformare una raccolta di risposte in una base informativa realmente affidabile.

Quando la tecnologia entra nel rapporto di lavoro

C’è poi un ambito che, soprattutto nel contesto italiano, merita un’attenzione particolare.

Il monitoraggio dei lavoratori.

Le piattaforme di cybersecurity possono raccogliere informazioni che, direttamente o indirettamente, permettono di ricostruire le attività svolte da una persona.

Pensiamo agli endpoint.

Alle applicazioni utilizzate.

Agli accessi.

Ai trasferimenti di file.

Alle attività nei servizi cloud.

Alle operazioni sui documenti.

Alle correlazioni temporali.

In determinate configurazioni, queste informazioni possono consentire una visibilità molto dettagliata sul comportamento individuale.

La finalità di sicurezza informatica non elimina automaticamente le implicazioni relative alla normativa sul lavoro.

In Italia, l’articolo 4 dello Statuto dei Lavoratori disciplina gli strumenti dai quali può derivare il controllo a distanza dell’attività dei dipendenti, prevedendo condizioni, garanzie ed eccezioni che devono essere valutate nel caso concreto.

Non è sufficiente affermare che una tecnologia viene installata per proteggere i dati aziendali.

Bisogna comprendere quali capacità di osservazione introduce e come saranno utilizzate.

Questo significa che, in determinati progetti, il coinvolgimento dell’HR e del Legal non dovrebbe avvenire quando la piattaforma è già stata distribuita.

Dovrebbe avvenire durante la progettazione.

Un assessment comune potrebbe rendere immediatamente disponibili le informazioni necessarie per identificare queste implicazioni.

La piattaforma permette di ricostruire l’attività individuale?

Con quale livello di dettaglio?

Per quanto tempo?

Chi può accedere alle informazioni?

È possibile limitare la raccolta?

Esistono funzionalità di registrazione o acquisizione dei contenuti?

Sono previste correlazioni con informazioni provenienti da altri sistemi?

Le informazioni possono essere utilizzate per finalità investigative o disciplinari?

Le risposte non determinano automaticamente la liceità del trattamento.

Ma consentono alle funzioni competenti di effettuare le verifiche necessarie prima dell’implementazione.

Ed evitano di scoprire troppo tardi che una funzionalità tecnicamente disponibile introduce obblighi organizzativi o giuridici non considerati.

Intelligenza artificiale: un’altra ragione per condividere le informazioni

L’integrazione dell’intelligenza artificiale nelle piattaforme enterprise rende questo problema ancora più evidente.

Sempre più tecnologie utilizzano algoritmi per classificare informazioni, identificare anomalie, correlare eventi, attribuire priorità agli alert o supportare decisioni operative.

Non tutte queste funzionalità rientrano necessariamente nella definizione di sistema di intelligenza artificiale prevista dalla normativa europea.

E non tutti i sistemi AI sono classificati ad alto rischio.

Ma proprio per questo è importante comprendere le caratteristiche effettive della tecnologia.

Quali funzionalità utilizzano AI?

Quali dati vengono elaborati?

I dati del cliente vengono utilizzati per addestrare o migliorare modelli?

Esistono trasferimenti verso servizi esterni?

Quali informazioni vengono conservate?

È possibile disabilitare determinate funzionalità?

Gli output vengono utilizzati per prendere decisioni?

Esiste una supervisione umana?

Quali sono le limitazioni dichiarate?

Come vengono gestiti errori, falsi positivi e risultati non affidabili?

Quali sono le responsabilità del fornitore e quali quelle dell’organizzazione che utilizza il sistema?

Sono domande rilevanti per il CISO.

Ma anche per il DPO, per il Legal, per il Risk Management e per chi si occupa di AI Governance.

Un modello comune di raccolta delle informazioni potrebbe evitare che ogni funzione debba ricostruire autonomamente il funzionamento della stessa componente tecnologica.

Naturalmente, l’eventuale valutazione richiesta dall’AI Act dovrebbe essere effettuata secondo gli obblighi applicabili al sistema e al ruolo dell’organizzazione.

Un Technology Governance Assessment non la sostituirebbe.

Potrebbe però fornire una parte delle informazioni necessarie.

La resilienza operativa è parte della stessa conversazione

Finora abbiamo parlato soprattutto di dati, accessi e configurazioni.

Ma l’introduzione di una tecnologia enterprise comporta anche dipendenze operative.

Che cosa accade se il servizio non è disponibile?

La piattaforma è necessaria per garantire la continuità di un processo critico?

Quali funzionalità rimangono operative durante un’interruzione?

Esistono modalità degradate?

Quali sono gli impegni di disponibilità?

Quali obiettivi di ripristino sono previsti?

Come vengono gestiti backup e disaster recovery?

Quali dati possono essere recuperati?

Con quali tempi?

Come viene verificata l’efficacia delle procedure di ripristino?

Quali dipendenze esistono da servizi cloud, API, identity provider o altri componenti?

Come vengono gestite le modifiche?

Quali sono le procedure di uscita dal servizio?

Come vengono restituiti o cancellati i dati al termine del contratto?

Queste domande appartengono alla resilienza operativa.

Ma molte delle risposte sono già state raccolte durante il Vendor Assessment o la Security Architecture Review.

Ancora una volta, il problema non è la mancanza di informazioni.

È la loro distribuzione tra processi differenti.

Non tutte le tecnologie richiedono lo stesso livello di assessment

A questo punto potrebbe sorgere un’obiezione legittima.

Un framework comune rischia di diventare l’ennesimo questionario interminabile?

È un rischio concreto.

E sarebbe paradossale risolvere il problema della duplicazione introducendo un documento ancora più complesso.

Per evitarlo, il framework dovrebbe essere modulare e proporzionato.

Non ha senso sottoporre ogni tecnologia allo stesso livello di approfondimento.

Un’applicazione utilizzata per una funzione marginale, senza accesso a dati personali o sistemi critici, non presenta necessariamente lo stesso profilo di rischio di una piattaforma che monitora migliaia di endpoint e analizza informazioni aziendali sensibili.

Il primo passaggio dovrebbe quindi essere una classificazione preliminare.

Che tipo di tecnologia stiamo introducendo?

Quali processi supporta?

Quali informazioni tratta?

Qual è la sua criticità?

Quali dipendenze introduce?

Quali categorie di persone possono essere coinvolte?

Quali normative potrebbero essere pertinenti?

Quali funzionalità possono generare rischi particolari?

Sulla base delle risposte, il framework dovrebbe attivare soltanto i domini di approfondimento necessari.

Una soluzione che non tratta dati personali potrebbe non richiedere un’analisi privacy della stessa profondità di una piattaforma di monitoraggio degli utenti.

Un prodotto che non utilizza AI non dovrebbe essere sottoposto inutilmente a un questionario dettagliato sui modelli.

Una tecnologia non rilevante per determinati obblighi settoriali non dovrebbe essere valutata come se tali obblighi fossero automaticamente applicabili.

Questo approccio permetterebbe di mantenere la profondità dove serve, evitando complessità dove non produce valore.

La proporzionalità dovrebbe quindi caratterizzare non soltanto le misure di sicurezza, ma anche il processo di assessment.

Il framework dovrebbe distinguere fatti, dichiarazioni, decisioni e rischi

Un altro elemento che considero essenziale riguarda la struttura delle informazioni.

Oggi molti questionari mescolano elementi molto differenti.

Domande sulle caratteristiche del prodotto.

Domande sulla configurazione del cliente.

Domande sulle responsabilità contrattuali.

Domande sulla conformità normativa.

Domande sui rischi.

Domande sulle misure di mitigazione.

Il risultato è spesso un documento nel quale non è chiaro chi debba rispondere e chi debba assumersi la responsabilità della decisione.

Un approccio più strutturato dovrebbe distinguere almeno quattro livelli.

Il primo riguarda le capacità tecniche della soluzione.

Che cosa può fare il prodotto?

Quali sono i limiti?

Quali sono le configurazioni disponibili?

Quali funzionalità sono obbligatorie?

Quali sono opzionali?

Il secondo riguarda le dichiarazioni e le evidenze del fornitore.

Quali processi di sicurezza sono documentati?

Quali certificazioni sono disponibili?

Quali impegni contrattuali vengono assunti?

Quali informazioni sono state verificate?

Il terzo riguarda le decisioni dell’organizzazione.

Quali funzionalità saranno abilitate?

Quali dati saranno raccolti?

Quale retention verrà applicata?

Quali ruoli potranno accedere alle informazioni?

Quali integrazioni saranno autorizzate?

Il quarto riguarda le valutazioni specialistiche.

Quali rischi derivano da quelle decisioni?

Quali obblighi si applicano?

Quali misure sono necessarie?

Quale rischio residuo rimane?

Chi può approvare il trattamento o l’introduzione della tecnologia?

Questa separazione aiuterebbe a evitare un equivoco piuttosto frequente.

Il vendor può dichiarare che una piattaforma consente di conservare i dati per un massimo di dodici mesi.

Ma non può decidere, al posto del cliente, che dodici mesi siano necessari e proporzionati per una determinata finalità.

Può descrivere le funzionalità di monitoraggio.

Ma non può determinare autonomamente se la loro attivazione sia compatibile con la disciplina applicabile al rapporto di lavoro del cliente.

Può documentare le misure tecniche di sicurezza.

Ma non può garantire che ogni possibile configurazione adottata dal cliente produca un livello di rischio accettabile.

Il vendor descrive le capacità e fornisce le evidenze pertinenti. Il cliente decide come utilizzare la tecnologia e valuta le conseguenze delle proprie decisioni.

Le responsabilità effettive dipendono naturalmente dai ruoli giuridici e contrattuali delle parti, ma questa distinzione metodologica rimane utile.

Un’informazione raccolta una volta non deve diventare un’informazione dimenticata

C’è però un problema che non possiamo ignorare.

Le tecnologie cambiano.

Cambiano le versioni.

Cambiano le funzionalità.

Cambiano le architetture.

Cambiano i subprocessori.

Cambiano le condizioni contrattuali.

Cambiano le integrazioni.

Cambiano le configurazioni.

Cambiano le minacce.

E cambiano anche i requisiti normativi.

Una risposta corretta oggi potrebbe non esserlo più tra sei mesi.

Per questo motivo l’idea di raccogliere le informazioni una sola volta non dovrebbe essere interpretata letteralmente.

Il principio dovrebbe essere un altro.

Raccogliere l’informazione una volta, mantenerla aggiornata e riutilizzarla finché rimane valida.

Questo richiede un modello di governance delle evidenze.

Ogni informazione dovrebbe avere un responsabile.

Una fonte.

Una data di verifica.

Un ambito di applicazione.

Una versione.

Una modalità di aggiornamento.

E, quando necessario, una scadenza.

Pensiamo alla retention.

Se il cliente modifica il periodo di conservazione, quella decisione potrebbe avere conseguenze sulla DPIA, sulle procedure investigative, sulla gestione degli incidenti e sui requisiti di cancellazione.

Non dovrebbe essere necessario aspettare il successivo audit per scoprire la modifica.

Analogamente, l’introduzione di una nuova funzionalità di analisi comportamentale potrebbe richiedere il riesame delle valutazioni privacy e lavoristiche.

Un nuovo subprocessor potrebbe richiedere verifiche contrattuali e sui trasferimenti.

Una modifica architetturale potrebbe influire sulla resilienza operativa.

Il framework dovrebbe quindi prevedere eventi che attivano il riesame delle informazioni e delle valutazioni collegate.

Non un documento statico.

Ma una base informativa governata lungo il ciclo di vita della tecnologia.

Una base comune non significa una valutazione del rischio comune

Questo punto merita particolare attenzione.

Quando parliamo di un approccio integrato alla governance, dobbiamo evitare una semplificazione pericolosa.

Il rischio considerato dal GDPR non coincide necessariamente con quello considerato dalla NIS2.

La DPIA valuta i rischi per i diritti e le libertà delle persone fisiche derivanti dal trattamento dei dati personali.

Una valutazione di cybersecurity può concentrarsi sulla compromissione della riservatezza, integrità e disponibilità dei sistemi e delle informazioni.

Una valutazione di resilienza operativa considera anche la capacità di mantenere o ripristinare servizi e processi.

Una valutazione relativa al rapporto di lavoro deve considerare ulteriori vincoli, diritti e garanzie.

Una valutazione di un sistema AI può richiedere analisi specifiche sui rischi per salute, sicurezza e diritti fondamentali, secondo il quadro normativo applicabile.

Sono prospettive differenti.

Possono sovrapporsi.

Possono influenzarsi.

Ma non devono essere confuse.

Un unico punteggio di rischio difficilmente sarebbe sufficiente a rappresentarle tutte.

E un’organizzazione non dovrebbe presumere che l’approvazione di una Security Review equivalga all’approvazione di una DPIA.

Oppure che una certificazione di sicurezza risolva automaticamente questioni relative al monitoraggio dei lavoratori.

Il valore di un framework comune non consiste nell’eliminare queste differenze.

Consiste nel permettere a ogni funzione di lavorare su informazioni coerenti.

Una base condivisa.

Valutazioni distinte.

Responsabilità definite.

Decisioni tracciabili.

Questo, a mio avviso, dovrebbe essere il principio architetturale del modello.

Come potrebbe funzionare concretamente?

Immagino un processo relativamente semplice.

Una funzione aziendale propone l’introduzione di una nuova tecnologia.

Il primo passaggio consiste nell’identificare il contesto di utilizzo.

Non soltanto il nome del prodotto, ma anche le finalità, i processi coinvolti, le categorie di dati, gli utenti interessati e le principali dipendenze.

Successivamente viene effettuata una classificazione preliminare per identificare i domini di approfondimento necessari.

Il vendor fornisce le informazioni tecniche e organizzative di propria competenza.

Il cliente documenta le configurazioni previste e le modalità di utilizzo.

Le informazioni vengono raccolte in un repository condiviso, con evidenze, responsabilità e stato di verifica.

A questo punto le diverse funzioni aziendali possono utilizzare la stessa base per svolgere le proprie valutazioni.

Il DPO può avviare lo screening per determinare se sia necessaria una DPIA e, quando richiesta, utilizzare le informazioni disponibili per svilupparla.

Il CISO può condurre la Security Architecture Review.

Il Risk Management può effettuare la valutazione del rischio del fornitore.

Il Legal può analizzare le condizioni contrattuali e gli obblighi applicabili.

L’HR può valutare le implicazioni relative al monitoraggio dei lavoratori.

La Compliance può verificare i requisiti normativi pertinenti.

L’IT Operations può valutare resilienza, integrazioni e continuità operativa.

Il Procurement può utilizzare le evidenze per supportare il processo di approvazione.

Le valutazioni rimangono separate.

Ma le informazioni non devono essere ricostruite ogni volta.

Alla fine del processo, le decisioni e le eventuali condizioni di approvazione vengono collegate alle configurazioni effettivamente adottate.

E quando la tecnologia cambia, il sistema permette di identificare quali valutazioni potrebbero dover essere riesaminate.

Questo sarebbe il modello ideale.

Naturalmente, implementarlo richiederebbe di affrontare questioni organizzative non banali.

Chi è responsabile della base informativa?

Chi può modificarla?

Chi verifica le evidenze?

Come si gestiscono informazioni riservate?

Come si evitano accessi non autorizzati?

Come si impedisce che una risposta non verificata venga riutilizzata come se fosse una certezza?

Come si gestiscono le differenze tra organizzazioni, settori e Paesi?

Sono problemi reali.

Ma sono problemi di governance che, in buona parte, esistono già.

Oggi sono semplicemente distribuiti tra processi differenti.

Il ruolo del CISO: dalla verifica dei controlli alla governance delle decisioni

Per un CISO, questo approccio potrebbe avere implicazioni particolarmente interessanti.

Tradizionalmente, molte attività di valutazione tecnologica sono concentrate sull’identificazione dei rischi di sicurezza e sulla verifica delle misure tecniche.

Ma il ruolo del CISO moderno si estende sempre più verso la gestione delle dipendenze tecnologiche, la resilienza, la supply chain e il supporto alle decisioni aziendali.

Questo non significa che debba diventare responsabile di ogni obbligo normativo.

Sarebbe irrealistico.

E, probabilmente, anche poco opportuno.

Significa però che potrebbe svolgere un ruolo importante nel promuovere un modello di valutazione tecnologica più integrato.

Non sostituendo il DPO.

Non sostituendo il Legal.

Non sostituendo l’HR.

Non sostituendo il Procurement.

Ma contribuendo a costruire un linguaggio comune.

Perché molte delle informazioni necessarie alle diverse funzioni nascono proprio dall’analisi tecnica della soluzione.

La differenza è nel modo in cui vengono organizzate e condivise.

Il CISO potrebbe quindi contribuire a spostare l’attenzione da una domanda relativamente limitata:

“Questa tecnologia è sicura?”

A una domanda più ampia:

“Abbiamo compreso sufficientemente questa tecnologia per decidere consapevolmente come introdurla, configurarla e governarla?”

La seconda domanda non elimina la prima.

La colloca in un contesto più completo.

E soprattutto riconosce che l’introduzione di una tecnologia enterprise non è soltanto una decisione tecnica.

È una decisione organizzativa.

Un esempio: cinque valutazioni, una base informativa

Torniamo alla piattaforma DLP.

Immaginiamo che il cliente abbia raccolto informazioni complete sulle categorie di dati trattati, sulle funzionalità di monitoraggio, sulla retention, sui ruoli amministrativi, sulla localizzazione dei dati, sui subprocessori e sulle integrazioni.

Queste informazioni possono alimentare attività differenti.

La valutazione privacy analizzerà la necessità e proporzionalità del trattamento, i rischi per gli interessati e le misure di mitigazione.

La valutazione di sicurezza analizzerà l’architettura, le superfici di attacco, gli accessi privilegiati, le dipendenze e i controlli tecnici.

La valutazione del fornitore esaminerà affidabilità, processi di sicurezza, continuità del servizio e rischi della supply chain.

La valutazione lavoristica analizzerà le capacità di monitoraggio e gli adempimenti eventualmente necessari.

La valutazione operativa considererà disponibilità, supporto, integrazioni, backup e procedure di ripristino.

Cinque valutazioni.

Cinque prospettive.

Ma un’unica descrizione verificata della tecnologia e della configurazione prevista.

Naturalmente, ciascuna funzione potrà richiedere informazioni aggiuntive.

E alcune evidenze saranno specifiche di una determinata disciplina.

Il framework non dovrebbe impedire questi approfondimenti.

Dovrebbe semplicemente evitare che si riparta ogni volta da zero.

Il costo nascosto della frammentazione

Quando si parla di assessment, tendiamo a misurare il costo in termini di tempo necessario per compilare i questionari.

Ma credo che il problema sia più ampio.

La frammentazione introduce anche rischi organizzativi.

Una funzione può basarsi su documentazione aggiornata mentre un’altra utilizza una versione precedente.

Un cambiamento contrattuale può essere conosciuto dal Procurement ma non dal team Security.

Una nuova integrazione può essere approvata tecnicamente senza che siano state rivalutate le implicazioni privacy.

Una modifica della retention può essere effettuata senza aggiornare le procedure investigative.

Una funzionalità può essere attivata dopo il go-live senza che le funzioni competenti siano informate.

Questi problemi non dipendono necessariamente dall’assenza di controlli.

Possono dipendere dall’assenza di collegamenti tra controlli esistenti.

È una differenza importante.

Molte organizzazioni hanno già processi maturi di Security Assessment, Privacy Assessment, Third Party Risk Management e Compliance.

Il problema non è necessariamente crearne altri.

È comprendere come farli dialogare.

La duplicazione delle informazioni rappresenta quindi soltanto il sintomo più visibile.

Il problema strutturale riguarda la frammentazione della conoscenza e delle decisioni.

E se il framework diventasse anche uno strumento di Change Management?

C’è un ulteriore aspetto che considero interessante.

Oggi molte valutazioni vengono effettuate durante la fase di procurement o prima del go-live.

Successivamente, però, la tecnologia continua a evolvere.

Nuove versioni.

Nuove funzionalità.

Nuove integrazioni.

Nuove configurazioni.

Nuovi dati.

Nuovi fornitori.

E, talvolta, nuove finalità di utilizzo.

Un framework comune potrebbe diventare anche uno strumento per valutare l’impatto dei cambiamenti.

Immaginiamo che una piattaforma introduca una nuova funzionalità di analisi comportamentale basata su AI.

La modifica potrebbe avere conseguenze sulla sicurezza, sulla privacy, sulla governance dell’AI e sul monitoraggio dei lavoratori.

Se le informazioni sono gestite separatamente, ogni funzione potrebbe scoprire il cambiamento in momenti differenti.

Se invece esiste una base informativa condivisa, la modifica potrebbe attivare una revisione mirata dei domini interessati.

Non necessariamente una nuova valutazione completa.

Ma un’analisi delle differenze rispetto alla configurazione precedentemente approvata.

Lo stesso potrebbe accadere quando cambia la localizzazione dei dati, viene introdotto un nuovo subprocessor oppure viene modificato il periodo di conservazione.

Questo approccio permetterebbe di collegare più strettamente Technology Governance e Change Management.

E potrebbe ridurre il rischio che le valutazioni diventino obsolete poco dopo essere state completate.

Non un nuovo standard, ma una proposta da discutere

Vorrei essere chiaro su un punto.

Non sto proponendo di sostituire i framework esistenti.

E non sto suggerendo che tutte le organizzazioni debbano adottare un ulteriore processo formale.

Il Technology Governance Assessment, almeno nella forma in cui lo sto immaginando, è una proposta metodologica.

Un possibile modo per collegare attività che oggi vengono spesso gestite separatamente.

Potrebbe essere implementato attraverso strumenti GRC già disponibili.

Attraverso processi di Enterprise Architecture.

Attraverso piattaforme di Third Party Risk Management.

Attraverso repository documentali strutturati.

Oppure attraverso un modello organizzativo relativamente semplice.

La tecnologia utilizzata per gestire il framework sarebbe secondaria rispetto ai principi.

Raccogliere informazioni pertinenti.

Verificarne l’affidabilità.

Distinguerle dalle valutazioni.

Attribuire responsabilità.

Documentare le decisioni.

Riutilizzare le evidenze.

Gestire i cambiamenti.

Mantenere la proporzionalità.

L’obiettivo non sarebbe produrre più documentazione.

Sarebbe produrre decisioni migliori.

E, possibilmente, farlo con meno duplicazioni.

Dalla teoria alla pratica: quali domini dovrebbe comprendere?

Se dovessi iniziare a strutturare concretamente questo modello, partirei da alcuni domini fondamentali.

Il primo sarebbe la governance del fornitore.

Comprendere chi fornisce la tecnologia, quali soggetti partecipano all’erogazione del servizio, quali dipendenze esistono e quali garanzie vengono offerte.

Il secondo riguarderebbe la sicurezza tecnologica.

Architettura, sviluppo sicuro, gestione delle vulnerabilità, patching, cifratura, autenticazione, autorizzazione, logging e gestione degli incidenti.

Il terzo sarebbe dedicato ai dati.

Categorie trattate, finalità, flussi, classificazione, localizzazione, conservazione, cancellazione e trasferimenti.

Il quarto riguarderebbe le configurazioni.

Funzionalità disponibili, impostazioni predefinite, valori minimi e massimi, possibilità di personalizzazione e configurazioni effettivamente adottate.

Il quinto sarebbe dedicato agli accessi e alle attività amministrative.

Ruoli, privilegi, segregazione delle responsabilità, supporto remoto, audit trail ed esportazione delle informazioni.

Il sesto riguarderebbe la resilienza operativa.

Disponibilità, continuità, disaster recovery, backup, dipendenze, supporto ed exit strategy.

Il settimo considererebbe le implicazioni organizzative e lavoristiche.

Capacità di monitoraggio, correlazione delle attività, visibilità sulle persone e possibili utilizzi delle informazioni raccolte.

L’ottavo riguarderebbe l’intelligenza artificiale.

Funzionalità AI, dati utilizzati, finalità, supervisione umana, limitazioni e responsabilità.

Il nono sarebbe dedicato alla governance contrattuale.

DPA, accordi sul trattamento, subprocessori, SLA, responsabilità, diritti di audit e condizioni di cessazione.

Il decimo riguarderebbe la tracciabilità delle evidenze.

Fonti, versioni, verifiche, responsabilità e aggiornamenti.

Questi domini non rappresentano una struttura definitiva.

Sono un punto di partenza.

E probabilmente andrebbero adattati in funzione della tecnologia, del settore e della complessità dell’organizzazione.

Ma potrebbero costituire il nucleo informativo comune dal quale derivare valutazioni differenti.

Il passaggio più difficile non sarà tecnico

Se un approccio di questo tipo dovesse essere adottato, credo che la difficoltà principale non sarebbe costruire il questionario.

Sarebbe definire la governance delle informazioni.

Chi possiede il processo?

Chi è responsabile dei dati raccolti?

Chi verifica le risposte del vendor?

Chi approva le configurazioni?

Chi decide quando una modifica richiede una nuova valutazione?

Chi stabilisce quali funzioni devono essere coinvolte?

Chi può dichiarare che un’informazione è sufficientemente verificata?

E soprattutto, chi garantisce che il framework non diventi semplicemente un ulteriore passaggio burocratico?

Sono domande alle quali non esiste una risposta universale.

In alcune organizzazioni il coordinamento potrebbe essere affidato al Risk Management.

In altre al CISO.

In altre ancora a una funzione di Technology Governance o Enterprise Architecture.

In contesti particolarmente strutturati potrebbe essere gestito attraverso un processo condiviso di Governance, Risk & Compliance.

La scelta dipenderebbe dal modello organizzativo.

Quello che considero importante è evitare che la responsabilità della raccolta delle informazioni venga confusa con la responsabilità delle valutazioni e delle decisioni.

Una funzione può coordinare il processo.

Ma questo non significa che debba assumersi tutte le responsabilità specialistiche.

Il DPO deve mantenere il proprio ruolo.

Il Legal il proprio.

Il CISO il proprio.

Il Procurement il proprio.

La direzione aziendale le responsabilità decisionali che le competono.

Il framework dovrebbe facilitare la collaborazione, non cancellare la separazione dei ruoli.

La vera opportunità: passare dalla compliance documentale alla governance delle decisioni

C’è una differenza importante tra dimostrare di aver compilato un assessment e dimostrare di aver preso una decisione consapevole.

Nel primo caso, il risultato è un documento.

Nel secondo, il risultato è una scelta supportata da informazioni, evidenze e valutazioni.

Pensiamo ancora alla retention.

Un’organizzazione potrebbe documentare che il prodotto consente di conservare gli eventi per un anno.

Ma perché dovrebbe scegliere proprio un anno?

Quali esigenze operative giustificano quel periodo?

Quali alternative sono disponibili?

Quali rischi introduce una conservazione più lunga?

Quali rischi derivano da una conservazione troppo breve?

Quali dati devono realmente essere mantenuti?

Quali possono essere cancellati prima?

Chi ha approvato la scelta?

Come viene verificato che la configurazione effettiva corrisponda a quella approvata?

Queste domande trasformano una caratteristica tecnica in una decisione di governance.

Ed è esattamente questo il passaggio che vorrei valorizzare.

Non basta sapere che un controllo esiste.

Bisogna comprendere perché viene utilizzato, come viene configurato, quali rischi affronta e quali conseguenze introduce.

La stessa logica si applica agli accessi privilegiati.

Alle integrazioni.

Alle funzionalità AI.

Alla registrazione delle attività.

Alla gestione delle evidenze.

Alla localizzazione dei dati.

Alla continuità operativa.

E a molte altre decisioni che oggi vengono spesso prese all’interno di singoli team senza una visione completamente condivisa.

Una serie di approfondimenti, non un framework calato dall’alto

Questa riflessione nasce osservando quanto sia complesso introdurre e governare nuove tecnologie in organizzazioni che devono confrontarsi contemporaneamente con esigenze di sicurezza, privacy, resilienza, continuità operativa e conformità normativa.

Non credo che la risposta sia necessariamente inventare un nuovo standard.

Credo però che valga la pena esplorare un approccio più integrato.

E vorrei farlo attraverso una serie di approfondimenti pratici.

Non articoli che si limitino a ripetere cosa prevedono le normative.

Ma contributi che affrontino le domande operative che un CISO, un DPO, un Security Architect o un responsabile del Procurement dovrebbe porsi prima di introdurre una tecnologia.

Sto pensando, in particolare, ai seguenti argomenti.

1. Prima della DPIA: quali informazioni raccogliere davvero?

Un approfondimento dedicato alle informazioni tecniche e organizzative necessarie per comprendere i trattamenti introdotti da una tecnologia, distinguendo ciò che deve fornire il vendor da ciò che deve decidere il cliente.

2. Vendor Privacy & Technical Assessment: come costruire una base informativa comune.

Una proposta operativa per strutturare le domande, raccogliere le evidenze, attribuire responsabilità e rendere le informazioni riutilizzabili.

3. Data Retention: minimo, massimo, default e configurazione effettiva.

Perché conoscere il periodo massimo di conservazione non è sufficiente e quali domande dovrebbero essere poste prima di approvare una piattaforma.

4. Data Residency, subprocessori e trasferimenti internazionali.

Come ricostruire il ciclo di vita delle informazioni, distinguendo localizzazione dello storage, elaborazione, accessi remoti e trasferimenti.

5. Logging, audit trail e gestione delle evidenze.

Quali informazioni vengono registrate, chi può accedervi, come vengono protette e quali conseguenze derivano dalla loro conservazione.

6. Privacy by Design nelle piattaforme di Data Security.

Come utilizzare configurabilità, minimizzazione, segregazione dei ruoli e limitazione degli accessi per ridurre i rischi senza compromettere gli obiettivi di sicurezza.

7. Cybersecurity e monitoraggio dei lavoratori.

Un approfondimento sulle tecnologie che possono ricostruire le attività individuali, con particolare attenzione al contesto italiano e all’articolo 4 dello Statuto dei Lavoratori.

8. NIS2, CRA e DORA: quali informazioni possono essere condivise e quali valutazioni devono rimanere distinte.

Un’analisi delle aree di sovrapposizione e delle differenze tra i principali strumenti europei di cybersecurity e resilienza.

9. AI nelle piattaforme enterprise: cosa chiedere realmente ai fornitori.

Dati, modelli, utilizzi, supervisione umana, responsabilità, configurazioni e valutazione dei rischi.

10. Come costruire operativamente una DPIA partendo dalle informazioni raccolte.

Dalla descrizione del trattamento alla necessità e proporzionalità, fino alla valutazione dei rischi, alle misure di mitigazione e al rischio residuo.

11. Dal Vendor Assessment al Change Management.

Come mantenere aggiornate le valutazioni quando cambiano funzionalità, configurazioni, subprocessori, architetture e finalità di utilizzo.

12. Technology Governance Assessment: verso un modello operativo condiviso.

Un tentativo di riunire gli elementi emersi in un framework modulare, con domini, responsabilità, evidenze e processi di aggiornamento.

L’ordine non è definitivo.

E, soprattutto, non vorrei definirlo senza confrontarmi con chi affronta quotidianamente questi problemi.

Una domanda alla community

Mi interessa capire quanto questa situazione sia comune.

Nelle vostre organizzazioni, quando viene introdotta una nuova tecnologia, esiste una base informativa condivisa tra Security, Privacy, Legal, Procurement, HR, Risk Management e Compliance?

Oppure ogni funzione conduce il proprio assessment, richiedendo informazioni che altre funzioni hanno già raccolto?

E ancora.

Se doveste progettare un Technology Governance Assessment, quali informazioni considerereste indispensabili?

Quali domini dovrebbero essere affrontati per primi?

Quali verifiche vengono oggi duplicate più frequentemente?

Quali informazioni risultano più difficili da ottenere dai vendor?

E quali sono le lacune che emergono più spesso quando una tecnologia è già stata acquistata e bisogna finalmente metterla in produzione?

Mi piacerebbe utilizzare il confronto per sviluppare progressivamente un modello che possa essere utile nella pratica, non soltanto sulla carta.

Perché credo che il punto centrale sia proprio questo.

La crescente centralità della valutazione del rischio nel quadro normativo europeo dovrebbe portarci a riflettere anche sul modo in cui raccogliamo, condividiamo e manteniamo le informazioni necessarie per valutare quel rischio.

Non abbiamo necessariamente bisogno di meno valutazioni.

Abbiamo bisogno di valutazioni meglio informate.

Non abbiamo necessariamente bisogno di meno controlli.

Abbiamo bisogno di controlli più coerenti.

E probabilmente non abbiamo bisogno dell’ennesimo questionario.

Abbiamo bisogno di sapere quali domande sono già state poste, quali risposte sono state verificate e quali decisioni sono state prese sulla base di quelle informazioni.

Perché, alla fine, la governance non consiste nel dimostrare che qualcuno ha compilato un documento.

Consiste nel poter spiegare perché una determinata tecnologia è stata introdotta, come è stata configurata, quali rischi sono stati considerati e chi ha assunto le decisioni.

E magari riuscire a farlo senza chiedere per la sesta volta al vendor quanto tempo conserva i log.

Ma questa è un’altra storia.

O forse è proprio il punto da cui dovremmo iniziare.

Voi da quale argomento partireste?

E soprattutto: cosa manca, secondo voi, a questo possibile framework?

Mi interessa davvero confrontarmi con CISO, DPO, Security Architect, Legal, Procurement, Risk Manager e professionisti della Compliance.

Perché un modello di governance che vuole superare i silos dovrebbe, quantomeno, evitare di essere progettato all’interno di uno solo di essi.