Sicurezza

GDPR su una piattaforma condivisa: le scelte che contano davvero

Sulle piattaforme usate da più aziende la conformità non si ottiene con un documento: si ottiene con scelte prese in fase di costruzione. Isolamento imposto dal database e non dal codice, minimizzazione dei dati, ruoli espliciti, registro delle richieste e prove di ripristino che verificano anche le protezioni. Un'informativa perfetta su un impianto sbagliato non protegge nessuno.

27 ago 2026 · 10 min di lettura

Quando un'azienda ci chiede se la sua piattaforma è "a norma", la conversazione parte quasi sempre dall'informativa e dai consensi. Sono la parte visibile, e sono necessari. Ma se i dati di due clienti diversi possono finire nella stessa schermata per un errore di programmazione, nessuna informativa vi salva.

La protezione dei dati, su una piattaforma usata da più aziende, si decide in cinque punti — e tutti e cinque si decidono mentre si costruisce, non dopo. Le raccontiamo come le abbiamo affrontate su un CRM che ospita una rete di agenzie: casa madre, aziende partner e persone che lavorano per più di una.

1. L'isolamento deve stare nel database, non nel codice

È la decisione più importante e la meno visibile. In una piattaforma condivisa, ogni interrogazione ai dati deve essere filtrata sull'azienda di chi sta guardando. Se quel filtro vive nel codice, prima o poi qualcuno scriverà una funzione nuova e lo dimenticherà: non per incompetenza, ma perché su qualche migliaio di righe capita.

Quel giorno un cliente vede i dati di un altro, e la cosa peggiore è che nessuno se ne accorge: nessun errore, nessun allarme, solo righe di troppo su una schermata.

La scelta che facciamo è mettere la regola dentro il database, con politiche di accesso per riga, e collegare l'applicazione con un'utenza che non ha il potere di scavalcarle. Il codice può sbagliare; il database no. Il permesso diventa un dato che si può leggere e revocare, invece di un ramo di codice sparso in trenta file.

Se la protezione dipende dal fatto che nessuno sbagli, non è una protezione: è una speranza.Il principio che applichiamo alle piattaforme condivise

2. Raccogliere meno è più semplice che proteggere di più

La minimizzazione è il principio più citato e meno praticato. In concreto significa fare, per ogni campo del modulo, una domanda scomoda: a cosa ci serve? Se la risposta è "potrebbe servire", quel campo è un rischio senza contropartita.

Un dato che non avete raccolto non può essere rubato, non va anonimizzato, non compare in un backup da gestire e non entra in una richiesta di accesso. È l'unica misura di sicurezza che non costa nulla mantenere.

Vale anche per la profondità storica: conservare tutto per sempre è una scelta, e va giustificata. Sapere per quanto tempo tenete ogni categoria di dato — e cancellarla davvero quando scade — è metà del lavoro di conformità.

3. I ruoli sono un dato, non una serie di eccezioni

Nella rete di agenzie di cui parlavamo, la struttura ha tre livelli: la rete raggruppa aziende che condividono un perimetro di strumenti, l'azienda è il cliente, la persona può lavorare per più aziende e la sessione ricorda su quale sta operando.

La tentazione, in casi così, è scrivere eccezioni: "se è la casa madre allora vede tutto". Abbiamo fatto il contrario: la casa madre è un'azienda con un tipo diverso, e il privilegio è un dato. Un dato si legge, si revoca e — soprattutto — lo capisce anche il database, cosa che una condizione nel codice non permette.

L'effetto pratico è che il menu non disegna nemmeno le voci che quel perimetro non prevede: chi è operatore e non titolare vede la scheda azienda in sola lettura senza che nessuno debba ricordarsi di nasconderla.

4. Le richieste degli interessati vanno gestite prima che arrivino

Chiunque ha diritto di sapere quali suoi dati avete, di correggerli, di ottenerne una copia e in molti casi di farli cancellare. Il momento sbagliato per scoprire come si fa è quando arriva la richiesta, con un mese di tempo per rispondere.

Le cose che rendono la differenza fra un pomeriggio e una settimana di panico sono tre: sapere dove vivono i dati di una persona (in quante tabelle, in quali allegati, in quali sistemi esterni), avere un modo per esportarli in un formato leggibile, e tenere un registro delle richieste ricevute con cosa è stato fatto e quando.

Su quella piattaforma il registro è parte del prodotto, non un foglio di calcolo tenuto a parte: è la prova che serve se qualcuno vi chiede conto di come avete risposto.

5. Cancellare non è sempre cancellare (e i backup complicano tutto)

Qui c'è una tensione reale, e chi la nasconde non vi sta aiutando. Da un lato una persona può chiedere la cancellazione; dall'altro non potete buttare via una fattura, che va conservata per legge.

La strada praticabile è distinguere: quello che serve per obbligo resta, tutto il resto si anonimizza — si spezza il legame fra il dato e la persona, mantenendo i numeri per la contabilità. Il documento fiscale sopravvive; l'identità no.

Poi ci sono i backup, che per definizione contengono ieri. Cancellare oggi non riscrive le copie di ieri, e riscriverle sarebbe peggio: significherebbe poterle manomettere. L'approccio accettato è dichiarare per quanto tempo le copie vivono, non ripescarle per rimettere in circolo dati cancellati, e tenerle protette come i dati vivi. È una posizione che va scritta, non improvvisata quando qualcuno la chiede.

La prova che quasi nessuno fa

C'è un controllo che consigliamo a chiunque abbia una piattaforma con dati di più clienti, e che quasi nessuno esegue: ripristinare un backup e verificare che le protezioni tornino su davvero.

Non contare che le regole esistano: contarle non basta. Bisogna collegarsi come farebbe l'applicazione, senza dichiarare per conto di chi si sta guardando, e verificare che non torni indietro nessuna riga. Se l'utenza fosse tornata su con i privilegi sbagliati, il conteggio delle regole sarebbe identico e ogni cliente vedrebbe i dati degli altri — in silenzio, fino al giorno in cui qualcuno se ne accorge.

Su quella piattaforma questa prova gira automaticamente ogni settimana su un database usa e getta, che poi viene cancellato. Il ripristino non tocca mai il database in uso: ne crea uno nuovo, così se non convince si può ancora tornare indietro.

Nessuna di queste cinque scelte compare in un'informativa, e tutte e cinque decidono se i dati dei vostri clienti sono davvero separati. Se state costruendo una piattaforma condivisa, sono le domande da fare a chi la sta scrivendo — adesso, non alla prima verifica.