# Auditoria de logs: quando o log vira banco de dados pessoais Guia · UNIFOKAL · 3 de setembro de 2026 · 8 min de leitura · LGPD e compliance Por que logs com IP e ações de usuário são dados pessoais sob a LGPD, como conciliar a guarda do Marco Civil com a minimização e quais práticas protegem sua trilha de auditoria. Pergunte a um time de engenharia onde vivem os dados pessoais da empresa e a resposta quase sempre aponta para o banco de produção, talvez para a base de análise. Raramente alguém aponta para os logs. No entanto, o log de aplicação médio registra endereço IP (Internet Protocol), identificador de conta, e-mail embutido em parâmetro de requisição e cada ação do usuário com data e hora. Linha por linha, ele fala sobre pessoas. A Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) define dado pessoal no art. 5º, inciso I, como informação relacionada a pessoa natural identificada ou identificável. A definição não exige nome nem CPF (Cadastro de Pessoas Físicas) no registro: basta que a informação, sozinha ou combinada com outras, permita chegar a alguém. Sob essa régua, o arquivo de log que a sua aplicação escreve todos os dias já é um banco de dados pessoais. A diferença é que ele quase nunca aparece no inventário de tratamento, não tem dono definido, não tem prazo de descarte e costuma ser legível por qualquer pessoa com acesso ao servidor. Este texto é para quem constrói ou audita sistemas que registram eventos: engenharia, segurança da informação e o encarregado de proteção de dados. O objetivo é sair daqui sabendo classificar os próprios logs, resolver o aparente conflito entre guarda obrigatória e minimização, e reconhecer os vazamentos que nascem dentro do log antes que uma auditoria os encontre. ## Por que o art. 5º da LGPD alcança o seu log O texto legal é curto e vale ler na fonte, no site do [Planalto](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm): > Dado pessoal: informação relacionada a pessoa natural identificada ou identificável (Lei 13.709/2018, art. 5º, I). A palavra decisiva é identificável. Um endereço IP com data e hora não diz o nome de ninguém, mas cruzado com o cadastro do provedor de conexão ele aponta para um assinante. Um identificador interno de conta parece opaco, mas a própria empresa tem a tabela que o liga a um cliente concreto. Pseudônimo não é anonimização: como já mostramos ao tratar de [anonimização e pseudonimização](https://unifokal.com/blog/anonimizacao-e-pseudonimizacao), o dado pseudonimizado continua sendo dado pessoal enquanto a chave de reversão existir em algum lugar. Aplique esse teste ao seu log de aplicação. Se ele guarda IP de origem, identificador de sessão, conta que executou a ação e o que foi feito, ele é um repositório de dados pessoais comportamentais. E repositórios de dados pessoais têm obrigações: base legal, prazo, segurança, resposta ao titular. Nada disso deixa de valer porque o formato é texto puro rotacionado por dia. ## Guarda obrigatória e minimização: o conflito é aparente O contra-argumento clássico é que a lei manda guardar logs. Manda mesmo, e é bom conhecer os artigos exatos. O Marco Civil da Internet (Lei 12.965/2014, disponível no [Planalto](https://www.planalto.gov.br/ccivil_03/_ato2011-2014/2014/lei/l12965.htm)) obriga o provedor de conexão a guardar registros de conexão por 1 ano (art. 13) e o provedor de aplicações a guardar registros de acesso a aplicações por 6 meses (art. 15). A LGPD, por sua vez, reconhece o cumprimento de obrigação legal como base de tratamento no art. 7º, inciso II. Até aqui, nenhuma tensão: guardar o que o Marco Civil manda é tratamento lícito. O conflito aparece quando a obrigação vira álibi. O próprio Marco Civil define registro de acesso a aplicações de forma estreita, no art. 5º, inciso VIII: o conjunto de informações referentes à data e hora de uso de uma determinada aplicação a partir de um determinado endereço IP. É isso que o art. 15 manda guardar por 6 meses. Não é o corpo da requisição, não é o histórico detalhado de navegação, não é o dump de erro com payload completo. Quem justifica um log de tudo para sempre citando o art. 15 está esticando a norma para cobrir dados que ela nunca pediu. A resolução prática é escopo. Guarde o que a lei manda, pelo prazo que a lei manda, no formato que a lei descreve. Todo o resto é tratamento que precisa se sustentar em outra base, tipicamente o legítimo interesse, com prazo próprio e proporcionalidade demonstrável. O detalhe dos prazos e do que conta como registro de conexão e de acesso está destrinchado no nosso guia sobre [guarda de logs no Marco Civil](https://unifokal.com/blog/guarda-de-logs-marco-civil). ## Os vazamentos clássicos nascem dentro do log Auditorias de log costumam encontrar as mesmas três famílias de problema. A primeira é o dado sensível em URL (Uniform Resource Locator). Servidores e proxies registram a linha de requisição por padrão, com a query string completa. Se a aplicação passa CPF, e-mail ou token por parâmetro de URL, esse dado está sendo copiado para o log de acesso de cada camada da infraestrutura, com retenção que ninguém controla. A segunda é o payload completo logado em erro. O tratador de exceção que despeja o corpo da requisição no log para facilitar o diagnóstico transforma cada falha em uma cópia não gerenciada de tudo que o usuário enviou: documento, endereço, foto codificada em base64. O log de erro passa a conter exatamente os dados que o banco principal protege com criptografia e controle de acesso, só que em texto plano. A terceira é o log de depuração ligado em produção. Em sistemas de verificação de identidade o risco é máximo: imagem de documento e dado biométrico transitando por um log de debug esquecido. Dado biométrico é dado sensível pelo art. 5º, inciso II, da LGPD, e um vazamento por essa via tem o mesmo peso de um vazamento do banco principal, como detalhamos no texto sobre [incidente com dado biométrico](https://unifokal.com/blog/incidente-com-dado-biometrico). ## Práticas que se defendem numa auditoria Quatro práticas separam quem trata log como ativo de quem trata como entulho acumulado. 1. **Classes de log com retenção própria.** Separe o registro de acesso do art. 15, com seus 6 meses, do log operacional de diagnóstico, que raramente precisa de mais de 30 a 90 dias, e da trilha de auditoria de negócio, que pode exigir anos. Uma política única de retenção para tudo é sinal de que ninguém pensou no assunto. 1. **Mascaramento na origem, não depois.** O dado que não entra no log não vaza pelo log. Filtros de campo no próprio logger, com CPF truncado, token omitido e corpo de requisição bloqueado por padrão, valem mais do que qualquer varredura posterior, porque a varredura chega depois que a cópia já se espalhou por agregadores e backups. 1. **Log como ativo, com trilha do próprio acesso.** A LGPD exige, no art. 46, medidas de segurança aptas a proteger os dados pessoais de acessos não autorizados. Para logs, isso significa controle de acesso restrito e um princípio que surpreende quem nunca pensou nele: quem consultou o log também é evento auditável. A norma internacional de gestão de segurança da informação ISO/IEC 27001 (da International Organization for Standardization com a International Electrotechnical Commission) segue a mesma linha ao tratar o registro de eventos e a proteção da informação de log como objeto de controle específico. 1. **Logs no inventário e no plano de incidente.** Se o mapa de tratamento de dados da empresa não lista os logs, ele está incompleto. E o plano de resposta a incidente precisa prever o cenário em que a fonte do vazamento é o próprio log, porque a resposta, que passa por identificar titulares afetados e medir a extensão, depende de saber o que havia lá dentro. ## Sinal de maturidade: auditoria imutável e separada O estágio mais maduro dessa disciplina é separar fisicamente a trilha de auditoria do log operacional. O log operacional existe para diagnosticar o sistema e pode ser agressivamente minimizado e descartado. A trilha de auditoria existe para provar quem fez o quê e precisa ser imutável: escrita uma vez, sem edição nem deleção, idealmente em armazenamento de escrita única (WORM, write once, read many) ou em tabela sem caminho de atualização. Esse desenho resolve o dilema aparente entre auditabilidade e minimização. Num fornecedor bem desenhado, a trilha de auditoria de ações administrativas registra quem fez o quê, mas os metadados da trilha são desenhados para não carregar dado pessoal da pessoa verificada: a trilha prova a ação do operador sem duplicar o dado do titular. A auditoria fica completa e o log não vira uma segunda cópia do banco de dados pessoais. O teste final é simples de aplicar na sua operação. Escolha um log qualquer e pergunte qual é a base legal dele, qual é o prazo, quem acessa e se ele aparece no inventário. Se alguma resposta for um não sei, você acabou de encontrar um banco de dados pessoais sem dono. ## Fontes citadas - Lei nº 13.709/2018 (Lei Geral de Proteção de Dados), arts. 5º, 7º e 46, texto no site do Planalto - Lei nº 12.965/2014 (Marco Civil da Internet), arts. 5º, 13 e 15, texto no site do Planalto - ISO/IEC 27001, norma internacional de gestão de segurança da informação