Acuerdo de Tratamiento de Datos

Versión 1.1 · Última actualización: 8 de septiembre de 2026 · En vigor desde el 8 de septiembre de 2026

Este Acuerdo de Tratamiento de Datos (el "DPA") se celebra en virtud del artículo 28 del Reglamento (UE) 2016/679 ("RGPD") y del artículo 28 del Decreto Legislativo italiano 196/2003, modificado por el Decreto Legislativo 101/2018 (el Código italiano de Protección de Datos), entre el Comercio, en calidad de Responsable del Tratamiento, y radioBros, en calidad de Encargado del Tratamiento, y regula el tratamiento de los datos personales de los clientes del Comercio en el marco del servicio TesserApp.

La versión 1.1 alinea el presente DPA con la versión 1.2 de la Política de Privacidad, tras una revisión completa del código fuente del Servicio. Amplía a todos los tipos de tarjeta personal y al alta web sin app la información que anteriormente estaba redactada solo para los programas privados; sustituye la lista de subencargados, la tabla de conservación y la descripción de las medidas de seguridad por lo que los sistemas hacen realmente; y elimina los compromisos que ningún proceso automatizado aplicaba. Donde el presente DPA y la Política de Privacidad describen el mismo tratamiento, la intención es que digan lo mismo.

La versión italiana de este DPA es la versión oficial y prevalece sobre las traducciones en caso de discrepancia.

1. Partes

1.1 Responsable del Tratamiento: la persona física o jurídica que se registra en la plataforma TesserApp Shop y se suscribe al Servicio (en adelante, el "Comercio"). Los datos identificativos del Comercio son los introducidos en el momento del registro y modificables desde el panel de control.

1.2 Encargado del Tratamiento: radioBros di Alberto Miconi, con sede en Via Ridolfino Venuti 30, 00162 Roma (Italia), número de IVA italiano (Partita IVA) IT15127451001, correo de contacto privacy@tesserapp.eu (en adelante, "radioBros").

Las Partes reconocen mutuamente los roles anteriores, sin perjuicio del rol independiente de radioBros como Responsable del Tratamiento para sus propios tratamientos en el marco de la ejecución de la suscripción (facturación, cuenta del Comercio, registros de seguridad de sus propios sistemas), regidos por la Política de Privacidad y los Términos del Servicio.

2. Definiciones

Se aplican las definiciones del artículo 4 del RGPD. Adicionalmente:

• "Datos Personales": cualquier información relativa a una persona física identificada o identificable en el sentido del art. 4, nº 1, del RGPD, tratada por el Encargado por cuenta del Responsable en el marco del Servicio.
• "Interesado": el cliente del Comercio que es titular de una tarjeta de fidelidad de uno de los programas del Comercio, ya la conserve en la app móvil TesserApp o únicamente en Apple Wallet o Google Wallet.
• "Servicio": la plataforma web, las aplicaciones móviles y los componentes de infraestructura que radioBros pone a disposición del Comercio para operar sus programas de fidelidad.
• "Tarjeta personal": una tarjeta que, por construcción, se emite a favor de una única persona identificada. Existen cuatro tipos: privada (tarjeta de sellos personal), descuento, acceso y prepago. En los cuatro casos, el nombre y el correo electrónico del titular son obligatorios.
• "Tarjeta anónima": una tarjeta estándar (de sellos) o una tarjeta de puntos, que el Interesado activa por sí mismo desde la app o desde el catálogo y que no lleva nombre ni correo electrónico.
• "Subencargado": cualquier tercero que el Encargado contrate para tratar Datos Personales, en virtud del art. 28, apdo. 4, del RGPD. La lista figura en el Anexo A, sección A.1.
• "Violación de Datos Personales": según se define en el art. 4, nº 12, del RGPD.

3. Objeto, duración, naturaleza y finalidades del tratamiento

3.1 El Comercio, como Responsable, encarga a radioBros, como Encargado, el tratamiento de los Datos Personales de los Interesados para las finalidades necesarias para la prestación del Servicio y establecidas en el presente DPA.

3.2 Objeto: la operación técnica del programa de fidelidad del Comercio, incluyendo la activación de tarjetas de cliente, el registro de transacciones (sellos otorgados, premios canjeados, reversos, variaciones de un saldo de puntos o de crédito), la sincronización de tarjetas con Apple Wallet y Google Wallet, el envío de notificaciones push relacionadas con el programa de fidelidad, la entrega de los avisos que el Comercio redacta para los titulares de uno de sus programas, la exposición del programa en el catálogo de la app de consumidor (cuando el Comercio haya optado por la visibilidad pública), la provisión de funciones de descubrimiento basadas en la ubicación y, adicionalmente:

• para las tarjetas personales (privada, descuento, acceso, prepago): la emisión de una tarjeta a un único titular identificado, la entrega de una invitación de instalación por correo electrónico y la vinculación de la tarjeta a la cuenta de dispositivo del titular;
• para el alta web sin app (solo tarjetas estándar): la creación de una tarjeta y de un pase Wallet nativo desde una página web, sin que el Interesado instale la app de consumidor, junto con el nombre, el correo electrónico y el marcador de consentimiento de marketing opcionales que el formulario de alta pueda recabar.

3.3 Naturaleza del tratamiento: tratamiento automatizado realizado sobre la infraestructura informática del Encargado y de sus Subencargados autorizados.

3.4 Finalidades: ejecución del contrato entre el Comercio y sus propios clientes en relación con el programa de fidelidad; cumplimiento de las obligaciones legales del Comercio como Responsable; seguridad de los sistemas informáticos y prevención del fraude en sellos, premios y saldos; entrega de tarjetas personales a las personas concretas designadas por el Responsable y restricción de cada una de esas tarjetas a la cuenta de dispositivo del titular; y, en el alta web sin app, creación de una tarjeta para un Interesado que no ha instalado la app.

3.5 Duración: el presente DPA está vigente durante toda la duración de la suscripción del Comercio al Servicio. Las obligaciones de los artículos 9 (Devolución y supresión) y 13 (Confidencialidad) subsisten tras la terminación.

4. Categorías de Interesados y de Datos Personales

4.1 Categorías de Interesados: clientes del Comercio titulares de una tarjeta de fidelidad de uno de los programas del Comercio, ya sea en la app de consumidor TesserApp o únicamente en un Wallet nativo.

4.2 Categorías de Datos Personales tratados (Anexo B):

• identificadores de instalación anónimos (tokens aleatorios de 256 bits, no vinculados a la identidad de una persona, almacenados por el Encargado únicamente como hash criptográfico);
• identificadores de las tarjetas de fidelidad (UUID opacos) y números de serie de las tarjetas;
• metadatos de transacción (otorgamientos de sellos, canjes de premios, reversos, variaciones del saldo de puntos o de crédito; fecha, hora y establecimiento del Comercio en el que tuvo lugar la operación; el importe o el número de sellos solicitados; y, en un reverso, el motivo en texto libre escrito por el Comercio);
• identificadores de pase Apple Wallet / Google Wallet, tokens de actualización del pase, identificador que el sistema operativo asigna a la biblioteca de pases del dispositivo y los tokens push asociados;
• tokens de notificación push emitidos por Apple (APNs) o Google (FCM), registrados para la instalación de la app en sí misma;
• idioma del sistema del dispositivo, plataforma (iOS o Android) y versión de la app;
• direcciones IP y cadenas user-agent, registradas en los registros de auditoría y de acceso con fines de seguridad. Contrariamente a lo que afirmaba la versión 1.0 del presente DPA, no se tratan de forma transitoria: se conservan según se describe en el Anexo B, sección B.2;
• coordenadas GPS, exclusivamente cuando el Interesado haya activado la función de descubrimiento de comercios cercanos o consulte el catálogo ordenado por distancia, y solo durante esa petición. Las coordenadas no se almacenan, ni por el Encargado ni en el dispositivo;
• dirección de correo electrónico del Interesado, cuando la facilite voluntariamente al Encargado (solicitudes de ejercicio de derechos RGPD, contactos con el soporte);
• informes técnicos de error y de fallo, que incluyen el modelo del dispositivo, la versión del sistema operativo y la versión de la app, y pueden contener el identificador técnico de una tarjeta o de un programa implicados en el error. Están configurados para no recabar datos identificativos del usuario y para no adjuntar la dirección IP.

4.2 bis — Tarjetas personales (privada, descuento, acceso, prepago): para los cuatro tipos de tarjeta personal, y no solo para los programas privados:

• el nombre y la dirección de correo electrónico del titular, ambos obligatorios, facilitados por el Responsable al crear la tarjeta y tratados para emitir la tarjeta, enviar una invitación de instalación por correo electrónico, imprimir los datos del titular en la tarjeta y en el pase Wallet y mostrarlos al personal del Comercio cuando se escanea la tarjeta;
• una referencia externa (external_ref) — el identificador que el Responsable ya emplea para esa persona física en sus propios sistemas, por ejemplo un número de empleado o de socio — cuando el Responsable la establezca a través de la API de integración o del conector MCP;
• una referencia pseudónima de vinculación a la cuenta de dispositivo (un identificador opaco derivado de la cuenta iCloud o Google del titular, no de su nombre ni de su correo electrónico), tratada únicamente para garantizar que la tarjeta permanezca en la cuenta del titular.

El Responsable garantiza que dispone de una base jurídica y, cuando proceda, del consentimiento del Interesado para facilitar estos datos; el Encargado los trata exclusivamente conforme a las instrucciones documentadas del Responsable.

4.2 ter — Alta web sin app (solo tarjetas estándar): cuando un Interesado obtiene una tarjeta estándar dándose de alta desde una página web y añadiéndola directamente a Apple Wallet o Google Wallet, sin instalar la app de consumidor, el formulario de alta puede recabar:

• un nombre opcional y una dirección de correo electrónico opcional. Si se dejan en blanco, la tarjeta se crea de forma anónima, exactamente igual que una tarjeta activada en la app; si se rellenan, se asocian a la tarjeta y se tratan por cuenta del Responsable conforme al §4.2 bis;
• un marcador de consentimiento de marketing, formado por la fecha y el origen de la captación. A día de hoy es únicamente un campo almacenado: no se envía ningún mensaje promocional sobre su base, ni por el Encargado ni por el Responsable a través de los sistemas del Encargado.

El alta web sin app solo está disponible para los programas estándar (de sellos). La página de alta que radioBros publica por sí misma no solicita ninguno de estos campos; siguen disponibles para el Responsable que integre la función en sus propias herramientas.

4.3 Datos NO tratados: dirección postal del Interesado; número de teléfono del Interesado; datos de pago del Interesado (el Servicio no trata pagos del cliente al Comercio); historial de navegación; datos biométricos; identificadores publicitarios; categorías especiales de datos conforme al art. 9 del RGPD; datos relativos a condenas penales conforme al art. 10 del RGPD; datos de menores de 16 años (el Servicio no se dirige a esa franja de edad). El Encargado no emplea ningún SDK publicitario, de atribución o de analítica y no construye ningún perfil de comportamiento.

Que se traten un nombre y un correo electrónico depende de la vía por la que se obtuvo la tarjeta, y no únicamente del tipo de tarjeta. La versión 1.0 del presente DPA afirmaba que "en todos los programas estándar/públicos, el nombre y el correo siguen sin tratarse". Eso ya no es exacto, y la posición correcta es la siguiente:

Cómo se obtuvo la tarjeta	Nombre y correo electrónico
Tarjeta estándar o de puntos activada por el propio Interesado en la app (código QR o catálogo)	No se tratan. La tarjeta es anónima y sigue siéndolo
Tarjeta personal (privada, descuento, acceso, prepago) creada por el Responsable	Siempre se tratan — ambos son obligatorios (§4.2 bis)
Tarjeta estándar obtenida mediante alta web sin app	Opcionales — se tratan solo si el formulario los recaba y el Interesado los rellena (§4.2 ter)
Tarjeta creada por el Responsable a través de la API de integración o del conector MCP	Nombre y correo como arriba, más la referencia externa del Responsable (§4.2 bis)

5. Obligaciones del Encargado del Tratamiento

El Encargado se compromete a:

5.1 tratar los Datos Personales únicamente siguiendo instrucciones documentadas del Responsable, incluso respecto a las transferencias de Datos Personales a un tercer país u organización internacional, salvo que esté obligado a ello por el Derecho de la Unión o de los Estados miembros que se aplique al Encargado; en tal caso, el Encargado informará al Responsable de esa exigencia legal previa al tratamiento, salvo que dicha ley lo prohíba por razones importantes de interés público;

5.2 garantizar que las personas autorizadas para tratar los Datos Personales se hayan comprometido a respetar la confidencialidad o estén sujetas a una obligación legal de confidencialidad adecuada;

5.3 adoptar todas las medidas requeridas en virtud del art. 32 del RGPD, según se describe en el Anexo D del presente DPA;

5.4 respetar las condiciones señaladas en los apartados 2 y 4 del art. 28 del RGPD para la contratación de Subencargados, según se especifica en el art. 6 del presente DPA;

5.5 teniendo en cuenta la naturaleza del tratamiento, asistir al Responsable mediante medidas técnicas y organizativas apropiadas, en la medida de lo posible, para el cumplimiento de la obligación del Responsable de responder a las solicitudes de ejercicio de los derechos del Interesado conforme a los arts. 15-22 del RGPD;

5.6 asistir al Responsable a garantizar el cumplimiento de las obligaciones previstas en los arts. 32 a 36 del RGPD, teniendo en cuenta la naturaleza del tratamiento y la información disponible para el Encargado;

5.7 a elección del Responsable, suprimir o devolver todos los Datos Personales tras finalizar la prestación de servicios de tratamiento, y suprimir las copias existentes, salvo que el Derecho de la Unión o de los Estados miembros exija la conservación de los datos;

5.8 poner a disposición del Responsable toda la información necesaria para demostrar el cumplimiento de las obligaciones establecidas en el art. 28 del RGPD, y permitir y contribuir a la realización de auditorías, incluidas las inspecciones, por parte del Responsable o de otro auditor designado por el Responsable;

5.9 informar inmediatamente al Responsable si, en su opinión, una instrucción infringe el RGPD u otras disposiciones de protección de datos de la Unión o de los Estados miembros.

6. Subencargados

6.1 El Comercio otorga al Encargado autorización general para contratar a los Subencargados enumerados en el Anexo A, sección A.1 del presente DPA.

6.2 El Encargado informará al Comercio de cualquier cambio previsto relativo a la incorporación o sustitución de otros Subencargados con un preaviso mínimo de 30 días, dando así al Comercio la oportunidad de oponerse a tales cambios.

6.3 En caso de oposición motivada del Comercio, el Encargado evaluará soluciones técnicas alternativas. Cuando no sea posible evitar al nuevo Subencargado, el Comercio podrá resolver la suscripción sin penalización, con efecto desde la fecha en que el nuevo Subencargado entre en funcionamiento.

6.4 El Encargado celebra con cada Subencargado un contrato escrito que contiene obligaciones de protección de datos equivalentes a las establecidas en el presente DPA, en particular en materia de medidas técnicas y organizativas adecuadas, confidencialidad, asistencia al Responsable y cooperación con la autoridad de control.

6.5 El Encargado sigue respondiendo ante el Comercio por la actuación del Subencargado dentro de los límites previstos en el art. 28, apdo. 4, del RGPD.

6.6 El Anexo A enumera además, de forma separada de los Subencargados, los otros destinatarios terceros que reciben datos como efecto directo de una funcionalidad del producto sin que esos datos pasen por los sistemas del Encargado (sección A.2), así como los componentes que son instalaciones propias del Encargado en sus propios dominios y, por tanto, no son Subencargados (sección A.3). La distinción refleja la utilizada en el §4 de la Política de Privacidad.

7. Derechos de los Interesados

7.1 Teniendo en cuenta la naturaleza del tratamiento, el Encargado asiste al Responsable mediante medidas técnicas y organizativas adecuadas, en la medida de lo posible, para el cumplimiento de la obligación del Responsable de responder a las solicitudes de ejercicio de los derechos de los Interesados conforme al capítulo III del RGPD (arts. 12-22), y en particular:

• derecho de acceso (art. 15);
• derecho de rectificación (art. 16);
• derecho de supresión (art. 17), operativizado mediante el flujo descrito en el artículo 9 siguiente, cuyo primer paso es la supresión inmediata e irreversible de los datos identificativos del titular;
• derecho a la limitación del tratamiento (art. 18);
• derecho a la portabilidad de los datos (art. 20);
• derecho de oposición (art. 21);
• derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado (art. 22): el Servicio no realiza elaboración de perfiles automatizada con efectos jurídicos para el Interesado.

7.2 Las solicitudes recibidas directamente por el Encargado se remiten sin demora al Responsable, salvo que el Encargado esté autorizado por escrito por el Responsable para responder directamente.

7.3 Qué ofrece realmente el panel a día de hoy. La versión 1.0 del presente DPA afirmaba que el panel ponía a disposición herramientas para exportar, anonimizar y suspender los datos de un Interesado concreto. De esas herramientas solo existe una. La posición exacta es la siguiente:

Derecho	Cómo se ejerce a día de hoy
Supresión de un Interesado concreto	En autoservicio desde el panel. En Ajustes → Datos de cliente, el Responsable puede buscar una tarjeta por su número de serie y suprimirla. La supresión retira de la tarjeta el nombre, el correo electrónico y la referencia externa del titular
Exportación de los datos de un Interesado concreto	A petición, ejecutada por el Encargado. En el panel no existe una exportación por Interesado. La función de exportación de datos del panel produce el archivo de la cuenta del propio Responsable, no el expediente de un Interesado concreto. Basta escribir a privacy@tesserapp.eu y el Encargado preparará el extracto
Rectificación de los datos de un Interesado concreto	A petición, ejecutada por el Encargado, o por el Responsable reemitiendo la tarjeta
Limitación / suspensión de un Interesado concreto	A petición, ejecutada por el Encargado. En el panel no existe un control de suspensión por Interesado

7.4 El Encargado se compromete a ampliar las herramientas de autoservicio a la exportación y a la limitación por Interesado. Hasta que existan, el presente DPA no las presenta como disponibles, y las solicitudes previstas en el §7.3 son atendidas por el Encargado dentro de los plazos del Anexo C.

8. Notificación de Violaciones de Datos Personales

8.1 En caso de Violación de Datos Personales de la que el Encargado tenga conocimiento, el Encargado notificará el incidente al Responsable sin dilación indebida y, en cualquier caso, en un plazo de 72 horas desde que tenga conocimiento del mismo, proporcionando, en la medida de lo posible, la información a que se refiere el art. 33, apdo. 3, del RGPD y, en particular:

• la naturaleza de la violación, las categorías y el número aproximado de Interesados afectados;
• las categorías y el número aproximado de registros de datos personales afectados;
• los datos de contacto del punto de contacto para el incidente;
• las probables consecuencias de la violación;
• las medidas adoptadas o propuestas para afrontarla y mitigar sus posibles efectos adversos.

8.2 Cuando, y en la medida en que, no sea posible facilitar la información simultáneamente, la información podrá facilitarse de manera gradual sin demora indebida adicional.

8.3 Se entiende que corresponde al Responsable, conforme a los arts. 33 y 34 del RGPD, decidir si notifica la violación a la autoridad de control y la comunica a los Interesados.

9. Devolución y supresión de los Datos Personales tras la terminación

9.1 Exportación. Al terminar la suscripción, y en todo caso dentro de los 30 días siguientes a la terminación, el Comercio podrá solicitar al Encargado la exportación íntegra de los Datos Personales en un formato estructurado, de uso común y de lectura mecánica. La exportación se produce como archivo ZIP con ficheros JSON, se sube al almacenamiento de objetos del Encargado y se entrega al Comercio mediante un enlace firmado válido durante 48 horas. El material identificativo del lado del cliente que no corresponde al Comercio recibir (hashes de los tokens de instalación, direcciones IP) se anonimiza dentro del archivo.

9.2 Supresión. Transcurrido el plazo anterior sin solicitud de exportación, o una vez completada la exportación, el Encargado procede a suprimir los Datos Personales. El ciclo de vida que el Servicio aplica realmente es el siguiente, y se retira la afirmación de la versión 1.0 según la cual los datos se "suprimen definitivamente de los sistemas de producción en un plazo de 5 días":

• una suscripción suspendida se cancela automáticamente a los 60 días;
• 150 días después de la cancelación se envía al Comercio un aviso de que sus datos van a suprimirse;
• 180 días después de la cancelación la cuenta se anonimiza automáticamente. La anonimización elimina el nombre y el correo de acceso, la contraseña, el segundo factor, las passkeys, las identidades sociales, el personal, los dispositivos vinculados, las claves de API y el nombre, el correo electrónico y la referencia externa en cada una de las tarjetas de los clientes del Comercio;
• cuando el Comercio solicita la supresión desde el panel, la misma anonimización se ejecuta 30 días después de la solicitud, siendo ese plazo una ventana de cortesía en la que la solicitud puede cancelarse;
• en una tarjeta individual suprimida los campos identificativos del titular se borran en el momento mismo de la solicitud, junto con la credencial de instalación que vinculaba la tarjeta al dispositivo del titular; desde ese momento la supresión es irreversible y no existe ninguna ventana de recuperación. En 30 días un proceso nocturno programado elimina los registros dependientes y el propio registro de la tarjeta, salvo que un asiento contable conservado lo mencione: el registro se purga entonces in situ y queda un identificador desnudo que no identifica a nadie, retirado en cualquier caso con la anonimización descrita más arriba.

9.3 Datos excluidos de la supresión. Quedan excluidos de la supresión, por el tiempo estrictamente necesario, los Datos Personales cuya conservación venga impuesta por obligaciones legales que vinculan a radioBros. Esto afecta a las facturas propias del Encargado al Comercio, no a datos de Interesados, y el plazo de conservación es de 10 años:

• El art. 2220 del Código Civil italiano obliga a conservar durante 10 años las facturas — las recibidas y las copias de las emitidas — y los registros contables que las mencionan. Es la obligación efectivamente aplicada y es el plazo indicado en la Política de Privacidad y en los Términos del Servicio.
• La normativa fiscal italiana aplicable (DPR 633/1972; D.Lgs. 127/2015) fija un mínimo más corto, de 7 años, ya satisfecho por el plazo anterior.

Tales datos se conservan en custodia separada, con acceso restringido y auditado, y no son objeto de ningún otro tratamiento distinto del cumplimiento de la obligación.

9.4 A solicitud escrita del Comercio, el Encargado emite una declaración formal de supresión realizada.

10. Transferencias internacionales de datos

10.1 El Encargado trata los Datos Personales en sus propios sistemas exclusivamente sobre infraestructura ubicada en el Espacio Económico Europeo. Los sistemas de producción están alojados en Alemania.

10.2 Algunos Subencargados enumerados en el Anexo A pueden tener su sede u operaciones en los Estados Unidos (en particular Stripe, Apple, Google, Cloudflare). Las transferencias de Datos Personales a dichas partes se realizan sobre la base de las Cláusulas Contractuales Tipo adoptadas por la Comisión Europea mediante la Decisión 2021/914/UE, complementadas con medidas adicionales cuando sea necesario a la luz de la sentencia del TJUE C-311/18 (Schrems II).

10.2 bis — Transferencias que no pasan por los sistemas del Encargado. Algunos destinatarios enumerados en el Anexo A, sección A.2, son contactados directamente por el navegador del Comercio o por el dispositivo del Interesado, como efecto directo de una funcionalidad del producto. Para estos, el lugar del tratamiento es el propio del destinatario y el Encargado no está en la vía de transmisión:

• Overpass (overpass-api.de, un servicio público del proyecto OpenStreetMap): en iOS, el dispositivo del Interesado le envía las coordenadas GPS cuando se usa la función de comercios cercanos;
• LocationIQ (Unwired Labs): el navegador del Comercio le envía el texto de la dirección escrito en el panel;
• Google Fonts y Stripe.js: cargados por el panel en cada página, de modo que la dirección IP y el tipo de navegador de quien abre el panel llegan a Google y a Stripe respectivamente.

10.3 No se realizan transferencias a terceros países fuera del marco de las Cláusulas Contractuales Tipo o de una decisión de adecuación de la Comisión, salvo las llamadas directas desde el navegador y desde el dispositivo previstas en el §10.2 bis, cuya base de transferencia se indica en el Anexo A.

11. Medidas técnicas y organizativas

Las medidas técnicas y organizativas adoptadas por el Encargado conforme al art. 32 del RGPD se describen en el Anexo D del presente DPA, que forma parte integrante del mismo. El Anexo D distingue las medidas ya implantadas de aquellas que el Encargado se compromete a implantar. Estas medidas están sujetas a una actualización periódica que refleje el estado de la técnica; cualquier actualización no podrá traducirse en una reducción del nivel de seguridad garantizado.

12. Auditoría

12.1 El Encargado pone a disposición del Responsable, previa solicitud escrita, la información necesaria para demostrar el cumplimiento de las obligaciones derivadas del art. 28 del RGPD y del presente DPA.

12.2 El Responsable podrá solicitar, una vez por año natural, la realización de una auditoría, que se llevará a cabo previa notificación escrita con al menos 30 días de antelación, durante el horario laboral, en las instalaciones del Encargado, en una modalidad que no interfiera con la continuidad operativa del Servicio y respete las medidas de seguridad vigentes.

12.3 Los costes directos de la auditoría correrán a cargo del Responsable, salvo que la auditoría revele incumplimientos significativos del presente DPA imputables al Encargado, en cuyo caso los costes correrán a cargo del Encargado.

12.4 El Encargado no dispone a día de hoy de ninguna certificación de seguridad emitida por un tercero (ningún informe SOC 2, ningún certificado ISO 27001). Si obtuviera alguna, podrá ofrecer, en sustitución de la auditoría in situ, el correspondiente informe de auditor independiente junto con documentación equivalente.

13. Confidencialidad

13.1 Las Partes se comprometen a tratar como estrictamente confidencial toda la información adquirida en la ejecución del presente DPA, salvo la información que sea de dominio público o cuya divulgación sea exigida por ley u orden de la autoridad.

13.2 La obligación de confidencialidad se extiende a los empleados, colaboradores y Subencargados de las Partes y sobrevive a la terminación del presente DPA.

14. Responsabilidad e indemnización

14.1 Cada Parte responde por los daños causados por su tratamiento que infrinjan el RGPD, en los términos y condiciones previstos por el art. 82 del RGPD.

14.2 En las relaciones internas entre las Partes, la responsabilidad de radioBros frente al Comercio por el tratamiento de los Datos Personales se rige por la cláusula de limitación de responsabilidad contenida en los Términos del Servicio, salvo en caso de dolo o culpa grave y sin perjuicio de la responsabilidad frente al Interesado conforme al RGPD.

14.3 El Comercio garantiza y mantiene indemne a radioBros frente a cualquier reclamación derivada del incumplimiento por parte del Comercio de sus propias obligaciones como Responsable conforme al RGPD (en particular: información adecuada a los Interesados conforme a los arts. 13-14 del RGPD; base jurídica adecuada para el tratamiento; corrección de las instrucciones impartidas al Encargado).

15. Duración, modificaciones y disposiciones finales

15.1 Duración. El presente DPA será efectivo a partir de la fecha de aceptación por el Comercio en el momento del registro (mediante casilla de verificación dedicada) y durante toda la duración de la suscripción al Servicio. Las obligaciones de devolución/supresión (art. 9) y de confidencialidad (art. 13) sobreviven a la terminación.

15.2 Modificaciones. Las modificaciones materiales del presente DPA se comunicarán al Comercio con un preaviso mínimo de 30 días mediante correo electrónico a la dirección registrada en la cuenta y mediante un banner dedicado en el panel de control. Se exigirá al Comercio aceptar de nuevo la nueva versión en el siguiente inicio de sesión. La no aceptación dará derecho a rescindir la suscripción sin penalización.

15.2 bis — Entrada en vigor de la versión 1.1. La versión 1.1 del presente DPA entra en vigor en la fecha de publicación indicada en el encabezado de este documento, sin esperar el preaviso de 30 días previsto en el §15.2. La razón reside en la naturaleza de esta revisión: la versión 1.1 no impone al Responsable del tratamiento obligaciones nuevas ni reduce las garantías de los Interesados, sino que corrige afirmaciones inexactas de la versión 1.0, amplía la información facilitada y retira compromisos que ningún proceso del Servicio llegó nunca a ejecutar — entre ellos la supresión «en cinco días» a la que se refiere el §9.2, que los sistemas no realizaban. En varios puntos el texto resultante es menos favorable al Encargado y más favorable a quien lo lee, porque deja de sobrevalorar la confidencialidad ofrecida y de prometer supresiones que no se producían. Diferir 30 días una corrección de esta clase significaría mantener en vigor durante otros 30 días un texto que se sabe inexacto: el preaviso del §15.2 existe para proteger al Comercio frente a modificaciones que alteran las obligaciones, no para retrasar la descripción veraz de un tratamiento ya en curso. Este razonamiento no se extiende al §6.2, que la presente disposición deja del todo intacto. El nuevo Anexo A enumera destinatarios que la versión 1.0 no recogía: la mayoría ya intervenía en el tratamiento y ahora simplemente se pone por escrito. Al menos uno, sin embargo — Unwired Labs (LocationIQ), del que el Encargado se sirve desde junio de 2026 para el autocompletado de direcciones en el panel del Comercio — fue efectivamente añadido después de la versión 1.0, y la situación de los demás puntos indicados en el Anexo A, sección A.4 no está aún determinada. Para ellos el §6.2 se aplica íntegramente: el preaviso de 30 días y el derecho de oposición del Comercio se dan como ese artículo exige, y la sección A.4 lo hace constar.

El §15.2 permanece intacto. El §15.2 conserva plena eficacia para toda modificación futura del presente DPA. El §15.2 bis es una excepción transitoria de aplicación única, limitada a la entrada en vigor de la versión 1.1: no reduce, no reinterpreta ni suspende el preaviso de 30 días, la exigencia de nueva aceptación ni la facultad de resolución sin penalización que el §15.2 reconoce al Comercio, y lo mismo vale para el §6.2 en cuanto a la incorporación efectiva de un nuevo Subencargado. Toda modificación posterior que altere las obligaciones de las Partes se rige íntegramente por el §15.2.

El preaviso que se da con esta publicación. Con la entrada en vigor de la versión 1.1 se dan: la publicación del texto en esta página, con la fecha y el número de versión en el encabezado; una comunicación por correo electrónico a los Comercios a la dirección registrada en la cuenta; y la solicitud de aceptación de la nueva versión, que se dirigirá al Comercio cuando la función correspondiente esté disponible — en la fecha de publicación el Servicio no dispone de un mecanismo de nueva aceptación, y esta disposición no promete ninguno antes de entonces. No se dirige ninguna comunicación a los Interesados a través de la aplicación: la aplicación no es un canal de comunicaciones legales. El Comercio que no desee aceptar la versión 1.1 conserva la facultad de resolución sin penalización prevista en el §15.2.

15.3 Lengua. La versión italiana del presente DPA es la versión oficial y prevalece sobre las traducciones en caso de discrepancia.

15.4 Ley aplicable y jurisdicción. El presente DPA se rige por la ley italiana. Cualquier controversia queda sometida a la jurisdicción exclusiva del Tribunal de Roma.

15.5 Trazabilidad de la aceptación. La aceptación del DPA es trazada por el Encargado mediante el registro de: razón social del Comercio, correo del usuario que aceptó, dirección IP, marca temporal y versión del DPA aceptada. Estos datos constituyen prueba de la aceptación conforme a los arts. 20 y 21 del Decreto Legislativo italiano 82/2005 (Código de la Administración Digital).

---

Anexo A — Subencargados, otros destinatarios e infraestructura propia

El presente anexo emplea la misma división en tres bloques que el §4 de la Política de Privacidad, de modo que ambos documentos puedan leerse en paralelo.

A.1 Subencargados (art. 28 del RGPD)

Proveedores que tratan Datos Personales por cuenta del Encargado, en virtud de un acuerdo conforme al art. 28. La columna "Datos de quién" es determinante: algunos de estos proveedores solo tocan datos propios del Comercio y nunca datos de Interesados.

Subencargado	Sede y lugar del tratamiento	Rol	Datos de quién, y cuáles	Base de la transferencia
Contabo GmbH	Alemania	Alojamiento VPS de todos los sistemas de producción: base de datos, aplicación, colas de trabajo, caché, índice de búsqueda del catálogo y los volcados de base de datos descritos en D.3	Datos de Interesados — todas las categorías objeto del Servicio	Tratamiento en la UE
Stripe Payments Europe Ltd.	Irlanda (grupo con operaciones en EE. UU.)	Procesamiento de los pagos de la suscripción del Comercio; emisión de facturas	Solo datos del Comercio — datos de pago y fiscales. No datos de Interesados	SCC 2021/914/UE
Cloudflare, Inc.	EE. UU. — buckets R2 configurados en región UE	Almacenamiento de objetos para las imágenes de programa y de tarjeta de acceso que sube el Comercio y para los archivos de exportación RGPD que solicita el Comercio; CDN para recursos estáticos. Aquí no se almacena ninguna copia de seguridad de la base de datos (véase D.3)	Datos del Comercio, y datos de Interesados en la medida en que estén contenidos en un archivo de exportación solicitado por el Comercio	SCC 2021/914/UE
Apple Inc.	EE. UU.	Entrega de pases Apple Wallet y notificaciones push (APNs); aprovisionamiento del Pass Type ID y del certificado de firma propios del Comercio a través de la API de App Store Connect	Datos de Interesados — tokens push, identificadores de pase y el propio contenido del pase, que en las tarjetas personales incluye el nombre y el correo del titular. Las llamadas a App Store Connect solo llevan identificadores del Comercio	SCC 2021/914/UE
Google LLC	EE. UU.	Entrega de pases Google Wallet (API de Google Wallet) y notificaciones push (Firebase Cloud Messaging)	Datos de Interesados — igual que en Apple	SCC 2021/914/UE
Operador del servidor de correo transaccional mail.tesserapp.eu	[POR COMPLETAR — véase A.4]	Envío de correo transaccional por SMTP: invitaciones de instalación de tarjeta, avisos de actividad, comunicaciones de servicio	Datos de Interesados — dirección de correo del destinatario y contenido del mensaje; y datos del Comercio	[POR COMPLETAR — véase A.4]
Unwired Labs (LocationIQ)	[POR COMPLETAR — véase A.4]	Autocompletado de direcciones en el panel del Comercio. Contratado por el Encargado, pero la llamada parte directamente del navegador del Comercio con una clave publicable y no pasa por los sistemas del Encargado — véanse A.2 y §10.2 bis	Solo datos del Comercio — el texto de la dirección escrito y la dirección IP del navegador. No datos de Interesados	[POR COMPLETAR — véase A.4]
Intermediario de facturación electrónica ante el Sistema di Interscambio italiano (SdI)	Italia	Transmisión de las facturas electrónicas propias del Encargado. Condicional: el Servicio contempla un intermediario externo, pero la configuración por defecto no transmite nada a ninguno. Si producción utiliza uno a día de hoy queda [POR COMPLETAR — véase A.4]	Solo datos del Comercio — datos de facturación. No datos de Interesados	Tratamiento en la UE

Eliminados en la versión 1.1. Dos proveedores mencionados en el Anexo A de la versión 1.0 no están, ni han estado nunca, contratados, y han sido eliminados:

• Resend — nunca utilizado. No existe en ninguna parte del Servicio dependencia, punto de llamada ni configuración alguna al respecto. El correo transaccional se envía por SMTP a través de mail.tesserapp.eu. Sobrevive, como denominación heredada, una columna de base de datos llamada resend_message_id, que se rellena con el identificador de mensaje que devuelve el servidor SMTP.
• FontAwesome, Inc. — no recibe nada. cdn.woptima.com es la CDN de iconos propia del Encargado, bajo su propia licencia (véase A.3); los iconos de este sitio se compilan dentro de las páginas publicadas.

A.2 Otros destinatarios terceros

Servicios que reciben datos como efecto directo de una funcionalidad del producto, sin que esos datos pasen por los sistemas del Encargado. No son Subencargados, porque el Encargado no está en la vía de transmisión.

Destinatario	Qué recibe, y cuándo
Overpass — overpass-api.de, un servicio público del proyecto OpenStreetMap	En iOS, cuando el Interesado usa la función de comercios cercanos, el dispositivo envía a este endpoint público las coordenadas GPS del Interesado, con precisión completa y sin redondear, para buscar puntos de interés en un radio de 50 metros. No envía nada más: ningún identificador, ninguna tarjeta, ningún dato de la app. En Android el mismo cliente existe en la app, pero esa ruta de código no se alcanza actualmente
LocationIQ (Unwired Labs)	Cuando el Comercio escribe una dirección en el panel, el navegador envía a LocationIQ el texto escrito (y, en los formularios de establecimiento, el código de país). No envía la identidad del Comercio ni ningún dato de sesión. La dirección IP del navegador es implícita en cada llamada. La clave publicable está incluida en el paquete del panel y está restringida por dominio
Google LLC (Google Fonts)	Las tipografías del panel se cargan desde fonts.googleapis.com y fonts.gstatic.com en cada página: Google recibe, por tanto, la dirección IP y el tipo de navegador de quien abre el panel
Stripe, Inc. (Stripe.js)	La biblioteca de pagos se carga en cada página del panel, no solo en las páginas de facturación: Stripe recibe, por tanto, la dirección IP y los datos técnicos del navegador incluso cuando no hay ningún pago en curso. Los datos de tarjeta se introducen en campos alojados por Stripe y nunca pasan por los sistemas del Encargado
Apple Inc. / Google LLC (Iniciar sesión con Apple / con Google)	Solo si el Comercio elige iniciar sesión con Apple o Google, y solo para la operación de inicio de sesión
Apple Inc. / Google LLC (copia de seguridad del dispositivo, Wallets nativos)	En su calidad de proveedores de la cuenta del propio Interesado: la base de datos local de la app de consumidor, incluidos el nombre y el correo del titular en las tarjetas personales, se incorpora a la copia de seguridad de la cuenta iCloud o Google del Interesado

A.3 Infraestructura propia del Encargado

Componentes que pueden parecer servicios de terceros pero son instalaciones propias del Encargado, en sus propios dominios, sin compartir datos con el fabricante del software. No son Subencargados.

Componente	Software	Rol
glitchtip.radiobros.com	GlitchTip (autoalojado)	Recogida de los informes técnicos de error y de fallo de las apps. Configurado para no recabar datos identificativos del usuario, no rastrear sesiones y no adjuntar direcciones IP
helpdesk.radiobros.com	Zammad (autoalojado)	Sistema de asistencia para los tickets del Comercio. Recibe el correo de contacto y la denominación del Comercio, y el título, el cuerpo y los adjuntos de cada ticket
mail.tesserapp.eu	SMTP	Dominio de correo transaccional propio del Encargado. Quién opera el servidor subyacente se recoge en A.1
cdn.woptima.com	CDN estática bajo licencia propia del Encargado	Entrega de los iconos de interfaz, tanto al navegador como a los servidores del Encargado cuando estos componen un pase Wallet. Ningún dato personal. FontAwesome, Inc. no recibe nada
adminizer.radiobros.com	Authentik (autoalojado)	Proveedor de identidad que controla el acceso administrativo y máquina a máquina a los sistemas de producción
Recogida centralizada de registros de aplicación	Loki (autoalojado)	Diagnóstico y seguridad. Cuando está activa, los registros pueden contener direcciones IP y el contexto técnico de una petición
Índice de búsqueda del catálogo	Meilisearch (autoalojado, en el servidor de producción)	Búsqueda sobre los programas públicos. Contiene datos de los programas del Comercio, no datos de Interesados: ningún nombre, ningún correo, ninguna tarjeta

A.4 Puntos abiertos de este anexo

Los siguientes elementos no son determinables a partir de la configuración del Servicio y se declaran aquí como abiertos en lugar de suponerse. El Encargado los completará en la próxima versión y, si alguno de ellos supusiera añadir un Subencargado, dará el preaviso de 30 días exigido por el §6.2:

1. Quién opera el servidor de correo mail.tesserapp.eu, su lugar de tratamiento y su base de transferencia.
2. El lugar de tratamiento y la base de transferencia de LocationIQ (Unwired Labs).
3. El proveedor de alojamiento de los subdominios *.radiobros.com propios del Encargado, enumerados en A.3.
4. Si producción transmite a día de hoy las facturas electrónicas a través de un intermediario SdI externo.

La lista vigente se mantiene en este anexo. La versión 1.0 remitía al Comercio a una página "Privacidad → Subencargados" del panel; esa página no existe, y este anexo es la lista con valor de referencia.

Anexo B — Categorías de datos y plazos de conservación

La versión 1.0 de este anexo citaba plazos de conservación que ningún proceso aplicaba. Esta versión separa los dos casos, partiendo del principio de que es mejor describir cómo se comporta realmente el Servicio que publicar un plazo que nada aplica.

B.1 Plazos aplicados por un proceso automatizado

Categoría	Conservación	Base jurídica
Registros de entrega de webhooks enviados al Comercio (en las tarjetas personales, estas cargas contienen el nombre y el correo del titular)	30 días, suprimidos automáticamente por un barrido programado. Al suprimirse una tarjeta, el nombre, el correo y la referencia externa se enmascaran de inmediato en las cargas ya almacenadas; el registro técnico de la llamada (evento, resultado, fecha) permanece hasta que transcurren los 30 días	Interés legítimo en la fiabilidad de la integración
Ciclo de vida de la suscripción del Comercio	Una suscripción suspendida se cancela a los 60 días; 150 días después de la cancelación se envía un aviso de supresión; 180 días después de la cancelación la cuenta se anonimiza, lo que elimina el nombre, el correo y la referencia externa en cada una de las tarjetas de los clientes del Comercio	Art. 28, apdo. 3, letra g), del RGPD; limitación del plazo de conservación
Supresión solicitada por el Comercio desde el panel	Ejecutada 30 días después de la solicitud, con la misma anonimización. La ventana es un plazo de cortesía en el que la solicitud puede cancelarse	Instrucción del Responsable
Tarjeta individual suprimida por el Interesado o por el Comercio	Campos identificativos borrados de inmediato e irreversiblemente; sin ventana de recuperación. Los registros dependientes y, cuando ningún asiento contable conservado lo mencione, el propio registro de la tarjeta se eliminan en 30 días; véase B.2	Ejecución del contrato del programa de fidelidad
Intenciones de pago no consumadas para nuevos establecimientos	24 horas, y después suprimidas por un barrido diario	Ejecución del contrato (solo datos del Comercio)

B.2 Categorías sin caducidad automatizada

Para las siguientes categorías, ningún proceso programado suprime los datos. Se retiran a petición conforme al §7.3 y, en todo caso, mediante la anonimización de B.1.

Categoría	Qué ocurre realmente
Identificadores de tarjetas de fidelidad y registros de tarjetas en estado "suprimido"	El registro se conserva indefinidamente en estado "suprimido". Al suprimir una tarjeta se escribe un campo de fecha para una purga definitiva, pero nada lo lee: la purga definitiva es una operación administrativa manual. La "supresión en un plazo de 5 días" de la versión 1.0 queda retirada
Metadatos de transacción (sellos, premios, reversos, variaciones de saldo)	Conservados como registro de la actividad del Comercio y no suprimidos junto con una tarjeta individual. Las referencias al titular se retiran cuando se suprimen sus datos. Los "24 meses activos y después archivados con referencias pseudonimizadas" de la versión 1.0 quedan retirados: no existe ningún proceso de archivo de ese tipo
Eventos de auditoría y registros de acceso, incluidas dirección IP y user-agent	Conservados sin caducidad predefinida. No existe para ellos ningún proceso de conservación ni una tabla separada de registros de acceso. Constituyen el registro de lo que se hizo, incluida la prueba de que una supresión se llevó a cabo. El "puesta a cero de las direcciones IP al suprimirse definitivamente la tarjeta del Interesado" de la versión 1.0 queda retirado
Registros de correos salientes (dirección del destinatario y contenido de las variables de la plantilla)	Conservados sin caducidad automática: nada los suprime. Los "30 días desde la conclusión del procedimiento" de la versión 1.0 quedan retirados
Dirección de correo del Interesado facilitada voluntariamente al Encargado	Conservada el tiempo necesario para atender la solicitud y acreditar su resultado. Ninguna caducidad automática
Avisos del Comercio enviados a los titulares de un programa (título, texto, imagen, enlace, número de dispositivos alcanzados)	Conservados como registro de las comunicaciones del Comercio. Ninguna caducidad automática
Registros de instalación para las notificaciones (hash del token de instalación, token push, idioma, plataforma, versión de la app)	Conservados hasta que se solicite su retirada. Ninguna caducidad automática
Identificadores y tokens de actualización de los pases Apple / Google Wallet	Conservados hasta que el Interesado retire el pase del Wallet nativo, o la tarjeta sea suprimida
Coordenadas GPS	No se conservan en absoluto. Viajan en la única petición que las usa y no se almacenan ni por el Encargado ni en el dispositivo
Archivos de exportación RGPD solicitados por el Comercio	El ZIP se sube al almacenamiento de objetos y se entrega mediante un enlace firmado de 48 horas. El archivo permanece después en el bucket hasta su retirada manual: la regla de ciclo de vida de 7 días a la que alude el código no está configurada. Lo que limita la exposición es la caducidad del enlace firmado, no un proceso de supresión
Tickets de asistencia en el helpdesk del Encargado	Conservados sin caducidad automática
Informes técnicos de error y de fallo	Conservados en el sistema de diagnóstico propio del Encargado durante el tiempo necesario para corregir el defecto
Facturas de la suscripción del Comercio	Véase §9.3: 10 años conforme al art. 2220 del Código Civil italiano, que menciona expresamente las facturas; la normativa fiscal aplicable exige al menos 7, ya satisfechos por dicho plazo. Datos del Comercio, no de Interesados

Anexo C — Derechos de los Interesados y modalidades de ejercicio

El Comercio es el primer destinatario de las solicitudes de ejercicio de derechos RGPD de sus propios clientes. radioBros asiste al Comercio proporcionando:

• una herramienta de datos de cliente en el panel (Ajustes → Datos de cliente) que busca una tarjeta por número de serie y la suprime, retirando el nombre, la dirección de correo y la referencia externa del titular. Es la única acción por Interesado disponible en autoservicio a día de hoy; la exportación, la rectificación y la limitación las ejecuta el Encargado a petición, según se indica en el §7.3;
• la posibilidad de solicitar directamente a radioBros, en privacy@tesserapp.eu, el ejercicio de derechos, que se remitirá sin demora al Comercio o se ejecutará por instrucción de este;
• un registro de auditoría de las operaciones significativas, mantenido por el Encargado y puesto a disposición del Comercio a petición. La versión 1.0 lo describía como "accesible en cualquier momento por el Comercio"; a día de hoy no existe una vista del mismo en el panel, y el Encargado facilita el extracto pertinente a petición.

Plazos indicativos de respuesta (máximos conforme al art. 12 del RGPD): 30 días desde la solicitud, prorrogables otros 60 días en caso de complejidad, con información al Interesado.

Anexo D — Medidas técnicas y organizativas (art. 32 del RGPD)

Cada medida siguiente se marca como [implantada] cuando está implementada en el Servicio a día de hoy, o como [compromiso] cuando el Encargado se obliga a ella sin poder acreditarla todavía. La versión 1.0 presentaba como hechos varias medidas que los sistemas no implementaban; aquí se corrigen.

D.1 Confidencialidad

• [implantada] Cifrado en tránsito mediante TLS 1.2 o superior en todos los endpoints expuestos.
• [implantada] Cifrado en reposo con AES-256 (SSE) de los objetos almacenados en Cloudflare R2. Los secretos de aplicación — certificados de pases Wallet, secretos TOTP — se cifran con AES-256-GCM bajo una clave separada.
• [implantada] Hash argon2id, con parámetros conformes a las directrices de OWASP, para las contraseñas de las cuentas del Comercio, los PIN del personal y los códigos de recuperación. Ninguna contraseña se almacena nunca en claro.
• [implantada] Hash SHA-256 para los tokens aleatorios de alta entropía — cookies de sesión, tokens de instalación, tokens de invitación, claves de API. La versión 1.0 afirmaba que los tokens de autenticación se sometían a hash con argon2id; eso no es correcto, y la elección es deliberada: para un token aleatorio de 256 bits el espacio de búsqueda ya hace inviable la fuerza bruta, de modo que un hash deliberadamente lento no aporta nada y cuesta una búsqueda en cada petición.
• [implantada] Determinados tokens se almacenan tal como se emitieron, sin hash, porque deben reproducirse literalmente ante un tercero o cotejarse en una llamada entrante: los tokens de notificación push (APNs, FCM), el token de autenticación del pase Wallet y los tokens de reclamación de un solo uso del alta sin app. Su exposición está limitada por su alcance — un token push carece de sentido fuera de la app del Servicio; un token de autenticación de pase solo autoriza actualizaciones de ese único pase — y por los controles de acceso de D.2.
• [implantada] Segregación de entornos (producción, preproducción, desarrollo) con credenciales distintas y sin acceso a datos de producción desde entornos que no son de producción.

D.2 Integridad

• [implantada] Control de acceso basado en roles en la infraestructura de producción, con el acceso administrativo y máquina a máquina controlado por el proveedor de identidad propio del Encargado (A.3).
• [implantada] Registro de auditoría de cada operación administrativa y de cada operación significativa del lado del Comercio, escrito en una tabla específica a la que la aplicación solo añade.
• [implantada] Migraciones de esquema de base de datos versionadas, seguidas por un diario de hashes que detecta la modificación de una migración.
• [implantada] Limitación de tasa en los endpoints de autenticación y en las API públicas.

D.3 Disponibilidad y resiliencia

La versión 1.0 describía "copias de seguridad automáticas diarias de la base de datos con Point-In-Time Recovery (PITR) mediante WAL streaming (pgBackRest)". Nada de eso está implementado. Lo que el Servicio hace realmente:

• [implantada] Volcados lógicos horarios de la base de datos (pg_dump, formato custom comprimido), realizados por un contenedor específico que se conecta directamente a PostgreSQL.
• [implantada] Verificación en tres pasos de cada volcado antes de publicarlo: el comando de volcado debe finalizar con éxito; el fichero debe superar un tamaño mínimo, lo que detecta el modo de fallo "conectado, autenticado, esquema vacío volcado"; y el índice del volcado debe contener una tabla centinela, lo que prueba que dentro hay datos reales. Solo se publica un volcado que supere los tres controles, y solo un éxito verificado puede desencadenar la eliminación de volcados más antiguos — de modo que una serie de fallos no puede erosionar nunca las copias buenas que quedan.
• [implantada] Retención plana de los 168 volcados más recientes, guardados en el sistema de archivos del servidor de producción. Al intervalo horario, eso equivale aproximadamente a una semana de histórico. No existe promoción por niveles.
• No implementado, dicho sin rodeos: los volcados no se cifran por el propio proceso de copia; no existe archivado de WAL y, por tanto, no hay recuperación a un instante concreto — el punto de recuperación es el intervalo de copia; y los volcados no se replican fuera del servidor. Un fichero de estado legible por máquina recoge el resultado de la última ejecución.
• [compromiso] Cifrado de los volcados en reposo y copia fuera del servidor.
• [compromiso] Simulacros de restauración documentados, al menos anuales.
• [compromiso] Monitorización de la infraestructura con alarmas sobre anomalías de seguridad y disponibilidad.
• [implantada] Limitación de tasa en los endpoints públicos. La afirmación de la versión 1.0 sobre un "anti-DDoS perimetral vía Cloudflare" queda retirada: Cloudflare se usa para el almacenamiento de objetos y la entrega de recursos estáticos, y no se sitúa delante de la API.

D.4 Procedimientos de verificación

• [compromiso] Prueba de penetración externa anual.
• [compromiso] Revisión interna semestral de las configuraciones de seguridad.
• [compromiso] Gestión de vulnerabilidades con objetivos de remediación definidos (crítica: 7 días; alta: 30 días; media: 90 días).

D.5 Continuidad del tratamiento

• [compromiso] Procedimientos documentados de recuperación ante desastres y de gestión de incidentes.
• [implantada] Sustituibilidad de los Subencargados de infraestructura en plazos razonables, al desplegarse el Servicio a partir de una definición de contenedor versionada y no de servicios gestionados propios de un proveedor.

D.6 Gestión de incidentes

• [implantada] Un único punto de contacto designado para la gestión de Violaciones de Datos Personales, localizable en privacy@tesserapp.eu.
• [compromiso] Un procedimiento interno escrito de gestión de violaciones con cadena de notificación predefinida, para garantizar el cumplimiento del plazo de 72 horas al que se refiere el art. 8 del presente DPA.

---

Contactos

• Encargado del Tratamiento: radioBros di Alberto Miconi, Via Ridolfino Venuti 30, 00162 Roma (Italia), número de IVA italiano (Partita IVA) IT15127451001.
• Correo electrónico para cualquier asunto relativo al presente DPA: privacy@tesserapp.eu.
• Autoridad de control competente: la Autoridad Italiana de Protección de Datos (Garante — gpdp.it) es la autoridad de control del establecimiento de radioBros. Los Comercios establecidos en otro Estado miembro de la UE pueden dirigirse también a la autoridad de control de su propio país de establecimiento.

---

Versión 1.1 — adoptada el 8 de septiembre de 2026, en sustitución de la versión 1.0 del 30 de mayo de 2026. Las versiones históricas, cuando estén disponibles, se archivan en formato PDF en las URL https://tesserapp.eu/legal/dpa/v{version}.pdf.