Retenção, descarte e gestão de evidências de eliminação

O que é retenção, descarte e gestão de evidências de eliminação

Retenção é a prática de manter dados (pessoais ou não) e registros associados por um período definido, com finalidade específica e critérios objetivos. Descarte é o conjunto de ações para eliminar dados de forma segura ao final do prazo de retenção ou quando a finalidade se encerra. Gestão de evidências de eliminação é a capacidade de demonstrar, por meio de registros verificáveis, que o descarte ocorreu de maneira íntegra, rastreável e compatível com requisitos legais, contratuais e de segurança.

Na prática, esses três elementos formam um controle organizacional e técnico: (1) definir por quanto tempo manter, (2) executar a eliminação com método adequado ao risco e ao tipo de mídia, e (3) registrar a eliminação de modo auditável. O objetivo é reduzir exposição a incidentes, evitar armazenamento indefinido e sustentar prestação de contas quando houver auditoria, fiscalização, litígio, investigação interna ou solicitações de titulares.

Por que isso é um controle crítico

• Redução de superfície de ataque: quanto menos dados acumulados, menor o impacto potencial de vazamentos e menor o custo de resposta a incidentes.
• Consistência operacional: prazos claros evitam decisões ad hoc e conflitos entre áreas (jurídico, TI, negócio, compliance).
• Previsibilidade de custos: retenção controlada reduz custos de armazenamento, backup, eDiscovery e governança.
• Auditabilidade: evidências de eliminação evitam disputas sobre “apagamos ou não apagamos” e permitem demonstrar diligência.

Escopo: o que entra em retenção e descarte

Uma política eficaz cobre dados em diferentes camadas e formatos, porque o “dado” raramente está em um único lugar. Exemplos comuns:

• Bases transacionais: cadastros, pedidos, faturamento, tickets, logs de atendimento.
• Documentos e anexos: PDFs, imagens, contratos, comprovantes, gravações.
• Mensageria e colaboração: e-mails, chats corporativos, comentários em ferramentas internas.
• Logs e telemetria: logs de acesso, logs de aplicação, trilhas de auditoria, SIEM.
• Backups e réplicas: cópias de segurança, snapshots, DR, replicações.
• Ambientes de teste e desenvolvimento: dumps, cópias de produção, dados mascarados ou não.
• Dispositivos e mídias: notebooks, celulares, pendrives, fitas, discos, impressões.
• Terceiros: operadores, provedores de nuvem, BPO, call center, bureaus.

O controle deve considerar também metadados e índices (por exemplo, índices de busca, caches, data lakes, catálogos), que podem reter fragmentos de dados mesmo após exclusão na origem.

Definindo prazos de retenção: critérios práticos

Prazos de retenção não devem ser definidos “por costume” ou “para sempre”. Devem ser derivados de requisitos objetivos e documentáveis. Critérios típicos:

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Obrigação legal/regulatória: prazos mínimos para manter determinados registros (ex.: fiscais, trabalhistas, contábeis, setoriais).
• Prescrição e defesa em litígios: retenção para suportar defesa de direitos e cumprimento de obrigações, alinhada a prazos prescricionais aplicáveis.
• Contrato e SLA: exigências contratuais de guarda e disponibilidade de evidências.
• Segurança e auditoria: retenção de logs por período compatível com detecção e investigação (ex.: 6 a 12 meses, conforme risco e capacidade).
• Necessidade operacional: tempo necessário para executar o serviço, conciliações, suporte e garantia.
• Arquivamento histórico (quando aplicável): somente se houver justificativa e controles adicionais (pseudonimização, agregação, acesso restrito).

Um erro comum é aplicar um único prazo para tudo. O adequado é criar uma tabela de retenção por categoria de dados e por sistema, com regras de início do prazo (gatilho) e destino ao final (excluir, anonimizar, arquivar com restrição, ou reter por hold).

Gatilhos de início do prazo (eventos)

O prazo de retenção precisa de um marco inicial claro. Exemplos:

• Data de encerramento do contrato ou término do relacionamento.
• Data de entrega do produto/serviço.
• Data de pagamento/baixa fiscal.
• Data de encerramento do chamado/ticket.
• Data do último acesso (para contas inativas), quando isso fizer sentido operacional.
• Data do evento de segurança (para logs de incidentes).

Sem gatilho, a regra vira ambígua e difícil de automatizar.

Modelos de descarte: exclusão, anonimização e destruição física

Descarte não é sinônimo de “apagar um registro na tela”. O método deve ser compatível com o tipo de dado, a tecnologia e o risco.

Exclusão lógica (aplicacional)

É a remoção do dado em nível de aplicação e banco, com garantia de que não permanecerá acessível por usuários e processos. Requisitos práticos:

• Excluir registros e dependências (tabelas relacionadas, anexos, histórico).
• Tratar caches e índices (ex.: motor de busca interno).
• Evitar “soft delete” indefinido (marcar como deletado sem purgar). Se houver soft delete por necessidade operacional, definir prazo curto para purga definitiva.
• Registrar a operação (quem, quando, o quê, por qual regra).

Anonimização ou agregação

Quando a organização precisa manter valor estatístico/analítico, pode substituir o descarte por anonimização robusta ou agregação, desde que o resultado não permita reidentificação razoável. Na prática, isso exige:

• Remover identificadores diretos (nome, CPF, e-mail) e tratar quasi-identificadores (data de nascimento, CEP, cargo).
• Aplicar técnicas como generalização, supressão, randomização, k-anonimato (com cautela) e validação de risco de reidentificação.
• Separar chaves de ligação (se existirem) com controles fortes; se a chave permitir reversão, não é anonimização.

Exemplo: manter histórico de vendas por faixa de idade e região, sem manter identificadores do cliente, após o prazo operacional.

Destruição criptográfica (crypto-shredding)

Em ambientes com criptografia forte, uma forma eficiente de descarte é destruir chaves de criptografia associadas ao conjunto de dados. Isso é útil em armazenamento em nuvem e data lakes, desde que:

• As chaves sejam gerenciadas de forma segregada (KMS/HSM) e associadas por escopo (por cliente, por dataset, por período).
• Não existam cópias das chaves fora do controle (backups de chaves, exportações).
• Haja evidência de rotação e destruição (logs do KMS, tickets, aprovações).

Destruição física e sanitização de mídia

Para discos, fitas, SSDs e dispositivos, descarte seguro pode exigir sanitização ou destruição física. Boas práticas:

• Aplicar padrões reconhecidos de sanitização (por exemplo, métodos equivalentes a “clear/purge/destroy”).
• Considerar particularidades de SSD (wear leveling pode impedir sobrescrita completa; preferir comandos de secure erase do fabricante, criptografia com destruição de chave, ou destruição física).
• Manter cadeia de custódia quando houver transporte para descarte por fornecedor.
• Emitir certificado de destruição com identificação do ativo, método, data e responsável.

Backups, snapshots e o “apagamento que não apaga”

Um dos pontos mais sensíveis é a presença do dado em backups e réplicas. Mesmo que o dado seja excluído do sistema primário, ele pode permanecer em cópias de segurança por semanas ou meses. A política deve definir como lidar com isso de forma realista e auditável.

Abordagem recomendada

• Definir retenção de backup separada: por exemplo, 30, 60, 90 dias, conforme criticidade e capacidade de recuperação.
• Evitar restaurações parciais que reintroduzam dados expirados: ao restaurar, aplicar rotinas de reconciliação/purga pós-restore.
• Segregar backups por ambiente e por sensibilidade: reduzir cópias desnecessárias de dados pessoais em ambientes não produtivos.
• Criptografar backups: facilita controle e, em alguns casos, descarte por destruição de chave.
• Documentar exceções: se não for tecnicamente viável remover um item específico de um backup, registrar que a eliminação ocorrerá no ciclo natural de expiração do backup, com controles de acesso e uso restrito.

Exemplo prático: um titular solicita eliminação. O dado é removido do sistema principal imediatamente, mas pode permanecer em backups por até 60 dias. A organização registra a solicitação, a execução no primário, e a data prevista de expiração do backup, garantindo que backups não sejam usados para finalidades operacionais e que restaurações acionem rotina de purga.

Legal hold e suspensão de descarte

Há situações em que o descarte deve ser suspenso: auditorias, investigações, litígios, incidentes de segurança, ordens judiciais. Esse mecanismo é conhecido como legal hold (ou hold de retenção). Ele precisa ser controlado para não virar “retenção eterna”.

Elementos de um processo de hold

• Critérios de acionamento: quem pode solicitar (jurídico, compliance, segurança), em quais hipóteses.
• Escopo: quais sistemas, quais tipos de registros, quais períodos.
• Controles: bloqueio de rotinas automáticas de descarte para o escopo definido, com rastreabilidade.
• Revisão periódica: datas de reavaliação e encerramento do hold.
• Registro de evidências: ticket, aprovação, lista de custodians, e logs de aplicação do hold.

Exemplo: após notificação de possível fraude, o jurídico aciona hold para e-mails e logs de acesso de um conjunto de usuários por 180 dias, revisando a cada 60 dias.

Gestão de evidências de eliminação: o que provar e como provar

Evidência de eliminação é a documentação técnica e processual que demonstra que o descarte ocorreu conforme regra e com integridade. O nível de evidência deve ser proporcional ao risco e ao impacto do dado.

O que uma evidência deve conter

• Identificação do item eliminado: dataset, tabela, bucket, pasta, ID de registro, ou lote (batch). Evitar registrar o próprio dado pessoal como “evidência”; preferir identificadores internos, hashes ou contagens.
• Base da eliminação: regra de retenção aplicável (código da regra), solicitação do titular, término de contrato, expiração de prazo.
• Data/hora e fuso: quando a eliminação ocorreu e quando foi solicitada/aprovada.
• Responsável e sistema: usuário técnico/serviço que executou, ambiente, versão do job.
• Método: exclusão lógica, purge, crypto-shredding, sanitização, destruição física.
• Resultado: sucesso/falha, quantidade de registros, logs de execução, checks de pós-condição (ex.: consulta que confirma ausência).
• Exceções: itens em hold, dependências técnicas, retenção em backup até expiração.

Formatos de evidência (exemplos)

• Logs imutáveis: trilhas em SIEM, WORM storage, ou logging com retenção e integridade.
• Relatórios de jobs: saída de rotinas de purge com contagem de registros e IDs de lote.
• Tickets e aprovações: workflow com validação (ex.: gestor do sistema + segurança).
• Certificados de destruição: para mídias e ativos, emitidos por fornecedor com cadeia de custódia.
• Evidência criptográfica: logs do KMS/HSM indicando revogação/destruição de chave, com identificador do dataset.

Um cuidado importante: evidência não deve recriar o risco. Por exemplo, anexar planilhas com dados pessoais “para provar que apagou” é contraproducente. Prefira evidências minimizadas (IDs internos, hashes, contagens, prints de console sem dados sensíveis).

Passo a passo prático para implementar retenção e descarte

1) Inventariar repositórios e fluxos de eliminação

Liste sistemas e locais onde dados e registros são armazenados, incluindo backups e ambientes não produtivos. Para cada repositório, identifique: tipo de armazenamento, capacidade de exclusão/purge, existência de soft delete, e como logs são gerados.

• Planilha ou catálogo com: sistema, dono, tipo de dado, local físico/lógico, método de descarte suportado, limitações.

2) Construir a tabela de retenção (por categoria e por sistema)

Crie regras com: categoria de dado, finalidade operacional, prazo, gatilho, destino ao final, e exceções (hold). Atribua um identificador único para cada regra (ex.: RET-CRM-001).

Exemplo de regra (estrutura sugerida):
- Regra: RET-ATEND-003
- Categoria: gravações de atendimento
- Gatilho: encerramento do ticket
- Retenção: 180 dias
- Destino: exclusão definitiva + expiração em backup (até 60 dias)
- Evidência: log do job + relatório mensal de purge
- Exceções: legal hold por solicitação do jurídico

3) Definir responsabilidades (RACI) e aprovações

Determine quem define regra, quem implementa, quem opera e quem audita. Um modelo comum:

• Negócio (dono do processo): valida necessidade operacional.
• Jurídico/Compliance: valida requisitos legais/contratuais e holds.
• Segurança da Informação: define método seguro e evidências, controla acesso.
• TI/Engenharia: implementa automações e monitora execução.
• Auditoria/Controles internos: testa amostras e verifica evidências.

4) Implementar automação de descarte (preferencialmente por lote)

Automatize para reduzir erro humano e garantir consistência. Padrões práticos:

• Jobs agendados (diário/semanal) que selecionam registros expirados por gatilho e data.
• Processo em duas etapas: marcar para purge e purgar (com janela de reversão curta, se necessário).
• Controle de concorrência e integridade referencial (ordem de exclusão, chaves estrangeiras).
• Rate limiting para não degradar performance.

Exemplo de pseudo-rotina:
1) Selecionar IDs expirados (WHERE data_fim + prazo < hoje)
2) Gerar lote (batch_id) e registrar contagem
3) Excluir dependências (anexos, histórico)
4) Excluir registro principal
5) Validar pós-condição (SELECT por IDs deve retornar 0)
6) Registrar evidência (batch_id, contagem, duração, status)

5) Tratar backups e restaurações

Documente a retenção de backups e implemente controles para evitar reintrodução de dados:

• Procedimento de restore com etapa obrigatória de “purga pós-restore”.
• Registro de restaurações e verificação de conformidade.
• Criptografia e segregação de acesso a backups.

6) Definir e operar o processo de legal hold

Implemente um fluxo formal (ticket/workflow) com escopo, prazo e revisão. Tecnicamente, isso pode significar:

• Desabilitar jobs de purge para determinados registros (flag de hold).
• Bloquear deleções em repositórios específicos.
• Exportar evidências para repositório controlado (quando necessário), com trilha de auditoria.

7) Padronizar evidências e armazená-las com integridade

Defina um “pacote mínimo de evidência” por tipo de descarte. Armazene evidências em local com retenção própria, controle de acesso e proteção contra alteração (imutabilidade quando aplicável).

• Relatórios mensais de purge por sistema (contagens e batch_ids).
• Logs técnicos (SIEM) com retenção definida.
• Certificados de destruição física vinculados ao inventário de ativos.

8) Monitorar, testar e auditar

Sem verificação, a política vira documento. Práticas objetivas:

• KPIs: % de jobs executados no prazo, volume descartado por mês, falhas e reprocessamentos.
• Testes por amostragem: selecionar lotes e confirmar ausência no primário, ausência em índices/caches, e evidência registrada.
• Alertas: falha de job, crescimento anormal de tabelas, retenção acima do esperado.
• Revisão de regras: anual ou quando houver mudança regulatória, contratual ou tecnológica.

Exemplos práticos por cenário

Exemplo 1: CRM com clientes inativos

Cenário: o CRM mantém dados de contato e histórico de interações. Regra: após encerramento do relacionamento e decurso do prazo definido, excluir dados de contato e manter apenas métricas agregadas.

• Implementação: job mensal identifica clientes com data_fim_relacionamento + prazo < hoje, gera lote, remove dados de contato e histórico detalhado, mantém contadores agregados por período.
• Evidência: batch_id, contagem de clientes tratados, logs do job, e validação de ausência de e-mail/telefone.

Exemplo 2: Logs de acesso e trilhas de auditoria

Cenário: logs são essenciais para investigação, mas acumulam rapidamente. Regra: manter logs detalhados por X meses e, depois, manter apenas agregados (ou excluir).

• Implementação: pipeline de logs com retenção por índice (hot/warm/cold), expiração automática e exportação de métricas agregadas.
• Evidência: política de retenção do repositório de logs, relatórios de expiração, e amostras de verificação.

Exemplo 3: Descarte de notebooks e mídias

Cenário: troca de parque de máquinas. Regra: antes de doação/reciclagem, sanitizar ou destruir mídias.

• Implementação: inventário do ativo, execução de secure erase ou destruição física por fornecedor, registro de cadeia de custódia.
• Evidência: certificado de destruição/sanitização com número de série, método, data, responsável e lote.

Erros comuns e como evitar

• Soft delete sem purga: vira retenção indefinida. Solução: prazo curto para purga e monitoramento.
• Esquecer anexos e objetos: excluir registro mas manter arquivos em storage. Solução: rotinas que varrem referências órfãs e políticas por bucket/pasta.
• Ambientes de teste com cópias reais: dados persistem fora do controle. Solução: mascaramento, dados sintéticos e retenção curta em não produção.
• Evidência contendo dados pessoais: “provar” com planilhas sensíveis. Solução: evidência minimizada, hashes e IDs internos.
• Backups sem política clara: restaurações reintroduzem dados expirados. Solução: retenção definida, criptografia e purga pós-restore.
• Holds sem revisão: tudo fica em hold para sempre. Solução: revisão periódica e encerramento formal.