Accordo sul trattamento dei dati personali

Data Processing Agreement (DPA)

Versione 1.1 · Ultimo aggiornamento: 8 settembre 2026 · In vigore dall'8 settembre 2026

Il presente Accordo sul trattamento dei dati personali (di seguito "DPA") è concluso ai sensi dell'art. 28 del Regolamento (UE) 2016/679 ("GDPR") e dell'art. 28 del D.Lgs. 196/2003, come modificato dal D.Lgs. 101/2018 (Codice in materia di protezione dei dati personali), tra l'Esercente, in qualità di Titolare del trattamento, e radioBros, in qualità di Responsabile del trattamento, e disciplina il trattamento dei dati personali dei clienti dell'Esercente nell'ambito dell'erogazione del servizio TesserApp.

La versione 1.1 allinea il presente DPA alla versione 1.2 della Privacy Policy, a seguito di una verifica integrale del codice sorgente del Servizio. Estende a tutte le carte personali e all'iscrizione web senza app le informazioni che in precedenza erano scritte per i soli programmi privati; sostituisce l'elenco dei sub-responsabili, la tabella dei tempi di conservazione e la descrizione delle misure di sicurezza con ciò che i sistemi effettivamente fanno; e rimuove gli impegni che nessun processo automatico faceva rispettare. Dove il presente DPA e la Privacy Policy descrivono lo stesso trattamento, l'intento è che dicano la stessa cosa.

1. Parti

1.1 Titolare del trattamento (Controller): la persona fisica o giuridica che si registra alla piattaforma TesserApp Shop e sottoscrive un abbonamento al Servizio (di seguito l'"Esercente"). I dati identificativi dell'Esercente sono quelli inseriti in sede di registrazione e modificabili dall'apposita sezione della dashboard.

1.2 Responsabile del trattamento (Processor): radioBros di Alberto Miconi, con sede in Via Ridolfino Venuti 30, 00162 Roma (Italia), P.IVA IT15127451001, email di contatto privacy@tesserapp.eu (di seguito "radioBros").

Le Parti si riconoscono reciprocamente la qualità sopra descritta, ferma restando l'autonomia di radioBros nella qualità di Titolare per i propri trattamenti relativi all'esecuzione dell'abbonamento (fatturazione, account dell'Esercente, log di sicurezza dei propri sistemi), che restano disciplinati dalla Privacy Policy e dai Termini di Servizio.

2. Definizioni

Ai fini del presente DPA si applicano le definizioni di cui all'art. 4 del GDPR. Inoltre:

• "Dati personali": qualsiasi informazione riguardante una persona fisica identificata o identificabile ai sensi dell'art. 4 n. 1 GDPR, trattata dal Responsabile per conto del Titolare nell'ambito del Servizio.
• "Interessato": il cliente dell'Esercente che è intestatario di una carta fedeltà di uno dei programmi dell'Esercente, sia che la conservi nell'app mobile TesserApp, sia che la conservi soltanto in Apple Wallet o Google Wallet.
• "Servizio": l'insieme della piattaforma web, delle applicazioni mobili e delle componenti infrastrutturali che radioBros mette a disposizione dell'Esercente per la gestione dei propri programmi fedeltà.
• "Carta personale": una carta che, per costruzione, è emessa a favore di una singola persona nominata. Ne esistono quattro tipi: privata (carta a timbri personale), sconto, accesso e prepagata. Per tutti e quattro, il nome e l'indirizzo email dell'intestatario sono obbligatori.
• "Carta anonima": una carta standard (a timbri) o una carta punti, che l'Interessato attiva autonomamente dall'app o dal catalogo e che non porta né nome né indirizzo email.
• "Sub-responsabile": qualsiasi terzo cui il Responsabile affidi attività di trattamento dei Dati personali, ai sensi dell'art. 28, par. 4, GDPR. L'elenco è contenuto nell'Appendice A, sezione A.1.
• "Violazione dei Dati personali": la nozione di cui all'art. 4 n. 12 GDPR.

3. Oggetto, durata, natura e finalità del trattamento

3.1 L'Esercente, quale Titolare, conferisce a radioBros, quale Responsabile, l'incarico di trattare i Dati personali degli Interessati per le finalità necessarie all'erogazione del Servizio e indicate nel presente DPA.

3.2 Oggetto del trattamento: gestione tecnica del programma fedeltà dell'Esercente, comprendente l'attivazione delle carte cliente, la registrazione delle transazioni (assegnazione di timbri, riscossione di premi, eventuali storni, variazioni di un saldo punti o di credito), la sincronizzazione delle carte verso Apple Wallet e Google Wallet, la consegna delle notifiche push relative al programma fedeltà, la consegna delle comunicazioni che l'Esercente compone per gli intestatari di un proprio programma, l'esposizione del programma nel catalogo dell'app cliente (ove l'Esercente abbia scelto la visibilità pubblica), la fornitura di funzionalità di scoperta basate sulla posizione e, in aggiunta:

• per le carte personali (privata, sconto, accesso, prepagata): l'emissione di una carta a favore di un singolo intestatario nominato, la consegna di un invito all'installazione via email e l'associazione della carta all'account del dispositivo dell'intestatario;
• per l'iscrizione web senza app (solo carte standard): la creazione di una carta e di un pass Wallet nativo a partire da una pagina web, senza che l'Interessato installi l'app cliente, unitamente al nome, all'indirizzo email e al marcatore di consenso marketing facoltativi che il modulo di iscrizione può raccogliere.

3.3 Natura del trattamento: trattamenti automatizzati svolti su infrastruttura informatica del Responsabile e dei suoi Sub-responsabili autorizzati.

3.4 Finalità del trattamento: esecuzione del contratto tra l'Esercente e i propri clienti relativo al programma fedeltà; adempimento degli obblighi di legge dell'Esercente in qualità di Titolare; sicurezza dei sistemi informativi e prevenzione delle frodi su timbri, premi e saldi; consegna delle carte personali agli specifici soggetti designati dal Titolare e limitazione di ciascuna di tali carte all'account del dispositivo dell'intestatario; e, per l'iscrizione web senza app, creazione di una carta a favore di un Interessato che non ha installato l'app.

3.5 Durata: il presente DPA ha efficacia per l'intera durata dell'abbonamento dell'Esercente al Servizio. Le obbligazioni di cui agli artt. 9 (Restituzione e cancellazione) e 13 (Riservatezza) sopravvivono alla cessazione.

4. Categorie di Interessati e di Dati personali

4.1 Categorie di Interessati: clienti dell'Esercente intestatari di una carta fedeltà di uno dei programmi dell'Esercente, sia nell'app TesserApp sia soltanto in un Wallet nativo.

4.2 Categorie di Dati personali trattati (Appendice B):

• identificatori anonimi di installazione (token casuali di 256 bit, non collegati a un'identità anagrafica, conservati dal Responsabile unicamente in forma di hash crittografico);
• identificatori delle carte fedeltà (UUID opachi) e numeri di serie delle carte;
• metadati delle transazioni (eventi di assegnazione timbri, riscossione premi, storni, variazioni del saldo punti o di credito; data, ora e sede dell'Esercente in cui è avvenuta l'operazione; l'importo o il numero di timbri richiesti; e, per uno storno, la motivazione in testo libero scritta dall'Esercente);
• identificatori dei pass Apple Wallet / Google Wallet, token di aggiornamento del pass, identificatore che il sistema operativo assegna alla libreria pass del dispositivo e relativi token di push;
• token di notifica push emessi da Apple (APNs) o Google (FCM), registrati per l'installazione dell'app in quanto tale;
• lingua di sistema del dispositivo, piattaforma (iOS o Android) e versione dell'app;
• indirizzi IP e stringhe user-agent, registrati nei log di audit e di accesso a fini di sicurezza. Contrariamente a quanto affermava la versione 1.0 del presente DPA, essi non sono trattati in via transitoria: sono conservati come descritto nell'Appendice B, sezione B.2;
• coordinate GPS, esclusivamente nei casi in cui l'Interessato abbia attivato la funzione di scoperta dei negozi vicini o consulti il catalogo ordinato per distanza, e per il solo tempo di quella richiesta. Le coordinate non sono conservate, né dal Responsabile né sul dispositivo;
• indirizzo email dell'Interessato, ove fornito volontariamente dall'Interessato al Responsabile (richieste di esercizio dei diritti GDPR, contatti al supporto);
• segnalazioni tecniche di errore e di crash, che riportano il modello del dispositivo, la versione del sistema operativo e la versione dell'app, e possono contenere l'identificatore tecnico di una carta o di un programma coinvolti nell'errore. Sono configurate per non raccogliere dati identificativi dell'utente e per non allegare l'indirizzo IP.

4.2 bis — Carte personali (privata, sconto, accesso, prepagata): per tutti e quattro i tipi di carta personale, e non soltanto per i programmi privati:

• il nome e l'indirizzo email dell'intestatario, entrambi obbligatori, forniti dal Titolare al momento della creazione della carta e trattati per emettere la carta, inviare un invito all'installazione via email, stampare i dati dell'intestatario sulla carta e sul pass Wallet e mostrarli al personale dell'Esercente quando la carta viene scansionata;
• un riferimento esterno (external_ref) — l'identificativo che il Titolare già utilizza per quella persona fisica nei propri sistemi, per esempio un numero di dipendente o di socio — ove il Titolare lo imposti attraverso l'API di integrazione o il connettore MCP;
• un riferimento pseudonimo di associazione all'account del dispositivo (un identificatore opaco derivato dall'account iCloud o Google dell'intestatario, non dal suo nome o dalla sua email), trattato unicamente per garantire che la carta rimanga sull'account dell'intestatario.

Il Titolare garantisce di disporre di una base giuridica e, ove richiesto, del consenso dell'Interessato a fornire tali dati; il Responsabile li tratta esclusivamente in base alle istruzioni documentate del Titolare.

4.2 ter — Iscrizione web senza app (solo carte standard): quando un Interessato ottiene una carta standard iscrivendosi da una pagina web e aggiungendola direttamente ad Apple Wallet o Google Wallet, senza installare l'app cliente, il modulo di iscrizione può raccogliere:

• un nome facoltativo e un indirizzo email facoltativo. Se lasciati in bianco, la carta è creata in forma anonima, esattamente come una carta attivata nell'app; se compilati, sono associati alla carta e trattati per conto del Titolare come previsto al §4.2 bis;
• un marcatore di consenso marketing, composto dalla data e dall'origine della raccolta. Ad oggi si tratta di un campo soltanto memorizzato: nessun messaggio promozionale viene inviato sulla sua base, né dal Responsabile né dal Titolare attraverso i sistemi del Responsabile.

L'iscrizione web senza app è disponibile per i soli programmi standard (a timbri). La pagina di iscrizione che radioBros pubblica direttamente non chiede alcuno di questi campi; essi restano disponibili al Titolare che integri la funzione nei propri strumenti.

4.3 Dati NON trattati: indirizzo postale dell'Interessato; numero di telefono dell'Interessato; dati di pagamento dell'Interessato (il Servizio non gestisce pagamenti del cliente verso l'Esercente); cronologia di navigazione; dati biometrici; identificatori pubblicitari; categorie particolari di dati ai sensi dell'art. 9 GDPR; dati relativi a condanne penali ai sensi dell'art. 10 GDPR; dati di minori di 16 anni (il Servizio non è rivolto a tale fascia di età). Il Responsabile non impiega alcun SDK pubblicitario, di attribuzione o di analytics e non costruisce alcun profilo comportamentale.

Che il nome e l'indirizzo email siano trattati dipende dal percorso attraverso il quale la carta è stata ottenuta, non dal solo tipo di carta. La versione 1.0 del presente DPA affermava che "per tutti i programmi standard/pubblici, il nome e l'email restano non trattati". Ciò non è più esatto, e la posizione corretta è la seguente:

Come è stata ottenuta la carta	Nome ed email
Carta standard o punti attivata autonomamente nell'app (QR code o catalogo)	Non trattati. La carta è anonima e resta anonima
Carta personale (privata, sconto, accesso, prepagata) creata dal Titolare	Sempre trattati — entrambi obbligatori (§4.2 bis)
Carta standard ottenuta tramite iscrizione web senza app	Facoltativi — trattati solo se il modulo li raccoglie e l'Interessato li compila (§4.2 ter)
Carta creata dal Titolare tramite l'API di integrazione o il connettore MCP	Nome ed email come sopra, più il riferimento esterno del Titolare (§4.2 bis)

5. Obblighi del Responsabile

Il Responsabile si impegna a:

5.1 trattare i Dati personali esclusivamente in base a istruzioni documentate del Titolare, comprese quelle in materia di trasferimento dei Dati personali verso un Paese terzo o un'organizzazione internazionale, salvo che lo richieda il diritto dell'Unione o dello Stato membro cui è soggetto il Responsabile; in tal caso, il Responsabile informa il Titolare di tale obbligo giuridico prima del trattamento, a meno che il diritto vieti tale informazione per rilevanti motivi di interesse pubblico;

5.2 garantire che le persone autorizzate al trattamento dei Dati personali si siano impegnate alla riservatezza o abbiano un adeguato obbligo legale di riservatezza;

5.3 adottare tutte le misure tecniche e organizzative richieste ai sensi dell'art. 32 GDPR, descritte nell'Appendice D del presente DPA;

5.4 rispettare le condizioni di cui ai paragrafi 2 e 4 dell'art. 28 GDPR per il ricorso a Sub-responsabili, come precisato all'art. 6 del presente DPA;

5.5 assistere il Titolare con misure tecniche e organizzative adeguate, nella misura in cui ciò sia possibile, al fine di soddisfare l'obbligo del Titolare di dare seguito alle richieste degli Interessati per l'esercizio dei diritti di cui agli artt. 15-22 GDPR;

5.6 assistere il Titolare nel garantire il rispetto degli obblighi di cui agli artt. 32-36 GDPR, tenuto conto della natura del trattamento e delle informazioni a disposizione del Responsabile;

5.7 su scelta del Titolare, cancellare o restituire tutti i Dati personali al termine dei servizi relativi al trattamento, e cancellare le copie esistenti, salvo che il diritto dell'Unione o dello Stato membro preveda la conservazione dei dati;

5.8 mettere a disposizione del Titolare tutte le informazioni necessarie per dimostrare il rispetto degli obblighi di cui all'art. 28 GDPR e contribuire alle attività di revisione, comprese le ispezioni, realizzate dal Titolare o da altro soggetto da questi incaricato;

5.9 informare immediatamente il Titolare qualora, a suo parere, un'istruzione violi il GDPR o altre disposizioni, nazionali o dell'Unione, relative alla protezione dei dati.

6. Sub-responsabili

6.1 L'Esercente autorizza in modo generale il ricorso da parte del Responsabile ai Sub-responsabili elencati nell'Appendice A, sezione A.1 del presente DPA.

6.2 Il Responsabile informerà l'Esercente di eventuali modifiche previste riguardanti l'aggiunta o la sostituzione di altri Sub-responsabili con preavviso di almeno 30 giorni, dando così all'Esercente l'opportunità di opporsi a tali modifiche.

6.3 In caso di opposizione motivata dell'Esercente, il Responsabile valuterà soluzioni tecniche alternative. Qualora non sia possibile evitare il ricorso al nuovo Sub-responsabile, l'Esercente potrà recedere dall'abbonamento senza penali, con effetto dalla data di entrata in operatività del nuovo Sub-responsabile.

6.4 Il Responsabile stipula con ciascun Sub-responsabile un contratto scritto contenente obblighi di protezione dei dati equivalenti a quelli stabiliti nel presente DPA, in particolare in tema di misure tecniche e organizzative adeguate, riservatezza, assistenza al Titolare e cooperazione con l'Autorità di controllo.

6.5 Il Responsabile risponde nei confronti dell'Esercente dell'operato del Sub-responsabile nei limiti previsti dall'art. 28, par. 4, GDPR.

6.6 L'Appendice A elenca inoltre, distintamente dai Sub-responsabili, gli altri destinatari terzi che ricevono dati come effetto diretto di una funzionalità di prodotto senza che tali dati transitino dai sistemi del Responsabile (sezione A.2), e le componenti che sono installazioni proprie del Responsabile sui propri domini e non costituiscono pertanto Sub-responsabili (sezione A.3). La distinzione rispecchia quella utilizzata al §4 della Privacy Policy.

7. Diritti degli Interessati

7.1 Il Responsabile, tenuto conto della natura del trattamento, assiste il Titolare con misure tecniche e organizzative adeguate, nella misura in cui ciò sia possibile, al fine di soddisfare l'obbligo del Titolare di dare seguito alle richieste degli Interessati per l'esercizio dei diritti di cui al Capo III del GDPR (artt. 12-22), e in particolare:

• diritto di accesso (art. 15);
• diritto di rettifica (art. 16);
• diritto alla cancellazione (art. 17), operazionalizzato attraverso il flusso descritto al successivo art. 9, il cui primo passaggio è la cancellazione immediata e irreversibile dei dati identificativi dell'intestatario;
• diritto di limitazione di trattamento (art. 18);
• diritto alla portabilità dei dati (art. 20);
• diritto di opposizione (art. 21);
• diritto di non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato (art. 22): il Servizio non opera profilazione automatizzata con effetti giuridici sull'Interessato.

7.2 Le richieste ricevute direttamente dal Responsabile sono inoltrate senza ritardo al Titolare, salvo che il Responsabile sia autorizzato per iscritto dal Titolare a rispondere direttamente.

7.3 Che cosa offre effettivamente la dashboard, ad oggi. La versione 1.0 del presente DPA affermava che la dashboard mettesse a disposizione strumenti per esportare, anonimizzare e sospendere i dati di un singolo Interessato. Di quegli strumenti ne esiste uno solo. La posizione esatta è la seguente:

Diritto	Come si esercita ad oggi
Cancellazione di un singolo Interessato	In autonomia dalla dashboard. In Impostazioni → Dati cliente il Titolare può cercare una carta per numero di serie e cancellarla. La cancellazione rimuove dalla carta il nome, l'email e il riferimento esterno dell'intestatario
Esportazione dei dati di un singolo Interessato	Su richiesta, eseguita dal Responsabile. Nella dashboard non esiste un'esportazione per singolo Interessato. La funzione di esportazione dati della dashboard produce l'archivio dell'account del Titolare, non il fascicolo di un singolo Interessato. Scrivendo a privacy@tesserapp.eu il Responsabile predispone l'estratto
Rettifica dei dati di un singolo Interessato	Su richiesta, eseguita dal Responsabile, oppure dal Titolare riemettendo la carta
Limitazione / sospensione di un singolo Interessato	Su richiesta, eseguita dal Responsabile. Nella dashboard non esiste un comando di sospensione per singolo Interessato

7.4 Il Responsabile si impegna a estendere gli strumenti in autonomia all'esportazione e alla limitazione per singolo Interessato. Fino a quando non esisteranno, il presente DPA non li rappresenta come disponibili, e le richieste di cui al §7.3 sono gestite dal Responsabile nei termini indicati nell'Appendice C.

8. Notifica di violazione dei Dati personali

8.1 In caso di Violazione dei Dati personali di cui il Responsabile venga a conoscenza, il Responsabile notifica l'evento al Titolare senza ingiustificato ritardo e comunque entro 72 ore dalla conoscenza, fornendo, nella misura del possibile, le informazioni di cui all'art. 33, par. 3, GDPR e in particolare:

• la natura della violazione, le categorie e il numero approssimativo di Interessati interessati;
• le categorie e il numero approssimativo di registrazioni dei Dati personali coinvolti;
• i dati di contatto del referente per la gestione dell'incidente;
• le probabili conseguenze della violazione;
• le misure adottate o proposte per porvi rimedio e attenuarne i possibili effetti.

8.2 Quando, e nella misura in cui, non è possibile fornire le informazioni contestualmente, le stesse possono essere fornite in fasi successive senza ulteriore ingiustificato ritardo.

8.3 Resta inteso che spetta al Titolare, ai sensi degli artt. 33 e 34 GDPR, valutare se notificare la violazione all'Autorità di controllo e comunicarla agli Interessati.

9. Restituzione e cancellazione dei Dati personali alla cessazione

9.1 Esportazione. Al termine dell'abbonamento, e in ogni caso entro 30 giorni dalla cessazione, l'Esercente può richiedere al Responsabile l'esportazione integrale dei Dati personali in formato strutturato di uso comune e leggibile da dispositivo automatico. L'esportazione è prodotta come archivio ZIP contenente file JSON, caricato sull'object storage del Responsabile e consegnato all'Esercente mediante un link firmato valido per 48 ore. All'interno dell'archivio è anonimizzato il materiale identificativo lato cliente che non spetta all'Esercente ricevere (hash dei token di installazione, indirizzi IP).

9.2 Cancellazione. Decorso il termine di cui al punto precedente senza richiesta di esportazione, ovvero a seguito di completamento dell'esportazione, il Responsabile procede alla cancellazione dei Dati personali. Il ciclo di vita effettivamente applicato dal Servizio è il seguente, e l'affermazione della versione 1.0 secondo cui i dati sarebbero "cancellati definitivamente dai sistemi di produzione entro 5 giorni" è ritirata:

• un abbonamento sospeso viene disdetto automaticamente dopo 60 giorni;
• 150 giorni dopo la disdetta, all'Esercente è inviato un avviso dell'imminente cancellazione dei suoi dati;
• 180 giorni dopo la disdetta, l'account è anonimizzato automaticamente. L'anonimizzazione rimuove il nome e l'email di accesso, la password, il secondo fattore, le passkey, le identità social, gli operatori, i dispositivi accoppiati, le chiavi API e il nome, l'indirizzo email e il riferimento esterno su ciascuna delle carte dei clienti dell'Esercente;
• se l'Esercente richiede la cancellazione dalla dashboard, la medesima anonimizzazione è eseguita 30 giorni dopo la richiesta, periodo che costituisce una finestra di grazia entro la quale la richiesta può essere revocata;
• per una singola carta cancellata i campi identificativi dell'intestatario sono cancellati nel momento stesso della richiesta, insieme alla credenziale di installazione che legava la carta al dispositivo dell'intestatario; da quel momento la cancellazione è irreversibile e non esiste alcuna finestra di recupero. Entro 30 giorni una procedura notturna pianificata rimuove i record dipendenti e il record della carta stesso, salvo che una registrazione contabile conservata lo richiami: in tal caso il record è purgato sul posto e resta un identificativo nudo che non identifica nessuno, rimosso in ogni caso con l'anonimizzazione sopra descritta.

9.3 Dati esclusi dalla cancellazione. Restano esclusi dalla cancellazione, per il tempo strettamente necessario, i Dati personali la cui conservazione sia imposta da obblighi di legge gravanti su radioBros. Ciò riguarda le fatture emesse dal Responsabile nei confronti dell'Esercente, non i dati degli Interessati, e il termine di conservazione è di 10 anni:

• L'art. 2220 c.c. impone di conservare per 10 anni le fatture — quelle ricevute e le copie di quelle spedite — e le scritture contabili che le richiamano. È questo l'obbligo effettivamente applicato ed è il termine indicato nella Privacy Policy e nei Termini di Servizio.
• La normativa fiscale italiana applicabile (DPR 633/1972; D.Lgs. 127/2015) fissa un minimo più breve, pari a 7 anni, già soddisfatto dal termine di cui sopra.

Tali dati restano in custodia separata, con accesso limitato e tracciato, e non sono oggetto di ulteriori trattamenti diversi dall'adempimento dell'obbligo.

9.4 Su richiesta scritta dell'Esercente, il Responsabile fornisce dichiarazione formale di avvenuta cancellazione.

10. Trasferimenti di Dati personali verso Paesi terzi

10.1 Il Responsabile tratta i Dati personali sui propri sistemi esclusivamente su infrastrutture localizzate nello Spazio Economico Europeo. I sistemi di produzione sono ospitati in Germania.

10.2 Alcuni Sub-responsabili indicati in Appendice A possono avere sede o operazioni negli Stati Uniti d'America (in particolare Stripe, Apple, Google, Cloudflare). Il trasferimento dei Dati personali verso tali soggetti è effettuato sulla base delle Clausole Contrattuali Tipo adottate dalla Commissione europea con decisione 2021/914/UE, integrate dalle misure supplementari ove necessario ai sensi della sentenza CGUE C-311/18 (Schrems II).

10.2 bis — Trasferimenti che non transitano dai sistemi del Responsabile. Alcuni destinatari elencati nell'Appendice A, sezione A.2, sono contattati direttamente dal browser dell'Esercente o dal dispositivo dell'Interessato, come effetto diretto di una funzionalità di prodotto. Per essi il luogo del trattamento è quello proprio del destinatario e il Responsabile non si trova nel percorso di trasmissione:

• Overpass (overpass-api.de, servizio pubblico del progetto OpenStreetMap): su iOS, il dispositivo dell'Interessato gli invia le coordinate GPS quando viene usata la funzione dei negozi vicini;
• LocationIQ (Unwired Labs): il browser dell'Esercente gli invia il testo dell'indirizzo digitato nella dashboard;
• Google Fonts e Stripe.js: caricati dalla dashboard su ogni pagina, per cui l'indirizzo IP e il tipo di browser di chi apre la dashboard raggiungono rispettivamente Google e Stripe.

10.3 Non sono effettuati trasferimenti verso Paesi terzi al di fuori del quadro delle Clausole Contrattuali Tipo o di una decisione di adeguatezza della Commissione, salvo le chiamate dirette dal browser e dal dispositivo di cui al §10.2 bis, la cui base di trasferimento è indicata nell'Appendice A.

11. Misure tecniche e organizzative

Le misure tecniche e organizzative adottate dal Responsabile ai sensi dell'art. 32 GDPR sono descritte nell'Appendice D del presente DPA, che ne forma parte integrante. L'Appendice D distingue le misure già in essere da quelle che il Responsabile si impegna ad adottare. Tali misure sono soggette ad aggiornamento periodico per riflettere lo stato dell'arte; eventuali aggiornamenti non possono comportare una riduzione del livello di sicurezza garantito.

12. Audit

12.1 Il Responsabile mette a disposizione del Titolare, dietro richiesta scritta, le informazioni necessarie a dimostrare il rispetto degli obblighi di cui all'art. 28 GDPR e al presente DPA.

12.2 Il Titolare può richiedere, una volta per anno solare, lo svolgimento di un'attività di audit, da effettuarsi previo preavviso scritto di almeno 30 giorni, in orario lavorativo, presso le sedi del Responsabile, con modalità tali da non interferire con la continuità operativa del Servizio e nel rispetto delle misure di sicurezza vigenti.

12.3 I costi diretti dell'audit sono a carico del Titolare, salvo che dall'audit emergano violazioni significative del presente DPA imputabili al Responsabile, nel qual caso i costi sono a carico del Responsabile.

12.4 Il Responsabile non possiede ad oggi alcuna certificazione di sicurezza rilasciata da terzi (nessun report SOC 2, nessun certificato ISO 27001). Qualora ne ottenesse una, potrà proporre in luogo dell'audit in loco l'esibizione del relativo report di auditor indipendente, unitamente a documentazione equipollente.

13. Riservatezza

13.1 Le Parti si impegnano a trattare come strettamente riservate tutte le informazioni acquisite nell'esecuzione del presente DPA, salvo quelle di pubblico dominio o di cui sia obbligatoria la divulgazione per legge o ordine dell'autorità.

13.2 L'obbligo di riservatezza si estende ai dipendenti, collaboratori e Sub-responsabili delle Parti e sopravvive alla cessazione del presente DPA.

14. Responsabilità e manleva

14.1 Ciascuna Parte risponde dei danni cagionati dal proprio trattamento che violi il GDPR, nei limiti e con le modalità previsti dall'art. 82 GDPR.

14.2 Nei rapporti interni tra le Parti, la responsabilità di radioBros nei confronti dell'Esercente per il trattamento dei Dati personali è disciplinata dalla clausola di limitazione di responsabilità prevista nei Termini di Servizio, salvo i casi di dolo o colpa grave e ferma restando la responsabilità verso l'Interessato ai sensi del GDPR.

14.3 L'Esercente garantisce e tiene indenne radioBros da qualsiasi pretesa derivante dalla violazione, da parte dell'Esercente, dei propri obblighi di Titolare ai sensi del GDPR (in particolare: corretta informativa agli Interessati ex artt. 13-14 GDPR; corretta base giuridica del trattamento; correttezza delle istruzioni impartite al Responsabile).

15. Durata, modifiche e disposizioni finali

15.1 Durata. Il presente DPA è efficace dalla data di accettazione da parte dell'Esercente in sede di registrazione (mediante apposita casella di spunta) e per l'intera durata dell'abbonamento al Servizio. Le obbligazioni di restituzione/cancellazione (art. 9) e di riservatezza (art. 13) sopravvivono alla cessazione.

15.2 Modifiche. Modifiche sostanziali del presente DPA saranno comunicate all'Esercente con preavviso di almeno 30 giorni via email all'indirizzo registrato sull'account e mediante apposito banner sulla dashboard. L'Esercente sarà chiamato a riaccettare la nuova versione al successivo accesso. La mancata accettazione comporta la facoltà di recedere dall'abbonamento senza penali.

15.2 bis — Entrata in vigore della versione 1.1. La versione 1.1 del presente DPA entra in vigore alla data di pubblicazione indicata in testa a questo documento, senza attendere il preavviso di 30 giorni previsto dal §15.2. La ragione sta nella natura di questa revisione: la versione 1.1 non impone al Titolare obblighi nuovi e non riduce le tutele degli Interessati, ma corregge affermazioni inesatte della versione 1.0, amplia le informazioni fornite e ritira impegni che nessun processo del Servizio ha mai eseguito — fra questi la cancellazione «entro cinque giorni» di cui al §9.2, che i sistemi non effettuavano. In più punti il testo risultante è meno favorevole al Responsabile e più favorevole a chi lo legge, perché smette di sopravvalutare la riservatezza offerta e di promettere cancellazioni che non avvenivano. Differire di 30 giorni una correzione di questo tipo significherebbe tenere in vigore per altri 30 giorni un testo che si sa essere inesatto: il preavviso del §15.2 esiste per proteggere l'Esercente da modifiche che alterano le obbligazioni, non per ritardare la descrizione veritiera di un trattamento già in corso. Questo ragionamento non si estende al §6.2, che la presente disposizione lascia del tutto intatto. La nuova Appendice A elenca destinatari che la versione 1.0 non riportava: la maggior parte era già coinvolta nel trattamento e viene semplicemente messa per iscritto. Almeno uno, però — Unwired Labs (LocationIQ), di cui il Responsabile si avvale da giugno 2026 per il completamento automatico degli indirizzi nella dashboard dell'Esercente — è stato effettivamente aggiunto dopo la versione 1.0, e la posizione degli ulteriori punti indicati nell'Appendice A, sezione A.4 non è ancora determinata. Per essi il §6.2 si applica integralmente: il preavviso di 30 giorni e il diritto di opposizione dell'Esercente sono dati come quell'articolo richiede, e la sezione A.4 ne dà atto.

Il §15.2 resta integro. Il §15.2 conserva piena efficacia per ogni modifica futura del presente DPA. Il §15.2 bis è una deroga transitoria una tantum, circoscritta all'entrata in vigore della versione 1.1: non riduce, non reinterpreta e non sospende il preavviso di 30 giorni, la richiesta di riaccettazione o la facoltà di recesso senza penali che il §15.2 attribuisce all'Esercente, e lo stesso vale per il §6.2 quanto all'aggiunta effettiva di un nuovo Sub-responsabile. Ogni modifica successiva che alteri le obbligazioni delle Parti segue integralmente il §15.2.

La comunicazione data con questa pubblicazione. Con l'entrata in vigore della versione 1.1 vengono dati: la pubblicazione del testo su questa pagina, con la data e il numero di versione in testa; una comunicazione via email agli Esercenti all'indirizzo registrato sull'account; e la richiesta di accettazione della nuova versione, che sarà rivolta all'Esercente quando la relativa funzione sarà disponibile — alla data di pubblicazione il Servizio non dispone di un meccanismo di riaccettazione, e la presente disposizione non ne promette uno prima di allora. Nessuna comunicazione è rivolta agli Interessati tramite l'app: l'app non è un canale di comunicazioni legali. L'Esercente che non intenda accettare la versione 1.1 conserva la facoltà di recesso senza penali di cui al §15.2.

15.3 Lingua. La versione italiana del presente DPA è quella ufficiale e prevale, in caso di discrepanza, sulle traduzioni in altre lingue.

15.4 Legge applicabile e foro competente. Il presente DPA è regolato dalla legge italiana. Per ogni controversia è competente in via esclusiva il Foro di Roma.

15.5 Tracciamento dell'accettazione. L'accettazione del DPA è tracciata dal Responsabile mediante registrazione di: ragione sociale dell'Esercente, email dell'utente che ha effettuato l'accettazione, indirizzo IP, marca temporale e versione del DPA accettata. Tali dati costituiscono prova dell'accettazione ai sensi degli artt. 20 e 21 del D.Lgs. 82/2005 (Codice dell'Amministrazione Digitale).

---

Appendice A — Sub-responsabili, altri destinatari e infrastruttura propria

La presente appendice adotta la stessa tripartizione del §4 della Privacy Policy, affinché i due documenti possano essere letti l'uno accanto all'altro.

A.1 Sub-responsabili (art. 28 GDPR)

Fornitori che trattano Dati personali per conto del Responsabile, in forza di un accordo ex art. 28. La colonna "Dati di chi" è dirimente: alcuni di questi fornitori toccano soltanto dati propri dell'Esercente e mai dati degli Interessati.

Sub-responsabile	Sede e luogo del trattamento	Ruolo	Dati di chi, e quali	Base trasferimento
Contabo GmbH	Germania	Hosting VPS di tutti i sistemi di produzione: database, applicazione, code di lavoro, cache, indice di ricerca del catalogo e i dump del database descritti al punto D.3	Dati degli Interessati — tutte le categorie oggetto del Servizio	Trattamento in UE
Stripe Payments Europe Ltd.	Irlanda (gruppo con operazioni in USA)	Elaborazione dei pagamenti dell'abbonamento dell'Esercente; emissione delle fatture	Solo dati dell'Esercente — dati di pagamento e fiscali. Non dati degli Interessati	SCC 2021/914/UE
Cloudflare, Inc.	USA — bucket R2 configurati in regione UE	Object storage per le immagini di programma e di carta accesso caricate dall'Esercente e per gli archivi di esportazione GDPR richiesti dall'Esercente; CDN per le risorse statiche. Nessun backup del database è conservato qui (vedi D.3)	Dati dell'Esercente, e dati degli Interessati nella misura in cui siano contenuti in un archivio di esportazione richiesto dall'Esercente	SCC 2021/914/UE
Apple Inc.	USA	Consegna dei pass Apple Wallet e delle notifiche push (APNs); provisioning del Pass Type ID e del certificato di firma propri dell'Esercente tramite le API di App Store Connect	Dati degli Interessati — token di push, identificatori del pass e il contenuto stesso del pass, che per le carte personali comprende il nome e l'email dell'intestatario. Le chiamate ad App Store Connect trasportano soltanto identificativi dell'Esercente	SCC 2021/914/UE
Google LLC	USA	Consegna dei pass Google Wallet (Google Wallet API) e delle notifiche push (Firebase Cloud Messaging)	Dati degli Interessati — come per Apple	SCC 2021/914/UE
Gestore del server di posta transazionale mail.tesserapp.eu	[DA COMPLETARE — vedi A.4]	Invio della posta transazionale via SMTP: inviti all'installazione delle carte, avvisi di attività, comunicazioni di servizio	Dati degli Interessati — indirizzo email del destinatario e contenuto del messaggio; e dati dell'Esercente	[DA COMPLETARE — vedi A.4]
Unwired Labs (LocationIQ)	[DA COMPLETARE — vedi A.4]	Completamento automatico degli indirizzi nella dashboard dell'Esercente. Il fornitore è ingaggiato dal Responsabile, ma la chiamata parte direttamente dal browser dell'Esercente con una chiave pubblicabile e non transita dai sistemi del Responsabile — vedi A.2 e §10.2 bis	Solo dati dell'Esercente — il testo dell'indirizzo digitato e l'indirizzo IP del browser. Non dati degli Interessati	[DA COMPLETARE — vedi A.4]
Intermediario per la fatturazione elettronica verso il Sistema di Interscambio (SdI)	Italia	Trasmissione delle fatture elettroniche del Responsabile. Condizionale: il Servizio prevede il supporto per un intermediario esterno, ma la configurazione predefinita non trasmette nulla a un intermediario. Se la produzione ne utilizzi uno ad oggi è [DA COMPLETARE — vedi A.4]	Solo dati dell'Esercente — dati di fatturazione. Non dati degli Interessati	Trattamento in UE

Rimossi nella versione 1.1. Due fornitori indicati nell'Appendice A della versione 1.0 non sono, e non sono mai stati, ingaggiati, e sono stati rimossi:

• Resend — mai utilizzato. Non esiste alcuna dipendenza, alcun punto di chiamata né alcuna configurazione che lo riguardi in nessuna parte del Servizio. La posta transazionale è inviata via SMTP attraverso mail.tesserapp.eu. Sopravvive, come denominazione storica, una colonna di database chiamata resend_message_id, che viene riempita con l'identificativo del messaggio restituito dal server SMTP.
• FontAwesome, Inc. — non riceve nulla. cdn.woptima.com è la CDN di icone di proprietà del Responsabile, sotto propria licenza (vedi A.3); le icone di questo sito sono compilate all'interno delle pagine pubblicate.

A.2 Altri destinatari terzi

Servizi che ricevono dati come effetto diretto di una funzionalità di prodotto, senza che tali dati transitino dai sistemi del Responsabile. Non sono Sub-responsabili, perché il Responsabile non si trova nel percorso di trasmissione.

Destinatario	Che cosa riceve, e quando
Overpass — overpass-api.de, servizio pubblico del progetto OpenStreetMap	Su iOS, quando l'Interessato usa la funzione dei negozi vicini, il dispositivo invia a questo endpoint pubblico le coordinate GPS dell'Interessato, a piena precisione e non arrotondate, per cercare punti di interesse in un raggio di 50 metri. Non invia altro: nessun identificatore, nessuna carta, nessun dato dell'app. Su Android lo stesso client è presente nell'app, ma il relativo percorso di codice non viene attualmente raggiunto
LocationIQ (Unwired Labs)	Quando l'Esercente digita un indirizzo nella dashboard, il browser invia a LocationIQ il testo digitato (e, nei moduli delle sedi, il codice Paese). Non invia l'identità dell'Esercente né alcun dato di sessione. L'indirizzo IP del browser è implicito in ogni chiamata. La chiave pubblicabile è inclusa nel bundle della dashboard ed è limitata per dominio
Google LLC (Google Fonts)	I caratteri tipografici della dashboard sono caricati da fonts.googleapis.com e fonts.gstatic.com su ogni pagina: Google riceve pertanto l'indirizzo IP e il tipo di browser di chi apre la dashboard
Stripe, Inc. (Stripe.js)	La libreria di pagamento è caricata su ogni pagina della dashboard, non soltanto sulle pagine di fatturazione: Stripe riceve pertanto l'indirizzo IP e i dati tecnici del browser anche quando non è in corso alcun pagamento. I dati della carta sono inseriti in campi ospitati da Stripe e non transitano mai dai sistemi del Responsabile
Apple Inc. / Google LLC (Accedi con Apple / con Google)	Soltanto se l'Esercente scelga di accedere con Apple o con Google, e soltanto per l'operazione di accesso
Apple Inc. / Google LLC (backup del dispositivo, Wallet nativi)	Nel loro ruolo di fornitori dell'account dell'Interessato stesso: il database locale dell'app cliente, compresi il nome e l'email dell'intestatario sulle carte personali, è incluso nel backup dell'account iCloud o Google dell'Interessato

A.3 Infrastruttura propria del Responsabile

Componenti che possono sembrare servizi di terzi ma sono installazioni proprie del Responsabile, su domini propri, senza alcuna condivisione di dati con il produttore del software. Non sono Sub-responsabili.

Componente	Software	Ruolo
glitchtip.radiobros.com	GlitchTip (self-hosted)	Raccolta delle segnalazioni tecniche di errore e di crash delle app. Configurato per non raccogliere dati identificativi dell'utente, non tracciare le sessioni e non allegare indirizzi IP
helpdesk.radiobros.com	Zammad (self-hosted)	Sistema di assistenza per i ticket dell'Esercente. Riceve l'email di contatto e la denominazione dell'Esercente, e il titolo, il corpo e gli allegati di ciascun ticket
mail.tesserapp.eu	SMTP	Dominio di posta transazionale proprio del Responsabile. Chi gestisce il server sottostante è indicato al punto A.1
cdn.woptima.com	CDN statica sotto licenza propria del Responsabile	Consegna delle icone di interfaccia, sia al browser sia ai server del Responsabile quando questi compongono un pass Wallet. Nessun dato personale. FontAwesome, Inc. non riceve nulla
adminizer.radiobros.com	Authentik (self-hosted)	Provider di identità che presidia l'accesso amministrativo e machine-to-machine ai sistemi di produzione
Raccolta centralizzata dei log applicativi	Loki (self-hosted)	Diagnostica e sicurezza. Ove attiva, i log possono contenere indirizzi IP e il contesto tecnico di una richiesta
Indice di ricerca del catalogo	Meilisearch (self-hosted, sul server di produzione)	Ricerca sui programmi pubblici. Contiene dati dei programmi dell'Esercente, non dati degli Interessati: nessun nome, nessuna email, nessuna carta

A.4 Punti aperti della presente appendice

I seguenti elementi non sono desumibili dalla configurazione del Servizio e sono qui dichiarati come aperti anziché ipotizzati. Il Responsabile li completerà nella prossima versione e, qualora uno di essi comportasse l'aggiunta di un Sub-responsabile, darà il preavviso di 30 giorni prescritto dal §6.2:

1. Chi gestisce il server di posta mail.tesserapp.eu, il relativo luogo del trattamento e la base di trasferimento.
2. Il luogo del trattamento e la base di trasferimento di LocationIQ (Unwired Labs).
3. Il fornitore di hosting dei sottodomini *.radiobros.com propri del Responsabile, elencati al punto A.3.
4. Se la produzione trasmetta ad oggi le fatture elettroniche attraverso un intermediario SdI esterno.

L'elenco corrente è mantenuto nella presente appendice. La versione 1.0 rimandava l'Esercente a una pagina "Privacy → Sub-responsabili" della dashboard; tale pagina non esiste, e la presente appendice è l'elenco autoritativo.

Appendice B — Categorie di dati e tempi di conservazione

La versione 1.0 della presente appendice indicava tempi di conservazione che nessun processo faceva rispettare. Questa versione distingue i due casi, nella convinzione che sia preferibile descrivere come il Servizio si comporta realmente anziché pubblicare una scadenza che nulla applica.

B.1 Termini applicati da un processo automatico

Categoria	Conservazione	Base giuridica
Registrazioni delle consegne webhook verso l'Esercente (per le carte personali questi payload contengono il nome e l'email dell'intestatario)	30 giorni, cancellati automaticamente da una procedura pianificata. Alla cancellazione di una carta, nome, email e riferimento esterno sono immediatamente mascherati nei payload già memorizzati; la registrazione tecnica della chiamata (evento, esito, data) permane fino allo scadere dei 30 giorni	Legittimo interesse all'affidabilità dell'integrazione
Ciclo di vita dell'abbonamento dell'Esercente	Un abbonamento sospeso è disdetto dopo 60 giorni; 150 giorni dopo la disdetta è inviato un avviso di imminente cancellazione; 180 giorni dopo la disdetta l'account è anonimizzato, con rimozione di nome, email e riferimento esterno su ciascuna delle carte dei clienti dell'Esercente	Art. 28, par. 3, lett. g) GDPR; limitazione della conservazione
Cancellazione richiesta dall'Esercente dalla dashboard	Eseguita 30 giorni dopo la richiesta, con la medesima anonimizzazione. La finestra costituisce un periodo di grazia entro il quale la richiesta può essere revocata	Istruzione del Titolare
Singola carta cancellata dall'Interessato o dall'Esercente	Campi identificativi cancellati immediatamente e irreversibilmente; nessuna finestra di recupero. I record dipendenti e, ove nessuna registrazione contabile conservata lo richiami, il record della carta stesso sono rimossi entro 30 giorni; vedi B.2	Esecuzione del contratto del programma fedeltà
Intenti di pagamento non perfezionati per nuove sedi	24 ore, poi cancellati da una procedura giornaliera	Esecuzione del contratto (soli dati dell'Esercente)

B.2 Categorie prive di scadenza automatica

Per le categorie che seguono nessun processo pianificato cancella i dati. Essi sono rimossi su richiesta ai sensi del §7.3 e, in ogni caso, dall'anonimizzazione di cui al punto B.1.

Categoria	Che cosa avviene realmente
Identificatori delle carte fedeltà e record di carte in stato "cancellato"	Il record è conservato a tempo indeterminato in stato "cancellato". Alla cancellazione di una carta viene scritto un campo con la data di una rimozione definitiva, ma nessuna procedura lo legge: la rimozione definitiva è un'operazione amministrativa manuale. La "cancellazione entro 5 giorni" della versione 1.0 è ritirata
Metadati delle transazioni (timbri, premi, storni, variazioni di saldo)	Conservati come registro dell'attività dell'Esercente e non cancellati insieme a una singola carta. I riferimenti all'intestatario sono rimossi quando i dati dell'intestatario sono cancellati. I "24 mesi attivi, poi archiviati con riferimenti pseudonimizzati" della versione 1.0 sono ritirati: non esiste alcuna procedura di archiviazione
Eventi di audit e log di accesso, compresi indirizzo IP e user-agent	Conservati senza scadenza predefinita. Non esiste alcuna procedura di conservazione per essi, né una tabella separata di log di accesso. Costituiscono il registro di ciò che è stato fatto, compresa la prova che una cancellazione è stata eseguita. L'"azzeramento degli indirizzi IP alla cancellazione definitiva della carta" della versione 1.0 è ritirato
Registrazioni delle email in uscita (indirizzo del destinatario e contenuto delle variabili del modello)	Conservate senza scadenza automatica: nulla le cancella. I "30 giorni dalla conclusione del procedimento" della versione 1.0 sono ritirati
Indirizzo email dell'Interessato fornito volontariamente al Responsabile	Conservato per il tempo necessario a gestire la richiesta e a documentarne l'esito. Nessuna scadenza automatica
Comunicazioni dell'Esercente inviate agli intestatari di un programma (titolo, testo, immagine, link, numero di dispositivi raggiunti)	Conservate come registro delle comunicazioni dell'Esercente. Nessuna scadenza automatica
Registrazioni di installazione per le notifiche (hash del token di installazione, token di push, lingua, piattaforma, versione dell'app)	Conservate fino a richiesta di rimozione. Nessuna scadenza automatica
Identificatori e token di aggiornamento dei pass Apple / Google Wallet	Conservati fino a quando l'Interessato rimuove il pass dal Wallet nativo, oppure la carta è cancellata
Coordinate GPS	Non conservate affatto. Viaggiano nella singola richiesta che le utilizza e non sono memorizzate né dal Responsabile né sul dispositivo
Archivi di esportazione GDPR richiesti dall'Esercente	Lo ZIP è caricato sull'object storage e consegnato mediante un link firmato di 48 ore. L'archivio permane poi nel bucket fino a rimozione manuale: la regola di ciclo di vita a 7 giorni richiamata nel codice non è configurata. È la scadenza del link firmato, non una procedura di cancellazione, a limitare l'esposizione
Ticket di assistenza nel sistema di helpdesk del Responsabile	Conservati senza scadenza automatica
Segnalazioni tecniche di errore e di crash	Conservate nel sistema diagnostico proprio del Responsabile per il tempo necessario a correggere il difetto
Fatture dell'abbonamento dell'Esercente	Vedi §9.3: 10 anni ai sensi dell'art. 2220 c.c., che menziona espressamente le fatture; la normativa fiscale applicabile ne richiede almeno 7, già soddisfatti da tale termine. Dati dell'Esercente, non degli Interessati

Appendice C — Diritti degli Interessati e modalità di esercizio

L'Esercente è il primo destinatario delle richieste di esercizio dei diritti GDPR da parte dei propri clienti. radioBros assiste l'Esercente fornendo:

• uno strumento per i dati cliente nella dashboard (Impostazioni → Dati cliente) che cerca una carta per numero di serie e la cancella, rimuovendo il nome, l'indirizzo email e il riferimento esterno dell'intestatario. È l'unica azione per singolo Interessato disponibile in autonomia ad oggi; esportazione, rettifica e limitazione sono eseguite dal Responsabile su richiesta, come indicato al §7.3;
• la possibilità di richiedere direttamente a radioBros, all'indirizzo privacy@tesserapp.eu, l'esercizio dei diritti, che sarà inoltrato senza ritardo all'Esercente oppure eseguito su istruzione dell'Esercente;
• un registro di audit delle operazioni significative, tenuto dal Responsabile e messo a disposizione dell'Esercente su richiesta. La versione 1.0 lo descriveva come "accessibile in qualsiasi momento dall'Esercente"; ad oggi non ne esiste una vista nella dashboard, e il Responsabile fornisce l'estratto pertinente su richiesta.

Tempi indicativi di evasione (massimi ai sensi dell'art. 12 GDPR): 30 giorni dalla richiesta, prorogabili di ulteriori 60 giorni in caso di complessità della richiesta, con informativa all'Interessato.

Appendice D — Misure tecniche e organizzative (art. 32 GDPR)

Ciascuna misura che segue è contrassegnata come [in essere] se è implementata nel Servizio ad oggi, oppure come [impegno] se il Responsabile la assume come obbligo senza poterla ancora documentare. La versione 1.0 presentava come fatti diverse misure che i sistemi non implementavano; sono qui corrette.

D.1 Riservatezza

• [in essere] Cifratura in transito mediante TLS 1.2 o superiore su tutti gli endpoint esposti.
• [in essere] Cifratura a riposo con AES-256 (SSE) degli oggetti conservati su Cloudflare R2. I segreti applicativi — certificati dei pass Wallet, segreti TOTP — sono cifrati con AES-256-GCM sotto una chiave separata.
• [in essere] Hashing argon2id, con parametri compatibili con le linee guida OWASP, per le password degli account Esercente, i PIN degli operatori e i codici di recupero. Nessuna password è mai memorizzata in chiaro.
• [in essere] Hashing SHA-256 per i token casuali a elevata entropia — cookie di sessione, token di installazione, token di invito, chiavi API. La versione 1.0 affermava che i token di autenticazione fossero sottoposti ad hashing con argon2id; ciò non è esatto, e la scelta è deliberata: per un token casuale da 256 bit lo spazio di ricerca rende già irrealizzabile un attacco a forza bruta, per cui un hash volutamente lento non aggiunge nulla e costa una ricerca a ogni richiesta.
• [in essere] Alcuni token sono conservati così come emessi, non sottoposti ad hashing, perché devono essere riprodotti letteralmente verso un terzo o riconosciuti in una chiamata in ingresso: i token di notifica push (APNs, FCM), il token di autenticazione del pass Wallet e i token monouso di rivendicazione usati dall'iscrizione senza app. La loro esposizione è limitata dall'ambito — un token di push è privo di significato al di fuori dell'app del Servizio; un token di autenticazione del pass autorizza soltanto gli aggiornamenti di quel singolo pass — e dai controlli di accesso di cui al punto D.2.
• [in essere] Segregazione degli ambienti (produzione, staging, sviluppo) con credenziali distinte e nessun accesso ai dati di produzione dagli ambienti non-produzione.

D.2 Integrità

• [in essere] Controllo accessi basato su ruoli sulle infrastrutture di produzione, con accesso amministrativo e machine-to-machine presidiato dal provider di identità proprio del Responsabile (A.3).
• [in essere] Audit log di ogni operazione amministrativa e di ogni operazione significativa lato Esercente, scritto su una tabella dedicata alla quale l'applicazione esegue soltanto operazioni di aggiunta.
• [in essere] Migrazioni di schema del database versionate, tracciate da un giornale di hash che rileva la modifica di una migrazione già applicata.
• [in essere] Limitazione dei tassi di richiesta (rate limiting) sugli endpoint di autenticazione e sulle API pubbliche.

D.3 Disponibilità e resilienza

La versione 1.0 descriveva "backup automatici giornalieri del database con Point-In-Time Recovery (PITR) mediante WAL streaming (pgBackRest)". Nessuna parte di ciò è implementata. Quanto il Servizio effettivamente fa:

• [in essere] Dump logici orari del database (pg_dump, formato custom compresso), eseguiti da un container dedicato che si connette direttamente a PostgreSQL.
• [in essere] Verifica in tre passaggi di ogni dump prima della pubblicazione: il comando di dump deve terminare con esito positivo; il file deve superare una dimensione minima, il che intercetta il caso di fallimento "connesso, autenticato, schema vuoto"; e l'indice del dump deve contenere una tabella sentinella, il che dimostra che all'interno vi sono dati reali. È pubblicato soltanto un dump che superi tutti e tre i controlli, e soltanto un esito positivo verificato può innescare l'eliminazione dei dump più vecchi — così una serie di fallimenti non può in alcun caso erodere i backup validi rimasti.
• [in essere] Ritenzione piatta dei 168 dump più recenti, conservati sul filesystem del server di produzione. All'intervallo orario ciò corrisponde a circa una settimana di storico. Non esiste alcuna promozione a livelli.
• Non implementato, dichiarato apertamente: i dump non sono cifrati dal processo di backup; non esiste archiviazione dei WAL e pertanto nessun recupero a un istante puntuale — il punto di ripristino è l'intervallo di backup; e i dump non sono replicati fuori dal server. Un file di stato leggibile registra l'esito dell'ultima esecuzione.
• [impegno] Cifratura dei dump a riposo e copia fuori dal server.
• [impegno] Restore drill documentati con cadenza almeno annuale.
• [impegno] Monitoraggio dell'infrastruttura con allarmi su anomalie di sicurezza e di disponibilità.
• [in essere] Limitazione dei tassi di richiesta sugli endpoint pubblici. L'affermazione della versione 1.0 relativa a un "anti-DDoS perimetrale via Cloudflare" è ritirata: Cloudflare è utilizzato per l'object storage e la consegna delle risorse statiche e non si trova davanti all'API.

D.4 Procedure di verifica

• [impegno] Penetration test esterno annuale.
• [impegno] Revisione interna semestrale delle configurazioni di sicurezza.
• [impegno] Gestione delle vulnerabilità con obiettivi di rimedio definiti (critical: 7 giorni; high: 30 giorni; medium: 90 giorni).

D.5 Continuità del trattamento

• [impegno] Procedure documentate di disaster recovery e di gestione degli incidenti.
• [in essere] Sostituibilità dei Sub-responsabili infrastrutturali in tempi ragionevoli, essendo il Servizio distribuito a partire da una definizione di container versionata e non da servizi gestiti specifici di un fornitore.

D.6 Gestione degli incidenti

• [in essere] Un unico referente nominato per la gestione delle violazioni dei Dati personali, raggiungibile all'indirizzo privacy@tesserapp.eu.
• [impegno] Una procedura interna scritta di gestione delle violazioni con catena di notifica preordinata, a garanzia del rispetto del termine di 72 ore di cui all'art. 8 del presente DPA.

---

Contatti

• Responsabile del trattamento: radioBros di Alberto Miconi, Via Ridolfino Venuti 30, 00162 Roma (Italia), P.IVA IT15127451001.
• Email per ogni questione relativa al presente DPA: privacy@tesserapp.eu.
• Autorità di controllo competente per l'Esercente (ove diversa dal Garante italiano): l'Esercente è invitato a indicarla in fase di registrazione qualora abbia stabilimento principale in altro Stato membro dell'UE.

---

Versione 1.1 — adottata l'8 settembre 2026, in sostituzione della versione 1.0 del 30 maggio 2026. Lo storico delle versioni precedenti, ove disponibile, è archiviato in formato PDF agli URL https://tesserapp.eu/legal/dpa/v{version}.pdf.