Verificare un accordo sul trattamento dei dati rispetto al servizio reale

Un accordo sul trattamento dei dati (DPA) diventa utile quando la sua descrizione corrisponde al servizio effettivo. Un contratto apparentemente completo può comunque descrivere i dati sbagliati, omettere un fornitore di assistenza o promettere una cancellazione che il prodotto non è in grado di eseguire.

Per un CTO, la verifica collega gli impegni giuridici ad architettura, configurazione e procedure operative. I colleghi dell'ufficio legale o della privacy interpretano le clausole; il team di engineering accerta se quelle clausole descrivono la realtà. Il risultato dovrebbe essere una decisione difendibile sul servizio, supportata da evidenze e da un elenco chiaro delle condizioni ancora aperte, non semplicemente un PDF firmato.

Stabilire il ruolo del fornitore prima di esaminare le clausole

Iniziate stabilendo se il fornitore agisce come responsabile del trattamento per il trattamento in questione. Ai sensi del GDPR, il responsabile del trattamento tratta dati personali per conto di un titolare del trattamento. Non ogni rapporto con un fornitore ha questo ruolo, e uno stesso fornitore può avere ruoli diversi per attività diverse.

Una piattaforma di assistenza ospitata può trattare i ticket dei clienti secondo le vostre istruzioni e agire al contempo come titolare autonomo per una parte della propria amministrazione degli account. Se le sue condizioni consentono anche di utilizzare il contenuto dei ticket per finalità determinate autonomamente, quell'attività richiede un'analisi separata. Chiamare tutto "miglioramento del servizio" non risolve la questione del ruolo.

Preparate una breve descrizione dell'ambito prima di annotare l'accordo:

• Individuate il soggetto contraente, il prodotto, il livello di abbonamento e le funzionalità attivate.
• Descrivete perché la vostra organizzazione utilizza il servizio e di chi sono i dati personali trattati.
• Separate il trattamento su istruzione da eventuali finalità definite dal fornitore.
• Indicate il referente interno del servizio e il revisore legale o privacy.

Un DPA non è una base giuridica ai sensi dell'articolo 6, né soddisfa automaticamente i requisiti sui trasferimenti internazionali. Queste questioni restano separate. Se la vostra organizzazione è essa stessa un responsabile del trattamento, individuate le istruzioni e le condizioni di autorizzazione del titolare a monte prima di ricorrere al fornitore come sub-responsabile.

Costruire una matrice di verifica dell'articolo 28

L'articolo 28 del GDPR richiede un contratto vincolante o un altro atto giuridico idoneo che disciplini l'attività del responsabile del trattamento. Deve descrivere materia disciplinata e durata, natura e finalità, tipo di dati personali, categorie di interessati e diritti e obblighi del titolare.

Questi dettagli devono individuare il trattamento effettivo. "Tutti i dati necessari a fornire i servizi" può lasciare i revisori nell'impossibilità di stabilire se siano coperti dati del personale, messaggi dei clienti o allegati sensibili. Confrontate gli allegati con il prodotto così come è configurato, comprese le integrazioni opzionali.

Usate la matrice seguente per esaminare gli obblighi richiesti al responsabile del trattamento. La colonna delle evidenze contiene raccomandazioni pratiche per la verifica, non un obbligo di legge di ottenere ciascun documento indicato.

Il responsabile del trattamento deve inoltre informare immediatamente il titolare qualora, a suo parere, un'istruzione violi la normativa applicabile in materia di protezione dei dati. Verificate dove arriva questa comunicazione e chi può risolvere la questione.

Contrassegnate ogni requisito come coperto, poco chiaro o mancante, con il riferimento alla clausola. Non classificate un'omissione obbligatoria come una normale preferenza commerciale. L'articolo 28, paragrafo 1, impone inoltre ai titolari di ricorrere a responsabili che presentino garanzie sufficienti; la sola formulazione contrattuale non può dimostrarlo.

Seguire un record rappresentativo attraverso il servizio

Scegliete un record realistico e seguitelo dall'acquisizione allo smaltimento. Per un servizio di assistenza clienti, potrebbe essere un ticket che contiene un nome, un indirizzo email, un identificativo dell'account e un allegato. Nei test, preferite dati sintetici.

Mappate raccolta, acquisizione via API, archiviazione primaria, indicizzazione, analytics, accesso del supporto, esportazioni, integrazioni, backup e cancellazione. Chiedete quali componenti ricevono contenuti e quali solo metadati. Log e tracce diagnostiche contengono spesso identificativi anche quando l'applicazione principale ha un ambito correttamente definito.

Per ogni fase, registrate il soggetto responsabile, la finalità del trattamento, l'ubicazione, il percorso di accesso e il periodo di conservazione. Confrontate il risultato con il DPA, l'allegato sulla sicurezza, l'elenco dei sub-responsabili e le modalità di trasferimento.

Prestate particolare attenzione alle funzionalità che gli amministratori possono attivare senza coinvolgere l'ufficio acquisti: trascrizione, arricchimento dei dati, riassunti con IA, webhook esterni e registrazione delle sessioni di supporto. Un contratto verificato per il prodotto base può non descrivere adeguatamente il servizio con queste funzionalità attivate.

Il deliverable può essere un semplice diagramma dei flussi di dati e un registro delle discrepanze. Ogni discrepanza dovrebbe indicare la dichiarazione contrattuale, il comportamento osservato, la conseguenza, il referente e la soluzione. Per esempio, "il DPA descrive una conservazione controllata dal cliente; i log diagnostici restano per un periodo fisso" è una voce su cui si può agire. "Conservazione poco chiara" non basta per chiudere la questione.

Mettere alla prova le promesse di sicurezza rispetto all'implementazione

L'articolo 32 richiede misure di sicurezza adeguate al rischio. Non impone un'unica configurazione tecnica universale. Valutate le misure in base a sensibilità, volume ed esposizione dei dati e alle probabili conseguenze di una compromissione.

Un allegato dovrebbe spiegare abbastanza da consentire la valutazione del servizio, senza richiedere la divulgazione di dettagli sensibili ai fini di un exploit. Date priorità a isolamento dei tenant, accessi privilegiati, autenticazione, cifratura, resilienza, ripristino, gestione delle vulnerabilità e test. Individuate i controlli gestiti dal fornitore e le impostazioni che deve configurare il vostro team.

Se l'accordo promette un accesso del supporto limitato, chiedete come l'accesso viene richiesto, approvato, limitato nel tempo e registrato. Se promette la cifratura, distinguete la protezione in transito da quella a riposo, poi stabilite chi controlla le chiavi e che cosa possono comunque leggere gli utenti autorizzati. La cifratura non risolve il problema di autorizzazioni applicative eccessive.

Per disponibilità e ripristino, determinate quali backup esistono, come viene testato il ripristino e se gli impegni contrattuali di recovery coprono il prodotto che state acquistando. Tenete distinti gli obiettivi commerciali di uptime dagli obblighi di sicurezza e privacy.

Certificati e report di assurance possono supportare la valutazione, ma il loro perimetro conta. Verificate servizio, soggetto giuridico, periodo di valutazione, esclusioni e responsabilità del cliente. Un report sul provider di hosting non è un'evidenza per ogni controllo dell'applicazione SaaS, e una certificazione non dimostra la conformità al GDPR. Per la verifica più ampia delle evidenze, si veda valutare le garanzie di sicurezza.

Quando l'allegato sulla sicurezza è incorporato tramite un link web, conservate la versione applicabile. Verificate se le modifiche possono ridurre la protezione e come vengono informati i clienti. Trattate una pagina non datata e modificabile come un problema di gestione delle evidenze da risolvere, anziché presumere che sia automaticamente sufficiente o automaticamente non valida.

Seguire la catena dei sub-responsabili e valutare separatamente i trasferimenti

L'articolo 28, paragrafo 2, richiede un'autorizzazione scritta, specifica o generale, preventiva per ricorrere a un altro responsabile del trattamento. In caso di autorizzazione generale, il responsabile deve informare il titolare di eventuali modifiche previste riguardanti l'aggiunta o la sostituzione di altri responsabili, dandogli la possibilità di opporsi. L'articolo 28, paragrafo 4, richiede che gli obblighi pertinenti in materia di protezione dei dati siano trasferiti a valle; il responsabile iniziale conserva nei confronti del titolare l'intera responsabilità dell'adempimento di tali obblighi da parte del sub-responsabile.

Ottenete un elenco utilizzabile che indichi, per ciascun fornitore, identità giuridica, funzione, dati interessati e luoghi del trattamento. Non ogni dipendenza da un fornitore è un sub-responsabile, ma i fornitori di infrastruttura, assistenza e analytics non dovrebbero sparire dalla verifica solo perché operano dietro l'interfaccia del prodotto.

Valutate il meccanismo di modifica:

• La comunicazione arriva a un indirizzo monitorato o a un referente assegnato?
• Ci sono informazioni e tempo sufficienti per valutare la modifica proposta?
• Come si presenta un'opposizione e come viene risolta?
• Che cosa succede se non è disponibile alcuna alternativa accettabile?

Un diritto contrattuale che nessuno può esercitare sul piano operativo è un segnale d'allarme. Iscrivete il team appropriato alle comunicazioni e registrate chi valuta gli avvisi.

L'hosting nell'UE è rilevante, ma non conclude la valutazione dei trasferimenti. Esaminate i destinatari effettivi, le modalità di accesso da remoto, le sedi dell'assistenza e i trasferimenti successivi. Allo stesso modo, la sola proprietà estera non è una descrizione completa di un trasferimento: documentate i soggetti e i percorsi di accesso effettivi.

Quando si applica il capo V, individuate il meccanismo di trasferimento pertinente e le eventuali valutazioni o misure di supporto necessarie. Mantenete questa analisi collegata alla verifica del fornitore, ma distinta dalla conformità all'articolo 28. Un DPA e un'impostazione di hosting regionale non rispondono da soli a tutte le domande sui trasferimenti.

Rendere eseguibili gli obblighi di assistenza

Notifica delle violazioni e passaggio di consegne negli incidenti

Ai sensi dell'articolo 33, paragrafo 2, il responsabile del trattamento deve informare il titolare senza ingiustificato ritardo dopo essere venuto a conoscenza di una violazione dei dati personali. Il titolare valuta separatamente la notifica all'autorità di controllo, richiesta senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche.

Non concedete al responsabile del trattamento il termine del titolare come periodo di attesa predefinito. Un contratto pratico dovrebbe stabilire una prima notifica tempestiva, canali nominativi e aggiornamenti progressivi. Un obiettivo di notifica concordato è una raccomandazione operativa; non sostituisce lo standard previsto dalla legge.

Richiedete le informazioni necessarie per valutare dati, persone e sistemi interessati, conseguenze probabili, contenimento e ripristino. La prima notifica può essere incompleta, quindi definite come seguono aggiornamenti ed evidenze. Il titolare deve inoltre valutare se un rischio elevato richieda la comunicazione agli interessati ai sensi dell'articolo 34, fatte salve le relative eccezioni, e documentare la valutazione della violazione, compresi i motivi di un'eventuale mancata notifica. Esaminate con attenzione l'evento che fa scattare la notifica: un processo che attende il completamento dell'indagine sulla causa principale può ritardare la valutazione del titolare.

Mettete alla prova il passaggio di consegne con un'esercitazione da tavolo. Verificate che la notifica raggiunga chi gestisce gli incidenti e i revisori privacy anche al di fuori del normale orario di lavoro, e non soltanto un account manager.

Richieste degli interessati

L'assistenza del responsabile del trattamento dovrebbe rendere praticabile il vostro processo di risposta all'esercizio dei diritti. Verificate se i record possono essere individuati tra contenuti, allegati, indici ed esportazioni e se cancellazione o rettifica raggiungono i componenti pertinenti.

Concordate il percorso di risposta e i tempi attesi. I titolari hanno normalmente un mese per rispondere a una richiesta, fatte salve le condizioni di proroga previste dal GDPR; l'assistenza del fornitore deve lasciare spazio a verifiche dell'identità, valutazione giuridica e consegna sicura. Di norma il fornitore dovrebbe inoltrarvi le richieste che riguardano il trattamento effettuato su vostra istruzione, anziché deciderne autonomamente l'esito.

Costi e limiti del servizio meritano una verifica. I corrispettivi per un'assistenza aggiuntiva non sono automaticamente vietati, ma non devono rendere inefficace l'assistenza obbligatoria. Collegate la procedura al vostro workflow per le richieste di accesso degli interessati.

Restituzione, cancellazione e backup

Al termine del servizio, l'articolo 28 richiede la cancellazione o la restituzione a scelta del titolare e la cancellazione delle copie esistenti, salvo che il diritto dell'Unione o degli Stati membri preveda la conservazione. Stabilite che cosa significhi tecnicamente prima dell'acquisto.

Verificate completezza, formato e finestra di disponibilità dell'esportazione e se allegati o configurazioni siano esclusi. Per la cancellazione, distinguete record attivi, cache, repliche, log e backup. Se la cancellazione dai backup segue un ciclo pianificato, documentate il periodo, le restrizioni di accesso e le misure che impediscono di reintrodurre i record cancellati attraverso un ripristino.

Chiedete come viene documentato il completamento e come viene individuata la conservazione richiesta per legge. Evitate di considerare "account chiuso" come prova che i dati personali siano stati rimossi.

Esaminare diritti di audit, responsabilità e clausole irrisolte

Le disposizioni sugli audit dovrebbero fornire garanzie significative, tutelando al contempo gli altri clienti e i legittimi interessi di sicurezza. Una pianificazione ragionevole, la riservatezza e l'uso di report indipendenti possono rendere gli audit praticabili. Tuttavia, una clausola basata solo su certificati, senza alcun percorso per ottenere le informazioni necessarie o affrontare preoccupazioni rilevanti, merita una verifica legale alla luce dell'articolo 28, paragrafo 3, lettera h).

Stabilite il percorso di escalation quando le evidenze sono insufficienti, si verifica un incidente o un'autorità richiede informazioni. Esaminate insieme costi degli audit, termini di preavviso e restrizioni: il loro effetto combinato conta più di qualsiasi singola formulazione.

Le clausole sulla responsabilità civile richiedono una valutazione commerciale separata. Il risarcimento ai sensi dell'articolo 82 dipende dalle condizioni di responsabilità previste dal regolamento; i responsabili del trattamento non rispondono automaticamente di ogni inadempimento del titolare. Quando più soggetti sono responsabili ai sensi dell'articolo 82, le norme possono esporli all'intero danno per garantire il risarcimento effettivo. Un massimale contrattuale non limita i diritti riconosciuti dalla legge agli interessati. Il suo effetto sulla ripartizione e sul recupero tra le parti richiede una verifica legale.

Se il fornitore rifiuta le modifiche, distinguete tre esiti:

• Chiarimento: ottenere una formulazione autorevole o evidenze che risolvano l'ambiguità.
• Accettazione condizionata: approvare un accordo lecito con un rischio residuo commerciale o operativo documentato e garanzie specifiche.
• Non procedere: interrompere o riprogettare il trattamento quando gli obblighi richiesti restano insoddisfatti.

L'accettazione da parte della direzione non può rendere lecito un accordo illecito. Il DPO, ove designato, fornisce consulenza e sorveglia in modo indipendente; il referente di business responsabile prende le decisioni sul servizio con il contributo dell'ufficio legale e della privacy. Non attribuite al DPO la determinazione delle finalità o dei mezzi del trattamento.

Esaminare le funzionalità di IA come percorsi di trattamento aggiuntivi

Le funzionalità di IA introducono input, output e artefatti intermedi che gli allegati più datati potrebbero non descrivere. Esaminate, ove pertinenti, prompt, documenti recuperati, embedding, risposte generate, feedback, registrazioni del monitoraggio degli abusi e accessi per la revisione umana.

Stabilite se i dati dei clienti vengono utilizzati per addestrare o migliorare modelli, a quali finalità ciò risponde e quale soggetto effettua il trattamento. "Nessun addestramento" non equivale a "nessuna conservazione", e nessuna delle due promesse dimostra che log di assistenza o registrazioni di monitoraggio non contengano dati personali.

Verificate che gli impegni si applichino al livello acquistato, agli endpoint attivati e ai fornitori di modelli a valle. Confermate impostazioni di conservazione, eccezioni e comportamento della cancellazione. Se un fornitore dichiara di anonimizzare i dati, chiedete che cosa supporti tale affermazione anziché presumere che gli artefatti dei modelli siano anonimi.

Registrate insieme l'impegno contrattuale e le evidenze di configurazione. Ogni nuova finalità richiede una propria valutazione del ruolo e della liceità; il DPA non fornisce quella base giuridica. Anche l'applicabilità dell'AI Act è una questione separata, che non si risolve firmando le clausole sul responsabile del trattamento.

Esempio pratico: software di assistenza con riassunti opzionali

Supponiamo, a titolo illustrativo, che un'azienda SaaS voglia una piattaforma di assistenza che contenga nomi, indirizzi email aziendali, testo dei ticket e allegati. I ticket possono contenere accidentalmente informazioni sensibili. Una funzionalità di IA opzionale riassume le conversazioni.

La bozza di DPA descrive il trattamento dei ticket e l'archiviazione nell'UE. Il walkthrough tecnico rivela un fornitore per i riassunti, un accesso dell'assistenza da un'altra regione e una conservazione dei dati diagnostici diversa da quella dei ticket.

La verifica produce quattro azioni concrete:

1. Completare l'ambito. Aggiungere alla descrizione allegati, identificativi diagnostici e trattamento con IA; verificare se il fornitore utilizza contenuti per finalità proprie.
2. Chiarire la catena dei fornitori. Ottenere identità, luoghi del trattamento, impegni di conservazione e copertura autorizzativa del fornitore del modello. Valutare separatamente i trasferimenti pertinenti.
3. Convalidare il comportamento lungo il ciclo di vita. Far passare un ticket sintetico attraverso esportazione e cancellazione. Ottenere la spiegazione della conservazione dei backup e dei dati diagnostici anziché presumere che la cancellazione del ticket rimuova ogni copia.
4. Fissare una condizione di rilascio. Mantenere disattivati i riassunti finché il relativo contratto e il flusso di dati non siano stati verificati. Definire l'instradamento delle notifiche di violazione e delle modifiche dei sub-responsabili prima dell'uso in produzione.

La registrazione della decisione distingue le evidenze ricevute dalle domande ancora aperte. Se il servizio principale è accettabile, l'approvazione può escludere esplicitamente la funzionalità di IA. Questo limite deve esistere anche nella configurazione e nel change control: una nota nel fascicolo della verifica non impedirà a qualcuno di attivarla in seguito.

Conservare la decisione e riaprirla quando il servizio cambia

Conservate insieme la versione applicabile del contratto, l'ambito del trattamento, il diagramma dei flussi di dati, le evidenze di assurance, la valutazione dei trasferimenti, il registro delle discrepanze e l'approvazione. Registrate i rischi residui accettati, le condizioni, i referenti e le date di follow-up. Conservate il motivo per cui un accordo è stato accettato, non soltanto il suo stato.

Ripetete la verifica quando cambiano in modo sostanziale finalità del trattamento, funzionalità attivate, sub-responsabili, luoghi o condizioni contrattuali. Includete tra gli eventi scatenanti anche incidenti significativi e nuove evidenze di debolezze nei controlli. Una revisione pianificata integra questi eventi scatenanti, non li sostituisce.

Secani può supportare questo workflow modellando il servizio e i fornitori esterni, collegando le evidenze a requisiti e decisioni e assegnando le lacune della verifica a dei referenti. Conclusioni revisionate da persone, collegamenti alle fonti, commenti e approvazioni preservano il ragionamento alla base dell'accettazione. In questo modo la verifica del contratto si collega alla gestione del rischio di terze parti senza considerare il software un sostituto del giudizio giuridico o tecnico.

L'accordo richiede una firma autografa?

L'articolo 28, paragrafo 9, richiede la forma scritta, anche in formato elettronico. Una firma autografa non è necessaria di per sé. Conservate le evidenze dell'accettazione vincolante e della versione in vigore; chiedete ai revisori legali di risolvere eventuali incertezze sull'incorporazione online o su condizioni in conflitto.

Ogni sub-responsabile deve essere nominato all'interno del DPA?

L'articolo 28 non prescrive un elenco fisso all'interno del documento. Un elenco mantenuto aggiornato può supportare l'autorizzazione, a condizione che l'accordo fornisca le informazioni richieste, le comunicazioni delle modifiche e la possibilità di opporsi. Conservate l'elenco pertinente per la vostra verifica.

Per la prossima verifica di un fornitore, partite da un flusso di dati rappresentativo e dalla matrice dell'articolo 28. Risolvete le discrepanze tra promesse contrattuali e funzionamento osservabile prima di autorizzare il trattamento in produzione.