Programas de LGPD normalmente começam com políticas, planilhas e questionários jurídicos. A parte mais difícil é técnica: onde estão os dados pessoais, quem consegue acessá-los, por quanto tempo eles sobrevivem e o que prova que os controles funcionam? Um diagnóstico de banco transforma essas perguntas em evidências, prioridades e plano de implementação.
O que um diagnóstico técnico de LGPD entrega
O diagnóstico não substitui a orientação jurídica nem a decisão do controlador sobre base legal. Ele produz a evidência técnica que DPO, privacidade, segurança e donos de sistemas precisam para tomar essas decisões e implementá-las de forma consistente.
- Mapa de dados: bancos, schemas, tabelas, colunas, arquivos, ETLs, réplicas, cópias analíticas e exports que podem conter dados pessoais ou sensíveis.
- Mapa de acesso: usuários humanos, identidades de aplicações, contas de serviço, roles privilegiadas, credenciais compartilhadas e caminhos de acesso à produção.
- Mapa de ciclo de vida: coleta, replicação, backup, retenção, arquivamento, exclusão, teste de restore e descarte.
- Registro de riscos: achados por impacto, probabilidade, responsável, controle proposto, dependências e evidência de validação.
- Roadmap de remediação: reduções rápidas de risco, mudanças estruturais e controles que exigem participação de produto, segurança, jurídico ou fornecedor.
Fase 1: escopo e responsáveis
Começamos identificando sistemas que tratam dados pessoais e quem responde por eles. Isso inclui banco de produção, réplicas de leitura, warehouse de relatórios, cópias de homologação, refreshes de desenvolvimento, ETLs, exports, object storage e repositórios de backup. O banco primário quase nunca é a única cópia do registro.
Para cada sistema, o cliente identifica dono de negócio, dono técnico, ambiente, classificação de dados, criticidade, fronteira de cloud/fornecedor e participação em solicitações do titular. Isso evita o erro recorrente de proteger a produção enquanto um extract noturno para analytics continua amplamente acessível.
Fase 2: descoberta e classificação com evidências
Nome de coluna é sinal, não prova. A descoberta disciplinada combina inspeção de schema, amostragem autorizada, conhecimento da aplicação, comentários de banco, metadados de ETL e relatórios. Procuramos identificadores diretos como CPF, e-mail, telefone, endereço, identificadores de conta, credenciais e atributos que se tornam identificáveis quando combinados.
-- PostgreSQL: inventário de objetos antes da classificação
SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name, ordinal_position;A classificação é validada com donos dos sistemas e registrada em inventário governado; não fica dependente de inferência eterna por palavras-chave. Para dados sensíveis, financeiros, credenciais e registros regulados, documentamos expectativas adicionais de acesso, criptografia, logging e retenção.
Fase 3: controles em todo o caminho do dado
Conformidade não é checkbox de uma tabela. Avaliamos controles em repouso, em trânsito e durante a operação:
- Desenho de roles, menor privilégio, acessos privilegiados, break-glass, contas antigas e credenciais compartilhadas.
- TLS para clientes e replicação, armazenamento de secrets, rotação de certificados e segmentação de rede.
- Criptografia, propriedade de chaves e proteção equivalente para backups, exports, WAL/archive logs e snapshots.
- Auditabilidade de DDL, acesso privilegiado, exports, falhas de login e mudanças de acesso ou retenção.
- Masking, minimização ou dados sintéticos para refresh de ambientes não produtivos.
Fase 4: remediação utilizável
Achados viram ações com responsável e critério de evidência. Exemplos prioritários: exposição pública de rede, credencial DBA compartilhada, backup sem proteção adequada, restore irrestrito em desenvolvimento, trilha de auditoria desabilitada, usuários órfãos e fluxos de ETL ou replicação que contornam os controles definidos.
Limite importante: o controlador e seus DPO/jurídico definem base legal, avisos de privacidade, obrigação de retenção e política de resposta. A consultoria técnica traduz obrigações aprovadas em controles de banco, valida a implementação e produz evidências.
Como João Victor Oliveira pode ajudar
João Victor Oliveira é Senior Database Administrator com mais de 13 anos em ambientes críticos de instituições financeiras, setor público, cloud e empresas. Sua experiência inclui PostgreSQL, MySQL/MariaDB, Oracle, SQL Server, AWS RDS, Azure, migrações, alta disponibilidade, backup/recovery, monitoramento e performance. A consultoria combina essa vivência operacional com uma abordagem prática para melhorar controles sem paralisar o sistema.