Fluxo de retenção legal para exclusão e auditorias

O problema real: excluir no prazo e ainda passar em auditorias

A maioria das equipes concorda que deve excluir dados quando eles não são mais necessários. Isso reduz riscos, diminui armazenamento e ajuda a cumprir regras de privacidade. O problema começa depois, quando alguém pergunta: “Você pode provar o que aconteceu?” Essa pergunta pode vir de um auditor, de uma reclamação de cliente ou de um processo.

Um fluxo sólido de retenção com legal hold resolve uma tensão difícil: excluir segundo o cronograma, mas ainda conseguir mostrar decisões, acessos e ações depois que os dados subjacentes sumiram.

Retenção é por quanto tempo você mantém uma categoria de dados por motivo de negócio ou legal. Exclusão é o que você faz quando esse tempo termina, incluindo remover cópias e backups dentro de uma janela definida. Um legal hold é uma pausa temporária na exclusão para registros específicos porque uma disputa, investigação ou regulação exige preservação.

“Manter evidência” não significa sempre manter os dados completos para sempre. Frequentemente significa manter um conjunto menor e mais seguro de provas que suporte uma auditoria sem recriar os dados pessoais originais. Por exemplo, você pode manter:

• Logs com carimbo de tempo mostrando que um registro foi criado, alterado, acessado ou excluído
• A regra de retenção que se aplicava no momento, mais quem a aprovou
• Um relatório de job de exclusão mostrando o que foi removido e quando
• Identificadores não sensíveis ou hashes que confirmam integridade sem expor conteúdo
• Avisos de legal hold, escopo e datas de liberação

O objetivo é um processo repetível que decide o que é excluído, o que é pausado e quais artefatos leves de auditoria permanecem.

Isto é orientação operacional, não aconselhamento jurídico. Períodos de retenção e gatilhos de hold devem ser revisados com o jurídico e alinhados às regras do seu setor.

Mapeie quais dados você tem e onde eles vivem

Você não consegue executar um cronograma de exclusão limpo ou um legal hold se não souber o que está guardando. Comece listando os tipos de dados que coleta e, em seguida, todos os sistemas que os armazenam ou fazem cópias.

Pense além do “banco de dados”. Perfis de clientes podem estar no banco de dados do app, mas os mesmos detalhes podem aparecer em tickets de suporte, threads de email, ferramentas de chat, planilhas exportadas e anexos. Logs, backups e analytics frequentemente guardam cópias extras que as pessoas esquecem.

Uma maneira simples de mapear isso é anotar cada conjunto de dados e responder três perguntas: onde ele é criado, para onde é copiado e quem pode excluí-lo.

O que inventariar (pequeno, mas completo)

Foque nas fontes que tendem a causar surpresas depois:

• Dados de cliente e conta (perfis, pedidos, detalhes de cobrança)
• Arquivos e mensagens (uploads, anexos, transcrições de email e chat)
• Logs e eventos (logs do app, logs de acesso, logs de auditoria)
• Backups e snapshots (backups automáticos, dumps de banco retidos)
• Cópias secundárias (exportações, arquivos locais, drives compartilhados)

Decida o que está no escopo do fluxo

Nem tudo precisa do mesmo tratamento no primeiro dia. Defina o que o fluxo cobre agora e o que será adicionado depois.

Um escopo prático inicial normalmente inclui sistemas que você controla (onde pode excluir no prazo), sistemas que devem ser pesquisados durante um legal hold e sistemas que armazenam apenas evidência de auditoria após a exclusão.

Também anote o que está fora do escopo (por exemplo, notas pessoais salvas em laptops). Essas lacunas são onde costuma surgir o comportamento de “guardar tudo para sempre”.

Termos-chave (como as pessoas os usam na prática)

A confusão muitas vezes vem de pessoas usando as mesmas palavras para significar coisas diferentes. Concorde definições desde o início para que o fluxo seja mais fácil de executar e defender.

Retenção vs cronogramas de exclusão

Uma tabela de retenção responde a uma pergunta: por quanto tempo mantemos cada tipo de dado? Geralmente é definida por lei, contratos ou necessidades de negócio. Deve ser específica (por exemplo: tickets de suporte por 2 anos, faturas por 7 anos, logs de aplicação por 30 dias).

Um cronograma de exclusão é o plano de execução. Responde: quando a exclusão acontece e como ela é executada? Algumas equipes excluem em lotes noturnos, outras excluem de forma contínua, e muitas usam exclusão baseada em eventos (como “30 dias após o fechamento da conta”). A tabela de retenção é a regra; o cronograma de exclusão é a rotina que aplica a regra.

Legal hold e requisitos de auditoria

Um legal hold é uma pausa direcionada na exclusão vinculada a um caso, reclamação, investigação ou processo. Deve incluir escopo (quais pessoas, contas, sistemas ou intervalo de datas) e propriedade (quem aprovou). Um legal hold não deve significar “parar toda exclusão em todo lugar.” Significa “parar a exclusão apenas para os registros afetados.”

Requisitos de auditoria são o que você deve ser capaz de mostrar depois: quem fez o quê, quando aconteceu e por que foi permitido. Auditorias normalmente se importam mais com evidência de um processo consistente do que com manter cada registro para sempre.

Mantenha a linguagem simples:

• Tabela de retenção: período permitido de armazenamento por tipo de dado
• Cronograma de exclusão: gatilho e método que removem dados no prazo
• Legal hold: exceção baseada em caso que bloqueia temporariamente a exclusão para registros específicos
• Evidência de auditoria: metadados provando decisões e ações (aprovações, carimbos de tempo, escopo, motivo)

Construa uma tabela de retenção que as pessoas possam realmente seguir

Uma tabela de retenção falha quando parece um livro de leis ou quando ninguém sabe quem decide o quê. Para cada tipo de dado, escreva por que você o mantém, por quanto tempo, o que inicia o relógio e quem é o responsável pela regra.

Agrupe dados por finalidade de negócio, não por onde eles ficam nos seus sistemas. “Faturas” é uma categoria mais clara que “linhas na tabela X.” Mantenha o número de categorias pequeno o suficiente para que uma pessoa ocupada possa revisar rapidamente.

Torne a propriedade explícita. Finanças não deve adivinhar o que Suporte precisa, e Suporte não deve definir regras de RH. Dê a cada categoria um dono que aprove mudanças e responda perguntas.

Gatilhos são tão importantes quanto o tempo. “7 anos” não significa nada a menos que você defina quando começa: fechamento de conta, término de contrato, último login, último pagamento, última atualização de ticket. Escolha um gatilho por categoria quando possível.

Por fim, escreva exceções em palavras simples. Essas são as razões pelas quais a exclusão é pausada: disputas, estornos, revisão de fraude e holds legais ativos. Se a exceção for vaga, as pessoas tratarão tudo como exceção.

Aqui está um formato de tabela simples que equipes realmente usam:

Passo a passo: um fluxo combinado de exclusão + legal hold

Um bom fluxo de retenção com legal hold tem um objetivo: excluir no prazo por padrão, mas pausar somente os registros específicos que precisam ser preservados. A abordagem mais confiável é tratar retenção, exclusão e holds como eventos separados que compartilham um único log de auditoria.

Uma sequência semanal que funciona

1. Crie ou atualize uma regra de retenção (com um responsável). Defina o conjunto de dados, a razão (contrato, imposto, suporte) e o período de retenção. Registre quem aprovou e a data de vigência.

2. Execute jobs de exclusão com escopo definido. Transforme regras em jobs automatizados que excluem ou anonimiza campos, tabelas, arquivos e índices de busca específicos. Seja explícito sobre o que “excluído” significa na sua organização (exclusão permanente, exclusão lógica ou anonimização irreversível) e quais sistemas estão incluídos.

3. Coloque um legal hold (congele apenas o que é relevante). Quando surgir uma disputa, investigação ou pedido regulatório, crie um registro de hold que direcione a uma pessoa, conta, ID de caso, intervalo de datas e tipos de dados. O job de exclusão deve pular apenas os registros correspondentes, não o banco de dados inteiro.

4. Libere o hold (depois retome a exclusão com segurança). Quando o Jurídico confirmar que o hold acabou, marque-o como liberado. Antes de retomar a exclusão, confirme que o escopo está correto e que não há novos holds sobrepostos.

5. Registre cada ação. Mudanças de retenção, execuções de exclusão, holds colocados, holds liberados e exceções manuais. Cada entrada deve incluir carimbo de tempo, ator, aprovador, escopo e resultado (sucesso ou falha).

Aprovações são onde os fluxos normalmente quebram. Mantenha papéis claros:

• Dono do dado propõe ou atualiza regras de retenção
• Jurídico/Compliance aprova regras e todos os legal holds
• Segurança/TI confirma o método de exclusão e monitora falhas
• Operações executa checagens rotineiras e escala exceções

Exemplo: um gerente de suporte altera a retenção de transcrições de chat de 24 para 12 meses após aprovação. O job semanal de exclusão remove transcrições com mais de 12 meses. Dois meses depois, o Jurídico coloca um hold na conta de um cliente por uma disputa, então apenas as transcrições daquele cliente são congeladas; todos os outros continuam seguindo o cronograma.

Como os legal holds funcionam sem congelar tudo

Um legal hold deve impedir exclusão apenas para os registros que importam, pelo período que importa. Se um hold virar “pausar toda exclusão em todo lugar”, você cria custo, risco e confusão.

Comece pelo escopo. Um hold pode ser limitado a usuários, pedidos, tickets de suporte, projetos, caixas postais, pastas ou um intervalo de datas como “mensagens de 1º de março a 15 de abril”. Quanto mais estreito o escopo, mais fácil defender e menos dados você mantém.

Para evitar exclusões acidentais, torne o hold legível por máquina. Normalmente isso significa uma flag de hold mais um ID de hold em cada registro (ou no objeto caso/pedido que possui o registro). Seu job de exclusão então tem uma regra rígida: se HoldActive = true, pule a exclusão e registre que foi pulada devido a um hold.

Novos dados após o início do hold são uma armadilha comum. Decida antecipadamente se o hold é:

• Estático: inclui apenas itens que já existem
• Contínuo: novos itens que correspondam ao escopo também são incluídos

Para disputas, holds contínuos costumam ser mais seguros (por exemplo, “todos os novos tickets do Cliente X enquanto o caso estiver aberto”).

Pense em dois relógios. O relógio de retenção define quando os dados ficam elegíveis para exclusão. O relógio do hold define se a exclusão é permitida agora. A retenção continua envelhecendo em segundo plano, mas o hold bloqueia a ação final de exclusão. Quando o hold termina, qualquer coisa além do período de retenção fica elegível imediatamente.

Ao documentar o hold, escreva o suficiente para explicar o “porquê” sem expor demais. Mantenha curto: solicitante, data, escopo e um motivo simples como “disputa de cobrança” ou “reclamação trabalhista”.

Evidência de auditoria: o que manter depois que os dados são excluídos

Auditores normalmente não precisam dos dados excluídos em si. Precisam da prova de que seu processo é controlado: quem decidiu, o que foi excluído, quando aconteceu e por que foi permitido.

Registre eventos de exclusão como você registraria uma transação financeira. O registro deve fazer sentido meses depois, mesmo para alguém que não estava na equipe.

Capture o essencial para cada evento de exclusão (ou anonimização):

• Ação tomada (excluir, anonimizar, arquivar, restaurar)
• Ator (usuário, conta de serviço, nome do job automatizado)
• Carimbo de tempo em um fuso horário consistente
• O que foi afetado (tipo de registro, chave ou ID, e quantidade)
• Motivo (nome da regra de retenção, ID de solicitação, número de ticket ou referência de liberação de hold)

Também mantenha prova operacional de que o job rodou e completou, sem armazenar conteúdo:

• ID da execução do job e status (iniciado, concluído, falhou)
• Contagens: selecionados para exclusão vs realmente excluídos
• Resumo de erros e tentativas (se houver)
• Um snapshot antes/depois apenas de metadados (por exemplo, contagens por tabela ou categoria)

Evite copiar registros completos para um banco de dados de auditoria “só por precaução.” Isso cria um segundo sistema do qual você também terá que excluir dados.

Para os próprios logs de auditoria, defina um período de retenção claro e regras de acesso. Muitas equipes mantêm logs detalhados por 12 a 24 meses e depois guardam um resumo mensal menor por mais tempo, se necessário. Restrinja o acesso a um grupo pequeno (segurança, compliance e um conjunto limitado de administradores) e registre acessos aos logs.

Para facilitar auditorias, prepare alguns relatórios simples que você possa gerar rapidamente: um resumo mensal de exclusões, uma lista de exceções (holds ativos, jobs bloqueados, falhas não resolvidas) e uma divisão das principais razões de exclusão.

Exemplo: se 1.240 contas encerradas foram excluídas em julho, sua evidência pode ser um único registro de execução mostrando quem aprovou a execução, a regra de retenção usada, a contagem, o status de conclusão e uma lista de exceções com as 12 contas bloqueadas por um legal hold ativo.

Erros comuns que levam a “guardar tudo para sempre”

A maioria dos programas de retenção falha por um motivo: quando algo parece arriscado, as pessoas param de excluir. Então exceções “temporárias” se acumulam até que nada saia mais.

Uma das maiores cegueiras são backups, réplicas e armazenamento arquivado. Equipes excluem o registro principal, mas esquecem cópias antigas em snapshots ou réplicas de leitura. Seja claro sobre o que “exclusão” significa na sua política: frequentemente significa que a cópia em produção é removida rapidamente, e os backups expiram em um cronograma separado e fixo.

Outra falha comum é colocar um legal hold em todo um sistema “por precaução.” Isso congela dados não relacionados e faz com que toda exclusão futura pareça perigosa. Holds devem ser escopados a pessoas, intervalos de datas, tipos de registro e sistemas que realmente contêm dados relevantes.

Lacunas de propriedade também causam holds permanentes. Se ninguém é responsável por aprovar um hold, documentá‑lo e liberá‑lo, ele nunca terminará. Trate holds como uma mudança controlada com papéis nomeados.

Exportações são o assassino silencioso da retenção. Você pode excluir dados no app e ainda tê‑los para sempre em planilhas, anexos de email, drives compartilhados ou extratos ad hoc de BI.

Algumas correções práticas evitam o comportamento de “guardar tudo”:

• Defina janelas de retenção para backups e réplicas, e documente como a exclusão se propaga
• Exija pedidos de hold com escopo (quem, o quê, quando, onde) com um aprovador
• Adicione um dono e uma data de revisão para cada hold
• Controle exportações (quem pode exportar, onde os arquivos podem ser armazenados e como expiram)
• Registre apenas o que você precisa para provar ações, não payloads sensíveis completos

Registrar é um ato de equilíbrio: pouco registro e você não prova que o fluxo funcionou; muito e seus logs viram um novo problema de privacidade.

Verificações rápidas antes de confiar no processo

Antes de confiar em um cronograma de exclusão na prática, faça um teste “podemos provar isto”. O fluxo vale tanto quanto a etapa mais fraca: o dono ausente, o backup silencioso ou o job que exclui a coisa errada.

Faça um exercício de mesa curto com as pessoas que usarão o processo (jurídico, segurança, TI e a equipe de negócio dona dos dados).

Cinco checagens que pegam a maioria das falhas

• Cada categoria de dado tem um dono nomeado e um período de retenção claro, incluindo o gatilho (como “conta encerrada” ou “contrato finalizado”)
• Jobs de exclusão pulam registros em legal hold, e a flag de hold não pode ser ignorada por um atalho administrativo
• Você consegue listar todos os lugares onde o registro pode existir, incluindo exportações, emails, ferramentas de terceiros e backups ou arquivos
• Você tem um log de auditoria mostrando quem colocou um hold, quando começou, qual escopo cobriu, quando foi liberado e o que foi excluído
• Você consegue gerar um relatório para um ID de caso específico ligando a decisão de hold, IDs de registros afetados e resultados de exclusão

Se algum item for difícil de responder, aperfeiçoe o fluxo antes que ele seja testado por um regulador, auditor ou tribunal.

Um exercício prático de “provar”

Escolha um objeto de dado real (por exemplo, um perfil de cliente) e siga‑o de ponta a ponta: onde é criado, onde é copiado e como é removido. Então coloque um legal hold vinculado a um ID de caso, execute um job de exclusão, libere o hold e execute a exclusão novamente. Salve o relatório e verifique se alguém de fora da sua equipe consegue entendê‑lo.

Cenário de exemplo: encerramento de conta e depois uma disputa

Um cliente encerra a conta em 1º de março. Sua política diz: excluir dados do perfil após 30 dias, excluir conversas de suporte após 90 dias e guardar faturas por 7 anos (regras fiscais e financeiras frequentemente exigem isso).

Em 20 de abril, o mesmo cliente abre uma disputa de cobrança referente a uma fatura de fevereiro. É aqui que o fluxo deve parecer preciso, não assustador.

Você faz duas coisas ao mesmo tempo. Continua a exclusão normal para tudo que não estiver relacionado à disputa. Ao mesmo tempo, coloca um legal hold em um pequeno conjunto de registros que provem o que aconteceu.

O que é excluído no prazo (porque não é necessário para a disputa) pode incluir preferências de marketing, chats antigos não relacionados à cobrança, eventos de uso do produto além da janela de analytics e notas internas que não fazem parte da decisão de cobrança.

O que você mantém como evidência e coloca em hold:

• A(s) fatura(s) em disputa e o status de pagamento
• O recibo ou referência do processador de pagamento
• Os ticket(s) de suporte ligados à disputa, incluindo anexos
• Um log curto de auditoria mostrando quem alterou configurações de cobrança e quando

O hold deve ser direcionado: apenas faturas e tickets relacionados. A conta inteira do cliente não deve ser congelada a menos que seja necessário.

Quando a disputa for resolvida, libere o hold, registre o resultado (aprovado, negado, reembolso parcial) e retome as exclusões pausadas para os itens que estavam em hold.

As perguntas de um auditor são geralmente básicas: o que foi excluído, por quê e como você evitou a exclusão dos registros da disputa. Você deve conseguir mostrar regras de retenção, datas de início e fim do hold, a lista de IDs de registros mantidos e um rastro de eventos provando que as exclusões ocorreram no prazo para todo o resto.

Próximos passos: transforme a política em um fluxo repetível

Uma política de retenção só funciona quando vira trabalho rotineiro. Comece pequeno, prove o processo e depois expanda. Escolha um tipo de dado (por exemplo, tickets de suporte), um sistema e um relatório que mostre o que foi excluído, o que foi colocado em hold e por quê.

Execute um piloto curto de 2 a 4 semanas e procure por atritos: donos pouco claros, aprovações faltantes e pedidos de hold que chegam tarde demais. Corrija isso antes de escalar para mais sistemas.

Um plano de rollout que aguente pressão:

• Escolha um conjunto de dados com regras claras e um dono definido
• Escreva um procedimento de legal hold de uma página e obtenha aprovação
• Adicione um lembrete recorrente de revisão de hold (mensal ou trimestral)
• Defina um relatório pronto para auditoria e quem o assina
• Expanda para o próximo conjunto de dados apenas depois que o primeiro rodar limpo

Mantenha o procedimento de hold curto o suficiente para que as pessoas o usem. Uma página é suficiente se responder: quem pode solicitar um hold, quem aprova, o que precisa ser incluído (escopo, motivo, data de início) e o que acontece quando termina.

Não deixe holds abertos por padrão. Configure lembretes que forcem uma decisão: renovar o hold com um motivo, estreitá‑lo ou fechá‑lo.

Se você estiver gerenciando aprovações, logs de auditoria e execuções de exclusão por email e planilhas, considere colocar o fluxo em um app interno para que o processo seja consistente. Equipes às vezes constroem esse tipo de rastreador de retenção e hold no AppMaster (appmaster.io) para que regras, holds e logs de auditoria vivam em um só lugar e jobs de exclusão possam pular registros em hold enquanto limpam todo o resto.