Medidas Técnicas e Organizacionais

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.1 · Última atualização: 22 de outubro de 2026

Medidas nos termos do Art. 32 do RGPD com as quais LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polônia, protege o serviço formexposed. Esta página faz parte do Acordo de Tratamento de Dados como Anexo 2.

1. Escopo e princípio

As medidas aplicam-se a todos os dados tratados pelo serviço: aos dados que tratamos em nome dos nossos Clientes (descritos no Acordo de Tratamento de Dados) e aos dados pelos quais nós mesmos somos o controlador, como contas de clientes e registros. Não há níveis de proteção separados para os dois; o que protege a conta também protege os dados tratados como operador.

Estrutura nos termos do Art. 32(1) do RGPD. Pseudonimização e criptografia (alínea (a)) são abordadas na seção 4; a confidencialidade, integridade, disponibilidade e resiliência contínuas dos sistemas (alínea (b)), nas seções 3, 5, 6 e 7; a capacidade de restaurar a disponibilidade em tempo hábil após um incidente (alínea (c)), na seção 7.1; o processo para testar, apreciar e avaliar regularmente a eficácia (alínea (d)), na seção 9. Selecionamos as medidas com base nos riscos descritos na nossa Avaliação de Impacto sobre a Proteção de Dados, levando em conta o estado da técnica e os custos de implementação.

Princípio: comprovado, não apenas pretendido. Aqui é indicado apenas o que foi efetivamente implementado no código ou na operação. O que está planejado, mas ainda não implementado, é expressamente listado como “planejado” na seção 10. Uma medida que não aparece aqui não está tacitamente em vigor.

Nomes de máquinas, endereços internos, portas, nomes de usuários e versões de software deliberadamente não são indicados. Eles não ajudam ninguém a avaliar as medidas, mas ajudam quem quiser contorná-las. Quem precisar deles para uma auditoria nos termos do Acordo de Tratamento de Dados os receberá durante essa auditoria sob confidencialidade, na medida em que forem necessários para ela.

2. Estrutura do serviço

O serviço é executado em dois servidores próprios do prestador na Polônia, localizados na mesma rede interna:

Servidor web com banco de dados. Ele fornece a aplicação, mantém o banco de dados, envia notificações e faz backups dos dados. Somente ele está configurado para aceitar solicitações da internet.
Servidor de verificação. Ele realiza as verificações de sites de terceiros e próprios em um navegador e executa o modelo de linguagem que classifica formulários individuais, resume as constatações das verificações em planos de ação priorizados para contas pagas e acrescenta código em “Fix it for me”. Não está configurado para aceitar solicitações da internet, mas obtém suas tarefas por conta própria do servidor web e devolve os resultados a ele.

Nenhum provedor de hospedagem, data center ou nuvem está envolvido na operação, e nada vai para um serviço externo de IA. Quais terceiros recebem dados está descrito na página Suboperadores.

3. Confidencialidade

3.1 Controle de acesso físico

Os servidores estão localizados em instalações do prestador na Polônia que não são abertas ao público. Somente o proprietário tem acesso (conforme declarado pelo operador). O endereço exato do local deliberadamente não é informado aqui.

3.2 Controle de acesso: login no serviço

Senhas são armazenadas apenas como hash usando o método-padrão do PHP (bcrypt). Se o método-padrão mudar, o hash será renovado no próximo login. Para uma tentativa de login com um endereço desconhecido, o servidor ainda calcula um hash, para que o tempo de resposta não revele se existe uma conta. Da mesma forma, a resposta a uma solicitação de redefinição de senha não revela, nem pela redação nem pela duração, se a conta existe; e-mails de redefinição são enviados ao mesmo endereço no máximo três vezes por hora. Novas senhas devem ter pelo menos dez caracteres e não podem exceder 72 bytes (UTF-8), pois o bcrypt não leva em conta mais bytes. Alterar a senha encerra as sessões de todos os outros dispositivos; redefini-la pelo link encerra as sessões de todos os dispositivos, e o link é válido apenas uma vez.
Bloqueio após tentativas malsucedidas. Os logins malsucedidos são contados por endereço IP; após muitos em pouco tempo (atualmente oito em 15 minutos), o login a partir desse endereço é bloqueado temporariamente. Um login bem-sucedido zera esse contador. As tentativas são excluídas após sete dias. Além disso, antes de cada verificação de senha, uma tentativa é contada por conta (para um endereço desconhecido, por endereço informado) e por endereço IP, incluindo as bem-sucedidas: atualmente no máximo oito por conta a partir do mesmo endereço IP e 80 por endereço IP em 15 minutos; um limite consideravelmente mais alto aplica-se por conta somando todos os endereços, contra tentativas distribuídas de adivinhar senhas. Portanto, tentativas malsucedidas a partir de outro endereço já não impedem o proprietário de acessar uma conta. Esses contadores contêm apenas uma chave HMAC, sem e-mail nem endereço IP em texto simples, e expiram com sua janela de tempo. Se o armazenamento dos contadores estiver indisponível, o login é recusado, não liberado. O mesmo tipo de limite aplica-se à confirmação de senha antes de uma alteração de senha ou endereço, à ativação ou desativação do segundo fator, à transferência de um espaço de trabalho, à exportação de dados e à exclusão da conta (cinco tentativas por conta em 15 minutos), aos cadastros (dez por endereço IP por hora) e às senhas de portais de clientes (dez tentativas por portal e endereço IP, 50 por portal em 15 minutos).
Segundo fator. Toda conta pode ativar o login com um código de uso único nos termos da RFC 6238 (TOTP). O segredo correspondente é armazenado criptografado no banco de dados; a chave não é armazenada no banco de dados, de modo que uma extração do banco de dados, por si só, não basta. Um código aceito não é válido uma segunda vez. Dez códigos de recuperação são armazenados apenas como hash. Códigos de uso único e de recuperação são limitados a dez tentativas por conta em 15 minutos, inclusive durante a configuração.
Área administrativa apenas com segundo fator. A área administrativa do operador só abre para contas com o segundo fator ativado. A lista de verificação de configuração informa cada conta de administrador sem segundo fator.
Sessões. O cookie de sessão não pode ser lido por scripts (HttpOnly), é enviado apenas por HTTPS (Secure) e não é enviado com solicitações de sites de terceiros que possam alterar algo (SameSite=Lax). No login, um novo ID de sessão é criado, para que um ID implantado anteriormente deixe de ser válido; o servidor não aceita um ID de sessão que ele próprio não tenha emitido. Toda conta vê seus dispositivos conectados e pode encerrar suas sessões individualmente.
“Manter conectado” é opcional e válido por 30 dias, mas não para contas com direitos de administração; elas sempre entram com senha e segundo fator. O token é composto de duas partes; a parte verificadora é armazenada no banco de dados apenas como hash. Cada uso a substitui por uma nova e, mesmo com solicitações simultâneas, cada token é válido apenas uma vez, para que um token roubado seja percebido no máximo na próxima visita legítima.
Links em e-mails. Links para confirmar o endereço e redefinir a senha são armazenados no banco de dados apenas como hash. O link de redefinição é válido por uma hora, o link de confirmação de cadastro por 72 horas e o link de confirmação de um endereço alterado por 24 horas. Se o endereço de e-mail for alterado, um link de redefinição pendente se torna inválido.
Interfaces. Chaves de API, códigos de conexão das extensões e códigos de implantação são armazenados apenas como hash. As chaves de API só podem ser usadas um número limitado de vezes por minuto; os códigos de conexão das extensões são válidos por 15 minutos e apenas uma vez.
Proteção contra bots nos formulários públicos (cadastro, login, senha, verificação, ferramenta de cabeçalhos, opt-out, suporte e contato): Google reCAPTCHA, que é carregado apenas no envio. Só é aceita uma resposta válida do Google com pontuação suficiente para a ação exata do formulário; se o Google não responder em três segundos, o envio é recusado. Os detalhes estão na Política de Privacidade.

3.3 Controle de acesso: administração dos servidores

O servidor acessível pela internet usa um filtro de pacotes para permitir apenas os serviços que oferece e bloqueia automaticamente endereços após repetidos logins malsucedidos na administração do servidor.
Os processos automatizados entre os servidores usam suas próprias chaves com direitos estritamente limitados. A chave com a qual o servidor web entrega novas versões do verificador só pode executar uma lista fixa de comandos no servidor de verificação e só pode copiar, com permissão apenas de escrita, para o diretório do verificador; não é possível fazer login interativo com ela, e todo comando rejeitado é registrado. Da mesma forma, o servidor de verificação só pode gravar capturas de tela em um diretório específico no servidor web.
O processo que fornece o site não tem acesso de escrita à instalação em produção nem uma chave para o servidor de verificação. Uma implantação acionada na área administrativa apenas registra uma tarefa, que é executada por uma rotina separada.
Segredos, como credenciais de banco de dados e chaves, são mantidos em arquivos de configuração fora do diretório servido e não são copiados durante a implantação. A configuração do servidor web não é distribuída pela interface web.

3.4 Controle de autorizações: direitos dentro do serviço

Papéis. Cada espaço de trabalho tem os papéis de proprietário, administrador e leitor. Alterar, excluir, convidar e armazenar credenciais são ações reservadas a proprietários e administradores; somente o proprietário pode alterar papéis e remover membros. Um convite é válido apenas enquanto a pessoa que o enviou ainda for proprietário ou administrador. Os leitores veem os endereços de webhooks e canais de chat reduzidos apenas ao host, pois o endereço, por si só, permite publicar no canal. A verificação ocorre no servidor, não apenas na interface.
Vínculo com o espaço de trabalho. Domínios e configurações são acessíveis apenas aos membros do espaço de trabalho. Para cada verificação, o Serviço cria um relatório sob um link aleatório que não pode ser adivinhado; os resultados e as capturas de tela de uma verificação podem ser acessados por esse link sem login, e as capturas de tela apenas junto com o link do respectivo relatório. O link aparece na conta e nos alertas; quem o transmite transmite o relatório.
Solicitações que alteram o estado exigem um token de segurança por sessão (proteção CSRF), que é comparado em tempo constante.
“Visualizar como cliente”. Para suporte, o operador pode ver a aplicação como um Cliente a vê. A visualização termina após uma hora, bloqueia alterações de senha, endereço, segundo fator, dispositivos, assinatura, exportação e exclusão, fecha a área administrativa nesse intervalo e é registrada. Encerrá-la desconecta completamente o operador; ele só pode voltar à área administrativa fazendo login novamente com senha e segundo fator. O Cliente pode vê-la na sua exportação de dados.
Administração. Apenas algumas contas expressamente autorizadas têm direitos administrativos; toda redefinição de segundo fator pela administração é registrada.

3.5 Controle de separação

Os dados dos clientes são separados logicamente por espaço de trabalho. Todo caminho de leitura e escrita na área conectada mantém esse vínculo; os relatórios também são acessíveis pelo seu link (seção 3.4).
O desenvolvimento e a operação são executados em instalações separadas, com bancos de dados e usuários de banco de dados separados. O usuário de desenvolvimento não tem acesso ao banco de dados de produção. Dados reais de clientes não são copiados para o desenvolvimento; nele trabalhamos com dados de exemplo gerados.
Para cada ambiente, o verificador tem suas próprias credenciais, com direitos apenas sobre os dados necessários para suas tarefas. Não pode ler contas, cobrança ou registros.
Outros serviços do mesmo prestador também são executados no servidor web. Eles têm seus próprios bancos de dados e usuários de banco de dados, sem acesso aos dados deste serviço.

4. Criptografia, pseudonimização e minimização de dados

4.1 Credenciais para a verificação de áreas protegidas por login

Para essa função, o Cliente armazena o nome de usuário e a senha de uma conta de teste. São os dados mais sensíveis do serviço e, por isso, são protegidos de forma diferente de todos os outros:

Ao armazená-los, o servidor web os criptografa com a chave pública do servidor de verificação (ECIES: X25519 com uma chave de uso único por registro, HKDF-SHA256, AES-256-GCM). A chave privada existe apenas no servidor de verificação. O servidor web, o banco de dados e os backups contêm apenas texto cifrado; nem nós podemos lê-lo nesses locais.
Cada registro é vinculado criptograficamente ao seu domínio. Se for movido para outro domínio, a descriptografia falha.
Para uma verificação, o texto cifrado é anexado à tarefa. O servidor de verificação o descriptografa e transmite as credenciais ao contêiner de verificação apenas pela entrada padrão, nunca como argumento de linha de comando que seria visível em listas de processos. Assim que o servidor de verificação o lê, o texto cifrado é excluído da tarefa; uma rotina limpa eventuais restos no máximo após uma hora.
As credenciais nunca são exibidas, registradas, disponibilizadas pela API ou exportadas. A interface mostra apenas o primeiro caractere e o comprimento do nome de usuário. Removê-las sobrescreve o texto cifrado.
Na área protegida por login, o verificador apenas lê: sem envio, sem teste ativo, sem capturas de tela, sem páginas de saída, exclusão ou cancelamento.

4.2 Outras criptografias e hashes

Senhas, códigos de recuperação, senhas de portais de clientes, chaves de API, códigos de conexão e implantação, tokens de “Manter conectado”, IDs de sessão na lista de dispositivos e links de confirmação e redefinição são armazenados apenas como hash.
Os segredos do segundo fator são armazenados criptografados (seção 3.2).
Não afirmamos que o banco de dados inteiro seja criptografado em repouso. Os valores sensíveis são protegidos individualmente, conforme descrito acima.

4.3 Minimização de dados desde a concepção

Verificação de entrega: São lidos apenas os cabeçalhos e no máximo os primeiros 8 KB do texto. Apenas o horário, a associação, quando aplicável o ID do envio de teste e o resultado da verificação de autenticidade (SPF, DKIM, DMARC) vão para o banco de dados, nunca o conteúdo ou um endereço completo de remetente. O resultado de autenticidade do e-mail mais recente é mantido com o domínio e sobrescrito pelo seguinte; contém o endereço IP do servidor de e-mail que realiza a entrega e o domínio de e-mail do remetente. O e-mail é excluído da caixa de e-mail após o processamento bem-sucedido; se a obtenção ou a exclusão falhar, isso ocorre na próxima execução bem-sucedida.
Verificações: A estrutura dos formulários é armazenada com nomes, tipos e rótulos de campos, atributos de obrigatoriedade e visibilidade, sem valores; o verificador lê o início dos campos ocultos preenchidos previamente (até 24 caracteres) e dos atributos de dados (até 60 caracteres) apenas durante a verificação e não os armazena. As capturas de tela da verificação completa não são editadas para ocultar dados; somente as verificações no navegador encobrem os campos de entrada. Os endereços de destinatários dos formulários são armazenados apenas como domínio. Os envios de teste ativos contêm apenas textos de teste identificados, sem dados pessoais.
As extensões para WordPress e TYPO3 transmitem apenas números diários e características, como o inventário de plugins, e, para um plugin WordPress conectado, também os domínios dos links de mensagens bloqueadas para a proteção coletiva (ativada por padrão); nenhum outro conteúdo, nenhum nome, endereço ou endereço IP de visitantes. As contagens opcionais de formulários e erros de campos ficam desativadas por padrão.
“Fix it for me”: O código colado é processado apenas durante a solicitação e não é armazenado.
Selo: A imagem do selo nos sites dos clientes não define cookie nem inicia sessão.
As notificações operacionais para o telefone do operador são textos fixos sem variáveis, ou seja, sem nomes, endereços ou conteúdo. As notificações de erro por e-mail ao operador contêm o texto bruto da mensagem de erro, sem sanitização e truncado em 400 caracteres; em casos individuais, ele pode conter endereços ou links.
Proteção coletiva: Entre as extensões dos Clientes, são compartilhados apenas domínios de links em spam bloqueado; o intercâmbio de redes IP está desativado.
Localização: O país de um endereço IP é determinado a partir de um arquivo local de banco de dados; nenhum endereço vai para um serviço de geolocalização.

5. Proteção contra uso indevido do verificador

O verificador carrega páginas de terceiros com um navegador real. Sem proteção, ele seria uma ferramenta com a qual alguém de fora poderia alcançar nossa rede interna ou outros destinos não públicos (falsificação de solicitações do lado do servidor). Por isso, há duas camadas independentes e o isolamento de cada execução individual.

5.1 Execução isolada

Cada verificação é executada em seu próprio contêiner, que é removido depois. Ela é executada sem direitos de administrador, sem capacidades adicionais do sistema operacional e sem a possibilidade de elevar privilégios. Seu sistema de arquivos é somente de leitura, exceto por pequenas áreas voláteis.
A memória, o número de processos e o tempo de execução são limitados; uma execução que exceda o tempo é encerrada.

5.2 Rede: duas camadas

Primeira camada, no verificador: Antes da verificação e depois para cada solicitação individual do navegador, incluindo redirecionamentos e conteúdo incorporado, verifica-se para onde o endereço é resolvido. Redes privadas, locais, reservadas e de documentação (IPv4 e IPv6) são rejeitadas, assim como portas diferentes das habituais para a web. O navegador não permite service workers, e as conexões WebSocket são fechadas, pois ambos poderiam contornar essa verificação.
Segunda camada, na rede: Os contêineres são executados na sua própria rede. As regras de firewall permitem conexões a partir dela para a internet apenas em portas web; conexões com redes privadas, incluindo nossa rede interna com servidor web e banco de dados, são bloqueadas. As exceções que a própria execução da verificação exige limitam-se ao necessário e estão descritas na nossa documentação interna. Essa camada também produz efeito se um nome passar a ser resolvido de forma diferente apenas após a primeira conferência.

5.3 Solicitações feitas pelo servidor web

Quando o próprio servidor web solicita endereços de terceiros – para comprovação de controle do domínio, para a ferramenta de cabeçalhos, para a busca por arquivos expostos, para solicitações de disponibilidade, para consultas RDAP e verificação de certificados, para webhooks e alertas de chat e para o segundo ponto de verificação opcional – aplicam-se as mesmas regras: apenas protocolos web nas portas web habituais (webhooks e alertas de chat apenas por HTTPS na porta-padrão), apenas endereços públicos, conexão apenas com o endereço exato conferido previamente, para que um nome não possa ser redirecionado posteriormente a um destino interno, redirecionamentos não seguidos de forma alguma ou seguidos apenas manualmente e conferidos novamente a cada vez, limites curtos de tempo; para comprovação de controle do domínio, solicitações de disponibilidade e o segundo ponto de verificação nas verificações no navegador, também um tamanho de resposta limitado.

5.4 O que o verificador não faz em sites de terceiros

Envios de teste ativos (no máximo cinco por verificação) existem para Clientes apenas em domínios para os quais tenha sido fornecida comprovação de controle (DNS, metatag, arquivo ou extensão); a única exceção são as verificações internas dos nossos próprios domínios de teste e demonstração. O nome de host de um domínio com comprovação de controle não pode ser alterado, para que a comprovação não passe a outro host. Todo o restante é passivo: ler páginas como um visitante.
As verificações no navegador vão até o momento anterior ao envio e não acionam nenhum pedido, pagamento ou envio.
Domínios na lista de opt-out não são verificados; o monitoramento em andamento termina na próxima verificação programada.

6. Integridade: transferência e entrada

6.1 Transporte

A aplicação só pode ser acessada pela internet por HTTPS; o navegador é instruído a usar apenas HTTPS por um ano (HSTS). Os certificados são renovados automaticamente.
Outros cabeçalhos restringem a incorporação da aplicação em páginas de terceiros, a inferência de tipos de arquivos e o envio de formulários a destinos de terceiros. Uma política de segurança de conteúdo permite que sejam executados na aplicação apenas os scripts que o servidor libera com a respectiva resposta; os navegadores atuais não executam scripts injetados nem manipuladores de eventos no HTML.
O conteúdo da caixa de e-mail da verificação de entrega é obtido por uma conexão criptografada com verificação de certificado.
Webhooks podem ser assinados com um segredo do Cliente (HMAC-SHA256 com registro de tempo), para que o destinatário possa verificar a origem e a integridade. As solicitações ao segundo ponto de verificação opcional são assinadas e, para verificações no navegador, suas respostas também.
Declarado abertamente: As conexões dentro da nossa rede interna não são integralmente criptografadas. As credenciais para a verificação de áreas protegidas por login permanecem criptografadas durante todo o processo (seção 4.1).

6.2 Controle de entrada e registros

Ações importantes em contas e espaços de trabalho (como login, alterações de domínios, destinos de alertas e direitos, exclusões, acesso do suporte) são registradas no registro de atividades com conta, horário, endereço IP e país e excluídas após 365 dias.
Os registros de acesso a páginas mantidos para segurança e prevenção de abuso são excluídos após 60 dias, os registros de erros após 90 dias e os conteúdos de e-mails enviados após 30 dias. Os tokens de acesso em endereços solicitados e referenciadores, como os de links de relatórios ou portais, aparecem nos registros de acesso a páginas apenas de forma mascarada.
A aceitação dos documentos contratuais é armazenada com a versão exibida, sua soma de verificação, horário, endereço IP e identificador do navegador.
Os registros de evidências podem receber um carimbo do tempo de uma autoridade externa de carimbo do tempo; apenas uma soma de verificação do conteúdo vai para ela, não o próprio conteúdo.

7. Disponibilidade e resiliência

7.1 Backup

É feito um backup do banco de dados todas as noites. Um backup só recebe seu nome definitivo após a conferência do seu conteúdo: conclusão bem-sucedida do programa de backup, pelo menos um registro, tantas tabelas quantas houver no banco de dados e a linha de encerramento de uma execução completa. Os backups mais antigos só são removidos após um novo backup bem-sucedido.
Cada backup é excluído após 14 dias. O local de armazenamento fica fora de qualquer diretório servido; um local dentro do projeto é rejeitado.
Teste de restauração: Uma vez por semana, o backup mais recente é carregado em um banco de dados descartável, comparado tabela por tabela com a produção e excluído novamente. O resultado é armazenado.
Se um backup ou teste falhar, uma notificação é enviada por e-mail e para o telefone do operador.
Recuperação após um incidente: Se o banco de dados falhar ou os dados forem corrompidos, restauramos o backup testado mais recente. As alterações feitas desde esse backup, em regra no máximo as de um dia, podem ser perdidas nesse processo; se um backup tiver falhado, proporcionalmente mais. Em seguida, executamos novamente as solicitações posteriores de exclusão conhecidas (seção 8). Não nos comprometemos com um tempo específico de recuperação.
Limite declarado abertamente: Atualmente, os backups são armazenados no mesmo local que o banco de dados e não são criptografados separadamente. Eles protegem contra erros operacionais, alterações incorretas e dados corrompidos, não contra a perda do próprio servidor. Uma cópia criptografada em um segundo local está planejada (seção 10).
As credenciais para a verificação de áreas protegidas por login estão contidas nos backups apenas como texto cifrado; o segredo do segundo fator, apenas de forma criptografada, com uma chave fora do banco de dados.

7.2 Monitoramento

Uma rotina de status verifica os componentes do serviço a cada cinco minutos, incluindo o banco de dados, a fila e o sinal de atividade do verificador, que ele grava regularmente mesmo quando ocioso. Se um componente falhar, uma notificação é enviada; se ele se recuperar, um aviso de normalização.
Monitoramento cruzado: Uma rotina de status não pode informar a falha da máquina na qual é executada. Por isso, o servidor de verificação confere a cada minuto se a aplicação responde e, após várias falhas consecutivas, informa com um texto fixo ao telefone do operador. No sentido contrário, o servidor web monitora o sinal de atividade do verificador; a lista de verificação de configuração mostra se o monitoramento cruzado está em execução.
Alerta de erro: Um tipo de erro que nunca ocorreu antes é informado imediatamente uma vez; um acúmulo de erros aciona apenas um único sinal para o telefone do operador; uma vez por dia, um resumo é enviado. Assim, não ficamos sabendo de um erro primeiro por um Cliente.
Limite declarado abertamente: Ambos os servidores estão no mesmo local. Uma falha de todo o local, por exemplo, de energia ou conexão com a internet, não é informada por nenhum mecanismo de alerta, mas percebida por uma pessoa.

7.3 Alterações e implantação

Novas versões são primeiro compiladas e testadas no ambiente de desenvolvimento separado. A implantação verifica todos os requisitos antes da gravação do primeiro arquivo, realiza as alterações no esquema do banco de dados e permite que as verificações em andamento terminem de forma ordenada antes de o verificador reiniciar.
Para o fluxo de um novo Cliente, há um teste de fumaça por HTTP real, executado após as mudanças de versão. Não afirmamos que haja uma suíte de testes automatizados antes de cada implantação.

8. Exclusão e prazos de retenção

Uma rotina de exclusão todas as noites aplica os prazos indicados na Política de Privacidade e no Acordo de Tratamento de Dados. Ela lê as mesmas configurações das quais são obtidos os números dos textos; portanto, para esses prazos, texto e comportamento não divergem.
Os resultados das verificações, incluindo capturas de tela, são excluídos após 13 meses (o mais recente por domínio permanece), os números das extensões após 13 meses, os registros de entrega de alertas após 90 dias e as solicitações de suporte após 24 meses.
Remover um domínio exclui os dados do domínio, incluindo verificações, formulários, constatações, capturas de tela, relatórios, tarefas, destinos e registros de alertas, incidentes, dados de entrega, credenciais para a verificação de áreas protegidas por login e evidências.
A exclusão de uma conta ocorre imediatamente; espaços de trabalho sem outros membros são excluídos com seus dados, enquanto espaços de trabalho com outros membros passam a outro membro, primeiro a administradores e, entre eles, ao mais antigo. Até o término dos seus próprios prazos, permanecem: os registros cujas entradas mantêm o número antigo da conta, que já não se refere a nenhuma conta existente, incluindo a entrada de exclusão, assim como e-mails enviados, a comprovação da celebração do contrato, solicitações de suporte, relatórios de verificações de potenciais clientes (até 90 dias) e dados de cobrança na Stripe; os detalhes estão na Política de Privacidade.
Os dados excluídos permanecem nos backups até sua expiração após 14 dias. Não ocorre exclusão seletiva dentro de um backup; se um backup for restaurado, as solicitações posteriores de exclusão conhecidas são executadas novamente de forma manual.

9. Organização e revisão

Pessoas: Atualmente, o serviço é operado pelo próprio proprietário. Outras pessoas só recebem acesso após um compromisso de confidencialidade e apenas na medida necessária, e tratam dados somente conforme nossas instruções (Art. 29 e Art. 32(4) do RGPD).
Suboperadores: Só os contratamos após revisar suas garantias e mediante contrato nos termos do Art. 28(4) do RGPD, e os listamos na página Suboperadores; os detalhes são regidos pelo Acordo de Tratamento de Dados.
Violações de dados pessoais: Se uma violação de dados pessoais afetar dados tratados como operador, notificamos o Cliente sem demora injustificada, se possível em até 48 horas; os detalhes são regidos pelo Acordo de Tratamento de Dados.
Comunicação de vulnerabilidades: Aceitamos comunicações em Segurança e pelo arquivo /.well-known/security.txt.
Lista de verificação de configuração e lançamento: Na área administrativa, uma lista de verificação mede o estado de configurações relevantes para a segurança, como backup, administradores sem segundo fator, configuração de e-mail e sinal de atividade, e exibe desvios.
Revisão destas medidas (Art. 32(1)(d) do RGPD): em toda alteração significativa no serviço, após cada incidente de segurança e, nos demais casos, pelo menos uma vez por ano. Nesse processo, avaliamos se as medidas são eficazes e ainda correspondem aos riscos e registramos o resultado em uma nova versão desta página ou, se nada mudar, com a data da revisão na seção 11. De forma contínua, a lista de verificação de configuração e lançamento mede o estado das configurações que abrange.
Auditorias externas: Atualmente, não são contratados testes de invasão externos, e não há certificações de segurança. Isso é declarado aqui para que ninguém presuma sua existência.

10. Planejado, ainda não implementado

Estes pontos não são medidas assumidas como compromisso até que sejam listados aqui como implementados em uma nova versão:

Backup em um segundo local: uma cópia criptografada do backup noturno fora do servidor, para que mesmo uma perda total do servidor não leve à perda de dados.
Segundo ponto de verificação: A confirmação independente das verificações no navegador a partir de um segundo local está preparada no serviço, mas não configurada. Sem ela, não há confirmação de um segundo local.
Reforço da segurança da administração dos servidores: Está em andamento. Pelos motivos apresentados na seção 1, não publicamos detalhes.

11. Estado e versão

Versão 1.1 · Última atualização: 22 de outubro de 2026 · em caso de divergências entre as versões linguísticas, prevalece a versão em polonês em vez da alemã; nenhuma outra alteração.
Versão 1.0 · Última atualização: 11 de outubro de 2026 · primeira versão como página separada; anteriormente, Anexo 2 do Acordo de Tratamento de Dados. Correções em relação ao anexo anterior: o teste de restauração ocorre semanalmente, os backups ficam no mesmo servidor, nenhuma suíte de testes automatizados é executada antes de cada implantação, as conexões na rede interna não são integralmente criptografadas. Novas descrições: criptografia das credenciais para a verificação de áreas protegidas por login, isolamento do verificador, monitoramento cruzado e alerta de erro.
As alterações são publicadas com um novo número de versão aqui e na visão geral Alterações nos Documentos Contratuais; para qualquer enfraquecimento das medidas, aplica-se o prazo de aviso do Acordo de Tratamento de Dados.
Em caso de divergências entre as versões linguísticas, prevalece a versão em polonês.

Como podemos ajudar?