--- title: "Retenção de Dados de Formulários: Uma Política Que Funciona" slug: form-data-retention-policy description: "Políticas de retenção falham na exclusão, não na redação. Como definir o relógio, escolher um prazo por formulário e transformar a exclusão em rotina." publishedAt: "2026-10-08" author: "Instaform Team" tags: ["forms", "compliance", "how-to"] locale: pt --- Quase toda política de retenção falha no mesmo ponto. Alguém escreve "as solicitações são mantidas por 24 meses" em um documento, arquiva, e nada muda depois disso. Dois anos depois a caixa de entrada ainda guarda todas as solicitações desde o lançamento, mais uma planilha em um notebook e uma pasta de currículos no armazenamento compartilhado. Redigir a política é a metade fácil. A metade que decide se ela é real é se você consegue encontrar todas as cópias de um envio e removê-las sem alguém perder um dia inteiro nisso. ## Comece pelo relógio, não pelo prazo "Doze meses" não significa nada até você dizer doze meses a partir de quê. Três relógios são comuns e se comportam de formas bem diferentes. *A partir do envio* é o mais simples e o certo para solicitações que não deram em nada. O registro vence em um cronograma fixo, independentemente do que aconteceu depois. *A partir do último contato* serve para qualquer coisa que possa virar um relacionamento. Um lead com quem você falou em março não deveria sumir porque a primeira solicitação foi há quatorze meses. Esse relógio reinicia, o que significa que a data do último contato precisa estar guardada em um campo pelo qual você consiga filtrar, e não deduzida de uma thread de e-mail. *A partir do fim do relacionamento* é o que registros contábeis e contratuais exigem. A obrigação normalmente conta a partir do encerramento do exercício fiscal em que o relacionamento terminou, e não da data de um formulário específico. Escolha um por tipo de formulário e escreva o gatilho ao lado do número. Quase toda discussão sobre retenção é, na verdade, uma discussão sobre o relógio. ## Um prazo por formulário é melhor que um prazo por empresa Uma regra global única acaba sendo curta demais para os registros de que você precisa ou longa demais para os de que não precisa. Pontos de partida razoáveis: solicitações gerais que nunca converteram, doze meses. Pedidos de orçamento, doze a vinte e quatro meses, porque clientes voltam. Candidaturas de emprego, seis a doze meses, salvo se a pessoa concordar em ficar no banco. Tickets de suporte, vinte e quatro meses, porque são seu histórico do que deu errado. Cadastros de newsletter, até o descadastro, mais um registro de supressão mantido indefinidamente, porque você precisa lembrar de não escrever para aquela pessoa. Registros de clientes e financeiros seguem o que a legislação fiscal exigir, e essa exigência se sobrepõe à sua preferência nos dois sentidos. ## As cópias que você vai esquecer Excluir o envio da ferramenta de formulários é a parte que todo mundo lembra. As cópias são a parte que reprova em uma auditoria. Notificações por e-mail que incluíam o corpo completo do envio estão na caixa de cada destinatário, no celular dele e no arquivo que o provedor de e-mail mantiver. É o vazamento mais comum de longe, e é por isso que e-mails de notificação deveriam dizer "chegou uma nova solicitação" com um link, em vez de reproduzir as respostas. Exportações em CSV vivem em notebooks e drives compartilhados sem prazo de validade. Cada exportação é uma cópia nova fora do seu sistema de retenção, envelhecendo por conta própria. Arquivos enviados costumam ficar guardados separados do registro que aponta para eles. Excluir um envio pode deixar um currículo órfão no armazenamento de objetos por tempo indeterminado. Backups mantêm os dados após a exclusão por design. Isso normalmente é aceitável se os backups rotacionam em um ciclo conhecido e nunca são usados para consultas. Anote o ciclo, porque "excluímos mediante solicitação" e "nossos backups guardam por 90 dias" precisam ser verdade os dois e ser ditos os dois. ## Anonimize onde excluir faz você perder algo útil Muitas vezes você quer o formato dos dados sem a pessoa. Se excluir um ano de envios, você também apaga sua visão de quais canais geraram solicitações, quais semanas foram fracas e o que as pessoas perguntavam. Remover os identificadores preserva a resposta. Tire nome, e-mail, telefone, IP, texto livre e anexos; mantenha o horário, a origem e as escolhas estruturadas. O registro deixa de ser dado pessoal e continua útil para [analytics de pesquisas](/survey-analytics) e planejamento de volume. Faça isso de propósito. Uma anonimização que se desfaz cruzando duas tabelas não é anonimização. ## Transforme a exclusão em tarefa, não em intenção As políticas que de fato rodam têm três coisas: um responsável com nome, uma data recorrente e um filtro salvo que produz a lista. Trimestral basta para a maioria dos negócios. O responsável abre o filtro, confere se a contagem faz sentido, exclui e anota a data e o número em algum lugar. Essa anotação é a evidência de que a política roda, e leva uns dez minutos quando os dados são estruturados. Se produzir a lista leva mais que alguns minutos, o problema é o modelo de dados e não a disciplina. Uma caixa de entrada não pode ser filtrada por "último contato antes de X e nunca converteu". Registros estruturados podem. ## Dê às solicitações de exclusão um caminho próprio Independentemente do seu cronograma, pessoas vão pedir que você apague os dados delas. Mande isso para algum lugar que não seja a caixa de entrada de uma pessoa. Um formulário curto com o e-mail que usaram, o que querem remover e uma etapa de confirmação é mais rápido de atender e deixa prova de que você agiu. Nosso [modelo de solicitação de exclusão de dados](/templates/data-deletion-request) é esse formulário. No Instaform um envio vira um registro estruturado com origem, horário e data de último contato, então uma rodada de retenção é um filtro e uma exclusão em massa, não um trabalho de arqueologia. Essa mesma estrutura é o que faz o [pipeline de CRM](/crm-pipeline) funcionar. Retenção é menos um recurso de conformidade do que um efeito colateral de não guardar dados de clientes em um e-mail.