Registo das Atividades de Tratamento (Art. 30 do RGPD)

Este documento é publicado em várias línguas. Em caso de divergência entre as versões linguísticas, prevalece a versão polaca.

Versão 1.2 · Última atualização: 29 de outubro de 2026

1. Como ler este registo

Este é o registo das atividades de tratamento nos termos do Art. 30 do RGPD para o formexposed. Não é uma política de privacidade nem material de marketing. A sua função é mostrar a uma autoridade de controlo, a um Cliente que nos audita enquanto subcontratante, ou à próxima pessoa que tenha de responder a uma pergunta, o que é efetivamente tratado, onde é conservado, quem o recebe e durante quanto tempo permanece. Publicamo-lo porque um serviço que verifica e monitoriza formulários deve, ele próprio, estar aberto a verificação.

A sua redação obedeceu a três regras.

1. Medido, não pretendido. Uma afirmação sobre campos de dados, prazos de conservação, destinatários ou garantias só aparece quando o código do programa, o esquema da base de dados ou uma medição a sustentam. O que está planeado é designado “planeado”. O que está desativado por predefinição é designado “desativado por predefinição”. Quando não conseguimos provar algo, dizemo-lo.
2. A conservação é indicada duas vezes. Uma vez para cada atividade de tratamento e outra na secção 6, como visão de conjunto: que processo noturno apaga que dados, e que dados não alcança. Um registo que indique um prazo de conservação aplicável apenas a parte dos dados é pior do que um que identifique o ponto em aberto.
3. Os pontos em aberto são indicados no texto, não numa nota de rodapé. A secção 8.1 enumera as medidas ainda não implementadas e a secção 10 os pontos em aberto com as medidas planeadas. Um registo é um instrumento de trabalho, não um certificado.

Campos de dados em vez de nomes de tabelas. Para cada atividade de tratamento, enumeramos os dados armazenados como campos em linguagem corrente. O nome da tabela da base de dados segue entre parênteses, para que um auditor possa encontrar o local, por exemplo “tentativas de início de sessão (login_attempts)”. As listas de campos foram derivadas do esquema da base de dados, e não de memória.

Prazos de conservação como marcadores. Quando um prazo de conservação pode ser definido na área de administração, aparece aqui exatamente como o processo noturno o lê: o número que vê provém da mesma definição que rege o apagamento. Os prazos de conservação fixados no programa são indicados como números.

Base de medição. O esquema, o código e as definições foram medidos em 11 de outubro de 2026 no sistema de desenvolvimento, que corresponde ao sistema de produção em código e esquema. Não indicamos números de linhas do sistema de desenvolvimento; contêm dados de teste e nada dizem sobre o funcionamento real.

Deliberadamente omitido. Este registo não indica nomes de anfitrião, endereços de rede internos, portas, nomes de utilizador nem versões de software dos nossos servidores. Esses pormenores ajudam um atacante e nenhum titular dos dados. Pelo mesmo motivo, descrevemos apenas em termos gerais os pontos em aberto na proteção dos nossos próprios servidores (secção 8.1): indicamos o risco, não o caminho até ele. Fornecemos os pormenores a uma autoridade de controlo mediante pedido.

Natureza jurídica. Este registo é a documentação que mantemos nos termos do Art. 30 do RGPD para a autoridade de controlo; é publicado voluntariamente. Não faz parte de nenhum contrato e não constitui qualquer declaração, garantia ou acordo sobre qualidade perante Clientes ou terceiros. O que devemos aos Clientes rege-se pelos Termos de Serviço, pelo Acordo de Tratamento de Dados e pelos seus anexos; no que respeita a essas obrigações, estes prevalecem sobre o presente registo. O registo descreve a situação na data desta versão. Classificações como “ponto em aberto” ou “avaliação” refletem a nossa própria opinião e não antecipam qualquer apreciação jurídica por uma autoridade de controlo ou um tribunal; as medidas descritas como “planeadas” são intenções sem data assumida.

2. A entidade jurídica e a razão pela qual este registo tem duas metades

Campo	Entrada
Entidade jurídica	LW IT Solutions Company Lukas Wójcik, empresa em nome individual inscrita no registo de atividades económicas polaco (CEIDG); proprietário Lukas Wójcik
Endereço	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland
Identificadores fiscais	NIP 7252266190, número de IVA PL7252266190
Contacto	contact@lukaswojcik.com; a janela de apoio (ponto de interrogação na navegação); a página de contacto
Serviço	formexposed: verificação, monitorização e proteção de formulários de contacto em sítios web (aplicação em formexposed.com, página de apresentação em form.exposed)
Representante nos termos do Art. 27 do RGPD	Não aplicável. A entidade jurídica está estabelecida na União (Polónia).
Encarregado da proteção de dados	Não designado. A avaliação nos termos do Art. 37 consta da secção 9.
Autoridade de controlo competente	Prezes Urzędu Ochrony Danych Osobowych (UODO, a autoridade polaca de proteção de dados), ul. Moniuszki 1A, 00-014 Warszawa
Alojamento	Os nossos próprios servidores na Polónia: um servidor web com a aplicação e a base de dados, e um servidor de análise com um modelo de linguagem local na mesma rede interna. Sem centro de dados de terceiros nem fornecedor de serviços de nuvem.

O formexposed desempenha funções diferentes perante diferentes grupos de pessoas. Confundi-las produz um registo que não está correto para nenhuma delas.

• Responsável pelo tratamento (Parte B, Art. 30(1)). Somos nós próprios o responsável pelo tratamento dos dados dos nossos próprios Clientes e dos membros das suas equipas (conta, início de sessão, faturação, apoio, registos), dos visitantes do nosso próprio sítio web, das verificações sem conta (verificação gratuita, ferramenta de cabeçalhos, estudo, verificação de potenciais clientes) e da prevenção de abusos.
• Subcontratante (Parte A, Art. 30(2)). Relativamente a dados pessoais de terceiros que um Cliente introduz no serviço ou que surgem quando prestamos um serviço ao Cliente, atuamos por conta do Cliente: cópias de e-mails de formulário reais na verificação de entrega, subscritores do portal de clientes do Cliente, destinatários dos alertas do Cliente, pessoas que estejam visíveis por acaso nas páginas verificadas do Cliente, as credenciais da conta de teste do Cliente e o código de formulário que o Cliente cola. O fundamento é o Acordo de Tratamento de Dados, celebrado com cada Cliente no momento do registo.
• Apenas do lado do Cliente. Algumas funções do plugin para WordPress e da extensão para TYPO3 tratam dados exclusivamente no sítio web do Cliente, sem que os dados alguma vez cheguem até nós (quarentena, rede de segurança, desafio aritmético, definições de conservação, contadores locais, gravador). Não constituem tratamento por nós e, por isso, não constam de nenhuma das partes. Ainda assim, descrevemo-las no final da Parte A, para que a fronteira seja visível.

A separação está incorporada no código, e não apenas no texto: de um e-mail de formulário real, a verificação de entrega escreve na base de dados apenas a hora, a associação e o resultado da autenticação; as capturas de ecrã das verificações no navegador tapam os campos de introdução; as credenciais das contas de teste são cifradas de tal forma que o servidor web já não as consegue ler. Os pormenores constam das entradas.

As secções 6 a 11 aplicam-se a ambas as metades: conservação, decisões automatizadas, medidas técnicas e organizativas, encarregado da proteção de dados, pontos em aberto e manutenção deste registo.

Âmbito. Este documento é a parte do registo que diz respeito ao serviço formexposed. O tratamento efetuado pela mesma entidade jurídica para outros serviços é registado nos respetivos registos; a contabilidade geral e a administração da empresa fora do serviço não são abrangidas por esta parte.

3. Parte A – Art. 30(2): tratamento por conta dos Clientes

A.0 Intervenientes

Campo	Entrada
Subcontratante	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland; contact@lukaswojcik.com
Responsáveis pelo tratamento	Os Clientes do formexposed: empresas e agências que têm domínios na sua conta e utilizam funções nas quais surgem dados de terceiros. No caso das agências, o próprio cliente da agência pode ser adicionalmente o responsável pelo tratamento; a agência atua então como subcontratante perante esse cliente e nós atuamos como subcontratante ulterior.
Lista dos responsáveis pelo tratamento	Parte integrante deste registo, mantida em formato eletrónico (Art. 30(3) do RGPD) no sistema do serviço e não reproduzida nesta versão pública, porque contém dados pessoais de Clientes e ficaria desatualizada com cada novo Cliente: o proprietário de cada espaço de trabalho, com nome, endereço de e-mail e empresa da conta de cliente (endereço e número de IVA apenas na Stripe) (users, workspaces, workspace_users), bem como os domínios do espaço de trabalho (domains). Fornecemo-la a uma autoridade de controlo, sob a forma de extrato, mediante pedido.
Representantes e encarregados da proteção de dados dos responsáveis pelo tratamento	Não existe no sistema um campo específico para o efeito. Se um Cliente tiver designado um representante nos termos do Art. 27 do RGPD ou um encarregado da proteção de dados, pode comunicar-nos essa designação; conservamos a comunicação juntamente com a lista dos responsáveis pelo tratamento.
Representante do subcontratante	Não aplicável (estabelecido na Polónia).
Encarregado da proteção de dados	Não designado (secção 9).
Instruções	A instrução decorre do Acordo de Tratamento de Dados e das definições configuradas pelo Cliente: o Cliente ativa a verificação de entrega, configura destinos de alerta, guarda uma conta de teste e configura um portal de clientes. Sem essa ação, o tratamento em causa não ocorre.
Medidas técnicas e organizativas	A secção 8 e a página Medidas Técnicas e Organizativas aplicam-se a todas as atividades de tratamento da Parte A. As medidas especiais são indicadas na entrada correspondente.

A.1 Verificação de entrega – cópia de controlo dos e-mails de formulário

Campo	Entrada
Finalidade	Verificar se o e-mail do formulário de contacto do Cliente é efetivamente enviado e como é autenticado (SPF, DKIM, DMARC, alinhamento). Após uma submissão de teste ativa aceite, a respetiva cópia tem de chegar à caixa de correio de controlo dentro de um tempo de espera ajustável (atualmente 3 horas); caso contrário, é emitido o alerta “E-mail de teste não recebido”. Os cabeçalhos são também utilizados para determinar a autenticidade do e-mail do formulário, o serviço de correio eletrónico utilizado e o endereço de envio para a verificação em listas de bloqueio.
Pré-requisito	Plano pago, domínio verificado, ativação pelo Cliente. O Cliente introduz o seu próprio endereço de controlo com um identificador (do tipo “delivery+identificador@…”) como cópia oculta na notificação do seu formulário. Sem uma caixa de correio de controlo configurada, a função não está disponível.
Categorias de titulares dos dados	Visitantes do sítio web do Cliente que submetem o formulário do Cliente; pessoas cujos dados um visitante escreve na mensagem; trabalhadores do Cliente que aparecem como destinatários nos cabeçalhos.
Categorias de dados pessoais	Na caixa de correio de controlo (no fornecedor de serviços de correio eletrónico): a cópia completa de cada e-mail de formulário, incluindo pedidos reais com nome, endereço de e-mail, número de telefone e texto livre, até à eliminação. Lido pela obtenção: os cabeçalhos e no máximo os primeiros 8 KB do corpo. Na base de dados: hora de receção, associação ao domínio e, se for caso disso, à execução de teste (delivery_log); o resultado de autenticação mais recente por domínio, com o resultado SPF, DKIM e DMARC, o alinhamento, o domínio do remetente, os domínios de assinatura e o endereço do servidor de correio de envio (campo de autenticação do domínio em domains). O conteúdo, o assunto e o endereço de remetente do visitante não são escritos na base de dados.
Nota sobre o domínio do remetente	Se um formulário introduzir o endereço do visitante como remetente (uma configuração incorreta que a verificação se destina a detetar), o resultado da autenticação contém o domínio desse endereço, e não o próprio endereço. Quando um visitante utiliza um domínio pessoal, também este pode constituir um dado pessoal. É sobrescrito na receção seguinte.
Origem	O formulário no sítio web do Cliente, através da cópia oculta introduzida pelo Cliente.
Fundamento jurídico (determinado pelo responsável pelo tratamento)	Determinado pelo Cliente. A nossa proposta de texto para a política de privacidade do Cliente baseia a cópia no Art. 6(1)(f) do RGPD (interesse legítimo na receção fiável de pedidos). O Cliente informa os seus visitantes sobre este fluxo de dados; o Acordo de Tratamento de Dados obriga-o a fazê-lo.
Destinatários	O fornecedor de serviços de correio eletrónico que gere a caixa de correio de controlo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). A cópia vai diretamente para lá: só chega se os registos MX do nosso domínio apontarem para esta caixa de correio (a lista de verificação anterior ao lançamento verifica-o); através de um reencaminhamento, não chega à caixa de correio. Na página do domínio, o Cliente vê apenas a hora, a associação e o resultado da autenticação. Se o resultado da autenticação piorar, o alerta enviado ao Cliente e aos canais por ele escolhidos indica o domínio do remetente, se este não pertencer ao sítio web (A.3, 4.1).
País terceiro	Depende do fornecedor de serviços de correio eletrónico; ver secção 4. O contrato com o fornecedor previsto e o fundamento da transferência ainda não estão documentados.
Conservação	Após o processamento bem-sucedido, o e-mail é marcado para eliminação e removido da caixa de correio na mesma execução, mesmo que não possa ser associado a nenhum domínio. A obtenção é executada com o processo de estado a cada cinco minutos, enquanto a monitorização estiver ativada na área de administração (srv/cron_status.php, cfg/zustellung_lib.php). Se a obtenção ou a eliminação falhar, o e-mail permanece na caixa de correio até à execução bem-sucedida seguinte. A mesma obtenção apaga as associações em delivery_log após 180 dias. O resultado da autenticação existe enquanto o domínio existir.
O que a prova demonstra	Apenas a receção, na caixa de correio de controlo, da cópia associada à execução de teste específica. Não demonstra nem a receção pelo destinatário efetivo nem um registo no CRM. Não é oferecida uma confirmação nativa do HubSpot.
Medidas técnicas e organizativas	Secção 8. Em especial: o conteúdo é avaliado apenas em memória; não são armazenados o corpo, o assunto nem endereços de remetente completos; eliminação independentemente de a associação ter sido bem-sucedida.

A verificação de entrega é a única função através da qual nos chegam mensagens reais dos visitantes dos nossos Clientes. É por isso que constitui tratamento por conta do Cliente e não um serviço sob a nossa própria responsabilidade, e é por isso que o tempo passado na caixa de correio é a verdadeira medida do risco: normalmente minutos; se a obtenção for perturbada, até voltar a ser executada. As cópias não devem conter categorias especiais de dados pessoais; não o podemos impedir tecnicamente, porque o que um visitante escreve depende do visitante.

A.2 Portal de clientes e relatório mensal para subscritores

Campo	Entrada
Finalidade	Uma agência (plano Business) mostra aos seus clientes o estado dos respetivos domínios sob a sua própria marca (portal num endereço aleatório, opcionalmente com palavra-passe, opcionalmente num subdomínio da própria agência). O cliente pode aí encomendar um relatório mensal por e-mail. O relatório é enviado em nome da agência.
Categorias de titulares dos dados	Os clientes da agência e os respetivos trabalhadores que encomendam o relatório; pessoas que abrem o portal.
Categorias de dados pessoais	Subscritor: endereço de e-mail, língua, identificador de confirmação, hora da encomenda e endereço IP no momento da encomenda, hora da confirmação (double opt-in), hora do cancelamento da subscrição, último mês enviado (client_subscribers). Portal: nome, seleção de domínios, identificador aleatório, palavra-passe apenas como hash, pessoa que o criou, hora, revogação (client_portals). As visitas ao portal aparecem no registo de visualizações de páginas (B.2).
Origem	Introduzidos pelos próprios subscritores no portal.
Fundamento jurídico (determinado pelo responsável pelo tratamento)	O consentimento do subscritor, obtido através de um procedimento de double opt-in; o responsável pelo tratamento é a agência. Não escrevemos a ninguém que não se tenha inscrito e confirmado pessoalmente.
Destinatários	A agência (vê os seus subscritores); o fornecedor de serviços de correio eletrónico (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) para o e-mail de confirmação e o relatório.
País terceiro	Através do fornecedor de serviços de correio eletrónico; ver secção 4.
Conservação	Processo noturno de apagamento (cfg/fristen_lib.php, parte “subscritores de portais”): encomendas nunca confirmadas após 30 dias; subscritores que cancelaram a subscrição três anos após o cancelamento, como prova do consentimento anterior. Os subscritores confirmados que não cancelaram a subscrição permanecem enquanto existir o espaço de trabalho da agência. Um portal revogado é apenas bloqueado, não eliminado; os seus subscritores deixam de receber relatórios, mas os seus dados permanecem (secção 10). Os portais e os subscritores são apagados imediatamente com o espaço de trabalho (fe_arbeitsbereich_daten_loeschen()). Os relatórios enviados permanecem na caixa de saída durante 30 dias (B.25).
Medidas técnicas e organizativas	Secção 8. Em especial: palavra-passe do portal apenas como hash, tentativas de adivinhação limitadas (dez por portal e endereço IP, 50 por portal em 15 minutos); cancelamento da subscrição com um clique em cada e-mail; o portal mostra apenas o estado e indicadores principais, sem resultados individuais com provas.

A.3 Destinatários de alertas, pessoas que confirmam incidentes e responsáveis designados do Cliente

Campo	Entrada
Finalidade	Notificações sobre falhas e alterações para os destinos que o Cliente configura para um domínio: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Por destino, de imediato ou agrupadas diária ou semanalmente, bem como destinos apenas para escalonamentos. Cada notificação de problema dá origem a um incidente, cuja receção o destinatário pode confirmar através de uma ligação. Para os formulários monitorizados, o Cliente pode indicar uma pessoa responsável e uma data-limite.
Categorias de titulares dos dados	Trabalhadores e prestadores de serviços do Cliente que o Cliente introduz como destino de alerta ou designa como responsáveis; pessoas que confirmam a receção de um incidente. Os membros da equipa com conta própria aparecem também na Parte B.
Categorias de dados pessoais	Destino de alerta: canal, endereço de destino (endereço de e-mail, endereço de webhook ou de chat, ID de chat do Telegram), eventos selecionados, modo de entrega, segredo de assinatura para webhooks, última entrega e último erro (alerts). Registo de entregas: destino, eventos, estado, erro, hora (alert_log). Fila de resumos: linhas de notificação e ligação até à entrega (alert_queue). Incidente: título, linhas de notificação, ligação, identificador de confirmação, hora e nome ou endereço de e-mail da pessoa que confirma tal como introduzido no formulário, caso contrário o endereço do membro com sessão iniciada (alert_incidents). Tentativas de entrega de escalonamento por incidente e destino: número de tentativas (no máximo cinco), horas da última e da próxima tentativa e do êxito, referência ao e-mail na caixa de saída, erro (tabela alert_escalation_deliveries). Atribuição: conta da pessoa responsável e data-limite (em monitored_forms).
Conteúdo das notificações	Domínio, evento, uma breve explicação e uma ligação para a página do domínio. Nenhum conteúdo de mensagens de visitantes.
Origem	Introduzidos pelo Cliente; a pessoa que confirma introduz ela própria o seu nome; o ID de chat do Telegram é criado quando o destinatário carrega em “Start” no bot (B.32).
Fundamento jurídico (determinado pelo responsável pelo tratamento)	Determinado pelo Cliente; em regra, a organização das próprias operações do Cliente (Art. 6(1)(b) ou (f) do RGPD relativamente aos trabalhadores e prestadores de serviços do Cliente).
Destinatários	Os operadores dos canais escolhidos; ver 4.1. Alertas por e-mail através do fornecedor de serviços de correio eletrónico (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
País terceiro	Consoante o canal escolhido; vários fornecedores têm sede nos EUA, o Telegram fora da UE sem decisão de adequação. Ver 4.1.
Conservação	Registo de entregas após 90 dias (noturno, fe_alert_log_aufraeumen() a partir de srv/cron_status.php). Notificações agrupadas 30 dias após a entrega (cfg/kanal_lib.php, em cada entrega de resumo). Incidentes enquanto não estiverem resolvidos; os resolvidos 180 dias após a resolução (cfg/vorfall_lib.php, processo de escalonamento), juntamente com as respetivas tentativas de entrega de escalonamento. Destinos de alerta e atribuições até à eliminação pelo Cliente ou juntamente com o domínio.
Medidas técnicas e organizativas	Secção 8. Em especial: webhooks assinados com um segredo próprio por destino; confirmação apenas após um clique (POST), para que as pré-visualizações de ligações em programas de chat não desencadeiem nada; os alertas durante uma janela de manutenção são apenas registados, não enviados.

A.4 Pessoas visíveis por acaso em páginas verificadas do Cliente e em capturas de ecrã

Campo	Entrada
Finalidade	A verificação dos domínios na conta do Cliente (análise, monitorização, verificação ativa) lê as páginas públicas do Cliente e efetua capturas de ecrã de formulários. O que a própria página apresenta pode dizer respeito a pessoas que nada têm a ver com a verificação. Estes dados surgem de forma acessória; não são a finalidade da verificação.
Categorias de titulares dos dados	Pessoas cujo nome, fotografia ou contactos aparecem na página verificada (pessoa de contacto junto ao formulário, fotografias da equipa na página inicial, dados da informação legal).
Categorias de dados pessoais	Capturas de ecrã: a área visível da página inicial, cada formulário visível como recorte e a imagem da página seguinte após uma submissão de teste ativa; armazenadas como ficheiros fora do diretório web, com apenas a referência na base de dados (scan_screenshots). Estrutura do formulário: endereço da página, seletor, nomes de campos, tipos de campos, etiquetas de campos, indicadores de obrigatoriedade e de visibilidade, etiquetas dos botões de envio (forms, campo “field map”); sem valores de campos. O scanner lê o início de campos ocultos (até 24 caracteres) e de atributos data (até 60 caracteres) apenas durante a verificação, para reconhecer carimbos temporais e tokens; só o resultado é armazenado. Resultados com provas (findings), resumo com títulos das páginas (scans). Se um endereço de e-mail aparecer no formulário como destinatário, só é armazenado o seu domínio, nunca o endereço.
Origem	As páginas públicas do domínio do Cliente, obtidas pelo scanner.
Fundamento jurídico (determinado pelo responsável pelo tratamento)	Determinado pelo Cliente relativamente ao conteúdo do seu próprio sítio web. Para nós, o tratamento faz parte da verificação encomendada.
Destinatários	O Cliente; no caso das agências, o respetivo cliente através do portal ou de um relatório white-label; qualquer pessoa que receba uma ligação de relatório (relatórios em endereços aleatórios, não indexados em motores de pesquisa). Quando o tipo de formulário não é claro, um modelo de linguagem local no nosso próprio servidor recebe a estrutura do formulário com o título da página, o endereço da página e o texto visível do formulário (até 400 caracteres) para classificação; não recebe imagens.
País terceiro	Nenhum.
Conservação	Resultados das verificações de um domínio durante no máximo 13 meses; mantém-se a última verificação concluída por domínio (processo noturno de apagamento, parte “resultados de verificações antigos”). Os formulários, os resultados, as referências de imagens e os ficheiros de imagem são apagados com o resultado da verificação. Com o domínio, estes dados são apagados imediatamente (cadeia de apagamento em B.15; exceções na secção 6.4).
Limites da ocultação	As capturas de ecrã da verificação completa não ocultam nada: mostram o que a página mostra a qualquer visitante. Os campos do formulário estão vazios no momento da obtenção, porque o scanner não introduz nada; os valores pré-preenchidos seriam visíveis. Não são efetuadas capturas de ecrã por detrás de um início de sessão (A.5). As imagens das verificações no navegador tapam os campos de introdução (A.6).
Medidas técnicas e organizativas	Secção 8. Em especial: as imagens só podem ser obtidas através do relatório, e o identificador de imagem de outra pessoa devolve “não encontrado”; relatórios com noindex; cada verificação é executada no seu próprio contentor isolado.

Os mesmos dados surgem nas verificações sem conta (verificação gratuita, estudo, verificação de potenciais clientes). Aí, não existe um Cliente por conta do qual atuemos; por isso, estes casos constam da Parte B (B.5, B.7, B.8).

A.5 Credenciais da conta de teste para a análise por detrás do início de sessão

Campo	Entrada
Finalidade	Leitura de formulários que só aparecem após o início de sessão (área de cliente, área de membros). O scanner inicia sessão com uma conta de teste que o Cliente criou no seu próprio sítio web e lê as páginas indicadas. Para além do formulário de início de sessão, não submete nada, não realiza aí qualquer teste ativo, não efetua capturas de ecrã e não visita endereços de terminar sessão, eliminação ou cancelamento. Se o formulário de início de sessão tiver um CAPTCHA, para; os CAPTCHA não são contornados.
Pré-requisito	Domínio verificado, plano pago, função de proprietário ou administrador, confirmação expressa de que a conta é uma conta de teste. No máximo cinco páginas, todas no mesmo domínio.
Categorias de titulares dos dados	A pessoa em cujo nome a conta de teste está registada (idealmente ninguém; o Cliente deve utilizar uma conta funcional); pessoas cujos dados aparecem nas páginas por detrás do início de sessão.
Categorias de dados pessoais	Nome de utilizador e palavra-passe da conta de teste, apenas cifrados; uma indicação do nome de utilizador (primeiro carácter e comprimento); endereço de início de sessão, lista de páginas, nomes dos campos de início de sessão, indicador de êxito, pessoa que a criou, horas, último resultado como código abreviado (domain_logins). Para uma tarefa em curso, uma cópia do texto cifrado (campo “login package” em scan_jobs). Das páginas por detrás do início de sessão: estrutura dos formulários como em A.4, sem capturas de ecrã e sem cookies.
Origem	Introduzidos pelo Cliente na conta.
Fundamento jurídico (determinado pelo responsável pelo tratamento)	Determinado pelo Cliente. O Cliente garante que tem o direito de utilizar a conta de teste.
Destinatários	Nenhum. Nem o Cliente, nem o apoio, nem a interface de programação conseguem ler as credenciais; a interface mostra apenas a indicação do nome de utilizador.
País terceiro	Nenhum.
Proteção das credenciais	O nome de utilizador e a palavra-passe são cifrados imediatamente no momento do armazenamento com a chave pública do servidor de análise (X25519, HKDF-SHA256, AES-256-GCM; o domínio é associado como dados associados, pelo que um texto cifrado não pode ser anexado a outro domínio). Só o servidor de análise tem a chave privada. O servidor web, a base de dados e as cópias de segurança contêm apenas texto cifrado; também nós não o conseguimos decifrar aí. O servidor de análise decifra apenas para a execução, transmite as credenciais ao contentor de verificação isolado apenas através da entrada padrão, apaga imediatamente a cópia na tarefa e não a escreve em nenhum resultado, registo ou texto de erro. No caminho até ao sítio web do Cliente, estão protegidas apenas pela cifragem desse sítio web; os limites deste transporte são descritos na secção 10.
Conservação	Credenciais armazenadas até à eliminação pelo Cliente. Na eliminação, o texto cifrado é sobrescrito com dados aleatórios do mesmo comprimento e a linha é apagada; as tarefas em espera são limpas (fe_login_loeschen()). Com o domínio, a linha é apagada através de uma chave estrangeira. O servidor de análise limpa as cópias nas tarefas após a execução; o que restar (tarefa interrompida, servidor de análise indisponível) é limpo pelo processo de estado o mais tardar após uma hora (fe_login_aufraeumen(), parte “login_jobs”). As cópias de segurança da base de dados contêm o texto cifrado até à expiração da cópia, após 14 dias.
Medidas técnicas e organizativas	Secção 8. Em especial: cifragem assimétrica com chaves separadas; lista de bloqueio para caminhos de terminar sessão e de eliminação; sem capturas de ecrã por detrás do início de sessão; função apenas para planos pagos e domínios verificados; cada alteração no registo de atividade (sem credenciais).

Deliberadamente, não criámos qualquer forma de armazenar credenciais para o servidor do Cliente, para a área de administração do CMS ou para contas de alojamento. A conta de teste é uma conta de visitante no sítio web do Cliente, e não um acesso ao sistema do Cliente.

A.6 Percursos de formulário configurados, verificações no navegador e sonda independente

Campo	Entrada
Finalidade	Um formulário monitorizado é percorrido num navegador real (Chromium, WebKit ou ambos) até ao momento imediatamente anterior à submissão: carregar a página, executar cliques prévios (no máximo cinco, nunca num campo de introdução nem num botão de envio), preencher campos com valores reconhecidamente sintéticos (como um endereço sob a terminação reservada .invalid), avançar em formulários de várias etapas. A verificação no navegador não submete nada; a submissão está tecnicamente bloqueada no navegador. Além disso, medições de tempos e comparações visuais do formulário.
Categorias de titulares dos dados	Como em A.4 (pessoas visíveis na página do formulário); trabalhadores do Cliente introduzidos como responsáveis (A.3).
Categorias de dados pessoais	Configuração: endereço do formulário, seletores, endereço de entrada, passos de clique, escolha do navegador, etiqueta, criticidade, atribuição, data-limite (monitored_forms). Resultados por execução: estado, motivo técnico da falha, mensagens de erro depuradas, medições de rede e de tempos, uma imagem do formulário em JPEG de no máximo 32 KB com os campos de introdução tapados (form_browser_runs). Observações por verificação (form_observations), séries temporais (form_performance). Tarefas com uma lista de destinos (campos “targets” e “result” em scan_jobs).
Acesso de teste	Se o Cliente tiver guardado uma conta de teste (A.5), a verificação completa utiliza-a também para os percursos de formulário configurados. De acordo com o código medido, as verificações autónomas no navegador entre duas verificações completas funcionam sem conta de teste.
Sonda independente	Está prevista uma segunda localização de controlo noutro local, que faria uma verificação cruzada antes de um alerta. Receberia o domínio, a configuração depurada e o identificador da tarefa, sem introduções de visitantes e sem credenciais. Atualmente não está configurada (desativada por predefinição). Sem a sonda, não há prova a partir de uma segunda localização; um alerta baseia-se então na nossa própria medição.
Origem	Configurado pelo Cliente; resultados da obtenção da página do Cliente.
Fundamento jurídico (determinado pelo responsável pelo tratamento)	Determinado pelo Cliente relativamente ao conteúdo do seu sítio web e às responsabilidades dos seus trabalhadores.
Destinatários	O Cliente; quando uma sonda estiver configurada, o respetivo operador (atualmente ninguém).
País terceiro	Nenhum.
Conservação	Resultados das execuções no navegador, tarefas de navegador concluídas e séries temporais após 13 meses (processo noturno de apagamento, partes “browser_runs”, “browser_jobs”, “form_performance”). Configurações até à eliminação do domínio (individualmente podem ser alteradas ou desativadas, não eliminadas); com o domínio, são apagadas, juntamente com execuções, observações e séries temporais, através de chaves estrangeiras.
O que a medição demonstra	Tempos e estados do nosso navegador de verificação. Não medem o que os visitantes reais experienciam e não demonstram nem taxas de conclusão nem pedidos perdidos.
Medidas técnicas e organizativas	Secção 8. Em especial: submissão tecnicamente impedida; apenas endereços no mesmo domínio; imagens com ocultação; contentor de verificação isolado.

A.7 “Fix it for me” – código de formulário colado

Campo	Entrada
Finalidade	O Cliente cola o código do seu formulário; um modelo de linguagem no nosso próprio hardware integra o módulo de proteção. O que é devolvido é o ficheiro modificado, um patch, o resultado de uma verificação de sintaxe e uma indicação sobre se a chamada de verificação foi efetivamente integrada. Sem código colado, o serviço fornece um módulo pronto a utilizar com os nomes de campos da última análise.
Categorias de titulares dos dados	Pessoas cujos dados constem por acaso do código colado (como um endereço de destinatário, nomes em comentários, credenciais de um servidor de correio).
Categorias de dados pessoais	O código colado, no máximo 30 000 caracteres. Na base de dados, apenas uma entrada no registo de atividade (ação “fix_ai” com espaço de trabalho e hora), que conta para o limite diário de atualmente dez chamadas por espaço de trabalho.
Origem	Colado pelo Cliente.
Fundamento jurídico	Execução do contrato com o Cliente (Art. 6(1)(b) do RGPD) relativamente ao próprio código; relativamente a dados de terceiros nele contidos por acaso, o Cliente determina o fundamento.
Destinatários	Nenhum. O modelo de linguagem é executado no nosso próprio servidor de análise na rede interna; nenhum serviço externo de IA, nem mesmo como alternativa.
País terceiro	Nenhum.
Conservação	O código não é armazenado. É criado um ficheiro temporário para a verificação de sintaxe, que é apagado imediatamente a seguir. A entrada no registo de atividade é apagada após 365 dias.
Nota ao Cliente	O código que contenha palavras-passe, chaves de API ou dados pessoais deve ser limpo antes de ser colado. Não verificamos o conteúdo.
Medidas técnicas e organizativas	Secção 8. Em especial: apenas proprietários e administradores em planos pagos; o código colado é transmitido ao modelo assinalado como dados e nunca é executado; sem carregamento para servidores de terceiros.

A.8 Marca white-label e pessoas de contacto da agência

Campo	Entrada
Finalidade	Os relatórios, relatórios resumidos, registos de prova e o portal de clientes de uma agência (plano Business) aparecem sob a sua marca e, mediante pedido, num subdomínio da própria agência.
Categorias de titulares dos dados	Pessoas de contacto da agência cujo nome ou contactos aparecem na linha de contacto.
Categorias de dados pessoais	Nome da empresa, sítio web, linha de contacto, nota ao cliente, cor de destaque, aspeto, ficheiro do logótipo, interruptor para a referência ao formexposed, domínio próprio com identificador de verificação e estado da verificação (workspace_branding).
Origem	Introduzidos pela agência.
Fundamento jurídico	Execução do contrato com a agência (Art. 6(1)(b) do RGPD). Quando a linha de contacto indica trabalhadores da agência, a agência determina o fundamento.
Destinatários	Qualquer pessoa a quem a agência entregue um relatório, um relatório resumido ou uma ligação de portal.
País terceiro	Nenhum.
Conservação	Até à alteração pela agência; a marca e o ficheiro do logótipo são apagados com o espaço de trabalho (fe_arbeitsbereich_daten_loeschen()). Um domínio próprio cuja verificação DNS falhe durante sete dias é desativado. O domínio próprio está desativado por predefinição.
Medidas técnicas e organizativas	Secção 8.

A.9 Contagens, indicadores de estado e erros de campos do plugin e da extensão

Campo	Entrada
Finalidade	Uma vez por dia, o plugin para WordPress e a extensão para TYPO3 comunicam números sobre os formulários do sítio web ligado: submissões bloqueadas por motivo, submissões, e-mails enviados e falhados, indicadores de estado das definições dos formulários, pedidos armazenados por origem e prazo de conservação. Facultativo, desativado por predefinição: eventos de formulário e categorias de erros de campos por posição do campo. Estes números dão origem à “Proteção em números”, ao relatório mensal, ao alerta de silêncio e a avisos sobre definições de risco.
Classificação	Os números estão concebidos de modo a não descreverem nenhuma pessoa. Enumeramo-los na Parte A porque resultam de eventos no sítio web do Cliente desencadeados pelos visitantes do Cliente; na nossa opinião, só constituem dados pessoais, quando muito, em casos-limite (um sítio web com muito poucas submissões num determinado dia). A própria transmissão (chaves, versões, anfitrião) consta da Parte B (B.20).
Categorias de titulares dos dados	Visitantes do sítio web do Cliente que submetem um formulário.
Categorias de dados pessoais	Números diários por anfitrião: bloqueados no total e por motivo, submissões, e-mails enviados e falhados, categoria de erro do envio de e-mail (apenas uma de quatro categorias, nunca o texto do erro, porque pode conter endereços de destinatários), contagens de respostas do reCAPTCHA, pedidos apagados e libertados (plugin_stats). Estado: versões de uma lista fixa de plugins de formulário, CAPTCHA e correio eletrónico, indicadores de definições como números, prazos de conservação (plugin_health). Notificações de alterações: nome e versão de um plugin atualizado (plugin_changes). Facultativo: contadores por formulário e dia com categorias de erros por posição do campo (form_metrics). Nunca: introduções, nomes de campos, palavras-passe, ficheiros, endereços de e-mail, nomes, endereços IP ou identificadores persistentes de visitantes.
Origem	O plugin no sítio web do Cliente, através de uma interface de programação que utiliza o segredo de ligação do sítio web.
Fundamento jurídico (determinado pelo responsável pelo tratamento)	Determinado pelo Cliente; o Cliente decide se ativa as contagens facultativas e como informa os seus visitantes.
Destinatários	O Cliente. Os domínios das ligações contidas em mensagens bloqueadas entram na proteção coletiva (B.21).
País terceiro	Nenhum.
Conservação	Números diários, notificações de alterações e contadores de formulários após 13 meses (processo noturno de apagamento, partes “plugin_stats” e “form_metrics”). Os indicadores de estado são sobrescritos em cada comunicação. Todos os dados do plugin relativos a um anfitrião são apagados logo que nenhum domínio no sistema remeta para esse anfitrião (imediatamente após a eliminação do último domínio; dados antigos todas as noites, parte “orphan_hosts”).
O que os números demonstram	O que o plugin contou. Não demonstram nem taxas de conclusão nem pedidos perdidos.
Medidas técnicas e organizativas	Secção 8. Em especial: aceitação apenas com o par de chaves associado ao sítio web; só são aceites chaves e números conhecidos, sendo tudo o resto descartado; os dias fora de uma janela de 14 dias são rejeitados.

A.10 Fronteira: o que fica apenas no sítio web do Cliente

As seguintes funções do plugin para WordPress e da extensão para TYPO3 tratam dados exclusivamente no servidor do Cliente. Não chegam até nós e não temos acesso a elas. O operador do sítio web é o único responsável; o operador decide sobre a ativação, os prazos de conservação e a forma de informar os seus visitantes. Para o efeito, o plugin propõe parágrafos para a política de privacidade do operador.

Função	O que é tratado localmente	Conservação do lado do Cliente
Quarentena	Submissões retidas com o motivo, libertáveis por e-mail para o endereço do sítio web	14 dias
Rede de segurança	Submissões cujo e-mail de formulário falhou, para reenvio (ativada por predefinição)	30 dias
Desafio aritmético em vez do reCAPTCHA	Tarefa aritmética no navegador do visitante, sem serviço de terceiros (desativado por predefinição)	–
Definições de conservação	Apagamento dos pedidos armazenados nos plugins de formulário após o prazo escolhido pelo operador (desativado por predefinição)	conforme configurado
Limitação de frequência	um identificador de curta duração derivado do endereço IP, não transmitido a nós	curta duração
Contadores diários locais	Valores dos contadores antes da transmissão	no máximo 14 dias
Gravador para administradores	seletores técnicos e passos de navegação no armazenamento de sessão do navegador de um administrador com sessão iniciada; as introduções não são lidas. Só a configuração selecionada é transmitida (passando então a A.6)	no máximo 15 minutos
Ajuda ao visitante	pode ser ativada separadamente; não armazena rascunhos e não reenvia automaticamente	–
Observação de novas regras de spam	as correspondências adicionais são contadas localmente, sem ativação automática	sete dias

A.11 Proteção de formulários (formconfirmed)

Campo	Descrição
Finalidade	Avaliação das submissões efetuadas através de formulários nos sítios web do Cliente, a fim de detetar submissões automatizadas: emissão e verificação de tarefas (prova de trabalho), tokens de verificação de utilização única, tempo de preenchimento, campo-armadilha, pedidos acumulados; a pedido do Cliente, avaliação do texto da mensagem por um modelo de linguagem. Apenas para Clientes que ativem a proteção de formulários.
Categorias de titulares dos dados	Visitantes dos sítios web do Cliente que abram uma página com um formulário protegido ou o submetam.
Categorias de dados pessoais	Endereço IP (conservado apenas de forma truncada e com hash com uma chave que muda diariamente), endereço e domínio da página, momentos e tempo de preenchimento, campo-armadilha preenchido sim/não, identificação do navegador no registo do servidor web; apenas com a verificação de conteúdo ativada, o texto da mensagem (apenas na memória de trabalho).
Origem	Navegador do visitante (tarefa, token de verificação); servidor do Cliente (pedido de verificação e, se for caso disso, texto).
Destinatários	O Cliente (pontuação, ação, motivos). Nenhum outro; não há subcontratantes ulteriores para este tratamento.
País terceiro	Nenhum.
Conservação	Identificador com hash 1 hora; tokens de verificação utilizados no máximo 11 minutos; resultados da verificação sem endereço IP e sem texto 30 dias; números diários 400 dias; registo do servidor web 14 dias; texto sem conservação.
MTO	Secção 8; adicionalmente, truncagem e hash com chave diária, tarefas assinadas, utilização única, modelo de linguagem em hardware próprio sem registo do texto.

4. Parte A – destinatários, subcontratantes ulteriores e transferências para países terceiros

O quadro seguinte enumera os destinatários que nós próprios contratamos e que podem receber dados da Parte A. A lista de referência, continuamente atualizada, é a página Subcontratantes Ulteriores; se divergir deste quadro, trata-se de uma constatação a corrigir, e não de uma questão de formatação.

Destinatário	O que recebe	País terceiro	Fundamento	Estado
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Caixa de correio de controlo da verificação de entrega (A.1); envio de e-mails de alerta (A.3), confirmações e relatórios aos subscritores de portais (A.2)	Local de tratamento ainda a verificar; ver a página “Subcontratantes Ulteriores”	Acordo de tratamento de dados; fundamento da transferência ainda a verificar	Em aberto. O contrato relevante, os locais efetivos de tratamento e o fundamento da transferência ainda não estão documentados. Este registo não confirma nem uma certificação nem um contrato celebrado.
Namecheap, Inc. (registo de domínios, DNS; reencaminhamento de e-mails até a caixa de correio estar configurada)	Até a caixa de correio estar configurada, o correio geral recebido em endereços do nosso domínio; não as cópias da verificação de entrega, que só chegam com registos MX que apontem diretamente para a caixa de correio (A.1)	EUA	a verificar: certificação ao abrigo do Quadro de Privacidade de Dados UE-EUA ou cláusulas contratuais-tipo	Em utilização; fundamento em aberto.
O nosso próprio servidor de análise com um modelo de linguagem local	Estrutura dos formulários para classificação (A.4), código colado (A.7), acesso de teste decifrado apenas durante a execução (A.5)	–	Operado por nós, não é um terceiro	Em utilização.
Sonda independente numa segunda localização	Domínio, configuração depurada, identificador da tarefa (A.6)	consoante a localização	a determinar antes da entrada em funcionamento	Não configurada.

Alojamento: nenhum terceiro. A aplicação, a base de dados, as capturas de ecrã e as cópias de segurança são conservadas nos nossos próprios servidores na Polónia. Se mudarmos para um centro de dados ou para um fornecedor de serviços de nuvem, este parágrafo terá de ser reescrito.

4.1 Canais de alerta escolhidos pelo Cliente

Para além dos destinatários que contratamos, existem canais que o Cliente escolhe para os seus alertas (A.3). O nosso servidor desencadeia a transmissão; o Cliente determina o destino e o fornecedor. A escolha de um canal não nos isenta das nossas próprias obrigações enquanto subcontratante. A função, o contrato e as garantias necessárias para países terceiros têm de ser determinados para cada fornecedor; para os serviços de chat, isso ainda não foi concluído (questão em aberto para a revisão jurídica).

Canal	O que é enviado	Sede do fornecedor
E-mail	Domínio, evento, explicação, ligação; para o endereço introduzido	através de Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook para um endereço livremente escolhido	Evento em JSON (domínio, eventos, linhas, ligação, carimbo temporal), assinado com o segredo do destino	determinada pelo Cliente
Slack, Discord, Microsoft Teams, Google Chat	a mesma notificação como mensagem de chat para o endereço de webhook introduzido	predominantemente EUA
Telegram	destino escolhido pelo Cliente; enviamos a mensagem através do nosso bot para o ID de chat associado	fora da UE, sem decisão de adequação; o fundamento da transferência é uma questão em aberto para a revisão jurídica

Em caso algum é enviado o conteúdo de uma mensagem de visitante. As notificações contêm o domínio, o evento e a ligação.

5. Parte B – Art. 30(1): tratamento sob a nossa própria responsabilidade

Responsável pelo tratamento relativamente a tudo o que consta desta parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, contact@lukaswojcik.com. Não é necessário representante (estabelecido na União). Não foi designado encarregado da proteção de dados (secção 9). Medidas técnicas e organizativas: secção 8 e a página Medidas Técnicas e Organizativas. A forma como os titulares dos dados exercem os seus direitos é descrita na página Acesso, apagamento e os seus outros direitos; os titulares de contas podem descarregar eles próprios os seus dados como ficheiro (Definições).

Quando invocamos interesses legítimos (Art. 6(1)(f) do RGPD), indicamos o interesse e a razão pela qual um meio menos intrusivo não é suficiente. A ponderação é a nossa avaliação; faz parte da revisão jurídica.

B.1 Visitantes do nosso sítio web – registos do servidor web

Campo	Entrada
Finalidade	Funcionamento e segurança do sítio web e da aplicação: disponibilização, resolução de problemas, deteção de ataques e de sobrecarga.
Categorias de titulares dos dados	Todas as pessoas que abrem uma página de formexposed.com ou form.exposed, incluindo visitantes de páginas de Clientes cujo navegador carrega a imagem do nosso selo (B.18), destinatários que abrem uma ligação de relatório ou de confirmação e sítios web cujo plugin chama a nossa interface.
Categorias de dados pessoais	Endereço IP completo, hora, endereço solicitado, código de estado, bytes transferidos, página de referência (referrer), identificação do navegador (user agent).
Local de armazenamento	Registos de acesso do proxy a montante e do servidor web, como ficheiros no servidor web, não na base de dados.
Origem	O navegador ou o programa que efetua o pedido.
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: funcionamento seguro e ininterrupto. Ponderação: sem o endereço completo, os pedidos repetidos do mesmo remetente não podem ser relacionados e os ataques não podem ser repelidos; um endereço truncado não permite esta distinção. Os registos não são combinados com outros dados e são apagados após um curto período.
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	14 dias: rotação diária com 14 gerações, seguida de sobrescrita (serviço de rotação de registos do sistema, não o processo noturno de apagamento da aplicação).
Medidas técnicas e organizativas	Secção 8.

B.2 Registo de visualizações de páginas da aplicação

Campo	Entrada
Finalidade	Segurança e deteção de abusos (quem solicita o quê e com que frequência), rastreabilidade dos acessos às contas, estatísticas de utilização simples sem serviço de análise.
Categorias de titulares dos dados	Todos os visitantes do sítio web e utilizadores da aplicação em visualizações de páginas reais (sem pedidos em segundo plano, sem submissões de formulários).
Categorias de dados pessoais	Endereço IP completo, o país dele derivado no momento da escrita (base de dados geográfica local, sem consulta a terceiros), ID da conta para utilizadores com sessão iniciada, endereço solicitado e página de referência (com os tokens de acesso neles contidos, como os de ligações de relatórios ou de portais, mascarados), identificação do navegador e o tipo de dispositivo, sistema operativo e navegador dela derivados, língua, hora (access_logs). Durante o “Ver como cliente” (B.14) não é definido qualquer ID de conta, para que as visualizações de páginas do apoio não apareçam no registo do Cliente.
Origem	O pedido do navegador.
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: prevenção de abusos e rastreabilidade. Ponderação: como em B.1; o prazo de conservação é mais longo porque os padrões de abuso se tornam visíveis ao longo de semanas. Saber se o endereço IP deve ser truncado ou o prazo de conservação encurtado é uma questão em aberto para a revisão jurídica.
Destinatários	Nenhum. Os titulares de contas recebem as suas próprias visualizações de páginas na exportação de dados.
País terceiro	Nenhum.
Conservação	60 dias (todas as noites entre as 03:00 e as 03:05, srv/cron_status.php, definição “registo de visualizações de páginas”).
Medidas técnicas e organizativas	Secção 8. O endereço IP só é retirado de um cabeçalho reencaminhado se o pedido provier do nosso próprio proxy a montante e, nesse caso, apenas a entrada acrescentada por esse proxy; caso contrário, qualquer pessoa poderia indicar a sua origem à vontade.

B.3 Cookies e armazenamento no navegador

Campo	Entrada
Finalidade	Armazenamento tecnicamente necessário: sessão, proteção contra falsificação de pedidos entre sítios (CSRF), contagem dos limites para verificações sem conta, início de sessão, manutenção da sessão iniciada a pedido, apresentação clara ou escura.
Categorias de titulares dos dados	Visitantes e utilizadores de formexposed.com.
Categorias de dados pessoais	Cookie de sessão bpid (identificador de sessão; termina quando o navegador é fechado; HttpOnly, SameSite=Lax, Secure através de HTTPS). Cookie bp_remember apenas após a escolha de “Manter sessão iniciada” (seletor e verificador; 30 dias). Armazenamento local bp_theme (claro, escuro ou sistema). Na área de administração, adicionalmente definições de apresentação locais dos operadores. Para os limites, é formado um hash a partir do identificador de sessão; o próprio identificador não é armazenado.
Não definidos	Nenhuns cookies de análise, publicidade ou rastreio. O programa de parceiros (B.33) funciona sem cookie. A imagem do selo nas páginas dos Clientes não define qualquer cookie (B.18). O reCAPTCHA pode definir cookies da Google quando é submetido um formulário protegido (B.23).
Fundamento jurídico	Acesso ao equipamento terminal: estritamente necessário para o serviço solicitado pelo utilizador (§ 25(2) n.º 2 TDDDG, a lei alemã de proteção de dados nas telecomunicações e nos serviços digitais; Art. 399(3) PKE, a lei polaca das comunicações eletrónicas (Prawo komunikacji elektronicznej)). Tratamento: Art. 6(1)(b) do RGPD (conta) e (f) (segurança, limites).
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	Sessão; 30 dias para o token de memorização. O processo noturno apaga os tokens de memorização expirados na base de dados (remember_tokens); ao terminar sessão, ao alterar a palavra-passe e ao revogar um dispositivo, imediatamente.
Medidas técnicas e organizativas	Secção 8.

B.4 Verificação gratuita sem conta – aceitação, limites e monitorização de abusos

Campo	Entrada
Finalidade	Qualquer pessoa pode mandar verificar um domínio sem conta. Para que o campo de introdução não se torne uma arma contra sítios web de terceiros, aplicam-se limites escalonados: uma verificação anónima por domínio em sete dias (após isso, o mesmo relatório), limites por endereço IP e por sessão em 24 horas, um limite diário para todo o sistema, bloqueio de domínios muito recentes, lista de bloqueio e opt-out, apenas endereços públicos. Os padrões suspeitos são registados e comunicados ao operador. Os limites por endereço IP, por sessão e para todo o sistema, cada um contado separadamente, aplicam-se também à verificação a partir do plugin sem conta (um plugin com um par de chaves associado conta por sítio web em vez de por endereço) e ao opt-out (B.30); a ferramenta gratuita de cabeçalhos (B.9) tem limites próprios por endereço IP e por dia e para todo o sistema.
Categorias de titulares dos dados	Pessoas que desencadeiam uma verificação, um pedido à ferramenta de cabeçalhos ou um opt-out; servidores nos quais está instalado um plugin.
Categorias de dados pessoais	Registo de cada pedido: origem (verificação, plugin, ferramenta de cabeçalhos, opt-out), endereço IP completo, hash do identificador de sessão, anfitrião verificado, país a partir do endereço IP, aceite ou rejeitado com motivo, hora (check_throttle). Anomalias: tipo (endereço IP, sessão, país, sistema), chave (para o tipo “IP”, o endereço IP completo), padrão, gravidade, breve descrição, horas de deteção e de resolução, pessoa que resolveu (abuse_flags). Tarefa: anfitrião, modo, nível de confiança e um hash de sessão truncado como identificador do requerente (scan_jobs). Relatório: identificador aleatório, anfitrião, língua, expiração, primeira visualização, número de visualizações (reports). Antiguidade do domínio em cache, proveniente da consulta ao registo (domain_age_cache).
Origem	A introdução da pessoa; o seu pedido; consulta ao registo (RDAP) para a antiguidade do domínio.
Fundamento jurídico	Execução da verificação solicitada: Art. 6(1)(b) do RGPD (utilização da verificação gratuita nos termos dos Termos de Serviço); subsidiariamente, (f). Limites e monitorização: Art. 6(1)(f). Interesse: impedir que o serviço seja utilizado como ferramenta contra sítios web de terceiros ou como canhão de spam. Ponderação: sem a ligação ao endereço e à sessão, os limites não poderiam ser aplicados; o prazo de sete dias é tão curto quanto o limite mais longo contado a partir dele.
Destinatários	Google (reCAPTCHA na submissão, B.23). Para a antiguidade do domínio, o scanner consulta o serviço de redirecionamento RDAP rdap.org, que reencaminha para o registo competente; só é transmitido o nome de domínio. Quando ocorre uma anomalia, o operador recebe um sinal via Telegram sem qualquer variável (sem anfitrião, sem endereço). O relatório pode ser visto por quem tiver a sua ligação aleatória.
País terceiro	EUA, através do reCAPTCHA (B.23).
Conservação	Registo de pedidos 7 dias (noturno, srv/cron_status.php). Anomalias resolvidas 90 dias após a resolução; as não resolvidas permanecem até alguém as resolver (secção 10). Os relatórios anónimos expiram após 30 dias; o processo noturno apaga então o relatório, a tarefa, o resultado da verificação, os formulários, os resultados e as imagens (fe_reports_aufraeumen()). Um administrador pode libertar manualmente as entradas de um endereço; isso apaga o respetivo registo das últimas 24 horas.
Medidas técnicas e organizativas	Secção 8. Paragem de emergência de todas as verificações anónimas na área de administração; contrapressão que não aceita novas verificações gratuitas quando existe acumulação.

B.5 Verificação de sítios web de terceiros pelo crawler

Campo	Entrada
Finalidade	Verificação de segurança de formulários de contacto públicos: proteções contra spam e abusos, características de proteção de dados e de acessibilidade, scripts de terceiros incorporados, comportamento após rejeição no banner de cookies, apresentação em dispositivos móveis. Aplica-se às verificações sem conta (B.4), aos domínios numa conta ainda não verificados e como base para o estudo (B.7) e para a verificação de potenciais clientes (B.8). No caso de domínios verificados numa conta, atuamos por conta do Cliente (A.4).
Comportamento do crawler	Identificador próprio com referência à página do crawler; lê o robots.txt antes da verificação e para se uma regra disallow abranger a página inicial (o mesmo se o robots.txt não puder ser acedido ou ocorrer um erro de servidor); as regras disallow para subcaminhos individuais não são respeitadas separadamente. O pulso de formulários, a obtenção da prova, a ferramenta de cabeçalhos e a procura de ficheiros expostos não leem o robots.txt. No máximo oito páginas públicas por verificação, mais até três páginas com um clique em “Rejeitar” no banner de cookies, até três páginas em vista de telemóvel, sondagens ativas para domínios verificados e até cinco páginas por detrás de um início de sessão (A.5); as páginas são carregadas uma após a outra, não em paralelo; apenas endereços públicos, sem redes internas, os redirecionamentos são verificados de novo; a lista de bloqueio e o opt-out são verificados antes da aceitação e uma segunda vez no scanner. Passivo: sem prova de controlo, nada é submetido para os Clientes (exceção: verificações internas dos nossos próprios domínios de teste e demonstração, B.6).
Categorias de titulares dos dados	Operadores dos sítios web verificados (quando sejam pessoas singulares, como empresários em nome individual); pessoas que estejam visíveis por acaso nas páginas verificadas.
Categorias de dados pessoais	Como em A.4: endereços e títulos das páginas, estrutura dos formulários (nomes, tipos e etiquetas de campos, sem valores de campos), proteções, scripts de terceiros (endereços; os IDs de conta de píxeis e ferramentas de gravação são substituídos antes do armazenamento), comportamento do banner de cookies, capturas de ecrã (área visível da página inicial, formulários). Se aparecer um endereço de destinatário no formulário, apenas o seu domínio (scans, forms, findings, scan_screenshots).
Origem	Páginas acessíveis ao público.
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: realização da verificação de segurança solicitada; alertar os operadores de sítios web para fragilidades que possam prejudicar os seus visitantes. Ponderação: só é lido o que qualquer visitante vê, em pequena escala e sem submeter nada; o operador pode excluir permanentemente o seu domínio em qualquer momento, sem prova. As informações nos termos do Art. 14 do RGPD são prestadas através da página do crawler, do opt-out e da Política de Privacidade; saber se isto é suficiente nos termos do Art. 14(5)(b) é uma questão em aberto para a revisão jurídica.
Destinatários	Quem desencadeia o relatório e qualquer pessoa a quem este entregue a ligação aleatória; o modelo de linguagem local no nosso próprio servidor, quando o tipo de formulário não é claro (estrutura do formulário, título e endereço da página, texto visível do formulário). Os avisos de vulnerabilidades relativos a versões de plugins nunca aparecem em relatórios anónimos.
País terceiro	Nenhum.
Conservação	Anónimos: 30 dias (B.4). Verificação de potenciais clientes: 90 dias (B.8). Estudo: até à publicação (B.7). Domínio numa conta: no máximo 13 meses, mantém-se a última verificação; imediatamente com o domínio. Verificações internas do operador sem domínio e sem relatório (como as criadas a partir da linha de comandos): sem prazo de conservação (secção 10). Os ficheiros temporários no servidor de análise são apagados após cada execução.
Medidas técnicas e organizativas	Secção 8. Em especial: contentor de verificação separado com privilégios reduzidos, sistema de ficheiros apenas de leitura, limite de memória e rede própria; dupla verificação do destino.

B.6 Submissões de teste ativas

Campo	Entrada
Finalidade	Verificar se um formulário de contacto aceita uma submissão sem proteção, se o CAPTCHA, a armadilha (honeypot), o token, a validação do endereço de e-mail e a limitação de frequência produzem efeito do lado do servidor, e se é possível injetar cabeçalhos.
Pré-requisito	Para os Clientes, apenas para domínios para os quais foi apresentada prova de controlo (registo DNS, meta tag, ficheiro ou plugin ligado); além disso, o operador utiliza uma ferramenta interna de linha de comandos para criar verificações com o nível “verificado” para os nossos próprios domínios de teste e demonstração. Apenas com o interruptor global ativado, apenas para um formulário classificado com segurança como formulário de contacto geral. Nunca para encomendas, reservas, registos, newsletters, pagamentos, carregamentos de ficheiros, campos obrigatórios com dados pessoais reais, nem para domínios de autoridades públicas, instituições de saúde ou de ensino.
Categorias de titulares dos dados	Os trabalhadores do Cliente que recebem os e-mails do formulário.
Categorias de dados pessoais	A submissão de teste não contém dados pessoais: remetente “FormExposed Security Scanner”, o nosso próprio endereço de remetente ou um endereço em .invalid, uma linha de assunto identificada e um texto na língua da página com referência à página do crawler e ao opt-out e o número da verificação. Armazenado por nós: a resposta da página, os resultados, uma imagem da página seguinte (como em A.4).
Âmbito	No máximo cinco submissões por verificação (definição, predefinição 5); recorrentes com a frequência de verificação do plano, diariamente no plano mais elevado.
Origem	A instrução do Cliente.
Fundamento jurídico	Execução do contrato com o Cliente (Art. 6(1)(b) do RGPD); as submissões vão para o próprio formulário do Cliente. Relativamente aos destinatários do lado do Cliente: a organização do Cliente.
Destinatários	O Cliente (o respetivo e-mail de formulário).
País terceiro	Nenhum através de nós.
Conservação	Resultados como em A.4.
Medidas técnicas e organizativas	Secção 8. A injeção de cabeçalhos é apenas detetada, nunca executada com um destinatário real; a validação do endereço de e-mail utiliza apenas um domínio que não pode existir.

B.7 Estudo “Índice de segurança de formulários”

Campo	Entrada
Finalidade	Estatísticas sobre a proteção de formulários de contacto num país ou setor. Só são publicados totais, sem nomes de sítios web; segmentos apenas a partir de 20 páginas com formulário.
Categorias de titulares dos dados	Operadores dos sítios web da lista; pessoas visíveis por acaso.
Categorias de dados pessoais	Como em B.5, apenas passivo. Além disso, a lista: anfitrião, segmento, estado, tarefa (study_domains); estudo com título, país, totais de resultados (studies).
Origem	Uma lista de sítios web públicos compilada pelo operador; as próprias páginas.
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: afirmações estatísticas sobre o estado da segurança dos formulários. Ponderação: passivo, com limitação de ritmo (poucas tarefas por execução), aplicam-se a lista de bloqueio e o opt-out, publicação apenas como totais, os dados brutos são apagados.
Destinatários	O público, apenas totais.
País terceiro	Nenhum.
Conservação	Os dados brutos (resultados das verificações, formulários, resultados, imagens, tarefas) são apagados aquando da publicação (fe_studie_veroeffentlichen()). A lista de anfitriões com segmento mantém-se posteriormente; não existe prazo de conservação para ela nem para estudos que nunca sejam publicados (secção 10). O operador decide que listas são verificadas e se os estudos são publicados.
Medidas técnicas e organizativas	Secção 8.

B.8 Verificação de potenciais clientes (modo de angariação para agências)

Campo	Entrada
Finalidade	Uma agência (plano Business) verifica passivamente o sítio web de um potencial cliente e recebe um relatório resumido com a sua marca e o relatório passivo. Não contactamos ninguém; é a própria agência que transmite a ligação.
Categorias de titulares dos dados	Operador do sítio web verificado; pessoas visíveis por acaso; trabalhadores da agência que desencadeiam a verificação.
Categorias de dados pessoais	Como em B.5, apenas passivo. Além disso: espaço de trabalho, pessoa que desencadeia a verificação, anfitrião, identificador aleatório do relatório, hora (prospect_checks).
Origem	A introdução da agência; páginas públicas.
Fundamento jurídico	Art. 6(1)(f) do RGPD (o nosso interesse em prestar o serviço e o interesse da agência numa abordagem fundamentada). As funções da agência e nossas e as obrigações da agência ao transmitir o relatório são questões em aberto para a revisão jurídica: se a agência enviar o relatório por e-mail sem solicitação ou efetuar uma chamada telefónica, trata-se de marketing direto que exige consentimento nos termos do Art. 398 PKE e do § 7(2) UWG (a lei alemã contra a concorrência desleal), mesmo entre empresas. Isso é da responsabilidade da agência; os Termos de Serviço obrigam-na em conformidade.
Destinatários	A agência e qualquer pessoa a quem esta entregue a ligação.
País terceiro	Nenhum.
Conservação	O relatório e o resultado da verificação expiram após 90 dias e são então apagados pelo processo noturno (fe_reports_aufraeumen()); a entrada da verificação é apagada após 90 dias no processo diário de proteção coletiva a partir das 04:00 (srv/cron_status.php). Com o espaço de trabalho, imediatamente.
Medidas técnicas e organizativas	Secção 8. Quota mensal (definição, predefinição 30); a mesma página no prazo de sete dias devolve o mesmo relatório; aplica-se o opt-out.

B.9 Ferramenta de cabeçalhos sem conta

Campo	Entrada
Finalidade	Classificação gratuita (A+ a F) dos cabeçalhos de segurança da página inicial de um domínio. Dois pedidos, sem navegador, sem formulário, sem submissão.
Categorias de titulares dos dados	Pessoas que utilizam a ferramenta; operadores do domínio verificado.
Categorias de dados pessoais	Registo de pedidos como em B.4 (origem “headers”, endereço IP, hash da sessão, anfitrião). Resultado: anfitrião, classificação, pontos, cabeçalhos avaliados (header_checks).
Fundamento jurídico	Art. 6(1)(f) do RGPD, como em B.4 e B.5.
Destinatários	Google (reCAPTCHA, B.23).
País terceiro	EUA, através do reCAPTCHA.
Conservação	Registo de pedidos 7 dias; resultados após atualmente 90 dias (processo noturno de apagamento, parte “header_checks”, definição “headers_keep_days”). Para domínios numa conta, a classificação é determinada de novo diariamente e armazenada junto do domínio.
Medidas técnicas e organizativas	Secção 8. Limites por endereço IP e por dia; aplica-se o opt-out.

B.10 Contas de cliente

Campo	Entrada
Finalidade	Gestão de contas de cliente, espaços de trabalho e planos.
Categorias de titulares dos dados	Clientes (profissionais) e os membros das suas equipas com conta própria.
Categorias de dados pessoais	Endereço de e-mail e forma normalizada, palavra-passe apenas como hash, nome próprio (obrigatório), apelido e empresa (se indicados); a aplicação não armazena o endereço nem o número de IVA, que só são indicados na Stripe (B.26); estado, língua, modo de apresentação, moeda, plano e estado de faturação, ID de cliente e de subscrição da Stripe, fim do período de faturação, cancelamento no fim do período, identificadores de confirmação e de reposição com expiração, novo endereço de e-mail até à confirmação, hora do registo, do último início de sessão e último endereço IP, hora em que todas as sessões foram revogadas, dados de dois fatores (B.11), relatório mensal ativado/desativado, hora do e-mail de lembrete, desbloqueios através de códigos, código de referência e referenciação (users). Espaços de trabalho com nome, horas, estado (workspaces); pertença com função e data de adesão (workspace_users).
Origem	Registo e definições pela pessoa; estado de faturação a partir da Stripe.
Fundamento jurídico	Art. 6(1)(b) do RGPD (contrato). Último endereço IP: (f) (segurança da conta).
Destinatários	Stripe (B.26); fornecedor de serviços de correio eletrónico para os e-mails da conta (B.25). Os membros do mesmo espaço de trabalho veem o nome, o endereço de e-mail e a função dos outros membros.
País terceiro	Através da Stripe e do fornecedor de serviços de correio eletrónico.
Conservação	Até à eliminação pelo titular da conta. Na eliminação, os espaços de trabalho próprios do titular que ninguém mais utiliza são apagados com todos os domínios e respetivos dados; os espaços de trabalho com outros membros passam para outro membro, em primeiro lugar para os administradores e, entre estes, para o mais antigo. As pertenças, os tokens de memorização, os dispositivos, as chaves de API, os códigos do Telegram pendentes, as avaliações de relatórios (B.35) e a linha da conta são apagados; uma subscrição paga em curso é primeiro terminada de imediato na Stripe, sem reembolso (www/ajax.php, fe_konto_reste_loeschen()). Um cancelamento na área de faturação, pelo contrário, produz efeitos no fim do período; depois disso, a conta continua no plano gratuito. O que se mantém consta da secção 6.4. As contas nunca confirmadas e nas quais nunca foi iniciada sessão são apagadas após 30 dias, salvo se outro membro estiver associado ao seu espaço de trabalho (processo noturno de apagamento, parte “pending_accounts”). Não há apagamento de contas inativas. Se o contrato relativo à conta cessar de outra forma, por exemplo por denúncia da nossa parte, eliminamos a conta o mais tardar 30 dias após o termo do contrato; atualmente, isto é feito manualmente (compromisso assumido no Acordo de Tratamento de Dados).
Medidas técnicas e organizativas	Secção 8.

B.11 Início de sessão, dispositivos, segundo fator e registo de atividade

Campo	Entrada
Finalidade	Proteção das contas: limitação das tentativas de início de sessão e de outras tentativas de palavra-passe, apresentação e revogação de dispositivos com sessão iniciada, início de sessão com dois fatores, rastreabilidade das alterações.
Categorias de titulares dos dados	Titulares de contas e membros de equipas; pessoas que tentam um início de sessão, um registo ou a palavra-passe de um portal de clientes.
Categorias de dados pessoais	Tentativas de início de sessão: endereço IP, endereço de e-mail introduzido, êxito, hora (login_attempts). Dispositivos: hash do identificador de sessão (nunca o próprio identificador), ligação ao token de memorização, endereço IP, identificação do navegador e o navegador, sistema operativo e tipo de dispositivo dela derivados, horas do início de sessão, da última atividade e da revogação e, no caso do “Ver como cliente”, o identificador da pessoa do apoio (login_sessions). Tokens de memorização para “Manter sessão iniciada”: seletor, verificador, expiração (remember_tokens). Dois fatores: segredo cifrado, hora da ativação, último intervalo de tempo utilizado, códigos de recuperação apenas como hash (em users). Registo de atividade: conta, espaço de trabalho, ação, alvo, pormenores, endereço IP, país, hora (audit_logs). Contadores de tentativas para o início de sessão, o segundo fator, a confirmação da palavra-passe, a reposição da palavra-passe, o registo e as palavras-passe dos portais de clientes: uma chave HMAC derivada da finalidade e do ID da conta (para um endereço desconhecido ou para uma reposição, o endereço de e-mail em minúsculas), do endereço IP, da conta e do endereço IP em conjunto, ou do ID do portal (também em conjunto com o endereço IP), número de tentativas, expiração; os endereços de e-mail e IP não são aí armazenados em texto simples (tabela auth_attempt_buckets).
Fundamento jurídico	Art. 6(1)(b) do RGPD em conjugação com o Art. 32 (lista de dispositivos, segundo fator) e (f) (tentativas de início de sessão, registo de atividade). Interesse: proteger as contas contra a usurpação, documentar as alterações (Art. 5(2)). Ponderação: um endereço truncado não responde à pergunta “fui eu?”; o registo de atividade tem de sobreviver a um litígio que só surja meses mais tarde.
Destinatários	Nenhum. O titular da conta vê os seus dispositivos e recebe as tentativas de início de sessão, os dispositivos e as atividades na exportação de dados; durante uma sessão de “Ver como cliente”, nem o endereço IP nem o navegador da pessoa do apoio aparecem aí.
País terceiro	Nenhum.
Conservação	Tentativas de início de sessão 7 dias; após um início de sessão bem-sucedido, as tentativas falhadas a partir do mesmo endereço são apagadas imediatamente. Contadores de tentativas no fim da respetiva janela temporal (atualmente 15 minutos, uma hora para a reposição da palavra-passe e o registo); os expirados são apagados no acesso seguinte e pelo processo noturno. Dispositivos 90 dias após a última utilização ou após a revogação (processo noturno de apagamento, parte “sessions”), imediatamente com a conta. Os tokens de memorização expiram após 30 dias. Registo de atividade 365 dias (noturno); quando uma conta é eliminada, as suas entradas mantêm-se até ao fim do prazo de conservação (secção 6.4).
Medidas técnicas e organizativas	Secção 8.

B.12 Prova da celebração do contrato

Campo	Entrada
Finalidade	Provar que versão dos Termos de Serviço, do Acordo de Tratamento de Dados e da Política de Privacidade um Cliente aceitou ou de que tomou conhecimento no momento do registo, e que o Cliente utiliza o serviço para a sua atividade profissional.
Categorias de titulares dos dados	Clientes.
Categorias de dados pessoais	Por documento: conta, documento, versão (hash do texto apresentado), ocasião, endereço IP, identificação do navegador, hora (legal_consents). A própria versão apresentada, com texto integral, língua, título e endereço, uma vez por versão (legal_versions; não contém dados pessoais).
Fundamento jurídico	Art. 6(1)(b) e (f) do RGPD (prova da celebração do contrato, defesa contra pretensões).
Destinatários	Nenhum. O titular da conta recebe os seus registos na exportação de dados.
País terceiro	Nenhum.
Conservação	Enquanto a conta existir; após a eliminação da conta, quatro anos a contar do consentimento, sendo depois apagados no processo noturno (srv/cron_status.php). Fundamentação no código: prazo de prescrição de três anos a contar do fim do ano, arredondado por excesso. Saber se o direito polaco sugere um prazo diferente faz parte da revisão jurídica.
Medidas técnicas e organizativas	Secção 8. Se faltar algum dos três documentos, o registo fica encerrado.

B.13 Convites para equipas

Campo	Entrada
Finalidade	Convidar outras pessoas para um espaço de trabalho.
Categorias de titulares dos dados	Pessoas convidadas.
Categorias de dados pessoais	Endereço de e-mail, função, identificador do convite, pessoa que convida, expiração, hora da aceitação (workspace_invites); o e-mail de convite na caixa de saída (B.25).
Origem	Introduzidos pelo membro que convida.
Fundamento jurídico	Art. 6(1)(b) do RGPD relativamente ao Cliente; perante a pessoa convidada, (f) (interesse do Cliente em envolver a sua equipa).
Destinatários	Fornecedor de serviços de correio eletrónico (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
País terceiro	Através do fornecedor de serviços de correio eletrónico.
Conservação	Um convite é válido durante 14 dias e apenas enquanto a pessoa que convida for proprietária ou administradora do espaço de trabalho. Os convites não aceites após a expiração, os aceites 30 dias após a aceitação (noturno, srv/cron_status.php e parte “invites” em cfg/fristen_lib.php). Com o espaço de trabalho, imediatamente.
Medidas técnicas e organizativas	Secção 8.

B.14 “Ver como Cliente” pelo suporte

Campo	Descrição
Finalidade	Um superadministrador vê a aplicação tal como um Cliente a vê, a fim de resolver uma questão de suporte (“o botão não me aparece”).
Categorias de titulares dos dados	O Cliente em causa; o superadministrador.
Categorias de dados pessoais	Tudo o que o Cliente vê na aplicação. Registado: uma linha de dispositivo separada com o identificador do superadministrador (login_sessions), início e fim no registo de atividades (audit_logs).
Fundamento jurídico	Art. 6(1)(b) do RGPD (suporte enquanto parte do serviço), subsidiariamente (f).
Limites	No máximo uma hora, seguida de terminação completa da sessão. Terminar a visualização também termina por completo a sessão do superadministrador, incluindo a sessão de onde veio; só regressa à área de administração iniciando nova sessão com palavra-passe e segundo fator. Termina imediatamente se o superadministrador for despromovido ou bloqueado. Tudo o que altere a conta do Cliente fica bloqueado: palavra-passe, endereço de e-mail, segundo fator, dispositivos, subscrição, exportação, eliminação, transferência. A área de administração está fechada durante a sessão. O Cliente vê o acesso na sua lista de dispositivos e na exportação de dados como acesso do suporte.
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	Linha de dispositivo 90 dias, registo de atividades 365 dias.
MTO	Secção 8.

B.15 Domínios, prova de controlo e monitorização

Campo	Descrição
Finalidade	O serviço principal para os Clientes: manter domínios na conta, apresentar prova de controlo, verificar regularmente e detetar alterações. Inclui o pulso do formulário (um pedido ligeiro sem navegador a cada 10 a 30 minutos, consoante o plano), a vigilância diária do DNS de correio e dos certificados, a data de expiração do domínio, listas de bloqueio, ficheiros expostos, versões visíveis do exterior, inventário de scripts, alterações visuais ao formulário, falhas de fornecedores de CAPTCHA e de correio, e a vigilância de vulnerabilidades em plugins de formulários.
Categorias de titulares dos dados	Clientes e os membros das suas equipas; operadores dos domínios, quando sejam pessoas singulares.
Categorias de dados pessoais	Domínio com anfitrião, identificador público, nota, etiqueta do cliente, tipo e identificador da prova, frequência de verificação, monitorização ligada/desligada, janelas de manutenção, valor por pedido de contacto, identificadores para o selo, a verificação de entrega e o deploy hook, chave do plugin, estados e resultados mais recentes das vigilâncias (DNS, certificado, autenticidade do e-mail do formulário, listas de bloqueio, ficheiros expostos, cabeçalhos, versões) (domains). Pulso por página de formulário (form_pulse). Vulnerabilidades a partir das versões dos plugins (vuln_hits). Inventário de scripts com endereço, hash, tamanho, aprovação com a pessoa que aprovou e o motivo (script_inventory, script_changes). Verificações como em A.4. Para ficheiros expostos, são guardados o caminho, a gravidade e o tipo, nunca o conteúdo.
Pedidos a terceiros	Consultas DNS (SPF, DMARC, MX, registo de prova). Consulta ao registo através de RDAP de acordo com o diretório da IANA: apenas o nome de domínio. Listas de bloqueio DNS (SpamCop, PSBL, Mailspike, SURBL; Spamhaus apenas com credenciais de acesso guardadas, atualmente não): endereços IP do servidor web e do servidor de correio e o nome de domínio, sem dados de visitantes. Google Web Risk apenas se configurado (atualmente não): o endereço da página inicial. Autoridade de carimbo temporal: apenas um valor de hash (B.19). WPVulnerability: apenas o identificador de um plugin ou tema, ou a versão do WordPress; a comparação com a versão do plugin instalada é feita por nós. Páginas de estado da Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun e Brevo: nada é transmitido além do próprio pedido.
Origem	Cliente; pedidos à página do Cliente; diretórios públicos.
Fundamento jurídico	Art. 6(1)(b) do RGPD.
Destinatários	Os serviços indicados não recebem dados pessoais dos nossos Clientes, na medida em que os nomes de domínio e os endereços de servidor de uma empresa não são dados pessoais; no caso de empresários em nome individual, o nome de domínio pode constituir um dado pessoal. Os membros do espaço de trabalho veem o domínio.
País terceiro	Os pedidos podem chegar a serviços em países terceiros (por exemplo, consultas ao registo, listas de bloqueio). Só é transmitido o que consta da linha “Pedidos a terceiros”.
Conservação	Até à eliminação do domínio. fe_domain_loeschen() elimina então de imediato os resultados de verificação, formulários, constatações, imagens, relatórios, tarefas, destinos de alerta e registo de alertas, incidentes, códigos Telegram, entregas, pulso, vulnerabilidades e provas; através de chaves estrangeiras, os formulários monitorizados, execuções de navegador, conta de teste e contadores de formulários; os dados do plugin do anfitrião, se nenhum outro domínio o referir. São também eliminados o inventário de scripts e as alterações de scripts do domínio; não têm prazo de conservação próprio (secção 6.4). Resultados de verificação no máximo 13 meses, mantendo-se o último.
MTO	Secção 8. Vigilância de ficheiros expostos e de versões apenas para domínios verificados, no máximo um pedido por caminho, apenas os primeiros 8 KB; sondar caminhos de terceiros sem ter sido pedido seria uma ferramenta de ataque.

B.16 Alertas, incidentes e escalonamento perante o titular da conta

Campo	Descrição
Finalidade	Informar o Cliente sobre falhas e alterações, respeitar janelas de manutenção, confirmar e escalar incidentes. Quando os destinos são terceiros, atuamos por conta do Cliente (A.3); quando se trata do próprio titular da conta, aplica-se o aqui descrito.
Categorias de titulares dos dados	Titulares de contas e membros das equipas enquanto destinatários.
Categorias de dados pessoais	Como em A.3. As notificações são apresentadas no idioma do titular da conta.
Fundamento jurídico	Art. 6(1)(b) do RGPD.
Destinatários	Prestador de serviços de correio eletrónico; serviços de chat escolhidos (4.1).
País terceiro	Consoante o canal (4.1).
Conservação	Como em A.3: registo de entregas 90 dias, notificações de resumo 30 dias após a entrega, incidentes até à resolução e depois 180 dias. Destinos de alerta juntamente com o domínio.
MTO	Secção 8.

B.17 Relatório mensal às contas

Campo	Descrição
Finalidade	No dia 1 de cada mês a partir das 08:00 (recuperação até ao dia 3), um e-mail por conta abrangendo todos os seus domínios: nível, pontuação e variação, alertas, bots bloqueados, envio de e-mails, valor de comparação.
Categorias de titulares dos dados	Titulares de contas ativas com o relatório mensal ativado.
Categorias de dados pessoais	Endereço de e-mail, idioma, indicadores dos domínios.
Fundamento jurídico	Art. 6(1)(b) do RGPD (parte do serviço). Pode ser cancelado nas definições; pode ser desativado centralmente.
Destinatários	Prestador de serviços de correio eletrónico (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
País terceiro	Através do prestador de serviços de correio eletrónico.
Conservação	Sem armazenamento separado; o e-mail permanece na caixa de saída durante 30 dias (B.25).
MTO	Secção 8.

B.18 Selo e página pública de confirmação

Campo	Descrição
Finalidade	Um Cliente pode incorporar uma imagem de selo no seu sítio web e ligá-la a uma página pública de confirmação. O selo só mostra “Protegido” se o domínio estiver verificado, a monitorização estiver em curso e a última verificação concluída tiver no máximo 45 dias e tiver resultado em “Protegido” ou “Parcialmente protegido”; caso contrário, mostra de forma neutra “Verificação do formulário de contacto”. A página de confirmação indica o nível e a data, sem constatações individuais.
Categorias de titulares dos dados	Visitantes do sítio web do Cliente cujo navegador carrega a imagem; visitantes da página de confirmação.
Categorias de dados pessoais	Quando a imagem é carregada: endereço IP, hora, endereço pedido, página de referência e identificação do navegador no registo do servidor web (B.1). O endereço da imagem não inicia qualquer sessão, não define cookies nem escreve no registo de visualizações de páginas. A página de confirmação é uma página normal (B.2, B.3).
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: fornecer a imagem e manter a segurança do funcionamento. Saber se o Cliente e nós somos responsáveis conjuntos pelo tratamento quanto à transmissão do endereço IP do visitante, na aceção da jurisprudência sobre conteúdos de terceiros incorporados, e se é necessário um acordo nos termos do Art. 26, é uma questão em aberto para a revisão jurídica. O Cliente recebe uma proposta de texto para a sua política de privacidade.
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	14 dias (registo do servidor web). A imagem fica em cache durante uma hora. Quando o selo é desativado, o identificador deixa de ser válido.
MTO	Secção 8.

B.19 Registo de prova e carimbo temporal

Campo	Descrição
Finalidade	Um registo por domínio e por mês (planos pagos): o que foi verificado, com que resultado, o que foi comunicado e o que mudou, como prova para efeitos de responsabilidade, seguradoras ou auditorias de fornecedores. Cada versão recebe um número de verificação; uma página pública confirma o domínio, o período e os indicadores, sem pormenores. Desde 7 de outubro de 2026, uma autoridade de carimbo temporal nos termos do RFC 3161 confirma a hora.
Categorias de titulares dos dados	Clientes; indiretamente, pessoas que possam ser referidas no registo como aprovadoras ou como tendo tomado conhecimento.
Categorias de dados pessoais	Domínio, mês, número de verificação, hash do conteúdo (SHA-512), resumo e dados do registo, resposta de carimbo temporal, autoridade de carimbo temporal e hora, tentativas falhadas (proof_docs).
Fundamento jurídico	Art. 6(1)(b) do RGPD.
Destinatários	A autoridade de carimbo temporal (por defeito Certum, alternativa DigiCert) recebe apenas o hash do registo, não o seu conteúdo. Público: indicadores através da página de confirmação. O Cliente e qualquer pessoa a quem o Cliente entregue o registo ou o número de verificação.
País terceiro	Sem transferência de dados pessoais: um hash não permite qualquer dedução quanto ao conteúdo. A autoridade alternativa está sediada nos EUA.
Conservação	Até à eliminação do domínio (fe_domain_loeschen()). O carimbo temporal não é um selo temporal qualificado na aceção do eIDAS.
MTO	Secção 8.

B.20 Plugin e extensão: verificação, ligação e transmissão

Campo	Descrição
Finalidade	O plugin para WordPress e a extensão para TYPO3 podem pedir uma verificação (mesmo sem conta), ligar-se a uma conta (a instalação conta como prova de controlo com um clique na conta), desbloquear funções de proteção, comunicar diariamente indicadores (A.9) e comunicar de imediato erros de e-mail e o modo de manutenção.
Categorias de titulares dos dados	Clientes; operadores de sítios web que utilizam o plugin sem conta.
Categorias de dados pessoais	Por anfitrião: versão do plugin e do CMS, número de verificações, último identificador de comunicação, hash do segredo de ligação, primeiro e último contacto (plugin_sites). Códigos de ligação de utilização única sob a forma de hash com prazo de validade (plugin_connect_tokens). Códigos de implementação de uma agência sob a forma de hash com prefixo, etiqueta, utilizações, pessoa que os criou (workspace_connect_codes). Registo de pedidos com o endereço IP do servidor que faz a chamada (B.4). A chave do plugin é publicamente visível no cabeçalho do sítio web; é um hash do segredo, e o próprio segredo só é guardado sob a forma de hash e nunca é devolvido.
Fundamento jurídico	Art. 6(1)(b) do RGPD (conta); sem conta (f) (verificação pedida, prevenção de abusos).
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	Os dados de um anfitrião são eliminados assim que nenhum domínio o refira; a linha de um plugin sem conta só após 90 dias sem contacto (processo noturno de eliminação, parte “orphan_hosts”). Códigos de utilização única um dia após expirarem. Códigos de implementação juntamente com o espaço de trabalho.
MTO	Secção 8. Desde 27 de setembro de 2026, o servidor só aceita pares de chaves associados ao sítio web; os segredos de ligação mais antigos e não associados foram eliminados.

B.21 Proteção em enxame

Campo	Descrição
Finalidade	Defesa partilhada contra spam: os sítios web ligados comunicam os domínios das ligações contidas em mensagens que a sua camada de proteção travou. Um domínio que surja em pelo menos três sítios web com pelo menos cinco ocorrências em sete dias é colocado numa lista que é devolvida a todos os sítios web ligados; a sua camada de proteção move as mensagens com essas ligações para quarentena, nunca para o esquecimento.
Categorias de titulares dos dados	Titulares dos domínios de ligações comunicados, quando sejam pessoas singulares (por exemplo, o operador de um sítio de spam em nome próprio). Não os remetentes nem os destinatários das mensagens: endereços, textos e nomes não são comunicados.
Categorias de dados pessoais	Sinais: tipo, domínio, anfitrião que comunica, dia, ocorrências (swarm_signals). Lista: tipo, domínio, número de sítios web e de ocorrências, horas (swarm_list). Grandes serviços, os domínios dos nossos Clientes e exceções definidas pelo operador nunca são incluídos na lista.
Redes IP	A partilha de redes IP (/24, /48) foi preparada. Está desativada e o plugin não comunica nenhuma; só será ativada após uma revisão jurídica, porque os endereços IP são dados pessoais.
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: proteger os formulários de todos os Clientes contra vagas de spam. Ponderação: apenas domínios, limiares mínimos contra envenenamento, nenhuma perda de mensagens, remoção possível a qualquer momento.
Destinatários	Todos os sítios web ligados (a lista de domínios).
País terceiro	Consoante a localização dos sítios web ligados; a lista pode também chegar a sítios web fora do EEE. Só constitui dados pessoais em casos-limite (domínios de pessoas singulares). O fundamento de transferência nos termos do Capítulo V do RGPD para estes casos está ainda por determinar (questão em aberto para a revisão jurídica).
Conservação	Sinais 30 dias (processo diário do enxame a partir das 04:00, cfg/swarm_lib.php). A lista é recalculada diariamente; o que deixar de atingir o limiar é retirado.
MTO	Secção 8.

B.22 Chaves de API, interface de programação e servidor MCP

Campo	Descrição
Finalidade	Acesso das ferramentas próprias do Cliente (API REST, Zapier, Make, servidor MCP para assistentes de IA) aos domínios, verificações e incidentes do Cliente.
Categorias de titulares dos dados	Clientes que criam chaves.
Categorias de dados pessoais	Chave apenas sob a forma de hash, prefixo, etiqueta, datas de criação, última utilização e revogação (api_keys). Chamadas por minuto (api_usage).
Fundamento jurídico	Art. 6(1)(b) do RGPD.
Destinatários	A ferramenta que o Cliente dota da chave; é o Cliente quem a determina.
País terceiro	Consoante a ferramenta do Cliente.
Conservação	Chaves até serem revogadas, de imediato juntamente com a conta; chaves sem conta (dados antigos) durante a noite. Contadores de chamadas após um dia (ocasionalmente limpos durante uma chamada).
MTO	Secção 8.

B.23 reCAPTCHA e a nossa própria proteção de formulários

Campo	Descrição
Finalidade	Defesa contra acessos automatizados aos nossos próprios formulários: verificação gratuita, ferramenta de cabeçalhos, opt-out, início de sessão, registo, palavra-passe esquecida e reposição, suporte e contacto. Além disso, a nossa própria proteção sem terceiros: armadilha (campo oculto), verificação de tempo assinada e token CSRF. Desde 29 de outubro de 2026, também a nossa proteção de formulários formconfirmed (prova de trabalho e token de verificação de utilização única) na verificação gratuita, no registo, no início de sessão e em «palavra-passe esquecida».
Categorias de titulares dos dados	Pessoas que submetem estes formulários.
Categorias de dados pessoais	Na Google: endereço IP, dados do navegador e do dispositivo, dados comportamentais, cookies da Google. Connosco: a avaliação da Google (pontuação e ação) apenas no momento da verificação, sem armazenamento, nem mesmo quando uma submissão é rejeitada. Na nossa própria proteção de formulários: endereço IP (conservado apenas de forma truncada e com hash), página, momentos, campo-armadilha preenchido sim/não; nenhum conteúdo.
Momento	O script da Google só é carregado quando um formulário protegido é submetido, não quando a página é aberta. A nossa própria proteção de formulários obtém a sua tarefa quando a página é aberta e efetua o cálculo logo que o formulário é utilizado. No sistema de desenvolvimento, o reCAPTCHA está desativado.
Fundamento jurídico	Art. 6(1)(f) do RGPD. Interesse: proteção contra bots, sobretudo na verificação gratuita, que de outro modo poderia ser utilizada contra sítios web de terceiros. Saber se o acesso ao equipamento terminal exige consentimento nos termos do § 25 TDDDG ou do Art. 399 PKE, apesar de o script só ser carregado na submissão, é uma questão em aberto para a revisão jurídica. A nossa própria proteção de formulários não define cookies, não guarda nada no navegador e não cria impressões digitais; destina-se a substituir o reCAPTCHA a longo prazo.
Destinatários	Google Ireland Limited; Google LLC. Na nossa própria proteção de formulários, nenhum.
País terceiro	EUA (apenas reCAPTCHA). Fundamento: certificação ao abrigo do Quadro de Privacidade de Dados UE-EUA ou cláusulas contratuais-tipo; a documentar em pormenor.
Conservação	reCAPTCHA: nenhum armazenamento da nossa parte; na Google, de acordo com as suas regras. Própria proteção de formulários: identificador com hash 1 hora, tokens de verificação utilizados no máximo 11 minutos, resultados da verificação sem endereço IP 30 dias.
Falha	Se a Google não responder no prazo de três segundos ou der uma resposta inutilizável, a submissão é rejeitada; o mesmo sucede com um token vazio e com uma resposta para uma ação diferente da do formulário. A verificação só é ignorada quando o reCAPTCHA está desativado. Na nossa própria proteção de formulários, uma submissão sem token de verificação válido é rejeitada; se o serviço não estava acessível para a tarefa, a submissão é admitida.
MTO	Secção 8.

B.24 Suporte e formulário de contacto

Campo	Descrição
Finalidade	Receber e responder a pedidos através da janela de suporte e da página de contacto. Ambas utilizam a mesma rota e a mesma tabela.
Categorias de titulares dos dados	Requerentes, com ou sem sessão iniciada.
Categorias de dados pessoais	Conta (se tiver sessão iniciada; aplica-se então o endereço da conta, não o introduzido), endereço de e-mail, motivo de uma lista fixa, texto até 4000 caracteres, estado, endereço IP completo, país, identificação do navegador, página de referência (apenas caminhos próprios), idioma, horas de receção e de resposta (support_requests); entrada no registo de atividades (sem texto); aviso de receção ao requerente na caixa de saída (B.25), com o texto até 2000 caracteres apenas para remetentes com sessão iniciada, sem o texto para pedidos feitos sem sessão iniciada.
Fundamento jurídico	Art. 6(1)(b) do RGPD quando o pedido diga respeito a um contrato; caso contrário (f). Endereço IP completo: (f) (limite de três pedidos por hora e por endereço, prevenção de abusos).
Destinatários	Prestador de serviços de correio eletrónico (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) para o aviso de receção e a resposta. O Telegram recebe um sinal fixo sem qualquer variável (“há um novo pedido de suporte”) e, portanto, nenhum dado pessoal.
País terceiro	Através do prestador de serviços de correio eletrónico.
Conservação	24 meses (processo noturno de eliminação, parte “support”); manualmente mais cedo. Quando uma conta é eliminada, os pedidos mantêm-se até ao fim do prazo de conservação (secção 6.4).
MTO	Secção 8. reCAPTCHA, a nossa própria proteção de formulários, limitação de pedidos.

B.25 Envio de e-mails (caixa de saída)

Campo	Descrição
Finalidade	E-mails transacionais: confirmação do registo e de novos endereços de e-mail, reposição de palavra-passe, convites, alertas, relatórios mensais, confirmações e comunicações do portal, avisos de receção e respostas do suporte, lembretes sobre o período experimental e a configuração, notificações operacionais aos operadores. Sem publicidade, sem e-mails a pessoas que não se tenham registado elas próprias nem tenham sido indicadas como destinatárias pelo Cliente.
Categorias de titulares dos dados	Destinatários destes e-mails.
Categorias de dados pessoais	Endereço do destinatário, assunto, conteúdo completo, endereço de resposta, finalidade, via de envio, estado, erro, tentativas, horas (mail_outbox). O conteúdo pode incluir ligações de confirmação e de reposição com identificadores válidos.
Fundamento jurídico	Art. 6(1)(b) do RGPD; para notificações operacionais (f).
Destinatários	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (envio); o titular da conta vê os e-mails que lhe foram enviados na exportação de dados (sem conteúdo).
País terceiro	Consoante o local de tratamento do prestador de serviços de correio eletrónico; o contrato e o fundamento de transferência estão ainda por documentar (secção 4).
Conservação	30 dias (durante a noite, srv/cron_status.php). Este prazo é deliberadamente o mais curto de todos os registos: um registo de envios longo seria uma coleção de chaves válidas. O processo de estado verifica a cada cinco minutos se é devida uma nova tentativa.
Estado	O envio de e-mails tem de estar configurado antes do lançamento. Enquanto o prestador de serviços de correio eletrónico, com a sua sede e fundamento, não estiver definido, os textos jurídicos apresentam uma marca.
MTO	Secção 8. Os e-mails falhados são reenviados a intervalos crescentes e abandonados após um número máximo de tentativas.

B.26 Pagamentos e faturação

Campo	Descrição
Finalidade	Celebração e gestão de subscrições (mensais ou anuais, pagas antecipadamente), período experimental de 14 dias sem cartão com lembrete três dias antes do fim, pagamento por fatura para subscrições anuais (desativado por defeito), desbloqueios através de códigos de alojamento e de parceiros sem pagamento, faturação, conservação para efeitos fiscais.
Categorias de titulares dos dados	Clientes.
Categorias de dados pessoais	Na Stripe: endereço de e-mail, nome, endereço de faturação, número de IVA, dados de pagamento, faturas; como metadados, o nosso ID de conta e o plano. Connosco: ID de cliente e de subscrição da Stripe, plano, estado, fim do período, cancelamento no fim do período (users); eventos da Stripe recebidos apenas com identificador, tipo, estado e horas, sem conteúdo (stripe_events); utilizações de códigos de alojamento com conta, campanha e prazo de validade (bundle_redemptions). Os dados do cartão nunca chegam até nós.
Origem	O Cliente no checkout da Stripe; eventos da Stripe.
Fundamento jurídico	Art. 6(1)(b) do RGPD; para a conservação para efeitos fiscais (c).
Destinatários	Stripe Payments Europe Limited (Irlanda); Stripe, Inc. (EUA). Em partes do processamento de pagamentos, a Stripe atua sob a sua própria responsabilidade; a repartição exata de funções faz parte da revisão jurídica.
País terceiro	EUA através da Stripe, Inc.; fundamento: Quadro de Privacidade de Dados ou cláusulas contratuais-tipo nos termos das condições da Stripe.
Conservação	Campos de faturação juntamente com a conta; uma subscrição em curso é terminada antes de a conta ser eliminada. Faturas e registos de faturação nos termos da legislação fiscal polaca durante cinco anos a contar do fim do ano em que terminou o prazo de pagamento do imposto; são mantidos na Stripe e podem ser obtidos no portal de cliente da Stripe. Os eventos da Stripe e as utilizações de códigos não têm prazo de conservação (secção 6.4).
MTO	Secção 8. Eventos da Stripe aceites apenas com assinatura válida; cada evento é processado uma única vez.

B.27 Cópias de segurança

Campo	Descrição
Finalidade	Recuperação após um erro: eliminação indevida, migração danificada.
Categorias de titulares dos dados	Todas as pessoas cujos dados constam da base de dados.
Categorias de dados pessoais	Dump completo e comprimido da base de dados da aplicação. As capturas de ecrã e os ficheiros de logótipo são mantidos fora da base de dados e não fazem parte desta cópia de segurança. As credenciais das contas de teste só constam da mesma sob a forma cifrada (A.5).
Procedimento	Todas as noites às 03:00, após o processo de eliminação, para que a cópia de segurança não leve consigo o que os prazos de conservação acabaram de eliminar. O dump só é mantido depois de o seu conteúdo ter sido verificado (código de saída, número de tabelas, linha final). Aos domingos, um teste de restauro carrega a cópia de segurança mais recente numa base de dados descartável e compara-a tabela a tabela. Se algo falhar, é emitido um sinal e enviado um e-mail aos operadores.
Fundamento jurídico	Art. 6(1)(f) do RGPD, em conjugação com o Art. 32(1)(c).
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	14 dias; os dumps mais antigos só são removidos após uma nova cópia de segurança bem-sucedida (cfg/backup_lib.php). As eliminações efetuadas durante este período só chegam à cópia de segurança quando esta expira; se forem restaurados dados a partir de uma cópia de segurança, os pedidos de eliminação são novamente aplicados a seguir.
Localização	As cópias de segurança encontram-se atualmente no mesmo local que a base de dados e não estão cifradas separadamente; está prevista uma cópia cifrada num segundo local (secções 8.1 e 10).
MTO	Secção 8.

B.28 Registo de erros e alerta de erros

Campo	Descrição
Finalidade	Encontrar e corrigir erros antes de um Cliente os comunicar. Novos tipos de erro e vagas de erros são comunicados aos operadores, juntamente com uma síntese diária a partir das 08:00.
Categorias de titulares dos dados	Utilizadores cujo pedido provoca um erro; indiretamente, pessoas cujos dados surjam numa mensagem de erro.
Categorias de dados pessoais	Nível, origem, mensagem, contexto em JSON, ID de conta da sessão, hora (error_logs). Tipos de erro: impressão digital, padrão (do qual foram removidos endereços de e-mail, endereços, números e identificadores), uma mensagem de exemplo inalterada com até 2000 caracteres, primeira e última ocorrência, contagem (error_kinds).
Fundamento jurídico	Art. 6(1)(f) do RGPD (segurança operacional, Art. 32).
Destinatários	Os operadores por e-mail através do prestador de serviços de correio eletrónico: para um novo tipo de erro, a origem e o texto em bruto da mensagem até 400 caracteres (não depurado), além do e-mail com a síntese diária; para uma vaga de erros, só é enviado o sinal do Telegram. O Telegram recebe apenas frases fixas sem variáveis (“Ocorreu um novo tipo de erro”, “Muitos erros em pouco tempo”).
País terceiro	Através do prestador de serviços de correio eletrónico.
Conservação	Registo de erros 90 dias (durante a noite). Tipos de erro sem prazo de conservação (secção 10). O alerta de erros está ativado no sistema de produção e desativado no sistema de desenvolvimento.
MTO	Secção 8.

B.29 Sinais operacionais e monitorização do estado

Campo	Descrição
Finalidade	Detetar falhas: a cada cinco minutos, uma verificação dos componentes (página inicial, base de dados, espaço em disco, sinal de vida do scanner, acumulação na fila), página de estado, sinal em caso de falha e de reposição da normalidade, sinal de vida para um serviço de monitorização externo para que até uma falha total seja detetada; acumulação à entrada do scanner.
Categorias de titulares dos dados	Em regra, nenhuma.
Categorias de dados pessoais	Nenhuma. Linhas diárias por componente com o número de verificações e o último erro (system_status_logs), sinal de vida do scanner (scanner_heartbeat), indicadores diários sem referência pessoal (daily_stats). Os sinais para o Telegram são frases fixas sem variáveis; o sinal de vida é um pedido sem conteúdo.
Fundamento jurídico	Não aplicável, uma vez que não há dados pessoais; por precaução, Art. 6(1)(f).
Destinatários	Telegram (frases fixas); o serviço de monitorização externo (apenas o pedido); os operadores por e-mail.
País terceiro	Telegram fora da UE; não são transmitidos dados pessoais.
Conservação	Linhas de estado 400 dias (durante a noite).
MTO	Secção 8.

B.30 Opt-out – exclusão de um domínio

Campo	Descrição
Finalidade	Qualquer pessoa pode excluir permanentemente qualquer domínio das verificações sem apresentar prova; o bloqueio produz efeitos imediatos em todas as vias de verificação (verificação gratuita, plugin sem conta, estudo, verificação de potenciais clientes, ferramenta de cabeçalhos) e também para domínios de Clientes pagantes com prova de controlo; a sua monitorização em curso termina com a próxima verificação agendada. Aplica-se ao domínio e à sua variante www, não a outros subdomínios. Só é levantado por nós, mediante pedido e com prova. Para que os abusos (por exemplo, um concorrente que bloqueia domínios de terceiros) possam ser detetados e revertidos, o bloqueio é registado.
Categorias de titulares dos dados	Pessoas que excluem um domínio.
Categorias de dados pessoais	Domínio, motivo facultativo até 250 caracteres, origem, endereço IP, país, identificação do navegador, hora; no levantamento, hora, pessoa que levantou o bloqueio e motivo (blocklist). Registo de pedidos como em B.4.
Fundamento jurídico	Para a exclusão, Art. 6(1)(f) do RGPD. Interesse: dar efeito, de forma permanente e em todas as vias de verificação, à vontade de que um domínio não seja verificado. Quando a pessoa que exclui é ela própria titular dos dados, a exclusão dá simultaneamente efeito à sua oposição nos termos do Art. 21 (Art. 6(1)(c)). Para o endereço, o país e a identificação do navegador, (f) (deteção de abusos).
Destinatários	Google (reCAPTCHA, B.23).
País terceiro	EUA através do reCAPTCHA.
Conservação	Endereço IP, país e identificação do navegador após 12 meses (processo noturno de eliminação, parte “optout_ip”). A exclusão em si mantém-se permanentemente, para que produza efeitos.
MTO	Secção 8. Muitos bloqueios a partir de um mesmo país num curto espaço de tempo geram uma anomalia (B.4).

B.31 Lembrete após o registo

Campo	Descrição
Finalidade	Um único e-mail entre dois e 14 dias após o registo, enviado a contas confirmadas sem domínio confirmado: “Adicionar sítio web” ou “Confirmar domínio”. Sem oferta, sem preço, sem upgrade; com a indicação de que não será enviado novamente. Dias úteis das 09:00 às 18:00, no máximo 50 por execução.
Categorias de titulares dos dados	Novos titulares de contas.
Categorias de dados pessoais	Endereço de e-mail, idioma, hora de envio (campo “lembrete enviado” em users), domínio e estado de confirmação.
Fundamento jurídico	Art. 6(1)(b) do RGPD (indicação sobre a configuração da própria conta). Saber se o e-mail constitui uma comunicação relativa à relação contratual ou informação comercial que exigiria consentimento (Art. 10 UŚUDE, a lei polaca relativa à prestação de serviços por via eletrónica (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 PKE; § 7 UWG) é uma questão em aberto para a revisão jurídica; o operador pode desativá-lo centralmente.
Destinatários	Prestador de serviços de correio eletrónico (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
País terceiro	Através do prestador de serviços de correio eletrónico.
Conservação	A hora é mantida enquanto a conta existir; o e-mail 30 dias na caixa de saída.
MTO	Secção 8. A hora é definida antes do envio, para que uma interrupção não provoque um segundo e-mail.

B.32 Bot do Telegram para alertas dos Clientes

Campo	Descrição
Finalidade	Um chat do Telegram é associado como destino de alertas: o Cliente recebe uma ligação para o nosso bot com um código de utilização única; quando o destinatário carrega em “Start”, o nosso servidor lê o código das novas mensagens enviadas ao bot e guarda o ID do chat. Para isso não é necessário nenhum ponto de acesso aberto do nosso lado (webhook).
Categorias de titulares dos dados	Clientes e as pessoas cujo chat do Telegram é associado.
Categorias de dados pessoais	Código de utilização única, domínio, conta que o criou, eventos, modo de entrega, ID do chat, horas (telegram_links); o ID do chat como destino (alerts). O Telegram fornece outros dados de perfil com a mensagem; só o código e o ID do chat são avaliados e guardados.
Fundamento jurídico	Art. 6(1)(b) do RGPD; para terceiros enquanto destinatários, A.3.
Destinatários	Telegram.
País terceiro	Fora da UE, sem decisão de adequação; a escolha é feita pelo Cliente (4.1). O fundamento e a informação são questões em aberto para a revisão jurídica.
Conservação	Um código é válido durante 30 minutos; as linhas de associação são eliminadas um dia depois, quando é criado um novo código, e os códigos pendentes juntamente com a conta e o domínio. O ID do chat como destino até à eliminação do destino de alerta ou do domínio.
MTO	Secção 8.

B.33 Programa de parceiros e códigos de desbloqueio

Campo	Descrição
Finalidade	Uma conta pode recomendar novos Clientes através de um código de recomendação e recebe uma comissão sobre as faturas pagas destes durante um número limitado de meses. O código segue no endereço até ao registo; não é definido nenhum cookie. Empresas de alojamento e parceiros podem emitir códigos que desbloqueiam um plano durante um período sem pagamento; uma semana antes do fim, o Cliente recebe um lembrete.
Estado	O programa de parceiros está desativado por defeito até que as Condições para parceiros estejam em vigor.
Categorias de titulares dos dados	Parceiros e Clientes recomendados.
Categorias de dados pessoais	Código de recomendação, parceiro que recomendou e data da recomendação (em users); comissão com parceiro, Cliente, ID da fatura Stripe, montante, moeda, comissão, estado, horas (partner_commissions). Desbloqueio com plano, fim, origem, lembrete (em users); campanhas e utilizações (bundle_campaigns, bundle_redemptions).
Fundamento jurídico	Art. 6(1)(b) do RGPD (acordo de parceria); para o Cliente (f) (liquidação da comissão, sem transmitir ao parceiro dados do Cliente para além do montante da comissão); registos fiscais (c).
Destinatários	O parceiro vê as suas comissões.
País terceiro	Nenhum.
Conservação	Recomendação e desbloqueio juntamente com a conta. As comissões e as utilizações não têm prazo de conservação no código; enquanto documentos contabilísticos, as comissões estão sujeitas a conservação para efeitos fiscais (secção 6.4).
MTO	Secção 8.

B.34 Ponto de comunicação de vulnerabilidades

Campo	Descrição
Finalidade	Receber comunicações de vulnerabilidades em formexposed, nos termos das regras da página Segurança e de /.well-known/security.txt.
Categorias de titulares dos dados	Pessoas que comunicam; pessoas cujos dados uma comunicação contenha como prova.
Categorias de dados pessoais	Endereço de e-mail, nome, conteúdo da comunicação e anexos, tal como enviados pela pessoa que comunica. A comunicação chega-nos por e-mail para o endereço aí indicado; a aplicação não a guarda.
Fundamento jurídico	Art. 6(1)(f) do RGPD (segurança do serviço, Art. 32); quando uma comunicação contenha dados pessoais de terceiros como prova, igualmente (f), com o objetivo de corrigir a vulnerabilidade.
Destinatários	Prestador de serviços de correio eletrónico e, até a caixa de correio estar configurada, o reencaminhamento do domínio na Namecheap (secção 4).
País terceiro	Através do prestador de serviços de correio eletrónico e, até à mudança, do reencaminhamento.
Conservação	Não foi fixado nem é tecnicamente aplicado qualquer prazo de conservação (secção 10). O operador ainda tem de fixar o prazo; uma abordagem óbvia seria eliminar as provas de terceiros assim que a vulnerabilidade estiver corrigida e tratar a correspondência como os pedidos de suporte.
MTO	Secção 8.

B.35 Feedback sobre um relatório

Campo	Descrição
Finalidade	Receber feedback por baixo de um relatório (“Há algo errado neste relatório?”) para encontrar erros na deteção de formulários. O superadministrador classifica-o (novo, confirmado, corrigido, rejeitado) e pode descarregar os dados de verificação do relatório como caso de teste (formulários com campos, motivos e constatações, sem capturas de ecrã e sem textos enviados ativamente).
Categorias de titulares dos dados	Pessoas que consultam um relatório, com ou sem sessão iniciada.
Categorias de dados pessoais	Categoria e verificação de listas fixas, endereço da página até 500 caracteres, texto até 1000 caracteres, idioma, hora, identificador do relatório, verificação, anfitrião; identificador da conta, se tiver sessão iniciada; HMAC-SHA256 do endereço IP com uma chave secreta para o limite; estado, responsável pelo tratamento do feedback, hora do tratamento (report_feedback). Registo de atividades: alterações de estado e descargas de um caso de teste. Nenhum endereço de e-mail, nenhum endereço IP em texto simples.
Fundamento jurídico	Art. 6(1)(f) do RGPD (encontrar e corrigir erros de deteção; limite contra abusos).
Destinatários	Nenhum.
País terceiro	Nenhum.
Conservação	24 meses (processo noturno de eliminação, parte “report_feedback”); a soma de controlo do endereço IP é apagada após 2 dias (parte “report_feedback_ip”); de imediato quando uma conta é eliminada. Os casos de teste descarregados não contêm dados sobre a pessoa que comunicou.
MTO	Secção 8. Proteção de formulários própria (armadilha, tempo assinado, CSRF), no máximo 5 comunicações por hora e 20 por dia por soma de controlo, 10 por relatório; legível apenas por superadministradores.

6. Conservação – o que o processo noturno de eliminação abrange e o que não abrange

Existe eliminação automática, e tem um lugar definido. Um processo de estado (srv/cron_status.php) é iniciado a cada cinco minutos através do crontab do servidor web, tanto no sistema de produção como no sistema de desenvolvimento. Verifica os componentes, recolhe o correio da verificação de entrega, agenda verificações e envia alertas. Uma vez por dia, na janela das 03:00 às 03:04, elimina dados de acordo com os prazos de conservação e cria depois a cópia de segurança. Desde 27 de setembro de 2026, chama adicionalmente o processo de prazos em cfg/fristen_lib.php (fe_fristen_lauf()), cujas partes funcionam de forma independente entre si: se uma falhar, as outras continuam, e o erro é registado no registo de erros.

Prova de que o processo está a funcionar: o estado das cópias de segurança do sistema de desenvolvimento mostra uma cópia de segurança bem-sucedida às 03:00 de 11 de outubro de 2026; a cópia de segurança é criada no mesmo bloco imediatamente após a eliminação. O processo escreve um registo por tabela eliminada apenas na saída padrão, que o crontab descarta; não existe qualquer registo permanente do que foi eliminado e quando (secção 10).

Os prazos de conservação que surgem como marcadores de posição são definidos na área de administração, nas definições de conservação. O processo lê as mesmas definições; os textos mostram, por isso, sempre o prazo após o qual os dados são efetivamente eliminados.

6.1 Abrangido pelo processo diário

Dados	Prazo de conservação e acionador	Local no código
Registo de visualizações de páginas (access_logs)	60 dias	srv/cron_status.php
Registo de atividades (audit_logs)	365 dias	srv/cron_status.php
Registo de erros (error_logs)	90 dias	srv/cron_status.php
Caixa de saída (mail_outbox)	30 dias	srv/cron_status.php
Tokens “Manter sessão iniciada” (remember_tokens)	após expirarem (30 dias)	srv/cron_status.php
Convites não aceites (workspace_invites)	após expirarem (14 dias)	srv/cron_status.php
Tentativas de início de sessão (login_attempts); contadores de tentativas (auth_attempt_buckets)	7 dias; contadores quando a respetiva janela temporal expira (atualmente 15 minutos, uma hora para a reposição de palavra-passe e o registo), também no acesso seguinte	srv/cron_status.php
Registo de pedidos de verificações sem conta (check_throttle)	7 dias	srv/cron_status.php
Códigos de utilização única para ligar o plugin (plugin_connect_tokens)	1 dia após expirarem	srv/cron_status.php
Anomalias resolvidas (abuse_flags)	90 dias após a resolução	srv/cron_status.php
Relatórios expirados juntamente com o resultado da verificação, formulários, constatações, imagens e tarefa (apenas sem domínio numa conta)	anónimos 30 dias, potenciais clientes 90 dias	fe_reports_aufraeumen()
Registo de entrega de alertas (alert_log)	90 dias	fe_alert_log_aufraeumen()
Linhas de estado (system_status_logs)	400 dias	srv/cron_status.php
Registos de consentimento de contas eliminadas (legal_consents)	quando a conta tiver sido eliminada e o consentimento tiver 4 anos	srv/cron_status.php
Órfãos de domínios eliminados: resultados de verificação, tarefas, dados de alertas, incidentes, códigos Telegram, entregas, pulso, vulnerabilidades, provas, inventário de scripts e alterações de scripts	de imediato na execução seguinte	fe_fristen_lauf(), partes “orphan_scans”, “orphan_rows”
Dados de plugin de anfitriões sem domínio; linha de plugin sem conta	de imediato; linha após 90 dias sem contacto	parte “orphan_hosts”
Resultados da ferramenta de cabeçalhos (header_checks)	atualmente 90 dias	parte “header_checks”
Resultados de verificação de um domínio com formulários, constatações, imagens, relatórios, tarefas	13 meses; mantém-se o último concluído por domínio	parte “old_scans”
Execuções de navegador, tarefas de navegador concluídas, séries temporais (form_browser_runs, scan_jobs, form_performance)	13 meses	partes “browser_runs”, “browser_jobs”, “form_performance”
Contadores de formulários (form_metrics), indicadores diários do plugin e notificações de alterações (plugin_stats, plugin_changes)	13 meses	partes “form_metrics”, “plugin_stats”
Dispositivos com sessão iniciada (login_sessions)	90 dias após a última utilização ou revogação	parte “sessions”
Convites aceites	30 dias após a aceitação	parte “invites”
Pedidos de suporte (support_requests)	24 meses	parte “support”
Feedback sobre relatórios (report_feedback)	24 meses; soma de controlo do endereço IP 2 dias	partes “report_feedback” e “report_feedback_ip”
Versões PDF de relatórios em cache (var/pdf)	7 dias	parte “pdf_cache”
Endereço IP, país e identificação do navegador no opt-out (blocklist)	12 meses; a exclusão mantém-se	parte “optout_ip”
Subscritores do portal (client_subscribers)	não confirmados 30 dias; com subscrição cancelada 3 anos	parte “subscribers”
Contas nunca confirmadas, juntamente com o espaço de trabalho	30 dias sem início de sessão, salvo se outro membro estiver associado	parte “pending_accounts”
Chaves de API sem conta (dados antigos)	de imediato	parte “api_keys”

6.2 Fora da janela das 03:00

Dados	Prazo de conservação e acionador	Local no código
Cópias na caixa de correio de controlo da verificação de entrega	após o processamento, a cada cinco minutos	fe_zustellung_abholen()
Correspondências da verificação de entrega (delivery_log)	180 dias, em cada recolha	fe_zustellung_abholen()
Texto cifrado da conta de teste em tarefas (scan_jobs)	após a execução, o mais tardar após uma hora	servidor de análise; fe_login_aufraeumen()
Incidentes (alert_incidents) com as respetivas tentativas de entrega de escalonamento	enquanto não resolvidos; 180 dias após a resolução	fe_vorfaelle_aufraeumen() em cfg/vorfall_lib.php
Notificações de resumo enviadas (alert_queue)	30 dias após a entrega	cfg/kanal_lib.php
Sinais do enxame (swarm_signals)	30 dias, diariamente a partir das 04:00	cfg/swarm_lib.php
Verificações de potenciais clientes (prospect_checks)	90 dias, diariamente a partir das 04:00	srv/cron_status.php
Códigos de associação do Telegram (telegram_links)	1 dia, quando é criado um novo código	cfg/kanal_lib.php
Contadores de chamadas à API (api_usage)	1 dia, ocasionalmente durante uma chamada	cfg/agentur_lib.php
Falhas de fornecedores resolvidas (provider_incidents), cache de vulnerabilidades (vuln_cache)	90 e 30 dias, respetivamente; sem dados pessoais	cfg/anbieter_lib.php, cfg/luecken_lib.php
Dados brutos de estudos	na publicação	fe_studie_veroeffentlichen()
Cópias de segurança	14 dias, após uma nova cópia de segurança bem-sucedida	cfg/backup_lib.php
Registos do servidor web	14 dias	rotação de registos do sistema

6.3 Em caso de eliminação pelo Cliente

• Eliminar um domínio (fe_domain_loeschen()): resultados de verificação com formulários, constatações e ficheiros de imagem, relatórios, tarefas, destinos de alerta, registo de entregas, fila de resumos, incidentes, códigos Telegram, entregas, pulso, vulnerabilidades, registos de prova, o domínio dos portais de clientes com seleção fixa; através de chaves estrangeiras, formulários monitorizados com execuções de navegador, observações e séries temporais, conta de teste, contadores de formulários; os dados do plugin do anfitrião, se nenhum outro domínio o referir. O inventário de scripts e as alterações de scripts do domínio são também eliminados juntamente com ele; não têm prazo de conservação próprio (secções 6.4 e 10). Os dados remanescentes sem domínio associado do período anterior a 27 de setembro de 2026 são apagados pelo processo noturno (partes “orphan_scans”, “orphan_rows”).
• Eliminar um espaço de trabalho (fe_arbeitsbereich_daten_loeschen()): adicionalmente, a marca, incluindo o logótipo, os portais de clientes, incluindo os subscritores, os códigos de implementação, as verificações de potenciais clientes; e ainda convites e associações de membros.
• Eliminar uma conta: terminar de imediato uma subscrição paga em curso na Stripe, sem reembolso; transferir ou eliminar os espaços de trabalho próprios do titular; eliminar associações de membros, tokens de memorização, dispositivos, chaves de API com contadores, códigos Telegram pendentes e a linha da conta.
• Eliminar uma conta de teste (fe_login_loeschen()): substituir o texto cifrado, eliminar a linha, limpar as tarefas em espera.

6.4 O que o processo não abrange

Esta lista é a mais importante. Indica os dados para os quais não existe prazo de conservação automático ou que sobrevivem a uma eliminação.

Dados	O que se aplica	Avaliação
Dados da conta, incluindo o último endereço IP (users)	até serem eliminados pelo titular da conta; não há eliminação de contas inativas	dados contratuais; falta uma regra para contas permanentemente inativas sem subscrição
Registo de atividades, visualizações de páginas, registo de erros de uma conta eliminada	mantêm-se com o ID da conta e o endereço IP até ao fim do respetivo prazo de conservação	intencional (prova de ações mesmo após a cessação); o ID deixa de remeter para uma conta
Pedidos de suporte de uma conta eliminada	mantêm-se até 24 meses com o ID de conta antigo	intencional; o ID não é apagado
Registos de consentimento de uma conta eliminada	até o consentimento ter 4 anos (contados a partir do consentimento, não da eliminação da conta)	intencional (secção B.12)
Anomalias não resolvidas com endereço IP (abuse_flags)	até alguém as resolver	ponto em aberto (secção 10)
Tipos de erro com mensagem de exemplo inalterada (error_kinds)	sem prazo de conservação	ponto em aberto (secção 10)
Inventário de scripts e alterações de scripts (script_inventory, script_changes)	sem prazo de conservação próprio; mantidos enquanto o domínio existir e eliminados com ele	ponto em aberto (secção 10)
Subscritores de portais de clientes revogados	até à eliminação do espaço de trabalho	ponto em aberto (secção 10)
Chaves de API e códigos de implementação revogados	até à eliminação da conta ou do espaço de trabalho	apenas hashes, prefixo e etiqueta; de pouca relevância
Lista de anfitriões de estudos (study_domains), estudos nunca publicados	sem prazo de conservação	ponto em aberto (secção 10)
Verificações internas sem domínio e sem relatório (resultados de verificação, formulários, constatações, capturas de ecrã)	sem prazo de conservação; nenhuma via de eliminação as abrange	ponto em aberto (secção 10)
Comissões, utilizações de códigos, eventos da Stripe	sem prazo de conservação	relevância contabilística; prazo a fixar nos termos da legislação fiscal
Idade do domínio em cache (domain_age_cache)	sem prazo de conservação	apenas nome de domínio e data de registo
Resultado de autenticação do e-mail do formulário com domínio do remetente	juntamente com o domínio; substituído a cada receção	ver A.1
Exclusões no opt-out	permanentes	intencional; sem permanência, nenhuma exclusão produz efeitos
E-mails na caixa de correio do ponto de comunicação e na caixa de correio geral	sem prazo de conservação técnico	ponto em aberto (secção 10)

6.5 Fora da base de dados

• As capturas de ecrã são guardadas como ficheiros fora do diretório web e são eliminadas com o respetivo resultado de verificação (todas as vias de eliminação acima indicadas eliminam também os ficheiros).
• Os ficheiros de logótipo da marca são eliminados quando substituídos e juntamente com o espaço de trabalho.
• No servidor de análise, é criado por tarefa um diretório temporário com o resultado e as imagens; é eliminado após cada execução, mesmo após um erro.
• As cópias de segurança são guardadas no servidor web (B.27).
• Os registos do servidor web com o endereço IP completo são conservados durante 14 dias (B.1).

7. Decisões automatizadas, definição de perfis e avaliação

formexposed avalia sítios web, não pessoas. No nosso entender, o serviço não toma qualquer decisão que produza efeitos na esfera jurídica de uma pessoa ou que a afete significativamente de forma similar (Art. 22(1) do RGPD). Existem, no entanto, avaliações automatizadas e bloqueios automáticos. Enumeramo-los para que a classificação possa ser verificada.

Mecanismo	O que faz	Quem afeta
Pontuação e veredito de uma verificação	Soma ponderada das camadas de proteção em falta (CAPTCHA, armadilha, token, verificação de tempo, CAPTCHA ineficaz, configuração exposta conhecida), de 0 a 100; daqui resulta “Exposto”, “Parcialmente protegido” ou “Protegido”. O veredito do sítio web segue o pior formulário de contacto reconhecido como tal pelas regras (não pelo modelo de linguagem); sem formulário de contacto não há veredito. As ponderações podem ser definidas na área de administração.	Operadores de sítios web; no caso de empresários em nome individual, indiretamente uma pessoa. O veredito não tem consequências jurídicas; é uma constatação com provas e instruções.
Classificação do tipo de formulário	Primeiro as regras, um modelo de linguagem local apenas se as regras devolverem “desconhecido”. Decide se é permitida uma submissão de teste ativa (apenas para um formulário de contacto reconhecido com fiabilidade pelas regras). Os formulários classificados pelo modelo de linguagem nunca são submetidos e não contam para a pontuação nem para o veredito.	O Cliente e os destinatários dos seus e-mails de formulário; efeito protetor: em caso de dúvida, nada é submetido.
Selo	Mostra “Protegido” apenas em condições fixas (B.18), caso contrário é neutro.	Cliente; sem efeito sobre os visitantes.
Limites e bloqueios para a verificação gratuita, a ferramenta de cabeçalhos e o opt-out	Rejeitam pedidos se forem atingidos limites por endereço, sessão, domínio ou sistema, se o domínio for demasiado recente ou de idade desconhecida, ou se constar da lista de bloqueio.	Requerentes; efeito: um serviço gratuito é recusado durante horas ou dias. Um administrador pode desbloquear um endereço; os pedidos feitos através da página de contacto chegam a uma pessoa.
Anomalias	Padrões (muitos domínios a partir de um endereço, picos de pedidos, muitas rejeições, muitos opt-outs a partir de um país, limite diário atingido) são registados e comunicados. Não bloqueiam por si só; os bloqueios resultam dos limites.	Requerentes.
Bloqueio de início de sessão	Após, atualmente, oito inícios de sessão falhados a partir de um endereço em 15 minutos, os inícios de sessão a partir desse endereço são temporariamente rejeitados. Além disso, todas as tentativas de início de sessão, incluindo as bem-sucedidas, são contabilizadas por conta e endereço IP (atualmente oito), por conta em todos os endereços (consideravelmente mais, contra tentativas distribuídas) e por endereço IP (atualmente 80) em 15 minutos, tal como os códigos de segundo fator (dez por conta em 15 minutos); para além disso, as tentativas são rejeitadas. Assim, tentativas falhadas a partir de outro endereço já não bloqueiam o titular da sua conta. As confirmações de palavra-passe (cinco por conta em 15 minutos), os e-mails de reposição (três por endereço por hora, com resposta inalterada), os registos (dez por endereço IP por hora) e as tentativas de introdução da palavra-passe de um portal de clientes (dez por portal e endereço IP, 50 por portal em 15 minutos) são limitados da mesma forma.	Pessoas que iniciam sessão, se registam ou abrem um portal de clientes; efeito limitado no tempo, a reposição de palavra-passe continua possível.
Limiar do reCAPTCHA	Rejeita submissões abaixo de uma pontuação da Google; limiar por ponto de utilização (atualmente 0,7 para a verificação e o opt-out). São também rejeitadas respostas para uma ação diferente e submissões para as quais a Google não responda no prazo de três segundos.	Pessoas que submetem os nossos formulários; efeito: uma nova tentativa ou o recurso à página de contacto.
Proteção em enxame	Coloca automaticamente um domínio de ligação numa lista quando são atingidos limiares mínimos; as camadas de proteção dos sítios web ligados movem as mensagens com essas ligações para quarentena.	Remetentes de mensagens para páginas de Clientes. Efeito: a mensagem é retida, não eliminada, e pode ser libertada pelo operador do sítio web. A decisão sobre a mensagem é tomada pelo plugin do operador no sítio web do operador, não por nós.
Valores de comparação	“Mais bem protegido do que X % dos sítios verificados”, apenas a partir de totais de pelo menos 20 anfitriões.	Operadores de sítios web; sem efeito.

O que mais se aproxima do Art. 22 é a camada de proteção do plugin nas páginas dos Clientes, que retém automaticamente submissões. Trata-se de um tratamento efetuado pelo operador do sítio web no servidor do operador (A.10). Não elimina nada, mas move as mensagens para quarentena, e o operador pode libertar qualquer mensagem. Não há definição de perfis de visitantes nem aí nem connosco; não existe qualquer identificador de visitante que associe uma mensagem a outra.

8. Medidas técnicas e organizativas (Art. 32) – descrição geral

Esta secção constitui a descrição geral nos termos do Art. 30(1)(g) e (2)(d) do RGPD. A versão detalhada encontra-se na página Medidas Técnicas e Organizativas. Cada medida abaixo está comprovada no código ou na configuração. As medidas ainda não implementadas constam da mesma secção (8.1), para que a descrição seja completa.

Área	Medida em vigor
Cifragem do transporte	HTTPS para o sítio web, a aplicação e as interfaces; HSTS; cookies de sessão e de token de memorização apenas por HTTPS, HttpOnly, SameSite=Lax.
Controlo de acesso (autenticação)	Palavras-passe apenas sob a forma de hash, as novas com pelo menos dez caracteres e no máximo 72 bytes; bloqueio de início de sessão após tentativas falhadas repetidas e limites de tentativas por conta e endereço IP em conjunto, por conta e por endereço IP, para que tentativas falhadas a partir de outro endereço não bloqueiem o titular; limites de tentativas também para confirmações de palavra-passe, reposição de palavra-passe (com a mesma resposta e o mesmo tempo de resposta), registos e palavras-passe de portais; início de sessão com dois fatores (TOTP) com segredo cifrado, proteção contra a reutilização de códigos e códigos de recuperação em hash; novo identificador de sessão em cada início de sessão, identificadores não emitidos pelo servidor não são aceites; “Manter sessão iniciada” não disponível para superadministradores, cada token válido apenas uma vez; a alteração do endereço de e-mail invalida uma ligação de reposição pendente; os dispositivos podem ser revogados individualmente ou todos de uma vez; a lista de dispositivos contém apenas o hash do identificador de sessão.
Controlo de acesso (autorização)	Funções por espaço de trabalho (proprietário, administrador, leitor); as permissões são verificadas em relação ao objeto, nunca em relação a um identificador proveniente do formulário; conta de teste, “Fix it for me” e verificações ativas apenas para proprietários e administradores; “Ver como Cliente” limitado no tempo e bloqueado para ações que alterem a conta, o seu termo encerra completamente a sessão, regresso à área de administração apenas com palavra-passe e segundo fator; convites válidos apenas enquanto a pessoa que convida for proprietária ou administradora; endereços de webhooks e canais de chat mostrados aos leitores apenas abreviados ao anfitrião; o nome de anfitrião de um domínio verificado não pode ser alterado.
Segurança da aplicação	Tokens CSRF; instruções de base de dados preparadas; a nossa própria proteção de formulários (armadilha, verificação de tempo assinada); reCAPTCHA nos formulários públicos; limitação de pedidos para suporte, verificações e interfaces; apenas uma chamada “Fix it for me” por espaço de trabalho de cada vez, para que a quota se mantenha também em pedidos simultâneos; Content Security Policy com proteção contra enquadramento que só permite executar scripts que tenham a autorização (nonce) da respetiva resposta; endereço IP de cabeçalhos reencaminhados apenas a partir do nosso próprio proxy e apenas da entrada por ele acrescentada; tokens de acesso mascarados no registo de visualizações de páginas.
Segredos	Chaves de API, códigos de implementação, segredos de ligação do plugin, códigos de utilização única e palavras-passe de portais apenas sob a forma de hash; credenciais das contas de teste cifradas assimetricamente, chave privada apenas no servidor de análise; webhooks assinados; eventos da Stripe apenas com assinatura válida.
Minimização dos dados	A verificação de entrega não guarda conteúdo nem endereços de remetente completos; endereços de destinatários em formulários apenas como domínio; os IDs de conta nos endereços de scripts são substituídos; indicadores do plugin apenas de listas fixas; textos de erro de envio de e-mails apenas como categoria; sinais do Telegram sem variáveis; imagens das verificações no navegador com introdução de dados mascarada; sem capturas de ecrã atrás de um início de sessão.
Isolamento do scanner	Cada verificação no seu próprio contentor: todas as capacidades Linux removidas, sem escalonamento de privilégios, sistema de ficheiros só de leitura, limite de memória e de processos, rede própria; verificação do destino contra redes privadas e locais antes da aceitação e no scanner, também após redirecionamentos; service workers bloqueados, ligações WebSocket fechadas. Pedidos do servidor web (prova de controlo, ferramenta de cabeçalhos, pesquisa de ficheiros, pulso, RDAP, certificados, webhooks e alertas por chat) apenas nas portas web habituais e apenas exatamente para o endereço verificado, webhooks e alertas por chat apenas por HTTPS.
Armazenamento	Capturas de ecrã fora do diretório web, acessíveis apenas através do relatório; relatórios em endereços aleatórios com noindex; diretório de cópias de segurança legível apenas pelo serviço.
Disponibilidade e recuperação	Cópia de segurança noturna com verificação do conteúdo, teste de restauro semanal, alerta em caso de falha; verificação dos componentes a cada cinco minutos com sinal e e-mail; sinal de vida externo; paragem de emergência para verificações anónimas; contrapressão em caso de acumulação.
Rastreabilidade	Registo de atividades para inícios de sessão, alterações, eliminações, acessos do suporte e aprovações; registo de erros com alerta.
Eliminação	Prazos de conservação num único local do código, a partir das mesmas definições que os textos (secção 6); cadeias de eliminação para domínio, espaço de trabalho e conta, com as exceções da secção 6.4.
Direitos dos titulares dos dados	Exportação com um clique de todos os dados da conta como ficheiro, com base numa lista de campos permitidos, sem segredos.
Organização	Área de administração apenas para contas com direitos de superadministrador, bloqueada durante “Ver como Cliente”; sistemas de desenvolvimento e de produção separados, o sistema de desenvolvimento atrás de uma barreira de acesso adicional; transferência dos textos jurídicos após aprovação através de uma ferramenta que recusa rascunhos e marcadores de posição.

8.1 Medidas ainda não implementadas

• Sem cifragem da base de dados em repouso (medido em 11 de outubro de 2026). As exceções são as credenciais das contas de teste e o segredo de dois fatores, que são cifrados ao nível do campo.
• Ligações internas não cifradas em toda a extensão. As ligações dentro da nossa rede interna não são cifradas em toda a extensão. As credenciais das contas de teste circulam aí apenas sob a forma cifrada.
• Sem cópia de segurança num segundo local. As cópias de segurança encontram-se atualmente no mesmo local que a base de dados e não estão cifradas separadamente; está prevista uma cópia cifrada num segundo local. Até lá, protegem contra um comando de eliminação errado, não contra a perda do local.
• Reforço da administração dos servidores não concluído. A segurança do acesso administrativo aos nossos servidores ainda não cumpre o padrão que pretendemos para o funcionamento; o reforço prossegue. Não publicamos pormenores, porque ajudariam um atacante; fornecemo-los a uma autoridade de controlo mediante pedido.
• Sem registo funcional de leituras na área de administração. As ações de escrita são registadas no registo de atividades; quem apenas consultou que pedido de suporte ou que relatório só pode ser apurado a partir do registo de visualizações de páginas (60 dias).
• Sem registo permanente de eliminações. O que o processo noturno eliminou não é registado (secção 6).
• Sem segundo ponto de verificação independente. A sonda num segundo local não está configurada (A.6).

9. Encarregado da proteção de dados – avaliação nos termos do Art. 37 do RGPD

Resultado: No nosso entender, não existe obrigação de designar um encarregado. A avaliação faz parte da revisão jurídica e será repetida logo que se altere qualquer das circunstâncias abaixo indicadas.

O Art. 37(1) exige uma designação em três casos.

• Alínea (a) (autoridade ou organismo público) não se aplica.
• Alínea (b) (atividades principais que exijam um controlo regular e sistemático dos titulares dos dados em grande escala): a nossa atividade principal é a verificação regular e sistemática de sítios web e formulários, não a observação de pessoas. Não criamos perfis de visitantes, não utilizamos rastreamento e não associamos nenhuma mensagem a outra. A verificação de entrega (A.1) faz passar mensagens reais de visitantes pela nossa caixa de correio, mas avalia apenas os cabeçalhos e os primeiros 8 KB para efeitos de correspondência e não guarda conteúdo; observa vias de entrega, não pessoas. As contas de clientes e os registos são acessórios à atividade empresarial.
• Alínea (c) (tratamento em grande escala de categorias especiais nos termos do Art. 9 ou de dados relacionados com infrações penais nos termos do Art. 10 como atividade principal): não se verifica. Podem surgir categorias especiais de forma acidental em cópias de e-mails de formulários (A.1), em páginas atrás de um início de sessão (A.5) ou em código colado (A.7); a recolha acidental não é uma atividade principal.

O Art. 37(4) permite que o direito nacional acrescente outros casos. Estamos a solicitar a um advogado que confirme se a legislação polaca nos obriga a designar um encarregado.

Fatores que desencadeiam uma nova avaliação: ativação da proteção em enxame com redes IP; uma função que reconheça visitantes ao longo de várias mensagens ou sítios web; armazenamento de conteúdo da verificação de entrega; um Cliente cujos formulários digam predominantemente respeito a categorias especiais (saúde, candidaturas a emprego) com a verificação de entrega ativada em grande escala; o primeiro trabalhador com acesso a dados de clientes. Continua a ser possível uma designação voluntária; aplicam-se então integralmente os Art. 37 a 39.

À parte: a questão de saber se é necessária uma avaliação de impacto sobre a proteção de dados nos termos do Art. 35 para determinadas atividades de tratamento é respondida na página Avaliação de Impacto sobre a Proteção de Dados. A sua avaliação de limiar conclui que é necessária uma AIPD para a proteção em enxame (B.21) e para estudos na escala prevista (B.7), sendo realizada por nós, e que, para a verificação de entrega (A.1), é necessária na constelação típica, como obrigação do Cliente, que apoiamos nesse âmbito.

10. Pontos em aberto e medidas previstas

Os pontos seguintes estão comprovados no código, no esquema ou na configuração, não são suposições. Descrevem a situação à data desta versão; a classificação é nossa e não antecipa qualquer apreciação jurídica. Estão ordenados pelo seu peso para os titulares dos dados, não pela facilidade de correção. As medidas previstas e a respetiva prioridade constam da Avaliação de Impacto sobre a Proteção de Dados.

Ponto em aberto	O que está comprovado	Relevância
Prestador de serviços de correio eletrónico sem contrato documentado	Para Namecheap, Inc. (Private Email), Phoenix, Arizona, USA, o contrato, os locais de tratamento e o fundamento de transferência não estão documentados. Os e-mails de conta, os alertas e a caixa de correio de controlo com mensagens reais de visitantes passam por este prestador.	As disposições relevantes são o Art. 28(2) e (4) e o Capítulo V do RGPD. A celebração e a documentação estão previstas antes do lançamento.
Fundamentos para serviços de chat e reCAPTCHA em aberto	Alertas para Telegram (sem decisão de adequação), Slack, Discord, Microsoft Teams e Google Chat; reCAPTCHA sem pedido de consentimento.	Questões em aberto para a revisão jurídica; até lá, a informação e o fundamento não são definitivos.
A caixa de correio de controlo pode reter mensagens durante perturbações	A eliminação ocorre após um processamento bem-sucedido; se a recolha falhar, as cópias mantêm-se até à execução bem-sucedida seguinte. Não há aviso quando se forma uma acumulação na caixa de correio durante um período prolongado.	As cópias contêm pedidos reais de visitantes.
Sem cópia de segurança num segundo local, sem cifragem da base de dados em repouso	Secção 8.1. Está prevista uma cópia cifrada da cópia de segurança num segundo local.	Um único evento no local afetaria simultaneamente os dados e a cópia de segurança; um suporte de armazenamento roubado seria legível.
Anomalias não resolvidas sem prazo de conservação	As anomalias com o endereço IP completo como chave só são eliminadas 90 dias após a resolução; o que nunca for resolvido mantém-se.	Diz respeito ao princípio da limitação da conservação (Art. 5(1)(e)); a eliminação depende de uma resolução manual. Está previsto um prazo de conservação fixo (medidas da Avaliação de Impacto sobre a Proteção de Dados).
Tipos de erro com mensagem de exemplo sem prazo de conservação	A mensagem de exemplo é guardada inalterada até 2000 caracteres; o padrão depurado remove endereços e números, o exemplo não.	As mensagens de erro podem conter endereços de e-mail, nomes de anfitrião ou endereços IP.
Inventário de scripts sem prazo de conservação próprio	O inventário de scripts e as alterações de scripts são eliminados com o domínio (FE_DOMAIN_TABELLEN), incluindo quando o espaço de trabalho ou a conta são eliminados e no processo noturno para órfãos; não têm prazo de conservação próprio. Contêm endereços de scripts, endereços de páginas e, no caso de aprovações, a pessoa que aprovou e um motivo em texto livre.	Diz respeito ao princípio da limitação da conservação (Art. 5(1)(e)); o registo de alterações com as aprovações continua a crescer enquanto o domínio existir.
Subscritores de portais revogados	Um portal revogado é bloqueado, não eliminado; os seus subscritores mantêm-se até à eliminação do espaço de trabalho.	A finalidade (envio do relatório) cessou com a revogação.
Listas de estudos sem prazo de conservação	Após a publicação, os anfitriões e os segmentos mantêm-se; os estudos nunca publicados conservam também os seus dados brutos.	A promessa “os dados brutos são eliminados” aplica-se apenas a estudos publicados.
Verificações internas sem via de eliminação	As verificações com o nível de confiança “interno” que não têm domínio nem relatório (estudos e verificações criados pelo operador a partir da linha de comandos) não são abrangidas por nenhuma via de eliminação; com elas mantêm-se formulários, constatações e capturas de ecrã de sítios web de terceiros.	Diz respeito ao princípio da limitação da conservação (Art. 5(1)(e)); afeta pessoas que nada sabem sobre a verificação. Avaliado como risco elevado na Avaliação de Impacto sobre a Proteção de Dados.
A prova de controlo não é renovada	A prova de controlo é verificada uma única vez; não existe no código nenhuma via pela qual um domínio a volte a perder.	As submissões de teste ativas, a pesquisa de ficheiros e a análise atrás do início de sessão continuam após uma mudança de proprietário ou de mandato.
Análise atrás do início de sessão: transporte até à página do Cliente	Como endereço de início de sessão, é permitido http a par de https, e os erros de certificado na página do Cliente não interrompem o início de sessão.	As credenciais da conta de teste poderiam ser intercetadas no caminho até à página do Cliente.
A eliminação depende de uma janela temporal	O bloco diário só é executado se um processo de estado arrancar entre as 03:00 e as 03:04. Se essa única execução falhar (base de dados inacessível, servidor reiniciado), a eliminação e a cópia de segurança desse dia não se realizam; não há recuperação. O que foi eliminado não é registado de forma permanente.	Os prazos de conservação são então prolongados silenciosamente por um dia. Uma janela perdida não desencadeia qualquer alerta; só é comunicada uma cópia de segurança que seja executada e falhe. A lista de configuração na área de administração mostra a data da última cópia de segurança bem-sucedida.
Algumas eliminações dependem da monitorização	O esvaziamento da caixa de correio de controlo da verificação de entrega, a eliminação de incidentes, notificações de resumo enviadas, sinais do enxame e verificações de potenciais clientes, bem como a limpeza de cópias remanescentes de contas de teste em tarefas, são executados na parte de agendamento do processo de estado, que só funciona enquanto a monitorização estiver ativada na área de administração; as correspondências da verificação de entrega só são eliminadas enquanto estiver configurada uma caixa de correio de controlo.	Se a monitorização for desativada centralmente ou a caixa de correio for removida, estes prazos de conservação deixam de ser aplicados sem que ninguém se aperceba.
Ponto de comunicação e caixas de correio sem prazo de conservação	As comunicações de vulnerabilidades e outros e-mails recebidos são mantidos fora da aplicação; não foi fixado qualquer prazo de conservação.	As comunicações podem conter provas relativas a terceiros.
Os valores de campos ocultos são lidos durante a verificação	O scanner lê o valor de campos de formulário ocultos até 24 caracteres e de atributos de dados até 60 caracteres, para reconhecer marcas temporais e tokens. Apenas o nome do campo, o tipo, a etiqueta e o resultado do reconhecimento entram no mapa de campos e nas constatações, não o valor.	Sem lacuna de armazenamento; o valor só existe na memória de trabalho do contentor de análise durante a verificação. Um valor pré-preenchido (por exemplo, um número de cliente) é lido nesse processo, mas não é guardado.
Domínio do remetente derivado no resultado de autenticação	A.1.	No caso de domínios pessoais de visitantes, dados pessoais provenientes de uma mensagem real.
Reforço da administração dos servidores não concluído; ligações internas não cifradas em toda a extensão	Secção 8.1. O reforço prossegue; não divulgamos pormenores publicamente.	Um incidente de segurança ao nível do servidor afetaria simultaneamente a aplicação, a base de dados e as cópias de segurança.
Medição no sistema de desenvolvimento	O esquema, o código e as definições foram medidos no sistema de desenvolvimento.	O código e o esquema coincidem com o sistema de produção; as definições podem diferir e têm de ser novamente verificadas aí antes do lançamento.

11. Manutenção deste registo

O Art. 30 exige que o registo seja mantido por escrito e disponibilizado à autoridade de controlo, mediante pedido. Isso requer alguém que seja responsável por ele e uma periodicidade com que seja confrontado com o sistema, e não com a sua versão anterior.

• Responsabilidade: Lukas Wójcik, proprietário. É revisto anualmente e sempre que uma atividade de tratamento se altere.
• Eventos que exigem uma atualização: um subcontratante novo ou alterado, em especial a escolha do prestador de serviços de correio eletrónico; uma nova tabela ou um novo campo com dados pessoais; uma alteração dos prazos de conservação ou das cadeias de eliminação em cfg/fristen_lib.php ou srv/cron_status.php; um novo canal de alerta ou um novo pedido a um terceiro; a ativação de uma função desativada por defeito (proteção em enxame com redes IP, sonda, domínios próprios, programa de parceiros, pagamento por fatura, Spamhaus ou Google Web Risk); uma mudança para outros servidores.
• Procedimento: cada afirmação aqui feita provém do código, do esquema ou de medições. Uma revisão que se limite a ler o texto não reviu nada: o esquema e as cadeias de eliminação são novamente medidos, os marcadores de posição continuam a ser marcadores de posição, os pontos em aberto são encerrados ou transitam com fundamentação.
• Relação com outros documentos: este registo não substitui a Política de Privacidade, o Acordo de Tratamento de Dados, as Medidas Técnicas e Organizativas nem a lista de Subcontratantes. Quando estes documentos e este registo divergirem, a divergência constitui uma constatação.
• As alterações a este documento estão enumeradas na página Alterações aos Documentos Contratuais.