LGPD e CPF: Guia Prático para Desenvolvedores

A LGPD (Lei nº 13.709/2018) classifica o CPF como dado pessoal. Para o desenvolvedor, isso tem implicações práticas em como coletar, armazenar, processar, registrar em logs e excluir esse dado. Este guia traduz os artigos da lei em decisões técnicas.

CPF como dado pessoal

O artigo 5º, inciso I da LGPD define dado pessoal como “informação relacionada a pessoa natural identificada ou identificável”. O CPF identifica diretamente uma pessoa, pois é o identificador fiscal único atribuído pela Receita Federal.

Consequência prática: toda operação com CPF está sujeita à LGPD, incluindo coleta, armazenamento, consulta, compartilhamento, transferência e exclusão.

Bases legais para tratar CPF

Você precisa de uma base legal (art. 7º) para processar CPFs. As mais comuns para desenvolvedores:

A base legal não é uma escolha livre, depende do contexto. Se a lei exige o CPF (ex: emissão de nota fiscal), a base é obrigação legal, não consentimento.

Minimização de dados

O artigo 6º, inciso III exige que os dados sejam “adequados, pertinentes e limitados ao mínimo necessário”.

Na prática:

• Não peça CPF se não precisa: formulário de contato não precisa de CPF; cadastro para emissão de nota fiscal precisa
• Não armazene se não vai usar: se o CPF serve apenas para autenticação, armazene um HMAC, não o número completo
• Não replique em múltiplos sistemas: centralize o CPF em um serviço e distribua tokens ou identificadores internos para os demais

Armazenamento seguro

O artigo 46 exige “medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais”. Para CPF, isso significa:

1. Nunca em texto plano: use HMAC ou AES-256
2. Tipo de coluna correto: CHAR(11), não BIGINT
3. Chaves em KMS: não no código-fonte ou variáveis de ambiente em repositórios
4. Acesso restrito: apenas os serviços que precisam acessam a tabela com CPFs

CPF em logs

Logs de aplicação frequentemente contêm CPF acidentalmente: em payloads de requisição, mensagens de erro, ou logs de debug. Isso é um problema porque:

• Logs geralmente têm retenção longa (30 a 90 dias ou mais)
• Equipes inteiras têm acesso a ferramentas de log (Datadog, CloudWatch, ELK)
• Logs são exportados para sistemas de terceiros sem controle de acesso granular

Como evitar

Filtro no logger:

function sanitizeLog(data) {
  const cpfPattern = /\d{3}\.?\d{3}\.?\d{3}-?\d{2}/g;
  return JSON.stringify(data).replace(cpfPattern, "***CPF***");
}

logger.info(sanitizeLog({ user: "João", cpf: "529.982.247-25" }));
// {"user":"João","cpf":"***CPF***"}

Middleware de sanitização:

function sanitizeRequest(req, res, next) {
  if (req.body?.cpf) {
    req.sanitizedBody = { ...req.body, cpf: "***" };
  }
  next();
}

// Logar req.sanitizedBody, não req.body

Campo explícito no ORM:

class Pessoa:
    cpf_hmac: str  # indexável, logável
    cpf_enc: str   # nunca vai para log

    def __repr__(self):
        return f"Pessoa(cpf=***)"  # impede leak em logs/debug

Regra prática

Se o campo se chama cpf, documento, ou cpf_number, não deve aparecer em logs. Configure filtros globais no logger para mascarar esses campos automaticamente.

Anonimização e pseudonimização

A LGPD distingue dois conceitos (art. 5º, III e art. 13, §4º):

Anonimização

Dado anonimizado não é dado pessoal e sai do escopo da LGPD. Mas para CPF, a anonimização real é difícil:

• Trocar por hash (SHA-256)? Reversível em minutos, o keyspace é pequeno
• Trocar por HMAC? Se você tem a chave, é pseudonimização, não anonimização
• Trocar por token sem mapeamento reverso? Agora sim é anônimo, mas você perdeu o vínculo com o titular

Quando usar: relatórios agregados, datasets de treinamento de ML, análises estatísticas onde o CPF individual é irrelevante.

-- Anonimizar para relatório: substituir por NULL
SELECT
    estado,
    COUNT(*) AS total_cadastros
FROM pessoas
GROUP BY estado;
-- CPF nunca aparece na query → dado efetivamente anônimo no resultado

Pseudonimização

Mais prática para sistemas em produção: o dado pode ser re-identificado quando necessário, mas está protegido no dia a dia.

• HMAC com chave separada → busca por CPF sem expor o número
• Tokenização → serviços usam token em vez de CPF

Ambas as técnicas estão detalhadas em como armazenar CPF com segurança.

Direito à exclusão

O artigo 18, inciso VI garante ao titular o direito de “eliminação dos dados pessoais tratados com o consentimento do titular”. Na prática:

1. Mapeie onde o CPF está: banco principal, backups, logs, caches, serviços de terceiros
2. Implemente exclusão real: DELETE no banco, não soft delete (ou garanta que o soft delete não expõe o CPF)
3. Logs: se o CPF está em logs, a sanitização preventiva evita o problema. Se já está registrado, a retenção do log determina quando será eliminado
4. Backups: documente a política de retenção de backups. Se o backup é mantido por 30 dias, o CPF será eliminado em até 30 dias após a exclusão no banco

async function deletePessoa(id) {
  // 1. Excluir do banco principal
  await db.query("DELETE FROM pessoas WHERE id = $1", [id]);

  // 2. Invalidar cache
  await cache.del(`pessoa:${id}`);

  // 3. Registrar a exclusão (sem o CPF)
  logger.info(`Pessoa ${id} excluída a pedido do titular`);
}

Incidentes de segurança

O artigo 48 exige que o controlador comunique à ANPD “a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante aos titulares”. Se CPFs vazarem:

1. Comunique a ANPD em prazo razoável (a lei não define prazo exato)
2. Comunique os titulares se houver risco relevante
3. Documente o incidente: o que vazou, quantos registros, medidas tomadas

Se os CPFs estavam criptografados (AES-256) e a chave não vazou, o risco real é baixo, pois o dado cifrado é inútil sem a chave. Isso não elimina a obrigação de comunicar, mas demonstra medidas técnicas adequadas.

Checklist para o desenvolvedor

1. Base legal definida: saiba por que você processa CPFs
2. Minimização: não colete CPF se não precisa
3. Criptografia: HMAC + AES-256 no banco
4. Tipo de coluna: CHAR(11), nunca BIGINT
5. Logs limpos: filtro global para mascarar CPF
6. Exclusão implementada: rota ou processo para deletar dados do titular
7. Backups documentados: política de retenção clara
8. Terceiros mapeados: saiba quais serviços recebem CPFs

Para ambientes de desenvolvimento e testes, use o gerador de CPF em vez de dados reais. CPFs gerados pelo algoritmo de módulo 11 são válidos matematicamente, mas não pertencem a ninguém.

Veja também: como armazenar CPF com segurança e validar CPF no cadastro.