Este documento é publicado em vários idiomas. Em caso de divergência entre as versões, a versão em polonês é vinculante.
Versão 1.2 · Última atualização: 29 de outubro de 2026
1. Como ler este registro
Este é o registro das atividades de tratamento nos termos do Art. 30 do RGPD para formexposed. Não é uma política de privacidade nem publicidade. Sua função é mostrar a uma autoridade de controle, a um Cliente que nos audita como operador ou à próxima pessoa que precise responder a uma pergunta o que é efetivamente tratado, onde é mantido, quem o recebe e por quanto tempo permanece. Nós o publicamos porque um serviço que verifica e monitora formulários deve, ele próprio, estar aberto à verificação.
Três regras orientaram sua elaboração.
- Medido, não apenas pretendido. Uma afirmação sobre campos de dados, prazos de retenção, destinatários ou salvaguardas aparece apenas quando o código do programa, o esquema do banco de dados ou uma medição a sustenta. O que está planejado é chamado de “planejado”. O que está desativado por padrão é chamado de “desativado por padrão”. Quando não podemos comprovar algo, nós o informamos.
- A retenção é indicada duas vezes. Uma vez para cada atividade de tratamento e outra na seção 6 como visão geral: qual rotina noturna exclui quais dados e quais dados ela não alcança. Um registro que afirma um prazo de retenção que se aplica apenas a parte dos dados é pior do que um que aponta a pendência.
- Os pontos pendentes são indicados no texto, não em uma nota de rodapé. A seção 8.1 lista medidas que ainda não foram implementadas, e a seção 10, os pontos pendentes com as medidas planejadas. Um registro é uma ferramenta de trabalho, não um certificado.
Campos de dados em vez de nomes de tabelas. Para cada atividade de tratamento, listamos os dados armazenados como campos em linguagem simples. O nome da tabela do banco de dados vem entre parênteses para que um auditor possa encontrar o local, por exemplo, “tentativas de login (login_attempts)”. As listas de campos foram derivadas do esquema do banco de dados, não da memória.
Prazos de retenção como marcadores. Quando um prazo de retenção pode ser definido na área administrativa, ele aparece aqui exatamente como a rotina noturna o lê: o número que você vê vem da mesma configuração que rege a exclusão. Os prazos de retenção fixados no programa são apresentados como números.
Base da medição. Esquema, código e configuraçõ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 fornecemos contagens de linhas do sistema de desenvolvimento; elas contêm dados de teste e nada dizem sobre a operação em produção.
Deliberadamente omitido. Este registro não informa nomes de hosts, endereços de rede interna, portas, nomes de usuários ou versões de software dos nossos servidores. Esses detalhes ajudam um invasor e nenhum titular de dados. Pelo mesmo motivo, descrevemos os pontos pendentes na segurança dos nossos próprios servidores apenas em termos gerais (seção 8.1): indicamos o risco, não o caminho até ele. Fornecemos os detalhes a uma autoridade de controle mediante solicitação.
Natureza jurídica. Este registro é a documentação que mantemos nos termos do Art. 30 do RGPD para a autoridade de controle; é publicado voluntariamente. Não faz parte de nenhum contrato e não constitui nenhuma declaração, garantia ou acordo sobre qualidade perante Clientes ou terceiros. O que devemos aos Clientes é regido pelos Termos de Serviço, pelo Acordo de Tratamento de Dados e por seus anexos; quanto a essas obrigações, eles prevalecem sobre este registro. O registro descreve a situação na data desta versão. Classificações como “ponto pendente” ou “avaliação” refletem nossa própria visão e não antecipam qualquer avaliação jurídica por uma autoridade de controle ou um tribunal; medidas descritas como “planejadas” são intenções sem uma data assumida como compromisso.
2. A entidade jurídica e por que este registro tem duas partes
| Campo | Informação |
|---|
| Entidade jurídica | LW IT Solutions Company Lukas Wójcik, empresa individual registrada no registro empresarial polonês (CEIDG); proprietário Lukas Wójcik |
| Endereço | al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polônia |
| Identificadores fiscais | NIP 7252266190, identificação de IVA PL7252266190 |
| Contato | contact@lukaswojcik.com; a janela de suporte (ponto de interrogação na navegação); a página de contato |
| Serviço | formexposed: verificação, monitoramento e proteção de formulários de contato em sites (aplicação em formexposed.com, página de apresentação em form.exposed) |
| Representante nos termos do Art. 27 do RGPD | Não se aplica. 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 está na seção 9. |
| Autoridade de controle competente | Prezes Urzędu Ochrony Danych Osobowych (UODO, a autoridade polonesa de proteção de dados), ul. Moniuszki 1A, 00-014 Warszawa |
| Hospedagem | Nossos próprios servidores na Polônia: um servidor web com a aplicação e o banco de dados e um servidor de verificação com um modelo de linguagem local na mesma rede interna. Nenhum provedor de data center ou nuvem de terceiros. |
formexposed desempenha diferentes papéis em relação a diferentes grupos de pessoas. Misturá-los produz um registro que não é correto para nenhum deles.
- Controlador (Parte B, Art. 30(1)). Nós mesmos somos o controlador dos dados dos nossos próprios Clientes e dos membros das suas equipes (conta, login, cobrança, suporte, registros), dos visitantes do nosso próprio site, das verificações sem uma conta (verificação gratuita, ferramenta de cabeçalhos, estudo, verificação de potencial cliente) e da prevenção de abuso.
- Operador (Parte A, Art. 30(2)). Para dados pessoais de terceiros que um Cliente introduza no serviço ou que surjam quando prestamos um serviço para o Cliente, atuamos em nome do Cliente: cópias de e-mails reais de formulário na verificação de entrega, assinantes do portal de clientes do Cliente, destinatários dos alertas do Cliente, pessoas que por acaso estejam visíveis 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. A base é o Acordo de Tratamento de Dados, celebrado com todo Cliente no cadastro.
- Apenas do lado do Cliente. Algumas funções do plugin WordPress e da extensão TYPO3 tratam dados exclusivamente no site do Cliente, sem que os dados cheguem a nós em nenhum momento (quarentena, rede de segurança, desafio aritmético, configurações de retenção, contadores locais, gravador). Elas não são tratamento por nós e, portanto, não aparecem em nenhuma das partes. Ainda assim, nós as descrevemos no fim da Parte A para tornar o limite visível.
A separação está implementada no código, não apenas no texto: de um e-mail real de formulário, a verificação de entrega grava no banco de dados apenas o horário, a associação e o resultado da autenticação; as capturas de tela das verificações no navegador mascaram os campos de entrada; as credenciais de contas de teste são criptografadas de tal forma que o servidor web já não pode lê-las. Os detalhes são apresentados nas entradas.
As seções 6 a 11 aplicam-se às duas partes: retenção, decisões automatizadas, medidas técnicas e organizacionais, encarregado da proteção de dados, pontos pendentes e manutenção deste registro.
Escopo. Este documento é a parte do registro que diz respeito ao serviço formexposed. O tratamento pela mesma entidade jurídica para outros serviços é documentado nos seus próprios registros; a contabilidade geral e a administração empresarial fora do serviço não são abrangidas por esta parte.
3. Parte A – Art. 30(2): tratamento em nome dos Clientes
A.0 Partes envolvidas
| Campo | Informação |
|---|
| Operador | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polônia; contact@lukaswojcik.com |
| Controladores | Os Clientes de formexposed: empresas e agências que mantêm domínios na sua conta e usam funções nas quais surgem dados de terceiros. No caso de agências, o próprio cliente da agência também pode ser o controlador; a agência atua então como operador perante esse cliente, e nós atuamos como outro operador. |
| Lista de controladores | Parte deste registro, mantida em formato eletrônico (Art. 30(3) do RGPD) no sistema do serviço e não reproduzida nesta versão pública, pois contém dados pessoais de Clientes e ficaria desatualizada a 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 identificação de IVA apenas na Stripe) (users, workspaces, workspace_users), além dos domínios do espaço de trabalho (domains). Nós a fornecemos como extrato a uma autoridade de controle mediante solicitação. |
| Representantes e encarregados da proteção de dados dos controladores | Não há um campo específico para isso no sistema. Se um Cliente tiver designado um representante nos termos do Art. 27 do RGPD ou um encarregado da proteção de dados, pode nos informar sobre eles; mantemos a comunicação junto com a lista de controladores. |
| Representante do operador | Não se aplica (estabelecido na Polônia). |
| Encarregado da proteção de dados | Não designado (seção 9). |
| Instruções | A instrução decorre do Acordo de Tratamento de Dados e das configurações que o Cliente faz: o Cliente ativa a verificação de entrega, configura destinos de alertas, armazena uma conta de teste e configura um portal de clientes. Sem essa ação, o tratamento em questão não ocorre. |
| Medidas técnicas e organizacionais | A seção 8 e a página Medidas Técnicas e Organizacionais aplicam-se a cada atividade de tratamento da Parte A. Medidas especiais são indicadas na respectiva entrada. |
A.1 Verificação de entrega – cópia de controle dos e-mails de formulário
| Campo | Informação |
|---|
| Finalidade | Verificar se o e-mail do formulário de contato do Cliente é efetivamente enviado e como é autenticado (SPF, DKIM, DMARC, alinhamento). Após um envio de teste ativo aceito, sua cópia deve chegar à caixa de e-mail de controle dentro de um tempo de espera ajustável (atualmente 3 horas); caso contrário, é gerado o alerta “E-mail de teste não recebido”. Os cabeçalhos também são usados para determinar a autenticidade do e-mail de formulário, o serviço de e-mail utilizado e o endereço de envio para a verificação de listas de bloqueio. |
| Pré-requisito | Plano pago, domínio verificado, ativado pelo Cliente. O Cliente insere seu próprio endereço de controle com um identificador (no formato “delivery+identifier@…”) como cópia oculta na notificação do seu formulário. Sem uma caixa de e-mail de controle configurada, a função não está disponível. |
| Categorias de titulares de dados | Visitantes do site do Cliente que enviam o formulário do Cliente; pessoas cujos dados um visitante escreve na mensagem; pessoal do Cliente que aparece como destinatário nos cabeçalhos. |
| Categorias de dados pessoais | Na caixa de e-mail de controle (no prestador de serviços de e-mail): a cópia completa de cada e-mail de formulário, incluindo consultas reais com nome, endereço de e-mail, telefone e texto livre, até a exclusão. Lido na obtenção: os cabeçalhos e no máximo os primeiros 8 KB do corpo. No banco de dados: horário de recebimento, associação ao domínio e, quando aplicável, à execução de teste (delivery_log); o resultado de autenticação mais recente por domínio com resultado de SPF, DKIM e DMARC, alinhamento, domínio do remetente, domínios de assinatura e o endereço do servidor de envio de e-mail (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 gravados no banco de dados. |
| Nota sobre o domínio do remetente | Se um formulário inserir o endereço do visitante como remetente (uma configuração incorreta que a verificação foi projetada para detectar), o resultado da autenticação contém o domínio desse endereço, não o próprio endereço. Quando um visitante usa um domínio pessoal, isso também pode ser dado pessoal. Ele é sobrescrito no próximo recebimento. |
| Origem | O formulário no site do Cliente, por meio da cópia oculta inserida pelo Cliente. |
| Base legal (determinada pelo controlador) | Determinada pelo Cliente. Nossa sugestão de texto para a política de privacidade do Cliente fundamenta a cópia no Art. 6(1)(f) do RGPD (interesse legítimo em receber consultas de forma confiável). O Cliente informa seus visitantes sobre esse fluxo de dados; o Acordo de Tratamento de Dados o obriga a fazê-lo. |
| Destinatários | O prestador de serviços de e-mail que opera a caixa de e-mail de controle (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). A cópia vai diretamente para lá: ela só chega se os registros MX do nosso domínio apontarem para essa caixa de e-mail (a lista de verificação anterior ao lançamento confere isso); por encaminhamento, ela não chega à caixa de e-mail. Na página do domínio, o Cliente vê apenas horário, associação e resultado da autenticação. Se o resultado da autenticação piorar, o alerta ao Cliente e aos canais escolhidos por ele menciona o domínio do remetente se não pertencer ao site (A.3, 4.1). |
| País terceiro | Depende do prestador de serviços de e-mail; veja a seção 4. O contrato com o provedor pretendido e a base de transferência ainda não estão documentados. |
| Retenção | Após o processamento bem-sucedido, o e-mail é marcado para exclusão e removido da caixa de e-mail na mesma execução, mesmo que não possa ser associado a nenhum domínio. A obtenção ocorre junto com a rotina de status a cada cinco minutos, enquanto o monitoramento estiver ativado na área administrativa (srv/cron_status.php, cfg/zustellung_lib.php). Se a obtenção ou a exclusão falhar, o e-mail permanece na caixa de e-mail até a próxima execução bem-sucedida. A mesma obtenção exclui as associações em delivery_log após 180 dias. O resultado da autenticação permanece enquanto o domínio existir. |
| O que a evidência comprova | Apenas o recebimento, na caixa de e-mail de controle, da cópia associada à execução de teste específica. Não comprova o recebimento pelo destinatário real nem um registro no CRM. Não é oferecida confirmação nativa do HubSpot. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: o conteúdo é avaliado apenas na memória; sem armazenamento de corpo, assunto ou endereços completos de remetentes; exclusão independentemente do sucesso da associação. |
A verificação de entrega é a única função pela qual mensagens reais dos visitantes dos nossos Clientes chegam a nós. É por isso que ela é tratamento em nome do Cliente, e não um serviço sob nossa própria responsabilidade, e é por isso que o tempo de permanência na caixa de e-mail é a medida real do risco: normalmente minutos; se a obtenção estiver interrompida, até que seja executada novamente. As cópias não devem conter categorias especiais de dados pessoais; não podemos impedir isso tecnicamente, pois o que um visitante escreve cabe ao visitante.
A.2 Portal de clientes e relatório mensal aos assinantes
| Campo | Informação |
|---|
| Finalidade | Uma agência (plano Business) mostra aos seus clientes o estado dos seus domínios sob sua própria marca (portal em um endereço aleatório, opcionalmente com senha, opcionalmente sob um subdomínio da própria agência). O cliente pode solicitar ali um relatório mensal por e-mail. O relatório é enviado em nome da agência. |
| Categorias de titulares de dados | Os clientes da agência e seu pessoal que solicitam o relatório; pessoas que abrem o portal. |
| Categorias de dados pessoais | Assinante: endereço de e-mail, idioma, identificador de confirmação, horário da solicitação e endereço IP no momento da solicitação, horário da confirmação (dupla confirmação de adesão), horário do cancelamento da assinatura, último mês enviado (client_subscribers). Portal: nome, seleção de domínios, identificador aleatório, senha apenas como hash, pessoa que o criou, horário, revogação (client_portals). As visitas ao portal aparecem no registro de visualizações de páginas (B.2). |
| Origem | Inseridos pelos próprios assinantes no portal. |
| Base legal (determinada pelo controlador) | O consentimento do assinante, obtido por um procedimento de dupla confirmação de adesão; o controlador é a agência. Não escrevemos a quem não se cadastrou e confirmou por conta própria. |
| Destinatários | A agência (vê seus assinantes); o prestador de serviços de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) para o e-mail de confirmação e o relatório. |
| País terceiro | Pelo prestador de serviços de e-mail; veja a seção 4. |
| Retenção | Rotina noturna de exclusão (cfg/fristen_lib.php, parte “assinantes do portal”): solicitações nunca confirmadas após 30 dias; assinantes que cancelaram, três anos após o cancelamento, como prova do consentimento anterior. Assinantes confirmados que não cancelaram permanecem enquanto o espaço de trabalho da agência existir. Um portal revogado é apenas bloqueado, não excluído; seus assinantes deixam de receber relatórios, mas seus dados permanecem (seção 10). Portais e assinantes são excluídos imediatamente com o espaço de trabalho (fe_arbeitsbereich_daten_loeschen()). Os relatórios enviados ficam na caixa de saída por 30 dias (B.25). |
| Medidas técnicas e organizacionais | Seção 8. Em particular: senha 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 assinatura com um clique em cada e-mail; o portal mostra apenas status e indicadores principais, sem constatações individuais com evidências. |
A.3 Destinatários dos alertas do Cliente, pessoas que confirmam recebimento e responsáveis
| Campo | Informação |
|---|
| Finalidade | Notificações sobre falhas e alterações aos destinos que o Cliente configura para um domínio: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Por destino, imediatamente ou reunidas diariamente ou semanalmente, além de destinos exclusivos para escalonamentos. Cada notificação de problema se torna um incidente, cujo recebimento o destinatário pode confirmar por um link. Para formulários monitorados, o Cliente pode especificar uma pessoa responsável e uma data-limite. |
| Categorias de titulares de dados | Pessoal e prestadores de serviços do Cliente que ele informa como destino de alerta ou indica como responsáveis; pessoas que confirmam o recebimento de um incidente. Membros da equipe com conta própria também aparecem 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 chat, ID de chat do Telegram), eventos selecionados, modo de entrega, segredo de assinatura para webhooks, última entrega e último erro (alerts). Registro de entrega: destino, eventos, status, erro, horário (alert_log). Fila de resumos: linhas de notificação e link até a entrega (alert_queue). Incidente: título, linhas de notificação, link, identificador de confirmação de recebimento, horário e nome ou endereço de e-mail da pessoa que confirma o recebimento, conforme inserido no formulário, ou, na ausência disso, o endereço do membro conectado (alert_incidents). Tentativas de entrega de escalonamentos por incidente e destino: número de tentativas (no máximo cinco), horários da última e da próxima tentativa e do sucesso, 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 um link para a página do domínio. Nenhum conteúdo das mensagens de visitantes. |
| Origem | Inseridos pelo Cliente; a própria pessoa que confirma o recebimento informa seu nome; o ID de chat do Telegram é criado quando o destinatário pressiona “Iniciar” no bot (B.32). |
| Base legal (determinada pelo controlador) | Determinada pelo Cliente; em regra, a organização das próprias operações do Cliente (Art. 6(1)(b) ou (f) do RGPD em relação ao pessoal e aos prestadores de serviços do Cliente). |
| Destinatários | Os operadores dos canais escolhidos; veja 4.1. Alertas por e-mail pelo prestador de serviços de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| País terceiro | Depende do canal escolhido; vários provedores estão sediados nos EUA, e o Telegram, fora da UE sem uma decisão de adequação. Veja 4.1. |
| Retenção | Registro de entrega após 90 dias (à noite, fe_alert_log_aufraeumen() de srv/cron_status.php). Notificações de resumo 30 dias após a entrega (cfg/kanal_lib.php, em cada entrega de resumo). Incidentes enquanto não resolvidos; os resolvidos, 180 dias após a resolução (cfg/vorfall_lib.php, rotina de escalonamento), junto com suas tentativas de entrega de escalonamentos. Destinos de alertas e atribuições até a exclusão pelo Cliente ou junto com o domínio. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: webhooks assinados com um segredo separado por destino; confirmação de recebimento somente após um clique (POST), para que prévias de links em programas de chat não acionem nada; alertas durante uma janela de manutenção são apenas registrados, não enviados. |
A.4 Pessoas incidentalmente visíveis nas páginas verificadas do Cliente e em capturas de tela
| Campo | Informação |
|---|
| Finalidade | A verificação dos domínios na conta do Cliente (verificação, monitoramento, verificação ativa) lê as páginas públicas do Cliente e faz capturas de tela dos formulários. O que a própria página exibe pode dizer respeito a pessoas que não têm relação com a verificação. Esses dados surgem incidentalmente; não são a finalidade da verificação. |
| Categorias de titulares de dados | Pessoas cujo nome, foto ou dados de contato aparecem na página verificada (pessoa de contato ao lado do formulário, fotos da equipe na página inicial, dados nas informações legais). |
| Categorias de dados pessoais | Capturas de tela: a área visível da página inicial, cada formulário visível como recorte e a imagem da página seguinte após um envio de teste ativo; armazenadas como arquivos fora do diretório web, com apenas a referência no banco de dados (scan_screenshots). Estrutura do formulário: endereço da página, seletor, nomes dos campos, tipos dos campos, rótulos dos campos, indicadores de obrigatoriedade e visibilidade, rótulos dos botões de envio (forms, campo “mapa de campos”); sem valores de campos. O verificador lê o início dos campos ocultos (até 24 caracteres) e dos atributos de dados (até 60 caracteres) apenas durante a verificação, para reconhecer registros de tempo e tokens; apenas o resultado é armazenado. Constatações com evidências (findings), resumo com títulos de páginas (scans). Para verificações elegíveis em contas pagas, um modelo local gera um plano de ação priorizado a partir de constatações selecionadas e metadados da verificação; seu texto, idioma, status e registro de tempo são armazenados no resumo da verificação. Se um endereço de e-mail aparecer no formulário como destinatário, apenas seu domínio é armazenado, nunca o endereço. |
| Origem | As páginas públicas do domínio do Cliente, obtidas pelo verificador. |
| Base legal (determinada pelo controlador) | Determinada pelo Cliente para o conteúdo do seu próprio site. Para nós, o tratamento faz parte da verificação contratada. |
| Destinatários | O Cliente; no caso de agências, seu cliente pelo portal ou por um relatório com sua marca; qualquer pessoa que receba um link de relatório (relatórios em endereços aleatórios, não em mecanismos de busca). Quando o tipo de formulário é incerto, um modelo de linguagem local em nosso próprio servidor recebe a estrutura do formulário com título da página, endereço da página e o texto visível do formulário (até 400 caracteres) para classificação; não recebe imagens. Para verificações pagas elegíveis, o modelo local também recebe o nome do host, o resultado geral e a pontuação, o CMS, o tipo de formulário relevante e o endereço da página, eventuais plugins identificados e constatações selecionadas com falha ou resultado incerto para produzir um plano de ação. A solicitação é mantida temporariamente na fila interna de tarefas e excluída após a coleta ou pela limpeza programada de entradas com mais de uma hora. |
| País terceiro | Nenhum. |
| Retenção | Resultados de verificações de um domínio por no máximo 13 meses; a última verificação concluída por domínio permanece (rotina noturna de exclusão, parte “resultados antigos de verificações”). Formulários, constatações, referências de imagens e os arquivos de imagem são excluídos com o resultado da verificação. Com o domínio, esses dados são excluídos imediatamente (cadeia de exclusão em B.15; exceções na seção 6.4). |
| Limites do mascaramento | As capturas de tela da verificação completa não mascaram nada: mostram o que a página mostra a cada visitante. Os campos do formulário estão vazios quando obtidos, pois o verificador não insere nada; valores preenchidos previamente ficariam visíveis. Não são feitas capturas de tela em áreas protegidas por login (A.5). As imagens das verificações no navegador mascaram os campos de entrada (A.6). |
| Medidas técnicas e organizacionais | Seção 8. Em particular: imagens só podem ser obtidas pelo relatório, e o identificador de imagem de outra pessoa retorna “não encontrado”; relatórios com noindex; cada verificação é executada em seu próprio contêiner isolado. |
Os mesmos dados surgem em verificações sem uma conta (verificação gratuita, estudo, verificação de potencial cliente). Nesses casos, não há um Cliente em cujo nome atuemos; por isso, esses casos aparecem na Parte B (B.5, B.7, B.8).
A.5 Credenciais de conta de teste para a verificação de áreas protegidas por login
| Campo | Informação |
|---|
| Finalidade | Ler formulários que aparecem apenas após o login (área do cliente, área de membros). O verificador faz login com uma conta de teste que o Cliente criou no seu próprio site e lê as páginas especificadas. Fora o formulário de login, não envia nada, não realiza nenhum teste ativo nessa área, não faz capturas de tela e não visita endereços de saída, exclusão ou cancelamento. Se o formulário de login tiver um CAPTCHA, ele para; CAPTCHAs não são contornados. |
| Pré-requisito | Domínio verificado, plano pago, papel 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 de dados | A pessoa em cujo nome a conta de teste é mantida (idealmente ninguém; o Cliente deve usar uma conta funcional); pessoas cujos dados aparecem nas páginas protegidas por login. |
| Categorias de dados pessoais | Nome de usuário e senha da conta de teste, apenas criptografados; uma indicação do nome de usuário (primeiro caractere e comprimento); endereço de login, lista de páginas, nomes dos campos de login, indicador de sucesso, pessoa que a criou, horários, último resultado como código curto (domain_logins). Para uma tarefa em execução, uma cópia do texto cifrado (campo “pacote de login” em scan_jobs). Das páginas protegidas por login: estrutura do formulário como em A.4, sem capturas de tela e sem cookies. |
| Origem | Inseridos pelo Cliente na conta. |
| Base legal (determinada pelo controlador) | Determinada pelo Cliente. O Cliente garante que está autorizado a usar a conta de teste. |
| Destinatários | Nenhum. Nem o Cliente, nem o suporte, nem a interface de programação podem ler as credenciais; a interface mostra apenas a indicação do nome de usuário. |
| País terceiro | Nenhum. |
| Proteção das credenciais | O nome de usuário e a senha são criptografados imediatamente no armazenamento com a chave pública do servidor de verificação (X25519, HKDF-SHA256, AES-256-GCM; o domínio é vinculado como dado associado, para que um texto cifrado não possa ser anexado a outro domínio). Somente o servidor de verificação tem a chave privada. O servidor web, o banco de dados e os backups contêm apenas texto cifrado; nem nós podemos descriptografá-lo nesses locais. O servidor de verificação descriptografa apenas para a execução, transmite as credenciais ao contêiner isolado de verificação somente pela entrada padrão, exclui imediatamente a cópia na tarefa e não a grava em nenhum resultado, registro ou texto de erro. No trajeto até o site do Cliente, elas são protegidas apenas pela criptografia desse site; os limites desse transporte estão descritos na seção 10. |
| Retenção | Credenciais armazenadas até a exclusão pelo Cliente. Na exclusão, o texto cifrado é sobrescrito com dados aleatórios de mesmo comprimento e a linha é excluída; tarefas em espera são limpas (fe_login_loeschen()). Com o domínio, a linha é excluída por uma chave estrangeira. O servidor de verificação apaga as cópias nas tarefas após a execução; tudo que restar (tarefa interrompida, servidor de verificação indisponível) é apagado pela rotina de status no máximo após uma hora (fe_login_aufraeumen(), parte “login_jobs”). Os backups do banco de dados contêm o texto cifrado até a expiração do backup após 14 dias. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: criptografia assimétrica com chaves separadas; lista de bloqueio para caminhos de saída e exclusão; sem capturas de tela em áreas protegidas por login; função apenas para planos pagos e domínios verificados; toda alteração no registro de atividades (sem credenciais). |
Deliberadamente, não desenvolvemos nenhuma forma de armazenar credenciais para o servidor, a área administrativa do CMS ou as contas de hospedagem do Cliente. A conta de teste é uma conta de visitante no site do Cliente, não acesso ao sistema do Cliente.
A.6 Fluxos de navegação de formulários configurados, verificações no navegador e sonda independente
| Campo | Informação |
|---|
| Finalidade | Um formulário monitorado é percorrido em um navegador real (Chromium, WebKit ou ambos) até o momento imediatamente anterior ao envio: carregar a página, realizar cliques anteriores (no máximo cinco, nunca em um campo de entrada ou botão de envio), preencher campos com valores reconhecivelmente sintéticos (como um endereço sob a terminação reservada .invalid), avançar formulários de várias etapas. A verificação no navegador não envia nada; o envio é bloqueado tecnicamente no navegador. Além disso, medições de tempo e comparações visuais do formulário. |
| Categorias de titulares de dados | Como em A.4 (pessoas visíveis na página do formulário); pessoal do Cliente indicado como responsável (A.3). |
| Categorias de dados pessoais | Configuração: endereço do formulário, seletores, endereço de entrada, etapas de clique, escolha do navegador, rótulo, criticidade, atribuição, data-limite (monitored_forms). Resultados por execução: estado, motivo técnico da falha, mensagens de erro sanitizadas, medições de rede e tempo, uma imagem do formulário como JPEG de no máximo 32 KB com campos de entrada mascarados (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 armazenado uma conta de teste (A.5), a verificação completa também a usa para os fluxos de navegação de formulários configurados. Segundo o código medido, as verificações independentes no navegador entre duas verificações completas funcionam sem uma conta de teste. |
| Sonda independente | Está previsto um segundo ponto de verificação em outro local, que faria uma verificação cruzada antes de um alerta. Ele receberia o domínio, a configuração sanitizada e o identificador da tarefa, sem valores inseridos por visitantes nem credenciais. Atualmente, não está configurado (desativado por padrão). Sem a sonda, não há evidência de um segundo local; nesse caso, um alerta baseia-se na nossa própria medição. |
| Origem | Configurados pelo Cliente; resultados da obtenção da página do Cliente. |
| Base legal (determinada pelo controlador) | Determinada pelo Cliente para o conteúdo do seu site e para as responsabilidades do seu pessoal. |
| Destinatários | O Cliente; quando uma sonda estiver configurada, seu operador (atualmente ninguém). |
| País terceiro | Nenhum. |
| Retenção | Resultados de execuções no navegador, tarefas de navegador concluídas e séries temporais após 13 meses (rotina noturna de exclusão, partes “browser_runs”, “browser_jobs”, “form_performance”). Configurações até a exclusão do domínio (individualmente, podem ser alteradas ou desativadas, não excluídas); com o domínio, são excluídas, junto com execuções, observações e séries temporais, por chaves estrangeiras. |
| O que a medição comprova | Tempos e estados do nosso navegador de verificação. Eles não medem a experiência dos visitantes reais e não comprovam taxas de conclusão nem consultas perdidas. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: envio impedido tecnicamente; apenas endereços no mesmo domínio; imagens mascaradas; contêiner isolado de verificação. |
A.7 “Fix it for me” – código de formulário colado
| Campo | Informação |
|---|
| Finalidade | O Cliente cola o código do seu formulário; um modelo de linguagem em nosso próprio hardware incorpora o módulo de proteção. O retorno é o arquivo modificado, um patch, o resultado de uma verificação de sintaxe e uma indicação de se a chamada de verificação foi efetivamente incorporada. Sem código colado, o serviço fornece um módulo pronto com os nomes dos campos da última verificação. |
| Categorias de titulares de dados | Pessoas cujos dados por acaso estejam no código colado (como um endereço de destinatário, nomes em comentários, credenciais de um servidor de e-mail). |
| Categorias de dados pessoais | O código colado, no máximo 30.000 caracteres. No banco de dados, apenas uma entrada no registro de atividades (ação “fix_ai” com espaço de trabalho e horário), que conta para o limite diário de atualmente dez chamadas por espaço de trabalho. |
| Origem | Colado pelo Cliente. |
| Base legal | Execução do contrato com o Cliente (Art. 6(1)(b) do RGPD) para o código em si; para dados de terceiros contidos nele por acaso, o Cliente determina a base. |
| Destinatários | Nenhum. O modelo de linguagem é executado em nosso próprio servidor de verificação na rede interna; nenhum serviço externo de IA, nem mesmo como alternativa de contingência. |
| País terceiro | Nenhum. |
| Retenção | O código não é armazenado. Um arquivo temporário é criado para a verificação de sintaxe e excluído imediatamente depois. A entrada no registro de atividades é excluída após 365 dias. |
| Nota ao Cliente | Código que contenha senhas, chaves de API ou dados pessoais deve ser limpo antes de ser colado. Não verificamos o conteúdo. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: apenas proprietários e administradores em planos pagos; o código colado é transmitido ao modelo identificado como dados e nunca é executado; sem upload para servidores de terceiros. |
A.8 Marca própria (white-label) e pessoas de contato da agência
| Campo | Informação |
|---|
| Finalidade | Os relatórios, relatórios breves, registros de evidências e o portal de clientes de uma agência (plano Business) aparecem sob sua marca, mediante solicitação sob um subdomínio da própria agência. |
| Categorias de titulares de dados | Pessoas de contato da agência cujo nome ou dados de contato aparecem na linha de contato. |
| Categorias de dados pessoais | Nome da empresa, site, linha de contato, nota ao cliente, cor de destaque, aparência, arquivo de logotipo, controle da referência a formexposed, domínio próprio com identificador e status de verificação (workspace_branding). |
| Origem | Inseridos pela agência. |
| Base legal | Execução do contrato com a agência (Art. 6(1)(b) do RGPD). Quando a linha de contato identifica pessoal da agência, a agência determina a base. |
| Destinatários | Qualquer pessoa a quem a agência forneça um relatório, relatório breve ou link de portal. |
| País terceiro | Nenhum. |
| Retenção | Até alteração pela agência; a marca e o arquivo de logotipo são excluídos com o espaço de trabalho (fe_arbeitsbereich_daten_loeschen()). Um domínio próprio cuja verificação DNS falhe por sete dias é desativado. O domínio próprio fica desativado por padrão. |
| Medidas técnicas e organizacionais | Seção 8. |
A.9 Contagens, indicadores de status e erros de campos do plugin e da extensão
| Campo | Informação |
|---|
| Finalidade | Uma vez por dia, o plugin WordPress e a extensão TYPO3 informam números sobre os formulários no site conectado: envios bloqueados por motivo, envios, e-mails enviados e com falha, indicadores de status das configurações dos formulários, consultas armazenadas por origem e prazo de retenção. Opcional, desativado por padrão: eventos de formulários e categorias de erros de campos por posição do campo. Esses números produzem “Proteção em números”, o relatório mensal, o alerta de silêncio de atividade e os avisos sobre configurações arriscadas. |
| Classificação | Os números são projetados para não descrever nenhuma pessoa. Nós os listamos na Parte A porque surgem de eventos no site do Cliente acionados pelos visitantes do Cliente; em nossa avaliação, são dados pessoais no máximo em casos limítrofes (um site com pouquíssimos envios em determinado dia). A transmissão em si (chaves, versões, host) está na Parte B (B.20). |
| Categorias de titulares de dados | Visitantes do site do Cliente que enviam um formulário. |
| Categorias de dados pessoais | Números diários por host: bloqueados no total e por motivo, envios, e-mails enviados e com falha, categoria de erro de envio de e-mail (apenas uma de quatro categorias, nunca o texto do erro, pois pode conter endereços de destinatários), contagens de respostas do reCAPTCHA, consultas excluídas e liberadas (plugin_stats). Status: versões de uma lista fixa de plugins de formulário, CAPTCHA e e-mail, indicadores de configurações como números, prazos de retenção (plugin_health). Notificações de alterações: nome e versão de um plugin atualizado (plugin_changes). Opcional: contadores por formulário e dia com categorias de erro por posição do campo (form_metrics). Nunca: valores inseridos, nomes de campos, senhas, arquivos, endereços de e-mail, nomes, endereços IP ou identificadores persistentes de visitantes. |
| Origem | O plugin no site do Cliente, por uma interface de programação usando o segredo de conexão do site. |
| Base legal (determinada pelo controlador) | Determinada pelo Cliente; o Cliente decide se ativa as contagens opcionais e como informa seus visitantes. |
| Destinatários | O Cliente. Os domínios dos links em mensagens bloqueadas entram na proteção coletiva (B.21). |
| País terceiro | Nenhum. |
| Retenção | Números diários, notificações de alterações e contadores de formulários após 13 meses (rotina noturna de exclusão, partes “plugin_stats” e “form_metrics”). Os indicadores de status são sobrescritos a cada informe. Todos os dados de plugin de um host são excluídos assim que nenhum domínio no sistema se refira mais a esse host (imediatamente na exclusão do último domínio; dados legados à noite, parte “orphan_hosts”). |
| O que os números comprovam | O que o plugin contou. Não comprovam taxas de conclusão nem consultas perdidas. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: aceitação apenas com o par de chaves vinculado ao site; apenas chaves conhecidas e números são aceitos, todo o restante é descartado; dias fora de uma janela de 14 dias são rejeitados. |
A.10 Limite: o que permanece apenas no site do Cliente
As funções a seguir do plugin WordPress e da extensão TYPO3 tratam dados exclusivamente no servidor do Cliente. Eles não chegam a nós, e não temos acesso a eles. Somente o operador do site é responsável; ele decide sobre a ativação, os prazos de retenção e como informar seus visitantes. Para essa finalidade, o plugin sugere parágrafos para a política de privacidade do operador.
| Função | O que é tratado localmente | Retenção do lado do Cliente |
|---|
| Quarentena | Envios interrompidos com motivo, que podem ser liberados por e-mail para o endereço do site | 14 dias |
| Rede de segurança | Envios cujo e-mail de formulário falhou, para reenvio (ativada por padrão) | 30 dias |
| Desafio aritmético em vez de reCAPTCHA | Tarefa aritmética no navegador do visitante, sem serviço de terceiros (desativado por padrão) | – |
| Configurações de retenção | Exclusão de consultas armazenadas em plugins de formulário após o período escolhido pelo operador (desativada por padrã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 etapas de navegação no armazenamento de sessão do navegador de um administrador conectado; os valores inseridos não são lidos. Apenas a configuração selecionada é transmitida (então 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 | ocorrências adicionais são contadas localmente, sem ativação automática | sete dias |
A.11 Proteção de formulários (formconfirmed)
| Campo | Informação |
|---|
| Finalidade | Avaliação de envios feitos por meio de formulários nos sites do Cliente, a fim de reconhecer envios automatizados: emissão e verificação de tarefas (prova de trabalho), tokens de verificação de uso único, tempo de preenchimento, campo-armadilha, solicitações em excesso; a pedido do Cliente, avaliação do texto da mensagem por um modelo de linguagem. Somente para Clientes que ativam a proteção de formulários. |
| Categorias de titulares de dados | Visitantes dos sites do Cliente que abrem uma página com formulário protegido ou o enviam. |
| Categorias de dados pessoais | Endereço IP (armazenado apenas de forma truncada e com hash gerado com uma chave que muda diariamente), endereço e domínio da página, horários e tempo de preenchimento, campo-armadilha preenchido sim/não, identificação do navegador no registro do servidor web; somente com a verificação de conteúdo ativada, o texto da mensagem (apenas na memória). |
| Origem | Navegador do visitante (tarefa, token de verificação); servidor do Cliente (solicitação de verificação e, se for o caso, texto). |
| Destinatários | O Cliente (pontuação, ação, motivos). Nenhum outro; não há suboperadores para este tratamento. |
| País terceiro | Nenhum. |
| Retenção | Identificador com hash 1 hora; tokens de verificação usados no máximo 11 minutos; resultados da verificação sem endereço IP e sem texto 30 dias; números diários 400 dias; registro do servidor web 14 dias; texto sem armazenamento. |
| Medidas técnicas e organizacionais | Seção 8; além disso, truncamento e hash com chave diária, tarefas assinadas, uso único, modelo de linguagem em hardware próprio sem registro do texto em log. |
4. Parte A – destinatários, suboperadores e transferências para países terceiros
A tabela a seguir lista os destinatários que nós mesmos contratamos e que podem receber dados da Parte A. A lista determinante, atualizada continuamente, é a página Suboperadores; se ela divergir desta tabela, isso será uma constatação, não uma questão de formatação.
| Destinatário | O que recebe | País terceiro | Base | Status |
|---|
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Caixa de e-mail de controle da verificação de entrega (A.1); envio de e-mails de alerta (A.3), confirmações e relatórios aos assinantes do portal (A.2) | Local de tratamento ainda a verificar; veja a página “Suboperadores” | Acordo de Tratamento de Dados; base de transferência ainda a verificar | Pendente. O contrato relevante, os locais reais de tratamento e a base de transferência ainda não estão documentados. Este registro não confirma uma certificação nem um contrato celebrado. |
| Namecheap, Inc. (registrador, DNS; encaminhamento de e-mail até a configuração da caixa de e-mail) | Até a configuração da caixa de e-mail, mensagens gerais recebidas em endereços do nosso domínio; não as cópias da verificação de entrega, que só chegam com registros MX apontando diretamente para a caixa de e-mail (A.1) | EUA | a verificar: certificação no Quadro de Privacidade de Dados UE-EUA ou cláusulas contratuais-padrão | Em uso; base pendente. |
| Nosso próprio servidor de verificação com um modelo de linguagem local | Estrutura do formulário para classificação e constatações selecionadas com metadados da verificação para planos de ação em contas pagas (A.4), código colado (A.7), acesso de teste descriptografado apenas durante a execução (A.5) | – | Operado por nós, não por um terceiro | Em uso. |
| Sonda independente em um segundo local | Domínio, configuração sanitizada, identificador da tarefa (A.6) | depende do local | a determinar antes da entrada em operação | Não configurada. |
Hospedagem: nenhum terceiro. Aplicação, banco de dados, capturas de tela e backups são mantidos em nossos próprios servidores na Polônia. Se migrarmos para um provedor de data center ou nuvem, este parágrafo precisará ser reescrito.
4.1 Canais de alerta escolhidos pelo Cliente
Além dos destinatários que contratamos, há canais que o Cliente escolhe para seus alertas (A.3). Nosso servidor aciona a transmissão; o Cliente determina o destino e o provedor. Escolher um canal não nos exime das nossas próprias obrigações como operador. O papel, o contrato e as salvaguardas exigidas para países terceiros devem ser determinados para cada provedor; para os serviços de chat, isso ainda não foi concluído (questão pendente para a revisão jurídica).
| Canal | O que é enviado | Sede do provedor |
|---|
| E-mail | Domínio, evento, explicação, link; para o endereço informado | por Namecheap, Inc. (Private Email), Phoenix, Arizona, USA |
| Webhook para um endereço de livre escolha | Evento como JSON (domínio, eventos, linhas, link, registro de tempo), 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 informado | predominantemente EUA |
| Telegram | destino escolhido pelo Cliente; enviamos a mensagem pelo nosso bot para o ID de chat vinculado | fora da UE, sem decisão de adequação; a base de transferência é uma questão pendente para a revisão jurídica |
Em nenhum caso é enviado o conteúdo de uma mensagem de visitante. As notificações levam domínio, evento e link.
5. Parte B – Art. 30(1): tratamento sob nossa própria responsabilidade
Controlador de tudo nesta parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polônia, contact@lukaswojcik.com. Nenhum representante necessário (estabelecido na União). Nenhum encarregado da proteção de dados designado (seção 9). Medidas técnicas e organizacionais: seção 8 e a página Medidas Técnicas e Organizacionais. A forma como os titulares dos dados exercem seus direitos está descrita na página Acesso, Exclusão e Seus Outros Direitos; os titulares de contas podem baixar seus dados por conta própria como arquivo (Configurações).
Quando nos baseamos em interesses legítimos (Art. 6(1)(f) do RGPD), indicamos o interesse e o motivo pelo qual um meio menos invasivo não é suficiente. A ponderação é nossa avaliação; faz parte da revisão jurídica.
B.1 Visitantes do nosso site – registros do servidor web
| Campo | Informação |
|---|
| Finalidade | Operação e segurança do site e da aplicação: entrega, solução de problemas, detecção de ataques e sobrecarga. |
| Categorias de titulares de dados | Todos que abrem uma página de formexposed.com ou form.exposed, incluindo visitantes de páginas de Clientes cujos navegadores carregam nossa imagem de selo (B.18), destinatários que abrem um relatório ou link de confirmação de recebimento e sites cujo plugin chama nossa interface. |
| Categorias de dados pessoais | Endereço IP completo, horário, endereço solicitado, código de status, bytes transferidos, página de origem (referenciador), identificador do navegador (user agent). |
| Onde são armazenados | Registros de acesso do proxy a montante e do servidor web como arquivos no servidor web, não no banco de dados. |
| Origem | O navegador ou programa que faz a solicitação. |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: operação segura e ininterrupta. Ponderação: sem o endereço completo, solicitações repetidas do mesmo remetente não podem ser relacionadas e ataques não podem ser repelidos; um endereço truncado não permite essa distinção. Os registros não são combinados com outros dados e são excluídos após um prazo curto. |
| Destinatários | Nenhum. |
| País terceiro | Nenhum. |
| Retenção | 14 dias: rotação diária com 14 gerações e, depois, sobrescritos (serviço de rotação de registros do sistema, não a rotina noturna de exclusão da aplicação). |
| Medidas técnicas e organizacionais | Seção 8. |
B.2 Registro de visualizações de páginas da aplicação
| Campo | Informação |
|---|
| Finalidade | Segurança e detecção de abuso (quem solicita o quê e com qual frequência), rastreabilidade do acesso à conta, estatísticas simples de uso sem serviço de análise. |
| Categorias de titulares de dados | Todos os visitantes do site e usuários da aplicação em visualizações reais de páginas (sem solicitações em segundo plano, sem envios de formulários). |
| Categorias de dados pessoais | Endereço IP completo, país derivado dele no momento da gravação (banco de dados geográfico local, sem consulta a terceiros), ID da conta para usuários conectados, endereço solicitado e página de origem (tokens de acesso nesses endereços, como os de links de relatórios ou portais, mascarados), identificador do navegador e o tipo de dispositivo, sistema operacional e navegador derivados dele, idioma, horário (access_logs). Durante “Visualizar como Cliente” (B.14), nenhum ID de conta é definido, para que as visualizações de páginas pelo suporte não apareçam no registro do Cliente. |
| Origem | A solicitação do navegador. |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: prevenção de abuso e rastreabilidade. Ponderação: como em B.1; o prazo de retenção é maior porque padrões de abuso se tornam visíveis ao longo de semanas. Se o endereço IP deve ser truncado ou o prazo de retenção reduzido é uma questão pendente para a revisão jurídica. |
| Destinatários | Nenhum. Os titulares de contas recebem suas próprias visualizações de páginas na exportação de dados. |
| País terceiro | Nenhum. |
| Retenção | 60 dias (à noite entre 03:00 e 03:05, srv/cron_status.php, configuração “registro de visualizações de páginas”). |
| Medidas técnicas e organizacionais | Seção 8. O endereço IP só é obtido de um cabeçalho encaminhado se a solicitação vier do nosso próprio proxy a montante e, nesse caso, apenas a entrada acrescentada por esse proxy; caso contrário, qualquer pessoa poderia declarar sua origem à vontade. |
B.3 Cookies e armazenamento no navegador
| Campo | Informação |
|---|
| Finalidade | Armazenamento tecnicamente necessário: sessão, proteção contra falsificação de solicitações entre sites (CSRF), contagem dos limites para verificações sem uma conta, login, permanência do login mediante solicitação, exibição clara ou escura. |
| Categorias de titulares de dados | Visitantes e usuários 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 por HTTPS). Cookie bp_remember apenas após escolher “Manter conectado” (seletor e verificador; 30 dias). Armazenamento local bp_theme (claro, escuro ou sistema). Na área administrativa, adicionalmente configurações locais de exibição dos operadores. Para os limites, um hash é formado a partir do identificador de sessão; o próprio identificador não é armazenado. |
| Não definidos | Nenhum cookie de análise, publicidade ou rastreamento. O programa de parceiros (B.33) funciona sem cookie. A imagem do selo nas páginas de Clientes não define cookie (B.18). O reCAPTCHA pode definir cookies do Google quando um formulário protegido é enviado (B.23). |
| Base legal | Acesso ao dispositivo terminal: estritamente necessário para o serviço solicitado pelo usuário (§ 25(2), nº 2, da TDDDG, a Lei alemã de Proteção de Dados em Telecomunicações e Serviços Digitais; Art. 399(3) da PKE, a Lei polonesa 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. |
| Retenção | Sessão; 30 dias para o token de permanência de login. A rotina noturna exclui tokens expirados de permanência de login no banco de dados (remember_tokens); na saída, alteração de senha e revogação de um dispositivo, imediatamente. |
| Medidas técnicas e organizacionais | Seção 8. |
B.4 Verificação gratuita sem uma conta – aceitação, limites e monitoramento de abuso
| Campo | Informação |
|---|
| Finalidade | Qualquer pessoa pode solicitar a verificação de um domínio sem uma conta. Para que o campo de entrada não se torne uma arma contra sites de terceiros, aplicam-se limites em níveis: uma verificação anônima por domínio em sete dias (depois disso, 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. Padrões suspeitos são registrados e informados ao operador. Os limites por endereço IP, por sessão e para todo o sistema, cada um contado separadamente, também se aplicam à verificação pelo plugin sem uma conta (um plugin com um par de chaves vinculado conta por site em vez de por endereço) e ao opt-out (B.30); a ferramenta gratuita de cabeçalhos (B.9) tem seus próprios limites por endereço IP e dia e para todo o sistema. |
| Categorias de titulares de dados | Pessoas que acionam uma verificação, uma solicitação da ferramenta de cabeçalhos ou um opt-out; servidores nos quais um plugin está instalado. |
| Categorias de dados pessoais | Registro de cada solicitação: origem (verificação, plugin, ferramenta de cabeçalhos, opt-out), endereço IP completo, hash do identificador de sessão, host verificado, país a partir do endereço IP, aceitação ou rejeição com motivo, horário (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, horários de detecção e resolução, pessoa que resolve (abuse_flags). Tarefa: host, modo, nível de confiança e um hash truncado da sessão como identificador do solicitante (scan_jobs). Relatório: identificador aleatório, host, idioma, expiração, primeira visualização, número de visualizações (reports). Idade do domínio em cache a partir da consulta ao registro (domain_age_cache). |
| Origem | O que a pessoa informa; sua solicitação; consulta ao registro (RDAP) para a idade do domínio. |
| Base legal | Execução da verificação solicitada: Art. 6(1)(b) do RGPD (uso da verificação gratuita nos termos dos Termos de Serviço); alternativamente, (f). Limites e monitoramento: Art. 6(1)(f). Interesse: impedir que o serviço seja usado como ferramenta contra sites de terceiros ou como um disparador de spam em massa. Ponderação: sem vínculo com o endereço e a sessão, os limites não poderiam ser aplicados; o prazo de sete dias é tão curto quanto o maior limite contado a partir dele. |
| Destinatários | Google (reCAPTCHA no envio, B.23). Para a idade do domínio, o verificador consulta o serviço de redirecionamento RDAP rdap.org, que encaminha ao registro responsável; apenas o nome do domínio é transmitido. Quando ocorre uma anomalia, o operador recebe um sinal pelo Telegram sem nenhuma variável (sem host, sem endereço). O relatório pode ser visto por quem tiver seu link aleatório. |
| País terceiro | EUA pelo reCAPTCHA (B.23). |
| Retenção | Registro de solicitações por 7 dias (à noite, srv/cron_status.php). Anomalias resolvidas, 90 dias após a resolução; as não resolvidas permanecem até que alguém as resolva (seção 10). Os relatórios anônimos expiram após 30 dias; a rotina noturna então exclui relatório, tarefa, resultado da verificação, formulários, constatações e imagens (fe_reports_aufraeumen()). Um administrador pode liberar manualmente entradas de um endereço; isso exclui seu registro das últimas 24 horas. |
| Medidas técnicas e organizacionais | Seção 8. Parada de emergência para todas as verificações anônimas na área administrativa; controle de contrapressão que não aceita novas verificações gratuitas quando há acúmulo de tarefas. |
B.5 Verificação de sites de terceiros pelo rastreador
| Campo | Informação |
|---|
| Finalidade | Verificação de segurança de formulários públicos de contato: salvaguardas contra spam e abuso, recursos de proteção de dados e acessibilidade, scripts incorporados de terceiros, comportamento após rejeição no banner de cookies, exibição em dispositivos móveis. Aplica-se a verificações sem uma conta (B.4), a domínios em uma conta ainda não verificados e como base para o estudo (B.7) e a verificação de potencial cliente (B.8). Para domínios verificados em uma conta, atuamos em nome do Cliente (A.4). |
| Comportamento do rastreador | Identificador próprio com referência à página do rastreador; lê o robots.txt antes da verificação e para se uma regra disallow abranger a página inicial (também se o robots.txt estiver inacessível ou houver erro de servidor); regras disallow para subcaminhos individuais não são observadas separadamente. A verificação de disponibilidade do formulário, a obtenção da comprovação, a ferramenta de cabeçalhos e a busca por arquivos expostos não leem o robots.txt. No máximo oito páginas públicas por verificação, além de até três páginas com um clique em “Rejeitar” no banner de cookies, até três páginas em visualização de celular, sondagens ativas para domínios verificados e até cinco páginas protegidas por login (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, redirecionamentos são conferidos novamente; lista de bloqueio e opt-out são conferidos antes da aceitação e uma segunda vez no verificador. Passivo: sem comprovação de controle, nada é enviado para Clientes (exceção: verificações internas dos nossos próprios domínios de teste e demonstração, B.6). |
| Categorias de titulares de dados | Operadores dos sites verificados (quando são pessoas físicas, como empresários individuais); pessoas que por acaso estejam visíveis nas páginas verificadas. |
| Categorias de dados pessoais | Como em A.4: endereços e títulos de páginas, estrutura do formulário (nomes, tipos e rótulos de campos, sem valores de campos), salvaguardas, scripts de terceiros (endereços; IDs de contas de pixels e ferramentas de gravação são substituídos antes do armazenamento), comportamento do banner de cookies, capturas de tela (área visível da página inicial, formulários). Se um endereço de destinatário aparecer no formulário, apenas seu domínio (scans, forms, findings, scan_screenshots). |
| Origem | Páginas publicamente acessíveis. |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: realizar a verificação de segurança solicitada; alertar operadores de sites sobre pontos fracos que possam prejudicar seus visitantes. Ponderação: lê-se apenas o que todo visitante vê, em pequena escala e sem enviar nada; o operador pode excluir permanentemente seu domínio a qualquer momento, sem comprovação. As informações nos termos do Art. 14 do RGPD são fornecidas pela página do rastreador, pelo opt-out e pela Política de Privacidade; se isso é suficiente nos termos do Art. 14(5)(b) é uma questão pendente para a revisão jurídica. |
| Destinatários | Quem aciona o relatório e qualquer pessoa a quem forneça o link aleatório; o modelo de linguagem local em nosso próprio servidor quando o tipo de formulário é incerto (estrutura do formulário, título e endereço da página, texto visível do formulário). Avisos de vulnerabilidades a partir de versões de plugins nunca aparecem em relatórios anônimos. |
| País terceiro | Nenhum. |
| Retenção | Anônimo: 30 dias (B.4). Verificação de potencial cliente: 90 dias (B.8). Estudo: até a publicação (B.7). Domínio em uma conta: no máximo 13 meses, a última verificação permanece; imediatamente com o domínio. Verificações internas pelo operador sem um domínio e sem um relatório (como as criadas pela linha de comando): sem prazo de retenção (seção 10). Arquivos temporários no servidor de verificação são excluídos após cada execução. |
| Medidas técnicas e organizacionais | Seção 8. Em particular: contêiner separado de verificação com privilégios reduzidos, sistema de arquivos somente de leitura, limite de memória e rede própria; dupla conferência do destino. |
B.6 Envios de teste ativos
| Campo | Informação |
|---|
| Finalidade | Verificar se um formulário de contato aceita um envio sem proteção, se CAPTCHA, armadilha (honeypot), token, validação de endereço de e-mail e limitação de frequência produzem efeito no servidor e se cabeçalhos podem ser injetados. |
| Pré-requisito | Para Clientes, apenas em domínios para os quais tenha sido fornecida comprovação de controle (registro DNS, metatag, arquivo ou plugin conectado); além disso, o operador usa uma ferramenta interna de linha de comando para criar verificações com o nível “verified” para nossos próprios domínios de teste e demonstração. Apenas com o controle global ativado, apenas para um formulário classificado de forma confiável como formulário de contato geral. Nunca para pedidos, agendamentos, cadastros, newsletters, pagamentos, uploads de arquivos, campos obrigatórios com dados pessoais reais ou domínios de autoridades públicas, instituições de saúde ou ensino. |
| Categorias de titulares de dados | Pessoal do Cliente que recebe os e-mails de formulário. |
| Categorias de dados pessoais | O envio de teste não contém dados pessoais: remetente “FormExposed Security Scanner”, nosso próprio endereço de remetente ou um endereço sob .invalid, uma linha de assunto identificada e um texto no idioma da página com referência à página do rastreador e ao opt-out e o número da verificação. Armazenados por nós: a resposta da página, constatações, uma imagem da página seguinte (como em A.4). |
| Escopo | No máximo cinco envios por verificação (configuração, padrão 5); recorrentes na frequência de verificação do plano, diariamente no plano mais alto. |
| Origem | A instrução do Cliente. |
| Base legal | Execução do contrato com o Cliente (Art. 6(1)(b) do RGPD); os envios vão para o próprio formulário do Cliente. Para os destinatários do lado do Cliente: a organização do Cliente. |
| Destinatários | O Cliente (seu e-mail de formulário). |
| País terceiro | Nenhum por nosso intermédio. |
| Retenção | Resultados como em A.4. |
| Medidas técnicas e organizacionais | Seção 8. A injeção de cabeçalhos é apenas detectada, nunca realizada com um destinatário real; a validação de endereço de e-mail usa apenas um domínio que não pode existir. |
B.7 Estudo “Índice de segurança de formulários”
| Campo | Informação |
|---|
| Finalidade | Estatísticas sobre a proteção de formulários de contato em um país ou setor. São publicados apenas totais, sem nomes de sites; segmentos apenas a partir de 20 páginas com formulário. |
| Categorias de titulares de dados | Operadores dos sites na lista; pessoas incidentalmente visíveis. |
| Categorias de dados pessoais | Como em B.5, apenas passivo. Adicionalmente, a lista: host, segmento, status, tarefa (study_domains); estudo com título, país, totais de resultados (studies). |
| Origem | Uma lista de sites públicos compilada pelo operador; as próprias páginas. |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: informações estatísticas sobre o estado da segurança de formulários. Ponderação: passivo, com frequência limitada (poucas tarefas por execução), aplicam-se lista de bloqueio e opt-out, publicação apenas como totais, os dados brutos são excluídos. |
| Destinatários | O público, apenas totais. |
| País terceiro | Nenhum. |
| Retenção | Os dados brutos (resultados de verificações, formulários, constatações, imagens, tarefas) são excluídos na publicação (fe_studie_veroeffentlichen()). A lista de hosts com segmento permanece depois; não há prazo de retenção para ela nem para estudos que nunca são publicados (seção 10). O operador decide quais listas são verificadas e se os estudos são publicados. |
| Medidas técnicas e organizacionais | Seção 8. |
B.8 Verificação de potencial cliente (modo de prospecção para agências)
| Campo | Informação |
|---|
| Finalidade | Uma agência (plano Business) verifica passivamente o site de um potencial cliente e recebe um relatório breve sob sua marca e o relatório passivo. Não entramos em contato com ninguém; a própria agência encaminha o link. |
| Categorias de titulares de dados | Operador do site verificado; pessoas incidentalmente visíveis; pessoal da agência que aciona a verificação. |
| Categorias de dados pessoais | Como em B.5, apenas passivo. Além disso: espaço de trabalho, pessoa que aciona a verificação, host, identificador aleatório do relatório, horário (prospect_checks). |
| Origem | O que a agência informa; páginas públicas. |
| Base legal | Art. 6(1)(f) do RGPD (nosso interesse em prestar o serviço e o interesse da agência em uma abordagem fundamentada). Os papéis da agência e o nosso e as obrigações da agência ao encaminhar o relatório são questões pendentes para a revisão jurídica: se a agência enviar o relatório por e-mail sem solicitação ou fizer uma ligação, isso é marketing direto que exige consentimento nos termos do Art. 398 da PKE e do § 7(2) da UWG (a Lei alemã contra a Concorrência Desleal), inclusive entre empresas. Essa é a responsabilidade da agência; os Termos de Serviço a obrigam nesse sentido. |
| Destinatários | A agência e qualquer pessoa a quem ela forneça o link. |
| País terceiro | Nenhum. |
| Retenção | O relatório e o resultado da verificação expiram após 90 dias e são então excluídos pela rotina noturna (fe_reports_aufraeumen()); a entrada da verificação é excluída após 90 dias na rotina diária de proteção coletiva a partir das 04:00 (srv/cron_status.php). Com o espaço de trabalho, imediatamente. |
| Medidas técnicas e organizacionais | Seção 8. Cota mensal (configuração, padrão 30); a mesma página dentro de sete dias retorna o mesmo relatório; aplica-se o opt-out. |
B.9 Ferramenta de cabeçalhos sem uma conta
| Campo | Informação |
|---|
| Finalidade | Nota gratuita (de A+ a F) para os cabeçalhos de segurança da página inicial de um domínio. Duas solicitações, sem navegador, sem formulário, sem envio. |
| Categorias de titulares de dados | Pessoas que usam a ferramenta; operadores do domínio verificado. |
| Categorias de dados pessoais | Registro de solicitações como em B.4 (origem “headers”, endereço IP, hash da sessão, host). Resultado: host, nota, pontos, cabeçalhos avaliados (header_checks). |
| Base legal | Art. 6(1)(f) do RGPD, como em B.4 e B.5. |
| Destinatários | Google (reCAPTCHA, B.23). |
| País terceiro | EUA pelo reCAPTCHA. |
| Retenção | Registro de solicitações por 7 dias; resultados após atualmente 90 dias (rotina noturna de exclusão, parte “header_checks”, configuração “headers_keep_days”). Para domínios em uma conta, a nota é determinada novamente diariamente e armazenada com o domínio. |
| Medidas técnicas e organizacionais | Seção 8. Limites por endereço IP e dia; aplica-se o opt-out. |
B.10 Contas de clientes
| Campo | Informação |
|---|
| Finalidade | Operar contas de clientes, espaços de trabalho e planos. |
| Categorias de titulares de dados | Clientes (empresas) e membros das suas equipes com conta própria. |
| Categorias de dados pessoais | Endereço de e-mail e forma normalizada, senha apenas como hash, nome (obrigatório), sobrenome e empresa (quando fornecidos); a aplicação não armazena endereço nem identificação de IVA, eles são fornecidos apenas na Stripe (B.26); status, idioma, modo de exibição, moeda, plano e status de cobrança, ID de cliente e assinatura da Stripe, fim do período de cobrança, cancelamento no fim do período, identificadores de confirmação e redefinição com expiração, novo endereço de e-mail até sua confirmação, horário do cadastro, último login e último endereço IP, horário da revogação de todas as sessões, dados de dois fatores (B.11), relatório mensal ativado/desativado, horário do e-mail de lembrete, liberações por códigos, código de indicação e indicação (users). Espaços de trabalho com nome, horários, status (workspaces); participação com papel e data de entrada (workspace_users). |
| Origem | Cadastro e configurações pela pessoa; status de cobrança da Stripe. |
| Base legal | Art. 6(1)(b) do RGPD (contrato). Último endereço IP: (f) (segurança da conta). |
| Destinatários | Stripe (B.26); prestador de serviços de e-mail para e-mails da conta (B.25). Membros do mesmo espaço de trabalho veem o nome, o endereço de e-mail e o papel dos outros membros. |
| País terceiro | Pela Stripe e pelo prestador de serviços de e-mail. |
| Retenção | Até a exclusão pelo titular da conta. Na exclusão, os espaços de trabalho próprios do titular que ninguém mais usa são excluídos com todos os domínios e seus dados; espaços de trabalho com outros membros passam a outro membro, primeiro a administradores e, entre eles, ao mais antigo. Participações, tokens de permanência de login, dispositivos, chaves de API, códigos pendentes do Telegram, feedback sobre relatórios (B.35) e a linha da conta são excluídos; uma assinatura paga em andamento é primeiro encerrada imediatamente na Stripe, sem reembolso (www/ajax.php, fe_konto_reste_loeschen()). Já um cancelamento na área de cobrança produz efeito no fim do período; depois disso, a conta continua no plano gratuito. O que permanece está descrito na seção 6.4. Contas nunca confirmadas e nas quais nunca houve login são excluídas após 30 dias, salvo se outro membro estiver vinculado ao seu espaço de trabalho (rotina noturna de exclusão, parte “pending_accounts”). Não há exclusão de contas inativas. Se o contrato da conta terminar de outra forma, por exemplo, por rescisão por nós, excluímos a conta em no máximo 30 dias após o fim do contrato; atualmente, isso é feito manualmente (compromisso assumido no Acordo de Tratamento de Dados). |
| Medidas técnicas e organizacionais | Seção 8. |
B.11 Login, dispositivos, segundo fator e registro de atividades
| Campo | Informação |
|---|
| Finalidade | Proteger contas: limitar tentativas de login e outras tentativas de senha, exibir e revogar dispositivos conectados, login com dois fatores, rastreabilidade de alterações. |
| Categorias de titulares de dados | Titulares de contas e membros de equipes; pessoas que tentam fazer login, cadastrar-se ou inserir a senha de um portal de clientes. |
| Categorias de dados pessoais | Tentativas de login: endereço IP, endereço de e-mail informado, sucesso, horário (login_attempts). Dispositivos: hash do identificador de sessão (nunca o próprio identificador), vínculo ao token de permanência de login, endereço IP, identificador do navegador e o navegador, sistema operacional e tipo de dispositivo derivados dele, horários de login, última atividade e revogação e, para “Visualizar como Cliente”, o identificador da pessoa do suporte (login_sessions). Tokens de “Manter conectado”: seletor, verificador, expiração (remember_tokens). Dois fatores: segredo criptografado, horário de ativação, último intervalo de tempo usado, códigos de recuperação apenas como hash (em users). Registro de atividades: conta, espaço de trabalho, ação, destino, detalhes, endereço IP, país, horário (audit_logs). Contadores de tentativas para login, segundo fator, confirmação de senha, redefinição de senha, cadastro e senhas de portais de clientes: uma chave HMAC derivada da finalidade e do ID da conta (para um endereço desconhecido ou uma redefinição, o endereço de e-mail em minúsculas), do endereço IP, da conta e do endereço IP juntos ou do ID do portal (também junto com o endereço IP), número de tentativas, expiração; endereços de e-mail e IP não são armazenados ali em texto simples (tabela auth_attempt_buckets). |
| Base legal | Art. 6(1)(b) do RGPD em conjunto com o Art. 32 (lista de dispositivos, segundo fator) e (f) (tentativas de login, registro de atividades). Interesse: proteger contas contra invasão, documentar alterações (Art. 5(2)). Ponderação: um endereço truncado não responde à pergunta “fui eu?”; o registro de atividades precisa durar além de uma disputa que só surge meses depois. |
| Destinatários | Nenhum. O titular da conta vê seus dispositivos e recebe tentativas de login, dispositivos e atividades na exportação de dados; durante uma sessão de “Visualizar como Cliente”, nem o endereço IP nem o navegador da pessoa do suporte aparecem ali. |
| País terceiro | Nenhum. |
| Retenção | Tentativas de login por 7 dias; após um login bem-sucedido, as tentativas malsucedidas do mesmo endereço são excluídas imediatamente. Contadores de tentativas ao fim da sua janela de tempo (atualmente 15 minutos, uma hora para redefinição de senha e cadastro); os expirados são excluídos no próximo acesso e pela rotina noturna. Dispositivos 90 dias após o último uso ou após a revogação (rotina noturna de exclusão, parte “sessions”), imediatamente com a conta. Os tokens de permanência de login expiram após 30 dias. Registro de atividades por 365 dias (à noite); quando uma conta é excluída, suas entradas permanecem até o fim do prazo de retenção (seção 6.4). |
| Medidas técnicas e organizacionais | Seção 8. |
B.12 Comprovação da celebração do contrato
| Campo | Informação |
|---|
| Finalidade | Comprovar qual versão dos Termos de Serviço, do Acordo de Tratamento de Dados e da Política de Privacidade um Cliente aceitou ou da qual tomou ciência no cadastro e que o Cliente usa o serviço para sua empresa. |
| Categorias de titulares de dados | Clientes. |
| Categorias de dados pessoais | Por documento: conta, documento, versão (hash do texto exibido), ocasião, endereço IP, identificador do navegador, horário (legal_consents). A própria versão exibida com texto integral, idioma, título e endereço, uma vez por versão (legal_versions; não contém dados pessoais). |
| Base legal | Art. 6(1)(b) e (f) do RGPD (comprovação da celebração do contrato, defesa contra pretensões). |
| Destinatários | Nenhum. O titular da conta recebe seus registros na exportação de dados. |
| País terceiro | Nenhum. |
| Retenção | Enquanto a conta existir; após a exclusão da conta, quatro anos a partir da concordância, depois excluídos à noite (srv/cron_status.php). Justificativa no código: prazo de prescrição de três anos a partir do fim do ano, arredondado para cima. Se a legislação polonesa sugere outro prazo faz parte da revisão jurídica. |
| Medidas técnicas e organizacionais | Seção 8. Se faltar qualquer um dos três documentos, o cadastro fica indisponível. |
B.13 Convites para a equipe
| Campo | Informação |
|---|
| Finalidade | Convidar outras pessoas para um espaço de trabalho. |
| Categorias de titulares de dados | Pessoas convidadas. |
| Categorias de dados pessoais | Endereço de e-mail, papel, identificador do convite, pessoa que convida, expiração, horário da aceitação (workspace_invites); o e-mail de convite na caixa de saída (B.25). |
| Origem | Inseridos pelo membro que convida. |
| Base legal | Art. 6(1)(b) do RGPD em relação ao Cliente; em relação à pessoa convidada, (f) (interesse do Cliente em envolver sua equipe). |
| Destinatários | Prestador de serviços de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| País terceiro | Pelo prestador de serviços de e-mail. |
| Retenção | Um convite é válido por 14 dias e apenas enquanto a pessoa que convida for proprietário ou administrador do espaço de trabalho. Convites não aceitos após a expiração; os aceitos, 30 dias após a aceitação (à noite, srv/cron_status.php e parte “invites” em cfg/fristen_lib.php). Com o espaço de trabalho, imediatamente. |
| Medidas técnicas e organizacionais | Seção 8. |
B.14 “Visualizar como Cliente” pelo suporte
| Campo | Informação |
|---|
| Finalidade | Um superadministrador vê a aplicação como um Cliente a vê, para resolver uma dúvida de suporte (“o botão não aparece para mim”). |
| Categorias de titulares de dados | O Cliente em questão; o superadministrador. |
| Categorias de dados pessoais | Tudo que o Cliente vê na aplicação. Registrados: uma linha de dispositivo separada com o identificador do superadministrador (login_sessions), início e fim no registro de atividades (audit_logs). |
| Base legal | Art. 6(1)(b) do RGPD (suporte como parte do serviço), alternativamente (f). |
| Limites | No máximo uma hora, depois saída completa. Encerrar a visualização também desconecta o superadministrador completamente, incluindo a sessão da qual veio; ele só volta à área administrativa fazendo login novamente com senha e segundo fator. Termina imediatamente se o superadministrador perder esse privilégio ou for bloqueado. Tudo que altera a conta do Cliente é bloqueado: senha, endereço de e-mail, segundo fator, dispositivos, assinatura, exportação, exclusão, transferência. A área administrativa fica 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. |
| Retenção | Linha de dispositivo por 90 dias, registro de atividades por 365 dias. |
| Medidas técnicas e organizacionais | Seção 8. |
B.15 Domínios, comprovação de controle e monitoramento
| Campo | Informação |
|---|
| Finalidade | O serviço principal para Clientes: manter domínios na conta, fornecer comprovação de controle, verificar regularmente e detectar alterações. Isso inclui a verificação de disponibilidade do formulário (uma solicitação leve sem navegador a cada 10 a 30 minutos, dependendo do plano), o monitoramento diário de DNS de e-mail e certificado, a data de expiração do domínio, listas de bloqueio, arquivos expostos, versões visíveis externamente, inventário de scripts, alterações visuais no formulário, indisponibilidades de provedores de CAPTCHA e e-mail e o monitoramento de vulnerabilidades de plugins de formulário. |
| Categorias de titulares de dados | Clientes e membros das suas equipes; operadores dos domínios, quando são pessoas físicas. |
| Categorias de dados pessoais | Domínio com host, identificador público, nota, identificação do cliente, tipo e identificador da comprovação, frequência de verificação, monitoramento ativado/desativado, janelas de manutenção, valor de uma consulta, identificadores para selo, verificação de entrega e hook de implantação, chave do plugin, estados e resultados mais recentes dos monitores (DNS, certificado, autenticidade do e-mail de formulário, listas de bloqueio, arquivos expostos, cabeçalhos, versões) (domains). Verificação de disponibilidade por página de formulário (form_pulse). Vulnerabilidades a partir de versões de plugins (vuln_hits). Inventário de scripts com endereço, hash, tamanho, aprovação com pessoa que aprova e motivo (script_inventory, script_changes). Verificações como em A.4. Para arquivos expostos, são armazenados caminho, gravidade e tipo, nunca o conteúdo. |
| Solicitações a terceiros | Consultas DNS (SPF, DMARC, MX, registro de comprovação). Consulta ao registro via RDAP segundo o diretório da IANA: apenas nome do domínio. Listas de bloqueio DNS (SpamCop, PSBL, Mailspike, SURBL; Spamhaus apenas com credenciais de acesso armazenadas, atualmente não): endereços IP do servidor web e de e-mail e o nome do 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 do tempo: apenas um valor de hash (B.19). WPVulnerability: apenas o identificador de um plugin ou tema, ou a versão do WordPress; nós mesmos realizamos a comparação com a versão do plugin instalado. Páginas de status de Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun e Brevo: nada é transmitido além da própria solicitação. |
| Origem | Cliente; solicitações à página do Cliente; diretórios públicos. |
| Base legal | Art. 6(1)(b) do RGPD. |
| Destinatários | Os serviços mencionados não recebem dados pessoais dos nossos Clientes, na medida em que os nomes de domínio e endereços de servidores de uma empresa não sejam dados pessoais; para empresários individuais, o nome do domínio pode ser dado pessoal. Os membros do espaço de trabalho veem o domínio. |
| País terceiro | As solicitações podem chegar a serviços em países terceiros (como consultas a registros, listas de bloqueio). É transmitido apenas o que está indicado na linha “Solicitações a terceiros”. |
| Retenção | Até a exclusão do domínio. fe_domain_loeschen() então exclui imediatamente resultados de verificações, formulários, constatações, imagens, relatórios, tarefas, destinos de alertas e registro de alertas, incidentes, códigos do Telegram, entregas, verificações de disponibilidade, vulnerabilidades e comprovações; por chaves estrangeiras, formulários monitorados, execuções no navegador, conta de teste e contadores de formulários; os dados de plugin do host, se nenhum outro domínio se referir a ele. Também são excluídos o inventário e as alterações de scripts do domínio; eles não têm prazo de retenção próprio (seção 6.4). Resultados de verificações por no máximo 13 meses, o último permanece. |
| Medidas técnicas e organizacionais | Seção 8. Monitoramento de arquivos expostos e versões apenas para domínios verificados, no máximo uma solicitação por caminho, apenas os primeiros 8 KB; sondar caminhos de terceiros sem solicitação seria uma ferramenta de ataque. |
B.16 Alertas, incidentes e escalonamento ao titular da conta
| Campo | Informação |
|---|
| Finalidade | Informar o Cliente sobre falhas e alterações, observar janelas de manutenção, confirmar o recebimento e escalonar incidentes. Quando os destinos são terceiros, atuamos em nome do Cliente (A.3); quando é o próprio titular da conta, o tratamento está descrito aqui. |
| Categorias de titulares de dados | Titulares de contas e membros de equipes como destinatários. |
| Categorias de dados pessoais | Como em A.3. As notificações aparecem no idioma do titular da conta. |
| Base legal | Art. 6(1)(b) do RGPD. |
| Destinatários | Prestador de serviços de e-mail; serviços de chat escolhidos (4.1). |
| País terceiro | Depende do canal (4.1). |
| Retenção | Como em A.3: registro de entrega por 90 dias, notificações de resumo por 30 dias após a entrega, incidentes até a resolução e depois por 180 dias. Destinos de alertas com o domínio. |
| Medidas técnicas e organizacionais | Seção 8. |
B.17 Relatório mensal às contas
| Campo | Informação |
|---|
| Finalidade | No dia 1 de cada mês a partir das 08:00 (recuperação de envios pendentes até o dia 3), um e-mail por conta abrangendo todos os seus domínios: nível, pontuação e alteração, alertas, bots bloqueados, envio de e-mails, valor comparativo. |
| Categorias de titulares de dados | Titulares de contas ativas com o relatório mensal ativado. |
| Categorias de dados pessoais | Endereço de e-mail, idioma, indicadores principais dos domínios. |
| Base legal | Art. 6(1)(b) do RGPD (parte do serviço). Seu recebimento pode ser cancelado nas configurações; pode ser desativado centralmente. |
| Destinatários | Prestador de serviços de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| País terceiro | Pelo prestador de serviços de e-mail. |
| Retenção | Sem armazenamento separado; o e-mail permanece na caixa de saída por 30 dias (B.25). |
| Medidas técnicas e organizacionais | Seção 8. |
B.18 Selo e página pública de confirmação
| Campo | Informação |
|---|
| Finalidade | Um Cliente pode incorporar uma imagem de selo ao seu site e vinculá-la a uma página pública de confirmação. O selo mostra “Protegido” apenas se o domínio estiver verificado, o monitoramento estiver em execução 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 de formulário de contato”. A página de confirmação indica o nível e a data, sem constatações individuais. |
| Categorias de titulares de dados | Visitantes do site do Cliente cujos navegadores carregam a imagem; visitantes da página de confirmação. |
| Categorias de dados pessoais | Ao carregar a imagem: endereço IP, horário, endereço solicitado, página de origem e identificador do navegador no registro do servidor web (B.1). O endereço da imagem não inicia sessão, não define cookie e não grava no registro de visualizações de páginas. A página de confirmação é uma página normal (B.2, B.3). |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: entregar a imagem e manter a operação segura. Se o Cliente e nós somos controladores conjuntos da transmissão do endereço IP do visitante, na acepção da jurisprudência sobre conteúdo incorporado de terceiros, e se é necessário um acordo nos termos do Art. 26 são questões pendentes para a revisão jurídica. O Cliente recebe uma sugestão de texto para sua política de privacidade. |
| Destinatários | Nenhum. |
| País terceiro | Nenhum. |
| Retenção | 14 dias (registro do servidor web). A imagem é mantida em cache por uma hora. Quando o selo é desativado, o identificador deixa de ser válido. |
| Medidas técnicas e organizacionais | Seção 8. |
B.19 Registro de evidências e carimbo do tempo
| Campo | Informação |
|---|
| Finalidade | Um registro por domínio e mês (planos pagos): o que foi verificado, com qual resultado, o que foi informado e o que mudou, como evidência para prestação de contas, seguradoras ou auditorias de fornecedores. Cada versão recebe um número de verificação; uma página pública confirma domínio, período e indicadores principais, sem detalhes. Desde 7 de outubro de 2026, uma autoridade de carimbo do tempo nos termos da RFC 3161 confirma o horário. |
| Categorias de titulares de dados | Clientes; indiretamente, pessoas que possam ser mencionadas no registro como responsáveis por aprovações ou confirmações de recebimento. |
| Categorias de dados pessoais | Domínio, mês, número de verificação, hash do conteúdo (SHA-512), resumo e dados do registro, resposta do carimbo do tempo, autoridade de carimbo do tempo e horário, tentativas malsucedidas (proof_docs). |
| Base legal | Art. 6(1)(b) do RGPD. |
| Destinatários | A autoridade de carimbo do tempo (padrão Certum, alternativa de contingência DigiCert) recebe apenas o hash do registro, não seu conteúdo. Público: indicadores principais pela página de confirmação. O Cliente e qualquer pessoa a quem o Cliente forneça o registro ou o número de verificação. |
| País terceiro | Nenhuma transferência de dados pessoais: um hash não permite inferir o conteúdo. A autoridade alternativa está sediada nos EUA. |
| Retenção | Até a exclusão do domínio (fe_domain_loeschen()). O carimbo do tempo não é um carimbo do tempo qualificado nos termos do eIDAS. |
| Medidas técnicas e organizacionais | Seção 8. |
B.20 Plugin e extensão: verificação, conexão e transmissão
| Campo | Informação |
|---|
| Finalidade | O plugin WordPress e a extensão TYPO3 podem solicitar uma verificação (mesmo sem uma conta), conectar-se a uma conta (a instalação conta como comprovação de controle com um clique na conta), liberar funções de proteção, informar números diariamente (A.9) e comunicar erros de e-mail e modo de manutenção imediatamente. |
| Categorias de titulares de dados | Clientes; operadores de sites que usam o plugin sem uma conta. |
| Categorias de dados pessoais | Por host: versão do plugin e do CMS, número de verificações, identificador do último relatório, hash do segredo de conexão, primeiro e último contato (plugin_sites). Códigos de conexão de uso único como hash com expiração (plugin_connect_tokens). Códigos de implantação de uma agência como hash com prefixo, rótulo, usos, pessoa que os criou (workspace_connect_codes). Registro de solicitações com o endereço IP do servidor que chama (B.4). A chave do plugin é publicamente visível no cabeçalho do site; é um hash do segredo, e o próprio segredo é armazenado apenas como hash e nunca retornado. |
| Base legal | Art. 6(1)(b) do RGPD (conta); sem uma conta, (f) (verificação solicitada, prevenção de abuso). |
| Destinatários | Nenhum. |
| País terceiro | Nenhum. |
| Retenção | Os dados de um host são excluídos assim que nenhum domínio se refira mais a ele; a linha de um plugin sem uma conta, somente após 90 dias sem contato (rotina noturna de exclusão, parte “orphan_hosts”). Códigos de uso único, um dia após a expiração. Códigos de implantação com o espaço de trabalho. |
| Medidas técnicas e organizacionais | Seção 8. Desde 27 de setembro de 2026, o servidor aceita apenas pares de chaves vinculados ao site; os segredos de conexão mais antigos e não vinculados foram excluídos. |
B.21 Proteção coletiva
| Campo | Informação |
|---|
| Finalidade | Defesa compartilhada contra spam: sites conectados informam os domínios dos links em mensagens que sua camada de proteção interrompeu. Um domínio que aparece em pelo menos três sites com pelo menos cinco ocorrências em sete dias é colocado em uma lista que retorna a todos os sites conectados; sua camada de proteção move as mensagens com esses links para a quarentena, nunca as descarta definitivamente. |
| Categorias de titulares de dados | Titulares dos domínios de links informados, quando são pessoas físicas (como o operador de um site de spam em seu próprio nome). Não os remetentes e destinatários das mensagens: endereços, textos e nomes não são informados. |
| Categorias de dados pessoais | Sinais: tipo, domínio, host que informa, dia, ocorrências (swarm_signals). Lista: tipo, domínio, número de sites e ocorrências, horários (swarm_list). Grandes serviços, os domínios dos nossos Clientes e exceções definidas pelo operador nunca são listados. |
| Redes IP | O compartilhamento de redes IP (/24, /48) foi preparado. Está desativado, e o plugin não informa nenhuma; só será ativado após uma revisão jurídica, pois endereços IP são dados pessoais. |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: proteger os formulários de todos os Clientes contra ondas de spam. Ponderação: apenas domínios, limites mínimos contra envenenamento da lista, sem perda de mensagens, remoção possível a qualquer momento. |
| Destinatários | Todos os sites conectados (a lista de domínios). |
| País terceiro | Depende da localização dos sites conectados; a lista também pode chegar a sites fora do EEE. Ela constitui dado pessoal apenas em casos limítrofes (domínios de pessoas físicas). A base de transferência nos termos do Capítulo V do RGPD para esses casos ainda precisa ser determinada (questão pendente para a revisão jurídica). |
| Retenção | Sinais por 30 dias (rotina diária de proteção coletiva a partir das 04:00, cfg/swarm_lib.php). A lista é recalculada diariamente; o que deixa de atingir o limite mínimo sai dela. |
| Medidas técnicas e organizacionais | Seção 8. |
B.22 Chaves de API, interface de programação e servidor MCP
| Campo | Informação |
|---|
| Finalidade | Acesso pelas próprias ferramentas do Cliente (API REST, Zapier, Make, servidor MCP para assistentes de IA) aos domínios, verificações e incidentes do Cliente. |
| Categorias de titulares de dados | Clientes que criam chaves. |
| Categorias de dados pessoais | Chave apenas como hash, prefixo, rótulo, horários de criação, último uso e revogação (api_keys). Chamadas por minuto (api_usage). |
| Base legal | Art. 6(1)(b) do RGPD. |
| Destinatários | A ferramenta à qual o Cliente fornece a chave; o Cliente a determina. |
| País terceiro | Depende da ferramenta do Cliente. |
| Retenção | Chaves até a revogação, imediatamente com a conta; chaves sem uma conta (dados legados), à noite. Contadores de chamadas após um dia (limpos ocasionalmente em uma chamada). |
| Medidas técnicas e organizacionais | Seção 8. |
B.23 reCAPTCHA e nossa própria proteção de formulários
| Campo | Informação |
|---|
| Finalidade | Defesa contra acesso automatizado aos nossos próprios formulários: verificação gratuita, ferramenta de cabeçalhos, opt-out, login, cadastro, esquecimento e redefinição de senha, suporte e contato. Além disso, 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 nossa proteção de formulários formconfirmed (prova de trabalho e token de verificação de uso único) na verificação gratuita, no cadastro, no login e em “esqueci minha senha”. |
| Categorias de titulares de dados | Pessoas que enviam esses formulários. |
| Categorias de dados pessoais | No Google: endereço IP, dados do navegador e do dispositivo, dados comportamentais, cookies do Google. Conosco: a avaliação do Google (pontuação e ação) apenas no momento da verificação, sem armazenamento, nem mesmo quando um envio é rejeitado. Na nossa própria proteção de formulários: endereço IP (armazenado apenas de forma truncada e com hash), página, horários, campo-armadilha preenchido sim/não; nenhum conteúdo. |
| Momento | O script do Google carrega apenas quando um formulário protegido é enviado, não quando a página é aberta. Nossa própria proteção de formulários busca sua tarefa quando a página é aberta e faz o cálculo assim que o formulário é usado. No sistema de desenvolvimento, o reCAPTCHA está desativado. |
| Base legal | Art. 6(1)(f) do RGPD. Interesse: proteção contra bots, especialmente para a verificação gratuita, que, de outra forma, poderia ser usada contra sites de terceiros. Se o acesso ao dispositivo terminal exige consentimento nos termos do § 25 da TDDDG ou do Art. 399 da PKE, mesmo que o script só carregue no envio, é uma questão pendente para a revisão jurídica. Nossa própria proteção de formulários não define cookies, não armazena nada no navegador e não cria impressão digital; ela deverá substituir o reCAPTCHA de forma permanente. |
| Destinatários | Google Ireland Limited; Google LLC. Na nossa própria proteção de formulários, nenhum. |
| País terceiro | EUA (somente reCAPTCHA). Base: certificação no Quadro de Privacidade de Dados UE-EUA ou cláusulas contratuais-padrão; a documentar em detalhe. |
| Retenção | reCAPTCHA: sem armazenamento conosco; no Google, de acordo com suas regras. Proteção de formulários própria: identificador com hash 1 hora, tokens de verificação usados no máximo 11 minutos, resultados da verificação sem endereço IP 30 dias. |
| Indisponibilidade | Se o Google não responder em três segundos ou responder de forma inutilizável, o envio é rejeitado; o mesmo ocorre com um token vazio e 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, um envio sem token de verificação válido é rejeitado; se o serviço não estava acessível para a tarefa, o envio é permitido. |
| Medidas técnicas e organizacionais | Seção 8. |
B.24 Suporte e formulário de contato
| Campo | Informação |
|---|
| Finalidade | Receber e responder a consultas pela janela de suporte e pela página de contato. Ambos usam o mesmo fluxo e a mesma tabela. |
| Categorias de titulares de dados | Solicitantes, conectados ou não. |
| Categorias de dados pessoais | Conta (se conectado; nesse caso, aplica-se o endereço da conta, não o informado), endereço de e-mail, motivo de uma lista fixa, texto de até 4.000 caracteres, status, endereço IP completo, país, identificador do navegador, página de origem (apenas caminhos próprios), idioma, horários de recebimento e resposta (support_requests); entrada no registro de atividades (sem texto); confirmação de recebimento ao solicitante na caixa de saída (B.25), com o texto de até 2.000 caracteres apenas para remetentes conectados, sem o texto para solicitações feitas sem login. |
| Base legal | Art. 6(1)(b) do RGPD quando a consulta diz respeito a um contrato; caso contrário, (f). Endereço IP completo: (f) (limite de três consultas por hora e endereço, prevenção de abuso). |
| Destinatários | Prestador de serviços de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) para confirmação de recebimento e resposta. O Telegram recebe um sinal fixo sem nenhuma variável (“há uma nova solicitação de suporte”) e, portanto, nenhum dado pessoal. |
| País terceiro | Pelo prestador de serviços de e-mail. |
| Retenção | 24 meses (rotina noturna de exclusão, parte “support”); manualmente antes. Quando uma conta é excluída, as consultas permanecem até o fim do prazo de retenção (seção 6.4). |
| Medidas técnicas e organizacionais | Seção 8. reCAPTCHA, nossa própria proteção de formulários, limitação de frequência. |
B.25 Envio de e-mail (caixa de saída)
| Campo | Informação |
|---|
| Finalidade | E-mails transacionais: confirmação de cadastro e de novos endereços de e-mail, redefinição de senha, convites, alertas, relatórios mensais, confirmações e relatórios de portal, confirmações de recebimento e respostas do suporte, lembretes sobre o período de teste e a configuração, notificações operacionais aos operadores. Sem publicidade, sem e-mails a pessoas que não tenham se cadastrado por conta própria nem sido inseridas como destinatárias pelo Cliente. |
| Categorias de titulares de dados | Destinatários desses e-mails. |
| Categorias de dados pessoais | Endereço do destinatário, assunto, conteúdo completo, endereço de resposta, finalidade, rota de envio, status, erro, tentativas, horários (mail_outbox). O conteúdo pode incluir links de confirmação e redefinição com identificadores válidos. |
| Base legal | 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ê seus e-mails enviados na exportação de dados (sem conteúdo). |
| País terceiro | Depende do local de tratamento do prestador de serviços de e-mail; contrato e base de transferência ainda precisam ser documentados (seção 4). |
| Retenção | 30 dias (à noite, srv/cron_status.php). Esse prazo é deliberadamente o mais curto dos registros: um registro longo de envios seria uma coleção de chaves válidas. A rotina de status verifica a cada cinco minutos se chegou o momento de uma nova tentativa. |
| Status | O envio de e-mails deve ser configurado antes do lançamento. Até que o prestador de serviços de e-mail, com sua sede e base, tenha sido definido, os textos legais mostram um marcador. |
| Medidas técnicas e organizacionais | Seção 8. E-mails com falha são tentados novamente em intervalos crescentes e abandonados após um número máximo de tentativas. |
B.26 Pagamentos e cobrança
| Campo | Informação |
|---|
| Finalidade | Celebrar e gerenciar assinaturas (mensais ou anuais pagas antecipadamente), período de teste de 14 dias sem cartão com lembrete três dias antes do fim, pagamento mediante fatura para assinaturas anuais (desativado por padrão), liberações por códigos de provedores de hospedagem e parceiros sem pagamento, faturamento, retenção para fins fiscais. |
| Categorias de titulares de dados | Clientes. |
| Categorias de dados pessoais | Na Stripe: endereço de e-mail, nome, endereço de cobrança, identificação de IVA, dados de pagamento, faturas; como metadados, nosso ID de conta e o plano. Conosco: ID de cliente e assinatura da Stripe, plano, status, fim do período, cancelamento no fim do período (users); eventos recebidos da Stripe apenas com identificador, tipo, status e horários, sem conteúdo (stripe_events); resgates de códigos de provedores de hospedagem com conta, campanha e expiração (bundle_redemptions). Dados de cartão nunca chegam a nós. |
| Origem | O Cliente na finalização da compra da Stripe; eventos da Stripe. |
| Base legal | Art. 6(1)(b) do RGPD; para retenção para fins fiscais, (c). |
| Destinatários | Stripe Payments Europe Limited (Irlanda); Stripe, Inc. (EUA). Para partes do processamento de pagamentos, a Stripe atua sob sua própria responsabilidade; a distribuição exata dos papéis faz parte da revisão jurídica. |
| País terceiro | EUA pela Stripe, Inc.; base: Quadro de Privacidade de Dados ou cláusulas contratuais-padrão segundo os termos da Stripe. |
| Retenção | Campos de cobrança com a conta; uma assinatura em andamento é encerrada antes da exclusão da conta. Faturas e registros de cobrança segundo a legislação fiscal polonesa por cinco anos a partir do fim do ano em que venceu o prazo de pagamento do tributo; eles são mantidos na Stripe e podem ser obtidos no portal do cliente da Stripe. Eventos da Stripe e resgates de códigos não têm prazo de retenção (seção 6.4). |
| Medidas técnicas e organizacionais | Seção 8. Eventos da Stripe aceitos apenas com assinatura válida; cada evento é processado uma vez. |
B.27 Backups
| Campo | Informação |
|---|
| Finalidade | Recuperação após um erro: exclusão indevida, migração danificada. |
| Categorias de titulares de dados | Todas as pessoas cujos dados estejam no banco de dados. |
| Categorias de dados pessoais | Exportação completa e compactada do banco de dados da aplicação. Capturas de tela e arquivos de logotipo são mantidos fora do banco de dados e não fazem parte deste backup. As credenciais de contas de teste estão contidas nele apenas como texto cifrado (A.5). |
| Procedimento | Todas as noites às 03:00, após a rotina de exclusão, para que o backup não leve o que os prazos de retenção acabaram de excluir. A exportação só é mantida após a conferência do seu conteúdo (código de saída, número de tabelas, linha final). Aos domingos, um teste de restauração carrega o backup mais recente em um banco de dados descartável e o compara tabela por tabela. Se algo falhar, há um sinal e um e-mail aos operadores. |
| Base legal | Art. 6(1)(f) do RGPD em conjunto com o Art. 32(1)(c). |
| Destinatários | Nenhum. |
| País terceiro | Nenhum. |
| Retenção | 14 dias; exportações mais antigas só são removidas após um novo backup bem-sucedido (cfg/backup_lib.php). Exclusões que ocorrem durante esse período só chegam ao backup quando ele expira; se dados forem restaurados de um backup, as solicitações de exclusão são aplicadas novamente depois. |
| Local | Atualmente, os backups são mantidos no mesmo local que o banco de dados e não são criptografados separadamente; uma cópia criptografada em um segundo local está planejada (seções 8.1 e 10). |
| Medidas técnicas e organizacionais | Seção 8. |
B.28 Registro de erros e alerta de erro
| Campo | Informação |
|---|
| Finalidade | Encontrar e corrigir erros antes que um Cliente os informe. Novos tipos de erros e ondas de erros são comunicados aos operadores, além de um resumo diário a partir das 08:00. |
| Categorias de titulares de dados | Usuários cuja solicitação causa um erro; indiretamente, pessoas cujos dados aparecem em uma mensagem de erro. |
| Categorias de dados pessoais | Nível, origem, mensagem, contexto como JSON, ID da conta da sessão, horário (error_logs). Tipos de erros: 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 de até 2.000 caracteres, primeira e última ocorrência, contagem (error_kinds). |
| Base legal | Art. 6(1)(f) do RGPD (segurança operacional, Art. 32). |
| Destinatários | Os operadores por e-mail pelo prestador de serviços de e-mail: para um novo tipo de erro, origem e texto bruto da mensagem de até 400 caracteres (sem limpeza), além do e-mail de resumo diário; para uma onda de erros, apenas o sinal do Telegram é enviado. O Telegram recebe apenas frases fixas sem variáveis (“Ocorreu um novo tipo de erro”, “Muitos erros em pouco tempo”). |
| País terceiro | Pelo prestador de serviços de e-mail. |
| Retenção | Registro de erros por 90 dias (à noite). Tipos de erros sem prazo de retenção (seção 10). O alerta de erro está ativado no sistema de produção e desativado no sistema de desenvolvimento. |
| Medidas técnicas e organizacionais | Seção 8. |
B.29 Sinais operacionais e monitoramento de status
| Campo | Informação |
|---|
| Finalidade | Perceber indisponibilidades: a cada cinco minutos, uma verificação dos componentes (página inicial, banco de dados, espaço em disco, sinal de atividade do verificador, acúmulo na fila), página de status, sinal em caso de falha e de normalização, sinal de atividade para um serviço externo de monitoramento para que mesmo uma indisponibilidade completa seja percebida; acúmulo de tarefas antes do verificador. |
| Categorias de titulares de 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 atividade do verificador (scanner_heartbeat), indicadores diários sem referência pessoal (daily_stats). Os sinais ao Telegram são frases fixas sem variáveis; o sinal de atividade é uma solicitação sem conteúdo. |
| Base legal | Não se aplica, pois não há dados pessoais; por precaução, Art. 6(1)(f). |
| Destinatários | Telegram (frases fixas); o serviço externo de monitoramento (apenas a solicitação); os operadores por e-mail. |
| País terceiro | Telegram fora da UE; nenhum dado pessoal é transmitido. |
| Retenção | Linhas de status por 400 dias (à noite). |
| Medidas técnicas e organizacionais | Seção 8. |
B.30 Opt-out – exclusão de um domínio
| Campo | Informação |
|---|
| Finalidade | Qualquer pessoa pode excluir permanentemente qualquer domínio das verificações sem comprovação; o bloqueio produz efeito imediatamente para todas as formas de verificação (verificação gratuita, plugin sem uma conta, estudo, verificação de potencial cliente, ferramenta de cabeçalhos) e também para domínios de Clientes pagantes com comprovação de controle; o monitoramento em andamento termina na próxima verificação programada. Aplica-se ao domínio e à sua variante www, não a outros subdomínios. Só pode ser revogado por nós, mediante solicitação e comprovação. Para que o abuso (como um concorrente bloqueando domínios de outras pessoas) possa ser detectado e revertido, o bloqueio é registrado. |
| Categorias de titulares de dados | Pessoas que excluem um domínio. |
| Categorias de dados pessoais | Domínio, motivo voluntário de até 250 caracteres, origem, endereço IP, país, identificador do navegador, horário; na revogação, horário, pessoa que revoga o bloqueio e motivo (blocklist). Registro de solicitações como em B.4. |
| Base legal | Para a exclusão, Art. 6(1)(f) do RGPD. Interesse: dar efeito, permanentemente e em todas as formas de verificação, à vontade de que um domínio não seja verificado. Quando a própria pessoa que exclui é um titular de dados, a exclusão também dá efeito à sua oposição nos termos do Art. 21 (Art. 6(1)(c)). Para endereço, país e identificador do navegador, (f) (detecção de abuso). |
| Destinatários | Google (reCAPTCHA, B.23). |
| País terceiro | EUA pelo reCAPTCHA. |
| Retenção | Endereço IP, país e identificador do navegador após 12 meses (rotina noturna de exclusão, parte “optout_ip”). A exclusão em si permanece permanentemente para produzir efeito. |
| Medidas técnicas e organizacionais | Seção 8. Muitos bloqueios de um país em pouco tempo geram uma anomalia (B.4). |
B.31 Lembrete após o cadastro
| Campo | Informação |
|---|
| Finalidade | Um único e-mail de dois a 14 dias após o cadastro para contas confirmadas sem domínio confirmado: “Adicionar site” ou “Confirmar domínio”. Sem oferta, sem preço, sem mudança para um plano superior; com a nota de que não será enviado novamente. Em dias úteis, das 09:00 às 18:00, no máximo 50 por execução. |
| Categorias de titulares de dados | Novos titulares de contas. |
| Categorias de dados pessoais | Endereço de e-mail, idioma, horário de envio (campo “lembrete enviado” em users), domínio e status de confirmação. |
| Base legal | Art. 6(1)(b) do RGPD (nota sobre a configuração da própria conta). Se o e-mail conta como comunicação sobre a relação contratual ou como informação comercial que exigiria consentimento (Art. 10 da UŚUDE, a Lei polonesa sobre a Prestação de Serviços por Meios Eletrônicos (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 da PKE; § 7 da UWG) é uma questão pendente para a revisão jurídica; o operador pode desativá-lo centralmente. |
| Destinatários | Prestador de serviços de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| País terceiro | Pelo prestador de serviços de e-mail. |
| Retenção | O horário permanece enquanto a conta existir; o e-mail, por 30 dias na caixa de saída. |
| Medidas técnicas e organizacionais | Seção 8. O horário é definido antes do envio, para que uma interrupção não acione um segundo e-mail. |
B.32 Bot do Telegram para alertas de Clientes
| Campo | Informação |
|---|
| Finalidade | Um chat do Telegram é vinculado como destino de alerta: o Cliente recebe um link para nosso bot com um código de uso único; quando o destinatário pressiona “Iniciar”, nosso servidor lê o código nas novas mensagens para o bot e armazena o ID do chat. Para isso, não é necessário um endpoint aberto do nosso lado (webhook). |
| Categorias de titulares de dados | Clientes e as pessoas cujos chats do Telegram são vinculados. |
| Categorias de dados pessoais | Código de uso único, domínio, conta que o criou, eventos, modo de entrega, ID do chat, horários (telegram_links); o ID do chat como destino (alerts). O Telegram fornece outros dados de perfil com a mensagem; apenas o código e o ID do chat são avaliados e armazenados. |
| Base legal | Art. 6(1)(b) do RGPD; para terceiros como 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). A base e a informação aos titulares são questões pendentes para a revisão jurídica. |
| Retenção | Um código é válido por 30 minutos; as linhas de vínculo são excluídas após um dia quando um novo código é criado, e os códigos pendentes com a conta e o domínio. O ID do chat como destino até a exclusão do destino de alerta ou do domínio. |
| Medidas técnicas e organizacionais | Seção 8. |
B.33 Programa de parceiros e códigos de liberação
| Campo | Informação |
|---|
| Finalidade | Uma conta pode indicar novos Clientes por um código de indicação e recebe uma comissão sobre suas faturas pagas por um número limitado de meses. O código é transmitido no endereço até o cadastro; nenhum cookie é definido. Provedores de hospedagem e parceiros podem emitir códigos que liberam um plano por um período sem pagamento; uma semana antes do fim, o Cliente recebe um lembrete. |
| Status | O programa de parceiros fica desativado por padrão até que os Termos para Parceiros estejam estabelecidos. |
| Categorias de titulares de dados | Parceiros e Clientes indicados. |
| Categorias de dados pessoais | Código de indicação, parceiro que indica e horário da indicação (em users); comissão com parceiro, Cliente, ID da fatura da Stripe, valor, moeda, comissão, status, horários (partner_commissions). Liberação com plano, fim, origem, lembrete (em users); campanhas e resgates (bundle_campaigns, bundle_redemptions). |
| Base legal | Art. 6(1)(b) do RGPD (acordo de parceria); para o Cliente, (f) (liquidação da comissão, sem transmitir os dados do Cliente ao parceiro além do valor da comissão); registros fiscais, (c). |
| Destinatários | O parceiro vê suas comissões. |
| País terceiro | Nenhum. |
| Retenção | Indicação e liberação com a conta. Comissões e resgates não têm prazo de retenção no código; como registros contábeis, as comissões estão sujeitas à retenção para fins fiscais (seção 6.4). |
| Medidas técnicas e organizacionais | Seção 8. |
B.34 Canal de comunicação de vulnerabilidades
| Campo | Informação |
|---|
| Finalidade | Receber comunicações de vulnerabilidades em formexposed, segundo as regras da página Segurança e de /.well-known/security.txt. |
| Categorias de titulares de dados | Pessoas que fazem comunicações; pessoas cujos dados uma comunicação contém como evidência. |
| Categorias de dados pessoais | Endereço de e-mail, nome, conteúdo da comunicação e anexos, conforme enviados pela pessoa que comunica. A comunicação chega a nós por e-mail no endereço ali indicado; a aplicação não a armazena. |
| Base legal | Art. 6(1)(f) do RGPD (segurança do serviço, Art. 32); quando uma comunicação contiver dados pessoais de terceiros como evidência, também (f), com o objetivo de corrigir a vulnerabilidade. |
| Destinatários | Prestador de serviços de e-mail e, até a configuração da caixa de e-mail, o encaminhamento do domínio na Namecheap (seção 4). |
| País terceiro | Pelo prestador de serviços de e-mail e, até a mudança, pelo encaminhamento. |
| Retenção | Nenhum prazo de retenção foi definido ou é aplicado tecnicamente (seção 10). O operador ainda precisa definir o prazo; uma abordagem evidente seria excluir as evidências de terceiros assim que a vulnerabilidade for corrigida e tratar a correspondência como consultas de suporte. |
| Medidas técnicas e organizacionais | Seção 8. |
B.35 Feedback sobre um relatório
| Campo | Informação |
|---|
| Finalidade | Receber feedback abaixo de um relatório (“Há algo errado neste relatório?”) para encontrar erros na detecção de formulários. O superadministrador o classifica (novo, confirmado, corrigido, rejeitado) e pode baixar os dados da verificação do relatório como caso de teste (formulários com campos, motivos e constatações, sem capturas de tela e sem textos enviados ativamente). |
| Categorias de titulares de dados | Pessoas que visualizam um relatório, conectadas ou não. |
| Categorias de dados pessoais | Categoria e verificação de listas fixas, endereço de página de até 500 caracteres, texto de até 1.000 caracteres, idioma, horário, identificador do relatório, verificação, host; identificador da conta se conectado; HMAC-SHA256 do endereço IP com uma chave secreta para o limite; status, pessoa que trata, horário do tratamento (report_feedback). Registro de atividades: alterações de status e downloads de um caso de teste. Sem endereço de e-mail, sem endereço IP em texto simples. |
| Base legal | Art. 6(1)(f) do RGPD (encontrar e corrigir erros de detecção; limite contra abuso). |
| Destinatários | Nenhum. |
| País terceiro | Nenhum. |
| Retenção | 24 meses (rotina noturna de exclusão, parte “report_feedback”); a soma de verificação do endereço IP é apagada após 2 dias (parte “report_feedback_ip”); imediatamente quando uma conta é excluída. Os casos de teste baixados não contêm dados sobre a pessoa que informou. |
| Medidas técnicas e organizacionais | Seção 8. Proteção própria de formulários (armadilha, tempo assinado, CSRF), no máximo 5 relatos por hora e 20 por dia por soma de verificação, 10 por relatório; leitura apenas por superadministradores. |
6. Retenção – o que a rotina noturna de exclusão abrange e o que não abrange
Há exclusão automática, e ela tem um local de execução. Uma rotina de status (srv/cron_status.php) é iniciada a cada cinco minutos pelo crontab do servidor web, tanto no sistema de produção quanto no de desenvolvimento. Ela verifica os componentes, obtém os e-mails da verificação de entrega, programa verificações e envia alertas. Uma vez por dia, na janela das 03:00 às 03:04, exclui conforme os prazos de retenção e depois cria o backup. Desde 27 de setembro de 2026, também chama a rotina de retenção em cfg/fristen_lib.php (fe_fristen_lauf()), cujas partes são executadas de forma independente: se uma falhar, as outras continuam, e o erro é registrado no registro de erros.
Evidência de que a rotina está sendo executada: o status de backup do sistema de desenvolvimento mostra um backup bem-sucedido às 03:00 de 11 de outubro de 2026; o backup é criado no mesmo bloco, imediatamente após a exclusão. A rotina grava um registro por tabela excluída apenas na saída padrão, que o crontab descarta; não há um registro permanente do que foi excluído e quando (seção 10).
Os prazos de retenção que aparecem como marcadores são definidos na área administrativa nas configurações de retenção. A rotina lê as mesmas configurações; portanto, os textos sempre mostram o prazo após o qual os dados são efetivamente excluídos.
6.1 Abrangido pela rotina diária
| Dados | Prazo de retenção e acionamento | Local no código |
|---|
Registro de visualizações de páginas (access_logs) | 60 dias | srv/cron_status.php |
Registro de atividades (audit_logs) | 365 dias | srv/cron_status.php |
Registro de erros (error_logs) | 90 dias | srv/cron_status.php |
Caixa de saída (mail_outbox) | 30 dias | srv/cron_status.php |
Tokens de “Manter conectado” (remember_tokens) | após a expiração (30 dias) | srv/cron_status.php |
Convites não aceitos (workspace_invites) | após a expiração (14 dias) | srv/cron_status.php |
Tentativas de login (login_attempts); contadores de tentativas (auth_attempt_buckets) | 7 dias; contadores quando sua janela de tempo expira (atualmente 15 minutos, uma hora para redefinição de senha e cadastro), também no próximo acesso | srv/cron_status.php |
Registro de solicitações de verificações sem uma conta (check_throttle) | 7 dias | srv/cron_status.php |
Códigos de uso único para conectar o plugin (plugin_connect_tokens) | 1 dia após a expiração | srv/cron_status.php |
Anomalias resolvidas (abuse_flags) | 90 dias após a resolução | srv/cron_status.php |
| Relatórios expirados junto com resultado da verificação, formulários, constatações, imagens e tarefa (apenas sem um domínio em uma conta) | anônimos, 30 dias; potenciais clientes, 90 dias | fe_reports_aufraeumen() |
Registro de entrega de alertas (alert_log) | 90 dias | fe_alert_log_aufraeumen() |
Linhas de status (system_status_logs) | 400 dias | srv/cron_status.php |
Registros de concordância de contas excluídas (legal_consents) | quando a conta tiver sido excluída e a concordância completar 4 anos | srv/cron_status.php |
| Órfãos de domínios excluídos: resultados de verificações, tarefas, dados de alertas, incidentes, códigos do Telegram, entregas, verificações de disponibilidade, vulnerabilidades, comprovações, inventário de scripts e alterações de scripts | imediatamente na próxima execução | fe_fristen_lauf(), partes “orphan_scans”, “orphan_rows” |
| Dados de plugin de hosts sem um domínio; linha de plugin sem uma conta | imediatamente; linha após 90 dias sem contato | parte “orphan_hosts” |
Resultados da ferramenta de cabeçalhos (header_checks) | atualmente 90 dias | parte “header_checks” |
| Resultados de verificações de um domínio com formulários, constatações, imagens, relatórios, tarefas | 13 meses; o último concluído por domínio permanece | parte “old_scans” |
Execuções no 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), números diários do plugin e notificações de alterações (plugin_stats, plugin_changes) | 13 meses | partes “form_metrics”, “plugin_stats” |
Dispositivos conectados (login_sessions) | 90 dias após o último uso ou a revogação | parte “sessions” |
| Convites aceitos | 30 dias após a aceitação | parte “invites” |
Solicitações de suporte (support_requests) | 24 meses | parte “support” |
Feedback sobre relatórios (report_feedback) | 24 meses; soma de verificação do endereço IP, 2 dias | partes “report_feedback” e “report_feedback_ip” |
Versões PDF de relatórios no cache (var/pdf) | 7 dias | parte “pdf_cache” |
Endereço IP, país e identificador do navegador no opt-out (blocklist) | 12 meses; a exclusão permanece | parte “optout_ip” |
Assinantes do portal (client_subscribers) | não confirmados, 30 dias; com assinatura cancelada, 3 anos | parte “subscribers” |
| Contas nunca confirmadas, junto com o espaço de trabalho | 30 dias sem login, salvo se outro membro estiver vinculado | parte “pending_accounts” |
| Chaves de API sem uma conta (dados legados) | imediatamente | parte “api_keys” |
6.2 Fora da janela das 03:00
| Dados | Prazo de retenção e acionamento | Local no código |
|---|
| Cópias na caixa de e-mail de controle da verificação de entrega | após o processamento, a cada cinco minutos | fe_zustellung_abholen() |
Associações da verificação de entrega (delivery_log) | 180 dias, em cada obtenção | fe_zustellung_abholen() |
Texto cifrado de contas de teste em tarefas (scan_jobs) | após a execução, no máximo após uma hora | servidor de verificação; fe_login_aufraeumen() |
Incidentes (alert_incidents) com suas tentativas de entrega de escalonamentos | 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 de proteção coletiva (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 vínculo do Telegram (telegram_links) | 1 dia, quando um novo código é criado | cfg/kanal_lib.php |
Contadores de chamadas de API (api_usage) | 1 dia, ocasionalmente em uma chamada | cfg/agentur_lib.php |
Indisponibilidades resolvidas de provedores (provider_incidents), cache de vulnerabilidades (vuln_cache) | 90 e 30 dias, respectivamente; sem dados pessoais | cfg/anbieter_lib.php, cfg/luecken_lib.php |
| Dados brutos de estudos | na publicação | fe_studie_veroeffentlichen() |
| Backups | 14 dias, após um novo backup bem-sucedido | cfg/backup_lib.php |
| Registros do servidor web | 14 dias | rotação de registros do sistema |
6.3 Na exclusão pelo Cliente
- Excluir um domínio (
fe_domain_loeschen()): resultados de verificações com formulários, constatações e arquivos de imagem, relatórios, tarefas, destinos de alertas, registro de entrega, fila de resumos, incidentes, códigos do Telegram, entregas, verificações de disponibilidade, vulnerabilidades, registros de evidências, o domínio nos portais de clientes com seleção fixa; por chaves estrangeiras, formulários monitorados com execuções no navegador, observações e séries temporais, conta de teste, contadores de formulários; os dados de plugin do host, se nenhum outro domínio se referir a ele. O inventário e as alterações de scripts do domínio também são excluídos junto com ele; não têm prazo de retenção próprio (seções 6.4 e 10). Dados restantes sem domínio associado do período anterior a 27 de setembro de 2026 são apagados pela rotina noturna (partes “orphan_scans”, “orphan_rows”).
- Excluir um espaço de trabalho (
fe_arbeitsbereich_daten_loeschen()): adicionalmente, marca incluindo logotipo, portais de clientes incluindo assinantes, códigos de implantação, verificações de potenciais clientes; além de convites e participações de membros.
- Excluir uma conta: encerrar imediatamente uma assinatura paga em andamento na Stripe, sem reembolso; transferir ou excluir os espaços de trabalho próprios do titular; excluir participações, tokens de permanência de login, dispositivos, chaves de API com contadores, códigos pendentes do Telegram e a linha da conta.
- Excluir uma conta de teste (
fe_login_loeschen()): sobrescrever o texto cifrado, excluir a linha, limpar tarefas em espera.
6.4 O que a rotina não abrange
Esta lista é a mais importante. Ela indica dados para os quais não existe prazo automático de retenção ou que permanecem após uma exclusão.
| Dados | O que se aplica | Avaliação |
|---|
Dados da conta, incluindo último endereço IP (users) | até a exclusão pelo titular da conta; sem exclusão de contas inativas | dados contratuais; falta uma regra para contas permanentemente inativas sem assinatura |
| Registro de atividades, visualizações de páginas e registro de erros de uma conta excluída | permanecem com ID da conta e endereço IP até o fim do seu prazo de retenção | intencional (evidência de ações mesmo após a rescisão); o ID já não aponta para uma conta |
| Solicitações de suporte de uma conta excluída | permanecem por até 24 meses com o ID antigo da conta | intencional; o ID não é apagado |
| Registros de concordância de uma conta excluída | até que a concordância complete 4 anos (contados da concordância, não da exclusão da conta) | intencional (seção B.12) |
Anomalias não resolvidas com endereço IP (abuse_flags) | até que alguém as resolva | ponto pendente (seção 10) |
Tipos de erros com mensagem de exemplo inalterada (error_kinds) | sem prazo de retenção | ponto pendente (seção 10) |
Inventário de scripts e alterações de scripts (script_inventory, script_changes) | sem prazo de retenção próprio; mantidos enquanto o domínio existir e excluídos com ele | ponto pendente (seção 10) |
| Assinantes de portais de clientes revogados | até a exclusão do espaço de trabalho | ponto pendente (seção 10) |
| Chaves de API e códigos de implantação revogados | até a exclusão da conta ou do espaço de trabalho | apenas hashes, prefixo e rótulo; de menor importância |
Lista de hosts de estudos (study_domains), estudos nunca publicados | sem prazo de retenção | ponto pendente (seção 10) |
| Verificações internas sem um domínio e sem um relatório (resultados de verificações, formulários, constatações, capturas de tela) | sem prazo de retenção; nenhuma rotina de exclusão as abrange | ponto pendente (seção 10) |
| Comissões, resgates de códigos, eventos da Stripe | sem prazo de retenção | relevância contábil; prazo a definir segundo a legislação fiscal |
Idade do domínio em cache (domain_age_cache) | sem prazo de retenção | apenas nome do domínio e data de registro |
| Resultado da autenticação do e-mail de formulário com domínio do remetente | com o domínio; sobrescrito a cada recebimento | veja A.1 |
| Exclusões no opt-out | permanentes | intencional; sem permanência, nenhuma exclusão produz efeito |
| E-mails na caixa de e-mail do canal de comunicações e na caixa de e-mail geral | sem prazo técnico de retenção | ponto pendente (seção 10) |
6.5 Fora do banco de dados
- As capturas de tela são mantidas como arquivos fora do diretório web e excluídas com seu resultado de verificação (todas as formas de exclusão acima também excluem os arquivos).
- Os arquivos de logotipo da marca são excluídos quando substituídos e com o espaço de trabalho.
- No servidor de verificação, um diretório temporário com resultado e imagens é criado por tarefa; ele é excluído após cada execução, mesmo após um erro.
- Os backups são mantidos no servidor web (B.27).
- Os registros do servidor web com o endereço IP completo são mantidos por 14 dias (B.1).
7. Decisões automatizadas, definição de perfis e avaliação
formexposed avalia sites, não pessoas. Segundo nossa avaliação, o serviço não toma nenhuma decisão que produza efeitos jurídicos em relação a uma pessoa ou que a afete de maneira igualmente significativa (Art. 22(1) do RGPD). No entanto, há avaliações e bloqueios automáticos. Nós os listamos para que a classificação possa ser verificada.
| Mecanismo | O que faz | Quem afeta |
|---|
| Pontuação e conclusão de uma verificação | Soma ponderada das camadas de proteção ausentes (CAPTCHA, armadilha, token, verificação de tempo, CAPTCHA ineficaz, configuração exposta conhecida), de 0 a 100; a partir disso, “Exposto”, “Parcialmente protegido” ou “Protegido”. A conclusão do site segue o pior formulário de contato reconhecido como tal pelas regras (não pelo modelo de linguagem); sem formulário de contato, não há conclusão. Os pesos podem ser definidos na área administrativa. | Operadores de sites; para empresários individuais, indiretamente uma pessoa. A conclusão não tem consequência jurídica; é uma constatação com evidências e instruções. |
| Classificação do tipo de formulário | Primeiro as regras, um modelo de linguagem local apenas se as regras retornarem “desconhecido”. Decide se um envio de teste ativo é permitido (apenas para um formulário de contato reconhecido de forma confiável pelas regras). Formulários classificados pelo modelo de linguagem nunca são enviados e não contam para a pontuação nem para a conclusão. | O Cliente e os destinatários dos seus e-mails de formulário; efeito protetivo: na dúvida, nada é enviado. |
| Plano de ação priorizado em relatórios pagos | Um modelo de linguagem local resume constatações selecionadas com falha ou resultado incerto e metadados da verificação em etapas curtas e numeradas. Seu texto é identificado como resumo de IA; as constatações individuais continuam sendo a referência determinante. Ele não altera a pontuação, a conclusão ou a configuração do site. | O Cliente ou outro leitor autorizado do relatório, que decide quais etapas executar. |
| Selo | Mostra “Protegido” apenas sob condições fixas (B.18); caso contrário, é neutro. | Cliente; sem efeito sobre visitantes. |
| Limites e bloqueios para a verificação gratuita, ferramenta de cabeçalhos e opt-out | Rejeitam solicitações se os limites por endereço, sessão, domínio ou sistema forem atingidos, se o domínio for recente demais ou tiver idade desconhecida, ou se estiver na lista de bloqueio. | Solicitantes; efeito: um serviço gratuito é recusado por horas a dias. Um administrador pode liberar um endereço; consultas pela página de contato chegam a uma pessoa. |
| Anomalias | Padrões (muitos domínios de um endereço, rajadas de solicitações, muitas rejeições, muitos opt-outs de um país, limite diário atingido) são registrados e informados. Eles não bloqueiam por si só; os bloqueios decorrem dos limites. | Solicitantes. |
| Bloqueio de login | Após atualmente oito logins malsucedidos de um endereço em 15 minutos, os logins desse endereço são rejeitados temporariamente. Além disso, todas as tentativas de login, incluindo as bem-sucedidas, são contadas por conta e endereço IP (atualmente oito), por conta somando todos os endereços (consideravelmente mais, contra tentativas distribuídas de adivinhar senhas) e por endereço IP (atualmente 80) em 15 minutos, assim como os códigos de segundo fator (dez por conta em 15 minutos); além desses limites, as tentativas são rejeitadas. Portanto, tentativas malsucedidas a partir de outro endereço já não impedem o proprietário de acessar uma conta. Confirmações de senha (cinco por conta em 15 minutos), e-mails de redefinição (três por endereço por hora, com resposta inalterada), cadastros (dez por endereço IP por hora) e tentativas de senha 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 fazem login, se cadastram ou abrem um portal de clientes; efeito limitado no tempo, a redefinição de senha continua possível. |
| Limite do reCAPTCHA | Rejeita envios abaixo de uma pontuação do Google; limite por ponto de uso (atualmente 0,7 para verificação e opt-out). Respostas para outra ação e envios para os quais o Google não responde em três segundos também são rejeitados. | Pessoas que enviam nossos formulários; efeito: uma nova tentativa ou a via da página de contato. |
| Proteção coletiva | Coloca automaticamente um domínio de link em uma lista quando os limites mínimos são atingidos; as camadas de proteção dos sites conectados movem as mensagens com esses links para a quarentena. | Remetentes de mensagens para páginas de Clientes. Efeito: a mensagem é retida, não excluída, e pode ser liberada pelo operador do site. A decisão sobre a mensagem é tomada pelo plugin do operador no site do operador, não por nós. |
| Valores comparativos | “Mais bem protegido que X % dos sites verificados”, apenas a partir de totais de pelo menos 20 hosts. | Operadores de sites; sem efeito. |
O que mais se aproxima do Art. 22 é a camada de proteção do plugin nas páginas de Clientes, que retém envios automaticamente. É tratamento pelo operador do site no servidor do operador (A.10). Ela não exclui nada, mas move as mensagens para a quarentena, e o operador pode liberar qualquer mensagem. Não há definição de perfis de visitantes ali nem conosco; não existe identificador de visitante que vincule uma mensagem a outra.
8. Medidas técnicas e organizacionais (Art. 32) – descrição geral
Esta seção é a descrição geral nos termos do Art. 30(1)(g) e (2)(d) do RGPD. A versão detalhada está na página Medidas Técnicas e Organizacionais. Cada medida abaixo é comprovada no código ou na configuração. As medidas ainda não implementadas estão na mesma seção (8.1), para que a descrição esteja completa.
| Área | Medida em vigor |
|---|
| Criptografia de transporte | HTTPS para site, aplicação e interfaces; HSTS; cookies de sessão e de token de permanência de login apenas por HTTPS, HttpOnly, SameSite=Lax. |
| Controle de acesso (autenticação) | Senhas apenas como hash, novas senhas com pelo menos dez caracteres e no máximo 72 bytes; bloqueio de login após repetidas tentativas malsucedidas e limites de tentativas por conta e endereço IP juntos, por conta e por endereço IP, para que tentativas malsucedidas de outro endereço não impeçam o proprietário de acessar a conta; limites de tentativas também para confirmações de senha, redefinição de senha (com a mesma resposta e o mesmo tempo de resposta), cadastros e senhas de portais; login com dois fatores (TOTP) com segredo criptografado, proteção contra reutilização de códigos e códigos de recuperação como hash; novo identificador de sessão em cada login, identificadores não emitidos pelo servidor não são aceitos; “Manter conectado” não disponível para superadministradores, cada token válido apenas uma vez; alterar o endereço de e-mail invalida um link de redefinição pendente; dispositivos podem ser revogados individualmente ou todos de uma vez; a lista de dispositivos mantém apenas o hash do identificador de sessão. |
| Controle de acesso (autorização) | Papéis por espaço de trabalho (proprietário, administrador, leitor); permissões são conferidas em relação ao objeto, nunca a um identificador do formulário; conta de teste, “Fix it for me” e verificações ativas apenas para proprietários e administradores; “Visualizar como Cliente” limitado no tempo e bloqueado para ações que alterem a conta, seu encerramento desconecta completamente, retorno à área administrativa apenas com senha e segundo fator; convites válidos apenas enquanto a pessoa que convida for proprietário ou administrador; endereços de webhooks e canais de chat mostrados a leitores reduzidos apenas ao host; o nome de host de um domínio verificado não pode ser alterado. |
| Segurança da aplicação | Tokens CSRF; instruções preparadas de banco de dados; nossa própria proteção de formulários (armadilha, verificação de tempo assinada); reCAPTCHA nos formulários públicos; limitação de frequência para suporte, verificações e interfaces; apenas uma chamada de “Fix it for me” por espaço de trabalho de cada vez, para que a cota também seja respeitada em solicitações simultâneas; Política de Segurança de Conteúdo com proteção contra incorporação em frames que permite executar apenas scripts com a autorização (nonce) da respectiva resposta; endereço IP de cabeçalhos encaminhados apenas do nosso próprio proxy e apenas da entrada que ele acrescentou; tokens de acesso mascarados no registro de visualizações de páginas. |
| Segredos | Chaves de API, códigos de implantação, segredos de conexão de plugins, códigos de uso único e senhas de portais apenas como hash; credenciais de contas de teste criptografadas assimetricamente, chave privada apenas no servidor de verificação; webhooks assinados; eventos da Stripe apenas com assinatura válida. |
| Minimização de dados | A verificação de entrega não armazena conteúdo nem endereços completos de remetentes; endereços de destinatários em formulários apenas como domínio; IDs de contas em endereços de scripts são substituídos; números de plugins apenas de listas fixas; textos de erros de envio de e-mail apenas como categoria; sinais do Telegram sem variáveis; imagens das verificações no navegador com valores inseridos mascarados; sem capturas de tela em áreas protegidas por login. |
| Isolamento do verificador | Cada verificação em seu próprio contêiner: todas as capacidades Linux removidas, sem elevação de privilégios, sistema de arquivos somente de leitura, limites de memória e processos, rede própria; conferência do destino em relação a redes privadas e locais antes da aceitação e no verificador, também após redirecionamentos; service workers bloqueados, conexões WebSocket fechadas. Solicitações pelo servidor web (comprovação de controle, ferramenta de cabeçalhos, busca de arquivos, disponibilidade, RDAP, certificados, webhooks e alertas de chat) apenas nas portas web habituais e apenas para o endereço exato conferido, webhooks e alertas de chat apenas por HTTPS. |
| Armazenamento | Capturas de tela fora do diretório web, acessíveis apenas pelo relatório; relatórios em endereços aleatórios com noindex; diretório de backups legível apenas pelo serviço. |
| Disponibilidade e recuperação | Backup noturno com conferência do conteúdo, teste semanal de restauração, alerta em caso de falha; verificação de componentes a cada cinco minutos com sinal e e-mail; sinal externo de atividade; parada de emergência para verificações anônimas; contrapressão quando há acúmulo de tarefas. |
| Rastreabilidade | Registro de atividades para logins, alterações, exclusões, acesso do suporte e aprovações; registro de erros com alerta. |
| Exclusão | Prazos de retenção em um único local no código, a partir das mesmas configurações que os textos (seção 6); cadeias de exclusão para domínio, espaço de trabalho e conta, com as exceções da seção 6.4. |
| Direitos dos titulares de dados | Exportação de todos os dados da conta como arquivo com um clique, baseada em uma lista de campos permitidos, sem segredos. |
| Organização | Área administrativa apenas para contas com direitos de superadministrador, bloqueada durante “Visualizar como Cliente”; sistemas de desenvolvimento e produção separados, o sistema de desenvolvimento protegido por uma barreira adicional de acesso; transferência de textos legais após aprovação por uma ferramenta que recusa rascunhos e marcadores. |
8.1 Medidas ainda não implementadas
- Sem criptografia do banco de dados em repouso (medido em 11 de outubro de 2026). As exceções são as credenciais de contas de teste e o segredo de dois fatores, que são criptografados no nível do campo.
- Conexões internas não integralmente criptografadas. As conexões dentro da nossa rede interna não são integralmente criptografadas. As credenciais de contas de teste trafegam ali apenas como texto cifrado.
- Sem backup em um segundo local. Atualmente, os backups são mantidos no mesmo local que o banco de dados e não são criptografados separadamente; uma cópia criptografada em um segundo local está planejada. Até lá, protegem contra um comando de exclusão incorreto, não contra a perda do local.
- Reforço da segurança da administração dos servidores incompleto. A segurança do acesso administrativo aos nossos servidores ainda não atende ao padrão que pretendemos para a operação; o reforço está em andamento. Não publicamos detalhes, pois ajudariam um invasor; nós os fornecemos a uma autoridade de controle mediante solicitação.
- Sem registro funcional de leituras na área administrativa. Ações de escrita são registradas no registro de atividades; quem apenas visualizou qual solicitação de suporte ou qual relatório só pode ser determinado pelo registro de visualizações de páginas (60 dias).
- Sem registro permanente de exclusões. O que a rotina noturna excluiu não é registrado (seção 6).
- Sem segundo ponto de verificação independente. A sonda em um 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: Segundo nossa avaliação, não há obrigação de designar um. A avaliação faz parte da revisão jurídica e será repetida assim que qualquer uma das circunstâncias listadas abaixo mudar.
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 monitoramento regular e sistemático de titulares de dados em larga escala): nossa atividade principal é a verificação regular e sistemática de sites e formulários, não a observação de pessoas. Não criamos perfis de visitantes, não usamos rastreamento e não vinculamos uma mensagem a outra. A verificação de entrega (A.1) faz mensagens reais de visitantes passarem pela nossa caixa de e-mail, mas avalia apenas os cabeçalhos e os primeiros 8 KB para associação e não armazena conteúdo; observa rotas de entrega, não pessoas. Contas de clientes e registros são acessórios à atividade empresarial.
- Alínea (c) (tratamento em larga escala de categorias especiais nos termos do Art. 9 ou de dados relativos a infrações penais nos termos do Art. 10 como atividade principal): não atendida. Categorias especiais podem ocorrer incidentalmente em cópias de e-mails de formulário (A.1), em páginas protegidas por login (A.5) ou no código colado (A.7); a captura incidental não é uma atividade principal.
O Art. 37(4) permite que a legislação nacional acrescente outros casos. Estamos solicitando a um advogado a confirmação de se a legislação polonesa exige que designemos um.
Fatores que levam a uma nova avaliação: ativação da proteção coletiva com redes IP; uma função que reconheça visitantes em várias mensagens ou sites; armazenamento de conteúdo da verificação de entrega; um Cliente cujos formulários tratem predominantemente de categorias especiais (saúde, candidaturas a emprego) com a verificação de entrega ativada em larga escala; o primeiro empregado com acesso a dados de clientes. Uma designação voluntária continua possível; nesse caso, os Art. 37 a 39 aplicam-se integralmente.
Separadamente: a página Avaliação de Impacto sobre a Proteção de Dados responde se uma avaliação de impacto sobre a proteção de dados nos termos do Art. 35 é necessária para atividades de tratamento individuais. Sua avaliação dos critérios de obrigatoriedade conclui que uma avaliação de impacto é necessária para a proteção coletiva (B.21) e para estudos na escala pretendida (B.7) e é realizada por nós, e que para a verificação de entrega (A.1) é necessária na configuração típica, como obrigação do Cliente, a quem damos suporte nisso.
10. Pontos pendentes e medidas planejadas
Os pontos a seguir são comprovados no código, no esquema ou na configuração, não presumidos. Descrevem a situação na data desta versão; a classificação é nossa e não antecipa qualquer avaliação jurídica. Estão ordenados pelo seu peso para os titulares de dados, não pela facilidade de correção. As medidas planejadas e sua prioridade estão descritas na Avaliação de Impacto sobre a Proteção de Dados.
| Ponto pendente | O que é comprovado | Relevância |
|---|
| Prestador de serviços de e-mail sem contrato documentado | Para Namecheap, Inc. (Private Email), Phoenix, Arizona, USA, o contrato, os locais de tratamento e a base de transferência não estão documentados. E-mails de contas, alertas e a caixa de e-mail de controle com mensagens reais de visitantes passam por esse provedor. | 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 planejadas antes do lançamento. |
| Bases para serviços de chat e reCAPTCHA pendentes | Alertas ao Telegram (sem decisão de adequação), Slack, Discord, Microsoft Teams e Google Chat; reCAPTCHA sem solicitação de consentimento. | Questões pendentes para a revisão jurídica; até lá, a informação aos titulares e a base não são definitivas. |
| A caixa de e-mail de controle pode manter mensagens durante interrupções | A exclusão ocorre após o processamento bem-sucedido; se a obtenção falhar, as cópias permanecem até a próxima execução bem-sucedida. Não há aviso quando se acumula um atraso na caixa de e-mail por um período mais longo. | As cópias contêm consultas reais de visitantes. |
| Sem backup em um segundo local, sem criptografia do banco de dados em repouso | Seção 8.1. Uma cópia criptografada do backup em um segundo local está planejada. | Um único evento no local afetaria dados e backup ao mesmo tempo; um meio de armazenamento roubado seria legível. |
| Anomalias não resolvidas sem prazo de retenção | Anomalias com o endereço IP completo como chave só são excluídas 90 dias após a resolução; o que nunca é resolvido permanece. | Relaciona-se ao princípio da limitação do armazenamento (Art. 5(1)(e)); a exclusão depende de resolução manual. Um prazo fixo de retenção está planejado (medidas da Avaliação de Impacto sobre a Proteção de Dados). |
| Tipos de erros com mensagem de exemplo sem prazo de retenção | A mensagem de exemplo é armazenada inalterada com até 2.000 caracteres; o padrão sanitizado remove endereços e números, o exemplo não. | Mensagens de erro podem conter endereços de e-mail, nomes de hosts ou endereços IP. |
| Inventário de scripts sem prazo de retenção próprio | O inventário e as alterações de scripts são excluídos com o domínio (FE_DOMAIN_TABELLEN), inclusive quando o espaço de trabalho ou a conta é excluído e na rotina noturna para órfãos; não têm prazo de retenção próprio. Contêm endereços de scripts, endereços de páginas e, para aprovações, a pessoa que aprova e um motivo em texto livre. | Relaciona-se ao princípio da limitação do armazenamento (Art. 5(1)(e)); o histórico de alterações com as aprovações continua crescendo enquanto o domínio existir. |
| Assinantes de portais revogados | Um portal revogado é bloqueado, não excluído; seus assinantes permanecem até a exclusão do espaço de trabalho. | A finalidade (envio do relatório) cessou com a revogação. |
| Listas de estudos sem prazo de retenção | Após a publicação, hosts e segmentos permanecem; estudos nunca publicados também mantêm seus dados brutos. | A promessa “os dados brutos são excluídos” aplica-se apenas a estudos publicados. |
| Verificações internas sem forma de exclusão | Verificações com nível de confiança “internal” que não tenham domínio nem relatório (estudos e verificações criados pelo operador pela linha de comando) não são abrangidas por nenhuma rotina de exclusão; com elas permanecem formulários, constatações e capturas de tela de sites de terceiros. | Relaciona-se ao princípio da limitação do armazenamento (Art. 5(1)(e)); afeta pessoas que nada sabem sobre a verificação. Avaliado como alto risco na Avaliação de Impacto sobre a Proteção de Dados. |
| A comprovação de controle não é renovada | A comprovação de controle é conferida uma vez; não há um caminho no código pelo qual um domínio a perca novamente. | Envios de teste ativos, busca de arquivos e verificação de áreas protegidas por login continuam após uma mudança de proprietário ou de mandato. |
| Verificação de áreas protegidas por login: transporte até a página do Cliente | Como endereço de login, http é permitido junto com https, e erros de certificado na página do Cliente não interrompem o login. | Credenciais de contas de teste poderiam ser interceptadas no trajeto até a página do Cliente. |
| A exclusão depende de uma janela de tempo | O bloco diário só é executado se uma rotina de status começar entre 03:00 e 03:04. Se essa execução falhar (banco de dados inacessível, servidor reiniciado), a exclusão e o backup desse dia não ocorrem; não há recuperação da execução perdida. O que foi excluído não é registrado permanentemente. | Os prazos de retenção são então prolongados silenciosamente por um dia. Uma janela perdida não aciona alerta; apenas um backup que é executado e falha é informado. A lista de configuração na área administrativa mostra a data do último backup bem-sucedido. |
| Algumas exclusões dependem do monitoramento | O esvaziamento da caixa de e-mail de controle da verificação de entrega, a exclusão de incidentes, notificações de resumo enviadas, sinais de proteção coletiva e verificações de potenciais clientes, e a limpeza de cópias restantes de contas de teste em tarefas ocorrem na parte de agendamento da rotina de status, que funciona apenas enquanto o monitoramento estiver ativado na área administrativa; as associações da verificação de entrega só são excluídas enquanto uma caixa de e-mail de controle estiver configurada. | Se o monitoramento for desativado centralmente ou a caixa de e-mail for removida, a aplicação desses prazos de retenção para sem que ninguém perceba. |
| Canal de comunicações e caixas de e-mail sem prazo de retenção | Comunicações de vulnerabilidades e outros e-mails recebidos são mantidos fora da aplicação; nenhum prazo de retenção foi definido. | As comunicações podem conter evidências de terceiros. |
| Valores de campos ocultos são lidos durante a verificação | O verificador lê o valor de campos ocultos do formulário até 24 caracteres e atributos de dados até 60 caracteres para reconhecer registros de tempo e tokens. Apenas nome, tipo, rótulo do campo e resultado do reconhecimento vão para o mapa de campos e as constatações, não o valor. | Não há lacuna de armazenamento; o valor é mantido apenas na memória de trabalho do contêiner de verificação durante a verificação. Um valor preenchido previamente (como um número de cliente) é lido no processo, mas não armazenado. |
| Domínio do remetente derivado no resultado da autenticação | A.1. | Para domínios pessoais de visitantes, dados pessoais originados de uma mensagem real. |
| Reforço da segurança da administração dos servidores incompleto; conexões internas não integralmente criptografadas | Seção 8.1. O reforço está em andamento; não divulgamos detalhes publicamente. | Um incidente de segurança no nível do servidor afetaria aplicação, banco de dados e backups ao mesmo tempo. |
| Medição no sistema de desenvolvimento | Esquema, código e configurações foram medidos no sistema de desenvolvimento. | Código e esquema correspondem ao sistema de produção; configurações podem diferir e precisam ser conferidas novamente lá antes do lançamento. |
11. Manutenção deste registro
O Art. 30 exige que o registro seja mantido por escrito e disponibilizado à autoridade de controle mediante solicitação. Isso exige alguém responsável por ele e um intervalo em que seja conferido em relação ao sistema, e não em relação à sua versão anterior.
- Responsabilidade: Lukas Wójcik, proprietário. A revisão ocorre anualmente e sempre que uma atividade de tratamento muda.
- Eventos que exigem atualização: um suboperador novo ou alterado, em particular a escolha do prestador de serviços de e-mail; uma nova tabela ou um novo campo com dados pessoais; uma alteração nos prazos de retenção ou nas cadeias de exclusão em
cfg/fristen_lib.php ou srv/cron_status.php; um novo canal de alerta ou uma nova solicitação a um terceiro; ativação de uma função desativada por padrão (proteção coletiva com redes IP, sonda, domínios próprios, programa de parceiros, pagamento mediante fatura, Spamhaus ou Google Web Risk); uma migração para outros servidores.
- Procedimento: cada afirmação aqui vem de código, esquema ou medição. Uma revisão que apenas lê o texto não revisou nada: esquema e cadeias de exclusão são medidos novamente, marcadores continuam sendo marcadores, pontos pendentes são resolvidos ou mantidos com justificativa.
- Relação com outros documentos: este registro não substitui a Política de Privacidade, o Acordo de Tratamento de Dados, as Medidas Técnicas e Organizacionais ou a lista de Suboperadores. Onde divergirem deste registro, a diferença é uma constatação.
- As alterações neste documento são listadas na página Alterações nos Documentos Contratuais.
English 
Deutsch 
Polski 
Български 
Čeština 
Dansk 
Ελληνικά 
Español 
Eesti 
Suomi 
Français 
Gaeilge 
Hrvatski 
Magyar 
Italiano 
Lietuvių 
Latviešu 
Malti 
Nederlands 
Português 
Română 
Slovenčina 
Slovenščina 
Svenska 
العربية 
हिन्दी 
Bahasa Indonesia 
日本語 
한국어 
Русский 
简体中文 
Norsk (bokmål) 
Português (Brasil) 
Türkçe 
Українська 
Español (México) 
Tiếng Việt 
ไทย 
Íslenska 
עברית 
Bahasa Melayu 
Srpski (latinica)