Checklist de retencao e eliminacao para founders e compliance leads

Retencao e eliminacao funcionam melhor como checklist. A equipa deve saber que dados pessoais existem, que finalidade justifica conserva-los, que evento inicia o prazo, que sistema executa eliminacao ou anonimizacao, que excecoes se aplicam e que evidencia prova que a regra foi seguida.

O objetivo nao e um memorando legal perfeito. E um modelo operacional que product, engineering, support, security, finance, legal e vendor owners podem usar antes de customer review, audit, incident, lancamento ou pedido de eliminacao forcaren o tema.

1. Confirme categorias e finalidade

Liste customer account data, perfis de utilizador, authentication, tickets de suporte, billing, product analytics, security logs, marketing, HR, vendor contacts, exports, spreadsheets, warehouses e backups. Nao pare no system of record: o risco costuma viver em copias, logs, anexos e vendors.

Para cada categoria, escreva porque a empresa ainda precisa dela: produto, contrato, impostos, billing, fraude, security, audit, legal claims ou customer commitments. Se a finalidade puder ser cumprida com dados anonimizados ou agregados, reduza identificabilidade. Isto liga-se a data minimisation.

2. Defina trigger e acao

Escolha o evento inicial: account deletion, contract termination, workspace closure, final invoice, ticket closure, lead inactivity, applicant rejection, offboarding, incident closure, legal hold release, vendor termination ou backup rotation.

Depois defina a acao real: hard deletion, soft deletion com purge, anonimizacao, pseudonimizacao, suppression record, restricted archive, deletion request ao processor, backup expiry ou retencao sob excecao documentada. Nao prometa eliminacao instantanea de todos os backups se o sistema funciona por rotacao.

3. Atribua owners

Cada regra precisa de policy owner, system owner, execution owner, approver de excecoes, reviewer legal ou privacy, evidence owner e por vezes customer communication owner. Engineering pode executar, mas legal, finance, security, support e vendor management decidem muitas vezes scope e excecoes.

4. Documente excecoes

Excecoes comuns incluem impostos, accounting, payroll, warranty, contract performance, billing disputes, fraud prevention, security monitoring, incident response, legal holds, litigation, insurance, audit evidence e regulatory reporting.

Cada excecao deve ter dados cobertos, razao, approver, data de inicio, data de review, restricao e release process. Uma excecao sem review pode transformar-se em retencao indefinida.

5. Prepare pedidos de eliminacao

Retencao de rotina nao e o mesmo que pedido de eliminacao. A equipa deve reconhecer requests em support, sales, legal, privacy ou customer success, registar deadline, verificar requester, identificar scope de account, workspace, sistemas, vendors e backups, decidir o que eliminar ou conservar, documentar recusas parciais e guardar completion evidence.

Ligue este processo a operacoes DSAR.

6. Inclua vendors e evidencia

A retencao segue os dados para processors. Pergunte que dados o vendor recebe, se armazena, loga, deriva ou exporta, que subprocessors acedem, como os prazos sao configurados, como se aciona a eliminacao e que evidencia e entregue.

Isto liga-se a processor management e GDPR compliance planning. Guarde schedule, inventory, review ticket, logs de eliminacao ou anonimizacao, exception approvals, backup policy, vendor confirmation e reviews periodicas.

Common mistakes

Os erros mais comuns sao manter um schedule sem system mapping, usar promessas vagas de eliminacao, tratar pedidos de eliminacao como rotina, nao documentar excecoes e esquecer copias em vendors.

FAQ

O que as equipas devem entender?

Quando retencao e eliminacao se aplicam, que mudancas operacionais exigem e que evidencia mostra que o workflow funciona.

Porque importa na pratica?

Afeta risco, customer trust, audit readiness, breach impact, erasure handling e precisao dos privacy commitments.

Qual e o maior erro?

Tratar retencao e eliminacao como interpretacao legal unica em vez de workflow repetivel com owners, triggers, evidencia e escalacao.

Sources

• European Union, General Data Protection Regulation.
• European Commission, For how long can data be kept and is it necessary to update it?
• European Commission, Do we always have to delete personal data if a person asks?
• European Commission, How much data can be collected?
• Information Commissioner's Office, Principle (e): Storage limitation.
• Information Commissioner's Office, Right to erasure.