Checklist LGPD para software empresarial: o que seu sistema precisa ter

A ANPD está fiscalizando de verdade

Em 2025, a ANPD aplicou mais de R$ 52 milhões em sanções. Não são multas simbólicas. Empresas de médio porte com sistemas internos mal configurados respondem por boa parte dos incidentes notificados.

A maioria das infrações vem de ausências previsíveis: dados pessoais sem criptografia, consentimento sem registro, ausência de logs. São falhas de implementação, não de legislação obscura.

Este checklist cobre cinco pilares técnicos que todo sistema empresarial precisa implementar. Sem teoria jurídica. Com código e decisões de design de banco.

1. Criptografia de dados pessoais

A LGPD não especifica algoritmo. Mas a ANPD deixou claro que "medidas de segurança apropriadas" incluem criptografia em trânsito e em repouso.

Em trânsito: TLS 1.2 no mínimo, TLS 1.3 preferível. Certificados autoassinados não são aceitáveis para dados pessoais.

Em repouso: AES-256 para campos sensíveis. Não criptografe a tabela inteira. Criptografe campos específicos: CPF, dados bancários, informações de saúde.

CREATE TABLE clientes (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  nome VARCHAR(255) NOT NULL,
  email VARCHAR(255) NOT NULL,
  cpf_encrypted BYTEA NOT NULL,
  cpf_hash VARCHAR(64) NOT NULL,
  dados_bancarios_encrypted BYTEA,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_clientes_cpf_hash ON clientes(cpf_hash);

O campo cpf_hash resolve o problema de buscar por CPF sem descriptografar todas as linhas. Use SHA-256 com salt fixo por tenant para o hash de busca, e AES-256-GCM para o campo criptografado.

Checklist de criptografia

• TLS 1.2+ em todas as conexões com dados pessoais
• AES-256-GCM para dados sensíveis em repouso
• Chaves em vault (HashiCorp Vault, AWS KMS, Azure Key Vault), nunca no código
• Rotação de chaves com periodicidade definida (mínimo anual)
• Senhas com bcrypt ou Argon2id, nunca MD5 ou SHA simples
• Backups também criptografados

2. Gestão de consentimento

A LGPD exige consentimento "livre, informado, inequívoco e para finalidade determinada" (Art. 8º). Para o sistema: registrar o que foi consentido, quando, e permitir revogação a qualquer momento.

CREATE TABLE consent_records (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id),
  purpose VARCHAR(100) NOT NULL,
  legal_basis VARCHAR(50) NOT NULL,
  granted BOOLEAN NOT NULL,
  ip_address INET,
  user_agent TEXT,
  consent_text_version VARCHAR(20) NOT NULL,
  granted_at TIMESTAMPTZ DEFAULT now(),
  revoked_at TIMESTAMPTZ
);

Erro comum: usar um campo booleano aceite_lgpd na tabela de usuários. Isso não diferencia finalidades e não mantém histórico. Outro erro: não versionar o texto de consentimento. Se o texto muda, você precisa saber qual versão o usuário aceitou.

Checklist de consentimento

• Consentimento granular por finalidade (não um checkbox único)
• Registro de IP, timestamp e versão do texto aceito
• Revogação acessível ao titular (não escondida em 5 níveis de menu)
• Histórico imutável (append-only, sem UPDATE/DELETE)
• Re-consentimento automático quando o texto de finalidade muda

3. Requisitos técnicos do DPO

A LGPD exige que o controlador indique um Encarregado de Proteção de Dados (DPO). Do ponto de vista do sistema, o DPO precisa de ferramentas concretas.

Painel de dados pessoais: quais dados o sistema armazena, por categoria de titular, com base legal associada. Não é um documento Word. É uma tela no sistema que reflete o estado real do banco.

Portal de direitos do titular: endpoints para que o titular exerça seus direitos previstos no Art. 18.

GET  /api/v1/titular/meus-dados           -- Acesso (Art. 18, II)
PUT  /api/v1/titular/corrigir              -- Correção (Art. 18, III)
POST /api/v1/titular/solicitar-exclusao    -- Eliminação (Art. 18, VI)
GET  /api/v1/titular/exportar              -- Portabilidade (Art. 18, V)
POST /api/v1/titular/revogar-consentimento -- Revogação (Art. 18, IX)

Checklist do DPO

• Identidade e contato do DPO publicados no site e no sistema
• Painel de inventário de dados pessoais acessível ao DPO
• Portal de direitos do titular com workflow e SLA
• Capacidade de gerar RIPD com dados extraídos do sistema

4. Notificação de incidentes

A Resolução CD/ANPD nº 15/2024 fixou o prazo de comunicação em 3 dias úteis após a detecção de incidente com risco ao titular. Três dias. Sem monitoramento, você descobre o vazamento pelo Twitter e perde o prazo.

CREATE TABLE access_logs (
  id BIGSERIAL PRIMARY KEY,
  user_id UUID NOT NULL,
  action VARCHAR(50) NOT NULL,
  resource_type VARCHAR(50) NOT NULL,
  resource_id UUID,
  records_affected INTEGER DEFAULT 1,
  ip_address INET NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

Se um usuário que normalmente acessa 10 registros por dia de repente consulta 5.000, algo está errado. Regras simples de detecção pegam a maioria dos incidentes.

Checklist de notificação

• Monitoramento de acesso anômalo (volume atípico, horários fora do padrão)
• Alertas automáticos para tentativas de acesso não autorizado
• Detecção de exfiltração (downloads em massa de dados pessoais)
• Plano de resposta a incidentes documentado, com responsáveis e prazos
• Template de notificação à ANPD pré-preenchido
• Simulação de incidente realizada ao menos uma vez ao ano

5. Trilha de auditoria

A trilha de auditoria prova que você fez tudo certo. Sem ela, qualquer afirmação de conformidade vira palavra contra palavra.

O princípio: toda operação sobre dado pessoal gera um registro imutável.

CREATE TABLE audit_trail (
  id BIGSERIAL PRIMARY KEY,
  event_type VARCHAR(30) NOT NULL,
  entity_type VARCHAR(50) NOT NULL,
  entity_id UUID NOT NULL,
  user_id UUID NOT NULL,
  changes JSONB,
  ip_address INET,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Append-only: sem UPDATE, sem DELETE
-- Particionar por mês para performance
CREATE INDEX idx_audit_entity ON audit_trail(entity_type, entity_id);
CREATE INDEX idx_audit_user ON audit_trail(user_id, created_at);

O campo changes armazena o diff em JSONB, não o estado completo. Mascare valores sensíveis: o campo "old" do CPF deve ser ***456.789-00, não o valor completo. A trilha prova que houve alteração sem expor o dado.

A LGPD não define prazo de retenção para logs. A expectativa da ANPD em fiscalizações é mínimo de 5 anos. Configure particionamento e arquivamento em cold storage após 12 meses.

Checklist de auditoria

• Toda operação CRUD sobre dados pessoais gera registro
• Trilha append-only (sem alteração ou exclusão)
• Valores sensíveis mascarados nos logs
• Retenção mínima de 5 anos
• Consulta de trilha disponível para o DPO
• Particionamento implementado para manter performance

Resumo

Pilar	Requisitos principais	Risco se ausente
Criptografia	TLS 1.2+, AES-256, vault	Multa + vazamento
Consentimento	Granular, versionado, revogável	Nulidade do tratamento
DPO	Painel, portal de direitos, RIPD	Sanção administrativa
Incidentes	Detecção, plano, notificação 3 dias	Multa agravada
Auditoria	Append-only, mascaramento, 5 anos	Impossibilidade de defesa

Comece pela trilha de auditoria, que demora para gerar valor retroativo, e pelo inventário de dados pessoais, que é o primeiro item solicitado pela ANPD em qualquer fiscalização.

Próximo passo

A Bradata implementa esses controles em todos os sistemas que desenvolve. Se o seu software empresarial precisa de adequação técnica à LGPD, ou se você está construindo um sistema novo e quer começar certo, fale com a nossa equipe.