Política de Privacidade

Última atualização: 27 de maio de 2026

Esta versão é uma tradução. A versão inglesa (privacy.en.md) é a versão controlante. Esta versão portuguesa é disponibilizada aos utilizadores lusófonos. Em caso de divergência entre as versões linguísticas, prevalece a versão inglesa — salvo quanto a questões reguladas exclusivamente pelo direito alemão dos telemedia, pelo direito alemão do consumo ou pelo direito alemão dos contratos, em que a formulação alemã é a autêntica.

1. Introdução

A presente declaração descreve a forma como a Uptimia («nós», «nos» ou «nosso»), operada pela JJ Online GmbH, procede ao tratamento dos seus dados pessoais no âmbito do https://uptimia.com (o «Website») e do serviço de monitorização Uptimia (o «Serviço»), em conformidade com os artigos 13.º e 14.º do RGPD e legislação equivalente em matéria de proteção de dados. É disponibilizada para sua informação; quando o tratamento depender do seu consentimento, esse consentimento é recolhido separadamente. Para os termos que regem a sua relação contratual connosco, consulte os nossos Termos de Serviço.

Recolha direta e indireta (Art. 13.º e Art. 14.º RGPD). A maior parte dos dados pessoais descritos no § 3 é-nos fornecida diretamente por si quando cria uma conta, configura monitores ou de outro modo utiliza o Serviço. Sempre que um elemento seja, em vez disso, obtido junto de um terceiro — concretamente:

metadados do método de pagamento devolvidos pela Stripe ou pelo PayPal no âmbito da sua subscrição;
payloads de Instant Payment Notification (IPN) do PayPal recebidos do PayPal no âmbito de cada transação, que podem incluir campos de contexto da transação (moeda de liquidação, estatuto do pagador, estatuto de confirmação da morada) que não foram originalmente fornecidos por si;
atributos de identidade devolvidos pela Google ou pelo GitHub através da página de início de sessão alojada na Auth0 quando opte por iniciar sessão através de uma ligação social (e os tokens associados emitidos pela Auth0);
normalização de morada, resultados de validação de NIF e outros metadados de geração de fatura devolvidos pela easybill no âmbito da emissão da sua fatura (quando a easybill devolve um campo — como uma morada postal normalizada ou um indicador de validade de NIF do sistema VIES da UE consultado através da easybill — que não foi literalmente introduzido por si, esse campo é recolhido indiretamente);

— o terceiro que constitui a fonte desses dados é identificado na entrada correspondente do § 5 (Serviços de terceiros) infra, em cumprimento da nossa obrigação ao abrigo do Art. 14.º, n.º 2, alínea f) RGPD de identificar a fonte. Fora destes fluxos específicos, nenhum dado pessoal que conservemos sobre si enquanto titular de conta é obtido junto de um terceiro.

2. Responsável pelo tratamento

Para efeitos do RGPD (Art. 4.º, n.º 7) e da legislação equivalente em matéria de proteção de dados, o responsável pelo tratamento dos seus dados pessoais enquanto titular de uma conta Uptimia é:

JJ Online GmbH (que opera a Uptimia)

Schönhauser Allee 163, 10435 Berlim

Alemanha

Registada em: Amtsgericht Charlottenburg, HRB 235074 B

USt-IdNr.: DE351060880

Representada por: Andrius Gecius, Geschäftsführer (gerente)

Telefone: +49 151 12032902

E-mail — geral / Informações Legais: admin@uptimia.com

E-mail — privacidade e pedidos do titular dos dados: privacy@uptimia.com

A identificação completa do prestador exigida pelo § 5 DDG está consignada nas nossas Informações Legais (inglês) / Impressum (alemão).

Nota sobre os papéis. Quando utiliza a Uptimia para monitorizar recursos que opera, atua como responsável pelo tratamento relativamente aos dados pessoais a que essa monitorização tenha acesso — endereços IP de visitantes captados pelos scripts de RUM que implementa, dados de utilizadores finais captados em capturas de ecrã da monitorização de transações, payloads de resposta de verificações autenticadas que incluam informação de utilizadores. Nesse cenário a Uptimia atua como subcontratante por sua conta, regida pelo nosso DPA — ver § 7 infra.

A presente Política descreve o nosso tratamento na qualidade de responsável pelo tratamento dos seus próprios dados enquanto utilizador do Serviço. A relação de subcontratação está descrita no § 7 e no DPA.

3. Informação que recolhemos

Recolhemos as seguintes categorias de dados pessoais sobre os utilizadores do Serviço.

Dados da conta

Identidade: endereço de e-mail, palavra-passe (armazenada como hash bcrypt; hashes legados são atualizados no primeiro início de sessão bem-sucedido), nome completo, um token opaco de retoma de conta
Morada postal: rua, código postal, cidade, estado, país, fuso horário
Identificação comercial: nome da empresa, número de identificação fiscal (NIF), moeda, região de faturação (código ISO de dois caracteres)
Contacto: número de telefone, e-mail de reporte, etiqueta de remetente personalizada para correio eletrónico de saída
Metadados de rede: o endereço IP a partir do qual se registou e o endereço IP a partir do qual iniciou sessão mais recentemente
Datas do ciclo de vida: data de registo, data da última atividade, início da subscrição, data de renovação da adesão, data de renovação dos créditos SMS
Segurança: estado da autenticação de dois fatores, preferência de notificação por e-mail no início de sessão, marca temporal do último início de sessão falhado, contador de inícios de sessão falhados, uma pontuação heurística interna de risco (consultiva; ver § 8 e a nota de conservação do § 11)
Preferências operacionais: os seus estados de opt-in para alertas por e-mail e por SMS, estado de cancelamento de subscrição, indicadores de onboarding, dias «sem alertas», a sua janela horária de alertas
Marketing / ciclo de vida: o código UTM ou de origem de referência do URL através do qual nos chegou pela primeira vez

Dados de faturação

Metadados de faturas, montantes, referências e referências de PDF armazenados
Metadados do método de pagamento (tokens Stripe / PayPal / cartão de crédito — nunca vemos o número completo do cartão)
Quando o pagamento é efetuado via PayPal, o payload de Instant Payment Notification do PayPal recebido no âmbito da transação

Dados de autenticação e de sessão

Cookies de sessão tal como listados na nossa Política de Cookies § 4
Registos de auditoria de início de sessão com 2FA — utilizador, marca temporal, endereço IP, user-agent — escritos sempre que conclui um desafio de 2FA
Registos de pedido de redefinição de palavra-passe — gerados a pedido quando solicita uma redefinição de palavra-passe
Chaves de API pessoais criadas por si para acesso programático ao Serviço — armazenadas apenas como hashes unidirecionais; ver § 12
Contador de inícios de sessão falhados e marca temporal do último falhanço no seu registo de utilizador

Canais de autenticação de dois fatores. Quando ativa a autenticação de dois fatores, o código único é entregue por e-mail (através do nosso subcontratante de correio transacional — AWS SES, ver § 5.2) ou gerado localmente por uma aplicação autenticadora TOTP no seu dispositivo (Google Authenticator, 1Password, Authy ou equivalente). Não enviamos códigos de 2FA por SMS e não transmitimos o seu número de telefone a qualquer fornecedor de SMS no fluxo de 2FA. Quando a funcionalidade de alertas por SMS for ativada por si separadamente para alertas de monitorização, esse fluxo está documentado nos § 5 e § 7 (Twilio).

Configurações de monitor criadas por si

Quando cria um monitor, a configuração é armazenada na nossa base de dados aplicacional e encaminhada para a rede de sondas no momento da execução. As configurações podem conter dados pessoais:

Verificações HTTP autenticadas: o URL, as credenciais de autenticação HTTP (credenciais Basic e/ou cabeçalhos de pedido personalizados, que podem transportar bearer tokens ou chaves de API), qualquer corpo POST que forneça e os padrões de conteúdo esperado que configure
Monitores de transação: os seletores CSS e expressões XPath utilizados para conduzir o percurso, em conjunto com quaisquer valores literais (incluindo credenciais de teste) que o percurso submete em cada passo

As credenciais e segredos que fornece nas configurações de monitor são mantidos sob criptografia em envelope ao nível da coluna, com chaves geridas separadamente, conforme descrito no § 12.

Resultados das verificações

Gerados pela nossa rede de sondas em cada verificação:

Uptime / HTTP: tempos por fase, estado, tipo de erro e o corpo da resposta devolvido pelo URL monitorizado (os corpos de resposta são conservados durante 7 dias e depois expirados automaticamente, conforme § 11)
SSL: emissor do certificado, datas de validade e quaisquer erros relacionados com o certificado observados
Domínio / WHOIS: registar, servidores de nomes, datas do ciclo de vida e a resposta WHOIS completa
Velocidade: tempos de carregamento, repartição por recurso, pontuações PageSpeed
Transação: estado por passo, duração e uma captura de ecrã armazenada da página em cada passo (a captura de ecrã pode incluir dados pessoais visíveis no ecrã no momento da captura)
Real User Monitoring (RUM): apenas métricas agregadas — tempo de carregamento da página, visualizações, contagens de erros JavaScript, origem geográfica, classe de navegador e dispositivo. Não são recolhidos Core Web Vitals (LCP / INP / CLS / TTFB) (conforme o âmbito do produto)
Vírus / malware: o estado devolvido pelo fornecedor de análise de malware; não é conservado qualquer payload analisado
Agente de servidor: métricas de CPU, memória, disco e rede transmitidas pelo agente que implementa nos seus próprios servidores. Estas métricas descrevem a saúde de um servidor, não de uma pessoa singular. São, no entanto, vinculáveis a si enquanto titular da conta porque o agente está registado contra a sua conta Uptimia, e com base nessa vinculação tratamo-las como dados pessoais seus enquanto titular da conta durante a duração da relação contratual — tratadas com base no Art. 6.º, n.º 1, alínea b) RGPD (contrato). O agente não transmite qualquer identificador de utilizador final do servidor monitorizado (sem listas de processos, sem nomes de contas de utilizador, sem variáveis de ambiente); as categorias supra listadas são exaustivas.

Os períodos de conservação para cada uma das categorias supra são regidos pelo § 11.

Configurações de canais de notificação

Quando configura um canal de alertas (Slack, Discord, Twilio SMS, Meta WhatsApp Cloud, PagerDuty, Atlassian Statuspage, Microsoft Teams, Mattermost, Telegram, X, webhooks genéricos), armazenamos as credenciais do canal e os registos de contacto que fornece. Cada um é encaminhado para o canal escolhido em cada alerta.

Duplo papel dos canais de alertas. Os canais de alertas transportam duas categorias diferentes de dados sob duas qualificações de papel diferentes, e o mesmo terceiro (Slack, Twilio, etc.) veste ambos os chapéus:

Registos de contacto e credenciais da equipa de operações — os números de telefone, identificadores de workspace e canal Slack, chaves de integração PagerDuty, tokens de bot Telegram, URLs de webhook, etc. que fornece, mais o próprio payload do alerta quando dirigido à sua própria equipa de operações. Estes registos identificam o seu pessoal (os seus engenheiros de plantão, o seu pessoal de resposta a incidentes), não visitantes dos seus sítios monitorizados. Para este vetor a Uptimia é Responsável pelo tratamento relativamente ao fluxo de dados do canal de alertas, e os terceiros de canais de alertas são prestadores de serviços da própria Uptimia; a base jurídica é o Art. 6.º, n.º 1, alínea b) RGPD (execução do seu contrato de subscrição — a entrega de alertas é a prestação contratada) e o Art. 6.º, n.º 1, alínea f) RGPD (interesse legítimo do Cliente, enquanto titular da conta, em ser notificado). Estes fluxos estão inventariados no § 5 como parte do stack de relações de responsável pelo tratamento da Uptimia.
Dados de utilizador final / visitante que possam incidentalmente aparecer num payload de alerta — por exemplo, quando tenha redigido um passo de monitorização de transação cuja mensagem de falha contenha um identificador de utilizador final, ou quando um extrato de corpo de resposta de uma verificação autenticada exponha dados pessoais de um dos seus visitantes e seja incluído no resumo do alerta. Para essa componente incidental a Uptimia atua como Subcontratante por sua conta (na qualidade de Responsável pelo tratamento), o terceiro do canal de alertas torna-se um Subcontratante ulterior para esse vetor, e o fluxo cai sob o inventário de subcontratantes ulteriores do Anexo C.5 do DPA. Esta componente é aquela que o § 7 infra aborda.

As duas qualificações coexistem porque o evento de alerta é uma única mensagem que transporta ambos os tipos de conteúdo. A análise de relação de responsável pelo tratamento do § 5 rege o vetor dos registos de contacto e credenciais e o vetor do alerta dirigido à sua equipa de operações; a análise do papel de subcontratante do § 7 rege apenas o vetor dos dados de visitante embebidos.

Dados de apoio

Quando nos contacta, recebemos e armazenamos o conteúdo da interação juntamente com os identificadores de contacto que fornece:

Conversas do widget de chat HelpCanvas — o widget de chat é carregado no sítio de marketing (https://uptimia.com) e, quando tenha sessão iniciada, na superfície aplicacional. Cada conversa é armazenada como o próprio fio de mensagens, o seu nome a apresentar e endereço de e-mail (quando os fornecer) e os metadados técnicos que o HelpCanvas regista sobre a sessão (marcas temporais, User-Agent do navegador, endereço IP, URL da página em que a conversa foi iniciada). O HelpCanvas é um produto JJ Online que corre na própria infraestrutura UE da JJ Online (ver § 5.7 infra); a conversa não sai da UE e não é partilhada com qualquer terceiro que já não seja subcontratante ulterior do HelpCanvas.
Correspondência por e-mail para os nossos endereços de função — admin@uptimia.com (geral), privacy@uptimia.com (privacidade e pedidos do titular dos dados) e qualquer outro endereço de função para o qual escreva. Recebemos e armazenamos os cabeçalhos do e-mail (o seu endereço de remetente, o nosso endereço de destinatário, marcas temporais, message-id), o corpo da mensagem e quaisquer anexos que opte por enviar. O correio de entrada e saída é processado através de AWS SES eu-central-1 (ver § 5.2) e armazenado na própria infraestrutura de correio UE da JJ Online.

Categorias. Identificadores (nome, endereço de e-mail), conteúdo de texto livre (a sua mensagem e quaisquer anexos) e metadados técnicos (marcas temporais, IP, User-Agent, contexto da página para o widget de chat; cabeçalhos SMTP para o e-mail).

Base jurídica. Art. 6.º, n.º 1, alínea b) RGPD quando a correspondência diga respeito à execução do contrato de Serviço que connosco mantém (p. ex. uma pergunta de funcionalidade numa conta paga); Art. 6.º, n.º 1, alínea c) RGPD quando a correspondência seja, ela própria, o cumprimento de uma obrigação legal (p. ex. resposta a um pedido do titular dos dados nos termos dos Artt. 12.º a 22.º RGPD); Art. 6.º, n.º 1, alínea f) RGPD para pedidos de entrada provenientes de potenciais clientes e outros correspondentes com quem não temos contrato, sendo o interesse legítimo responder a comunicações de entrada dirigidas aos nossos endereços de função publicados.

Destinatários. Internos: membros da JJ Online GmbH que gerem a fila de apoio, faturação ou privacidade pertinente. Subcontratantes ulteriores externos: AWS SES eu-central-1 para transporte de e-mail (§ 5.2); a pilha aplicacional HelpCanvas corre na própria infraestrutura UE da JJ Online e não introduz um destinatário terceiro (§ 5.7 e § 11 «Conversas de apoio alojadas no HelpCanvas»). Nenhum conteúdo de apoio é partilhado com terceiros para além do necessário para entregar o e-mail ou para acionar o seu pedido concreto (por exemplo, quando nos pede para encaminhar uma questão de faturação para a Stripe, fá-lo-emos conforme a sua instrução).

Conservação. Duração do processo de apoio mais 3 anos civis ancorados ao fim do ano, conforme a linha Correspondência de apoio no § 11, com base no Art. 6.º, n.º 1, alínea f) RGPD lido com a regelmäßige Verjährungsfrist nos §§ 195 + 199 BGB. A conversa na plataforma HelpCanvas e a correspondência por e-mail estão sujeitas à mesma conservação; ver § 11 «Conversas de apoio alojadas no HelpCanvas» para a análise da plataforma de registo.

Metadados de pedido do lado do servidor lidos em cada pedido

O seu endereço IP (utilizado para limitação de taxa e defesa contra abuso)
A string User-Agent do seu navegador (utilizada para validação da integridade da sessão; aplicado hash no controlo de integridade por sessão)

O endereço IP é persistido no seu registo de conta apenas como os valores de registo e de início de sessão mais recente descritos em «Dados da conta» supra; de outro modo é lido transitoriamente e não conservado. A string User-Agent não é conservada para além do controlo de integridade de sessão sob hash.

Se a prestação desta informação é obrigatória (Art. 13.º, n.º 2, alínea e) RGPD)

Estamos obrigados, ao abrigo do Art. 13.º, n.º 2, alínea e) RGPD, a informá-lo se a prestação dos seus dados pessoais é um requisito legal ou contratual e quais as consequências caso opte por não os fornecer:

Exigido por lei. O seu nome, morada de faturação, NIF quando aplicável e detalhes da transação têm de ser conservados para cumprir as obrigações fiscais e contabilísticas alemãs (§ 147 AO, § 257 HGB; § 14 UStG quanto ao conteúdo da fatura IVA). Sem estes, não podemos emitir-lhe fatura legalmente.
Exigido por contrato. O seu e-mail, palavra-passe, identificador do método de pagamento de faturação e as configurações de monitor que submete são necessários para operar o contrato de Serviço nos termos do Art. 6.º, n.º 1, alínea b) RGPD. Sem eles não podemos prestar o Serviço.
Necessário para acesso à conta e segurança. O seu endereço IP, user-agent, marcas temporais de início de sessão e estado de 2FA são tratados ao abrigo do Art. 6.º, n.º 1, alínea f) RGPD para manter a sua conta segura.
Voluntário. Preferências de opt-in de marketing, campos de perfil opcionais e feedback ficam ao seu critério; a não prestação não afeta o seu acesso ao Serviço.

Categorias especiais de dados pessoais (Art. 9.º RGPD)

Não tratamos conscientemente categorias especiais de dados pessoais na aceção do Art. 9.º, n.º 1 RGPD — isto é, dados que revelem a origem racial ou étnica, opiniões políticas, convicções religiosas ou filosóficas, filiação sindical, dados genéticos, dados biométricos tratados para identificar uma pessoa singular de forma inequívoca, dados relativos à saúde ou dados relativos à vida sexual ou orientação sexual de uma pessoa singular. A Uptimia é um produto de observabilidade business-to-business; nenhuma das categorias listadas no § 3 supra (conta, faturação, autenticação, configurações de monitor, resultados de verificações, configurações de canais de notificação, dados de apoio, metadados de pedido do lado do servidor) está concebida ou destinada a captar dados do Art. 9.º.

Não nos submeta dados de categoria especial — por exemplo, não os cole em URLs de monitor, cabeçalhos de monitor, corpos de pedido, mensagens de teste de canais de alertas ou tickets de apoio, e não programe percursos de monitorização de transações que encaminhem dados de categoria especial através da Uptimia. Caso, ainda assim, nos submeta inadvertidamente esses dados — por exemplo, numa descrição de apoio em texto livre — tratamo-los como receção inadvertida: não invocamos qualquer base do Art. 9.º, n.º 2 RGPD para tratá-los como dados de categoria especial, não os utilizamos para qualquer finalidade além do estritamente inevitável para acionar o ticket de apoio que no-los trouxe, e eliminaremos o campo problemático a pedido sem prejuízo do restante fio de apoio. Na medida limitada em que o tratamento do campo seja inevitável nos instantes entre a receção e a eliminação (p. ex., o agente lê a mensagem para perceber o pedido antes de o ocultar), apoiamo-nos no Art. 9.º, n.º 2, alínea f) RGPD (tratamento necessário para a declaração, o exercício ou a defesa de um direito em processo judicial — aqui, o tratamento do ticket de apoio que assenta no Art. 6.º, n.º 1, alínea f) e nos §§ 195 + 199 BGB conforme estabelecido no § 11 «Correspondência de apoio») apenas na medida em que essa alínea seja efetivamente acionada. Não nos apoiamos no Art. 9.º, n.º 2, alínea e) RGPD (dados manifestamente tornados públicos pelo titular dos dados): submeter informação pessoal num ticket de apoio privado não é uma divulgação deliberada e dirigida ao público dentro da leitura estrita do Art. 9.º, n.º 2, alínea e) exigida pelo acórdão Lindqvist (TJUE C-101/01) e orientações do CEPD, e não a tratamos como tal.

Quando, na qualidade de Responsável pelo tratamento, implemente o nosso script RUM ou a monitorização de transações numa superfície que trate dados de categoria especial dos seus visitantes / utilizadores finais, essa é uma decisão sua enquanto responsável pelo tratamento e da sua exclusiva responsabilidade nos termos do Art. 9.º RGPD; nada no nosso Serviço ou DPA o autoriza a encaminhar dados de categoria especial através da Uptimia, e a declaração de categorias de dados do Anexo A do DPA pressupõe apenas dados ordinários de visitante / utilizador final.

4. Como utilizamos a sua informação

Utilizamos os dados que recolhemos para as finalidades indicadas infra. Conforme o Art. 13.º, n.º 1, alínea c) RGPD, a base jurídica é indicada junto a cada finalidade.

Finalidade	Base jurídica (Art. 6.º RGPD)
Operar, manter e melhorar o Serviço e o Website	Art. 6.º, n.º 1, alínea f) — interesse legítimo
Autenticá-lo, manter a sua sessão, aplicar a 2FA quando ativada	Art. 6.º, n.º 1, alínea b) — contrato
Executar as configurações de monitor que cria e entregar os resultados das verificações no seu painel	Art. 6.º, n.º 1, alínea b) — contrato
Entregar alertas nos canais configurados (SMS, WhatsApp, Slack, Discord, Teams, Mattermost, Telegram, PagerDuty, Atlassian Statuspage, X, webhooks)	Art. 6.º, n.º 1, alínea b) — contrato
Processar pagamentos de subscrição e emitir faturas	Art. 6.º, n.º 1, alínea b) — contrato
Manter registos fiscais e contabilísticos	Art. 6.º, n.º 1, alínea c) — obrigação legal (§ 147 AO, § 257 HGB)
Detetar, prevenir e tratar fraude, ataques de força bruta a credenciais e abuso do Serviço	Art. 6.º, n.º 1, alínea f) — interesse legítimo na integridade da conta
Executar os seus monitores contra os recursos que configura, a partir da rede de sondas multirregião	Art. 6.º, n.º 1, alínea b) — contrato
Monitorização de qualidade de medição cross-customer e operações da rede de sondas — agregação dos resultados das sondas entre clientes para detetar anomalias do lado das sondas, calibrar timings e identificar incidentes regionais que afetem múltiplos clientes; o output é agregado e não produz qualquer sinal a nível individual	Art. 6.º, n.º 1, alínea f) — interesse legítimo na qualidade do serviço, na deteção de anomalias das sondas e na fiabilidade global da plataforma. Não afirmamos que o output agregado é «anónimo» no quadro estrito dos três testes da Opinião 05/2014 sobre Técnicas de Anonimização do antigo Grupo de Trabalho do Artigo 29.º (singularização, vinculabilidade, inferência, todos vencidos); tratamos a agregação cross-customer como pseudonimizada para a análise da base jurídica e ancoramo-la no Art. 6.º, n.º 1, alínea f) em conformidade. Os relatórios de output são divulgados apenas a um nível de agregação por região suficiente para impedir a reidentificação da configuração de monitor de qualquer Responsável pelo tratamento individual
Executar rastreio de atribuição de afiliados no sítio de marketing (FirstPromoter — só dispara quando o URL inclui `?via=`)	Art. 6.º, n.º 1, alínea a) + § 25 Abs. 1 TDDDG (em vigor desde 14 de maio de 2024 enquanto sucessor da TTDSG) — consentimento via banner Datriva
Emitir comunicações transacionais (conta, faturação, segurança)	Art. 6.º, n.º 1, alínea b) — contrato
Emitir notificações legalmente obrigatórias (atualizações de privacidade / termos nos termos dos Artt. 12.º a 14.º, notificações de violação de dados pessoais nos termos do Art. 34.º)	Art. 6.º, n.º 1, alínea c) — obrigação legal
Enviar comunicações de atualização de produto a titulares de conta existentes (lançamentos de funcionalidades Uptimia, atualizações pertinentes para o serviço e anúncios sobre serviços JJ Online semelhantes)	Art. 6.º, n.º 1, alínea f) RGPD em conjugação com o § 7 Abs. 3 UWG (Bestandskundenwerbung). As quatro condições cumulativas do § 7 Abs. 3 UWG estão todas preenchidas: (i) o seu endereço foi obtido no contexto da venda dos nossos bens ou serviços (subscrição ou inscrição em teste); (ii) utilizamos o endereço apenas para marketing direto dos nossos próprios produtos e serviços semelhantes; (iii) não se opôs a esta utilização — uma vez que se oponha, todo o envio dessa natureza cessa imediatamente; e (iv) foi clara e visivelmente informado, tanto no momento em que recolhemos o seu endereço como em cada mensagem subsequente, de que pode opor-se em qualquer momento sem incorrer em quaisquer custos para além das tarifas básicas de transmissão (Basistarif) — i.e., nada mais do que o destinatário pagaria para enviar uma mensagem normal de volta no meio de transmissão. A oposição ao abrigo do Art. 21.º RGPD é incondicional e processada na receção sem prejuízo do contrato subjacente
Enviar comunicações de marketing às quais consentiu	Art. 6.º, n.º 1, alínea a) — consentimento
Cumprir obrigações legais, responder a pedidos lícitos	Art. 6.º, n.º 1, alínea c) — obrigação legal

Para cada finalidade assente em interesses legítimos, o resumo do teste de balanceamento e o seu direito de oposição ao abrigo do Art. 21.º RGPD estão descritos no § 15. Uma Avaliação de Interesses Legítimos (AIL) para qualquer destas atividades está disponível mediante pedido em privacy@uptimia.com.

5. Serviços de terceiros que utilizamos enquanto responsável pelo tratamento

Os serviços listados nesta secção tratam dados pessoais seus enquanto titular de conta Uptimia sob as nossas instruções enquanto responsável pelo tratamento do Website e do Serviço. Quando a Uptimia atue adicionalmente como subcontratante por sua conta relativamente a dados pessoais dos seus próprios visitantes / utilizadores finais, os subcontratantes ulteriores contratados para esse papel distinto estão listados no § 7 e no Anexo C do DPA.

A lista completa de Subcontratantes ulteriores com moradas, datas de DPA e mecanismos de transferência consta do Anexo C do DPA. O resumo infra destina-se à transparência ao abrigo do Art. 13.º, n.º 1, alínea e) RGPD.

5.1 Pagamentos e faturação

Prestador	Entidade jurídica	Localização	Função	Mecanismo de transferência
Stripe	Stripe Payments Europe Ltd.	Irlanda (+ subcontratação ulterior nos EUA pela Stripe, Inc.)	Processamento de pagamentos de subscrição, tokenização de cartões, deteção de fraude	EU–US DPF + SCC como recurso
PayPal	PayPal (Europe) S.à r.l. et Cie, S.C.A.	Luxemburgo (+ subcontratação ulterior nos EUA)	Checkout alternativo	EU–US DPF + SCC como recurso
easybill	easybill GmbH	Alemanha	Geração de faturas, arquivo de faturas em conformidade com GoBD	n/a (apenas UE)

5.2 Hospedagem e infraestrutura central

Prestador	Entidade jurídica	Localização	Função	Mecanismo de transferência
OVH	OVH SAS	França	Hospedagem aplicacional principal (painel, API, base de dados aplicacional primária), rede de sondas (região UE), base de dados time-series auto-hospedada	n/a (UE)
AWS — UE	Amazon Web Services EMEA SARL	Luxemburgo (eu-central-1 Frankfurt + S3)	E-mail transacional via SES para destinatários UE; armazenamento de PDFs de fatura e exportações em S3; rede de sondas (regiões UE)	n/a (região UE de Frankfurt)
AWS — EUA	Amazon Web Services, Inc.	EUA (us-east-1 Virgínia)	E-mail transacional via SES para destinatários não-UE; rede de sondas (regiões não-UE)	EU–US DPF + SCC como recurso

5.3 Rede de sondas

A rede de sondas Uptimia está geograficamente distribuída por nove prestadores. Propriedade de design importante: as sondas tratam o resultado da verificação transitoriamente em memória + em trânsito e eliminam imediatamente qualquer cópia local após reencaminhar o resultado para a infraestrutura principal localizada na UE. Não são persistidos quaisquer Dados Pessoais do Cliente em repouso na camada de sondas.

Prestador	Entidade jurídica	Localização	Mecanismo de transferência
OVH	OVH SAS	França	n/a (UE)
GCore	G-Core Labs S.A.	Luxemburgo + regiões globais	n/a regiões UE; SCC para não-UE
DigitalOcean	DigitalOcean, LLC	EUA + regiões	EU–US DPF + SCC como recurso
Linode / Akamai	Akamai Technologies, Inc.	EUA + regiões	EU–US DPF + SCC como recurso
EDIS	EDIS Telekommunikation GmbH (operando como EDIS.at)	Klagenfurt, Áustria	n/a (UE)
Scaleway	Scaleway SAS (Grupo Iliad)	França — regiões de sondas em França (Paris), Países Baixos (Amesterdão) e Polónia (Varsóvia); todas UE	n/a (UE)
AWS	tal como supra (5.2)	UE + EUA	n/a UE; DPF + SCC EUA
Contabo	Contabo GmbH	Alemanha (sede em Munique) — regiões de sondas na UE (Alemanha, Áustria, Espanha, Portugal) e fora da UE (EUA, Reino Unido, Singapura, Japão, Austrália, Índia)	n/a regiões UE (Contabo GmbH é a entidade contratante UE); SCC para regiões não-UE, com a propriedade de tratamento efémero descrita no § 7 (Anexo B.6 do DPA) como medida suplementar que impede o armazenamento persistente de Dados Pessoais do Cliente em hosts de sondas, independentemente da região
Vultr	Vultr Holdings, LLC (The Constant Company, LLC)	EUA (Delaware) — 13 localizações de sondas distribuídas pelos EUA, Países Baixos, Alemanha, Reino Unido, Austrália, Japão	Sem certificação DPF — SCC + a propriedade de tratamento efémero descrita supra como principal medida suplementar. A Vultr fornece IaaS puro e não garante contratualmente a propriedade de ausência de armazenamento persistente para qualquer utilização específica que um cliente faça dos seus servidores; a propriedade de tratamento efémero é, portanto, uma medida técnica e organizativa ao nível da implementação da JJ Online (sem persistência ao nível aplicacional para discos da Vultr; inputs e outputs das verificações apenas em memória e em trânsito; o binário da sonda não escreve qualquer Dado Pessoal do Cliente em disco local) implementada por nós enquanto responsável pelo tratamento, e está documentada como tal no Anexo B.6 do DPA. Verificamos periodicamente a propriedade — pelo menos trimestralmente e a cada alteração do binário da sonda ou da sua configuração de implementação — amostrando hosts de sondas, listando escritas em disco local face a uma lista de exclusão de caminhos que o binário da sonda está autorizado a tocar e confirmando que não foram escritos Dados Pessoais do Cliente em disco; o registo de verificação faz parte do registo regular de testes do Art. 32.º, n.º 1, alínea d) que mantemos e é apresentável a pedido da autoridade de controlo. O próprio DPA da Vultr é o DPA standard do lado do prestador e não é invocado para evidenciar esta medida.

5.4 Autenticação

Prestador	Entidade jurídica	Localização	Função	Mecanismo de transferência
Auth0	Auth0 EMEA Limited (Grupo Okta)	Irlanda (+ subcontratação ulterior nos EUA)	Gestão de identidade, fluxo de início de sessão, orquestração de ligações sociais	EU–US DPF + SCC como recurso

Subcontratantes ulteriores de ligações sociais do Auth0. Quando opte por iniciar sessão com Google ou GitHub na página de início de sessão alojada na Auth0, a Auth0 entrega o fluxo OAuth a esses prestadores. Não existe integração OAuth direta entre a Uptimia e a Google ou o GitHub; a Auth0 detém o DPA subjacente. Os prestadores são: Google Ireland Limited (com subcontratação ulterior nos EUA pela Google LLC) e GitHub, Inc. (Grupo Microsoft).

Cookies durante o fluxo de início de sessão. A página de início de sessão alojada na Auth0 define os seus próprios cookies estritamente necessários no domínio Auth0 (não em uptimia.com) durante a autenticação. Estes cookies são necessários para concluir o início de sessão que solicitou e estão isentos de consentimento nos termos do § 25 Abs. 2 Nr. 2 TDDDG. Os botões «Iniciar sessão com Google» e «Iniciar sessão com GitHub» nas nossas páginas de início e criação de sessão utilizam um padrão click-to-load: nenhum script Auth0, Google ou GitHub é carregado, e nenhum pedido a esses prestadores é efetuado, até que clique num desses botões; detalhe completo e o URL de privacidade Auth0 / Okta estão na nossa Política de Cookies § 4.8.

5.5 Segurança e inteligência de ameaças

Prestador	Entidade jurídica	Localização	Função	Mecanismo de transferência
Google Web Risk API	Google Ireland Limited	Irlanda (+ subcontratação ulterior nos EUA)	Análise de malware / phishing de URLs monitorizados — apenas o URL é enviado	EU–US DPF + SCC como recurso
Google PageSpeed Insights	Google Ireland Limited	Irlanda (+ subcontratação ulterior nos EUA)	Análise de desempenho para o monitor de Velocidade — apenas o URL é enviado	EU–US DPF + SCC como recurso

5.6 Integrações da página de marketing

Prestador	Entidade jurídica	Localização	Função	Mecanismo de transferência
FirstPromoter	Igil Webs SRL	Roménia	Atribuição de afiliados em páginas de marketing uptimia.com — só dispara quando o URL inclui `?via=`; sujeito ao seu consentimento via banner de cookies Datriva	n/a (UE)

5.7 Serviços internos JJ Online entre produtos (mesmo responsável pelo tratamento — não Subcontratantes ulteriores do Art. 28.º)

Os seguintes são operados pela própria JJ Online GmbH e não são Subcontratantes ulteriores do Art. 28.º. Todos os cinco correm na mesma pegada UE da aplicação principal Uptimia — OVH França (base de dados aplicacional e serviços auto-hospedados) e, quando seja necessário armazenamento de blobs, AWS Frankfurt eu-central-1 — sob as mesmas medidas técnicas e organizativas do Art. 32.º descritas no § 12. Nenhum tratamento de produto-irmão JJ Online sai da UE.

Banner CMP Datriva — gestão de consentimento de cookies no sítio de marketing (https://datriva.com/cdn/banner/uptimia.js). Alojado em OVH França.
Widget HelpCanvas — apoio em chat in-app no sítio de marketing. A aplicação HelpCanvas e o seu repositório de mensagens estão alojados em OVH França sob o stack da JJ Online; as transcrições de chat HelpCanvas não saem da UE.
Base de dados time-series auto-hospedada — armazenamento time-series para métricas de monitorização, operada pela JJ Online em infraestrutura OVH França.
Altcha — biblioteca de captcha proof-of-work executada localmente em infraestrutura Uptimia; sem fluxo de dados de terceiros.
ErrorHawk (produto-irmão) — fora do âmbito de produção: o DSN está configurado apenas no nosso ambiente interno de desenvolvimento, não na infraestrutura de produção uptimia.com. Não são reencaminhados Dados Pessoais do Cliente para o ErrorHawk em produção. O próprio stack de produção do ErrorHawk, quando pertinente para outros produtos JJ Online, corre igualmente em OVH França.

Divulgação a terceiros — sem revenda, sem treino de IA, sem construção de audiência. Não divulgamos os seus dados pessoais a terceiros para os seus próprios fins comerciais. Os serviços de terceiros nos § 5.1 a 5.6 tratam os seus dados pessoais apenas como nossos subcontratantes, com base nas nossas instruções documentadas, ao abrigo de contratos escritos de tratamento de dados que proíbem contratualmente cada subcontratante de utilizar os seus dados pessoais para qualquer finalidade além do serviço específico que prestam por nossa conta. As utilizações secundárias proibidas incluem, sem limitação:

Treino de modelos de inteligência artificial, aprendizagem automática ou modelos de linguagem de grande dimensão — incluindo pré-treino de modelos fundacionais, fine-tuning, extração de embeddings, indexação de retrieval-augmented-generation, construção de conjuntos de avaliação ou qualquer outra incorporação dos seus dados pessoais em conjuntos de dados derivados ou pesos de modelo, seja pelo subcontratante seja por qualquer terceiro a quem o subcontratante sublicencie a jusante
Publicidade, perfilagem, construção de audiências similares (look-alike), segmentação publicitária ou enriquecimento de segmentos de audiência
Revenda, sublicenciamento ou sindicação dos seus dados pessoais — em base nominal, pseudonimizada, em hash ou agregada — a contrapartes de tipo data-broker, redes analíticas ou redes publicitárias
Qualquer outra utilização secundária que não seja necessária para entregar-nos o serviço contratado

As restrições do Art. 28.º, n.º 3 em cada contrato de tratamento de dados de subcontratante são o mecanismo de execução das proibições supra. Quando os termos standard ou o DPA de um subcontratante não cubram adequadamente estas proibições, ou negociamos termos modificados antes de o instruir, ou não contratamos o subcontratante.

6. Outros destinatários — fiscal, auditoria, jurídico, M&A e pedidos lícitos

Para além dos subcontratantes do dia a dia no § 5, em linha com o Art. 13.º, n.º 1, alínea e) RGPD e as Orientações do CEPD sobre Transparência (WP260 rev. 01), podemos também divulgar dados pessoais às seguintes categorias de destinatários:

Categoria de destinatário	Quando	Base jurídica	Âmbito
Autoridades fiscais (Finanzamt; equivalentes noutras jurisdições)	Declarações fiscais periódicas, auditorias de conformidade, pedidos lícitos de informação	Art. 6.º, n.º 1, alínea c) — § 147 AO, § 257 HGB	Limitado a dados de transação, faturação e contabilísticos exigidos por lei
Auditores externos (estatutários, voluntários, due-diligence do lado do comprador)	Auditoria anual, auditoria financeira ou de segurança voluntária, due-diligence pré-aquisição	Art. 6.º, n.º 1, alínea c) quando obrigatório; caso contrário Art. 6.º, n.º 1, alínea f)	Sob obrigações escritas de confidencialidade profissional; minimizado ao âmbito do mandato
Consultores jurídicos (advogados externos, attorneys, notários)	Defesa de pretensões, litígios contratuais, resposta regulatória, aconselhamento transacional	Art. 6.º, n.º 1, alínea f); § 203 StGB confidencialidade profissional	Minimizado ao âmbito da instrução
Potenciais adquirentes e respetivos consultores (M&A, investimento, venda de ativos, reestruturação)	Operações societárias — data rooms de due-diligence, contratos de compra e venda de ações, vendas de ativos	Art. 6.º, n.º 1, alínea f), interpretado de forma consistente com o Beschluss «Datenschutz im Asset Deal» da DSK de 11 de setembro de 2024 (que substituiu e ampliou o documento original da DSK de 24 de maio de 2019). Aplicamos especificamente a estrutura fase a fase do Beschluss: na fase de due-diligence, os dados pessoais dos clientes são, em princípio, disponibilizados apenas em forma pseudonimizada ou agregada, sendo a divulgação de dados identificadores limitada à exceção estreita do Art. 6.º, n.º 1, alínea f) que o Beschluss reconhece para a fase final (LOI assinada / negociações avançadas, NDA em vigor, minimização ao estritamente necessário para as questões de diligência remanescentes do comprador, sem despejo amplo de data room); na fase de fecho / transferência, seguimos o percurso de base jurídica que o Beschluss prescreve para a estrutura de transação relevante e, em particular, tratamos a venda de uma base de dados de clientes como ativo autónomo como o caso mais sensível que, na análise do Beschluss, exige geralmente consentimento ou um processo significativo de informação e oposição pré-transferência, distinto do caso em que as relações com os clientes se transferem incidentalmente como parte de um asset deal mais amplo em going-concern. Em ambas as fases, o afastamento do Beschluss em relação a uma pura Widerspruchslösung pós-fecho a favor da informação prévia à transferência aos titulares dos dados afetados está refletido na coluna de garantias	NDA escrita, minimização do data room, pseudonimização ou agregação durante a due-diligence (com dados identificadores libertados apenas sob a exceção estreita do Art. 6.º, n.º 1, alínea f) da fase final, em base need-to-know e apenas depois de cruzado o limiar da LOI / negociações avançadas), e informação prévia à transferência aos titulares dos dados afetados em conformidade com o Beschluss de 11 de setembro de 2024, em vez de um mero opt-out pós-transferência — com o cenário de base de dados de clientes autónoma tratado no percurso mais protetor de base jurídica que o Beschluss prevê para esse caso
Autoridades de aplicação da lei, tribunais, reguladores	Pedido lícito — decisão judicial, intimação, investigação regulatória	Art. 6.º, n.º 1, alínea c) quando vinculativo; Art. 6.º, n.º 1, alínea f) para cooperação voluntária verificada	Limitado ao âmbito do pedido concreto; contestamos pedidos demasiado amplos quando a lei o permite
Seguradoras e administradores de sinistros	Sinistros de responsabilidade civil profissional, ciber-seguro, responsabilidade comercial	Art. 6.º, n.º 1, alínea f)	Minimizado a dados pessoais necessários para avaliar e tratar o sinistro concreto

Nenhum destes destinatários recebe dados pessoais de forma rotineira ou em escala; cada divulgação é desencadeada por um evento específico.

7. Uptimia como subcontratante para dados dos seus visitantes / utilizadores finais

Quando utiliza a Uptimia para monitorizar recursos que opera, surgem certos fluxos de tratamento em que o Cliente é o responsável pelo tratamento dos dados pessoais dos seus visitantes ou utilizadores finais e a Uptimia é o subcontratante que atua por sua conta:

Fluxo	Que dados pessoais fluem através da Uptimia
Verificações HTTP autenticadas	Corpos de resposta de URLs que configure podem conter nomes de utilizador, endereços de e-mail ou outros dados pessoais dos seus utilizadores finais — captados em instantâneos de resposta da verificação (TTL de 7 dias no campo do corpo da resposta)
Monitorização de transações	Capturas de ecrã captadas em cada passo de um script de transação podem incluir dados pessoais visíveis em páginas autenticadas (p. ex., o nome de um utilizador com sessão iniciada na barra de navegação) — armazenadas durante o período de conservação indicado no § 11
Real User Monitoring (RUM)	Quando implementa o nosso script RUM em URLs que selecione, este reenvia tempos de carregamento de página, metadados de navegador e dispositivo, origem geográfica e eventos de erro JavaScript; os endereços IP dos visitantes são truncados para /24 IPv4 e /48 IPv6 antes do armazenamento; os eventos são persistidos apenas em forma agregada — não existe registo por beacon de um visitante individual
Subscrições de incidentes da página de estado	Endereços de e-mail que os seus visitantes introduzem para subscrever notificações de incidentes numa página de estado que opera via Uptimia

Distinção responsável / subcontratante — análise dos meios essenciais e não essenciais. O Art. 28.º RGPD exige que o responsável pelo tratamento determine as finalidades e os meios do tratamento e que o subcontratante atue com base nas instruções documentadas do responsável. As Orientações 07/2020 do CEPD sobre os conceitos de responsável pelo tratamento e subcontratante (parágrafo 38) traçam uma linha clara entre os meios essenciais — quais as categorias de dados que são tratadas, quais as categorias de titulares de dados, a duração da conservação, os destinatários dos dados — que o responsável pelo tratamento tem de determinar e os meios não essenciais — escolhas técnicas de implementação como algoritmo, formato, software, hardware — que o subcontratante é livre de determinar. Somos o subcontratante dos dados pessoais dos seus visitantes / utilizadores finais com base na seguinte análise:

As finalidades são suas. O Cliente decide se implementa o nosso script RUM e em que URLs, se monitoriza um endpoint autenticado, se programa um percurso de transação e se opera uma página de estado pública que recebe subscrições de visitantes. Nenhuma dessas operações de tratamento começa até que o Cliente as inicie.
Os meios essenciais são seus. A escolha de implementação determina a categoria de dados (implementar RUM = eventos de carregamento de página dos seus visitantes; configurar monitorização de transações = capturas de ecrã do percurso programado pelo Cliente); as categorias de titulares dos dados são determinadas por quem visita os sítios do Cliente e por quem o Cliente programa o percurso; o período de conservação é determinado pelo nível do Plano de Serviço do Cliente (ver § 11 e a matriz de níveis de plano em uptimia.com); os destinatários dos dados estão limitados pelo isolamento da conta e pelos subcontratantes ulteriores documentados no Anexo C do DPA, aos quais o Cliente consente ao implementar.
Os meios não essenciais são nossos. A truncagem /24 IPv4 e /48 IPv6 dos endereços IP dos visitantes antes do armazenamento, a lógica de agregação que mantém os eventos RUM fora de tabelas por beacon, a escolha de infraestrutura de armazenamento localizada na UE (OVH França para a base de dados aplicacional, AWS Frankfurt eu-central-1 para blobs de capturas de ecrã em S3) e a propriedade de tratamento efémero da camada de sondas são escolhas técnicas de implementação que fazemos enquanto subcontratante. Constituem medidas técnicas e organizativas do Art. 32.º RGPD — reforçam o controlo do Cliente sobre os meios essenciais, em vez de o substituírem.

Com base nesta análise, os quatro fluxos supra são relações limpas responsável-para-subcontratante do Art. 28.º. O nosso DPA incorpora os termos de responsável-para-subcontratante exigidos pelo Art. 28.º, n.º 3 RGPD; a implementação do Serviço (implementação do script, configuração de monitores, seleção do nível de plano), as instruções documentadas no DPA e o Resumo de Instruções de Tratamento por Conta descrito no DPA § 6.1, alínea e) e no Anexo A.8 constituem, em conjunto, as suas instruções documentadas para efeitos do Art. 28.º, n.º 3, alínea a) RGPD. O DPA aplica-se automaticamente por remissão nos termos do § 17.2 dos ToS da Uptimia quando o Cliente começa a utilizar funcionalidades de monitorização que tratam dados pessoais dos seus visitantes / utilizadores finais; não é necessária qualquer assinatura separada para colocar o DPA em vigor.

Art. 28.º, n.º 9 RGPD — forma escrita / eletrónica. O Art. 28.º, n.º 9 RGPD exige que o contrato responsável-subcontratante seja celebrado «por escrito, incluindo em formato eletrónico». Os Termos de Serviço da Uptimia nos quais o DPA está incorporado são, eles próprios, em formato eletrónico, e o texto integral do DPA é publicado num URL estável e persistente em uptimia.com (atualmente https://uptimia.com/legal/dpa — a mesma superfície canónica a partir da qual esta Política de Privacidade é publicada) e está acessível ao Cliente no momento da incorporação, tanto antes como durante a sua aceitação dos ToS. A sua aceitação eletrónica dos ToS — ao subscrever, pagar ou de outro modo utilizar o Serviço de forma que active funcionalidades de monitorização que tratem dados pessoais dos seus visitantes / utilizadores finais — constitui a sua assinatura do DPA para efeitos do Art. 28.º, n.º 9 RGPD. O percurso de «contrapartida contra-assinada mediante pedido» no parágrafo seguinte é, portanto, uma cortesia para preferências de forma de procurement, não uma condição prévia para que o DPA esteja em vigor; o DPA é plenamente vinculativo ao abrigo do Art. 28.º, n.º 9 apenas com base na aceitação eletrónica.

Instruções documentadas por conta. O Cliente pode solicitar o Resumo de Instruções de Tratamento por Conta a qualquer momento escrevendo para privacy@uptimia.com. O Resumo é gerado a partir do estado da sua conta no momento do pedido e lista, para a sua conta específica: os tipos de monitor ativos, os URLs e recursos que escolheu monitorizar, o seu nível de Plano de Serviço e os períodos de conservação que dele decorrem, os canais de alertas que ativou (e, portanto, os Subcontratantes ulteriores ativos na sua conta), a região de armazenamento UE aplicável aos seus dados e quaisquer instruções escritas subsequentes que tenhamos aceitado do Cliente. Devolvemos o Resumo no prazo de cinco (5) dias úteis. O Resumo é documental — não modifica o DPA — e destina-se a apoiar a sua obrigação de registo das atividades de tratamento ao abrigo do Art. 30.º, n.º 1 e a responsabilização do Art. 5.º, n.º 2 quando o Cliente trate dados pessoais dos seus visitantes / utilizadores finais através do Serviço. A geração self-service do Resumo no painel está no roadmap do produto; até lá, aplica-se o processo manual.

Contrapartida assinada do DPA. Quando o seu processo de procurement, auditoria ou regulatório exija uma contrapartida contra-assinada do nosso DPA com o Resumo de Instruções de Tratamento anexado como Anexo A.8, executá-la-emos a pedido sem custos. Contacto privacy@uptimia.com.

Subcontratantes ulteriores do lado do visitante. Os subcontratantes ulteriores contratados para o papel de subcontratante estão listados no Anexo C do DPA. Constituem um superconjunto dos subcontratantes do § 5 supra. As entradas adicionais do Anexo C.5 são os canais de alertas que o Cliente configura (Slack, Discord, Twilio, PagerDuty, etc.), que se tornam Subcontratantes ulteriores apenas na medida em que o payload do alerta inclua dados pessoais de visitantes / utilizadores finais do Cliente (conforme indicado no § 3 «Configurações de canais de notificação — duplo papel dos canais de alertas» supra), e apenas quando o Cliente efetivamente ative o canal. Os mesmos terceiros atuam também como prestadores de serviços da própria Uptimia quanto aos registos de contacto e credenciais da equipa de operações e à componente do alerta dirigido à sua equipa de operações do mesmo fluxo — esse vetor de relação de responsável pelo tratamento é o que está inventariado no § 5, não aqui. A listagem do Anexo C.5 é, portanto, mais estreita do que a lista canal a canal do § 5: é a projeção em papel de subcontratante do mesmo conjunto de terceiros.

Garantias técnicas para os fluxos no papel de subcontratante.

Os endereços IP de visitantes RUM são truncados para /24 (IPv4) ou /48 (IPv6) antes de o evento ser escrito em armazenamento; o endereço IP completo nunca é persistido
Os eventos RUM são persistidos apenas em forma agregada — não existe tabela por beacon e nenhum visitante individual pode ser reconstruído a partir dos dados armazenados
As capturas de ecrã de transações e os instantâneos de resposta de verificação são armazenados em AWS S3 (Frankfurt) sob a nossa conta; o acesso é controlado pela autenticação da conta de registo
Os nós de sondas tratam inputs e outputs de verificações apenas efemeramente; não são persistidos Dados Pessoais do Cliente em repouso na camada de sondas
As credenciais e segredos que o Cliente fornece para que o Serviço possa autenticar-se nos seus recursos (credenciais HTTP Basic, cabeçalhos de pedido personalizados, credenciais de integração, valores literais de passos de monitorização de transação) são mantidos sob criptografia em envelope ao nível da coluna, com chaves geridas separadamente, conforme descrito no § 12

Consentimento do visitante. É responsabilidade do Cliente enquanto responsável pelo tratamento obter qualquer consentimento exigido dos seus visitantes antes de implementar o nosso script RUM no seu sítio Web. Quando o § 25 TDDDG ou direito nacional UE equivalente exija consentimento para o armazenamento ou acesso a informação no terminal do visitante, os seus visitantes devem ter uma oportunidade de consentimento conforme ao § 25 antes de o nosso script RUM carregar. Disponibilizamos documentação sobre a integração de gating de consentimento; a implementação é do Cliente.

8. Definição de perfis e decisões automatizadas

Esta secção divulga as atividades automatizadas que o Serviço opera que cumprem a definição de definição de perfis nos termos do Art. 4.º, n.º 4 RGPD, conforme exigido pelos Art. 13.º, n.º 2, alínea f) e Art. 15.º, n.º 1, alínea h) RGPD — incluindo a única atividade que cumpre a definição de decisão automatizada nos termos do Art. 22.º, n.º 1 RGPD.

Decisão de fraude de pagamento no checkout (Art. 22.º, n.º 1 RGPD). Quando submete um pagamento, o nosso processador de pagamentos avalia a transação face a sinais que incluem método de pagamento, impressão digital do dispositivo, morada de faturação, endereço IP, histórico de utilização anterior e padrões de aprendizagem automática extraídos do corpus de fraude mais alargado do processador, para produzir uma pontuação de risco de fraude. Uma pontuação suficientemente elevada provoca a recusa da transação, a sinalização para revisão manual pelo processador ou o encaminhamento para verificação adicional como 3-D Secure. Esta é uma decisão exclusivamente automatizada que, ao impedir em tempo real a conclusão da compra, tem efeitos sobre si suficientemente significativos para se enquadrar no Art. 22.º, n.º 1 RGPD.

A análise aqui divide-se entre (i) a base jurídica para o tratamento subjacente dos seus dados de pagamento (Art. 6.º RGPD) e (ii) a porta do Art. 22.º, n.º 2 RGPD que autoriza a própria decisão automatizada. Seguindo a leitura estrita do CEPD sobre «necessário para o contrato» nas suas Orientações sobre o Art. 22.º (e a linha reforçada pelos comentários pós-SCHUFA Holding (TJUE C-634/21, 7 dez. 2023)), conduzimos a análise pelas bases estatutárias e tratamos a necessidade contratual apenas como fallback.

Base jurídica para o tratamento subjacente — Art. 6.º, n.º 1, alínea c) RGPD (principal). O tratamento é necessário para o cumprimento, pelo processador de pagamentos, dos requisitos de Autenticação Forte do Cliente (SCA) da DSP2 (Diretiva (UE) 2015/2366 e Regulamento Delegado (UE) 2018/389 da Comissão), dos regimes de combate ao branqueamento de capitais / financiamento do terrorismo (Diretiva (UE) 2015/849 conforme alterada; o Regulamento AML da UE; atos nacionais de transposição) e da obrigação constante das Orientações EBA/GL/2017/17 sobre medidas de segurança para riscos operacionais e de segurança dos serviços de pagamento da EBA de aplicar mecanismos de monitorização de transações que detetem transações de pagamento fraudulentas. Essas obrigações estatutárias vinculam diretamente o processador de pagamentos e refletem-se em nós enquanto comerciante por conta do qual a análise é operada; tornam o tratamento necessário para o cumprimento de uma obrigação legal à qual a Uptimia (através do processador) está sujeita na aceção do Art. 6.º, n.º 1, alínea c) RGPD.

Art. 6.º, n.º 1, alínea f) RGPD — base alternativa para o interesse residual do lado do comerciante em prevenção de fraude. Na medida em que qualquer elemento da análise vá além do estritamente exigido pelo quadro estatutário supra e reflita o nosso próprio interesse, do lado do comerciante, em prevenir fraude card-not-present, estornos e tomada de conta no momento da inscrição, apoiamo-nos no Art. 6.º, n.º 1, alínea f) RGPD. O balanceamento de interesse legítimo para este elemento residual está documentado no § 15 («Resumo da avaliação de interesses legítimos») e trata o interesse como substancial (perda direta de fraude + ónus de tratamento de disputas), os interesses do titular dos dados como protegidos pelas garantias do Art. 22.º, n.º 3 infra, e o tratamento como proporcionado (sinais por transação, não conservados como perfil).

Art. 6.º, n.º 1, alínea b) RGPD — base de execução do contrato, apenas fallback. Quando nem o enquadramento estatutário nem o de interesse residual abrangerem um elemento concreto do tratamento, a análise é também necessária para nos permitir entrar no leg de pagamento do contrato que procura celebrar connosco, apoiando o Art. 6.º, n.º 1, alínea b). Listamo-lo como fallback porque partilhamos a visão do CEPD de que a «necessidade» do Art. 6.º, n.º 1, alínea b) deve ser lida de forma restrita: o facto de a análise de fraude ser operacionalmente indispensável não satisfaz, por si só, o teste de «ausência de alternativa menos intrusiva», e as bases supra do Art. 6.º, n.º 1, alíneas c) e f) são a narrativa mais limpa.

Porta do Art. 22.º, n.º 2 para a própria decisão automatizada. O Art. 6.º só por si não autoriza a decisão automatizada do Art. 22.º, n.º 1; essa decisão precisa de uma porta do Art. 22.º, n.º 2 — a) necessidade contratual, b) direito da União ou de um Estado-Membro autorizador que estabeleça garantias adequadas ou c) consentimento explícito. Apoiamo-nos principalmente no Art. 22.º, n.º 2, alínea b) RGPD: o quadro SCA da DSP2 (Diretiva (UE) 2015/2366 lida com o Regulamento Delegado (UE) 2018/389 da Comissão) e o quadro AML / CTF citado supra constituem direito da União autorizador que exige as próprias decisões de monitorização de transações tomadas no checkout e que estabelece, ele próprio, as garantias adequadas para o titular dos dados (capítulo de proteção do consumidor do Título IV da DSP2; mecanismos de reclamação e revisão da AMLD na transposição nacional; as garantias do Art. 22.º, n.º 3 RGPD do titular dos dados aplicadas em paralelo). As Orientações da EBA citadas supra operacionalizam esse regime estatutário através de expectativas supervisórias vinculativas sobre as decisões de monitorização de pagamentos. Tratamos o Art. 22.º, n.º 2, alínea a) RGPD (necessidade contratual) como porta do Art. 22.º apenas fallback — acionada se e na medida em que uma autoridade de controlo lesse de forma restrita a porta autorizadora do Art. 22.º, n.º 2, alínea b) — e não nos apoiamos no Art. 22.º, n.º 2, alínea c) (consentimento explícito), que não seria livremente prestado num contexto de checkout de pagamento.

As suas garantias ao abrigo do Art. 22.º, n.º 3 RGPD. O Cliente tem direito:

a obter intervenção humana na decisão — escreva para privacy@uptimia.com identificando a transação recusada; encaminharemos o caso para a equipa de revisão manual do processador de pagamentos e para a nossa operação de faturação, ambas com capacidade para anular o resultado automatizado com base nos factos;
a expressar o seu ponto de vista — pode submeter qualquer contexto que considere relevante (p. ex. contexto de viagem para uma recusa por IP estrangeiro, dados de faturação corrigidos, prova de propriedade do cartão);
a contestar a decisão — o resultado da revisão manual é ele próprio reanalisável por nós; se permanecer insatisfeito pode utilizar o percurso de checkout alternativo (Stripe ↔ PayPal) ou solicitar uma explicação escrita adequada para envio ao emissor do seu cartão.
a receber o código específico do motivo de recusa e, quando aplicável, o nome da regra Stripe Radar — mediante pedido nos termos do Art. 22.º, n.º 3, além dos passos de revisão humana supra, comunicar-lhe-emos o código de motivo de recusa devolvido pelo processador de pagamentos para a sua transação e, quando a recusa tenha sido motivada por uma regra Radar específica que o processador nos exponha no painel de comerciante (por oposição a uma recusa do banco emissor), o nome dessa regra. Esta é a divulgação dos motivos principais por decisão descrita em «Informação significativa sobre a lógica subjacente» infra; tornamos o compromisso explícito aqui para que esteja acessível a partir da lista de garantias do Art. 22.º, n.º 3 sem ter de ler primeiro o parágrafo de implementação SCHUFA.

Responderemos a qualquer pedido nos termos do Art. 22.º, n.º 3 no prazo do Art. 12.º, n.º 3 RGPD (um mês, prorrogável por mais dois meses em casos complexos com aviso ao Cliente).

Informação significativa sobre a lógica subjacente (Art. 15.º, n.º 1, alínea h) RGPD; TJUE Processo C-634/21 SCHUFA Holding, 7 dez. 2023). A pontuação de risco de fraude é produzida por um modelo de aprendizagem automática de terceiros mantido pelo processador de pagamentos (Stripe Radar; o modelo equivalente do PayPal) e afinado contra o corpus global de fraude desse processador. Os pesos internos desses modelos não são publicados pelo processador e não nos são disponibilizados nos termos standard de comerciante — expor os pesos permitiria aos fraudadores fazer engenharia inversa do modelo, o que é o motivo pelo qual nenhum processador de pagamentos de cartões com expressão divulga os pesos. Não consideramos que essa ausência prejudique o seu direito ao abrigo do Art. 15.º, n.º 1, alínea h). O SCHUFA Holding exige «informação significativa sobre a lógica subjacente» suficiente para permitir ao titular dos dados compreender o procedimento que conduziu à pontuação e, sendo caso disso, contestar a decisão concreta no seu caso — não o algoritmo em si. Nesse padrão divulgamos, e mediante pedido confirmaremos por escrito:

Os principais grupos de fatores que o modelo avalia — montante e moeda da transação; metadados do método de pagamento (BIN do cartão, país de emissão, marca, tipo de financiamento); resultado AVS de verificação de morada de faturação; impressão digital do dispositivo e do navegador; endereço IP, geolocalização IP e incompatibilidade IP-vs-país de faturação; resultados anteriores para o mesmo cartão ou conta no corpus global do processador e na Uptimia (o seu próprio histórico connosco); sinais de reputação ao nível da rede e listas de bloqueio; resultado 3-D Secure quando disponível.
O motivo principal do seu resultado específico. Se a sua transação foi recusada, o processador devolve um código específico de motivo de recusa (por exemplo do_not_honor, card_declined, fraudulent, lost_card, stolen_card, pickup_card, incorrect_cvc, expired_card) e, quando a recusa tenha sido motivada por uma regra Radar, em vez do banco emissor, o nome da regra que disparou (visível para nós no painel de comerciante). Repassaremos esse código específico e, quando disponível, o nome específico da regra, mediante pedido — essa é a divulgação dos motivos principais exigida pelo SCHUFA Holding parágrafos 54 a 59.
O percurso de anulação que controlamos enquanto comerciante. Uma recusa de fraude do lado do processador não o tranca fora do Serviço. Podemos optar por honrar uma transação que o modelo recusou; escreva para privacy@uptimia.com identificando a transação, forneça qualquer contexto que considere relevante (viagem, dados de faturação corrigidos, prova de propriedade do cartão) e (a) escalaremos para a equipa de revisão manual do processador, que pode anular o modelo com base nos factos, e (b) reapresentaremos a cobrança do nosso lado de comerciante após a anulação, ou utilizaremos o percurso de checkout alternativo (Stripe ↔ PayPal).
Significância para si. Uma pontuação suficientemente elevada recusa a transação no checkout, dispara um step-up 3-D Secure ou encaminha a transação para revisão manual no processador. A pontuação não é conservada como perfil no seu registo de utilizador; é um sinal por transação.

Limites de taxa anti-abuso e classificação de bots de inscrição (sem decisão do Art. 22.º). Separadamente da fraude de pagamento, aplicamos decisões automatizadas de limite de taxa contra os endpoints da API e de inscrição com base em padrões de pedido, reputação de IP e antiguidade da conta. A inscrição é adicionalmente protegida por Altcha, um desafio proof-of-work auto-hospedado executado localmente em infraestrutura Uptimia (sem fluxo de dados de terceiros). É também registada uma pontuação heurística interna no seu registo de utilizador. Estes sinais são apenas consultivos — não existe lógica de suspensão automática nem de rejeição automática. As contas são desativadas manualmente por um administrador após revisão humana. A inscrição é limitada a 3 tentativas por 15 minutos por IP. A decisão é reversível mediante escrita para privacy@uptimia.com.

Transparência da definição de perfis para a heurística consultiva (Art. 4.º, n.º 4, Art. 13.º, n.º 2, alínea f), Art. 14.º, n.º 2, alínea g), Art. 15.º, n.º 1, alínea h) RGPD). A pontuação heurística consultiva no seu registo de utilizador é definição de perfis dentro do Art. 4.º, n.º 4 RGPD, mesmo que não seja tomada qualquer decisão exclusivamente automatizada com efeitos jurídicos ou similarmente significativos com base nela (o Art. 22.º, n.º 1 RGPD não é acionado). As obrigações de transparência ao abrigo do Art. 13.º, n.º 2, alínea f) e Art. 14.º, n.º 2, alínea g) — e o correspondente direito de acesso a «informação significativa sobre a lógica subjacente» ao abrigo do Art. 15.º, n.º 1, alínea h) — não estão, na melhor leitura, estritamente limitadas à definição de perfis do Art. 22.º, n.º 1; divulgamos, portanto, tanto aqui antecipadamente como mediante pedido de acesso, as principais categorias de inputs que a heurística avalia: taxa de tentativas de inscrição ou início de sessão a partir do mesmo IP e do mesmo domínio de e-mail num intervalo definido; presença do IP em listas de reputação internas e externas bem conhecidas (p. ex. agregadores de listas open-proxy / Tor-exit / known-VPN); sinais de antiguidade e estado da conta (recém-criada vs. antiga, histórico anterior de tickets de apoio); semelhança de padrões com impressões digitais conhecidas de abuso (taxa de falha de proof-of-work via Altcha, padrão de criação de monitores nos minutos posteriores à inscrição). Mediante pedido de acesso nos termos do Art. 15.º, n.º 1, alínea h), divulgaremos adicionalmente a pontuação registada na sua conta, os principais contribuidores para essa pontuação e a ausência de qualquer regra de decisão automática associada.

O seu direito de oposição ao abrigo do Art. 21.º RGPD. O Cliente conserva o direito de se opor a qualquer definição de perfis que se apoie nos nossos interesses legítimos (Art. 6.º, n.º 1, alínea f) RGPD). Esse direito não se estende, porém, à decisão de fraude de pagamento descrita supra na medida em que essa decisão assente na porta autorizadora do Art. 22.º, n.º 2, alínea b) e na base estatutária do Art. 6.º, n.º 1, alínea c) — nenhuma das quais aciona o Art. 21.º. Para o elemento residual de Art. 6.º, n.º 1, alínea f) da análise, o Art. 21.º aplica-se, mas o balanceamento de interesse legítimo registado no § 15 prevaleceria na prática sobre uma oposição relativa a uma tentativa de pagamento ativa; para a própria decisão, as suas garantias são os direitos do Art. 22.º, n.º 3 estabelecidos supra.

9. Consentimento de cookies — dar e retirar

O banner de cookies em uptimia.com é operado pela Datriva (também um produto JJ Online GmbH — utilizamos a nossa própria plataforma de gestão de consentimento — dogfooding). Quando utilizamos cookies ou tecnologias comparáveis que exijam o seu consentimento ao abrigo do Art. 6.º, n.º 1, alínea a) RGPD e § 25 Abs. 1 TDDDG, o mecanismo de consentimento e o mecanismo de retirada são regidos pelas seguintes regras.

Como obtemos o consentimento. Na sua primeira visita ao sítio de marketing, o banner Datriva aparece antes de ser colocado qualquer cookie não essencial. O banner apresenta as três categorias que exigem consentimento (Funcional, Análise, Marketing) apenas como opt-in — cada categoria está desmarcada por defeito. Pode aceitar tudo, recusar tudo ou aceitar um subconjunto granular com o mesmo número de cliques, em conformidade com o Art. 7.º, n.º 2 RGPD e Orientações 05/2020 do CEPD sobre consentimento. Os cookies estritamente necessários são colocados sem consentimento com base no § 25 Abs. 2 Nr. 2 TDDDG.

Retirada — tão fácil como dar. O Art. 7.º, n.º 3 RGPD exige que a retirada do consentimento seja tão fácil como dá-lo. Conforme as Orientações 05/2020 do CEPD sobre consentimento (parágrafo 117), paridade aqui significa o mesmo meio e o mesmo número de passos que o opt-in original. Operamos, portanto, um único percurso de paridade nos termos do Art. 7.º, n.º 3:

Hiperligação «Preferências de Cookies» no rodapé do sítio de marketing (percurso de paridade do Art. 7.º, n.º 3). Uma hiperligação persistente «Preferências de Cookies» está presente no rodapé de cada página de marketing. Ao clicar nela, reabre o mesmo banner Datriva com as suas configurações atuais, onde pode desligar qualquer categoria — ou recusar todos os cookies não essenciais — no mesmo número de cliques que demorou a aceitá-los. Como o banner que trata da retirada é o mesmo elemento de UI, no mesmo meio, com os mesmos controlos de comutação que o banner que tratou do consentimento original, o mecanismo de retirada é idêntico (não meramente «tão fácil como») ao mecanismo de prestação. Esta é a forma mais forte de paridade do Art. 7.º, n.º 3 contemplada pelas Orientações 05/2020 do CEPD sobre consentimento parágrafo 117 e é o que invocamos como o nosso percurso de paridade.

Dois percursos adicionais estão disponíveis por conveniência mas não equivalem ao opt-in original e não são invocados para satisfazer a paridade do Art. 7.º, n.º 3:

E-mail para privacy@uptimia.com. Registaremos e acionaremos a retirada manualmente no prazo do Art. 12.º, n.º 3 RGPD.
Limpar cookies no seu navegador. Isto também limpa o nosso registo de consentimento armazenado localmente, pelo que o banner reaparece na sua próxima visita; os passos envolvidos não são equivalentes ao mecanismo de opt-in original.

Efeito da retirada. Os cookies não essenciais deixam de ser colocados imediatamente após a retirada. A retirada não afeta a licitude do tratamento realizado antes da retirada (Art. 7.º, n.º 3 RGPD, segunda frase).

Para o inventário cookie a cookie, ver a Política de Cookies.

10. Cookies

Utilizamos cookies e tecnologias de rastreio semelhantes. A nossa Política de Cookies estabelece: (i) as quatro categorias (Estritamente Necessários, Funcionais, Análise, Marketing — atualmente não utilizamos quaisquer Funcionais, quaisquer de Análise, e apenas um terceiro de categoria Marketing, e apenas quando o Cliente chega via ?via=), (ii) cada cookie específico e cada entrada de localStorage / sessionStorage com o seu fornecedor e duração, (iii) scripts de terceiros, (iv) as bases jurídicas para cada categoria ao abrigo do § 25 TDDDG e Art. 6.º RGPD e (v) os mecanismos de consentimento e retirada.

11. Conservação dos dados

Conservamos dados pessoais apenas pelo tempo necessário para as finalidades estabelecidas nesta política ou conforme exigido por lei. Conforme o Art. 5.º, n.º 1, alínea e) RGPD, aplicamos uma análise de limitação da conservação baseada em categorias, em vez de um único relógio uniforme. As categorias infra cobrem todos os dados pessoais que tratamos.

Categoria	Período de conservação	Base jurídica
Dados de conta e de comprovação contratual — nome legal, e-mail de contacto, identidade de faturação, histórico de pedidos e subscrições, alterações contratuais, aviso de rescisão, correspondência sobre litígios	Duração da sua conta + 3 anos civis após a rescisão (ancorados ao fim do ano)	Art. 6.º, n.º 1, alínea f); § 195 + § 199 Abs. 1 BGB (declaração, exercício e defesa de direitos em processo judicial)
Faturas, registos de pagamento, livros contabilísticos	6 a 10 anos, dependendo do tipo de documento, ancorados ao fim do ano civil — 10 anos para livros, inventários e contas anuais (§ 147 Abs. 1 Nr. 1 AO; § 257 Abs. 1 Nr. 1, Nr. 3 HGB lidos com Abs. 4); 8 anos para documentos contabilísticos e registos de fatura do § 14b UStG (§ 147 Abs. 1 Nr. 4 e Nr. 4a AO pós-Bürokratieentlastungsgesetz IV, em vigor desde 1 de janeiro de 2025; § 257 Abs. 4 HGB pós-BEG IV); 6 anos para correspondência comercial (§ 147 Abs. 1 Nr. 2 e Nr. 3 AO; § 257 Abs. 1 Nr. 2 HGB)	Art. 6.º, n.º 1, alínea c); § 147 AO, § 257 HGB, § 14 UStG
Preferências operacionais — preferências de notificação e comunicação, configurações de UI, filtros guardados, layouts de painel, tokens de integração, chaves de API, ficheiros carregados	Duração da relação contratual	Art. 6.º, n.º 1, alínea b)
Eventos de autenticação e auditoria de segurança — registos de início de sessão, eventos de dois fatores, auditoria de IP, contadores de inícios de sessão falhados	180 dias	Art. 6.º, n.º 1, alínea f); base BSI IT-Grundschutz
Pontuação heurística interna consultiva de risco (descrita no § 3 «Segurança» e § 8 «Limites de taxa anti-abuso e classificação de bots de inscrição») — um único inteiro consultivo por registo de utilizador	Duração da sua conta, recalculado a cada novo sinal de abuso e sobrescrito no local (não é mantida qualquer tabela histórica da pontuação); eliminado com a conta no momento da anonimização de fim de conta, ao abrigo da linha «Dados de conta e de comprovação contratual» supra	Art. 6.º, n.º 1, alínea f) (defesa contra abuso; não é tomada qualquer decisão do Art. 22.º, n.º 1 com base nesta pontuação)
Logs de aplicação e de acesso — tráfego de rotina, logs de erro	30 dias	Art. 6.º, n.º 1, alínea f) (integridade operacional)
Configurações de monitor criadas por si	Duração do monitor	Art. 6.º, n.º 1, alínea b)
Dados de resultados de monitor — uptime, SSL, domínio/WHOIS, velocidade, transação, agregados RUM, vírus/malware, métricas de agente de servidor	Até 13 meses, por nível de plano (ver a matriz de níveis de plano em uptimia.com)	Art. 6.º, n.º 1, alínea b); teto de utilidade para o cliente
Corpos de resposta HTTP de uptime	7 dias (auto-expirados)	Art. 6.º, n.º 1, alínea b) (apenas operacional)
Capturas de ecrã de transações	30 dias	Art. 6.º, n.º 1, alínea f); minimização de dados nos termos do Art. 5.º, n.º 1, alínea c) (dados pessoais podem ser visíveis em ecrãs autenticados)
Correspondência de apoio	Duração do processo de apoio + 3 anos civis (ancorados ao fim do ano)	Art. 6.º, n.º 1, alínea f); § 195 + § 199 BGB
Registos de consentimento de cookies	180 dias para o registo de consentimento + 12 meses de conservação de log de auditoria	Art. 7.º, n.º 1 RGPD (evidência de consentimento)
Cópias de segurança	Janela rotativa de 14 dias	Art. 6.º, n.º 1, alínea f) (recuperação de desastres)

Decorrido o período supra, os dados pessoais são eliminados ou — quando a eliminação prejudicar a integridade da auditoria — anonimizados de forma que a reidentificação deixe de ser razoavelmente possível. A conservação estatutária (a segunda linha supra) prevalece sobre eliminação anterior nos termos do Art. 17.º, n.º 3, alínea b) RGPD.

Comportamento de eliminação de conta (Art. 17.º RGPD). Quando o Cliente elimina a sua conta através das Definições ou por pedido a privacy@uptimia.com, integrações de pagamento, páginas de estado, operadores e sessões ativas são removidas imediatamente; as configurações de monitor e definições de alertas entram na cauda de defesa de pretensões descrita na primeira linha supra; a sua identidade de contacto e comprovação contratual é anonimizada ou eliminada no final dessa cauda, sob reserva da conservação estatutária exigida para faturas e livros contabilísticos. As cópias de segurança expiram conforme a janela rotativa de 14 dias: durante essa janela os dados não são ativamente tratados e existem apenas como um snapshot congelado de recuperação de desastres. A combinação de uma janela rotativa curta, da ausência de tratamento ativo durante essa janela e do passo de re-eliminação na restauração descrito infra é consistente com a prática estabelecida das autoridades de controlo sobre cópias de segurança ao abrigo do Art. 17.º, n.º 1 / n.º 3 RGPD. Mantemos um registo interno de cópias de segurança que documenta os sistemas abrangidos (base de dados aplicacional, base de dados time-series, AWS S3 Frankfurt para capturas de ecrã de transações), a política de rotação, a localização de armazenamento, os controlos de acesso e o runbook de re-eliminação. Se restaurarmos a partir de uma cópia de segurança anterior a um pedido de eliminação, a eliminação original é reaplicada aos dados restaurados nas 72 horas seguintes à conclusão da restauração — e, quando a restauração reponha o sistema online para tratamento ativo, antes de o sistema restaurado ser aberto ao tráfego de utilizadores — para que os dados pessoais eliminados não sejam reintroduzidos no tratamento ativo. As 72 horas são o teto externo de auditoria; em operação normal, o replay da re-eliminação corre como primeiro passo programado após a restauração e conclui-se em minutos, não em horas. O registo de cópias de segurança regista, para cada restauração de produção, (i) a marca temporal de conclusão da restauração, (ii) a marca temporal de conclusão do replay do log de eliminação e (iii) a confirmação de que não foi admitido tráfego de utilizadores ao sistema restaurado entre (i) e (ii).

Dados de visitante tratados ao abrigo do § 7 (papel de subcontratante). Conservados conforme o DPA, em geral conforme instruído pelo Cliente enquanto responsável pelo tratamento. Os valores por defeito correspondem à categoria equivalente supra.

Conversas de apoio alojadas no HelpCanvas. O HelpCanvas é um produto JJ Online que corre na própria infraestrutura UE da JJ Online (§ 5.7) — não é uma plataforma de terceiros — pelo que a JJ Online é o único responsável pelo tratamento para a conversa, independentemente da superfície em que seja lida ou escrita. A conservação segue a linha Correspondência de apoio supra (duração do processo de apoio + 3 anos civis ancorados ao fim do ano; Art. 6.º, n.º 1, alínea f); § 195 + § 199 BGB). Não existe conservação separada de «plataforma de registo» a respeitar.

12. Segurança dos dados

Implementamos medidas técnicas e organizativas adequadas ao abrigo do Art. 32.º RGPD para proteger os seus dados pessoais contra acesso, divulgação, alteração ou destruição não autorizados. Na prática:

TLS 1.2+ para todas as interfaces orientadas ao cliente e todas as comunicações com subcontratantes ulteriores
Controlos de acesso baseados em função que limitam o acesso aos dados pessoais ao pessoal que deles necessita; autenticação multifator para todo o pessoal operacional
Obrigações escritas de confidencialidade do pessoal
Criptografia ao nível do disco em repouso para a base de dados aplicacional e para a base de dados time-series em infraestrutura UE; cópias de segurança encriptadas com chave gerida separadamente
Criptografia ao nível da coluna (envelope) para credenciais e segredos que o Cliente forneça para que o Serviço possa atuar por sua conta — ver o parágrafo dedicado infra; as chaves de API pessoais são armazenadas apenas como hashes unidirecionais
Truncagem de endereços IP para eventos RUM (/24 IPv4, /48 IPv6) antes do armazenamento
Isolamento lógico por utilizador na camada aplicacional
Processo de notificação de violação de dados pessoais em 72 horas nos termos do Art. 33.º RGPD
Análise periódica de vulnerabilidades, monitorização de dependências, revisão de código antes do merge

Credenciais e segredos que o Cliente nos confia. Quando o Cliente fornece credenciais para que o Serviço se autentique nos seus recursos por sua conta — por exemplo, credenciais HTTP Basic, cabeçalhos de pedido personalizados (incluindo bearer tokens e chaves de API), credenciais de integração para canais de alertas e valores literais configurados em passos de monitorização de transação —, essas credenciais são mantidas sob criptografia ao nível da coluna, em adição à criptografia ao nível do disco que se aplica à base de dados como um todo. As chaves de criptografia são geridas separadamente da própria base de dados, pelo que o pessoal operacional com acesso à base de dados não pode ler as credenciais em texto claro. A descriptação ocorre apenas no ponto em que a rede de sondas executa a verificação contra o recurso configurado, e o texto claro é mantido em memória apenas durante a duração dessa única execução de verificação. As chaves de API pessoais que o Cliente cria para acesso programático ao Serviço são armazenadas como hashes unidirecionais; não conservamos uma cópia em texto claro após a emissão — se perder uma chave de API pessoal, terá de a rodar através do painel.

Nenhum método de transmissão pela Internet ou de armazenamento eletrónico é completamente seguro. Se considerar que a sua interação connosco deixou de ser segura, contacte privacy@uptimia.com.

13. Os seus direitos

Enquanto responsável pelo tratamento estabelecido na União Europeia, estamos sujeitos ao RGPD ao abrigo do Art. 3.º, n.º 1 para todo o nosso tratamento, independentemente do local onde o titular dos dados se encontre. Os direitos infra aplicam-se, portanto, a cada pessoa cujos dados pessoais tratamos, não apenas a residentes na UE / EEE / Reino Unido / Suíça.

Tem os seguintes direitos:

Direito de acesso (Art. 15.º RGPD) — solicitar uma cópia dos dados pessoais que conservamos sobre si
Direito de retificação (Art. 16.º RGPD) — solicitar a correção de dados inexatos ou incompletos
Direito ao apagamento (Art. 17.º RGPD) — solicitar a eliminação, sob reserva das exceções no Art. 17.º, n.º 3 (em particular: obrigação legal nos termos do § 147 AO / § 257 HGB para faturas)
Direito à limitação do tratamento (Art. 18.º RGPD)
Direito à portabilidade dos dados (Art. 20.º RGPD) — receber os seus dados num formato estruturado, de uso corrente e de leitura automática
Direito de oposição (Art. 21.º RGPD) — opor-se a tratamento baseado nos nossos interesses legítimos, incluindo definição de perfis; a oposição a marketing direto é incondicional
Direito a não ficar sujeito a decisão automatizada (Art. 22.º RGPD) — existe uma decisão do Art. 22.º, n.º 1 no checkout (análise de fraude de pagamento); o tratamento subjacente assenta principalmente no Art. 6.º, n.º 1, alínea c) RGPD (cumprimento estatutário SCA da DSP2 + AML/CTF) com o Art. 6.º, n.º 1, alínea f) a cobrir o interesse residual do lado do comerciante em prevenção de fraude, e a própria decisão do Art. 22.º, n.º 1 é autorizada pela porta de direito da União autorizador do Art. 22.º, n.º 2, alínea b) RGPD (com o Art. 22.º, n.º 2, alínea a) tratado apenas como fallback). Disponibilizamos as garantias do Art. 22.º, n.º 3 (intervenção humana, expressão de ponto de vista, contestação, mais a divulgação do código de motivo de recusa Stripe Radar e do nome da regra descrita no § 8). Todas as outras atividades automatizadas no § 8 são definição de perfis sem decisão exclusivamente automatizada com efeitos significativos associada. Detalhes no § 8.
Direito de retirar o consentimento (Art. 7.º, n.º 3 RGPD) — quando nos apoiamos no seu consentimento, retirar a qualquer momento sem afetar a licitude do tratamento anterior
Direito de apresentar reclamação (Art. 77.º RGPD) — o Art. 77.º, n.º 1 confere-lhe três foros alternativos: a autoridade de controlo (i) da sua residência habitual, (ii) do seu local de trabalho ou (iii) do local da alegada infração. Ver § 15 infra para as autoridades competentes e o diretório de autoridades de controlo do EEE.

Para exercer qualquer destes direitos, contacte privacy@uptimia.com. Nos termos do Art. 12.º, n.º 3 RGPD responderemos no prazo de um mês a contar da receção de um pedido completo, prorrogável por mais dois meses em casos complexos ou numerosos; quando prorroguemos, informaremos o Cliente da prorrogação e do motivo no primeiro mês, conforme o Art. 12.º, n.º 3 exige.

Vias operacionais de cumprimento.

Direito de acesso (Art. 15.º RGPD) e direito à portabilidade dos dados (Art. 20.º RGPD) — exportação de dados de conta. Até estar disponível self-service, a exportação é gerada e devolvida manualmente mediante pedido por e-mail a privacy@uptimia.com. Internamente mantemos um procedimento operacional padrão SAR (Subject Access Request) por escrito que tem como meta um tempo de entrega útil de cinco (5) a dez (10) dias úteis para uma conta normal, bem dentro do teto estatutário de um mês do Art. 12.º, n.º 3. A exportação é entregue como um único arquivo ZIP contendo ficheiros JSON estruturados por categoria de dados — perfil de conta, histórico de faturação, configurações de monitor (credenciais mostradas como impressões digitais unidirecionais, nunca em texto claro; ver § 12), resumos de resultados de verificações, índice de correspondência de apoio, registo de consentimento de cookies — através de uma hiperligação de descarregamento com tempo limitado. Um endpoint self-service /api/v1/me/export está no roadmap do produto; até ser lançado, o SOP manual é a garantia operacional.
Direito ao apagamento (Art. 17.º RGPD). A eliminação de conta é self-service a partir da página de Definições (com confirmação por palavra-passe) e dispara o cron de purga descrito no § 11; os registos fiscais e contabilísticos sobrevivem conforme § 11 / § 147 AO / § 257 HGB. Quando preferir tratamento humano, escreva para privacy@uptimia.com.
Direito de retificação (Art. 16.º RGPD). A maioria dos campos da conta são editáveis pelo utilizador na página de Definições; para campos que não são editáveis pelo utilizador (p. ex. nome de faturação em documentos fiscais já emitidos), envie e-mail para privacy@uptimia.com.
Direito à limitação (Art. 18.º RGPD) e direito de oposição (Art. 21.º RGPD). Envie e-mail para privacy@uptimia.com identificando o tratamento que pretende limitar ou ao qual se opõe. A oposição a marketing direto é processada na receção sem fundamentação adicional (Art. 21.º, n.ºs 2 e 3 RGPD).
Direito de retirar o consentimento (Art. 7.º, n.º 3 RGPD). Para cookies, ver § 9 (hiperligação Preferências de Cookies, único percurso de paridade conforme Orientações 05/2020 do CEPD parágrafo 117). Para qualquer outro tratamento baseado em consentimento, envie e-mail para privacy@uptimia.com.

Todos os pedidos são tratados gratuitamente. Quando um pedido seja manifestamente infundado ou excessivo, podemos cobrar uma taxa administrativa razoável ou recusar atuar nos termos do Art. 12.º, n.º 5 RGPD.

Verificação de identidade. A nossa abordagem de verificação de identidade é proporcionada ao pedido, conforme exigido pelo Art. 12.º, n.º 6 RGPD e pelas Orientações 01/2022 do CEPD sobre direitos dos titulares dos dados — Direito de acesso (parágrafo 64 e segs.). No caso normal, verificamos a identidade fazendo correspondência entre o endereço de remetente do seu pedido e o endereço de e-mail constante na sua conta Uptimia e, para ações tomadas a partir do interior da aplicação, apoiando-nos na sua sessão autenticada (palavra-passe + 2FA quando ativada). Quando essa correspondência seja suficiente para afastar a dúvida razoável, não solicitamos informação adicional — pedir documentos de identidade em cada pedido de rotina violaria, ele próprio, o princípio de minimização dos dados do Art. 5.º, n.º 1, alínea c) RGPD. Quando exista dúvida razoável e específica nos termos do Art. 12.º, n.º 6 RGPD — por exemplo, quando o pedido chega de um endereço diferente do constante em ficha, quando a conta mudou recentemente de mãos ou teve o e-mail de contacto atualizado, quando o pedido respeite a categorias sensíveis como logs de autenticação ou sinais de fraude de pagamento, ou quando a ação solicitada seja irreversível (exportação total de dados, eliminação de conta) — podemos aplicar uma ou mais verificações adicionais proporcionadas: confirmação a partir do endereço de e-mail registado, conclusão de uma ação a partir do painel autenticado, ou um código único entregue através do seu canal 2FA configurado. Não pedimos documentos de identificação emitidos pelo governo, cópias de documentos de identidade ou verificação por «selfie» — tais medidas seriam desproporcionadas para um produto de observabilidade B2B cuja ligação à conta é um endereço de e-mail, não uma identidade no mundo real, e são inconsistentes com a cautela das Orientações 01/2022 do CEPD parágrafo 73 contra a recolha rotineira de documentos de identidade. Se, após verificações proporcionadas, persistir dúvida razoável sobre a sua identidade, solicitaremos, em conformidade com o Art. 12.º, n.º 6 RGPD, a informação adicional mínima estritamente necessária para resolver essa dúvida, e dir-lhe-emos exatamente o que pedimos e porquê.

14. Privacidade das crianças

O Serviço não é dirigido a crianças com menos de 16 anos, e não recolhemos conscientemente dados pessoais de crianças com menos de 16 anos. Se tomarmos conhecimento de que recolhemos dados pessoais de uma criança com menos de 16 anos sem o consentimento verificável dos pais, eliminá-los-emos o mais rapidamente possível.

Aplicamos 16 anos como o nosso piso global para tratamento baseado em consentimento, independentemente de qualquer limiar nacional inferior ao abrigo do Art. 8.º, n.º 1 RGPD — e estamos cientes de que vários Estados-Membros exerceram a Wahlrecht do Art. 8.º, n.º 1 em sentido descendente, incluindo Espanha em 14, França em 15 e Itália em 14. O piso «16 globalmente» é, portanto, um padrão deliberado e auto-imposto que é mais protetor do que os limiares nacionais mais baixos aplicáveis nesses mercados, e aceitamos que, como matéria de política, somos auditáveis face a ele: se alguma vez começarmos a dirigir-nos diretamente a um desses mercados com limiar inferior, continuaremos a aplicar o piso de 16 em vez de descer para o mínimo nacional, e qualquer alteração a essa postura seria, ela própria, uma alteração material à presente Política a divulgar nos termos do § 17. A nossa abordagem de verificação é proporcionada a um serviço que não é dirigido a crianças, no sentido contemplado pelo Art. 8.º, n.º 2 RGPD. Não recolhemos data de nascimento na inscrição — a Uptimia é um produto de observabilidade business-to-business, a superfície de inscrição é orientada a administradores técnicos (nomes de servidores, URLs de monitor, canais de alertas), e pedir data de nascimento a cada titular de conta criaria, ela própria, um problema de minimização de dados desproporcionado ao risco. Em vez disso, apoiamo-nos na combinação de: (i) o Serviço não é dirigido a crianças, comercializado para crianças, nem concebido para crianças; (ii) os titulares de conta auto-identificam-se como utilizadores profissionais pelo ato de configurar monitores, aceitar subscrições pagas ou assinar os Termos de Serviço; (iii) quando, à face de uma conta ou de uma interação de apoio, exista dúvida razoável de que um titular de conta tem menos de 16 anos — por exemplo, correspondência de apoio que indique afirmativamente que a conta é operada por um menor — pedimos ao titular da conta que confirme por escrito que tem 16 anos ou mais, e eliminamos a conta caso a confirmação não seja apresentada. Este é o modelo «serviço não dirigido a crianças, com eliminação por dúvida razoável» que a linguagem de proporcionalidade do Art. 8.º, n.º 2 RGPD contempla para serviços B2B.

Quando o Cliente implementa o nosso script RUM num sítio Web dirigido a crianças, essa é uma decisão sua nos termos do Art. 8.º RGPD e da sua exclusiva responsabilidade enquanto responsável pelo tratamento.

Pais ou tutores que considerem que uma criança submeteu dados pessoais podem contactar privacy@uptimia.com para eliminação imediata.

15. Regimes aplicáveis, autoridade de controlo principal e transferências transfronteiriças

Regimes aplicáveis

RGPD da UE. Enquanto responsável pelo tratamento estabelecido na Alemanha, o Regulamento (UE) 2016/679 aplica-se ao abrigo do Art. 3.º, n.º 1 a todo o nosso tratamento, independentemente do local em que o titular dos dados se encontre.
UK GDPR. Não dirigimos o nosso Serviço a titulares de dados no Reino Unido. A análise de âmbito territorial das Orientações 3/2018 do CEPD parágrafo 2.1 / parágrafo 2.2 assenta numa leitura cumulativa dos marcadores enunciados — moeda, domínio de topo, língua como sinal de país, menção a clientes locais, campanhas de marketing específicas para o país, telefone ou morada local dedicados, condições de entrega — e a conclusão é alcançada analisando os marcadores em conjunto, não excluindo qualquer marcador individualmente. Numa leitura cumulativa desses fatores, nenhum aponta para o Reino Unido: os nossos preços são listados em EUR (e, quando aplicável, em USD), não em GBP; o nosso domínio é uptimia.com sem qualquer superfície .co.uk; não publicamos landing pages para o Reino Unido, case studies do Reino Unido, testemunhos de clientes residentes no Reino Unido, campanhas de marketing específicas para o Reino Unido, nem publicidade com geo-targeting para o Reino Unido; não corremos SEO em língua do Reino Unido nem produção de conteúdos visando o Reino Unido; e o Website é publicado em inglês porque o inglês é a língua controlante da nossa documentação e do produto (o inglês, na análise das Orientações 3/2018, não é um sinal de país quando não emparelhado com nenhum dos outros marcadores supra). Com base nesses factos, consideramos que o UK GDPR Art. 3 (2)(a) não é acionado: os titulares de dados do Reino Unido que se inscrevem no Serviço fazem-no por chegarem a uptimia.com através de pesquisa orgânica em língua inglesa e não porque lhes tenhamos oferecido o Serviço no Reino Unido na aceção do UK GDPR Art. 3 (2)(a). Também não «monitorizamos o comportamento» de titulares de dados do Reino Unido na aceção do UK GDPR Art. 3 (2)(b) — o script RUM que o Responsável pelo tratamento implementa corre nos próprios visitantes do Responsável nos próprios sítios Web do Responsável e é tratado conforme as instruções do Responsável, não dirigido por nós a qualquer população do Reino Unido. Caso o UK GDPR Art. 3 (2) fosse, ainda assim, considerado aplicável a inscrições incidentais do Reino Unido, o nosso tratamento também satisfaz a isenção do UK GDPR Art. 27 (2)(a) como ocasional (sem operações estruturadas no Reino Unido, sem atividade de aquisição no Reino Unido, sem motion de customer-success no Reino Unido) e de baixo risco (sem dados de categoria especial, sem perfilagem em larga escala, sem monitorização em larga escala de titulares de dados do Reino Unido). Reavaliaremos esta posição e nomearemos um representante no Reino Unido se começarmos a dirigir-nos ao Reino Unido — por exemplo, acrescentando preços em GBP, um domínio ou subdiretório .co.uk, case studies ou testemunhos do Reino Unido, landing pages ou páginas de comparação específicas do Reino Unido, aquisição paga com geo-targeting para o Reino Unido, ou produção de conteúdos em língua do Reino Unido. Os titulares de dados do Reino Unido que interajam com o Serviço conservam o seu direito legal de apresentar reclamação ao Information Commissioner's Office (ICO) em https://ico.org.uk ao abrigo do UK GDPR Art. 77; cooperaremos com qualquer inquérito do ICO no seu mérito, independentemente da nossa posição quanto ao âmbito territorial.
Outras jurisdições (CCPA / CPRA, LGPD, PIPL, e regimes extraterritoriais semelhantes). Não tratamos atualmente dados pessoais de consumidores da Califórnia, de titulares de dados brasileiros, de titulares de dados chineses ou de outros titulares de dados não-EEE / não-Reino Unido / não-Suíça numa escala ou configuração que acione os limiares de aplicação extraterritorial do California Consumer Privacy Act (conforme alterado pelo California Privacy Rights Act), da Lei Geral de Proteção de Dados brasileira (LGPD), da Lei chinesa de Proteção de Informações Pessoais (PIPL) ou de regimes de privacidade não-UE comparáveis. Em particular, estamos abaixo dos limiares de receita US e de consumidores da Califórnia para a aplicabilidade do CCPA / CPRA nos termos do Cal. Civ. Code § 1798.140(d). Monitorizamos a nossa exposição ao abrigo de cada um destes regimes à medida que a nossa base de clientes evolui e atualizaremos esta Política e nomearemos representantes locais ou agentes designados (p. ex., um verified-request agent dos EUA ao abrigo do § 999.312 CCPA Regulations; um encarregado (DPO) ao abrigo do Art. 41.º LGPD — notando que a própria LGPD não contém um equivalente ao Art. 27.º RGPD e qualquer obrigação de representação local no Brasil surgiria separadamente do direito societário brasileiro (em particular o Art. 1.134 do Código Civil brasileiro e o Art. 146, § 2.º, da Lei 6.404/1976), e não da LGPD enquanto tal; um representante local PIPL ao abrigo do Art. 53.º PIPL) se e quando os limiares forem cruzados.
FADP suíça. Aplica-se ao abrigo do Art. 3.º, n.º 1 FADP quando as nossas atividades produzam efeitos na Suíça. A análise de targeting aqui espelha a disciplina de leitura cumulativa aplicada supra para o Reino Unido: a questão é se os fatores marcadores de país enunciados, tomados em conjunto, apontam para a Suíça — não se cada fator individual pode ser excluído por si só. Numa leitura cumulativa, nenhum o faz: não operamos qualquer domínio .ch, sem preços em CHF, sem landing pages suíças e sem campanhas dirigidas à Suíça; e o Website é publicado em inglês, não como sinal de país suíço, mas como a nossa língua de documentação controlante. O Art. 14.º, n.º 1 FADP exige que um responsável pelo tratamento privado domiciliado no estrangeiro designe um representante na Suíça quando trate dados pessoais de pessoas na Suíça e o tratamento satisfaça cumulativamente quatro condições: (a) o tratamento esteja relacionado com a oferta de bens ou serviços ou com a monitorização do comportamento dessas pessoas; (b) seja extensivo (em larga escala); (c) seja regular; e (d) coloque um risco elevado para a personalidade dos titulares dos dados (hohes Risiko für die Persönlichkeit der betroffenen Personen). O limiar não é cumprido nos nossos factos: os titulares de dados suíços que se inscrevem no Serviço chegam a uptimia.com através de pesquisa orgânica em língua inglesa, incidental às nossas operações na UE, não através de uma oferta suíça por nós — pelo que a condição a) não é acionada — e o volume não é nem extensivo dentro da condição b) nem regular dentro da condição c) tal como esses termos são entendidos na orientação FDPIC; também não consideramos que a condição d) seja cumprida, dado que o Serviço não coloca, sobre os factos do nosso tratamento suíço típico incidental, um risco elevado para a personalidade dos titulares dos dados. O incumprimento de qualquer uma das quatro condições cumulativas é, por si só, suficiente; nos nossos factos, as condições a) a d) falham, cada uma, independentemente. (Note-se que risco elevado é tanto a condição de nomeação de representante do Art. 14.º, n.º 1, alínea d) como, separadamente, o gatilho para uma Avaliação de Impacto sobre a Proteção de Dados ao abrigo do Art. 22.º FADP — são obrigações independentes ligadas ao mesmo elemento factual, e tratamos a análise de AIPD do Art. 22.º FADP separadamente.) Reavaliaremos e nomearemos um representante suíço se começarmos a dirigir-nos à Suíça (uma superfície .ch, preços em CHF, case studies suíços, publicidade dirigida à Suíça) ou se o nosso tratamento suíço se tornar em larga escala e regular.

Autoridade de controlo principal

A nossa autoridade de controlo principal ao abrigo do mecanismo balcão único do RGPD é a Berliner Beauftragte für Datenschutz und Informationsfreiheit (BlnBDI):

Alt-Moabit 59-61 10555 Berlim, Alemanha Sítio Web: https://www.datenschutz-berlin.de

Os residentes no EEE podem reclamar, à sua escolha ao abrigo do Art. 77.º, n.º 1 RGPD, à autoridade de controlo (i) da sua residência habitual, (ii) do seu local de trabalho ou (iii) do local da alegada infração — ou diretamente à BlnBDI enquanto autoridade principal. O diretório de autoridades de controlo do EEE encontra-se em https://edpb.europa.eu. Os residentes no Reino Unido podem reclamar ao Information Commissioner's Office (ICO) em ico.org.uk ao abrigo do UK GDPR Art. 77. Os residentes na Suíça podem notificar o Federal Data Protection and Information Commissioner (FDPIC / EDÖB) em edoeb.admin.ch ao abrigo do Art. 49.º FADP.

Resumo da avaliação de interesses legítimos

Para cada finalidade assente no Art. 6.º, n.º 1, alínea f):

Sinais de segurança da conta (o seu IP de registo, o seu IP de início de sessão mais recente, o seu contador de inícios de sessão falhados, o seu log de auditoria de autenticação de dois fatores e uma pontuação heurística interna de risco) — o nosso interesse em proteger a sua conta contra credential stuffing, ataques de força bruta e abuso na inscrição, ponderado contra a natureza limitada e ligada à conta dos sinais; os interesses do titular dos dados são protegidos por controlos de acesso e pelo facto de os dados estarem ligados a uma relação contratual.
Melhoria do serviço e operações da rede de sondas — apenas tratamento pseudonimizado ou agregado; sem perfilagem individual.
Monitorização agregada de qualidade de medição do lado do servidor — sem identificação individual.
Comunicações de atualização de produto a titulares de conta existentes (§ 7 Abs. 3 UWG Bestandskundenwerbung) — o nosso interesse de retenção em manter clientes pagantes informados das alterações de produto que afetam o que adquiriram, ponderado contra o ónus de marketing imposto ao destinatário. O cumprimento das quatro condições cumulativas do § 7 Abs. 3 UWG é tratado como principal garantia: (i) endereço recolhido no contexto da venda dos nossos bens ou serviços; (ii) conteúdo limitado a marketing direto dos nossos próprios produtos e serviços semelhantes; (iii) o destinatário não se opôs; e (iv) o destinatário foi clara e visivelmente informado (klar und deutlich) do direito de oposição tanto no momento da recolha como em cada mensagem subsequente, sem custos para além das tarifas básicas de transmissão (Basistarif). A oposição ao abrigo do Art. 21.º RGPD é incondicional e processada na receção sem fundamentação adicional.
Respostas a pedidos de não clientes — responder a pedidos de entrada de visitantes que nos contactam (questões comerciais, pedidos de parceria, questões de apoio fora de uma conta ativa) assenta na expectativa razoável de que responderemos ao endereço que usaram para nos escrever.

Uma AIL completa para qualquer destas atividades está disponível mediante pedido em privacy@uptimia.com.

Decisões automatizadas (Art. 22.º RGPD)

Uma decisão automatizada no âmbito do Art. 22.º, n.º 1 RGPD opera no ponto da análise de fraude de pagamento no checkout, descrita no § 8. A porta do Art. 22.º, n.º 2 que invocamos é principalmente o Art. 22.º, n.º 2, alínea b) RGPD — o quadro SCA da DSP2 (Diretiva (UE) 2015/2366 lida com o Regulamento Delegado (UE) 2018/389 da Comissão) e o quadro AML/CTF citado no § 8 constituem direito da União autorizador que exige as próprias decisões de monitorização de transações tomadas no checkout e que estabelece, ele próprio, garantias adequadas para o titular dos dados; o Art. 22.º, n.º 2, alínea a) RGPD (necessidade contratual) é acionado apenas como fallback, em consonância com a leitura estrita do CEPD sobre «necessário para o contrato». Disponibilizamos as garantias do Art. 22.º, n.º 3 RGPD em pleno: um direito significativo a intervenção humana pela equipa de revisão manual do processador de pagamentos e pela nossa operação de faturação, um direito a expressar o seu ponto de vista, um direito a contestar o resultado e — acrescentado em 2026-05-27 — divulgação mediante pedido nos termos do Art. 22.º, n.º 3 do código específico de motivo de recusa e, quando aplicável, do nome da regra Stripe Radar (ver § 8 quarta marca do Art. 22.º, n.º 3). O contacto para qualquer pedido desse tipo é privacy@uptimia.com; respondemos no prazo do Art. 12.º, n.º 3 RGPD. A pontuação heurística interna no seu registo de utilizador descrita no § 8 é um input consultivo para revisão humana, não uma decisão automatizada.

Notificação de violação de dados pessoais (Art. 33.º a 34.º RGPD)

Em caso de violação de dados pessoais suscetível de implicar um risco para os seus direitos e liberdades, notificaremos a BlnBDI sem demora injustificada e, sempre que possível, no prazo de 72 horas após termos tomado conhecimento da violação (Art. 33.º RGPD). Quando a violação seja suscetível de implicar um risco elevado, notificaremos também os utilizadores afetados sem demora injustificada ao abrigo do Art. 34.º RGPD.

Mecanismo de notificação. E-mail direto para o endereço registado na sua conta, com uma linha de assunto que identifique a mensagem como notificação de violação de dados pessoais nos termos do Art. 34.º RGPD. Apresentamos adicionalmente um aviso in-product no painel autenticado na sua próxima sessão. Quando a notificação direta envolva um esforço desproporcionado ao abrigo do Art. 34.º, n.º 3, alínea c), emitimos uma comunicação pública no Website.

Transferências internacionais de dados

Transferimos dados pessoais para destinatários fora do EEE apenas como parte da operação normal dos serviços de terceiros listados nos § 5 e § 7. Estão envolvidos os seguintes destinos não-EEE:

Destino	Destinatário(s)	Mecanismo
EUA	Stripe, Inc. (subcontratação ulterior Stripe); PayPal, Inc. (subcontratação ulterior PayPal); Amazon Web Services, Inc. (SES destinatários não-UE, rede de sondas regiões não-UE); DigitalOcean, LLC (rede de sondas); Akamai Technologies, Inc. (rede de sondas); Vultr Holdings, LLC (rede de sondas); Contabo GmbH (rede de sondas — regiões de sondas localizadas nos EUA; entidade contratante é a Contabo GmbH em Munique, tratamento ocorre fisicamente na infraestrutura US da Contabo); Okta, Inc. (subcontratação ulterior Auth0); GitHub, Inc. (ligação social Auth0); Google LLC (subcontratação ulterior Web Risk, PageSpeed; ligação social Auth0); Mattermost, Inc. (alertas, se configurado); PagerDuty, Inc. (alertas, se configurado); Microsoft Corporation (subcontratação ulterior alertas Teams, se configurado); Slack Technologies, LLC (Grupo Salesforce) (subcontratação ulterior alertas Slack, se configurado); Discord, Inc. (subcontratação ulterior alertas Discord, se configurado); X Corp. (alertas X, se configurado); Twilio, Inc. (subcontratação ulterior SMS); Meta Platforms, Inc. (subcontratação ulterior WhatsApp Cloud)	EU–US Data Privacy Framework (Decisão de Execução (UE) 2023/1795) quando o destinatário esteja certificado DPF, com SCCs (Decisão de Execução (UE) 2021/914) mantidas como recurso automático. A Vultr não está certificada DPF — SCCs + a propriedade de tratamento efémero na camada de sondas (ver § 5.3) são as medidas suplementares invocadas. A Contabo é contratada através da sua entidade UE (Contabo GmbH, Munique), pelo que a análise SCC aplica-se ao vetor de tratamento físico em regiões não-UE da Contabo; a mesma propriedade de tratamento efémero na camada de sondas (Anexo B.6 do DPA) é a medida suplementar invocada para regiões não-UE da Contabo. A X Corp. não está atualmente certificada DPF — SCCs + medidas suplementares; ativada apenas se o Cliente configurar X como canal de alertas.
EAU	Telegram FZ-LLC (alertas, apenas se o Cliente configurar Telegram)	Sem decisão de adequação para os EAU, e a Telegram FZ-LLC não oferece um mecanismo de transferência standard do Art. 46.º RGPD (sem oferta SCC publicada, sem template DPA, sem materiais de impacto de transferência). Apoiamo-nos, portanto, enquanto responsável pelo tratamento que inicia a transferência quando um alerta despacha, na derrogação do Art. 49.º, n.º 1, alínea b) RGPD — a transferência é necessária para a execução do contrato entre o Cliente (titular da conta, enquanto titular dos dados) e a Uptimia: ao configurar o Telegram como o seu canal de entrega de alertas escolhido nas definições de canal de alertas, o Cliente tornou a entrega do alerta para o seu chat Telegram um elemento objetivamente necessário do serviço de monitorização que contratou. A base do Art. 49.º, n.º 1, alínea b) abrange os próprios dados pessoais do titular da conta (o seu user-ID Telegram, o ID de canal do bot que forneceu, o payload do alerta dirigido ao Cliente). Quando o Cliente quiser encaminhar alertas para um grupo ou canal Telegram que inclua destinatários que não são partes no seu contrato Uptimia, esses destinatários estão fora do âmbito da base do Art. 49.º, n.º 1, alínea b) — utilize um acordo responsável-a-responsável da sua autoria (p. ex. obtenha consentimento explícito do Art. 49.º, n.º 1, alínea a) desses destinatários antes de os adicionar, ou encaminhe o alerta através de um intermediário com quem tenham uma relação estabelecida), e não se apoie na cobertura do Art. 49.º, n.º 1, alínea b) da Uptimia para esse vetor. As medidas suplementares que aplicamos do nosso lado são encriptação em trânsito (HTTPS para a Telegram Bot API), minimização do payload (o evento do alerta contém apenas metadados do incidente — nome do monitor, alteração de estado, marca temporal; não transmitimos dados pessoais de utilizadores finais do Cliente), e o canal é opt-in (ativável, desativável). Em consonância com as Orientações 2/2018 do CEPD sobre derrogações do Art. 49.º parte III, tratamos a invocação do Art. 49.º, n.º 1, alínea b) como ocasional e necessária: só é acionada em contas que tenham afirmativamente configurado Telegram, os dados transferidos são minimizados ao estritamente exigido para a entrega de alertas e reconsideraremos a base se os alertas Telegram se tornarem um fluxo estruturalmente repetitivo para uma dada conta além do exigido para cumprir o seu contrato. Recomendado apenas para paging da equipa de operações; não programe dados pessoais de utilizadores finais em payloads de alerta Telegram.
Austrália (com tratamento subsequente nos EUA)	Atlassian Pty Ltd (alertas Statuspage e páginas de estado públicas, apenas se o Cliente configurar Statuspage como canal de alertas ou superfície de página de estado)	Sem decisão de adequação para a Austrália. O Statuspage é operado pela Atlassian em infraestrutura US (AWS), pelo que uma transferência para os EUA surge em paralelo com a transferência para a parte contratante na Austrália. Apoiamo-nos no Data Processing Addendum publicado da Atlassian e nas SCCs da UE (Decisão de Execução (UE) 2021/914) que cobrem os fluxos do responsável pelo tratamento australiano e do subcontratante ulterior US, em conjunto com a lista de Sub-Processors da Atlassian (que monitorizamos em cada revisão da política) para a cadeia subsequente. Medidas suplementares: TLS 1.2+ em cada evento de alerta / página de estado de saída, minimização do payload do alerta/página de estado a metadados do incidente (um alerta ou postagem de estado é estado, timing e resumo do incidente; nenhum dado pessoal de utilizador final é exigido num evento Statuspage) e o canal / superfície de página de estado é ativado apenas conforme a configuração do Cliente. O Cliente suporta a avaliação de risco do lado do responsável pelo tratamento por escolher o Statuspage como canal de alertas ou superfície de estado pública.

Para o regime paralelo UK GDPR, aplicamos o UK International Data Transfer Agreement e o UK Addendum às SCCs da UE (ICO, março de 2022) para clientes incidentais do Reino Unido. Para o regime FADP suíço, aplicamos as SCCs da UE aprovadas pelo FDPIC com a adenda específica suíça.

Mantemos em ficheiro uma Avaliação de Impacto de Transferência por destinatário para cada destinatário US e para a linha Atlassian (Austrália + transferência subsequente para os EUA). Cópias disponíveis em privacy@uptimia.com. A linha Telegram (EAU) não assenta no Art. 46.º RGPD — assenta antes na derrogação do Art. 49.º, n.º 1, alínea b) RGPD, com o âmbito operacional estabelecido na tabela supra. A invocação do Art. 49.º é registada numa entrada do Art. 30.º, n.º 1, alínea e) RGPD no nosso registo das atividades de tratamento (conta a conta, já que a base só é acionada em contas que tenham afirmativamente configurado o canal) em vez de num TIA de mecanismo de transferência, que é o formato das Orientações 2/2018 do CEPD para invocação do Art. 49.º.

Versionamento do estatuto DPF. O estatuto de certificação DPF de cada destinatário US identificado supra é verificado à data «Última atualização:» no topo desta Política. As certificações DPF podem ser concedidas, suspensas ou retiradas entre revisões da política — a X Corp., por exemplo, apareceu e desapareceu da lista ativa mais de uma vez desde a entrada em vigor do quadro ao abrigo da Decisão de Execução (UE) 2023/1795. Reverificamos a lista DPF em cada revisão da política; entretanto, as SCCs (Decisão de Execução (UE) 2021/914) são mantidas como recurso automático para cada destinatário US, independentemente do estatuto DPF atual, de modo a que nenhuma transferência dependa exclusivamente de um estatuto que não tenhamos acabado de reverificar. O módulo SCC selecionado por destinatário, as medidas suplementares e as cópias da Avaliação de Impacto de Transferência por destinatário são controlados por versão internamente e reemitidos sempre que os factos subjacentes mudem.

Mecanismos de resolução de litígios DPF — os seus direitos contra o destinatário. Os destinatários certificados ao abrigo do EU–US Data Privacy Framework estão obrigados, como condição da certificação, a cumprir os Princípios DPF, a disponibilizar um mecanismo de recurso independente sem custos para o titular dos dados (cada organização certificada designa um — tipicamente TRUSTe, BBB EU Privacy Shield, JAMS, AAA-ICDR, o painel das autoridades de proteção de dados da UE para dados de RH, ou outro prestador aprovado) e, como opção vinculativa de último recurso, a participar em arbitragem vinculativa perante o Painel DPF ao abrigo do Anexo I aos Princípios DPF. Estão sujeitos aos poderes de investigação e execução da US Federal Trade Commission (ou, para certos setores, o US Department of Transportation) e à supervisão do US Department of Commerce. O Cliente pode invocar diretamente estas vias contra o destinatário certificado se considerar que esse destinatário violou os seus compromissos DPF relativamente aos seus dados pessoais — tipicamente apresentando primeiro uma reclamação ao destinatário, escalando depois para o mecanismo de recurso independente designado no registo de certificação DPF do destinatário em https://www.dataprivacyframework.gov e, em última instância, remetendo o assunto para a FTC ou invocando arbitragem do Painel DPF. O destinatário é obrigado a identificar o mecanismo de recurso independente aplicável no seu próprio aviso de privacidade e na sua entrada de certificação DPF em dataprivacyframework.gov; recomendamos que consulte a entrada de certificação do destinatário para a designação atual. Nada neste parágrafo afasta o seu direito de apresentar reclamação à autoridade de controlo UE/EEE competente ao abrigo do Art. 77.º RGPD ou de exercer recursos judiciais ao abrigo dos Artt. 78.º a 79.º RGPD — esses recursos permanecem disponíveis em paralelo com as vias DPF.

Encarregado da proteção de dados

Avaliámos os critérios do Art. 37.º, n.º 1 RGPD e do § 38 Abs. 1 BDSG. O § 38 Abs. 1 BDSG exige a designação de EPD em três bases independentes: (a) a base do número de funcionários — 20 ou mais pessoas permanentemente ocupadas com o tratamento automatizado de dados pessoais (limiar elevado de 10 para 20 pela 2. DSAnpUG-EU de 20 de novembro de 2019, em vigor desde 26 de novembro de 2019); (b) a base AIPD — tratamento sujeito a uma avaliação de impacto sobre a proteção de dados ao abrigo do Art. 35.º RGPD, independentemente do número de funcionários; e (c) a base de transferência comercial ou de investigação — tratamento comercial de dados pessoais para fins de transferência, transferência anonimizada, ou investigação de mercado ou de opinião, novamente independentemente do número de funcionários. Não cumprimos nenhuma das três bases. Em (a), não cumprimos o limiar de 20 pessoas. Em (b), o nosso tratamento não está sujeito a uma AIPD: não consta da lista do Art. 35.º, n.º 4 da BlnBDI de operações de tratamento que exigem AIPD, e a nossa própria autoavaliação ao abrigo do Art. 35.º, n.º 1 — pequeno serviço B2B de observabilidade, sem dados de categoria especial como atividade nuclear, sem monitorização sistemática em larga escala de pessoas singulares na sua vida privada, sem decisões automatizadas com efeitos jurídicos ou similarmente significativos fora do estreito fluxo de fraude de pagamento descrito no § 8 (que é, ele próprio, autorizado pela porta de direito da União autorizador do Art. 22.º, n.º 2, alínea b), com o Art. 22.º, n.º 2, alínea a) como fallback apenas) — conclui que nenhuma operação de tratamento individual atinge o gatilho «suscetível de implicar um risco elevado» do Art. 35.º, n.º 1. Em (c), não tratamos comercialmente dados pessoais para fins de transferência a terceiros, transferência anonimizada, ou investigação de mercado ou de opinião; o Serviço é uma ferramenta de observabilidade paga, não um negócio de data-broker, de aluguer de listas ou de painéis de investigação. Não estamos, portanto, obrigados a designar um EPD. Os assuntos relativos ao nosso tratamento de dados pessoais podem ser dirigidos a privacy@uptimia.com; Andrius Gecius (Geschäftsführer) é o ponto de contacto responsável.

16. Hiperligações para outros sítios Web

O Serviço pode conter hiperligações para sítios Web de terceiros. Não temos qualquer controlo sobre, nem aceitamos qualquer responsabilidade por, as práticas de privacidade ou o conteúdo desses sítios Web. Encorajamo-lo a ler a política de privacidade de qualquer sítio Web que visite.

17. Alterações a esta política

Podemos atualizar esta Política de Privacidade de tempos em tempos. Quando o fizermos, atualizaremos a data «Última atualização:» no topo deste documento e atualizaremos a versão. Para alterações materiais — em particular qualquer alteração que afete a base jurídica para o tratamento, as categorias de destinatários dos seus dados pessoais ou as transferências internacionais — daremos aviso prévio destacado (por exemplo, uma notificação por e-mail) com pelo menos 30 dias de antecedência relativamente à entrada em vigor da alteração.

Não perde quaisquer direitos, nem concede quaisquer novos direitos, por continuar a utilizar o Serviço.

18. Contacte-nos

Para questões, preocupações ou para exercer os seus direitos ao abrigo desta política, contacte o responsável pelo tratamento identificado no § 2:

JJ Online GmbH (que opera a Uptimia)

Schönhauser Allee 163, 10435 Berlim

Alemanha

Telefone: +49 151 12032902

E-mail — geral: admin@uptimia.com

E-mail — privacidade e pedidos do titular dos dados: privacy@uptimia.com

Para matérias relativas ao papel de subcontratante (dados dos seus visitantes / utilizadores finais que fluam através da Uptimia), ver o DPA.

#1. Introdução

#2. Responsável pelo tratamento

#3. Informação que recolhemos

#Dados da conta

#Dados de faturação

#Dados de autenticação e de sessão

#Configurações de monitor criadas por si

#Resultados das verificações

#Configurações de canais de notificação

#Dados de apoio

#Metadados de pedido do lado do servidor lidos em cada pedido

#Se a prestação desta informação é obrigatória (Art. 13.º, n.º 2, alínea e) RGPD)

#Categorias especiais de dados pessoais (Art. 9.º RGPD)

#4. Como utilizamos a sua informação

#5. Serviços de terceiros que utilizamos enquanto responsável pelo tratamento

#5.1 Pagamentos e faturação

#5.2 Hospedagem e infraestrutura central

#5.3 Rede de sondas

#5.4 Autenticação

#5.5 Segurança e inteligência de ameaças

#5.6 Integrações da página de marketing

#5.7 Serviços internos JJ Online entre produtos (mesmo responsável pelo tratamento — não Subcontratantes ulteriores do Art. 28.º)

#6. Outros destinatários — fiscal, auditoria, jurídico, M&A e pedidos lícitos

#7. Uptimia como subcontratante para dados dos seus visitantes / utilizadores finais

#8. Definição de perfis e decisões automatizadas

#9. Consentimento de cookies — dar e retirar

#10. Cookies

#11. Conservação dos dados

#12. Segurança dos dados

#13. Os seus direitos

#14. Privacidade das crianças

#15. Regimes aplicáveis, autoridade de controlo principal e transferências transfronteiriças

#Regimes aplicáveis

#Autoridade de controlo principal

#Resumo da avaliação de interesses legítimos

#Decisões automatizadas (Art. 22.º RGPD)

#Notificação de violação de dados pessoais (Art. 33.º a 34.º RGPD)

#Transferências internacionais de dados

#Encarregado da proteção de dados

#16. Hiperligações para outros sítios Web

#17. Alterações a esta política

#18. Contacte-nos