Como documentar consentimento válido para campanhas promocionais: guia prático LGPD

Você recebeu uma notificação de reclamação no provedor de e-mail: um destinatário alega nunca ter autorizado suas campanhas promocionais. Sua equipe abre o CRM e encontra apenas um campo “optin=true” sem data, IP, versão do termo ou prova de que a caixa não estava pré-marcada. Agora, como demonstrar à ANPD ou ao conselho de autorregulamentação que o consentimento é válido?

A documentação de consentimento não é burocracia — é ativo de defesa. O Artigo 7º da LGPD exige consentimento livre, informado e inequívoco, e o Artigo 8º do Código de Autorregulamentação da ABEMD determina que o remetente deve “manter registro comprobatório da autorização”. Sem evidências técnicas robustas, sua base passa de ativo para passivo jurídico.

Este guia mostra o que registrar, como armazenar com integridade e como recuperar a prova em minutos, não dias.

O que a LGPD e o Código de Autorregulamentação exigem na prática

A lei não prescreve formato de banco de dados, mas estabelece requisitos funcionais: o titular deve saber para que concorda, quem usa os dados, como revogar e por quanto tempo a autorização vale. O Código de Autorregulamentação complementa exigindo registro de data, hora, IP e versão do termo.

Na prática, isso significa que cada linha de consentimento no seu banco deve conter, no mínimo:

1. Identificador único do titular (e-mail hash ou ID)
2. Timestamp com fuso horário (ISO 8601)
3. Endereço IP de origem
4. User agent do navegador/app
5. Versão do termo de consentimento (ex.: v2.3-2024-01-15)
6. Hash do conteúdo aceito (SHA-256) para provar imutabilidade
7. Canal de coleta (site, app, ponto de venda, telefone)
8. Granularidade: flags booleanas por finalidade (promo, newsletter, pesquisa, terceiros)
9. Status atual: ativo, revogado, expirado
10. Data da última alteração de status

A ausência de qualquer item enfraquece a prova. Um campo “optin=true” isolado não resiste a questionamento.

Estrutura de formulário que gera evidência automática

O formulário de coleta é a fábrica da prova. Erros aqui propagam-se para toda a base.

• Checkbox não pré-marcado para cada finalidade distinta. Texto ao lado: “Autorizo receber ofertas promocionais da Empresa X por e-mail.”
• Link direto para a política de privacidade e para o termo de consentimento na versão vigente.
• Botão de envio rotulado “Confirmar autorização” — não “Cadastrar” ou “Enviar”.
• Campos ocultos preenchidos via JavaScript no submit: timestamp, timezone, ip (via API server-side), user_agent, term_version, term_hash.
• Validação server-side rejeita submissão se checkbox estiver vazio ou se term_hash não conferir com a versão atual.

Exemplo de payload JSON armazenado no log de auditoria:

{
  "event": "consent_given",
  "subject_id": "sha256:email@dominio.com",
  "timestamp": "2024-03-15T14:32:11-03:00",
  "ip": "203.0.113.45",
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
  "term_version": "v3.1-2024-01-10",
  "term_hash": "a1f5e8c3...",
  "channel": "website_checkout",
  "purposes": {
    "promocional": true,
    "newsletter": false,
    "pesquisa": true,
    "terceiros": false
  },
  "status": "active"
}

Double opt-in: camada extra de segurança e entregabilidade

Embora não seja obrigatório por lei, o double opt-in é recomendado pelo Código de Autorregulamentação e pela ANPD. Funciona assim:

1. Usuário preenche formulário e clica “Confirmar autorização”.
2. Sistema grava log com status pending_confirmation e envia e-mail com link único (token JWT com expiração 24h).
3. Usuário clica no link → sistema valida token, altera status para active e grava novo log confirmation_completed com novo timestamp, IP e user agent.
4. Se token expirar ou não for usado em 24h, status vira expired e o registro não entra na base de envio.

Benefícios comprovados: redução de hard bounces em 30-50%, eliminação de typos (ex.: “gamil.com”), prova reforçada de intenção e alinhamento com boas práticas internacionais (GDPR, CASL).

Armazenamento imutável e trilha de auditoria

Logs de consentimento não podem ser editáveis. Use estratégias append-only:

• Banco de dados: tabela consent_audit sem UPDATE/DELETE permitidos para a aplicação; apenas INSERT.
• Hash encadeado: cada linha inclui previous_hash (hash da linha anterior), criando cadeia estilo blockchain.
• Backup WORM (Write Once Read Many) em storage objeto com Object Lock (AWS S3, Azure Blob, GCS).
• Replicação em região diferente para disaster recovery.

Tabela de referência para arquitetura de logs:

Portal de preferências: transparência e revogação fácil

O Artigo 18 da LGPD garante ao titular revogar consentimento a qualquer momento, com a mesma facilidade com que o deu. O portal de preferências atende a esse requisito e reduz reclamações de spam.

Funcionalidades mínimas:

• Login via link mágico (magic link) enviado para o e-mail cadastrado — sem senha.
• Lista de finalidades com toggles on/off por finalidade (granularidade).
• Botão “Revogar todos” com confirmação em duas etapas.
• Histórico visual: “Você autorizou promoções em 15/03/2024 às 14:32 via site.”
• Geração de PDF com todo o histórico para o titular baixar.
• Sincronização em tempo real com a base de supressão (suppression list) da plataforma de envio.

Integre o portal ao fluxo de descadastro obrigatório: todo opt-out via link no rodapé do e-mail deve redirecionar para o portal pré-logado, não para página genérica.

Gestão de versões de termo e migração de base legada

Termos de consentimento evoluem: nova finalidade, mudança de controlador, adequação a orientação da ANPD. Cada versão recebe número semântico (v2.0, v2.1, v3.0) e hash.

Regra de ouro: consentimento dado na v2.0 não cobre v3.0 se houver mudança de finalidade ou controlador. Nesses casos, campanha de reconsentimento é obrigatória.

Passos para migração segura:

1. Mapear todas as versões históricas e seus hashes.
2. Classificar alterações: cosméticas (texto, formatação) vs. substanciais (finalidade, controlador, compartilhamento).
3. Para alterações cosméticas: manter consentimento válido, apenas atualizar term_version no próximo login do titular no portal.
4. Para alterações substanciais: disparar e-mail de reconsentimento com link para novo termo, prazo de 30 dias. Quem não responder → status expired e supressão da base ativa.
5. Documentar decisão jurídica de cada classificação em ata assinada pelo DPO.

Bases legadas (coletadas antes da LGPD ou sem logs completos) devem passar por auditoria de legitimidade: amostragem estatística, contato ativo para reconfirmação e, se taxa de resposta for baixa, descarte da base.

Resposta a incidentes: exportando prova em 48 horas

Quando a reclamação chega — seja via canal de atendimento, provedor de e-mail (FBL), ANPD ou Procon —, o SLA interno deve ser: prova exportada em até 48 horas.

Playbook de resposta:

1. Receber ticket com e-mail do reclamante.
2. Buscar subject_id (hash do e-mail) na consent_audit.
3. Filtrar eventos consent_given, confirmation_completed, revocation ordenados por data.
4. Gerar relatório PDF assinado digitalmente (ICP-Brasil) contendo:
   • Linha do tempo completa
   • Hashes de integridade verificados
   • Captura de tela do formulário na versão original (armazenada no Object Lock)
   • Status atual da base (ativo/suprimido)
5. Enviar ao solicitante e anexar ao ticket.

Automatize com stored procedure ou script serverless que recebe e-mail e devolve PDF assinado. Treine a equipe de suporte conforme checklist de conformidade para não depender de desenvolvedor em momento de crise.

Documentar consentimento válido é engenharia de evidência: cada campo, cada log, cada hash existe para responder “sim, o titular autorizou” com certeza técnica. Implemente o checklist acima, audite sua base atual e elimine lacunas antes que virem passivo. Sua entregabilidade e sua conformidade agradecem.

Checklist prático

Perguntas frequentes