GDPR e sicurezza: collegare le misure di protezione al trattamento

Un sistema di gestione della sicurezza delle informazioni ben condotto mette a disposizione processi utili per il GDPR: gestione degli accessi, gestione degli incidenti, valutazione dei fornitori e resilienza. Il lavoro sulla protezione dei dati si chiede però anche perché un trattamento sia lecito, proporzionato e trasparente. Queste domande si incontrano nella stessa attività aziendale, ma richiedono decisioni diverse.

Per il vertice aziendale, il compito è collegarle senza considerare l'una un sostituto dell'altra. Un database clienti sicuro può comunque contenere informazioni che l'azienda non avrebbe dovuto raccogliere. Un contratto valido con il cliente non dimostra che chiunque abbia accesso a quel database ne abbia bisogno. Un certificato ISO 27001 non risolve nessuna delle due questioni.

Il punto di partenza pratico è quindi il trattamento, non un catalogo di controlli. Occorre individuare che cosa l'azienda vuole fare con i dati personali, valutare se quell'attività sia ammissibile e poi scegliere le misure di protezione in funzione delle conseguenze di un eventuale fallimento. Vanno conservati il ragionamento, le evidenze, il responsabile incaricato e il prossimo evento che dovrà far scattare un riesame.

Stabilire quali trattamenti e responsabilità rientrano nel perimetro

Il Regolamento generale sulla protezione dei dati disciplina il trattamento dei dati personali. Il trattamento comprende raccolta, conservazione, consultazione, comunicazione, modifica e cancellazione. Il dato personale è qualsiasi informazione riguardante una persona fisica identificata o identificabile; non si limita ai nomi o ai dati palesemente sensibili.

Indirizzi e-mail aziendali, identificativi dei dipendenti, identificativi dei dispositivi, cronologie di localizzazione e conversazioni di assistenza possono essere tutti dati personali. Se un determinato identificativo lo sia dipende dal contesto e dai mezzi di cui si può ragionevolmente prevedere l'utilizzo per identificare una persona. Sostituire i nomi con numeri di riferimento produce normalmente dati pseudonimizzati, non anonimi, quando la reidentificazione resta possibile. I dati personali pseudonimizzati rimangono nell'ambito di applicazione del GDPR.

Verificare l'ambito territoriale prima di scegliere un modello operativo

L'articolo 3 copre il trattamento effettuato nell'ambito delle attività di uno stabilimento nell'UE, anche quando il trattamento in sé avviene altrove. Può riguardare anche un'organizzazione stabilita fuori dall'UE quando il suo trattamento riguarda l'offerta di beni o servizi a persone nell'Unione o il monitoraggio del loro comportamento nell'Unione. La sola accessibilità di un sito web non risolve la questione del targeting; va valutata l'effettiva attività di offerta e di monitoraggio.

Quando si applica l'articolo 3, paragrafo 2, l'articolo 27 può richiedere la designazione di un rappresentante nell'Unione. Le relative esenzioni sono limitate e non dipendono semplicemente dalle dimensioni dell'azienda. Anche l'esenzione per il trattamento occasionale richiede il rispetto delle condizioni previste in materia di dati sensibili e di rischio. Un rappresentante non sostituisce il titolare del trattamento, un DPO né una direzione responsabile.

Il GDPR è entrato in vigore il 24 maggio 2016 e si applica dal 25 maggio 2018. Per le decisioni attuali, occorre distinguere il diritto vigente dalle semplificazioni proposte. Un comunicato stampa su una possibile esenzione non è una base per interrompere un processo di conformità già in corso.

Determinare i ruoli in base all'attività, non all'etichetta aziendale

Il titolare del trattamento determina le finalità e i mezzi del trattamento. Il responsabile del trattamento tratta dati personali per conto del titolare. I contitolari determinano congiuntamente finalità e mezzi e necessitano di un accordo ai sensi dell'articolo 26 che rifletta le rispettive responsabilità.

Una stessa azienda può ricoprire più ruoli. Un fornitore di software può essere responsabile del trattamento per i dati caricati dai clienti e titolare per le proprie buste paga, per l'amministrazione degli account e per alcune attività di sicurezza. L'etichetta contrattuale scelta da un fornitore è rilevante, ma non può prevalere su ciò che le parti fanno effettivamente.

Il primo deliverable dovrebbe essere una breve decisione sul perimetro: attività interessate, entità organizzative, ruoli di titolare o responsabile, mercati e questioni aperte. Assegnate un responsabile che risolva le incertezze prima che il trattamento collegato inizi o si estenda.

Separare la finalità aziendale dalla base giuridica

Gli articoli 5 e 6 costituiscono il fondamento del trattamento ordinario dei dati personali. La sicurezza è una parte di questo fondamento, non una scorciatoia per aggirarlo.

I principi dell'articolo 5 vengono comunemente presentati come sette: liceità, correttezza e trasparenza; limitazione della finalità; minimizzazione dei dati; esattezza; limitazione della conservazione; integrità e riservatezza; responsabilizzazione. La responsabilizzazione impone al titolare di essere competente per il rispetto delle norme e di essere in grado di comprovarlo. Non richiede un particolare prodotto software, ma richiede una motivazione difendibile, supportata da evidenze adeguate.

Ogni principio va tradotto in una domanda di business:

Scegliere una base per ciascuna finalità

L'articolo 6 prevede sei basi giuridiche. Le loro condizioni contano più delle loro etichette:

• Consenso: una manifestazione di volontà libera, specifica, informata e inequivocabile, con possibilità di revoca.
• Contratto: trattamento necessario all'esecuzione di un contratto con l'interessato o all'esecuzione di misure precontrattuali adottate su sua richiesta.
• Obbligo legale: trattamento necessario per adempiere un obbligo legale applicabile.
• Interessi vitali: trattamento necessario per la salvaguardia degli interessi vitali di una persona.
• Compito di interesse pubblico: trattamento necessario per l'esecuzione di un compito di interesse pubblico o connesso all'esercizio di pubblici poteri, con il necessario fondamento giuridico.
• Legittimo interesse: trattamento necessario per il perseguimento di legittimi interessi, previo bilanciamento di tali interessi con gli interessi, i diritti e le libertà dell'interessato.

Non elencate più basi come se fossero un'assicurazione intercambiabile. Stabilite la base che sostiene effettivamente ciascuna finalità e comunicatela con precisione. Aggiungere una clausola al contratto con il cliente non rende automaticamente il trattamento necessario all'esecuzione di quel contratto. Allo stesso modo, il legittimo interesse richiede una valutazione; non è un'autorizzazione generale a usare i dati disponibili.

Come raccomandazione pratica, documentate una valutazione del legittimo interesse che consideri l'interesse perseguito, la necessità, gli effetti sulle persone, le loro ragionevoli aspettative e le garanzie. Considerate alternative meno invasive. Mantenete l'analisi proporzionata all'attività, ma abbastanza specifica da risultare comprensibile a chi è esterno al progetto.

Il consenso non è sempre la scelta più sicura. Deve essere realmente facoltativo laddove le circostanze richiedano una scelta, e la revoca deve funzionare nella pratica. I rapporti di lavoro sollevano particolari dubbi sulla libertà del consenso. La revoca pone fine per il futuro al trattamento basato su quel consenso; non cancella automaticamente i dati soggetti a distinti obblighi legali di conservazione. Non spostate retroattivamente lo stesso trattamento su un'altra base solo perché il consenso è stato revocato. Ogni trattamento distinto, come la conservazione imposta dalla legge, necessita di una propria base applicabile e di una trasparenza adeguata.

I dati appartenenti a categorie particolari, come le informazioni sulla salute, richiedono una condizione dell'articolo 9 oltre a una base dell'articolo 6. I dati relativi a condanne penali e reati sono soggetti ai requisiti distinti dell'articolo 10. Un'azienda non dovrebbe approvare nessuna di queste categorie solo perché il trattamento ordinario dei dati dei clienti è già stato valutato.

Costruire un registro dei trattamenti che guidi le decisioni

Il registro delle attività di trattamento previsto dall'articolo 30 è utile perché collega l'analisi giuridica alla realtà operativa. Il registro del titolare comprende finalità, categorie di interessati e di dati, destinatari, trasferimenti, ove possibile i termini previsti per la cancellazione e, ove possibile, una descrizione generale delle misure di sicurezza. I responsabili del trattamento hanno un obbligo di registro diverso, che riguarda i trattamenti svolti per conto dei titolari.

L'esenzione per le organizzazioni con meno di 250 dipendenti è condizionata. Non copre il trattamento non occasionale, quello che può presentare il rischio indicato o quello che include le categorie sensibili previste. Una piccola impresa con trattamenti continuativi di dati di dipendenti o clienti non dovrebbe presumere che il numero di addetti la esoneri dagli obblighi di registro.

Usate le attività di trattamento come unità organizzativa. "Infrastruttura cloud" è di solito troppo generico per spiegare perché i dati vengono trattati. "Gestione delle richieste di assistenza clienti" è più utile, perché ha una finalità, persone identificabili, categorie di dati, destinatari, regole di conservazione e sistemi di supporto.

Un registro di lavoro pratico può andare oltre i campi previsti dalla legge:

• Responsabile di business e revisore privacy.
• Finalità e base giuridica pertinente.
• Fonti dei dati, categorie e gruppi interessati.
• Rapporti di titolarità, responsabilità o contitolarità.
• Applicazioni, esportazioni, log e destinatari a valle.
• Regole di conservazione e modalità di esecuzione della cancellazione.
• Riferimenti a informative, gestione dei diritti, fornitori e trasferimenti.
• Esito dello screening DPIA e misure di protezione collegate.
• Data di approvazione, azioni aperte ed eventi che fanno scattare il riesame.

I campi aggiuntivi sono una raccomandazione per il coordinamento, non l'affermazione che l'articolo 30 richieda espressamente ogni voce. Il loro valore sta nel rendere il registro utilizzabile durante un lancio, una richiesta di accesso, un cambio di fornitore o un incidente.

Allineare il registro ai sistemi che le persone usano davvero

È improbabile che un questionario annuale faccia emergere ogni esportazione in un foglio di calcolo, ogni applicazione in prova o ogni abbonamento a strumenti di IA sottoscritto da un singolo team. Confrontate il registro con le informazioni degli acquisti, gli elenchi delle applicazioni approvate, gli inventari dei sistemi e le interviste con i responsabili dei processi. Esaminate le cartelle condivise e i passaggi manuali quando incidono in modo significativo sull'attività.

Non confondete un inventario degli asset con un registro dei trattamenti. L'inventario degli asset descrive sistemi e dipendenze; il registro dei trattamenti descrive gli usi dei dati personali. Collegateli in modo che un'applicazione possa supportare più finalità senza fonderle in una descrizione indistinta.

Per un ulteriore contesto operativo, consultate data discovery e privacy. La discovery dovrebbe produrre un elenco verificabile di discrepanze, non il presupposto che ogni campo rilevato sia stato classificato correttamente o valutato sotto il profilo giuridico.

Tradurre l'articolo 32 in misure di protezione per conseguenze reali

L'articolo 32 del GDPR impone a titolari e responsabili del trattamento di mettere in atto misure tecniche e organizzative adeguate al rischio. La valutazione tiene conto dello stato dell'arte, dei costi di attuazione, della natura, dell'oggetto, del contesto e delle finalità del trattamento, nonché della probabilità e della gravità dei rischi per i diritti e le libertà delle persone.

Le conseguenze rilevanti comprendono distruzione, perdita, modifica accidentali o illecite, divulgazione non autorizzata e accesso non autorizzato. Ciò rende disponibilità e integrità importanti quanto la riservatezza. Perdere l'accesso a un servizio può danneggiare le persone anche quando nessun dato è stato sottratto.

Una dichiarazione generica secondo cui "si applicano misure di sicurezza conformi agli standard di settore" non basta a spiegare perché le misure siano adatte a una determinata attività. Partite da scenari: chi potrebbe essere coinvolto, che cosa potrebbe accadere, con quale probabilità e con quale gravità. Poi collegate ogni scenario importante a misure preventive, di rilevamento e di ripristino.

Le restrizioni di accesso devono seguire la finalità

Per un'attività di assistenza, chiedetevi quali operatori abbiano bisogno di quali dati dei clienti, se gli allegati sensibili richiedano restrizioni separate e quando gli accessi temporanei debbano scadere. Considerate l'amministrazione privilegiata, l'accesso di supporto dei fornitori, le esportazioni massive, gli account condivisi e gli accessi di emergenza.

Tra le evidenze utili rientrano le definizioni dei ruoli, le approvazioni degli accessi, i registri di ingressi, cambi di ruolo e uscite del personale, le modalità di gestione degli accessi privilegiati e le revisioni degli accessi completate. Una policy sugli accessi dimostra una regola prevista. Una revisione recente che mostra la rimozione di autorizzazioni non necessarie dimostra che la regola viene applicata.

Il vertice dovrebbe chiedersi se l'organizzazione sia in grado di distinguere l'accesso autorizzato dall'uso appropriato. Un dipendente può avere un account tecnicamente valido e usare comunque i dati per una finalità non autorizzata. Formazione, supervisione, progettazione degli accessi e processi di indagine contano tutti.

La cifratura richiede una decisione di implementazione

L'articolo 32 indica la cifratura e la pseudonimizzazione tra le misure da considerare; non impone un obbligo generalizzato di cifratura per ogni situazione. Quando si sceglie la cifratura, occorre specificare che cosa protegge e che cosa no.

La cifratura in transito protegge i dati che viaggiano tra endpoint quando i protocolli e l'autenticazione degli endpoint sono configurati correttamente. La cifratura a riposo protegge i dati archiviati in determinati scenari di minaccia. Nessuna delle due impedisce automaticamente a un'applicazione o a un amministratore autorizzati di vedere i dati in chiaro.

Verificate chi controlla le chiavi, come è separato l'accesso a esse e come vengono generate, ruotate, revocate, sottoposte a backup e ripristinate. La cifratura gestita dal provider può essere adeguata per alcuni rischi e lasciarne altri irrisolti. Una cifratura le cui chiavi sono accessibili allo stesso attore compromesso potrebbe non coprire lo scenario oggetto di valutazione.

La decisione del vertice non riguarda quale algoritmo implementare personalmente. Riguarda se la progettazione affronta il rischio pertinente e se il responsabile tecnico è in grado di motivare tale conclusione. Consultate cifratura e gestione delle chiavi per le distinzioni a livello di controllo.

La resilienza va dimostrata, non presunta

L'articolo 32 riguarda la riservatezza, l'integrità, la disponibilità e la resilienza permanenti, insieme alla capacità di ripristinare tempestivamente la disponibilità e l'accesso dopo un incidente. Un job di backup andato a buon fine non dimostra che l'azienda sia in grado di ripristinare un servizio utilizzabile.

Definite le aspettative di ripristino in base al trattamento e alle conseguenze di un'interruzione. Testate il ripristino, le dipendenze, le credenziali e la gestione dei dati personali negli ambienti ripristinati. Conservate evidenze di che cosa è stato ripristinato, quanto tempo ha richiesto, che cosa non ha funzionato e che cosa è stato corretto. Anche le regole di conservazione e cancellazione devono tenere conto del comportamento dei backup.

Verificare l'efficacia con evidenze pertinenti

L'articolo 32 prevede una procedura per testare, verificare e valutare regolarmente le misure. Il metodo adeguato dipende dal controllo: revisioni degli accessi, esercitazioni di ripristino, verifiche di configurazione, valutazioni delle vulnerabilità, riesami dei fornitori ed esercitazioni sugli incidenti possono contribuire tutti.

Un penetration test può essere utile, ma non sostituisce in assoluto queste attività né costituisce un obbligo generale del GDPR. Registrate il perimetro testato e i limiti del test. Il test di un'applicazione non dimostra che un'esportazione di marketing appena introdotta, una connessione con un fornitore o un processo di ripristino siano adeguatamente controllati.

Per ogni misura di protezione rilevante, conservate un responsabile, una descrizione dell'implementazione, le evidenze pertinenti, la data della valutazione e l'evento che farà scattare il prossimo riesame. Si tratta di una struttura pratica per le evidenze, non di un modello prescritto dall'articolo 32.

Riutilizzare il SGSI senza fondere le conclusioni di sicurezza e privacy

ISO/IEC 27001 riguarda un sistema di gestione della sicurezza delle informazioni con un perimetro definito. La valutazione del rischio, il trattamento del rischio, i processi operativi, l'audit interno e il riesame della direzione possono supportare la gestione delle misure di protezione richieste dal GDPR.

La sovrapposizione è preziosa. Spesso non occorre ricreare per la privacy le evidenze sulla gestione degli accessi, le valutazioni dei fornitori, le esercitazioni sugli incidenti e i test di ripristino. La loro pertinenza va però verificata rispetto all'attività di trattamento e al perimetro attuale.

La certificazione rilasciata da un organismo di certificazione indipendente riguarda il perimetro dichiarato del SGSI. Non copre automaticamente ogni prodotto, entità, fornitore o attività di trattamento. La Dichiarazione di Applicabilità registra l'applicabilità dei controlli e le decisioni di trattamento; non è una dichiarazione che ogni obbligo GDPR sia stato soddisfatto.

ISO 27001 non è nemmeno, di per sé, un regime normativo generale di notifica delle violazioni. Gli obblighi di notifica del GDPR vanno valutati separatamente. Viceversa, essere conformi al GDPR non dimostra che un'organizzazione abbia attuato tutti i requisiti necessari per la certificazione ISO 27001.

Il GDPR prevede meccanismi di certificazione agli articoli 42 e 43. Tale certificazione non riduce la responsabilità del titolare o del responsabile del trattamento e non equivale a un certificato ISO 27001 né a una dichiarazione universale di conformità normativa.

La questione gestionale è quindi riutilizzare le evidenze mantenendo conclusioni separate: che cosa dimostra questo elemento, per quali sistemi e per quale periodo, e quali domande sulla privacy restano senza risposta?

Attribuire responsabilità distinte a direzione, sicurezza e privacy

Un modello operativo funzionante richiede più di una casella di posta condivisa per la compliance. I responsabili di business dovrebbero descrivere e giustificare i propri trattamenti; la sicurezza dovrebbe valutare e attuare le misure di protezione pertinenti; gli specialisti privacy dovrebbero fornire consulenza su requisiti giuridici, diritti, informative e valutazioni. La direzione deve mettere a disposizione le risorse e risolvere le decisioni rilevanti nel rispetto della legge.

Un DPO non è automaticamente obbligatorio per ogni azienda. L'articolo 37 include le autorità pubbliche e gli organismi pubblici, fatta salva l'eccezione per le autorità giurisdizionali, e le organizzazioni le cui attività principali soddisfano le condizioni previste di monitoraggio su larga scala o di trattamento di dati sensibili. Il diritto nazionale può aggiungere requisiti, quindi verificate le giurisdizioni pertinenti.

Quando è designato, il DPO ha compiti indipendenti di consulenza e sorveglianza, deve essere coinvolto in modo adeguato e tempestivo e riferisce direttamente al vertice gerarchico. Al DPO non dovrebbero essere impartite istruzioni per giungere a una conclusione gradita né essere assegnate responsabilità in conflitto che determinino finalità e mezzi del trattamento.

Non fate del DPO il responsabile di ogni controllo, colui che approva ogni finalità di business e allo stesso tempo la persona che verifica quelle stesse decisioni. Ciò concentra responsabilità incompatibili e può indurre i team operativi a credere che la responsabilità sia stata trasferita altrove.

Un registro di approvazione utile identifica il responsabile proponente, la consulenza specialistica, le evidenze considerate, chi decide, le condizioni e le azioni aperte. Se la direzione sceglie un approccio lecito diverso da quello raccomandato, registratene la motivazione. La direzione non può trasformare una base giuridica mancante o una clausola contrattuale obbligatoria assente in conformità etichettandola come "rischio accettato".

La guida alle responsabilità di CISO e DPO spiega più in dettaglio il confine delle responsabilità. Per il CEO, la domanda chiave di supervisione è se i disaccordi arrivino a qualcuno in grado di modificare il trattamento, finanziare la misura di protezione o fermare la proposta, e non soltanto di approvare un documento.

Valutare i fornitori attraverso ruolo, contratto e implementazione

Il riesame di sicurezza dei fornitori e quello ai fini GDPR si sovrappongono, ma non coincidono. Per prima cosa stabilite se il fornitore sia un responsabile del trattamento, un titolare autonomo, un contitolare o ricopra ruoli diversi per servizi diversi.

Ai sensi dell'articolo 28, i titolari devono ricorrere a responsabili che presentino garanzie sufficienti per l'attuazione di misure tecniche e organizzative adeguate. I rapporti con i responsabili richiedono un contratto vincolante o un altro atto giuridico idoneo che contenga gli elementi prescritti. Una semplice clausola di riservatezza non soddisfa tale requisito.

I requisiti dell'articolo 28 comprendono:

• Materia disciplinata, durata, natura e finalità del trattamento.
• Tipo di dati personali e categorie di interessati.
• Obblighi e diritti del titolare.
• Trattamento soltanto su istruzione documentata, comprese le disposizioni pertinenti sui trasferimenti.
• Riservatezza e misure di sicurezza dell'articolo 32.
• Condizioni per ricorrere ad altri responsabili.
• Assistenza nella gestione delle richieste di esercizio dei diritti e negli obblighi di conformità specificati.
• Restituzione o cancellazione dei dati al termine dei servizi, fatti salvi i requisiti di legge applicabili.
• Informazioni e modalità di audit per dimostrare la conformità.

Esaminate le effettive condizioni del servizio insieme all'accordo. Un fornitore potrebbe promettere la cancellazione e conservare tuttavia alcuni log per una distinta finalità di cui è titolare. Un abbonamento enterprise potrebbe limitare l'uso dei dati per l'addestramento mentre un account di prova non lo fa. Un responsabile può avvalersi di più sub-responsabili con sedi e modalità di supporto diverse.

Ai sensi dell'articolo 28, l'autorizzazione al ricorso a sub-responsabili può essere specifica o generale. Quando si utilizza un'autorizzazione scritta generale, il responsabile deve informare il titolare delle aggiunte o delle sostituzioni previste, dandogli la possibilità di opporsi. La questione operativa è chi riceve queste comunicazioni e le valuta prima che finiscano in una casella di posta non presidiata.

Tenete il riesame contrattuale separato dalla valutazione dei trasferimenti. Un accordo ai sensi dell'articolo 28 non costituisce di per sé uno strumento di trasferimento ai sensi del capo V. Né la firma di un accordo sul trattamento stabilisce la base giuridica dell'attività del titolare.

Gestire le condizioni non negoziabili come una decisione aziendale

I clienti più piccoli possono avere un potere negoziale limitato. Questo rende la valutazione anticipata più importante, non facoltativa. Documentate la carenza, chiedete quali alternative siano disponibili e valutate se modificare la configurazione, ridurre i dati, scegliere un altro servizio o non procedere.

Quando un requisito obbligatorio resta insoddisfatto, l'approvazione del vertice non può sanarlo. Quando la questione è una scelta tra opzioni lecite con rischi residui diversi, la direzione può decidere sulla base di una consulenza documentata. Gli acquisti dovrebbero distinguere queste situazioni invece di raccogliere ogni criticità in un'unica categoria di eccezioni.

Il riesame di un fornitore dovrebbe concludersi con una decisione, condizioni, riferimenti alle evidenze ed eventi che fanno scattare un nuovo riesame, non soltanto con un questionario compilato.

Progettare la gestione dei diritti prima della prima richiesta difficile

Gli articoli da 15 a 22 prevedono diritti tra cui accesso, rettifica, cancellazione, limitazione, portabilità, opposizione e tutela rispetto a determinate decisioni basate unicamente su un trattamento automatizzato. Questi diritti hanno condizioni ed eccezioni diverse; un unico flusso "cancella tutto" non li servirà tutti.

Ai sensi dell'articolo 12, le organizzazioni devono rispondere senza ingiustificato ritardo e, di norma, entro un mese dal ricevimento della richiesta. È possibile una proroga fino a due ulteriori mesi, se necessario, tenuto conto della complessità e del numero delle richieste, ma l'interessato deve esserne informato entro il primo mese, con indicazione dei motivi. Le richieste sono in genere gratuite; il contributo spese o il rifiuto sono limitati alle condizioni previste dal regolamento, come le richieste manifestamente infondate o eccessive, che il titolare deve dimostrare.

Costruite un percorso operativo che funzioni attraverso i canali di assistenza, risorse umane, vendite e privacy:

1. Registrare la ricezione, i diritti richiesti e la scadenza.
2. Confermare il titolare competente e il perimetro.
3. Verificare l'identità in modo proporzionato quando sussistono ragionevoli dubbi.
4. Localizzare i dati e identificare sistemi, destinatari e responsabili pertinenti.
5. Valutare condizioni, esenzioni applicabili e diritti di altre persone.
6. Preparare la risposta o l'azione e sottoporla a revisione.
7. Consegnare in modo sicuro e conservare un'adeguata registrazione del completamento.

Non chiedete abitualmente documenti d'identità quando basterebbe una verifica meno invasiva. Allo stesso modo, non divulgate dati sensibili solo perché qualcuno conosce un indirizzo e-mail. La verifica stessa comporta un trattamento di dati personali e richiede un approccio proporzionato.

Una risposta a una richiesta di accesso richiede normalmente più di un elenco di categorie. L'articolo 15 comprende una copia dei dati personali oggetto di trattamento e informazioni supplementari. Esaminate le informazioni e i diritti di terzi prima della comunicazione; la presenza del nome di un'altra persona non giustifica il trattenimento di tutto.

La cancellazione non è assoluta. Possono applicarsi obblighi legali di conservazione e altre eccezioni dell'articolo 17. Quando la cancellazione è dovuta, determinate come raggiunga i servizi collegati e i destinatari pertinenti e come il ripristino dei backup eviti di reintrodurre con leggerezza dati cancellati. Spiegate con precisione eventuali limitazioni lecite.

L'automazione può monitorare le scadenze e organizzare le ricerche, ma qualcuno deve decidere se i risultati sono completi, se gli oscuramenti sono giustificati e se si applica un'eccezione. Una risposta standard generata rapidamente non serve se omette un sistema che contiene i dati richiesti.

Consultate richieste di accesso degli interessati per un flusso più dettagliato. Il vertice dovrebbe testare periodicamente una richiesta rappresentativa, dalla ricezione alla consegna sicura, invece di affidarsi soltanto alla pubblicazione di una procedura.

Usare la DPIA per mettere in discussione la progettazione prima di approvarla

Una valutazione d'impatto sulla protezione dei dati ai sensi dell'articolo 35 è obbligatoria prima di un trattamento che può presentare un rischio elevato per i diritti e le libertà delle persone. Il regolamento individua casi particolari, tra cui determinate valutazioni automatizzate significative, il trattamento su larga scala di dati sensibili e la sorveglianza sistematica su larga scala di zone accessibili al pubblico. Vanno considerati anche gli elenchi pertinenti delle autorità di controllo.

Sottoponete a screening le attività proposte fin dall'inizio. Come raccomandazione pratica, conservate il ragionamento quando lo screening conclude che una DPIA non è necessaria, soprattutto nei casi limite. Un breve registro dello screening consente di riconsiderare la decisione quando cambiano la scala, la tecnologia o la finalità.

La DPIA completa dovrebbe affrontare quattro elementi collegati:

• Una descrizione sistematica dei trattamenti previsti e delle finalità, compreso, ove applicabile, il legittimo interesse.
• La necessità e la proporzionalità rispetto a tali finalità.
• I rischi per i diritti e le libertà degli interessati.
• Le misure previste per affrontare i rischi e dimostrare la conformità.

Non iniziate e non concludete con un elenco di minacce alla sicurezza. Chiedetevi prima se i dati, la frequenza, i destinatari e il processo decisionale proposti siano necessari. Una progettazione meno invasiva può eliminare un rischio in modo più efficace di un ulteriore controllo tecnico.

Ad esempio, un progetto sulla produttività dei dipendenti potrebbe proporre di acquisire screenshot in modo continuativo. Cifratura e accessi limitati potrebbero ridurre il rischio di divulgazione, lasciando però aperte gravi questioni di proporzionalità, monitoraggio, aspettative dei dipendenti e idoneità di misure meno invasive. La finalità di business va esaminata prima che la progettazione della sicurezza possa avere senso.

Valutare il rischio per le persone, non solo l'esposizione dell'azienda

Considerate perdite finanziarie, discriminazione, uso illecito dell'identità, perdita di riservatezza, esclusione dai servizi e altri effetti pertinenti. Uno scenario può avere un impatto finanziario limitato sull'azienda e un impatto rilevante su una persona.

Documentate le mitigazioni proposte, i responsabili dell'attuazione e la valutazione residua. Chiedete il parere del DPO, se designato. Verificate se modifiche nel trattamento o nel rischio richiedano l'aggiornamento della valutazione.

L'articolo 36 impone la consultazione preventiva dell'autorità di controllo quando la DPIA indica che il trattamento presenterebbe un rischio elevato in assenza di misure adottate per attenuarlo. Se l'organizzazione non è in grado di affrontare in modo sufficiente tale rischio elevato, non può sostituire la consultazione richiesta con uno stato interno di "accettato". La direzione può riprogettare, rinviare o abbandonare l'attività; non può disporre dei diritti di altre persone come se fossero soltanto un rischio commerciale.

Collegare la risposta agli incidenti alle decisioni di notifica del GDPR

Una violazione dei dati personali comprende una violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l'accesso ai dati personali. È un concetto più ampio del furto di un database da parte di un attaccante. Un allegato inviato al destinatario sbagliato, un dispositivo non protetto smarrito o un incidente che incide sulla disponibilità o sull'integrità dei dati personali possono richiedere una valutazione.

Ai sensi degli articoli 33 e 34, i titolari valutano due diverse soglie di notifica:

Il termine di 72 ore decorre dal momento in cui si viene a conoscenza della violazione, non semplicemente dal momento dell'incidente originario né dal giorno lavorativo successivo. Se la notifica avviene più tardi, deve essere corredata dei motivi del ritardo. Le informazioni possono essere fornite in fasi successive quando non è possibile fornirle tutte contemporaneamente senza ulteriore ingiustificato ritardo.

Predisponete in anticipo la catena di escalation: responsabile dell'incidente, consulente privacy, decisore competente per il titolare, investigatori tecnici, comunicazione e contatti dei fornitori. Individuate il canale di segnalazione dell'autorità competente prima di un'emergenza. Un responsabile del trattamento non dovrebbe attendere la propria conclusione definitiva sul rischio prima di informare il titolare.

Il registro dell'incidente dovrebbe riportare che cosa è accaduto, i dati e le persone coinvolti, le probabili conseguenze, il contenimento e la correzione, nonché le decisioni di notifica. L'articolo 33, paragrafo 5, impone di documentare le violazioni dei dati personali, comprese le circostanze, le conseguenze e i provvedimenti adottati. Conservate la motivazione delle mancate notifiche, in modo che la decisione possa essere compresa in seguito.

La cifratura può incidere sull'analisi del rischio e dell'articolo 34, ma solo quando la sua protezione è pertinente ed efficace. "Il servizio usa la cifratura" non basta se un attaccante ha avuto accesso ai dati in chiaro tramite un account compromesso. L'articolo 34 prevede anche altre eccezioni, come le misure successive che scongiurano il sopraggiungere di un rischio elevato; valutate le condizioni effettive invece di applicare un'esenzione generica.

Esercitatevi su uno scenario che coinvolga un fornitore e su un altro che riguardi una divulgazione interna. L'esercitazione dovrebbe verificare la raccolta delle evidenze e l'autorità decisionale, oltre al contenimento tecnico.

Trattare i trasferimenti internazionali come una valutazione separata

I requisiti sui trasferimenti del capo V si affiancano al resto del GDPR. Uno strumento di trasferimento non fornisce una base giuridica ai sensi dell'articolo 6, e una base giuridica non elimina la necessità di un adeguato meccanismo di trasferimento.

Mappate i destinatari effettivi e i percorsi di accesso. L'hosting in un data center nell'UE è rilevante, ma non dimostra di per sé che non avvenga alcun trasferimento verso paesi terzi né che tutti gli obblighi privacy siano soddisfatti. Considerate l'accesso di supporto, i sub-responsabili, l'accesso amministrativo, le comunicazioni successive e le parti coinvolte.

Il quadro del GDPR sui trasferimenti comprende le decisioni di adeguatezza dell'articolo 45, le garanzie adeguate dell'articolo 46 e le deroghe limitate dell'articolo 49. Verificate lo strumento pertinente e il suo ambito al momento della decisione.

Quando ci si basa su un regime di adeguatezza limitato alle organizzazioni aderenti, verificate il destinatario esatto e l'attività coperta. Una società del gruppo o una denominazione commerciale simile non è necessariamente il destinatario coperto. Conservate l'esito e la data della verifica.

Quando si utilizzano clausole contrattuali tipo, scegliete i moduli corrispondenti ai ruoli effettivi delle parti e compilate gli allegati pertinenti. Valutate le leggi e le prassi del paese di destinazione e se siano necessarie misure supplementari per rendere effettiva la protezione. Un contratto firmato non risponde da solo a ogni domanda sul rischio di trasferimento.

Un fascicolo pratico sul trasferimento dovrebbe identificare esportatore e importatore, dati e finalità, sedi e accessi, trasferimenti successivi, strumento scelto, valutazione pertinente, misure tecniche od organizzative ed eventi che fanno scattare il riesame. La documentazione del provider può supportare questo lavoro, ma chiedere se un provider "ha una valutazione" non equivale a valutarne le conclusioni pertinenti.

La direzione dovrebbe sapere quali servizi dipendono da un determinato strumento e quali cambiamenti richiederebbero una nuova valutazione. Ciò consente un piano di contingenza ponderato, senza implicare che ogni fornitore necessiti di un'identica alternativa contrattuale.

Valutare l'uso dell'IA come trattamento, non solo come nuovo strumento

Un'applicazione di IA può introdurre nuovi destinatari, dedurre ulteriori informazioni personali, conservare i prompt o rendere possibile una nuova finalità. Questi cambiamenti contano anche se l'applicazione riutilizza i sistemi di single sign-on e di controllo degli accessi già esistenti nell'organizzazione.

Prima di approvare l'inserimento di dati personali in un servizio di IA, stabilite:

• Il compito preciso e se i dati personali siano necessari.
• Le categorie di input, di output e di persone interessate.
• Il ruolo del provider per ciascun utilizzo, comprese eventuali finalità di addestramento o miglioramento.
• Conservazione, accesso da parte di persone, sub-responsabili e meccanismi di trasferimento.
• Impegni contrattuali e impostazioni di configurazione pertinenti.
• Rischi legati a esattezza, divulgazione, gestione dei diritti e processi decisionali.

Non date per scontato che ogni provider di modelli sia esclusivamente un responsabile del trattamento. Il suo ruolo dipende dal trattamento che svolge e dalle finalità che determina. Allo stesso modo, un accordo ai sensi dell'articolo 28 non rende automaticamente lecita la trasmissione proposta. Valutate finalità, base giuridica, trasparenza, necessità e tutti gli altri requisiti applicabili.

Se l'azienda è essa stessa un responsabile del trattamento, l'introduzione di un provider di IA può creare un rapporto di sub-responsabilità. Verificate le istruzioni del cliente e la procedura di autorizzazione concordata prima di inviare dati dei clienti. Non sempre serve un nuovo emendamento contrattuale, ma è sempre necessario rispettare gli accordi contrattuali e le disposizioni di legge esistenti.

L'articolo 22 riguarda determinate decisioni basate unicamente su un trattamento automatizzato che producono effetti giuridici o incidono in modo analogo significativamente sulla persona. Una revisione umana solo nominale non risolve la questione se il revisore non è in grado di valutare o modificare in modo significativo l'esito. Selezione del personale, ammissibilità e decisioni finanziarie richiedono particolare attenzione.

Il regolamento sull'IA e il GDPR impongono obblighi distinti. Una valutazione ai sensi del regolamento sull'IA non assolve una DPIA, e la conformità al GDPR non dimostra la conformità al regolamento sull'IA. Per le date di applicazione utilizzate la panoramica aggiornata della Commissione europea sul regolamento sull'IA, invece di trasferire in un progetto attuale un vecchio calendario di lancio.

Per il lavoro interno sulla privacy, l'IA può redigere descrizioni a partire da fonti approvate, confrontare documenti o suggerire domande. Trattate il suo output come una bozza. Una base giuridica plausibile ma sbagliata, un destinatario dimenticato o un'indicazione errata sulla conservazione possono rendere un documento curato sostanzialmente errato.

Automatizzare il coordinamento preservando una revisione responsabile

Le organizzazioni in crescita accumulano lavoro ricorrente: aggiornamenti del registro dei trattamenti, scadenze delle richieste di esercizio dei diritti, documenti dei fornitori, azioni derivanti dalle valutazioni, scadenza delle evidenze e decisioni di riesame. L'automazione può organizzare input e scadenze. Non dovrebbe però offuscare la differenza tra raccogliere informazioni e giungere a una conclusione difendibile.

Partite da un processo stabile e da responsabilità chiare. Automatizzare un passaggio di consegne ambiguo può soltanto diffondere l'ambiguità più velocemente. Definite che cosa apre un'attività, chi la riceve, quali evidenze sono necessarie, chi esamina il risultato e che cosa completa il lavoro.

Per le bozze redatte con l'aiuto dell'IA, conservate le fonti approvate e segnalate le incertezze. Non lasciate che un riassunto generato sostituisca silenziosamente un contratto con un fornitore o una valutazione. I revisori dovrebbero poter distinguere i fatti forniti, i suggerimenti dedotti e le questioni ancora aperte.

Applicate il principio del privilegio minimo anche al flusso di lavoro stesso. I fascicoli delle richieste di esercizio dei diritti, i registri degli incidenti e le valutazioni sui dipendenti possono contenere informazioni sensibili. Un accesso ampio a uno spazio di lavoro dedicato alla compliance può vanificare le restrizioni che si stanno documentando. Minimizzate i dati personali nelle evidenze e limitate l'accesso al materiale che richiede effettivamente l'identificazione.

Tra gli indicatori gestionali utili rientrano le azioni scadute, i responsabili mancanti, i registri in attesa di revisione dopo una modifica rilevante e i controlli con evidenze obsolete o insufficienti. Il semplice conteggio dei documenti è meno informativo. Misurate se le decisioni e le azioni correttive vengono completate, non solo se è stato generato più testo.

Esempio pratico: un'integrazione di marketing che riutilizza i controlli di sicurezza

L'esempio seguente è illustrativo. Supponiamo che un'azienda B2B di software in crescita disponga di un database clienti consolidato, di un SGSI che copre il proprio servizio di produzione e di una piattaforma per campagne in fase di valutazione. Il marketing vuole inviare messaggi di onboarding e, in seguito, promuovere prodotti aggiuntivi. La piattaforma riceverebbe dati di contatto, eventi di utilizzo del prodotto e note di assistenza in testo libero. Non si intende alcun risultato reale di clienti né alcuna funzionalità di Secani.

1. Separare le finalità proposte

La richiesta iniziale parla di "migliorare il coinvolgimento dei clienti". Il responsabile di business la riformula in finalità specifiche: onboarding necessario per il servizio, comunicazioni promozionali facoltative e analisi delle prestazioni delle campagne.

Il revisore privacy valuta la base per ciascuna finalità invece di applicare il contratto con il cliente a tutte e tre. Le comunicazioni promozionali possono inoltre ricadere nelle norme nazionali applicabili sul marketing elettronico. L'azienda non presume che un'analisi del legittimo interesse ai sensi del GDPR risolva da sola questi requisiti distinti.

Il primo deliverable è una decisione su finalità e base giuridica, con le questioni aperte assegnate. Il marketing non può avviare l'uso esteso solo perché l'integrazione ha superato un controllo tecnico di sicurezza.

2. Ridurre il flusso di dati proposto

Le note di assistenza sono comode per la personalizzazione, ma non necessarie per il messaggio di onboarding approvato. Possono inoltre contenere informazioni che i clienti non si aspettavano venissero riutilizzate per il marketing. La progettazione le elimina.

Il responsabile tecnico limita gli eventi di prodotto a quelli necessari per il flusso approvato ed esclude le cronologie dettagliate degli utenti dove bastano dati aggregati o eventi più semplici. Ciò riduce l'esposizione prima ancora di aggiungere un altro controllo.

Il registro dei trattamenti descrive ora i campi effettivi, gli utenti interessati, il destinatario, le finalità e l'approccio alla conservazione. L'informativa privacy viene rivista rispetto all'attività approvata e non rispetto all'ampia richiesta originaria.

3. Verificare i rapporti con il fornitore e i trasferimenti

L'ufficio acquisti stabilisce il ruolo della piattaforma per l'invio delle campagne e verifica l'esistenza di finalità distinte del provider. Il team esamina l'accordo ai sensi dell'articolo 28, i rapporti con i sub-responsabili, le condizioni di cancellazione, l'accesso di supporto e lo strumento di trasferimento applicabile.

Un'opzione di hosting nell'UE viene registrata come fatto rilevante, non considerata la conclusione dell'analisi sui trasferimenti. Se mancano informazioni necessarie, l'attività resta aperta e la condizione di lancio indica che cosa deve essere risolto.

4. Riutilizzare con attenzione le evidenze di sicurezza

L'integrazione può riutilizzare i controlli aziendali sulle identità e un processo di gestione degli accessi già esistente. Le evidenze di questi controlli vengono collegate, non ricreate. La nuova piattaforma per campagne ha però autorizzazioni, esportazioni e impostazioni di conservazione proprie.

Il responsabile della sicurezza valuta la compromissione degli account, l'esportazione massiva non autorizzata, la mappatura errata degli eventi e la perdita delle preferenze di esclusione. Il team limita gli accessi, approva le autorizzazioni di integrazione necessarie, testa la mappatura con dati di test adeguati e verifica come i record vengono cancellati o esclusi.

L'esercitazione di ripristino esistente per il servizio di produzione non dimostra che le preferenze relative alle campagne possano essere ripristinate correttamente. Il responsabile verifica separatamente il comportamento di ripristino pertinente per questo flusso.

5. Completare la valutazione e l'approvazione

Il revisore privacy effettua lo screening DPIA sulla base dell'attività effettiva e ne registra la motivazione. Il team verifica anche come le richieste di accesso, opposizione e cancellazione raggiungano la piattaforma. In particolare, un'opposizione al marketing non deve essere annullata dalla successiva sincronizzazione del database.

La direzione esamina un pacchetto decisionale sintetico: finalità approvate, dati eliminati, conclusioni su fornitore e trasferimenti, misure di protezione, condizioni aperte, gestione dei diritti e responsabili nominati. Ogni requisito obbligatorio non risolto blocca il trattamento interessato invece di essere trasformato in un'eccezione commerciale accettata.

6. Conservare l'evento che farà scattare il riesame

L'approvazione è legata alla configurazione valutata. L'aggiunta di uno scoring comportamentale, il caricamento delle note di assistenza, la modifica delle condizioni di addestramento del provider o l'introduzione di un nuovo destinatario fanno scattare un riesame. Il team può riutilizzare le evidenze di sicurezza invariate mentre rivaluta le nuove questioni privacy.

È questa la distinzione centrale: le misure di protezione comuni possono restare valide mentre la finalità, il destinatario o l'effetto sulle persone cambiano in modo sostanziale.

Mettere in pratica l'approccio partendo da un perimetro circoscritto

Scegliete un'attività di trattamento con una titolarità di business ben visibile e dipendenze gestibili. L'assistenza clienti, l'onboarding dei dipendenti o un flusso di prodotto rappresentativo possono far emergere lacune senza richiedere prima una riprogettazione a livello di intera organizzazione.

Come raccomandazione pratica, iniziate con quattro deliverable:

• Una descrizione condivisa del trattamento e una valutazione dei ruoli.
• Un elenco delle decisioni privacy, tra cui base giuridica, informativa, conservazione, diritti e screening DPIA.
• Una valutazione delle misure di protezione basata su scenari e collegata alle evidenze di sicurezza esistenti.
• Un registro di approvazione con responsabili, azioni aperte ed eventi che fanno scattare un riesame.

In Secani, i team possono partire da un perimetro circoscritto, modellare le applicazioni, i sistemi, i servizi e i provider di supporto e collegare le evidenze a requisiti, controlli e decisioni. Le evidenze mancanti e le questioni di revisione aperte possono diventare attività assegnate. I suggerimenti generati con l'aiuto dell'IA restano bozze, con tracciabilità delle fonti e approvazione umana esplicita. In questo modo i revisori di sicurezza e privacy dispongono di un contesto di evidenze condiviso, mantenendo visibili le rispettive conclusioni distinte; ciò non sostituisce i registri dei trattamenti, l'evasione delle richieste di esercizio dei diritti né l'analisi giuridica.

Estendete il perimetro solo dopo aver messo alla prova il primo flusso. Testatelo con un cambio di fornitore, una richiesta di esercizio dei diritti e uno scenario di incidente pertinente. Se il team non riesce a identificare il responsabile, recuperare le evidenze o spiegare la decisione, correggete il processo operativo prima di aggiungere altre attività.

Per il riesame della direzione, ponete tre domande: il registro corrisponde ai trattamenti attuali, le misure di protezione affrontano le conseguenze per le persone e una modifica rilevante riaprirà in modo affidabile la decisione? Queste domande indicano un passo successivo concreto per collegare le garanzie di sicurezza alla responsabilizzazione prevista dal GDPR.

Domande che il vertice dovrebbe chiarire esplicitamente

Un CEO può approvare un'eccezione al GDPR?

La direzione può scegliere tra opzioni lecite e destinare risorse per affrontare il rischio. Non può derogare a requisiti di legge, autorizzare un trattamento privo di una base applicabile né sostituire con un'approvazione interna la consultazione preventiva obbligatoria.

Ogni modifica a un trattamento richiede una nuova DPIA?

No. Valutate la modifica rispetto alla soglia del rischio elevato e riesaminate le valutazioni esistenti quando cambiano il trattamento o il rischio. Una decisione di screening documentata è più utile sia della produzione automatica di una DPIA completa sia del presupposto che il risultato precedente valga sempre.

Che cosa riesaminare per primo quando le risorse sono limitate?

Date priorità ai trattamenti con conseguenze potenzialmente gravi per le persone, alle questioni aperte di liceità o di natura contrattuale e alle scadenze operative come le richieste di esercizio dei diritti e la risposta alle violazioni. Usate le lacune nelle evidenze per orientare le verifiche, ma non presumete che l'attività con più documenti mancanti presenti necessariamente il rischio maggiore.

Quale autorità applica il GDPR e quanto possono costare le violazioni?

Individuate l'autorità di controllo competente per il trattamento. Per i trattamenti transfrontalieri che ne soddisfano i presupposti, il meccanismo dell'autorità capofila dipende in genere dallo stabilimento principale o unico del titolare o del responsabile nell'UE, con il coinvolgimento delle altre autorità interessate. Un rappresentante ai sensi dell'articolo 27 non crea uno stabilimento nell'UE né dà accesso a tale meccanismo.

L'articolo 83 prevede due fasce principali di sanzioni amministrative massime: fino a 10 milioni di euro o il 2% del fatturato mondiale totale annuo dell'esercizio precedente dell'impresa, e fino a 20 milioni di euro o il 4%, se superiore, in ciascuna fascia. La fascia applicabile dipende dalla violazione; si tratta di massimali, non di sanzioni automatiche. Le autorità tengono conto delle circostanze e possono anche ordinare misure correttive o limitare il trattamento. L'articolo 82 prevede separatamente il risarcimento quando una violazione causa un danno materiale o immateriale.