Como implementar Data Retention Policy em Governação de Dados: passo a passo

João Barros 31 de August de 2026 4 min de leitura

Este guia mostra como implementar uma Data Retention Policy em Governação de Dados para garantir que os dados são retidos e eliminados conforme as políticas internas e os requisitos legais. A retenção automatizada reduz o risco regulatório, limita a exposição de dados sensíveis e optimiza custos de armazenamento — por exemplo, ao arquivar 500 GB de dados frios pode reduzir custos de armazenamento activo em 60% ao ano. A abordagem apresentada é prática: descreve como definir políticas, marcar datasets, detetar registos elegíveis, aplicar acções seguras e validar resultados.

Pré-requisitos

Conta com permissões de administrador em Azure (ou outro cloud) e acesso a um repositório de dados (ex.: Azure Data Lake, Azure SQL). Garanta RBAC adequado: um utilizador de operação deve ter permissões de escrita limitadas e o papel de auditor com acesso apenas leitura aos logs.
Ferramenta de catalogação/metadados (ex.: Microsoft Purview ou catálogo próprio) para marcar políticas e armazenar metadados sobre datas sensíveis e titularidade dos dados.
Capacidade de executar scripts ETL/ELT (PowerShell, Azure Data Factory, Azure Functions ou SQL). Para operações em produção, planeie lotes de processamento — por exemplo, 10k registos por job para evitar bloqueios.
Conhecimentos básicos de SQL e das políticas de compliance da organização, incluindo prazos legais comuns (ex.: 5 anos para dados fiscais, 2 anos para dados de marketing) e requisitos de retenção de logs (por exemplo, 7 anos para auditoria).
Processo de excepção/legal hold documentado: uma funcionalidade para suspender a eliminação em casos jurídicos ou de investigação interna.

Passo 1: Definir a política de retenção (quem, o quê, por quanto tempo)

Antes de codificar, faça um inventário e descreva a política: quais classes de dados (PII, CustomerData, Transactional), o motivo da retenção (fiscal, operativo, histórico), o prazo e a acção ao fim do prazo (anonimização, eliminação, arquivamento). Mapear responsabilidades é crucial: quem aprova a política, quem executa a job e quem valida os resultados. Por exemplo, uma política para PII de clientes pode ser: retenção 60 meses depois de created_at, acção = delete, aprovador = Data Protection Officer.

{
  "policyName": "Retencao_PII_5anos",
  "dataClasses": ["PII", "CustomerData"],
  "retentionPeriodMonths": 60,
  "action": "delete", // ou "anonymize" / "archive"
  "startDateField": "created_at"
}

Passo 2: Marcar datasets no catálogo

Associe os datasets no catálogo (ex.: Microsoft Purview) às classes usadas na política. Isto permite aplicar a mesma regra a todos os ficheiros/tabelas classificados e gerir excepções centralmente. Idealmente, mantenha um mapeamento entre class tags e owners: por exemplo, 15 datasets marcados como PII, cada um com um owner responsável por aprovar o plano de eliminação. A automatização baseia-se nesta etiqueta para escalar políticas a centenas de tabelas sem configuração manual por tabela.

// Exemplo conceptual: marcar um dataset via API do catálogo
POST /catalog/datasets/{id}/tags
Body: { "tags": ["PII", "CustomerData"] }

Passo 3: Criar uma job que detecta dados elegíveis para acção

Crie um processo ETL/ELT que identifica registos cujo campo de início (ex.: created_at) exceda o período de retenção. Pode ser uma pipeline em Azure Data Factory, Azure Function ou SQL job. Para eficiência, processe em incremental batches (ex.: 10k–50k registos por execução), e utilize índices no campo de data para reduzir scanning. Teste em ambiente de staging com amostras representativas (1–5% do volume total) e estime o tempo de execução: uma tabela de 10M registos com índice adequado pode ser avaliada em poucos minutos por batch.

-- Exemplo SQL para identificar registos antigos
SELECT id, created_at
FROM dbo.Customers
WHERE created_at <= DATEADD(month, -60, GETUTCDATE())
  AND classification IN ('PII','CustomerData');

Passo 4: Implementar acção: eliminação segura ou anonimização

Escolha a acção definida na política. Para "delete" implemente primeiro uma eliminação lógica (flag "deleted" e mover para tabela de quarentena) seguida de eliminação física após período de carência — por exemplo, 30 dias para recuperação. Para "anonymize", substitua campos sensíveis por valores irreversíveis ou por hashes e mantenha um identificador irreversível se necessário para análises agregadas. Para "archive", mova dados para um storage com custo mais baixo e políticas de retenção longas.

-- Exemplo: anonimização parcial em SQL
UPDATE dbo.Customers
SET email = CONCAT('redacted+', HASHBYTES('SHA2_256', CAST(id AS varchar)), '@example.invalid'),
    ssn = NULL
WHERE created_at <= DATEADD(month, -60, GETUTCDATE())
  AND classification IN ('PII','CustomerData');

-- Exemplo: eliminação física (faça backup antes!)
DELETE FROM dbo.Customers
WHERE created_at <= DATEADD(month, -60, GETUTCDATE())
  AND classification IN ('PII','CustomerData');

Passo 5: Automatizar e agendar a execução segura

Coloque a job num agendamento (Azure Data Factory trigger, Azure Automation, SQL Agent) e implemente controlos: logging detalhado, transacções com rollbacks, testes em ambiente de staging e aprovação manual para operações maiores. Recomenda-se executar em horários de baixa actividade (ex.: diário às 02:00) e limitar a taxa para evitar impacto. Mantenha um plano de recuperação e backups antes de cada execução massiva; por exemplo, um snapshot semanal antes da primeira execução do mês.

// Exemplo conceptual Azure Function trigger (pseudo)
// Trigger diário: verifica e executa acções conforme política JSON
// Regista resultados em table RetentionAudit

Passo 6: Audit e provas da conformidade

Registe quem executou o processo, que registos foram afectados e a operação realizada. Mantenha logs imutáveis (por exemplo, armazenados em Append-Only storage ou enviados para um SIEM) e resumos no catálogo para auditorias. Guarde evidência por um período superior às exigências legais (ex.: logs por 7 anos). A auditoria deve incluir contagens before/after, hashes de amostras e identificação de excepções.

-- Exemplo de tabela de auditoria
CREATE TABLE RetentionAudit (
  audit_id UNIQUEIDENTIFIER DEFAULT NEWID(),
  dataset_name NVARCHAR(200),
  action NVARCHAR(50),
  affected_count INT,
  executed_by NVARCHAR(200),
  executed_at DATETIMEOFFSET DEFAULT SYSDATETIMEOFFSET()
);

Verificar o resultado

Valide que a política foi aplicada: confira contagens antes/depois (por exemplo, 120k registos identificados e 119.8k processados com 0.2k em erro), verifique amostras de registos para garantir anonimização correcta, confirme entradas em RetentionAudit e que o catálogo mostra o estado actualizado. Teste cenários de erro (permissões insuficientes, falha na job) e implemente alertas (e-mail/Teams/Syslog) para incidentes. Métricas úteis: tempo médio por batch, taxa de sucesso, percentagem de registos em excepção.

Conclusão

Implementar uma Data Retention Policy em Governação de Dados protege a organização, reduz risco e simplifica auditorias. Comece por políticas pequenas e bem documentadas, valide em staging e lance por fases (por exemplo, 3 datasets piloto), para reduzir risco operacional. Próximos passos: integrar com processos de Data Lifecycle Management, criar testes automatizados e ligar a alertas de segurança. Pergunta prática: qual conjunto de dados terá maior impacto de custo ou risco se não for priorizado — comece por aí.