Cómo implementar una Data Retention Policy en Gobernanza de Datos: paso a paso

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

Esta guía muestra cómo implementar una Data Retention Policy en Gobernanza de Datos para garantizar que los datos se retienen y eliminan conforme a las políticas internas y los requisitos legales. La retención automatizada reduce el riesgo regulatorio, limita la exposición de datos sensibles y optimiza costes de almacenamiento — por ejemplo, al archivar 500 GB de datos fríos se pueden reducir los costes de almacenamiento activo en un 60% al año. El enfoque presentado es práctico: describe cómo definir políticas, etiquetar datasets, detectar registros elegibles, aplicar acciones seguras y validar resultados.

Prerequisitos

Cuenta con permisos de administrador en Azure (u otra cloud) y acceso a un repositorio de datos (p. ej.: Azure Data Lake, Azure SQL). Asegure un RBAC adecuado: un usuario de operación debe tener permisos de escritura limitados y el rol de auditor con acceso solo lectura a los logs.
Herramienta de catalogación/metadata (p. ej.: Microsoft Purview o catálogo propio) para etiquetar políticas y almacenar metadatos sobre fechas sensibles y titularidad de los datos.
Capacidad para ejecutar scripts ETL/ELT (PowerShell, Azure Data Factory, Azure Functions o SQL). Para operaciones en producción, planifique lotes de procesamiento — por ejemplo, 10k registros por job para evitar bloqueos.
Conocimientos básicos de SQL y de las políticas de compliance de la organización, incluidos plazos legales comunes (p. ej.: 5 años para datos fiscales, 2 años para datos de marketing) y requisitos de retención de logs (por ejemplo, 7 años para auditoría).
Proceso de excepción/legal hold documentado: una funcionalidad para suspender la eliminación en casos jurídicos o de investigación interna.

Paso 1: Definir la política de retención (quién, qué, por cuánto tiempo)

Antes de codificar, haga un inventario y describa la política: qué clases de datos (PII, CustomerData, Transactional), el motivo de la retención (fiscal, operativo, histórico), el plazo y la acción al finalizar el plazo (anonimización, eliminación, archivado). Mapear responsabilidades es crucial: quién aprueba la política, quién ejecuta el job y quién valida los resultados. Por ejemplo, una política para PII de clientes puede ser: retención 60 meses después de created_at, acción = delete, aprobador = Data Protection Officer.

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

Paso 2: Etiquetar datasets en el catálogo

Asocie los datasets en el catálogo (p. ej.: Microsoft Purview) a las clases usadas en la política. Esto permite aplicar la misma regla a todos los archivos/tablas clasificados y gestionar excepciones centralmente. Idealmente, mantenga un mapeo entre class tags y owners: por ejemplo, 15 datasets etiquetados como PII, cada uno con un owner responsable de aprobar el plan de eliminación. La automatización se basa en esta etiqueta para escalar políticas a cientos de tablas sin configuración manual por tabla.

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

Paso 3: Crear un job que detecte datos elegibles para acción

Creé un proceso ETL/ELT que identifique registros cuyo campo de inicio (p. ej.: created_at) exceda el período de retención. Puede ser una pipeline en Azure Data Factory, Azure Function o SQL job. Para eficiencia, procese en incremental batches (p. ej.: 10k–50k registros por ejecución), y utilice índices en el campo de fecha para reducir el scanning. Pruebe en entorno de staging con muestras representativas (1–5% del volumen total) y estime el tiempo de ejecución: una tabla de 10M registros con índice adecuado puede evaluarse en pocos 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');

Paso 4: Implementar la acción: eliminación segura o anonimización

Elija la acción definida en la política. Para "delete" implemente primero una eliminación lógica (flag "deleted" y mover a tabla de cuarentena) seguida de eliminación física tras un periodo de carencia — por ejemplo, 30 días para recuperación. Para "anonymize", sustituya campos sensibles por valores irreversibles o por hashes y mantenga un identificador irreversible si es necesario para análisis agregados. Para "archive", mueva datos a un storage de menor coste y políticas de retención largas.

-- 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');

Paso 5: Automatizar y programar la ejecución segura

Ponga el job en un calendario (Azure Data Factory trigger, Azure Automation, SQL Agent) e implemente controles: logging detallado, transacciones con rollbacks, pruebas en entorno de staging y aprobación manual para operaciones mayores. Se recomienda ejecutar en horarios de baja actividad (p. ej.: diario a las 02:00) y limitar la tasa para evitar impacto. Mantenga un plan de recuperación y backups antes de cada ejecución masiva; por ejemplo, un snapshot semanal antes de la primera ejecución del mes.

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

Paso 6: Auditoría y pruebas de conformidad

Registre quién ejecutó el proceso, qué registros fueron afectados y la operación realizada. Mantenga logs inmutables (por ejemplo, almacenados en Append-Only storage o enviados a un SIEM) y resúmenes en el catálogo para auditorías. Guarde evidencia por un periodo superior a las exigencias legales (p. ej.: logs por 7 años). La auditoría debe incluir contadores before/after, hashes de muestras e identificación de excepciones.

-- 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 el resultado

Valide que la política se aplicó: compruebe contadores antes/después (por ejemplo, 120k registros identificados y 119.8k procesados con 0.2k en error), verifique muestras de registros para asegurar una anonimización correcta, confirme entradas en RetentionAudit y que el catálogo muestre el estado actualizado. Pruebe escenarios de error (permisos insuficientes, fallo del job) e implemente alertas (e-mail/Teams/Syslog) para incidentes. Métricas útiles: tiempo medio por batch, tasa de éxito, porcentaje de registros en excepción.

Conclusión

Implementar una Data Retention Policy en Gobernanza de Datos protege a la organización, reduce riesgo y simplifica auditorías. Comience con políticas pequeñas y bien documentadas, valide en staging y lance por fases (por ejemplo, 3 datasets piloto), para reducir el riesgo operacional. Próximos pasos: integrar con procesos de Data Lifecycle Management, crear tests automatizados y conectar a alertas de seguridad. Pregunta práctica: qué conjunto de datos tendrá mayor impacto de coste o riesgo si no se prioriza — comience por ahí.