Acordo de Tratamento de Dados

Versão 1.1 · Última atualização: 8 de setembro de 2026 · Em vigor desde 8 de setembro de 2026

O presente Acordo de Tratamento de Dados (o "DPA") é celebrado ao abrigo do artigo 28 do Regulamento (UE) 2016/679 ("RGPD") e do artigo 28 do Decreto Legislativo italiano 196/2003, alterado pelo Decreto Legislativo 101/2018 (o Código italiano de Proteção de Dados Pessoais), entre a Loja, na qualidade de Responsável pelo Tratamento, e a radioBros, na qualidade de Subcontratante, e regula o tratamento dos dados pessoais dos clientes da Loja no âmbito do serviço TesserApp.

A versão 1.1 alinha o presente DPA com a versão 1.2 da Política de Privacidade, após uma revisão integral do código-fonte do Serviço. Estende a todos os tipos de cartão pessoal e à inscrição web sem aplicação as informações que anteriormente estavam redigidas apenas para os programas privados; substitui a lista de subcontratantes ulteriores, o quadro de conservação e a descrição das medidas de segurança pelo que os sistemas efetivamente fazem; e elimina os compromissos que nenhum processo automatizado aplicava. Onde o presente DPA e a Política de Privacidade descrevem o mesmo tratamento, pretende-se que digam o mesmo.

A versão em língua italiana do presente DPA é a versão oficial e prevalece sobre as traduções em caso de divergência.

1. Partes

1.1 Responsável pelo Tratamento: a pessoa singular ou coletiva que se regista na plataforma TesserApp Shop e subscreve o Serviço (doravante a "Loja"). Os dados de identificação da Loja são os introduzidos no momento do registo e alteráveis a partir do painel.

1.2 Subcontratante: radioBros di Alberto Miconi, com sede em Via Ridolfino Venuti 30, 00162 Roma (Itália), número de IVA italiano (Partita IVA) IT15127451001, correio eletrónico de contacto privacy@tesserapp.eu (doravante "radioBros").

As Partes reconhecem mutuamente as qualidades acima descritas, sem prejuízo do papel autónomo da radioBros como Responsável pelo Tratamento relativamente aos tratamentos próprios efetuados na execução da subscrição (faturação, conta da Loja, registos de segurança dos seus próprios sistemas), os quais são regidos pela Política de Privacidade e pelos Termos de Serviço.

2. Definições

Aplicam-se as definições do artigo 4 do RGPD. Adicionalmente:

• "Dados Pessoais": qualquer informação relativa a uma pessoa singular identificada ou identificável na aceção do art. 4, n.º 1, do RGPD, tratada pelo Subcontratante em nome do Responsável pelo Tratamento no âmbito do Serviço.
• "Titular dos Dados": o cliente da Loja que é titular de um cartão de fidelização de um dos programas da Loja, quer o conserve na aplicação móvel TesserApp, quer apenas no Apple Wallet ou no Google Wallet.
• "Serviço": a plataforma web, as aplicações móveis e os componentes de infraestrutura que a radioBros disponibiliza à Loja para a operação dos seus programas de fidelização.
• "Cartão pessoal": um cartão que, por construção, é emitido a favor de uma única pessoa identificada. Existem quatro tipos: privado (cartão de selos pessoal), desconto, acesso e pré-pago. Nos quatro casos, o nome e o endereço de correio eletrónico do titular são obrigatórios.
• "Cartão anónimo": um cartão padrão (de selos) ou um cartão de pontos, que o Titular dos Dados ativa por si a partir da aplicação ou do catálogo e que não contém nome nem endereço de correio eletrónico.
• "Subcontratante Ulterior": qualquer terceiro contratado pelo Subcontratante para tratar Dados Pessoais, ao abrigo do art. 28, n.º 4, do RGPD. A lista consta do Anexo A, secção A.1.
• "Violação de Dados Pessoais": conforme definida no art. 4, n.º 12, do RGPD.

3. Objeto, duração, natureza e finalidades do tratamento

3.1 A Loja, na qualidade de Responsável pelo Tratamento, encarrega a radioBros, na qualidade de Subcontratante, de tratar os Dados Pessoais dos Titulares dos Dados para as finalidades necessárias à prestação do Serviço e estabelecidas no presente DPA.

3.2 Objeto: a operação técnica do programa de fidelização da Loja, incluindo a ativação dos cartões de cliente, o registo das transações (selos atribuídos, prémios resgatados, anulações, variações de um saldo de pontos ou de crédito), a sincronização dos cartões com o Apple Wallet e o Google Wallet, o envio de notificações push relacionadas com o programa de fidelização, a entrega das comunicações que a Loja redige para os titulares de um dos seus programas, a apresentação do programa no catálogo da aplicação do consumidor (nos casos em que a Loja tenha optado pela visibilidade pública), a disponibilização de funcionalidades de descoberta baseadas na localização e, adicionalmente:

• para os cartões pessoais (privado, desconto, acesso, pré-pago): a emissão de um cartão a favor de um único titular identificado, o envio de um convite de instalação por correio eletrónico e a associação do cartão à conta de dispositivo do titular;
• para a inscrição web sem aplicação (apenas cartões padrão): a criação de um cartão e de um passe Wallet nativo a partir de uma página web, sem que o Titular dos Dados instale a aplicação do consumidor, juntamente com o nome, o endereço de correio eletrónico e o marcador de consentimento de marketing facultativos que o formulário de inscrição possa recolher.

3.3 Natureza do tratamento: tratamento automatizado realizado na infraestrutura informática do Subcontratante e dos seus Subcontratantes Ulteriores autorizados.

3.4 Finalidades: execução do contrato entre a Loja e os seus próprios clientes relativo ao programa de fidelização; cumprimento das obrigações legais da Loja na qualidade de Responsável pelo Tratamento; segurança dos sistemas de informação e prevenção de fraude nos selos, nos prémios e nos saldos; entrega de cartões pessoais às pessoas concretas designadas pelo Responsável pelo Tratamento e restrição de cada um desses cartões à conta de dispositivo do titular; e, na inscrição web sem aplicação, criação de um cartão para um Titular dos Dados que não instalou a aplicação.

3.5 Duração: o presente DPA vigora durante toda a duração da subscrição da Loja ao Serviço. As obrigações dos artigos 9 (Devolução e eliminação) e 13 (Confidencialidade) subsistem após a cessação.

4. Categorias de Titulares dos Dados e de Dados Pessoais

4.1 Categorias de Titulares dos Dados: clientes da Loja titulares de um cartão de fidelização de um dos programas da Loja, seja na aplicação do consumidor TesserApp, seja apenas num Wallet nativo.

4.2 Categorias de Dados Pessoais tratados (Anexo B):

• identificadores de instalação anónimos (tokens aleatórios de 256 bits, não ligados à identidade de uma pessoa, conservados pelo Subcontratante apenas sob a forma de resumo criptográfico);
• identificadores dos cartões de fidelização (UUID opacos) e números de série dos cartões;
• metadados de transação (atribuições de selos, resgates de prémios, anulações, variações do saldo de pontos ou de crédito; data, hora e estabelecimento da Loja em que a operação ocorreu; o montante ou o número de selos solicitados; e, numa anulação, o motivo em texto livre escrito pela Loja);
• identificadores de passe Apple Wallet / Google Wallet, tokens de atualização do passe, identificador que o sistema operativo atribui à biblioteca de passes do dispositivo e os tokens push associados;
• tokens de notificação push emitidos pela Apple (APNs) ou pela Google (FCM), registados para a instalação da aplicação em si;
• idioma de sistema do dispositivo, plataforma (iOS ou Android) e versão da aplicação;
• endereços IP e cadeias user-agent, registados nos registos de auditoria e de acesso para fins de segurança. Contrariamente ao que afirmava a versão 1.0 do presente DPA, não são tratados de forma transitória: são conservados conforme descrito no Anexo B, secção B.2;
• coordenadas GPS, exclusivamente quando o Titular dos Dados tenha ativado a funcionalidade de descoberta de lojas próximas ou consulte o catálogo ordenado por distância, e apenas durante essa solicitação. As coordenadas não são conservadas, nem pelo Subcontratante nem no dispositivo;
• endereço de correio eletrónico do Titular dos Dados, quando por ele voluntariamente fornecido ao Subcontratante (pedidos de exercício de direitos RGPD, contactos com o suporte);
• relatórios técnicos de erro e de falha, que incluem o modelo do dispositivo, a versão do sistema operativo e a versão da aplicação, e podem conter o identificador técnico de um cartão ou de um programa envolvidos no erro. Estão configurados para não recolher dados identificativos do utilizador e para não anexar o endereço IP.

4.2 bis — Cartões pessoais (privado, desconto, acesso, pré-pago): para os quatro tipos de cartão pessoal, e não apenas para os programas privados:

• o nome e o endereço de correio eletrónico do titular, ambos obrigatórios, fornecidos pelo Responsável pelo Tratamento ao criar o cartão e tratados para emitir o cartão, enviar um convite de instalação por correio eletrónico, imprimir os dados do titular no cartão e no passe Wallet e mostrá-los ao pessoal da Loja quando o cartão é lido;
• uma referência externa (external_ref) — o identificador que o Responsável pelo Tratamento já utiliza para essa pessoa singular nos seus próprios sistemas, por exemplo um número de colaborador ou de associado — quando o Responsável pelo Tratamento a defina através da API de integração ou do conector MCP;
• uma referência pseudonimizada de associação à conta de dispositivo (um identificador opaco derivado da conta iCloud ou Google do titular, não do seu nome nem do seu correio eletrónico), tratada unicamente para garantir que o cartão permaneça na conta do titular.

O Responsável pelo Tratamento garante dispor de um fundamento jurídico e, quando exigido, do consentimento do Titular dos Dados para fornecer estes dados; o Subcontratante trata-os exclusivamente com base nas instruções documentadas do Responsável pelo Tratamento.

4.2 ter — Inscrição web sem aplicação (apenas cartões padrão): quando um Titular dos Dados obtém um cartão padrão inscrevendo-se a partir de uma página web e adicionando-o diretamente ao Apple Wallet ou ao Google Wallet, sem instalar a aplicação do consumidor, o formulário de inscrição pode recolher:

• um nome facultativo e um endereço de correio eletrónico facultativo. Se ficarem em branco, o cartão é criado de forma anónima, exatamente como um cartão ativado na aplicação; se forem preenchidos, são associados ao cartão e tratados em nome do Responsável pelo Tratamento nos termos do §4.2 bis;
• um marcador de consentimento de marketing, composto pela data e pela origem da recolha. Atualmente é apenas um campo armazenado: nenhuma mensagem promocional é enviada com base nele, nem pelo Subcontratante nem pelo Responsável pelo Tratamento através dos sistemas do Subcontratante.

A inscrição web sem aplicação está disponível apenas para os programas padrão (de selos). A página de inscrição que a radioBros publica ela própria não solicita nenhum destes campos; continuam disponíveis para um Responsável pelo Tratamento que integre a funcionalidade nas suas próprias ferramentas.

4.3 Dados NÃO tratados: endereço postal do Titular dos Dados; número de telefone do Titular dos Dados; dados de pagamento do Titular dos Dados (o Serviço não trata pagamentos do cliente à Loja); histórico de navegação; dados biométricos; identificadores publicitários; categorias especiais de dados ao abrigo do art. 9 do RGPD; dados relativos a condenações penais ao abrigo do art. 10 do RGPD; dados de menores de 16 anos (o Serviço não se dirige a essa faixa de idade). O Subcontratante não utiliza qualquer SDK publicitário, de atribuição ou de análise e não constrói qualquer perfil comportamental.

O tratamento de um nome e de um endereço de correio eletrónico depende da via pela qual o cartão foi obtido, e não apenas do tipo de cartão. A versão 1.0 do presente DPA afirmava que "em todos os programas padrão/públicos, o nome e o correio eletrónico continuam a não ser tratados". Isso já não é exato, e a posição correta é a seguinte:

Como o cartão foi obtido	Nome e correio eletrónico
Cartão padrão ou de pontos ativado pelo próprio Titular dos Dados na aplicação (código QR ou catálogo)	Não tratados. O cartão é anónimo e permanece anónimo
Cartão pessoal (privado, desconto, acesso, pré-pago) criado pelo Responsável pelo Tratamento	Sempre tratados — ambos são obrigatórios (§4.2 bis)
Cartão padrão obtido por inscrição web sem aplicação	Facultativos — tratados apenas se o formulário os recolher e o Titular dos Dados os preencher (§4.2 ter)
Cartão criado pelo Responsável pelo Tratamento através da API de integração ou do conector MCP	Nome e correio eletrónico como acima, mais a referência externa do Responsável pelo Tratamento (§4.2 bis)

5. Obrigações do Subcontratante

O Subcontratante compromete-se a:

5.1 tratar os Dados Pessoais apenas com base em instruções documentadas do Responsável pelo Tratamento, incluindo no que respeita a transferências de Dados Pessoais para um país terceiro ou uma organização internacional, salvo se for obrigado a fazê-lo pelo direito da União ou de um Estado-Membro a que o Subcontratante esteja sujeito; nesse caso, o Subcontratante informa o Responsável pelo Tratamento dessa exigência legal antes do tratamento, salvo se esse direito proibir tal informação por motivos importantes de interesse público;

5.2 garantir que as pessoas autorizadas a tratar os Dados Pessoais assumiram um compromisso de confidencialidade ou estão sujeitas a uma obrigação legal adequada de confidencialidade;

5.3 adotar todas as medidas exigidas ao abrigo do art. 32 do RGPD, conforme descritas no Anexo D do presente DPA;

5.4 respeitar as condições referidas nos n.os 2 e 4 do art. 28 do RGPD para a contratação de Subcontratantes Ulteriores, conforme especificado no art. 6 do presente DPA;

5.5 tendo em conta a natureza do tratamento, assistir o Responsável pelo Tratamento através de medidas técnicas e organizativas adequadas, na medida do possível, no cumprimento da obrigação do Responsável pelo Tratamento de responder aos pedidos de exercício dos direitos do Titular dos Dados previstos nos arts. 15-22 do RGPD;

5.6 assistir o Responsável pelo Tratamento a assegurar o cumprimento das obrigações previstas nos arts. 32-36 do RGPD, tendo em conta a natureza do tratamento e as informações à disposição do Subcontratante;

5.7 por opção do Responsável pelo Tratamento, eliminar ou devolver todos os Dados Pessoais após o termo da prestação dos serviços relativos ao tratamento, e eliminar as cópias existentes, salvo se o direito da União ou de um Estado-Membro exigir a conservação dos dados;

5.8 disponibilizar ao Responsável pelo Tratamento todas as informações necessárias para demonstrar o cumprimento das obrigações estabelecidas no art. 28 do RGPD e permitir e contribuir para auditorias, incluindo inspeções, realizadas pelo Responsável pelo Tratamento ou por outro auditor por este mandatado;

5.9 informar imediatamente o Responsável pelo Tratamento se, na sua opinião, uma instrução violar o RGPD ou outras disposições de proteção de dados da União ou de um Estado-Membro.

6. Subcontratantes Ulteriores

6.1 A Loja concede pelo presente ao Subcontratante autorização geral para contratar os Subcontratantes Ulteriores enumerados no Anexo A, secção A.1 do presente DPA.

6.2 O Subcontratante informará a Loja de quaisquer alterações previstas quanto ao aditamento ou à substituição de outros Subcontratantes Ulteriores com um pré-aviso de, pelo menos, 30 dias, dando assim à Loja a oportunidade de se opor a tais alterações.

6.3 Em caso de oposição fundamentada da Loja, o Subcontratante avaliará soluções técnicas alternativas. Quando não for possível evitar o novo Subcontratante Ulterior, a Loja poderá cessar a subscrição sem penalização, com efeitos a partir da data em que o novo Subcontratante Ulterior entre em funcionamento.

6.4 O Subcontratante celebra com cada Subcontratante Ulterior um contrato escrito que contém obrigações de proteção de dados equivalentes às estabelecidas no presente DPA, em particular quanto a medidas técnicas e organizativas adequadas, confidencialidade, assistência ao Responsável pelo Tratamento e cooperação com a autoridade de controlo.

6.5 O Subcontratante continua a responder perante a Loja pela atuação do Subcontratante Ulterior nos limites previstos no art. 28, n.º 4, do RGPD.

6.6 O Anexo A enumera ainda, separadamente dos Subcontratantes Ulteriores, os outros destinatários terceiros que recebem dados como efeito direto de uma funcionalidade do produto sem que esses dados passem pelos sistemas do Subcontratante (secção A.2), bem como os componentes que são instalações próprias do Subcontratante nos seus próprios domínios e, por isso, não constituem Subcontratantes Ulteriores (secção A.3). A distinção reflete a utilizada no §4 da Política de Privacidade.

7. Direitos do Titular dos Dados

7.1 Tendo em conta a natureza do tratamento, o Subcontratante assiste o Responsável pelo Tratamento através de medidas técnicas e organizativas adequadas, na medida do possível, para o cumprimento da obrigação do Responsável pelo Tratamento de responder aos pedidos de exercício dos direitos dos Titulares dos Dados ao abrigo do capítulo III do RGPD (arts. 12-22), e em particular:

• direito de acesso (art. 15);
• direito de retificação (art. 16);
• direito ao apagamento (art. 17), operacionalizado através do fluxo descrito no artigo 9 seguinte, cujo primeiro passo é o apagamento imediato e irreversível dos dados identificativos do titular;
• direito à limitação do tratamento (art. 18);
• direito à portabilidade dos dados (art. 20);
• direito de oposição (art. 21);
• direito de não ficar sujeito a uma decisão tomada exclusivamente com base no tratamento automatizado (art. 22): o Serviço não realiza definição de perfis automatizada com efeitos jurídicos sobre o Titular dos Dados.

7.2 Os pedidos recebidos diretamente pelo Subcontratante são encaminhados sem demora para o Responsável pelo Tratamento, salvo se o Subcontratante estiver autorizado por escrito pelo Responsável pelo Tratamento a responder diretamente.

7.3 O que o painel oferece efetivamente hoje. A versão 1.0 do presente DPA afirmava que o painel disponibilizava ferramentas para exportar, anonimizar e suspender os dados de um Titular dos Dados individual. Dessas ferramentas existe apenas uma. A posição exata é a seguinte:

Direito	Como é exercido hoje
Apagamento de um Titular dos Dados individual	Em autosserviço no painel. Em Configurações → Dados de cliente, o Responsável pelo Tratamento pode procurar um cartão pelo seu número de série e eliminá-lo. A eliminação retira do cartão o nome, o correio eletrónico e a referência externa do titular
Exportação dos dados de um Titular dos Dados individual	A pedido, executada pelo Subcontratante. Não existe no painel uma exportação por Titular dos Dados. A funcionalidade de exportação de dados do painel produz o arquivo da conta do próprio Responsável pelo Tratamento, não o processo de um Titular dos Dados individual. Basta escrever para privacy@tesserapp.eu e o Subcontratante prepara o extrato
Retificação dos dados de um Titular dos Dados individual	A pedido, executada pelo Subcontratante, ou pelo Responsável pelo Tratamento reemitindo o cartão
Limitação / suspensão de um Titular dos Dados individual	A pedido, executada pelo Subcontratante. Não existe no painel um comando de suspensão por Titular dos Dados

7.4 O Subcontratante compromete-se a estender as ferramentas de autosserviço à exportação e à limitação por Titular dos Dados. Enquanto não existirem, o presente DPA não as apresenta como disponíveis, e os pedidos referidos no §7.3 são tratados pelo Subcontratante nos prazos do Anexo C.

8. Notificação de Violação de Dados Pessoais

8.1 Em caso de Violação de Dados Pessoais de que o Subcontratante tome conhecimento, o Subcontratante notifica o evento ao Responsável pelo Tratamento sem demora injustificada e, em qualquer caso, no prazo de 72 horas a contar do momento em que dela tomou conhecimento, fornecendo, na medida do possível, as informações referidas no art. 33, n.º 3, do RGPD e, em particular:

• a natureza da violação, as categorias e o número aproximado de Titulares dos Dados afetados;
• as categorias e o número aproximado de registos de dados pessoais em causa;
• os dados de contacto do ponto de contacto para o incidente;
• as consequências prováveis da violação;
• as medidas adotadas ou propostas para lhe dar resposta e atenuar os seus eventuais efeitos negativos.

8.2 Quando, e na medida em que, não seja possível fornecer as informações simultaneamente, estas podem ser fornecidas por fases, sem demora injustificada adicional.

8.3 Fica entendido que compete ao Responsável pelo Tratamento, ao abrigo dos arts. 33 e 34 do RGPD, decidir se notifica a violação à autoridade de controlo e se a comunica aos Titulares dos Dados.

9. Devolução e eliminação dos Dados Pessoais na cessação

9.1 Exportação. Na cessação da subscrição, e em todo o caso no prazo de 30 dias a contar da cessação, a Loja pode solicitar ao Subcontratante a exportação integral dos Dados Pessoais num formato estruturado, de uso corrente e de leitura automática. A exportação é produzida como arquivo ZIP com ficheiros JSON, carregada no armazenamento de objetos do Subcontratante e entregue à Loja através de uma ligação assinada válida por 48 horas. O material identificativo do lado do cliente que não cabe à Loja receber (resumos dos tokens de instalação, endereços IP) é anonimizado no interior do arquivo.

9.2 Eliminação. Decorrido o prazo anterior sem pedido de exportação, ou após a conclusão da exportação, o Subcontratante procede à eliminação dos Dados Pessoais. O ciclo de vida efetivamente aplicado pelo Serviço é o seguinte, e retira-se a afirmação da versão 1.0 segundo a qual os dados seriam "eliminados definitivamente dos sistemas de produção no prazo de 5 dias":

• uma subscrição suspensa é cancelada automaticamente após 60 dias;
• 150 dias após o cancelamento, é enviado à Loja um aviso de que os seus dados vão ser eliminados;
• 180 dias após o cancelamento, a conta é anonimizada automaticamente. A anonimização remove o nome e o correio eletrónico de acesso, a palavra-passe, o segundo fator, as passkeys, as identidades sociais, os registos de pessoal, os dispositivos emparelhados, as chaves de API e o nome, o endereço de correio eletrónico e a referência externa em cada um dos cartões dos clientes da Loja;
• quando a Loja solicita a eliminação a partir do painel, a mesma anonimização é executada 30 dias após o pedido, constituindo esse prazo uma janela de tolerância na qual o pedido pode ser anulado;
• num cartão individual eliminado os campos identificativos do titular são apagados no próprio momento do pedido, juntamente com a credencial de instalação que ligava o cartão ao dispositivo do titular; a partir desse momento a eliminação é irreversível e não existe qualquer janela de recuperação. No prazo de 30 dias uma rotina noturna programada remove os registos dependentes e o próprio registo do cartão, salvo se um lançamento contabilístico conservado o referir: o registo é então purgado no local e resta um identificador nu que não identifica ninguém, removido em qualquer caso com a anonimização acima descrita.

9.3 Dados excluídos da eliminação. Estão excluídos da eliminação, pelo tempo estritamente necessário, os Dados Pessoais cuja conservação seja imposta por obrigações legais que vinculam a radioBros. Isto diz respeito às faturas próprias do Subcontratante emitidas à Loja, e não a dados de Titulares dos Dados, e o prazo de conservação é de 10 anos:

• O art. 2220 do Código Civil italiano obriga a conservar durante 10 anos as faturas — as recebidas e as cópias das emitidas — e os registos contabilísticos que a elas se referem. É esta a obrigação efetivamente aplicada e é o prazo indicado na Política de Privacidade e nos Termos de Serviço.
• A legislação fiscal italiana aplicável (DPR 633/1972; D.Lgs. 127/2015) fixa um mínimo mais curto, de 7 anos, já satisfeito pelo prazo acima.

Tais dados são mantidos em custódia separada, com acesso restrito e auditado, e não são objeto de qualquer outro tratamento além do cumprimento da obrigação.

9.4 A pedido escrito da Loja, o Subcontratante emite uma declaração formal de eliminação concluída.

10. Transferências internacionais de dados

10.1 O Subcontratante trata os Dados Pessoais nos seus próprios sistemas exclusivamente em infraestrutura localizada no Espaço Económico Europeu. Os sistemas de produção estão alojados na Alemanha.

10.2 Alguns Subcontratantes Ulteriores enumerados no Anexo A podem ter sede ou operações nos Estados Unidos (em particular a Stripe, a Apple, a Google e a Cloudflare). As transferências de Dados Pessoais para tais partes são efetuadas com base nas Cláusulas Contratuais-Tipo adotadas pela Comissão Europeia através da Decisão 2021/914/UE, complementadas por medidas adicionais quando necessário à luz do acórdão do TJUE C-311/18 (Schrems II).

10.2 bis — Transferências que não passam pelos sistemas do Subcontratante. Alguns destinatários enumerados no Anexo A, secção A.2, são contactados diretamente pelo navegador da Loja ou pelo dispositivo do Titular dos Dados, como efeito direto de uma funcionalidade do produto. Para estes, o local do tratamento é o do próprio destinatário e o Subcontratante não está na via de transmissão:

• Overpass (overpass-api.de, um serviço público do projeto OpenStreetMap): no iOS, o dispositivo do Titular dos Dados envia-lhe as coordenadas GPS quando a funcionalidade de lojas próximas é utilizada;
• LocationIQ (Unwired Labs): o navegador da Loja envia-lhe o texto do endereço escrito no painel;
• Google Fonts e Stripe.js: carregados pelo painel em cada página, pelo que o endereço IP e o tipo de navegador de quem abre o painel chegam à Google e à Stripe, respetivamente.

10.3 Não são efetuadas transferências para países terceiros fora do quadro das Cláusulas Contratuais-Tipo ou de uma decisão de adequação da Comissão, salvo as chamadas diretas a partir do navegador e do dispositivo referidas no §10.2 bis, cuja base de transferência é indicada no Anexo A.

11. Medidas técnicas e organizativas

As medidas técnicas e organizativas adotadas pelo Subcontratante ao abrigo do art. 32 do RGPD estão descritas no Anexo D do presente DPA, que dele faz parte integrante. O Anexo D distingue as medidas já implementadas daquelas que o Subcontratante se compromete a implementar. Tais medidas estão sujeitas a atualização periódica para refletir o estado da técnica; nenhuma atualização pode resultar numa redução do nível de segurança garantido.

12. Auditoria

12.1 O Subcontratante disponibiliza ao Responsável pelo Tratamento, a pedido escrito, as informações necessárias para demonstrar o cumprimento das obrigações previstas no art. 28 do RGPD e no presente DPA.

12.2 O Responsável pelo Tratamento pode solicitar, uma vez por ano civil, a realização de uma auditoria, a efetuar com um pré-aviso escrito de, no mínimo, 30 dias, em horário de expediente, nas instalações do Subcontratante, de forma a não interferir com a continuidade operacional do Serviço e no respeito pelas medidas de segurança em vigor.

12.3 Os custos diretos da auditoria são suportados pelo Responsável pelo Tratamento, salvo se a auditoria revelar incumprimentos significativos do presente DPA imputáveis ao Subcontratante, caso em que os custos são suportados pelo Subcontratante.

12.4 O Subcontratante não detém atualmente qualquer certificação de segurança emitida por terceiros (nenhum relatório SOC 2, nenhum certificado ISO 27001). Caso venha a obter uma, poderá oferecer, em substituição da auditoria no local, o correspondente relatório de auditor independente, acompanhado de documentação equivalente.

13. Confidencialidade

13.1 As Partes comprometem-se a tratar como estritamente confidenciais todas as informações obtidas na execução do presente DPA, exceto as informações de domínio público ou cuja divulgação seja exigida por lei ou por ordem da autoridade.

13.2 A obrigação de confidencialidade estende-se aos trabalhadores, colaboradores e Subcontratantes Ulteriores das Partes e subsiste após a cessação do presente DPA.

14. Responsabilidade e indemnização

14.1 Cada Parte é responsável pelos danos causados pelo seu tratamento que viole o RGPD, nos limites e nos termos previstos no art. 82 do RGPD.

14.2 Nas relações internas entre as Partes, a responsabilidade da radioBros perante a Loja pelo tratamento dos Dados Pessoais rege-se pela cláusula de limitação de responsabilidade constante dos Termos de Serviço, salvo em casos de dolo ou de negligência grosseira e sem prejuízo da responsabilidade perante o Titular dos Dados ao abrigo do RGPD.

14.3 A Loja garante e mantém a radioBros indemne de qualquer reclamação resultante do incumprimento, por parte da Loja, das suas próprias obrigações como Responsável pelo Tratamento ao abrigo do RGPD (em particular: informação adequada aos Titulares dos Dados nos termos dos arts. 13-14 do RGPD; fundamento jurídico adequado para o tratamento; correção das instruções dadas ao Subcontratante).

15. Duração, alterações e disposições finais

15.1 Duração. O presente DPA é eficaz a partir da data de aceitação pela Loja no momento do registo (através de uma caixa de seleção dedicada) e durante toda a duração da subscrição do Serviço. As obrigações de devolução/eliminação (art. 9) e de confidencialidade (art. 13) subsistem após a cessação.

15.2 Alterações. As alterações substanciais do presente DPA serão comunicadas à Loja com uma antecedência mínima de 30 dias, por correio eletrónico para o endereço registado na conta e através de um banner dedicado no painel. Será exigido à Loja que volte a aceitar a nova versão no início de sessão seguinte. A não aceitação confere o direito de cessar a subscrição sem penalização.

15.2 bis — Entrada em vigor da versão 1.1. A versão 1.1 do presente DPA entra em vigor na data de publicação indicada no início deste documento, sem aguardar o pré-aviso de 30 dias previsto no §15.2. A razão está na natureza desta revisão: a versão 1.1 não impõe ao Responsável pelo tratamento obrigações novas nem reduz as garantias dos Titulares dos dados; corrige afirmações inexatas da versão 1.0, amplia as informações prestadas e retira compromissos que nenhum processo do Serviço chegou a executar — entre eles o apagamento «no prazo de cinco dias» referido no §9.2, que os sistemas não realizavam. Em vários pontos o texto resultante é menos favorável ao Subcontratante e mais favorável a quem o lê, porque deixa de sobrevalorizar a confidencialidade oferecida e de prometer apagamentos que não ocorriam. Diferir por 30 dias uma correção desta natureza significaria manter em vigor por mais 30 dias um texto que se sabe inexato: o pré-aviso do §15.2 existe para proteger o Comerciante de alterações que modificam obrigações, não para atrasar a descrição verídica de um tratamento já em curso. Este raciocínio não se estende ao §6.2, que a presente disposição deixa inteiramente intacto. O novo Anexo A enumera destinatários que a versão 1.0 não indicava: a maioria já participava no tratamento e é agora simplesmente reduzida a escrito. Pelo menos um, porém — Unwired Labs (LocationIQ), de que o Subcontratante se serve desde junho de 2026 para o preenchimento automático de endereços no painel do Comerciante — foi efetivamente acrescentado após a versão 1.0, e a situação dos demais pontos indicados no Anexo A, secção A.4 não está ainda determinada. Para esses, o §6.2 aplica-se integralmente: o pré-aviso de 30 dias e o direito de oposição do Comerciante são dados como esse artigo exige, e a secção A.4 disso dá conta.

O §15.2 mantém-se intacto. O §15.2 conserva plena eficácia para qualquer alteração futura do presente DPA. O §15.2 bis é uma derrogação transitória única, circunscrita à entrada em vigor da versão 1.1: não reduz, não reinterpreta nem suspende o pré-aviso de 30 dias, a exigência de nova aceitação ou a faculdade de resolução sem penalização que o §15.2 reconhece ao Comerciante, e o mesmo vale para o §6.2 quanto ao acrescento efetivo de um novo Subcontratante ulterior. Qualquer alteração posterior que modifique as obrigações das Partes segue integralmente o §15.2.

O pré-aviso dado com esta publicação. Com a entrada em vigor da versão 1.1 são dados: a publicação do texto nesta página, com a data e o número de versão no início; uma comunicação por correio eletrónico aos Comerciantes para o endereço registado na conta; e o pedido de aceitação da nova versão, que será dirigido ao Comerciante quando a função correspondente estiver disponível — na data de publicação o Serviço não dispõe de um mecanismo de nova aceitação, e a presente disposição não promete nenhum antes disso. Não é dirigida qualquer comunicação aos Titulares dos dados através da aplicação: a aplicação não é um canal de comunicações legais. O Comerciante que não pretenda aceitar a versão 1.1 conserva a faculdade de resolução sem penalização prevista no §15.2.

15.3 Língua. A versão em língua italiana do presente DPA é a versão oficial e prevalece sobre as traduções em caso de divergência.

15.4 Lei aplicável e jurisdição. O presente DPA é regido pela lei italiana. Qualquer litígio está sujeito à jurisdição exclusiva do Tribunal de Roma.

15.5 Registo da aceitação. A aceitação do DPA é registada pelo Subcontratante mediante o registo de: denominação legal da Loja, correio eletrónico do utilizador que efetuou a aceitação, endereço IP, marca temporal e versão do DPA aceite. Estes dados constituem prova da aceitação ao abrigo dos arts. 20 e 21 do Decreto Legislativo italiano 82/2005 (Código da Administração Digital).

---

Anexo A — Subcontratantes Ulteriores, outros destinatários e infraestrutura própria

O presente anexo utiliza a mesma divisão em três blocos que o §4 da Política de Privacidade, para que os dois documentos possam ser lidos em paralelo.

A.1 Subcontratantes Ulteriores (art. 28 do RGPD)

Fornecedores que tratam Dados Pessoais em nome do Subcontratante, ao abrigo de um acordo nos termos do art. 28. A coluna "Dados de quem" é determinante: alguns destes fornecedores tocam apenas dados próprios da Loja e nunca dados de Titulares dos Dados.

Subcontratante Ulterior	Sede e local do tratamento	Papel	Dados de quem, e quais	Base da transferência
Contabo GmbH	Alemanha	Alojamento VPS de todos os sistemas de produção: base de dados, aplicação, filas de trabalho, cache, índice de pesquisa do catálogo e as cópias (dumps) da base de dados descritas em D.3	Dados de Titulares dos Dados — todas as categorias objeto do Serviço	Tratamento na UE
Stripe Payments Europe Ltd.	Irlanda (grupo com operações nos EUA)	Processamento dos pagamentos da subscrição da Loja; emissão de faturas	Apenas dados da Loja — dados de pagamento e fiscais. Não dados de Titulares dos Dados	SCC 2021/914/UE
Cloudflare, Inc.	EUA — buckets R2 configurados na região UE	Armazenamento de objetos para as imagens de programa e de cartão de acesso carregadas pela Loja e para os arquivos de exportação RGPD solicitados pela Loja; CDN para recursos estáticos. Não é aqui armazenada qualquer cópia de segurança da base de dados (ver D.3)	Dados da Loja e dados de Titulares dos Dados na medida em que estejam contidos num arquivo de exportação solicitado pela Loja	SCC 2021/914/UE
Apple Inc.	EUA	Entrega de passes Apple Wallet e de notificações push (APNs); aprovisionamento do Pass Type ID e do certificado de assinatura próprios da Loja através da API do App Store Connect	Dados de Titulares dos Dados — tokens push, identificadores de passe e o próprio conteúdo do passe, que nos cartões pessoais inclui o nome e o correio eletrónico do titular. As chamadas ao App Store Connect transportam apenas identificadores da Loja	SCC 2021/914/UE
Google LLC	EUA	Entrega de passes Google Wallet (API Google Wallet) e de notificações push (Firebase Cloud Messaging)	Dados de Titulares dos Dados — como na Apple	SCC 2021/914/UE
Operador do servidor de correio transacional mail.tesserapp.eu	[A COMPLETAR — ver A.4]	Envio de correio transacional por SMTP: convites de instalação de cartão, avisos de atividade, comunicações de serviço	Dados de Titulares dos Dados — endereço de correio do destinatário e conteúdo da mensagem; e dados da Loja	[A COMPLETAR — ver A.4]
Unwired Labs (LocationIQ)	[A COMPLETAR — ver A.4]	Preenchimento automático de endereços no painel da Loja. Contratado pelo Subcontratante, mas a chamada parte diretamente do navegador da Loja com uma chave publicável e não passa pelos sistemas do Subcontratante — ver A.2 e §10.2 bis	Apenas dados da Loja — o texto do endereço escrito e o endereço IP do navegador. Não dados de Titulares dos Dados	[A COMPLETAR — ver A.4]
Intermediário de faturação eletrónica junto do Sistema di Interscambio italiano (SdI)	Itália	Transmissão das faturas eletrónicas próprias do Subcontratante. Condicional: o Serviço prevê um intermediário externo, mas a configuração predefinida não transmite nada a nenhum. Se a produção utiliza um atualmente, fica [A COMPLETAR — ver A.4]	Apenas dados da Loja — dados de faturação. Não dados de Titulares dos Dados	Tratamento na UE

Removidos na versão 1.1. Dois fornecedores indicados no Anexo A da versão 1.0 não estão, nem nunca estiveram, contratados, e foram removidos:

• Resend — nunca utilizado. Não existe em nenhuma parte do Serviço qualquer dependência, ponto de chamada ou configuração a seu respeito. O correio transacional é enviado por SMTP através de mail.tesserapp.eu. Subsiste, como designação herdada, uma coluna de base de dados chamada resend_message_id, preenchida com o identificador de mensagem devolvido pelo servidor SMTP.
• FontAwesome, Inc. — não recebe nada. cdn.woptima.com é a CDN de ícones própria do Subcontratante, sob licença própria (ver A.3); os ícones deste sítio são compilados dentro das páginas publicadas.

A.2 Outros destinatários terceiros

Serviços que recebem dados como efeito direto de uma funcionalidade do produto, sem que esses dados passem pelos sistemas do Subcontratante. Não são Subcontratantes Ulteriores, porque o Subcontratante não está na via de transmissão.

Destinatário	O que recebe, e quando
Overpass — overpass-api.de, um serviço público do projeto OpenStreetMap	No iOS, quando o Titular dos Dados usa a funcionalidade de lojas próximas, o dispositivo envia a este endpoint público as coordenadas GPS do Titular dos Dados, com precisão integral e não arredondadas, para procurar pontos de interesse num raio de 50 metros. Nada mais é enviado: nenhum identificador, nenhum cartão, nenhum dado da aplicação. No Android o mesmo cliente existe na aplicação, mas esse caminho de código não é atualmente alcançado
LocationIQ (Unwired Labs)	Quando a Loja escreve um endereço no painel, o navegador envia à LocationIQ o texto escrito (e, nos formulários de estabelecimento, o código de país). Não envia a identidade da Loja nem quaisquer dados de sessão. O endereço IP do navegador é implícito em cada chamada. A chave publicável está incluída no pacote do painel e é restrita por domínio
Google LLC (Google Fonts)	Os tipos de letra do painel são carregados de fonts.googleapis.com e fonts.gstatic.com em cada página: a Google recebe, por isso, o endereço IP e o tipo de navegador de quem abre o painel
Stripe, Inc. (Stripe.js)	A biblioteca de pagamentos é carregada em cada página do painel, e não apenas nas páginas de faturação: a Stripe recebe, por isso, o endereço IP e os dados técnicos do navegador mesmo quando não está em curso qualquer pagamento. Os dados do cartão são introduzidos em campos alojados pela Stripe e nunca passam pelos sistemas do Subcontratante
Apple Inc. / Google LLC (Iniciar sessão com a Apple / com a Google)	Apenas se a Loja optar por iniciar sessão com a Apple ou com a Google, e apenas para a operação de início de sessão
Apple Inc. / Google LLC (cópia de segurança do dispositivo, Wallets nativos)	Na sua qualidade de fornecedores da conta do próprio Titular dos Dados: a base de dados local da aplicação do consumidor, incluindo o nome e o correio eletrónico do titular nos cartões pessoais, é integrada na cópia de segurança da conta iCloud ou Google do Titular dos Dados

A.3 Infraestrutura própria do Subcontratante

Componentes que podem parecer serviços de terceiros mas são instalações próprias do Subcontratante, nos seus próprios domínios, sem qualquer partilha de dados com o fabricante do software. Não são Subcontratantes Ulteriores.

Componente	Software	Papel
glitchtip.radiobros.com	GlitchTip (autoalojado)	Recolha dos relatórios técnicos de erro e de falha das aplicações. Configurado para não recolher dados identificativos do utilizador, não seguir sessões e não anexar endereços IP
helpdesk.radiobros.com	Zammad (autoalojado)	Sistema de assistência para os tickets da Loja. Recebe o correio eletrónico de contacto e a denominação da Loja, e o título, o corpo e os anexos de cada ticket
mail.tesserapp.eu	SMTP	Domínio de correio transacional próprio do Subcontratante. Quem opera o servidor subjacente consta de A.1
cdn.woptima.com	CDN estática sob licença própria do Subcontratante	Entrega dos ícones de interface, tanto ao navegador como aos servidores do Subcontratante quando estes compõem um passe Wallet. Nenhum dado pessoal. A FontAwesome, Inc. não recebe nada
adminizer.radiobros.com	Authentik (autoalojado)	Fornecedor de identidade que controla o acesso administrativo e máquina-a-máquina aos sistemas de produção
Recolha centralizada dos registos aplicacionais	Loki (autoalojado)	Diagnóstico e segurança. Quando ativa, os registos podem conter endereços IP e o contexto técnico de um pedido
Índice de pesquisa do catálogo	Meilisearch (autoalojado, no servidor de produção)	Pesquisa sobre os programas públicos. Contém dados dos programas da Loja, não dados de Titulares dos Dados: nenhum nome, nenhum correio eletrónico, nenhum cartão

A.4 Pontos abertos do presente anexo

Os elementos seguintes não são determináveis a partir da configuração do Serviço e são aqui declarados como abertos em vez de presumidos. O Subcontratante completá-los-á na próxima versão e, caso algum deles implique acrescentar um Subcontratante Ulterior, dará o pré-aviso de 30 dias exigido pelo §6.2:

1. Quem opera o servidor de correio mail.tesserapp.eu, o respetivo local de tratamento e a base de transferência.
2. O local de tratamento e a base de transferência da LocationIQ (Unwired Labs).
3. O fornecedor de alojamento dos subdomínios *.radiobros.com próprios do Subcontratante, enumerados em A.3.
4. Se a produção transmite atualmente as faturas eletrónicas através de um intermediário SdI externo.

A lista corrente é mantida no presente anexo. A versão 1.0 remetia a Loja para uma página "Privacidade → Subcontratantes" do painel; essa página não existe, e o presente anexo é a lista com valor de referência.

Anexo B — Categorias de dados e prazos de conservação

A versão 1.0 do presente anexo citava prazos de conservação que nenhum processo aplicava. Esta versão separa os dois casos, no entendimento de que é preferível descrever como o Serviço se comporta realmente do que publicar um prazo que nada aplica.

B.1 Prazos aplicados por um processo automatizado

Categoria	Conservação	Fundamento jurídico
Registos de entrega de webhooks enviados à Loja (nos cartões pessoais, estas cargas contêm o nome e o correio eletrónico do titular)	30 dias, eliminados automaticamente por uma varredura programada. Quando um cartão é eliminado, o nome, o correio eletrónico e a referência externa são imediatamente mascarados nas cargas já armazenadas; o registo técnico da chamada (evento, resultado, data) permanece até decorrerem os 30 dias	Interesse legítimo na fiabilidade da integração
Ciclo de vida da subscrição da Loja	Uma subscrição suspensa é cancelada após 60 dias; 150 dias após o cancelamento é enviado um aviso de eliminação; 180 dias após o cancelamento a conta é anonimizada, o que remove o nome, o correio eletrónico e a referência externa em cada um dos cartões dos clientes da Loja	Art. 28, n.º 3, alínea g), do RGPD; limitação da conservação
Eliminação solicitada pela Loja a partir do painel	Executada 30 dias após o pedido, com a mesma anonimização. A janela é um prazo de tolerância no qual o pedido pode ser anulado	Instrução do Responsável pelo Tratamento
Cartão individual eliminado pelo Titular dos Dados ou pela Loja	Campos identificativos apagados de imediato e irreversivelmente; sem janela de recuperação. Os registos dependentes e, quando nenhum lançamento contabilístico conservado o referir, o próprio registo do cartão são removidos em 30 dias; ver B.2	Execução do contrato do programa de fidelização
Intenções de pagamento não concretizadas para novos estabelecimentos	24 horas, sendo depois eliminadas por uma varredura diária	Execução do contrato (apenas dados da Loja)

B.2 Categorias sem caducidade automatizada

Para as categorias seguintes, nenhum processo programado elimina os dados. São removidos a pedido nos termos do §7.3 e, em qualquer caso, pela anonimização prevista em B.1.

Categoria	O que acontece realmente
Identificadores de cartões de fidelização e registos de cartões em estado "eliminado"	O registo é conservado por tempo indeterminado em estado "eliminado". Ao eliminar um cartão é escrito um campo com a data de uma purga definitiva, mas nada o lê: a purga definitiva é uma operação administrativa manual. A "eliminação no prazo de 5 dias" da versão 1.0 é retirada
Metadados de transação (selos, prémios, anulações, variações de saldo)	Conservados como registo da atividade da Loja e não eliminados juntamente com um cartão individual. As referências ao titular são removidas quando os dados do titular são apagados. Os "24 meses ativos e depois arquivados com referências pseudonimizadas" da versão 1.0 são retirados: não existe qualquer processo de arquivo desse tipo
Eventos de auditoria e registos de acesso, incluindo endereço IP e user-agent	Conservados sem caducidade predefinida. Não existe para eles qualquer processo de conservação, nem uma tabela separada de registos de acesso. Constituem o registo do que foi feito, incluindo a prova de que um apagamento foi executado. A "anulação dos endereços IP na eliminação definitiva do cartão do Titular dos Dados" da versão 1.0 é retirada
Registos de correio eletrónico enviado (endereço do destinatário e conteúdo das variáveis do modelo)	Conservados sem caducidade automática: nada os elimina. Os "30 dias a contar da conclusão do procedimento" da versão 1.0 são retirados
Endereço de correio eletrónico do Titular dos Dados fornecido voluntariamente ao Subcontratante	Conservado pelo tempo necessário para tratar o pedido e comprovar o seu resultado. Sem caducidade automática
Comunicações da Loja enviadas aos titulares de um programa (título, texto, imagem, ligação, número de dispositivos alcançados)	Conservadas como registo das comunicações da Loja. Sem caducidade automática
Registos de instalação para as notificações (resumo do token de instalação, token push, idioma, plataforma, versão da aplicação)	Conservados até que a remoção seja solicitada. Sem caducidade automática
Identificadores e tokens de atualização dos passes Apple / Google Wallet	Conservados até que o Titular dos Dados remova o passe do Wallet nativo, ou o cartão seja eliminado
Coordenadas GPS	Não conservadas de forma alguma. Viajam no único pedido que as utiliza e não são armazenadas nem pelo Subcontratante nem no dispositivo
Arquivos de exportação RGPD solicitados pela Loja	O ZIP é carregado no armazenamento de objetos e entregue através de uma ligação assinada de 48 horas. O arquivo permanece depois no bucket até remoção manual: a regra de ciclo de vida de 7 dias referida no código não está configurada. O que limita a exposição é a caducidade da ligação assinada, e não um processo de eliminação
Tickets de assistência no helpdesk do Subcontratante	Conservados sem caducidade automática
Relatórios técnicos de erro e de falha	Conservados no sistema de diagnóstico próprio do Subcontratante pelo tempo necessário para corrigir o defeito
Faturas da subscrição da Loja	Ver §9.3: 10 anos ao abrigo do art. 2220 do Código Civil italiano, que menciona expressamente as faturas; a legislação fiscal aplicável exige pelo menos 7, já satisfeitos por esse prazo. Dados da Loja, não de Titulares dos Dados

Anexo C — Direitos do Titular dos Dados e formas de exercício

A Loja é a primeira destinatária dos pedidos de exercício de direitos RGPD dos seus próprios clientes. A radioBros assiste a Loja disponibilizando:

• uma ferramenta de dados de cliente no painel (Configurações → Dados de cliente) que procura um cartão por número de série e o elimina, removendo o nome, o endereço de correio eletrónico e a referência externa do titular. É a única ação por Titular dos Dados disponível em autosserviço atualmente; a exportação, a retificação e a limitação são executadas pelo Subcontratante a pedido, conforme indicado no §7.3;
• a possibilidade de solicitar diretamente à radioBros, em privacy@tesserapp.eu, o exercício de direitos, que será encaminhado sem demora para a Loja ou executado por instrução desta;
• um registo de auditoria das operações significativas, mantido pelo Subcontratante e disponibilizado à Loja a pedido. A versão 1.0 descrevia-o como "acessível em qualquer momento pela Loja"; atualmente não existe uma vista do mesmo no painel, e o Subcontratante fornece o extrato pertinente a pedido.

Prazos indicativos de resposta (máximos ao abrigo do art. 12 do RGPD): 30 dias a contar do pedido, prorrogáveis por mais 60 dias em caso de complexidade, com informação ao Titular dos Dados.

Anexo D — Medidas técnicas e organizativas (art. 32 do RGPD)

Cada medida seguinte está assinalada como [implementada] quando está aplicada no Serviço atualmente, ou como [compromisso] quando o Subcontratante a assume sem ainda a poder comprovar. A versão 1.0 apresentava como factos várias medidas que os sistemas não aplicavam; são aqui corrigidas.

D.1 Confidencialidade

• [implementada] Cifragem em trânsito através de TLS 1.2 ou superior em todos os endpoints expostos.
• [implementada] Cifragem em repouso com AES-256 (SSE) dos objetos armazenados na Cloudflare R2. Os segredos aplicacionais — certificados dos passes Wallet, segredos TOTP — são cifrados com AES-256-GCM sob uma chave separada.
• [implementada] Resumo criptográfico argon2id, com parâmetros conformes às orientações da OWASP, para as palavras-passe das contas da Loja, os PIN do pessoal e os códigos de recuperação. Nenhuma palavra-passe é jamais armazenada em texto simples.
• [implementada] Resumo criptográfico SHA-256 para os tokens aleatórios de elevada entropia — cookies de sessão, tokens de instalação, tokens de convite, chaves de API. A versão 1.0 afirmava que os tokens de autenticação eram resumidos com argon2id; isso não é exato, e a escolha é deliberada: para um token aleatório de 256 bits, o espaço de procura já torna inviável um ataque por força bruta, pelo que um resumo deliberadamente lento nada acrescenta e custa uma procura em cada pedido.
• [implementada] Determinados tokens são armazenados tal como foram emitidos, sem resumo criptográfico, porque têm de ser reproduzidos literalmente junto de um terceiro ou reconhecidos numa chamada recebida: os tokens de notificação push (APNs, FCM), o token de autenticação do passe Wallet e os tokens de reivindicação de uso único da inscrição sem aplicação. A sua exposição é limitada pelo âmbito — um token push não tem significado fora da aplicação do Serviço; um token de autenticação de passe apenas autoriza atualizações desse único passe — e pelos controlos de acesso de D.2.
• [implementada] Segregação de ambientes (produção, pré-produção, desenvolvimento) com credenciais distintas e sem acesso a dados de produção a partir de ambientes que não sejam de produção.

D.2 Integridade

• [implementada] Controlo de acesso baseado em papéis na infraestrutura de produção, com o acesso administrativo e máquina-a-máquina controlado pelo fornecedor de identidade próprio do Subcontratante (A.3).
• [implementada] Registo de auditoria de cada operação administrativa e de cada operação significativa do lado da Loja, escrito numa tabela dedicada à qual a aplicação apenas acrescenta.
• [implementada] Migrações de esquema da base de dados versionadas, acompanhadas por um diário de resumos que deteta a alteração de uma migração.
• [implementada] Limitação de taxa nos endpoints de autenticação e nas API públicas.

D.3 Disponibilidade e resiliência

A versão 1.0 descrevia "cópias de segurança automáticas diárias da base de dados com Point-In-Time Recovery (PITR) através de WAL streaming (pgBackRest)". Nada disso está implementado. O que o Serviço faz realmente:

• [implementada] Cópias lógicas horárias da base de dados (pg_dump, formato custom comprimido), realizadas por um contentor dedicado que se liga diretamente ao PostgreSQL.
• [implementada] Verificação em três passos de cada cópia antes da publicação: o comando de cópia tem de terminar com êxito; o ficheiro tem de exceder um tamanho mínimo, o que deteta o modo de falha "ligado, autenticado, esquema vazio copiado"; e o índice da cópia tem de conter uma tabela sentinela, o que prova que existem dados reais no seu interior. Apenas uma cópia que passe os três controlos é publicada, e apenas um êxito verificado pode desencadear a remoção de cópias mais antigas — de modo que uma série de falhas nunca pode erodir as boas cópias que restam.
• [implementada] Retenção plana das 168 cópias mais recentes, guardadas no sistema de ficheiros do servidor de produção. Ao intervalo horário, isso corresponde a cerca de uma semana de histórico. Não existe promoção por níveis.
• Não implementado, dito sem rodeios: as cópias não são cifradas pelo próprio processo de cópia; não existe arquivo de WAL e, por isso, não há recuperação para um instante determinado — o ponto de recuperação é o intervalo de cópia; e as cópias não são replicadas fora do servidor. Um ficheiro de estado legível por máquina regista o resultado da última execução.
• [compromisso] Cifragem das cópias em repouso e uma cópia fora do servidor.
• [compromisso] Exercícios de restauro documentados, no mínimo anuais.
• [compromisso] Monitorização da infraestrutura com alarmes sobre anomalias de segurança e de disponibilidade.
• [implementada] Limitação de taxa nos endpoints públicos. A afirmação da versão 1.0 relativa a um "anti-DDoS perimetral através da Cloudflare" é retirada: a Cloudflare é utilizada para o armazenamento de objetos e a entrega de recursos estáticos, e não se encontra à frente da API.

D.4 Procedimentos de verificação

• [compromisso] Teste de intrusão externo anual.
• [compromisso] Revisão interna semestral das configurações de segurança.
• [compromisso] Gestão de vulnerabilidades com objetivos de correção definidos (crítica: 7 dias; elevada: 30 dias; média: 90 dias).

D.5 Continuidade do tratamento

• [compromisso] Procedimentos documentados de recuperação de desastres e de gestão de incidentes.
• [implementada] Substituibilidade dos Subcontratantes Ulteriores de infraestrutura em prazos razoáveis, sendo o Serviço implantado a partir de uma definição de contentor versionada e não de serviços geridos próprios de um fornecedor.

D.6 Gestão de incidentes

• [implementada] Um único ponto de contacto designado para a gestão de Violações de Dados Pessoais, contactável em privacy@tesserapp.eu.
• [compromisso] Um procedimento interno escrito de gestão de violações com cadeia de notificação predefinida, para garantir o cumprimento do prazo de 72 horas referido no art. 8 do presente DPA.

---

Contactos

• Subcontratante: radioBros di Alberto Miconi, Via Ridolfino Venuti 30, 00162 Roma (Itália), número de IVA italiano (Partita IVA) IT15127451001.
• Correio eletrónico para qualquer questão relativa ao presente DPA: privacy@tesserapp.eu.
• Autoridade de controlo principal da radioBros: Autoridade italiana de proteção de dados (Garante) — gpdp.it. As Lojas estabelecidas noutros Estados-Membros da UE podem também contactar a respetiva autoridade de controlo local.

---

Versão 1.1 — adotada em 8 de setembro de 2026, substituindo a versão 1.0 de 30 de maio de 2026. As versões históricas, quando disponíveis, são arquivadas em formato PDF nos URL https://tesserapp.eu/legal/dpa/v{version}.pdf.