La privacy non è solo un documento
Ogni moderno prodotto SaaS ha un'informativa sulla privacy. La maggior parte dice le cose giuste.
Descrivono quali dati vengono raccolti, come vengono utilizzati, quali categorie di destinatari li ricevono, per quanto tempo vengono conservati e come un cliente può esercitare i propri diritti.
Questo è necessario, ma non basta.
Un'informativa sulla privacy ti dice cosa un fornitore promette di fare. L'architettura del prodotto ti dice cosa potrebbe fare.
Se una policy dice "non vendiamo i tuoi dati" ma l'architettura è costruita su un'infrastruttura ad-tech, allora la policy sta facendo gran parte del lavoro. Se una policy dice "manteniamo i tuoi dati al sicuro" ma il sistema è tenuto insieme da venti servizi esterni, allora la policy sta facendo promesse su parti del sistema che il fornitore non può controllare completamente.
Crediamo che la privacy debba essere visibile prima nell'architettura e solo dopo descritta nella policy.
Cosa significa davvero "by architecture"
Privacy by architecture è l'idea che la struttura stessa del sistema debba limitare il modo in cui i dati possono essere raccolti, consultati, trattati e condivisi.
È la differenza tra "scegliamo di non fare X" e "abbiamo costruito la piattaforma in modo che X sia poco praticabile".
La prima è una cultura. La seconda è un vincolo.
Le culture cambiano. I vincoli sono stabili.
Le decisioni che la definiscono
La privacy by architecture non è una singola funzionalità. È una sequenza di piccole decisioni, ripetute nel corso degli anni.
Scegliere di gestire i componenti internamente invece di instradare i dati attraverso servizi esterni. Scegliere di ridurre al minimo le categorie di dati che raccogliamo. Scegliere di non integrarsi con ecosistemi pubblicitari o di tracciamento comportamentale. Scegliere di archiviare i dati aziendali nelle regioni che i nostri clienti si aspettano. Scegliere di mantenere isolati gli spazi di lavoro. Scegliere di non analizzare i contenuti dei clienti per ottenere insight di marketing.
Nessuna di queste decisioni è di per sé eclatante. È l'effetto cumulativo a dare forma alla piattaforma.
Cosa deliberatamente non raccogliamo
Un esercizio utile è l'opposto del tipico riepilogo sulla privacy.
Non raccogliamo profili comportamentali del tuo team per il targeting pubblicitario. Non registriamo replay delle sessioni di utilizzo dello spazio di lavoro. Non implementiamo tracciamento cross-site da reti pubblicitarie all'interno della piattaforma autenticata. Non raccogliamo dati di cui non possiamo giustificare la necessità.
Ogni dato aggiuntivo che una piattaforma raccoglie è una decisione sulla privacy. La maggior parte delle piattaforme sbaglia dalla parte del troppo. Noi sbagliamo dalla parte del meno.
Cosa deliberatamente non condividiamo
Non c'è rivendita delle informazioni dei clienti. Non c'è condivisione con partner di marketing. Non c'è una pipeline verso data broker. Non c'è alcun dataset "anonimizzato" concesso in licenza a terze parti.
Quando un fornitore dice "potremmo condividere dati aggregati e anonimizzati con i nostri partner", vale la pena capire cosa quella frase consente davvero. Noi non volevamo scriverla.
Cosa deliberatamente non conserviamo per sempre
La conservazione dei backup esiste, per ragioni di affidabilità operativa e obblighi normativi. Documentiamo i nostri periodi di conservazione nella Privacy Policy.
Ma al di fuori di queste finestre di conservazione esplicite, eliminiamo ciò di cui non abbiamo più bisogno. Non manteniamo indefinitamente le informazioni dei clienti come impostazione predefinita. Non teniamo pronti i dati degli account chiusi nel caso in cui "potresti tornare". Non accumuliamo informazioni in vista di future idee di prodotto.
Se non avevamo bisogno di conservarli, li eliminiamo.
Perché la minimizzazione conta
La minimizzazione dei dati è uno dei principi fondamentali del GDPR. È anche buona ingegneria.
Ogni dato aggiuntivo che un sistema archivia è qualcosa che deve essere protetto, messo in sicurezza, sottoposto a backup, replicato, mantenuto conforme e infine eliminato. Meno dati significa meno superficie da difendere.
Per i nostri clienti significa anche meno preoccupazioni. Le informazioni che esistono sono quelle che inserisci tu, non una lunga ombra di metadati comportamentali che qualcuno, da qualche parte, potrebbe prima o poi trovare utili.
Perché l'isolamento conta
Ogni workspace KIMISUITE è logicamente isolato da tutti gli altri. I dati della tua azienda non si mescolano ai contenuti di altri clienti. Le operazioni tra workspace non avvengono per impostazione predefinita. Le funzionalità cross-workspace sono facoltative ed esplicite.
Questo isolamento è integrato nel funzionamento della piattaforma, non solo nella policy.
Perché l'architettura batte il marketing
Per qualsiasi fornitore è facile scrivere "la privacy è nel nostro DNA" su una pagina di marketing. Non costa nulla.
È più difficile prendere decisioni architetturali che vincolano la piattaforma stessa, decisioni che devono essere difese ogni volta che emerge un requisito concorrente.
I team interni chiederanno più dati comportamentali. I team commerciali chiederanno profili cliente più ricchi. Il marketing vorrà replay di sessione. Qualche futuro investitore suggerirà di monetizzare dataset "anonimizzati".
La risposta a tutto questo, per architettura e per intenzione, è no.
Considerazioni finali
Una policy sulla privacy può descrivere ciò che un fornitore vuole fare.
L'architettura di una piattaforma decide ciò che un fornitore può fare.
Abbiamo scelto di far coincidere le due cose e di continuare a mantenerle allineate mentre la piattaforma cresce.
Se la tua azienda archivia informazioni importanti all'interno di una piattaforma SaaS, vale la pena esaminare attentamente questa corrispondenza.
Continua a leggere la Trust Series:
← Precedente: Chi può accedere ai dati della tua azienda?
→ Successivo: Cosa succede ai tuoi dati quando annulli?
Inizia la tua prova gratuita di 14 giorni · Scopri i prezzi di KIMISUITE