Sovranità dei dati nell'UE: chiedersi chi può accedere alle evidenze

Le evidenze di compliance possono rivelare l'architettura, debolezze non risolte, informazioni sul personale, dipendenze dai fornitori e la cronologia degli incidenti. Scegliere dove conservarle merita la stessa attenzione che si dedica a scegliere dove conservare i dati dei clienti. In alcuni casi, un archivio di evidenze offre un quadro dell'azienda più concentrato di qualsiasi singolo sistema di produzione.

Per il vertice aziendale, la sovranità dei dati nell'UE è quindi una questione di acquisto e di responsabilità: chi può accedere a queste informazioni, sotto quale autorità, e che cosa succede se dobbiamo andarcene?

Una regione di hosting europea è un'informazione utile. Non è una risposta completa. La decisione deve coprire la catena del servizio, l'esposizione giuridica, l'accesso tecnico e la capacità di conservare registri utilizzabili al di fuori della piattaforma.

Partire dalle informazioni che si affidano

Una piattaforma di compliance può contenere schemi di rete, revisioni degli accessi, report sulle vulnerabilità, inventari dei trattamenti, valutazioni del rischio e indagini sugli incidenti. Nel loro insieme, questi registri descrivono sia come opera l'organizzazione sia dove le sue difese devono essere migliorate.

Contengono inoltre tipi diversi di sensibilità. Una revisione degli accessi dei dipendenti riguarda dati personali. Un report di penetration test può rivelare debolezze sfruttabili. Una decisione della direzione può registrare una dipendenza commerciale o un rischio accettato. Queste categorie richiedono un trattamento diverso anche quando si trovano nello stesso spazio di lavoro.

Prima di confrontare i fornitori, create un piccolo inventario delle evidenze. Per ogni categoria, registrate finalità, sensibilità, responsabile, destinatari previsti, requisito di conservazione e se il documento originale debba davvero essere caricato.

Ad esempio, il riesame di un controllo può richiedere la prova che la correzione è stata completata, non il report tecnico completo che descrive ogni vulnerabilità. Un estratto oscurato può talvolta dimostrare il fatto richiesto riducendo l'esposizione. L'oscuramento non deve però eliminare il contesto necessario per valutare l'evidenza.

Si tratta di una raccomandazione pratica, non di un obbligo universale di sostituire gli originali con sintesi. L'obiettivo è rendere consapevole la gestione delle evidenze, invece di lasciare che ogni richiesta di audit amplii indefinitamente l'archivio.

Separare residenza, controllo e conformità normativa

La residenza dei dati riguarda il luogo. La sovranità riguarda anche controllo, accesso, esposizione giuridica e capacità di trasferire o continuare a usare le informazioni. Nessuno dei due termini dovrebbe essere trattato come un certificato di conformità.

Queste dimensioni interagiscono, ma non sono intercambiabili. Un servizio ospitato nell'UE può coinvolgere personale di supporto o trattamenti al di fuori dell'UE. Un fornitore di proprietà europea può dipendere da infrastrutture, monitoraggio o servizi di IA gestiti da altre entità. La sola proprietà non dimostra che ogni percorso di accesso sia accettabile.

Allo stesso modo, l'esposizione a un'altra giurisdizione non significa che la divulgazione sia inevitabile né che il servizio sia automaticamente illecito. Valutate le entità coinvolte, il diritto applicabile, l'accesso effettivo e le garanzie. Quando la divulgazione obbligatoria è rilevante per la decisione, chiedete un parere legale invece di affidarvi a un'etichetta di nazionalità o a una rassicurazione commerciale.

Capire quali norme si applicano davvero

Il GDPR non impone una regola generale secondo cui tutti i dati personali debbano restare nell'UE. Richiede un'adeguata base giuridica e un trattamento conforme, comprese la sicurezza, i rapporti con i responsabili del trattamento e, ove applicabili, i requisiti sui trasferimenti internazionali.

Per un archivio di compliance che contiene dati personali, determinate i ruoli delle parti ed esaminate le clausole sul trattamento previste dall'articolo 28 quando esiste un rapporto con un responsabile del trattamento. Valutate separatamente i meccanismi di trasferimento del capo V. Firmare un accordo sul trattamento non risolve la questione dei trasferimenti, e scegliere una regione di archiviazione nell'UE non elimina la necessità di esaminare gli accessi dall'estero o i trattamenti successivi.

L'articolo 32 richiede una sicurezza adeguata al rischio. La cifratura può essere una misura importante, ma il GDPR non prescrive un'unica architettura di cifratura generalizzata per ogni archivio. L'articolo 48 riguarda inoltre le sentenze o decisioni amministrative di paesi terzi che dispongono un trasferimento o una comunicazione; non va letto come uno scudo universale contro l'accesso straniero.

Altri obblighi dipendono dall'organizzazione. La NIS2, attuata tramite il diritto nazionale, prevede la supervisione degli organi di gestione e misure di sicurezza della catena di approvvigionamento per i soggetti che rientrano nell'ambito di applicazione. Il DORA stabilisce obblighi sul rischio derivante da terzi fornitori di servizi ICT per le entità finanziarie coperte. Nessuno dei due dovrebbe essere ridotto a un'istruzione generica ad acquistare software europeo.

Anche le politiche europee sulla sovranità e le discussioni sugli appalti richiedono un'interpretazione attenta. Separate gli obblighi già in vigore da proposte, dichiarazioni politiche, criteri di appalto e schemi di certificazione. I requisiti di Francia e Germania non dovrebbero essere trattati come intercambiabili né come automaticamente applicabili a ogni impresa privata in Europa.

Chiedete ai legali e all'ufficio acquisti di documentare gli specifici requisiti nazionali, settoriali e dei clienti che incidono sul vostro acquisto. Un report di garanzia sul cloud può contribuire alle evidenze, ma non risolve la questione della sovranità. Ad esempio, il catalogo C5 del BSI riguarda controlli e attestazione per il cloud; non è una certificazione generale di sovranità.

Mappare l'intera catena del servizio

Il documento di acquisto più utile è una mappa della gestione delle evidenze. Mostra come le informazioni entrano nel servizio, quali sistemi le elaborano, chi può accedervi e come ne escono.

Chiedete risposte per storage di produzione, repliche, backup, disaster recovery, log applicativi, monitoraggio, ticket di supporto e copie temporanee per la risoluzione dei problemi. Includete esportazioni e notifiche e-mail: un rilievo sensibile può uscire dal perimetro previsto tramite una notifica anche quando il relativo allegato resta all'interno della piattaforma.

Per ogni componente, registrate:

• L'entità che lo gestisce e il suo ruolo.
• Le categorie di dati che riceve e la finalità del trattamento.
• I luoghi di archiviazione e di trattamento, compresi quelli da cui avviene l'accesso remoto.
• I gruppi autorizzati ad accedere ed eventuali ulteriori fornitori coinvolti.
• Conservazione, cancellazione e trattamento dei backup.
• Le condizioni contrattuali che disciplinano l'attività.

Distinguete il fornitore di infrastruttura di un provider da un fornitore di supporto o da un responsabile del trattamento per l'IA. Le loro funzioni e i loro accessi possono differire in modo sostanziale. Un elenco di loghi di fornitori non sostituisce questa mappa.

Esaminate anche la gestione delle modifiche. Come verrete a sapere di un nuovo sub-responsabile, di un luogo di trattamento modificato o di una revisione delle modalità di supporto? Quali diritti di riesame o di opposizione esistono, e che cosa accade se la modifica proposta è in contrasto con i vostri requisiti? Una valutazione soddisfacente oggi richiede un meccanismo per rilevare i cambiamenti domani.

Trattare l'elaborazione tramite IA come un percorso di divulgazione distinto

La revisione delle evidenze assistita dall'IA può introdurre un ulteriore provider e un'ulteriore policy di conservazione. Una funzionalità che riassume un report di incidente può trasmettere il report, il testo estratto, i prompt, i metadati o informazioni diagnostiche al di là dell'applicazione principale.

Chiedete che cosa raggiunge il provider di IA, per quale finalità e a quali condizioni contrattuali. Verificate nell'accordo vigente l'uso per l'addestramento dei modelli, la conservazione, l'accesso da parte di persone, i luoghi di trattamento e i trattamenti successivi. Non date per scontato che un account enterprise o una dichiarazione di "nessun addestramento" significhino anche nessuna conservazione o nessun accesso del supporto.

Chiarite se le funzioni di IA sono facoltative e se è possibile applicare restrizioni al materiale sensibile. Se la piattaforma non è in grado di far rispettare il confine richiesto, un'istruzione interna a non caricare documenti riservati può risultare troppo fragile per l'uso quotidiano.

Un riesame pratico dovrebbe seguire un documento rappresentativo attraverso la funzionalità. Identificate la fonte, il contenuto trasmesso, l'output, i registri conservati e i revisori. Le sintesi generate possono contenere esse stesse informazioni sensibili, quindi rientrano nella mappa della gestione.

La revisione umana resta necessaria per le conclusioni sulle evidenze. È una garanzia distinta dalle restrizioni sul trattamento: approvare una sintesi generata dall'IA non autorizza retroattivamente una divulgazione inaccettabile della sua fonte.

Chiedersi chi può davvero decifrare e amministrare

La cifratura protegge le informazioni solo entro i limiti della sua progettazione e del suo funzionamento. La cifratura in transito protegge le connessioni; la cifratura a riposo protegge i dati archiviati in base a determinate ipotesi di minaccia. Nessuna delle due impedisce automaticamente a un'applicazione autorizzata o a un operatore privilegiato di leggerne il contenuto.

Chiedete chi controlla le chiavi, chi può avviare la decifratura e se gli amministratori possono modificare le autorizzazioni che regolano tale accesso. Un sistema con chiavi gestite dal cliente può migliorare il controllo, ma il suo effetto dipende dall'architettura. Se il servizio riceve abitualmente dati in chiaro, la sola titolarità delle chiavi non elimina l'accesso del provider.

Fate esaminare al team tecnico la separazione delle chiavi, la rotazione, la revoca, il ripristino e le conseguenze della perdita di una chiave. Il vertice dovrebbe comprendere qualsiasi compromesso in termini di disponibilità prima di approvarlo. Un confine di accesso più rigoroso che renda però irrecuperabili evidenze essenziali non è una soluzione di continuità completa.

L'accesso del supporto merita particolare attenzione. Cercate identità nominative, privilegi limitati, autorizzazioni a tempo, approvazione del cliente ove opportuno e azioni verificabili. Chiedete come funziona l'accesso di emergenza e come viene riesaminato in seguito.

La domanda in fase di acquisto non è semplicemente se l'accesso venga registrato. È se l'organizzazione possa ottenere informazioni sufficienti per indagare su un evento: chi ha avuto accesso a quali record, quando, per quale motivo e con quale autorizzazione. Concordate quali evidenze saranno disponibili prima che un incidente renda la questione urgente.

Rendere la portabilità un requisito testato

La portabilità fa parte della sovranità, perché il controllo si indebolisce quando andarsene significa perdere il significato delle evidenze.

Testate un'esportazione rappresentativa prima di impegnarvi. I soli file possono non preservare le relazioni tra controlli, evidenze, rilievi, responsabili, approvazioni e decisioni. Una cartella di PDF può conservare i documenti perdendo però traccia di che cosa dimostravano e di chi ha accettato la conclusione.

Scegliete un campione che contenga un allegato, il controllo collegato, un commento di revisione, un'approvazione, un rilievo aperto e le relative marcature temporali. Chiedete a qualcuno esterno al team di implementazione di ricostruire la decisione a partire dall'esportazione. In questo modo si verifica l'usabilità e non la semplice esistenza di un pulsante di esportazione.

OSCAL offre modelli utili per informazioni di sicurezza portabili. Le sue specifiche pubblicate possono supportare uno scambio strutturato, ma l'uso di un formato aperto non garantisce automaticamente completezza o compatibilità. Verificate versioni dei modelli, identificativi, allegati, estensioni e se il sistema ricevente sia in grado di interpretare la struttura esportata.

Accanto ai formati contano le condizioni contrattuali di uscita. Stabilite quando sono disponibili le esportazioni, quale assistenza viene fornita, se sono previsti costi e per quanto tempo l'accesso prosegue dopo la cessazione. Trattate separatamente la cancellazione dei record attivi e il trattamento delle copie di backup.

Esempio pratico: decidere che cosa può entrare in un archivio

Consideriamo, a titolo illustrativo, un'azienda software con sede nell'UE che sta scegliendo una piattaforma per le evidenze. Supponiamo che il perimetro iniziale comprenda revisioni degli accessi dei dipendenti, risultanze oscurate dei test di sicurezza e registri delle decisioni sugli incidenti. La sua policy interna richiede l'archiviazione nell'UE per questo perimetro e una valutazione esplicita di qualsiasi accesso da fuori dell'UE. Si tratta di ipotesi di esempio, non di requisiti giuridici universali.

Il fornitore conferma che lo storage di produzione si trova nell'UE. Un ulteriore riesame individua un servizio separato per i ticket di supporto e un provider facoltativo per le sintesi tramite IA. Il team non dichiara la piattaforma accettabile o inaccettabile sulla sola base della risposta sull'hosting.

Documenta invece tre decisioni:

Il team verifica poi se allegati sensibili finiscono nei ticket di supporto, controlla le restrizioni di accesso proposte ed esporta un registro di riesame completo.

Supponiamo che le condizioni per l'elaborazione tramite IA restino poco chiare. Il vertice può approvare un'introduzione più limitata solo se l'esclusione da tale elaborazione è affidabile. Se non può essere garantita, il materiale interessato resta fuori dall'introduzione. La questione aperta riceve un responsabile e una scadenza per la decisione, invece di sparire in un punteggio generico di rischio del fornitore.

Il deliverable è un'approvazione circoscritta: categorie di evidenze definite, trattamenti consentiti, restrizioni, questioni aperte ed eventi che fanno scattare un riesame. È più utile di una dichiarazione incondizionata che il fornitore sia "sovrano".

Affidare la decisione alla responsabilità del vertice

L'ufficio acquisti può raccogliere i documenti, la sicurezza può valutare i controlli degli accessi e l'ufficio legale può valutare gli obblighi. Il vertice è titolare della decisione di business su quale esposizione e quale dipendenza siano accettabili. Quando è coinvolto un DPO, preservate le sue responsabilità indipendenti di consulenza e sorveglianza, invece di renderlo titolare delle decisioni sul trattamento.

Utilizzate criteri di accettazione espliciti. Accessi privilegiati poco chiari, luoghi di trattamento non spiegati o un percorso di uscita inutilizzabile possono essere motivi di esclusione per un perimetro sensibile. Altre lacune possono consentire un deployment limitato con condizioni documentate. Registrate chi può accettare ciascun rischio residuo e che cosa imporrebbe una nuova valutazione.

Gli errori comuni sono accettare "ospitato nell'UE" senza una mappa della catena del servizio, considerare la cifratura come prova che nessun altro possa leggere i dati e rinviare il test di esportazione fino alla cessazione del contratto. Un altro è presumere che una certificazione o un report di audit copra esattamente il servizio, il percorso di trattamento e le categorie di evidenze che si stanno acquistando. Verificatene perimetro e limiti.

Trasformare la valutazione in un flusso di lavoro ripetibile

Secani collega le evidenze a requisiti, controlli, oggetti di riferimento e decisioni riesaminate, utilizzando modelli aperti per i controlli di sicurezza come fondamento del prodotto. Un flusso di lavoro circoscritto può partire da un servizio, da responsabili nominati, dalle sue dipendenze da provider esterni e dai documenti che supportano la decisione di acquisto. Le risposte mancanti diventano attività; i suggerimenti generati con l'aiuto dell'IA restano bozze soggette a revisione umana e a tracciabilità delle fonti.

Conservate le modalità di hosting, trattamento, accesso ed esportazione del servizio scelto insieme alla decisione di acquisto. Riesaminate tale registro quando cambiano configurazioni, sub-responsabili o condizioni contrattuali. Così il revisore successivo avrà una base chiara per verificare se l'assetto soddisfa ancora i requisiti dell'organizzazione.

Il passo successivo concreto è scegliere una categoria di evidenze sensibili e ricostruirne l'intero percorso. Portate alla decisione di acquisto la mappa risultante, un'esportazione testata e le questioni di accesso ancora aperte. In questo modo il vertice dispone di una base verificabile per decidere chi può custodire le evidenze, e a quali condizioni.