Accordo sul trattamento dei dati: clausole e negoziazione
|
7
min di lettura
Un fornitore supera finalmente la revisione di sicurezza. Il procurement è pronto. L'engineering vuole l'integrazione operativa entro la settimana. Poi nella vostra casella di posta arriva un accordo sul trattamento dei dati (data processing agreement, DPA) e tutto si ferma.
È lungo, denso e pieno di clausole che sembrano intercambiabili finché non le si legge con attenzione. Una versione concede al fornitore ampi diritti sui sub-responsabili. Un'altra limita il supporto in caso di violazione a vaghi “sforzi commercialmente ragionevoli”. Una terza sembra curata, ma manca di termini che contano se il vostro team dovesse mai indagare su un incidente di sicurezza o rispondere a un'autorità di controllo. Ecco perché trattare un DPA come semplice burocrazia è un errore.
La posta in gioco è reale. A marzo 2025 le autorità europee per la protezione dei dati avevano inflitto sanzioni per circa 5,6 miliardi di euro ai sensi del GDPR, e le organizzazioni prive di un DPA valido sono esposte a sanzioni fino a 10 milioni di euro o al 2% del fatturato annuo mondiale ai sensi dell'articolo 83, paragrafo 4, come riassunto in questa panoramica sui DPA nel GDPR. Per i team dati, questa regola giuridica si traduce in qualcosa di semplice. Se un'altra azienda tratta dati personali per vostro conto, il contratto che regola quel rapporto deve essere strutturalmente solido.
Questo va ben oltre l'ambito legale. Un DPA solido impone chiarezza su chi può accedere ai dati, su come vengono gestite le escalation degli incidenti, su cosa succede alla fine del contratto e su come il vostro team possa verificare tutto questo. Conta anche quando esaminate i termini sulla privacy di un fornitore, come la privacy policy pubblicata da digna, perché gli impegni pubblici e quelli contrattuali devono essere allineati.
Indice
Introduzione: il DPA nella vostra casella di posta
Lo schema è noto. Un responsabile di business dice che il fornitore è a basso rischio perché è “solo software”. La sicurezza chiede se il fornitore conserva dati dei clienti. L'ufficio legale chiede il DPA. Nessuno è d'accordo su quale sia il rischio effettivo, e la trattativa si blocca.
Una buona revisione del DPA inizia respingendo due cattivi istinti. Il primo è firmare il testo del fornitore così com'è perché il progetto sembra urgente. Il secondo è modificare ogni clausola senza capire quali punti sono obbligatori per legge, quali sono prassi di mercato e quali dipendono dall'architettura.
Perché questo documento conta dal punto di vista operativo
Un DPA stabilisce come lavorerete insieme quando le cose vanno male, non solo quando tutto funziona. Se un responsabile del trattamento ricorre a un nuovo sub-responsabile, subisce un incidente o conserva i dati più a lungo del previsto, il DPA è il documento che determina se avrete margine di intervento o solo giustificazioni.
Ecco perché i team più maturi considerano il DPA parte della governance dei fornitori, non una semplice sistemazione contrattuale. Data engineering, sicurezza, privacy, procurement e responsabili di piattaforma devono leggerlo ciascuno dalla propria prospettiva.
Regola pratica: se il vostro team non sa spiegare in parole semplici cosa può fare il fornitore con i vostri dati, il DPA non è pronto per la firma.
Cosa controllano per primo i team più esperti
Prima che qualcuno modifichi il testo, verificate tre aspetti di base:
Chiarezza dei ruoli: il fornitore agisce come responsabile del trattamento o opera con un ruolo giuridico diverso?
Realismo dei flussi di dati: il contratto descrive ciò che il prodotto fa davvero, inclusi percorsi di accesso, modello di hosting e modello di supporto?
Dettagli applicabili: gli obblighi sono abbastanza specifici da poter essere verificati in seguito tramite evidenze, log, report o materiale di audit?
Quest'ultimo punto viene spesso trascurato. Nella pratica i contratti falliscono quando si basano su promesse generiche senza alcuna possibilità di verifica.
Che cos'è un accordo sul trattamento dei dati
Un accordo sul trattamento dei dati è il contratto vincolante che stabilisce le regole quando un'organizzazione tratta dati personali per conto di un'altra. Il titolare del trattamento decide perché e come i dati personali devono essere trattati. Il responsabile del trattamento svolge quel lavoro seguendo le istruzioni del titolare.
Consideratelo il manuale operativo del trattamento delegato dei dati
Il modo più semplice per spiegare un DPA è questo. State conferendo a un'altra azienda un'autorità limitata per trattare dati di cui restate comunque responsabili. Il DPA definisce i confini di questa autorità.
Se il fornitore ospita un CRM, una piattaforma di gestione paghe, uno strumento di assistenza, un servizio di analytics o un ambiente dati in cloud che tratta dati personali per vostro conto, il DPA gli dice cosa può fare, cosa deve proteggere, chi altro può coinvolgere e come deve aiutarvi se un interessato o un'autorità di controllo bussa alla porta.
La distinzione tra titolare e responsabile del trattamento
Questa distinzione sembra un tecnicismo giuridico, ma ha conseguenze pratiche.
Ruolo | Cosa decide | Principale responsabilità pratica |
|---|---|---|
Titolare | Finalità e mezzi del trattamento | Sceglie il fornitore, impartisce le istruzioni, verifica la compliance |
Responsabile | Come erogare operativamente il servizio nel rispetto di quelle istruzioni | Protegge i dati, rispetta il contratto, supporta il titolare |
Un titolare non può esternalizzare la propria accountability solo perché un fornitore è affidabile. Un responsabile non può accettare istruzioni vaghe e presumere che sia un problema di qualcun altro. Entrambe le parti hanno bisogno di un DPA che rispecchi il servizio effettivo.
Che cosa costituisce trattamento nella realtà
Il trattamento non si limita alla semplice conservazione o all'analisi. Può includere l'accesso durante il supporto, la gestione dei backup, l'alerting, la trasformazione, l'arricchimento, il monitoraggio e i workflow di cancellazione. La domanda pratica è se il fornitore tratta dati personali per vostro conto in una qualsiasi di queste attività.
Ecco perché gli ingegneri devono partecipare. I team legali spesso esaminano le parole. Gli ingegneri sanno se il prodotto copia righe, gira all'interno del vostro ambiente o vede solo metadati. Queste differenze contano.
Un DPA fa la differenza tra “pensavamo che se ne occupasse il fornitore” e “il contratto dice esattamente chi deve fare cosa”.
Quando i team saltano questa verifica tecnica, firmano contratti che descrivono un sistema molto diverso da quello effettivamente installato.
Le otto clausole obbligatorie del DPA ai sensi del GDPR
Ai sensi dell'articolo 28, paragrafo 3, del GDPR, un DPA è obbligatorio per legge e deve includere esplicitamente otto disposizioni specifiche, tra cui istruzioni documentate, riservatezza, misure di sicurezza, regole sui sub-responsabili, assistenza per i diritti degli interessati, supporto in caso di violazione, cancellazione o restituzione dei dati e diritti di audit, come illustrato in questa sintesi dei requisiti del DPA secondo l'articolo 28.
Il minimo legale che non si può liquidare con superficialità
Se manca uno di questi elementi, il DPA non è semplicemente debole. Può essere non conforme. È il problema di base, ancora prima di arrivare alle preferenze negoziali.
Ecco cosa significa davvero ciascuna clausola nella pratica.
Solo istruzioni documentate
Il responsabile non può decidere autonomamente di riutilizzare i vostri dati per altri scopi. Se intende usare i dati dei clienti per l'addestramento di modelli, analisi interne o il miglioramento del prodotto, ciò deve essere espressamente autorizzato o escluso.Obblighi di riservatezza
Chiunque abbia accesso ai dati deve essere vincolato alla riservatezza. Nella pratica, volete che questo obbligo copra dipendenti, collaboratori esterni e personale di supporto, non che si limiti a una promessa generica dell'azienda.Misure di sicurezza ai sensi dell'articolo 32
Il DPA dovrebbe collegare gli impegni di sicurezza a controlli reali. Ciò include controllo degli accessi, cifratura, monitoraggio e gestione degli incidenti. Se il vostro team lavora tra più regioni, è utile anche allineare questo aspetto ai vostri requisiti di residenza dei dati.Autorizzazione dei sub-responsabili
I fornitori raramente operano da soli. Hosting in cloud, piattaforme di supporto e fornitori di infrastruttura possono trovarsi tutti a valle. Il DPA deve prevedere una regola per l'autorizzazione scritta preventiva, la notifica e il trasferimento a cascata degli obblighi.
Le clausole che determinano l'operatività quotidiana
Le clausole restanti diventano critiche una volta che il prodotto è in produzione.
Assistenza per i diritti degli interessati: se qualcuno chiede accesso, rettifica, cancellazione o limitazione, il responsabile deve aiutare il titolare a rispondere.
Supporto per violazioni e DPIA: il responsabile deve assistere nella risposta alle violazioni e, ove pertinente, nelle valutazioni d'impatto sulla protezione dei dati.
Cancellazione o restituzione alla cessazione: un contratto senza meccanismi di uscita chiari diventa spesso, in seguito, un problema di conservazione dei dati.
Diritti di audit e di informazione: avete bisogno di un modo per verificare la compliance, che sia tramite documenti, report o una revisione più approfondita.
Se un responsabile dice “fidatevi del nostro team di sicurezza” ma si oppone a fornire evidenze, il DPA si regge più sulla fiducia che sulle prove.
Come si presenta una buona redazione
I DPA migliori non si limitano a ripetere la legge. La rendono operativa. Indicano chi riceve le notifiche degli incidenti, come vengono comunicate le modifiche ai sub-responsabili e cosa succede ai backup alla cessazione del contratto.
Si adattano anche al contesto. Un fornitore di analytics sanitarie, un provider di infrastruttura Web3 e una piattaforma HR non avranno bisogno degli stessi allegati né dello stesso percorso di revisione. Ecco perché i team che operano in ambienti affini e fortemente regolamentati prendono spesso spunto da materiali di settore come questa guía de cumplimiento para empresas Web3, per poi adattare il testo contrattuale alla propria realtà di trattamento invece di affidarsi a un modello SaaS generico.
Una checklist pratica per redigere e rivedere i DPA
La maggior parte dei problemi dei DPA non deriva dall'assenza di parole chiave. Nasce da un ambito vago, da una formulazione approssimativa sulla sicurezza e da termini che nessuno è in grado di applicare una volta firmato l'accordo.
Partite dal trattamento reale, non dal modello
Prima di esaminare le clausole, mappate il servizio:
Quali dati sono coinvolti: identificate se il fornitore tratta record dei clienti, dati dei dipendenti, dati di log, ticket di assistenza o solo metadati tecnici.
Dove si spostano i dati: verificate se i dati vengono copiati, memorizzati in cache, esportati, consultati da remoto o mantenuti interamente nel vostro ambiente.
Chi vi accede: includete team interni, sub-responsabili, percorsi di accesso del supporto e strumenti di amministrazione.
Questo esercizio previene un errore comune: i team negoziano modifiche su un documento che fin dall'inizio non descrive correttamente il prodotto.
La checklist di revisione che userei nella pratica
Usatela come revisione operativa, non solo come controllo legale.
La descrizione del trattamento è specifica: il DPA dovrebbe indicare natura e finalità del trattamento con un livello di dettaglio sufficiente perché un revisore della sicurezza possa verificarle.
L'ambito dei dati personali è delimitato: le categorie di dati e di interessati non dovrebbero essere così ampie da autorizzare più di quanto il servizio richieda.
Il linguaggio sulla sicurezza è verificabile: cercate riferimenti a controlli concreti, procedure documentate ed evidenze disponibili.
Il processo per i sub-responsabili è utilizzabile: periodi di preavviso, modalità di opposizione e obblighi a cascata dovrebbero essere abbastanza chiari da poter essere gestiti.
Il supporto alle richieste degli interessati è assegnato: qualcuno deve essere responsabile di ricezione, escalation e supporto alla risposta.
La gestione delle violazioni è credibile dal punto di vista operativo: eventi che fanno scattare la notifica, canali di comunicazione e contenuti minimi devono essere praticabili sotto pressione.
I termini di uscita sono espliciti: restituzione dei dati, cancellazione, copie residue e gestione dei backup non dovrebbero essere lasciati a verifiche informali successive.
I diritti di audit sono equilibrati: avete bisogno di diritti di verifica, ma devono essere adeguati al modello di servizio e al livello di rischio.
Dove i team dovrebbero andare oltre il minimo indispensabile
La legge vi dà una soglia minima. La gestione del rischio spesso richiede di più.
Una revisione matura si chiede se il regime di responsabilità corrisponda alla sensibilità dei dati, se gli allegati sulla sicurezza siano aggiornati e se i responsabili delle diverse funzioni conoscano i propri obblighi. Negli ambienti con una forte componente HR, ad esempio, molte delle stesse domande di revisione compaiono in risorse operative più ampie come questa guida completa alla protezione dei dati per i responsabili HR, anche se il testo contrattuale va comunque adattato al rapporto con il fornitore.
Test pratico: se il vostro responsabile della sicurezza, il consulente privacy e il responsabile della piattaforma interpreterebbero una clausola in tre modi diversi, riscrivetela prima della firma.
Negoziare il DPA: il confronto su audit e sicurezza
La maggior parte delle negoziazioni sui DPA non si arena sull'esistenza dei diritti di audit, ma su cosa significhi concretamente un audit.
I titolari vogliono una verifica diretta. I responsabili vogliono un modello di revisione scalabile che non consenta a ogni cliente di condurre una valutazione su misura sulle operations in produzione. Entrambe le posizioni sono comprensibili. Il problema nasce quando ciascuna parte considera la propria preferenza come l'unica risposta conforme.
Perché la clausola di audit crea tanti attriti
Circa l'80% delle negoziazioni sui DPA si blocca sulla clausola di audit, e un compromesso pratico consiste nel far fornire al responsabile certificazioni come SOC 2 o ISO fin dall'inizio, riservando gli audit in loco ai soli casi di insufficienza documentata, secondo questa analisi dei punti critici più comuni nei DPA.
Questo compromesso funziona perché separa le garanzie di routine dall'escalation eccezionale. Il titolare ottiene rapidamente evidenze significative. Il responsabile evita continue interruzioni operative.
Un modello di negoziazione praticabile
Ho constatato che questa struttura sblocca le trattative senza svuotare i diritti del titolare:
Tema | Preoccupazione del titolare | Preoccupazione del responsabile | Compromesso pratico |
|---|---|---|---|
Garanzie di routine | Serve una prova della compliance | Troppi audit personalizzati | Condividere prima certificazioni, sintesi e documentazione sulla sicurezza |
Ispezione approfondita | Serve un rimedio se le evidenze sono deboli | Le verifiche in loco sono invasive | Consentire audit mirati in caso di insufficienza documentata o di incidenti |
Ambito e tempistiche | Serve un accesso tempestivo | Richieste illimitate esauriscono i team | Definire periodi di preavviso, frequenza, ambito e riservatezza |
Questo approccio è anche più coerente con il funzionamento dei moderni programmi di sicurezza. Molti rischi possono essere verificati tramite evidenze sui controlli, governance degli accessi, risultati dei test e materiale di logging, anziché con ripetute visite fisiche. I team che adottano solide tecniche di monitoraggio e audit dei database hanno di solito una base molto migliore per queste discussioni, perché possono dimostrare la tracciabilità invece di affidarsi a rassicurazioni.
Gli allegati sulla sicurezza contano quanto i diritti di audit
La clausola di audit attira l'attenzione, ma spesso è l'allegato sulla sicurezza a meritare la revisione più rigorosa. Un allegato credibile dovrebbe coprire la cifratura dei dati a riposo e in transito, test di sicurezza regolari come penetration test e vulnerability scan, procedure documentate di risposta alle violazioni, obblighi a cascata per i sub-responsabili, catene di autorizzazione per i trasferimenti incluse le SCC e audit trail per l'accesso ai dati e le attività di trattamento, come descritto in questa panoramica pratica delle specifiche di sicurezza dei DPA.
È qui che una revisione tecnica esterna può aiutare. Se un fornitore dichiara solide misure di protezione in un ambiente regolamentato, servizi indipendenti come Affordable Pentesting HIPAA services possono aiutare i team a verificare se i controlli descritti nei contratti trovano riscontro nelle pratiche di sicurezza effettive.
Non negoziate una clausola di audit spettacolare per poi accettare un allegato sulla sicurezza scarno. È nell'allegato che si trova la maggior parte del rischio reale.
I DPA per piattaforme in-database come digna
Molti team presumono ancora che ogni strumento per i dati richieda la stessa struttura di DPA. Questa ipotesi non regge quando si guarda all'architettura.
La domanda preliminare che la maggior parte dei modelli ignora
Se una piattaforma gira all'interno del vostro ambiente, non esporta righe e il fornitore non accede ai dataset di produzione, avete davvero a che fare con lo stesso modello di responsabile del trattamento di una piattaforma SaaS convenzionale che copia e ospita i dati dei clienti nel proprio cloud?
Spesso no. E la distinzione conta. Una lacuna comune nella copertura dei DPA riguarda il trattamento degli strumenti che non elaborano PII: il 60% delle aziende presume erroneamente che un DPA sia necessario per tutti gli strumenti per i dati, mentre le piattaforme in cui il fornitore non accede ai dataset di produzione vengono spesso gestite male dai modelli generici, come osservato in questa discussione sulle questioni di applicabilità dei DPA.
Il punto non è se un DPA sia sempre negativo o superfluo. Il punto è che l'analisi legale e operativa cambia quando cambia l'architettura del fornitore.
Perché l'esecuzione in-database cambia il modello di rischio
I DPA SaaS tradizionali sono costruiti attorno a un modello di trasferimento. I dati escono dal vostro ambiente. Il fornitore li conserva o li elabora su un'infrastruttura che controlla. Questo crea evidenti obblighi nel DPA su accesso, conservazione, sub-responsabili, meccanismi di trasferimento e cancellazione.
I sistemi in-database sono diversi. La logica gira dove i dati già risiedono. Questo può restringere in modo sostanziale il ruolo del fornitore, se il fornitore non accede né estrae i record sottostanti.
Questo conta in particolare per i casi d'uso di observability e qualità. Il rilevamento delle anomalie nei dati è il processo di identificazione dei punti dati che si discostano in modo significativo dai pattern o dalle tendenze attesi in un dataset, come descritto in questa definizione di anomaly detection. Le piattaforme moderne usano spesso il rilevamento delle anomalie basato sull'AI, che applica il machine learning per individuare pattern insoliti senza affidarsi solo a regole statiche, come spiegato in questa panoramica sul rilevamento delle anomalie con l'AI. Un metodo comune è l'apprendimento non supervisionato, che individua le deviazioni rispetto ai pattern scoperti senza richiedere dati etichettati, secondo questa sintesi delle tecniche di anomaly detection. Nella pratica, ciò consente a un sistema di monitoraggio di apprendere il comportamento normale e di far emergere rapidamente variazioni insolite su grandi volumi, che è il valore centrale descritto in questa guida al rilevamento delle anomalie con l'AI.
Dal punto di vista contrattuale, però, la domanda chiave è più ristretta del metodo tecnico. Il fornitore tratta dati personali per vostro conto, oppure il software viene eseguito all'interno del vostro ambiente senza che il fornitore acceda a quei dati?
Cosa verificare invece di ricorrere a un generico DPA SaaS
Per gli strumenti in-database, la revisione del contratto dovrebbe concentrarsi su domande coerenti con l'architettura:
Modello di accesso del fornitore: il fornitore può vedere righe di produzione durante il supporto, il troubleshooting o la raccolta di telemetria?
Gestione dei metadati: la piattaforma esporta dettagli dello schema, metriche, alert o log che, nel contesto, potrebbero comunque qualificarsi come dati personali?
Amministrazione remota: esistono meccanismi di accesso di emergenza (break-glass) e chi li approva?
Perimetro di esecuzione: tutta l'elaborazione resta all'interno dell'ambiente controllato dal cliente?
Profilo degli output: i risultati sono aggregati, statistici o comunque separati da dati personali diretti a livello di riga?
Uno strumento può comunque richiedere clausole contrattuali sulla protezione dei dati per metadati, canali di supporto o accessi amministrativi limitati. Ma è cosa diversa dall'inserire alla cieca lo stesso DPA che usereste per un SaaS che ospita dati dei clienti.
Un approccio più intelligente alla compliance
Per queste piattaforme la risposta pratica di solito non è “non usate mai un DPA”, ma “usate il documento giusto per il trattamento effettivo”. A volte sarà un DPA più circoscritto. Altre volte saranno solide clausole su sicurezza e accessi nel contratto principale, più un allegato privacy limitato.
Ecco perché i team che valutano architetture di observability moderne dovrebbero esaminare il modello del prodotto in sé, non solo la checklist di procurement. Un approccio basato su una piattaforma di data quality in-database cambia il modo in cui i dati si spostano, dove si colloca il rischio e cosa dovrebbe ragionevolmente coprire un contratto.
Se il fornitore non accede mai ai dataset di produzione, il vostro contratto dovrebbe riflettere questa realtà invece di fingere che il servizio funzioni come un normale responsabile del trattamento in hosting.
Conclusione: il DPA come asset strategico
I team migliori non considerano un accordo sul trattamento dei dati un ostacolo legale. Lo usano come strumento di controllo.
Un DPA solido porta allo scoperto il rapporto con il fornitore. Chiarisce le istruzioni, blinda gli accessi, fissa le aspettative sugli incidenti, regola i sub-responsabili e dà al vostro team un modo per verificare che il contratto corrisponda al sistema che state acquistando. Ecco perché la qualità dell'accordo conta più della sua semplice esistenza.
Conviene anche smettere di trattare tutti i fornitori allo stesso modo. Una piattaforma SaaS convenzionale che ospita dati dei clienti richiede un certo tipo di verifica. Uno strumento in-database senza accesso del fornitore ai dataset di produzione può richiedere un approccio contrattuale del tutto diverso. Se il vostro team non coglie questa distinzione architetturale, finirà per creare oneri legali inutili oppure per lasciare un'esposizione reale documentata in modo insufficiente.
L'approccio pratico è semplice. Conoscete le clausole obbligatorie. Insistete su un linguaggio utilizzabile dal punto di vista operativo. Negoziate i diritti di audit pensando alle evidenze, non alla messinscena. E verificate sempre la carta rispetto al design tecnico.
È così che un DPA diventa utile. Non come un PDF firmato in un archivio contrattuale, ma come parte attiva del vostro modello di data governance.
Se il vostro team sta valutando strumenti moderni di data quality e observability, digna merita un'analisi attenta. È progettata per l'esecuzione in-database, il rilevamento delle anomalie, la validazione, il monitoraggio della tempestività e il tracciamento dello schema all'interno di ambienti controllati dal cliente, il che la rende particolarmente adatta alle organizzazioni che vogliono un controllo più solido sui dati senza estendere l'accesso dei fornitori ai dataset di produzione.
Se volete vedere come si presenta un perimetro di esecuzione all'interno di un ambiente controllato dal cliente per il monitoraggio, leggete come la data platform observability di digna analizza i dati dove già risiedono.
Domande frequenti
Che cos'è un accordo sul trattamento dei dati?
Un accordo sul trattamento dei dati (DPA) è il contratto vincolante che stabilisce le regole quando un'organizzazione tratta dati personali per conto di un'altra. Il titolare decide perché e come i dati personali vengono trattati, il responsabile svolge quel lavoro seguendo le istruzioni del titolare e il DPA definisce i confini di questa autorità.
Quali clausole deve contenere un accordo sul trattamento dei dati secondo il GDPR?
L'articolo 28, paragrafo 3, del GDPR richiede otto disposizioni: istruzioni documentate, riservatezza, misure di sicurezza ai sensi dell'articolo 32, regole sui sub-responsabili, assistenza per i diritti degli interessati, supporto per violazioni e DPIA, cancellazione o restituzione dei dati alla cessazione e diritti di audit. Se ne manca una, il DPA può risultare non conforme, non solo debole.
Qual è la sanzione per la mancanza di un DPA ai sensi del GDPR?
Le organizzazioni prive di un DPA valido sono esposte a sanzioni fino a 10 milioni di euro o al 2 percento del fatturato annuo mondiale ai sensi dell'articolo 83, paragrafo 4. L'articolo aggiunge che, a marzo 2025, le autorità europee per la protezione dei dati avevano inflitto sanzioni GDPR per circa 5,6 miliardi di euro.
Come si negozia la clausola di audit in un DPA?
Un compromesso pratico prevede che il responsabile condivida fin dall'inizio certificazioni come SOC 2 o ISO, sintesi e documentazione sulla sicurezza, riservando gli audit in loco ai casi di insufficienza documentata o di incidenti. Definite periodi di preavviso, frequenza, ambito e riservatezza. L'articolo cita un'analisi secondo cui circa l'80 percento delle negoziazioni sui DPA si blocca su questa clausola.
Gli strumenti di data quality in-database richiedono un DPA?
Dipende dall'accesso del fornitore, non dalla categoria dello strumento. Se l'elaborazione resta nel vostro ambiente e il fornitore non accede mai alle righe di produzione, un generico DPA SaaS spesso descrive il servizio in modo errato. Verificate l'accesso del supporto, i metadati esportati, l'amministrazione di emergenza (break-glass) e il profilo degli output; a volte è più adatto un DPA più circoscritto o un allegato privacy limitato.
