Progettare il modello dati CRM: strutturare contatti, aziende e relazioni

Perché il modello dati anticipa la conformità alla LPD

La Legge federale sulla protezione dei dati (LPD) riveduta è in vigore dal 1° settembre 2023, insieme all’Ordinanza sulla protezione dei dati (OPD) e all’Ordinanza sulle certificazioni in materia di protezione dei dati (OCPD). I sette principi della LPD possono essere tradotti direttamente in decisioni di modellazione.

La liceità richiede una base giuridica; la buona fede impone un trattamento trasparente e un’informativa sulla privacy aggiornata; la proporzionalità richiede di minimizzare i campi obbligatori. La finalità del trattamento esige che lo scopo dell’utilizzo sia registrato nel CRM; l’esattezza richiede una pulizia regolare dei dati; la limitazione della conservazione impone termini di cancellazione automatici; la sicurezza dei dati richiede crittografia e controlli degli accessi.

Questi principi sono prescritti dalla legge, non facoltativi. L’autorità di vigilanza competente è l’IFPDP; le sue nuove competenze sottolineano l’urgenza di chiarire proporzionalità, finalità del trattamento e concetti di cancellazione già nella fase di scelta e configurazione di uno strumento CRM.

Le correzioni tardive sono costose: secondo WEKA, l’introduzione di uno strumento CRM richiede l’integrazione coerente della protezione dei dati in ogni fase del progetto, altrimenti si rischiano adattamenti successivi o il fallimento dell’iniziativa. Come conseguenze, WEKA cita sanzioni legali, ordinanze di cancellazione dei dati o interruzioni del trattamento dei dati.

Per il modello dati questo significa: ogni categoria di dati riceve due attributi – base giuridica e termine di cancellazione – e i campi obbligatori sono limitati a quanto richiesto dallo scopo. Proporzionalità, finalità del trattamento e limitazione della conservazione sono così integrate nello schema e non solo nel rapporto di progetto.

Principi della LPD e loro attuazione nel modello dati

Contatti e aziende come oggetti centrali separati

Le persone di contatto e le aziende appartengono a due oggetti con identità propria, invece di essere inserite in un set di dati misto. In questo modo è possibile definire campi obbligatori, basi giuridiche e termini di cancellazione per tipo: per un’azienda valgono motivi di conservazione diversi rispetto a una persona che lascia l’impresa.

Un esempio di modello dati comune è fornito da Microsoft Dynamics 365: il sistema utilizza un modello dati comune con integrazioni a Office 365, affinché le applicazioni aziendali interagiscano con gli strumenti di collaborazione e produttività.

I campi obbligatori devono essere limitati a quanto richiesto dallo scopo definito. tytos.ch indica esplicitamente la minimizzazione dei campi obbligatori come attuazione del principio di proporzionalità.

Per i dati CRM B2B, l’esecuzione contrattuale è spesso la base rilevante: indirizzo di consegna, dati di fatturazione e comunicazione non richiedono, secondo tytos.ch, un consenso separato e coprono la maggior parte dei dati CRM nell’ambito B2B.

Ciò che va oltre – interessi, indicazioni sull’origine, preferenze di marketing – appartiene a campi propri con giustificazione specifica, in modo che possa essere cancellato o bloccato singolarmente in seguito.

Una possibile suddivisione: indirizzo di consegna e dati di fatturazione sono legati all’azienda, mentre comunicazione e informazioni volontarie come interessi, indicazioni sull’origine e preferenze di marketing sono legate alla persona di contatto. In questo modo ogni categoria rimane indirizzabile e cancellabile singolarmente, anche se la persona cambia azienda.

Quattro indicazioni dovrebbero essere presenti in ogni oggetto: scopo dell’utilizzo, base giuridica per categoria di dati, termine di cancellazione e un campo di revoca per i consensi. Agiscono contemporaneamente come regole di verifica e fissano proporzionalità, finalità del trattamento e limitazione della conservazione direttamente nel modello.

Strutturare relazioni e ruoli in base alla finalità

Le relazioni sono rappresentate come oggetti propri: un’assegnazione di contatto ad azienda con ruolo, periodo di validità e fonte. Questo permette assegnazioni multiple – una persona presso più aziende, più interlocutori per azienda – senza duplicare i dati anagrafici.

Tecnicamente si tratta di una relazione n:m: contatto e azienda si confrontano più volte, l’oggetto relazione fa da mediatore tra i due. Chi conosce questa cardinalità crea formulari e valutazioni di conseguenza e tiene conto di persone che ricoprono ruoli in più aziende.

I duplicati sono anche una questione di esattezza: tytos.ch annovera la pulizia regolare dei dati tra i requisiti del principio di esattezza.

Ogni categoria di dati nell’oggetto relazione necessita di uno scopo dell’utilizzo documentato; tytos.ch cita la registrazione dello scopo dell’utilizzo nel CRM come attuazione della finalità del trattamento.

Per il cross-selling e up-selling presso clienti esistenti, secondo tytos.ch vale l’interesse preponderante come base, purché il cliente non si sia opposto, e la ponderazione degli interessi deve essere documentata.

Chi gestisce le responsabilità come assistenza clienti, vendite o supporto come ruolo nel modello, può basare questa ponderazione sul ruolo invece che sulle singole persone: in caso di cambio di collaboratori non rimane così alcuna lacuna.

Se un interlocutore cambia azienda, l’assegnazione esistente viene chiusa con una data di fine e ne viene creata una nuova. Il vecchio collegamento rimane tracciabile e ogni ruolo continua a portare la propria base giuridica.

Ancorare basi giuridiche e consensi nel modello

La LPD conosce diverse basi giuridiche che devono essere distinguibili nel modello: esecuzione contrattuale, interesse preponderante, consenso esplicito e obbligo legale. Per newsletter, campagne di marketing rivolte a non clienti e profilazione è necessario un consenso esplicito e informato; esso deve essere documentato nel CRM e revocabile in qualsiasi momento.

I consensi appartengono quindi al sistema come record di dati propri – con indicazione del momento, versione del testo del consenso, canale di acquisizione e un campo per la revoca. Una revoca che esiste solo in un’e-mail non può essere valutata nel modello; se è presente come record di dati, una query di segmentazione ne tiene conto prima dell’avvio di una campagna.

Per ogni categoria di dati si può inoltre registrare se essa si basa su esecuzione contrattuale, interesse preponderante, consenso o obbligo legale.

La base giuridica può essere registrata per gruppo di campi: indirizzo di consegna, dati di fatturazione e comunicazione si basano sull’esecuzione contrattuale, newsletter e campagne rivolte a non clienti sul consenso esplicito, cross-selling e up-selling presso clienti esistenti sull’interesse preponderante, documenti contabili sull’obbligo legale. In questo modo ogni gruppo di campi è assegnato a una base nel modello e verificabile singolarmente.

Basi giuridiche nel modello dati CRM: differenze e applicazione

Integrare termini di cancellazione e obblighi di conservazione

Limitazione della conservazione significa: cancellare quando lo scopo è raggiunto. tytos.ch associa al principio termini di cancellazione automatici.

Nel modello serve per questo una data di cancellazione calcolata per record di dati o per scopo – ad esempio ultimo contatto o fine del contratto – più uno stato che segnala i record per la verifica prima della cancellazione. In questo modo un processo automatico non rimuove inconsapevolmente relazioni commerciali attive.

L’obbligo legale prevale sul diritto alla cancellazione: i documenti contabili devono essere conservati per dieci anni, secondo tytos.ch. Questi dati appartengono a un’area bloccata, esclusa dalla cancellazione automatica.

I dati di marketing e vendita senza obbligo di conservazione devono essere gestiti separatamente, affinché una routine di cancellazione non colpisca i record sbagliati e l’obbligo di conservazione venga rispettato.

Procedura per l’attuazione del concetto di cancellazione nel CRM

Proteggere accessi, sicurezza dei dati e contratti con i fornitori

tytos.ch associa crittografia e controlli degli accessi al principio di sicurezza dei dati. I diritti basati sui ruoli devono essere definiti a livello di oggetto e di campo: chi ha bisogno di un indirizzo per l’invio non deve necessariamente poter accedere ai dati di solvibilità o di profilazione.

Secondo WEKA, i dati personali particolarmente sensibili e le profilazioni ad alto rischio richiedono una giustificazione rigorosa – questi campi non dovrebbero nemmeno essere ampiamente visibili.

Con i fornitori di CRM cloud si aggiungono aspetti contrattuali. WEKA raccomanda di prestare attenzione, nella scelta del fornitore, a misure tecniche e organizzative adeguate (TOM) nonché a garanzie contrattuali, e propone un accordo con il fornitore e una lista di domande come strumenti di lavoro.

Da chiarire concretamente sono il luogo di archiviazione, i subappaltatori coinvolti, la cancellazione alla fine del contratto, le vie di segnalazione in caso di violazione della protezione dei dati e la questione di quali dati il fornitore utilizzi per scopi propri. Per il caso grave – una violazione dei dati – gli uffici specializzati in protezione dei dati in Svizzera offrono supporto (Swiss Infosec).

Vantaggi e rischi del controllo degli accessi basato sui ruoli nel CRM

Ancorare il Privacy by Design nella quotidianità del progetto

Secondo tytos.ch, la protezione dei dati nel CRM non è un atto unico, ma un processo continuo. WEKA ne deriva la regola di progetto: la protezione dei dati deve essere pianificata in ogni fase del progetto, già nella scelta e nella configurazione.

Ciò include formazioni regolari dei collaboratori e verifiche periodiche – date fisse e responsabili nominati invece di una dichiarazione d’intenti.

La responsabilità deve essere regolata per iscritto: secondo tytos.ch, la multa fino a CHF 250'000 colpisce la persona fisica responsabile, non l’azienda.

Dove è necessaria una valutazione d’impatto sulla protezione dei dati (VIPD) o si verifica un incidente di protezione dei dati, sono disponibili uffici specializzati in protezione dei dati.