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

> Quanto tempo guardar cada dado pessoal e como apagar sem perder o que a lei exige: tabela de prazos, anonimização, backups, logs e pedidos do titular.

Fonte: https://pervian.tech/blog/retencao-e-descarte-de-dados-pessoais · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/anonimizacao-ou-pseudonimizacao) 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](https://pervian.tech/blog/lgpd-no-desenvolvimento-de-sistemas) 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](https://pervian.tech/blog/portal-de-vagas-e-recrutamento), é 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:

| Tipo de dado | Gatilho da contagem | Justificativa típica | Destino ao fim do prazo |
|---|---|---|---|
| Cadastro de cliente ativo | Enquanto houver relação | Execução de contrato | Não se aplica enquanto ativo |
| Cadastro de cliente inativo | Última compra ou fim do contrato | Defesa em eventual disputa | Anonimizar |
| Documentos fiscais vinculados à venda | Emissão da nota | Obrigação legal | Manter pelo prazo legal, depois excluir |
| Dados de funcionário desligado | Data do desligamento | Obrigações trabalhistas e previdenciárias | Manter o exigido, excluir o restante |
| Currículo de candidato não contratado | Encerramento da vaga | Processo seletivo | Excluir, salvo consentimento para banco de talentos |
| Lead que nunca virou cliente | Último contato | Interesse comercial ou consentimento | Excluir |
| Imagens de câmera e [registros de portaria](https://pervian.tech/blog/app-para-condominio) | Data da gravação | Segurança patrimonial | Excluir |
| Logs de acesso ao sistema | Data do evento | Segurança, auditoria e, em aplicações na internet, o Marco Civil da Internet | Excluir ou agregar após o prazo mínimo |

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](https://pervian.tech/blog/automatizar-coleta-de-documentos-de-clientes).

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](https://pervian.tech/blog/ambientes-de-homologacao-e-producao)), mais pontos a rotina precisa alcançar. Por isso, retenção é uma decisão de [arquitetura de software](https://pervian.tech/servicos/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](https://pervian.tech/blog/plano-de-recuperacao-de-desastres-para-sistemas) 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](https://pervian.tech/blog/sincronizacao-de-cadastros-entre-sistemas) 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](https://pervian.tech/blog/controle-de-acesso-e-trilha-de-auditoria), 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](https://pervian.tech/servicos/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](https://pervian.tech/blog/categoria/seguranca-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](https://pervian.tech/#contato).