Salta al contenuto

Informativa privacy

Versione v0.4 · ultima revisione del corpus: . Tutti i testi legali.

BOZZA — documento tecnico-preparatorio, NON parere legale. Da validare con legale abilitato prima di qualsiasi uso. Bozza di informativa privacy. Titolare (= Cliente), DPO, basi giuridiche e trasferimenti sono da confermare con legale abilitato. Non usare prima della validazione. Documento predisposto per JURA Club (società titolare: QUANTANA S.R.L., titolare del trattamento); da validare con legale abilitato prima di qualsiasi uso. Il/i fornitore/i tecnico/i esterno/i è/sono responsabile/i del trattamento ex art. 28 per i soli trattamenti svolti per conto del Cliente (sviluppo/hosting/manutenzione), da disciplinare con DPA. Versione: v0.5 · Data: 2026-08-20 · Stato: DRAFT interno Novità v0.5: recepita D-165. È l'aggiornamento più favorevole dell'intero corpus sul piano GDPR: il titolo non risiede più su una catena pubblica, quindi nessun indirizzo riferibile a un interessato viene scritto in modo immutabile su rete pubblica. I due profili EDPB aperti nella v0.2 cambiano entrambi di segno — vedi il riquadro del §3. In compenso nasce un profilo nuovo: il registro è tenuto dal titolare del trattamento, e questo va dichiarato invece di essere presentato come un vantaggio e basta. Novità v0.3: inserito il committente reale QUANTANA S.R.L. (visura 24/07/2026) al posto del placeholder; aggiornate le formulazioni che dipendevano dalla sede del Cliente, ora nota: Italia → MiCAR, GDPR e TUF in via diretta. Novità v0.2: aggiunto il riquadro sulle Linee guida EDPB 02/2025 (versione finale 7 luglio 2026) e i due profili aperti da chiudere.

03 · Privacy Policy (GDPR) — JURA Club

1. Titolare del trattamento

Titolare del trattamento: QUANTANA S.R.L. (denominazione, sede/Stato, recapiti, PEC), operatore e titolare della piattaforma JURA Club.

⚖️ Da definire/confermare in capo al Cliente: eventuali contitolari e DPO (art. 37, da valutare: trattamento su larga scala di dati identità). Il rappresentante UE ex art. 27 non è necessario, perché il titolare è stabilito in Italia.

Responsabile del trattamento (art. 28): il/i fornitore/i tecnico/i esterno/i (responsabile del trattamento ex art. 28), da disciplinare con DPA, per i soli trattamenti svolti per conto del Cliente (sviluppo, hosting, manutenzione). Il fornitore tecnico esterno non è titolare del trattamento.

2. Categorie di dati trattati

CategoriaEsempiFonte
Dati identificativi (KYC)Nome, documento, dati anagrafici, verifica identitàOnboarding (obbligatorio per tutti, D-010)
Dati walletIndirizzo del titolare nel Registro, saldi JUS, storico delle operazioniPiattaforma / Registro privato
Dati del fascicolo documentaleDocumenti, atti, perizie (possibili dati personali di terzi)Caricamento creator, off-chain cifrato
Dati tecnici/logLog di accesso, audit trail, grant a tempoUso della Piattaforma

Nota sull'indirizzo del titolare: sebbene pseudonimo, se collegato all'identità KYC è dato personale. Risiede nel Registro privato tenuto dal titolare del trattamento, non su una catena pubblica: è quindi rettificabile e cancellabile con i mezzi ordinari.

3. Separazione dato ↔ prova (impianto tecnico)

  • I documenti (con eventuali dati personali) risiedono solo off-chain, in vault cifrato AES-256-GCM (D-003/D-016).
  • Il Registro su cui le quote esistono e circolano è privato, tenuto dal titolare del trattamento.
  • Sulla catena pubblica vive soltanto un'impronta — l'hash SHA-256 del documento (docRef) e l'impronta di ciascuna operazione registrata: non rivelano il contenuto, non contengono indirizzi in chiaro, saldi né identificativi, e non costituiscono dato personale in chiaro.
  • Conseguenza: la cancellazione avviene sul Registro e nel vault; l'impronta pubblica resta ma, privata del dato, non consente di risalire ad alcunché. ⚖️ Tesi da validare legalmente (art. 17 vs immutabilità).

Linee guida EDPB 02/2025 — blockchain e dati personali (versione finale adottata il 7 luglio 2026).

Aggiornamento del 2026-08-20 — i due profili aperti nella versione precedente cambiano entrambi di segno, e va spiegato perché. Fino al 19 agosto il titolo circolava su una rete pubblica: l'indirizzo del titolare vi era scritto in chiaro e in modo non cancellabile, e la scelta di una rete pubblica andava motivata proprio là dove le linee guida invitano a preferire il contrario. Il 20 agosto il committente ha deliberato un assetto a due piani: le quote vivono su un Registro privato, e sulla catena pubblica va soltanto l'impronta di ciascuna operazione — nessun token, nessun saldo, nessun indirizzo.

(a) La scelta della governance. L'invito delle linee guida a preferire soluzioni a governance chiusa è ora seguito: il registro che contiene i dati è chiuso e sotto il controllo del titolare del trattamento. La catena pubblica non è più il luogo del dato, ma solo quello della prova. ⚖️ Resta da motivare per iscritto, nella DPIA, perché sia comunque necessaria una componente su rete pubblica — e la motivazione è che l'impronta esterna è ciò che rende la fedeltà del Registro verificabile da terzi anziché affidata alla parola del titolare: senza di essa il registro chiuso sarebbe più tutelante sul piano della cancellazione e meno affidabile su quello dell'integrità.

(b) Validatori e provider DLT. Il profilo si riduce ma non si estingue: sulla catena pubblica non transitano dati personali, quindi i validatori non trattano dati personali per conto del titolare. ⚖️ Resta da qualificare chi gestisce l'infrastruttura del Registro privato, che tratta invece dati personali per intero, e da regolare il rapporto con DPA.

(c) Il profilo nuovo, che nasce con questo assetto e va dichiarato. Il registro delle quote è tenuto dal titolare del trattamento stesso. Ciò che si guadagna in esercitabilità dei diritti — rettifica e cancellazione tornano tecnicamente possibili — si accompagna alla concentrazione del dato presso un solo soggetto, senza la ridondanza di una rete distribuita. ⚖️ Vanno definite le misure di sicurezza, di continuità e di conservazione del Registro, e la sorte dei dati in caso di cessazione dell'attività.

⚖️ Vedi quesito Q31 in 09_Pacchetto_Consegna_Legale e riga G12 della checklist.

3-bis. Moduli di contatto del sito pubblico

Trattamento introdotto l'8 agosto 2026, quando il sito ha smesso di rimandare alla sola PEC. Fino a quel momento non esisteva: la scelta di non metterlo era motivata proprio dal fatto che un modulo raccoglie dati personali e che dove finiscono va deciso prima di chiederli.

Che cosa si raccoglie. Due moduli — richiesta di informazioni e richiesta di adesione. Campi: nome e cognome, indirizzo e-mail, organizzazione (facoltativa), veste in cui si scrive (solo nel secondo), testo del messaggio. Nessun altro dato: nessun recapito telefonico è richiesto, nessuna categoria particolare ex art. 9 è prevista, e l'interessato è avvisato di non inserirne.

Base giuridica. Consenso (art. 6.1.a), prestato con una casella non preselezionata che rimanda a questa informativa. Il consenso è necessario per l'invio: senza, il modulo non parte.

Finalità. Rispondere alla richiesta, e nient'altro. L'indirizzo non viene usato per comunicazioni promozionali, non è ceduto a terzi e non alimenta alcun elenco.

Dove finiscono i dati. Il messaggio viene composto e scritto su disco come file .eml in uno spool del server, prima di essere consegnato: se la consegna non riesce, il messaggio non si perde. Lo spool è escluso dal repository e contiene dati personali. ⚖️ Conservazione e cancellazione dello spool sono da definire e da riportare nel registro dei trattamenti (art. 30).

Che cosa NON viene registrato. Nei log applicativi non finisce alcun dato del modulo: risulta che un messaggio è stato composto, per quale modulo e con quale identificativo — non chi lo ha scritto né che cosa contiene.

Misure adottate. Validazione lato server; campo esca e tempo minimo di compilazione contro gli invii automatici; limite di invii per indirizzo IP; ripulitura delle intestazioni del messaggio contro l'iniezione di destinatari. L'indirizzo dell'interessato è usato come Reply-To e mai come mittente.

⚖️ Da definire in capo al Cliente: periodo di conservazione dei messaggi, responsabile del trattamento per il servizio di posta in uscita (se esterno, DPA ex art. 28), e procedura di cancellazione su richiesta.

4. Finalità e basi giuridiche (art. 6)

FinalitàBase giuridica (proposta)Note
Verifica identità (KYC)Obbligo legale (AML) e/o esecuzione del contratto⚖️ dipende da perimetro AML (checklist §2)
Emissione/gestione JUS, adesione ai doveriEsecuzione del contrattoPrivity/adesione
Sicurezza, audit, prevenzione abusiLegittimo interesse / obbligo legaleBilanciamento da documentare
Comunicazioni di servizioEsecuzione del contratto
Marketing (eventuale)ConsensoSolo se attivato

⚖️ Ogni base giuridica va confermata dal legale; l'elenco è preliminare.

5. Conservazione dei dati (retention)

  • Dati KYC/AML: conservazione per il periodo imposto dalla normativa antiriciclaggio applicabile (da definire, tipicamente 5–10 anni).
  • Log e audit trail: l'AuditTrail registrato è immutabile, e la sua impronta pubblica lo è definitivamente; i log hanno retention da definire, conciliando immutabilità e principio di limitazione.
  • Documenti del fascicolo: per la durata della posizione giuridica + periodi legali; poi cancellazione off-chain.

6. Diritti dell'interessato (artt. 15–22)

Accesso, rettifica, cancellazione, limitazione, opposizione, portabilità. Limiti pratici:

  • Cancellazione: eseguibile sul Registro e nel vault; l'impronta iscritta su catena pubblica non è cancellabile ma, privata del dato, è priva di contenuto intelligibile.
  • Dati del titolare nel Registro: rettificabili e cancellabili, perché il Registro è privato e sotto il controllo del titolare del trattamento. ⚠ Fino al 19 agosto 2026 non era così: l'indirizzo era scritto su una catena pubblica e non era cancellabile. Il limite è venuto meno con la migrazione al Registro privato, e questa riga lo registra perché non si continui a dichiarare un limite che non esiste più.

⚖️ L'informativa deve spiegare chiaramente questi limiti tecnici all'interessato, e deve dire che cosa resta iscritto sulla catena pubblica anche dopo la cancellazione — cioè l'impronta, e nient'altro.

7. Destinatari e responsabili del trattamento

  • Il/i fornitore/i tecnico/i esterno/i quale responsabile ex art. 28 per sviluppo/hosting/manutenzione; provider KYC/AML, hosting/vault, KMS custodial, eventuale notaio/partner (A5, da definire) quali ulteriori responsabili/sub-responsabili.
  • Il Cliente (titolare) stipula con ciascuno un accordo ex art. 28 (DPA), incluso quello con il/i fornitore/i tecnico/i esterno/i. ⚖️ Da predisporre.

8. Trasferimenti extra-UE

Il titolare è stabilito in Italia: il GDPR si applica in via diretta e i trasferimenti rilevanti sono quelli in uscita verso Paesi terzi. In particolare il fornitore tecnico esterno ha sede in San Marino, Paese terzo rispetto alla UE: per i dati ivi trasferiti (sviluppo, hosting, manutenzione) occorre individuare la base del trasferimento. ⚖️ Da definire: verificare l'applicabilità di una decisione di adeguatezza per San Marino e, in mancanza, adottare clausole contrattuali tipo (SCC) con valutazione d'impatto sul trasferimento; analoga valutazione per ogni altro sub-responsabile fuori UE.

9. Misure di sicurezza

Cifratura at-rest (AES-256-GCM), AAD anti-swap legato al docRef (D-017), accesso ai documenti solo tramite grant a tempo revocabile e tracciato, ammissione controllata e KYC. Gestione chiavi via KMS/HSM in produzione (residuo T-023).

⚠️ Il Registro privato è una misura di sicurezza e insieme una concentrazione di rischio. Poiché le quote e gli indirizzi dei titolari risiedono in un registro tenuto dal titolare del trattamento, e non replicato su una rete di terzi, le misure di continuità, backup e conservazione del Registro non sono un requisito operativo ma un presidio dei diritti degli interessati. ⚖️ Da definire, con la sorte del Registro in caso di cessazione dell'attività.

10. Processo decisionale automatizzato

Il controllo dei trasferimenti (KYC/adesione) è basato su regole deterministiche applicate dal Registro. ⚖️ Valutare se costituisce trattamento automatizzato rilevante ex art. 22.


⚠️ Verifiche legali necessarie

  1. Titolare (= Cliente) / contitolari, DPO, rappresentante UE (art. 27) in capo al Cliente — dati mancanti, da definire in funzione della sede del Cliente.
  2. DPIA obbligatoria (larga scala + tecnologia innovativa + dati identità).
  3. Trasferimenti verso Paesi terzi (in funzione della sede del Cliente; in particolare verso il/i fornitore/i tecnico/i esterno/i con sede in Paese terzo, es. San Marino, come responsabile/sub-responsabile): base giuridica del trasferimento.
  4. Qualificazione dell'indirizzo del titolare come dato personale e informativa dedicata.
  5. Conciliazione art. 17 (cancellazione) con l'immutabilità dell'impronta pubblica: validare la tesi della §3/§6, ora che il dato non è più su catena pubblica e il limite riguarda la sola impronta.
  6. Contenuto dell'impronta pubblica (§3): verificare che, per come è costruita, non consenta a un terzo di ricostruire chi ha compiuto quale operazione — nemmeno per correlazione fra impronte successive. È il punto su cui le linee guida EDPB sono più esigenti, e la verifica è tecnica prima che giuridica.
  7. Registro privato (§9): misure di continuità, conservazione e sorte dei dati alla cessazione dell'attività; qualificazione del gestore dell'infrastruttura e relativo DPA.
  8. Retention KYC/AML e log: durate esatte.
  9. DPA che il Cliente (titolare) stipula con tutti i responsabili (fornitore/i tecnico/i esterno/i, KYC, vault, KMS, notaio).