A maioria dos construtores de formulários parece semelhante por fora. Um editor de arrastar e soltar, um botão de publicação, notificações por e-mail ao enviar. Nada nessa interface informa se os dados são criptografados, quem pode acessá-los ou para onde vão após a coleta.
Falhas de segurança em construtores de formulários raramente são visíveis antes de se tornarem um problema. Elas aparecem em notificações de violação, auditorias de conformidade ou solicitações de usuários que querem saber o que aconteceu com seus dados.
Os sinais de aviso, no entanto, são em grande parte visíveis com antecedência. Na documentação, nos conjuntos de recursos e nas respostas a perguntas específicas. Este artigo aborda sete deles.
Este artigo é apenas para fins informativos e não constitui aconselhamento jurídico. Consulte um profissional qualificado em proteção de dados para obter orientações específicas para sua organização.
Nesta página
- Nenhum Acordo de Processamento de Dados disponível
- Scripts de terceiros executados em páginas de formulários sem divulgação
- Reivindicações de criptografia são vagas ou ausentes
- Sem retenção de dados configurável
- Sem registro de auditoria para acesso a submissões
- Nenhum BAA disponível para casos de uso em saúde
- Submissões individuais não podem ser deletadas mediante solicitação
Sinal 1: Nenhum Acordo de Processamento de Dados disponível
Um Acordo de Processamento de Dados (DPA) é um contrato legalmente vinculativo entre a organização que coleta dados (o controlador) e a plataforma que os processa (o processador). Onde o GDPR se aplica e um controlador usa um processador terceirizado, o Artigo 28 exige um Acordo de Processamento de Dados compatível antes que o processador lide com dados pessoais em nome do controlador.
O contrato deve definir, no mínimo: o assunto e a duração do processamento, o tipo de dados e categorias de indivíduos envolvidos, as instruções do controlador para o processador, obrigações de segurança, divulgação de sub-processadores, procedimentos para lidar com solicitações de direitos dos titulares de dados, prazos de notificação de violação e exclusão ou devolução de dados no término do contrato.
Isso não é apenas uma formalidade. O Artigo 28(3) especifica cada um desses elementos explicitamente. Uma política de privacidade não é um DPA. Termos de serviço não são um DPA. Um DPA é um instrumento separado e bilateral assinado por ambas as partes.
O sinal: O site do construtor de formulários não possui um DPA disponível para download. Pesquisar por “DPA” ou “Acordo de Processamento de Dados” não retorna nada ou redireciona para uma política de privacidade geral.
O que isso significa na prática: Sem um DPA assinado, usar a plataforma para coletar dados pessoais de indivíduos na UE cria exposição legal para sua organização. Não para a plataforma. Sob o GDPR, o controlador (você) tem a responsabilidade primária de garantir que um acordo compatível com o Artigo 28 esteja em vigor. Não ter um acordo de processamento compatível com o Artigo 28 em vigor é, por si só, uma questão de conformidade, independentemente de ocorrer uma violação de dados pessoais.
Princípios de responsabilidade semelhantes existem sob outras estruturas de privacidade. CCPA/CPRA, a LGPD do Brasil e a PIPEDA do Canadá esperam que as organizações usem salvaguardas contratuais apropriadas ao contratar prestadores de serviços terceirizados, embora os mecanismos legais sejam diferentes do Artigo 28 do GDPR.
O que procurar: Um DPA disponível publicamente para download que possa ser assinado sem exigir negociação empresarial. Para organizações sob o GDPR, o DPA também deve abordar sub-processadores. As terceiras partes das quais o construtor de formulários depende para infraestrutura, armazenamento ou processamento. O centro de confiança de um fornecedor é geralmente o lugar certo para encontrar essa documentação. Para uma lista de verificação completa de implementação do GDPR, veja Conformidade com o GDPR para Formulários Online: Uma Lista de Verificação Prática.
Sinal 2: Scripts de terceiros executados em páginas de formulários sem divulgação
Quando um usuário abre seu formulário, ele pode estar compartilhando seus dados com mais do que apenas você.
A maioria dos aplicativos web — incluindo construtores de formulários — carrega JavaScript de terceiros para análises, publicidade, gravação de sessão, monitoramento de erros e testes A/B. Alguns desses scripts têm acesso aos valores dos campos do formulário enquanto os usuários digitam. Isso significa que um nome, endereço de e-mail ou número de telefone pode sair do dispositivo do usuário antes que ele clique em “Enviar”.
Este é um comportamento documentado. Um estudo de 2022 por pesquisadores da Universidade Radboud, KU Leuven e da Universidade de Lausanne — intitulado “Formulários Vazados: Um Estudo sobre a Exfiltração de E-mails e Senhas Antes do Envio do Formulário” — descobriu que 1.844 sites em uma amostra de 100.000 coletaram endereços de e-mail de usuários antes do envio do formulário via scripts de rastreamento de terceiros, sem o consentimento do usuário. Os dados foram exfiltrados silenciosamente, antes de qualquer evento de envio ocorrer.
O mecanismo é simples: scripts de análise e marketing anexam ouvintes de eventos aos campos de entrada e transmitem o conteúdo para pontos de coleta remotos. O próprio construtor de formulários pode não ter a intenção desse comportamento. Mas se scripts de terceiros são carregados na mesma página, os dados fluem para eles independentemente.
O sinal: O construtor de formulários não documenta quais scripts de terceiros são executados nas páginas de formulários publicados. Sua política de privacidade descreve sua própria coleta de dados, não o comportamento de coleta dos scripts que rodam em seus formulários.
O que isso significa na prática: Se seu formulário carrega um pixel de análise de terceiros ou ferramenta de gravação de sessão, os dados que seus usuários digitam podem ser transmitidos a esse terceiro sem consentimento. Isso afeta a precisão da sua política de privacidade, sua conformidade com o GDPR (base legal para processamento) e, em contextos de saúde, potencialmente suas obrigações sob a HIPAA.
O que procurar: Documentação explícita dos scripts carregados nas páginas de formulários publicados. Uma plataforma que lida com dados sensíveis deve ser capaz de declarar, precisamente, quais serviços recebem dados das submissões de formulários e em que forma. Formulários servidos em domínios isolados e de primeira parte, sem scripts de publicidade ou análise, são a solução mais forte.
Sinal 3: Reivindicações de criptografia são vagas ou ausentes
“Seus dados estão seguros” é uma declaração de marketing. Não descreve um controle técnico. Duas reivindicações específicas são importantes para dados de formulários:
Criptografia em trânsito significa que os dados são criptografados enquanto viajam entre o navegador do usuário e o servidor. O padrão atual é TLS 1.2 ou superior. Isso é amplamente padrão na web. Mas deve ser declarado explicitamente, com a versão do protocolo.
Criptografia em repouso significa que os dados armazenados — submissões de formulários em um banco de dados — são criptografados. O padrão atual para dados sensíveis é AES-256. É aqui que as plataformas diferem. Algumas criptografam dados de submissão em repouso; muitas não. Uma plataforma pode ter excelente criptografia em trânsito enquanto armazena seus dados em texto simples.
A distinção é importante porque os modelos de ameaça são diferentes. A criptografia em trânsito protege contra interceptação durante a transmissão. A criptografia em repouso protege contra acesso não autorizado a dados armazenados — que é a ameaça relevante na maioria dos cenários de violação. De acordo com o Relatório de Custo de Violação de Dados da IBM de 2025, a violação média leva 158 dias para ser identificada e 83 dias para ser contida — um ciclo de vida total de 241 dias, o mais baixo em nove anos, segundo a IBM Security. Durante esse período, os dados armazenados são a principal exposição.
O Top 10 da OWASP (2025) lista “Falhas Criptográficas” como A04 — um dos riscos de segurança de aplicativos web mais críticos — incluindo especificamente “dados armazenados em texto claro” como um modo de falha primário.
O sinal: A documentação de segurança da plataforma usa frases como “usamos segurança padrão da indústria” sem especificar o algoritmo de criptografia, versão do protocolo ou escopo de cobertura. Nenhuma menção de AES-256 ou TLS 1.2+.
O que isso significa na prática: Reivindicações de criptografia vagas não fornecem garantia verificável. Para dados regulamentados — saúde, financeiro, jurídico — a criptografia em repouso é frequentemente um requisito de conformidade, não uma preferência. A Regra de Segurança da HIPAA (45 CFR § 164.312) aborda especificamente a criptografia como uma salvaguarda “endereçável”, significando que as entidades cobertas devem implementá-la ou documentar por que uma alternativa equivalente oferece a mesma proteção.
O que procurar: Uma declaração clara e técnica: “Os dados de submissão são criptografados em repouso usando AES-256 e em trânsito usando TLS 1.2+.” Se isso não puder ser encontrado na documentação pública — tipicamente no centro de confiança ou página de segurança de um fornecedor — pergunte diretamente. Uma plataforma que lida com dados sensíveis deve responder sem ambiguidade. Para uma análise completa de como a pilha de segurança deve se parecer, veja Segurança de Dados para Formulários Online: O Que Toda Empresa Deve Saber.
Sinal 4: Sem retenção de dados configurável
Por quanto tempo a plataforma armazena seus dados de submissão? Se a resposta for “indefinidamente, a menos que você os exclua manualmente”, isso é um problema.
O princípio de limitação de armazenamento do GDPR (Artigo 5(1)(e)) exige que os dados pessoais sejam “mantidos em uma forma que permita a identificação dos titulares dos dados por não mais tempo do que o necessário para os fins para os quais os dados pessoais são processados”. Armazenar submissões de formulários para sempre — mesmo de anos atrás — quase nunca é compatível com esse requisito.
Há também um risco prático: quanto maior o conjunto de dados mantido por uma plataforma, mais valioso ele se torna como alvo de violação. Submissões de formulários de três anos atrás, ainda em um servidor, ainda estão em risco. A exclusão automatizada reduz essa exposição.
Diferentes fluxos de trabalho têm diferentes necessidades legítimas de retenção:
| Tipo de formulário | Consideração típica de retenção |
|---|---|
| Formulários de contato e consulta | Duração do acompanhamento ativo |
| Formulários de geração de leads | Ciclo de vendas ativo |
| Registro de eventos | Data do evento mais qualquer período necessário de manutenção de registros |
| Admissão em saúde | Duração exigida pela regulamentação aplicável (a HIPAA exige 6 anos para registros cobertos) |
| Candidaturas de emprego | Varia por jurisdição e é regida pela legislação trabalhista local — consulte seu DPO ou consultor jurídico antes de definir um período de retenção |
O sinal: A plataforma armazena submissões indefinidamente por padrão. Não há configurações para configurar um cronograma de exclusão automática. A única opção é a exclusão manual.
O que isso significa na prática: A conformidade com os requisitos de retenção de dados depende da ação humana. Políticas automatizadas não. Uma organização que depende de funcionários para excluir manualmente submissões de formulários antigos eventualmente perderá um ciclo de exclusão — especialmente durante transições de pessoal ou períodos de alto volume.
O que procurar: Períodos de retenção configuráveis no nível da conta ou do formulário. O intervalo deve acomodar tanto a retenção curta (para fluxos de trabalho de alta privacidade) quanto a retenção estendida (para manutenção de registros exigida por conformidade). Opções como “excluir imediatamente após exportar para armazenamento em nuvem” representam a melhor prática para fluxos de trabalho críticos para a privacidade.
Sinal 5: Sem registro de auditoria para acesso a submissões
Quando uma submissão é aberta, quem a abriu? Quando? Alguém a exportou? Foi compartilhada via link? Foi deletada, e por quem?
Na ausência de um registro de auditoria, nenhuma dessas perguntas pode ser respondida. Isso cria uma lacuna significativa de responsabilidade — que se torna visível em auditorias regulatórias, solicitações de acesso de titulares de dados ou investigações internas.
A Regra de Segurança da HIPAA aborda explicitamente isso. O padrão de controles de auditoria (45 CFR § 164.312(b)) exige que as entidades cobertas “implementem mecanismos de hardware, software e/ou procedimentos que registrem e examinem a atividade em sistemas de informação que contenham ou usem informações de saúde protegidas eletrônicas”. Registrar quem visualizou uma submissão e quando é uma implementação direta desse requisito.
Além da saúde: o Artigo 5(2) do GDPR estabelece o princípio da responsabilidade — os controladores devem ser capazes de “demonstrar conformidade” com os princípios de proteção de dados. Um registro de auditoria é um componente fundamental dessa demonstração. Sem ele, “não acessamos esses dados” é uma afirmação que você não pode verificar.
O Top 10 da OWASP (2025) inclui “Falhas de Registro e Alerta de Segurança” (A09) como um risco crítico de aplicativos web — especificamente: “Eventos auditáveis, como logins, logins falhados e transações de alto valor, não são registrados.”
O sinal: A plataforma não possui registro de atividades. Os administradores podem visualizar submissões, mas não podem ver o histórico de acesso, histórico de exportação ou atividade de compartilhamento.
O que isso significa na prática: Você não pode responder a perguntas sobre quem acessou submissões específicas. Se um titular de dados exercer seu direito de acesso sob o Artigo 15 do GDPR, ele pode solicitar informações sobre os destinatários ou categorias de destinatários com quem seus dados pessoais foram compartilhados — uma pergunta que um registro de auditoria ajuda a responder. Embora o Artigo 15 não exija que os controladores mantenham registros de auditoria, tais registros podem ajudar significativamente a demonstrar conformidade e a responder com precisão a solicitações de acesso.
O que procurar: Um registro de auditoria em nível de equipe acessível aos administradores, registrando no mínimo: eventos de acesso a submissões, eventos de exportação, criação de links de compartilhamento e eventos de exclusão. Os registros devem ser mantidos por um período consistente com seus requisitos de conformidade.
Sinal 6: Nenhum BAA disponível para casos de uso em saúde
Nos Estados Unidos, qualquer organização que lida com Informações de Saúde Protegidas (PHI) em nome de uma entidade coberta — incluindo um construtor de formulários que processa formulários de admissão de pacientes — é legalmente um Associado Comercial sob a HIPAA (45 CFR § 160.103).
Antes que qualquer PHI flua através de uma ferramenta de terceiros, um Acordo de Associação Comercial (BAA) assinado deve estar em vigor. O BAA não é apenas uma formalidade: ele estabelece as obrigações do Associado Comercial em relação à proteção de PHI, prazos de notificação de violação e usos permitidos de dados. Sem ele, a entidade coberta assume a responsabilidade por violações da HIPAA decorrentes do manuseio de PHI pelo Associado Comercial — independentemente dos controles de segurança reais da plataforma.
O OCR tem consistentemente aplicado esse requisito. Acordos foram alcançados contra organizações de saúde por usarem ferramentas de terceiros não autorizadas para processar PHI, mesmo na ausência de uma violação. A violação é o acordo ausente, não a violação.
Para as salvaguardas técnicas específicas que a HIPAA exige — que um construtor de formulários deve implementar para assinar validamente um BAA — veja o que a HIPAA realmente exige de ferramentas de formulários online.
O sinal: A plataforma não oferece BAA, ou oferece apenas em níveis de preços empresariais inacessíveis para a maioria das organizações de saúde. Pequenas clínicas, terapeutas independentes e startups de saúde ficam coletando PHI sem uma relação de processamento compatível.
O que isso significa na prática: Usar um construtor de formulários sem um BAA para coletar dados de pacientes — formulários de admissão, formulários de consentimento, solicitações de consulta, detalhes de seguro vinculados a informações de saúde — é uma violação da HIPAA. Não é uma área cinzenta.
O que procurar: Um BAA disponível em um plano de mercado médio, assinado automaticamente (ou com atrito mínimo) quando o modo HIPAA é ativado. O BAA assinado deve ser entregue ao administrador da conta como um documento que ele pode reter e produzir em uma auditoria.
Sinal 7: Submissões individuais não podem ser deletadas mediante solicitação
O Artigo 17 do GDPR estabelece o direito ao apagamento. Quando um titular de dados solicita a exclusão de seus dados pessoais, o controlador deve cumprir sem demora indevida e, em qualquer caso, dentro de um mês — sujeito a exceções limitadas (obrigação legal, interesse público, etc.). A solicitação se aplica aos dados do indivíduo específico, não a arquivos em massa.
Isso cria um requisito técnico: você deve ser capaz de identificar a submissão de um indivíduo específico e deletá-la de forma limpa. Muitas plataformas tornam isso difícil. A exclusão em massa geralmente está disponível; a busca e exclusão direcionada por respondente não.
O mesmo problema afeta a conformidade proativa. Se sua política de retenção especifica exclusão após 90 dias, você precisa que a plataforma imponha isso no nível do registro — não apenas forneça um botão “apagar tudo” que limpe tudo.
O sinal: A interface de submissão não possui busca por identificador de respondente (e-mail, nome). A exclusão é apenas em massa. Não há como identificar todas as submissões de um indivíduo específico em vários formulários.
O que isso significa na prática: Quando um usuário envia uma solicitação de exclusão — que o GDPR lhes dá o direito de fazer — cumpri-la se torna um processo manual e propenso a erros. Se as submissões abrangerem vários formulários ou períodos de tempo, encontrar e excluir todos os registros relevantes se torna operacionalmente difícil.
O que procurar: Busca de submissão por valor de campo, incluindo endereço de e-mail, nome ou qualquer campo identificador. Exclusão de registro individual na interface de submissão. Para organizações sob o GDPR, a capacidade de executar uma consulta cruzada por respondente é valiosa.
Uma lista de verificação
Antes de publicar qualquer formulário que colete dados sensíveis:
- Um DPA disponível para download e assinatura está disponível na plataforma
- A plataforma documenta quais scripts de terceiros são executados nas páginas de formulários publicados
- Criptografia em repouso (AES-256) e em trânsito (TLS 1.2+) são declaradas explicitamente
- A retenção de dados é configurável, com opções de exclusão automática
- Um registro de auditoria registra eventos de acesso e exportação de submissões
- Se coletar PHI, um BAA assinado está em vigor antes de qualquer dado ser coletado
- Submissões individuais podem ser encontradas e deletadas por respondente
Referências
- Parlamento Europeu e Conselho, GDPR Artigo 28. Obrigações do processador e requisitos de DPA, gdpr-info.eu/art-28-gdpr/
- Parlamento Europeu e Conselho, GDPR Artigo 15. Direito de acesso pelo titular dos dados, gdpr-info.eu/art-15-gdpr/
- Parlamento Europeu e Conselho, GDPR Artigo 17. Direito ao apagamento, gdpr-info.eu/art-17-gdpr/
- Escritório de Direitos Civis do HHS, 45 CFR § 160.103. Definições (Associado Comercial), ecfr.gov
- Escritório de Direitos Civis do HHS, 45 CFR § 164.312. Salvaguardas técnicas, ecfr.gov
- Escritório de Direitos Civis do HHS, Contratos de Associados Comerciais, hhs.gov
- Acar, G. et al., Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission, Universidade Radboud / KU Leuven / Universidade de Lausanne, apresentado na USENIX Security 2023
- OWASP, OWASP Top 10 2025, owasp.org/Top10. A04 Falhas Criptográficas; A09 Falhas de Registro e Alerta de Segurança
- IBM Security, Relatório de Custo de Violação de Dados 2025, ibm.com/reports/data-breach. ciclo médio de violação de 241 dias (158 para identificar, 83 para conter)
Leitura relacionada: Conformidade com o GDPR para Formulários Online: Um Checklist Prático · Formulários Online Compatíveis com HIPAA: Um Guia 2026 · Segurança de Dados para Formulários Online: O Que Toda Empresa Deve Saber
