Retenção e descarte de dados pessoais: guia prático da LGPD

Abra o banco de dados de um sistema de gestão com dez anos de uso e faça uma pergunta simples: quantos cadastros ali pertencem a pessoas que não compram, não trabalham e não se candidatam a nada na empresa há anos? Na maioria das vezes, ninguém sabe responder. Currículos de processos seletivos encerrados, clientes inativos com CPF e endereço, cópias de documentos anexadas a chamados antigos: tudo continua lá, porque apagar sempre pareceu mais arriscado do que guardar.

Com a LGPD, essa conta inverteu. A lei pede que o dado pessoal seja tratado só enquanto houver finalidade e base legal para isso, e que depois seja eliminado ou anonimizado, salvo as exceções que ela mesma prevê, como o cumprimento de obrigação legal. O problema é que "guardar só pelo tempo necessário" é uma frase de política de privacidade. O sistema precisa transformar essa frase em regra, rotina e registro.

Este texto mostra como fazer isso: o que decidir antes, que funcionalidades o software precisa ter e como lidar com as partes difíceis, como backups, logs e pedidos de exclusão.

Resposta curta: como fazer retenção e descarte de dados pessoais

Se você precisa de um roteiro antes de ler o resto, ele é este:

1. Inventarie que dados pessoais o sistema guarda, onde ficam e para que servem.
2. Defina um prazo de retenção para cada tipo de dado, com o gatilho que inicia a contagem e a justificativa (contrato, obrigação legal, defesa em processo, consentimento).
3. Escolha o destino ao fim do prazo: excluir, anonimizar ou manter com acesso restrito por exigência legal. A diferença entre anonimização e pseudonimização muda o que conta como descarte.
4. Automatize o descarte com rotinas agendadas que aplicam a tabela, em vez de depender de alguém lembrar.
5. Trate backups e logs com prazos próprios, para que o dado excluído não sobreviva indefinidamente em cópias.
6. Crie um fluxo para pedidos do titular, com triagem, verificação de identidade e resposta registrada.
7. Registre tudo: o que foi descartado, quando, por qual regra e por quem.

Se a base de privacidade do sistema ainda não existe, vale começar pelo panorama em LGPD no software: o que o sistema precisa fazer e voltar aqui depois.

Guardar tudo para sempre é um risco

Guardar "porque pode ser útil um dia" gera três problemas.

• Exposição maior em caso de incidente. Um vazamento que inclui quem deixou de ser cliente há muitos anos é maior e mais difícil de justificar.
• Dificuldade para atender o titular. Com dados espalhados em tabelas, anexos e planilhas exportadas, responder "que dados vocês têm sobre mim?" vira um mutirão.
• Falta de justificativa. A LGPD trabalha com finalidade e necessidade. Manter o currículo de um candidato reprovado anos atrás, sem consentimento para banco de talentos, é difícil de defender.

O oposto também é problema: apagar por impulso destrói documentos que a empresa precisa manter para o fisco, a área trabalhista ou a própria defesa. Retenção bem feita é apagar o que deve ser apagado, no momento certo, e guardar o resto com motivo registrado.

Tabela de retenção por tipo de dado

A peça central é uma tabela de retenção: para cada tipo de dado, quanto tempo fica, a partir de quando conta, por que fica e o que acontece no fim. É uma decisão de negócio e jurídica; o software a executa.

Um modelo para começar a discussão, com prazos deixados em aberto de propósito:

Os prazos exatos dependem do segmento, dos contratos e da legislação, e devem ser definidos com o jurídico e o contador. O sistema garante que cada linha vire configuração, não texto que ninguém consulta.

Três perguntas para cada linha

• Qual evento inicia o prazo? Data de cadastro, último pedido e fim do contrato produzem resultados muito diferentes.
• O dado está ligado a algo que precisa ficar? O cliente pode ser anonimizado, mas a nota fiscal emitida para ele precisa continuar íntegra pelo prazo legal. O sistema precisa saber dessas dependências.
• Existe exceção ativa? Um processo judicial em andamento ou uma auditoria podem exigir que o descarte seja suspenso para determinados registros. Isso precisa de uma marca de bloqueio no próprio dado.

Anonimizar, pseudonimizar ou excluir

Ao fim do prazo, há três caminhos, e eles não são equivalentes.

Excluir remove o registro. É o caminho mais simples quando o dado não alimenta nada que precise continuar existindo, como um lead antigo ou um currículo.

Anonimizar remove a possibilidade de identificar a pessoa, mantendo o registro útil para estatística. O pedido de um cliente inativo pode continuar contando no faturamento histórico por região e por produto, sem nome, CPF, e-mail, telefone ou endereço completo. Pela LGPD, dado anonimizado deixa de ser dado pessoal, desde que a anonimização não possa ser revertida com meios razoáveis.

Pseudonimizar troca o identificador por um código, mas a empresa mantém, em separado, a forma de voltar ao original. O dado continua pessoal e sujeito à lei. Não serve como descarte.

O cuidado com a anonimização de verdade

Apagar o nome e deixar data de nascimento, bairro e cargo pode bastar para identificar alguém numa cidade do interior. Anonimizar bem significa olhar a combinação de campos:

• trocar data de nascimento por faixa etária;
• trocar endereço completo por cidade ou região;
• remover campos de texto livre, como observações, onde costuma haver nome, telefone e detalhes pessoais digitados à mão;
• remover ou substituir anexos, que muitas vezes são cópias de documentos.

Anexos são o ponto que mais escapa: a rotina limpa as colunas e deixa o RG digitalizado no armazenamento de arquivos.

Rotinas automáticas de descarte

Descarte manual depende de alguém lembrar, ter tempo e coragem de apagar, e por isso não acontece. O desenho que usamos é uma rotina agendada com estas partes:

• Regras configuráveis. Cada tipo de dado tem seu prazo, gatilho e destino cadastrados numa tela administrativa, não escritos no código. Quando o jurídico revisar um prazo, a mudança não exige nova versão do sistema.
• Rotina periódica. Uma tarefa diária ou semanal seleciona os registros que venceram, respeitando bloqueios e dependências, e aplica o destino definido.
• Modo de simulação. Antes de ativar uma regra nova, a rotina roda em modo de teste e gera um relatório do que seria excluído ou anonimizado. Alguém da área responsável confere antes de liberar.
• Lotes pequenos e retomáveis, para não travar o banco no horário comercial.
• Alerta de falha. Rotina de descarte que falha em silêncio por meses passa a falsa sensação de que está tudo em ordem.

Um cuidado de arquitetura: quanto mais o sistema espalha cópias do mesmo dado (relatórios gerados, exportações, integrações com outros sistemas, ambiente de homologação com cópia da produção), mais pontos a rotina precisa alcançar. Por isso, retenção é uma decisão de arquitetura de software e funciona melhor quando é pensada desde o início, com um mapa de onde cada dado pessoal vive.

E os backups e logs?

O cliente pediu exclusão, o dado saiu da produção, mas continua nos backups dos últimos meses.

Backups

Editar backups para remover um registro específico costuma ser inviável e arriscado: um backup alterado deixa de ser uma cópia confiável. A abordagem mais comum e defensável é outra:

• Definir uma retenção de backups curta e documentada. O dado excluído da produção desaparece das cópias quando elas expiram pelo ciclo normal.
• Restringir o acesso aos backups, com criptografia e poucas pessoas autorizadas.
• Manter uma lista de exclusões pendentes. Se for preciso restaurar um backup antigo, a lista é reaplicada logo após a restauração, para que dados já excluídos não voltem à produção.

Esse último item precisa estar no procedimento de restauração, que por sua vez deveria fazer parte de um plano de recuperação de desastres testado. Sem isso, uma restauração de emergência traz de volta tudo o que a empresa já tinha descartado.

Logs

Logs de aplicação costumam guardar mais dado pessoal do que deveriam: CPF no corpo de requisições, e-mail em mensagens de erro. Três práticas resolvem boa parte:

• Não registrar o que não precisa. Mascarar CPF, e-mail e telefone antes de gravar no log.
• Separar log técnico de trilha de auditoria. O log técnico serve para investigar falhas e pode ter prazo curto. A trilha de auditoria registra quem fez o quê e pode precisar de prazo maior.
• Aplicar retenção também aos logs, com expiração automática na ferramenta de armazenamento.

Pedidos de exclusão do titular na prática

A LGPD garante ao titular, entre outros direitos, o de pedir a eliminação dos dados tratados com base no consentimento e a eliminação de dados desnecessários, excessivos ou tratados em desconformidade com a lei, além de acesso e correção. Mas nem todo pedido de exclusão pode ser atendido integralmente: dados que a empresa precisa manter por obrigação legal ou para exercer direitos em processo podem continuar guardados. O sistema precisa suportar essa nuance.

Um fluxo que funciona:

1. Canal de entrada único. Formulário no site ou e-mail dedicado, que gera um protocolo no sistema, em vez de pedidos soltos na caixa de entrada de alguém.
2. Verificação de identidade. Antes de excluir qualquer coisa, confirmar que quem pede é o titular. Excluir dados a pedido de um terceiro, ou entregá-los a ele, pode configurar um incidente de segurança.
3. Localização dos dados. Uma busca que encontra todos os registros ligados àquela pessoa: cadastro, pedidos, chamados, anexos, integrações. Se essa busca não existe, o atendimento depende de memória.
4. Triagem por regra. Para cada registro, o sistema indica se pode ser excluído, se deve ser anonimizado ou se precisa ficar por obrigação legal, com base na tabela de retenção.
5. Execução e propagação. A exclusão roda no sistema principal e é enviada aos sistemas integrados que receberam o dado, como CRM, ferramenta de e-mail marketing ou plataforma de atendimento.
6. Resposta ao titular. Um retorno claro dizendo o que foi excluído e o que foi mantido, e por quê.

Erros comuns no atendimento

• Excluir o cliente e quebrar a nota fiscal. A exclusão em cascata apaga registros que precisavam ficar. Anonimizar o cadastro preserva o documento fiscal.
• Esquecer os sistemas integrados. O dado sai do ERP e continua na ferramenta de e-mail marketing, que volta a enviar campanhas.
• Responder sem registro. Sem protocolo e histórico, não há como provar que o pedido foi atendido.

Registros que provam o que foi feito

Descartar sem conseguir provar tem pouco valor numa fiscalização. O sistema precisa manter evidências, sem guardar de novo o dado que acabou de apagar.

O registro de descarte deve conter:

• tipo de dado e quantidade de registros afetados;
• regra de retenção aplicada e versão dela;
• data e hora da execução;
• quem executou ou aprovou, no caso de pedidos do titular;
• resultado: excluído, anonimizado, mantido por exceção.

O cuidado é não colocar no registro o nome e o CPF de quem foi excluído. Um identificador interno ou um código do protocolo basta. Esse registro conversa diretamente com a trilha de auditoria do sistema, que também precisa mostrar quem consultou ou exportou dados pessoais antes do descarte.

Checklist para avaliar o seu sistema

• Existe uma tabela de retenção aprovada pelo jurídico para cada tipo de dado pessoal?
• Os prazos estão configurados no sistema ou só escritos num documento?
• Há uma rotina automática de descarte, com alerta em caso de falha?
• A anonimização trata campos de observação e anexos?
• Backups têm prazo definido e um procedimento que reaplica exclusões após restauração?
• Logs mascaram dados pessoais e expiram automaticamente?
• Um pedido de exclusão localiza todos os dados do titular rapidamente?
• Cada descarte gera um registro que pode ser apresentado se for preciso?

Se várias respostas forem "não" ou "não sei", o caminho não é sair apagando. É começar pelo inventário e pela tabela, e só então automatizar.

Perguntas frequentes

Por quanto tempo a empresa pode guardar dados pessoais de clientes?

Depende da finalidade e da justificativa de cada tipo de dado. A LGPD não fixa um prazo único: o dado pessoal pode ser mantido enquanto houver finalidade e base legal, ou por exceções como obrigação legal e defesa em processo. Os prazos exatos devem ser definidos com o jurídico e o contador e configurados no sistema.

O cliente pode pedir para apagar todos os dados dele?

Pode pedir, mas nem sempre o pedido é atendido integralmente. A LGPD garante a eliminação de dados tratados com base no consentimento e de dados desnecessários ou excessivos, mas a empresa pode manter o que precisa guardar por obrigação legal, como documentos fiscais. A resposta ao titular deve explicar o que foi excluído e o que foi mantido.

Dado anonimizado ainda é considerado dado pessoal pela LGPD?

Não, desde que a anonimização não possa ser revertida com meios razoáveis. Pela LGPD, o dado anonimizado deixa de ser dado pessoal, o que permite manter registros úteis para estatística. Já o dado pseudonimizado, em que a empresa guarda a forma de voltar ao original, continua sendo pessoal e não serve como descarte.

É preciso apagar o dado pessoal também dos backups?

Não necessariamente, porque editar backups costuma ser inviável e arriscado. A abordagem mais defensável é manter uma retenção de backups curta e documentada, restringir o acesso às cópias e reaplicar a lista de exclusões pendentes sempre que um backup antigo for restaurado, para que dados já descartados não voltem à produção.

Como a Pervian Tech trabalha privacidade no software

Na Pervian Tech, começamos por um diagnóstico: mapeamos onde os dados pessoais vivem no sistema, inclusive anexos, logs, integrações e cópias fora da produção, e montamos com a sua equipe e o seu jurídico a tabela de retenção. A partir dela, desenhamos as regras configuráveis, a rotina de descarte, o fluxo de atendimento ao titular e os registros de evidência, como parte do trabalho de arquitetura de software. Em sistemas existentes, implementamos por etapas, começando pelos dados de maior risco.

Cada projeto é sob medida, porque a retenção depende do seu segmento, dos seus contratos e de como o seu sistema foi construído. O diagnóstico inicial é gratuito e o investimento é definido sob consulta. Outros textos sobre o tema estão em Segurança e LGPD. Se o seu banco de dados guarda mais do que deveria e ninguém sabe por onde começar, fale com a gente.