Plantilla de Política de Retención de Datos

Descripción General

Toda decisión de retención negocia valor de negocio contra obligación legal y costo de almacenamiento — y equivocarse en cualquiera de los dos sentidos sale caro. Esta plantilla sirve para clasificar los datos, ponerles un período, cubrir las retenciones legales y dejar asentados los controles. Ponerla por escrito mata la ambigüedad: los equipos saben qué borrar, los auditores tienen evidencia y las reglas se aplican siempre igual.

Cuándo Usar

• Definir las reglas de retención de una plataforma o app nueva antes de que los datos se acumulen.
• Prepararse para auditorías de GDPR, CCPA, HIPAA o SOC 2 — combiná esta política con la plantilla de clasificación de datos para que cada categoría tenga un responsable.
• Bajar el gasto de almacenamiento moviendo datos viejos a tiers más baratos.
• Responder a una solicitud de acceso o eliminación por parte de un titular de datos (la receta de privacidad de datos GDPR cubre el lado operativo de las solicitudes).
• Definir estrategias de backup y archivo.
• En la revisión post-brecha, cuando alguien pregunta por qué ese dato seguía existiendo.

Prerequisitos

• Inventario de tipos de datos, sistemas y ubicaciones de almacenamiento.
• Guía legal y de cumplimiento para períodos de retención mínima y máxima.
• Esquema de clasificación de datos como público, interno, confidencial, restringido.
• Herramientas de almacenamiento y backup que soporten políticas de ciclo de vida.
• Proceso para identificar y gestionar retenciones legales.
• Dueños para cada categoría de datos o sistema.

Solución

Plantilla

1. Alcance y Roles de la Política

Campo	Descripción	Ejemplo
Nombre de la política	Nombre de la política	Política de Retención de Datos de Clientes
Fecha efectiva	Cuándo entra en vigor	2026-07-01
Ciclo de revisión	Cada cuánto se revisa	Anualmente
Dueño de la política	Equipo responsable	Data governance
Aprobador legal	Revisor de cumplimiento o legal	Asesoría legal
Dueño técnico	Equipo que implementa controles	Ingeniería de plataforma
Alcance	Sistemas y datos cubiertos	Todas las bases de datos productivas, logs, almacenamiento de objetos y backups

2. Categorías de Datos y Períodos de Retención

Categoría de Datos	Ejemplos	Período de Retención	Archivar Después de	Eliminar Después de	Base Legal
Datos de cuenta de cliente	Perfiles, preferencias	Vida de la cuenta + 1 año	1 año después del cierre	2 años después del cierre	Contrato, obligación legal
Registros de transacciones	Órdenes, pagos	7 años	1 año	7 años después del cierre del período	Ley fiscal y contable
Logs de aplicación	Logs de request, logs de error	90 días	30 días	90 días	Necesidad operativa
Logs de seguridad	Autenticación, logs de acceso	2 años	1 año	2 años después de la creación	Seguridad y cumplimiento
Datos de backup	Backups completos e incrementales	30 días	30 días	Según programación de backup	Recuperación ante desastres
Datos de analítica	Eventos agregados	1 año	6 meses	1 año después de la agregación	Interés legítimo
Datos de marketing	Interacciones de email, leads	2 años o hasta opt-out	1 año	En opt-out o 2 años	Consentimiento
Datos temporales	Caché, archivos de importación	7 días	3 días	7 días	Necesidad operativa

3. Reglas de Retención por Clasificación de Datos

Clasificación	Retención Mínima	Retención Máxima	Manejo Especial
Público	Según necesidad del negocio	1 año o menos	Sin manejo especial
Interno	Necesidad del negocio	3 años	Ciclo de vida estándar
Confidencial	Mínimo legal o contractual	7 años o menos	Cifrado, logs de acceso
Restringido	Mínimo regulatorio	Máximo regulatorio	Proceso de retención legal, cifrado, trazabilidad de auditoría

4. Acciones del Ciclo de Vida de Datos

Etapa	Disparador	Acción	Herramienta / Equipo Responsable
Activo	Datos creados	Almacenar en tier primario con controles de acceso	Equipo de aplicación
Frío	30 días de antigüedad	Mover a almacenamiento de menor costo	Política de ciclo de vida de almacenamiento
Archivo	1 año de antigüedad	Mover a archivo con política de recuperación	Política de ciclo de vida de almacenamiento
Marcar para eliminación	Finaliza período de retención	Marcar registros y notificar dueños	Plataforma de data governance
Eliminación segura	Aprobado por legal / política	Eliminar o anonimizar permanentemente	Ingeniería de plataforma
Log de auditoría	Cada acción del ciclo de vida	Registrar eventos de retención y eliminación	Sistema de logs de auditoría

5. Proceso de Retención Legal y Excepciones

Escenario	Proceso	Dueño	Documentación
Retención por litigio	Suspender eliminación de datos afectados	Asesoría legal	Aviso de retención y alcance
Investigación regulatoria	Extender retención según requerido	Oficial de cumplimiento	Registro de solicitud regulatoria
Solicitud de titular de datos	Revisar y eliminar o anonimizar	Equipo de privacidad de datos	Log de solicitud y respuesta
Solicitud de excepción	Enviar razón, revisión de riesgo, aprobación	Data governance	Registro de excepciones
Anulación de política	Aprobación ejecutiva con revisión legal	C-level / legal	Registro de excepción firmado

6. Checklist de Eliminación y Verificación

• El dueño de datos confirma que el período de retención ha expirado.
• No hay retención legal activa que cubra los datos.
• Los datos ya no están ni en el almacenamiento primario ni en los índices.
• Los backups que contienen los datos se purgan o se programan para purga según la política.
• Los archivos se eliminan o anonimizan según la programación.
• Los datasets derivados, cachés y réplicas se refrescan o limpian.
• La eliminación se registra con timestamp, dueño y alcance.
• Se verifica una muestra para confirmar la eliminación.
• El equipo de cumplimiento revisa los logs de eliminación periódicamente.

Explicación

Retener datos siempre implica elegir entre valor de negocio, obligación legal y costo de almacenamiento. Una política escrita elimina la ambigüedad, asegura la ejecución consistente y proporciona evidencia durante auditorías. Al clasificar los datos, definir períodos de retención y automatizar las acciones del ciclo de vida, los equipos pueden reducir el trabajo manual y evitar conservar datos más tiempo del necesario.

El ciclo de vida de la sección 4 sigue un pipeline fijo y secuencial:

Dos puntos de ese pipeline causan la mayoría de los fallos reales. El primero es la propagación: eliminar del almacenamiento primario no toca backups, réplicas, cachés ni datasets derivados — por eso existe el checklist de la sección 6. El segundo es la compuerta de retención legal entre “marcar” y “eliminar”: sin una verificación explícita de retenciones, la automatización del ciclo de vida purga datos bajo litigio sin enterarse.

Al completar los períodos de retención, no copies los valores de ejemplo sin más — las regulaciones difieren según el tipo de dato y la jurisdicción. El GDPR no fija períodos: su principio de limitación de conservación (Art. 5(1)(e)) solo exige conservar datos personales el tiempo justo y poder justificarlo. HIPAA exige conservar la documentación de cumplimiento durante seis años. Para registros fiscales y financieros, SOX, IRS y SEC/FINRA suelen pedir siete años. Los logs de seguridad y auditoría en entornos regulados suelen necesitar de uno a siete años. Ancla cada fila de la tabla de retención a una base legal con nombre o a una necesidad de negocio documentada, y registra quién la aprobó.

El mismo equilibrio aplica a los tiers de almacenamiento. El almacenamiento caliente (volúmenes de bloques, clase STANDARD, índices de logs calientes) es el más caro por GB-mes y debería contener solo los datos que consultás seguido. Una regla que se sostiene en la práctica: la mayoría de los datos operativos se leen en sus primeros 30 días, rara vez hasta el día 90 y casi nunca después — por eso el ciclo de vida de ejemplo transiciona a los 30, 90 y 365 días. Si tu patrón de acceso difiere, medilo antes de fijar los umbrales: consultá los logs de acceso o las métricas de almacenamiento durante un mes en lugar de adivinar. También presupuestá la recuperación — las clases de archivo como Glacier y Deep Archive son baratas para guardar pero cobran por GB recuperado, así que los datos que auditores o soporte consultan con regularidad pertenecen a un tier frío, no a archivo profundo.

Cómo Adoptar Esta Plantilla

Implementar la política funciona mejor en cinco pasadas que en una reescritura única:

1. Inventario — listá cada almacén de datos (bases de datos, object storage, logs, cachés, warehouses, backups) y las categorías que contiene. No podés fijar retención para datos que no encontraste.
2. Clasificación — cada almacén queda mapeado a público, interno, confidencial o restringido según el esquema de la sección 3.
3. Asignación de períodos — completá la tabla de retención fila por fila con una base legal y un responsable por categoría. Donde la ley no diga nada, anotá la razón de negocio.
4. Automatización — implementá las reglas de ciclo de vida (la config de S3 y el script de purga más abajo son puntos de partida) y agregá la compuerta de retención legal antes de cualquier paso de eliminación.
5. Verificación y revisión — programá el checklist de eliminación trimestralmente, registrá cada acción y reejecutá la política tras cambios regulatorios o nuevos almacenes.

Configuración de Política de Ciclo de Vida S3

{
  "Rules": [
    {
      "ID": "transition-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    },
    {
      "ID": "expire-temp-data",
      "Status": "Enabled",
      "Filter": { "Prefix": "temp/" },
      "Expiration": { "Days": 7 }
    },
    {
      "ID": "retain-user-data",
      "Status": "Enabled",
      "Filter": { "Prefix": "users/" },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "Expiration": { "Days": 3650 }
    }
  ]
}

Script de Purga de Retención de Base de Datos

-- Trabajo programado de purga en PostgreSQL
-- Ejecutar semanalmente vía pg_cron o scheduler externo

-- Purgar sesiones expiradas (retención: 30 días)
DELETE FROM sessions
WHERE created_at < NOW() - INTERVAL '30 days';

-- Purgar logs de auditoría (retención: 7 años para cumplimiento)
-- NO PURGAR: archivados por separado

-- Purgar datos de usuarios eliminados (retención: 90 días después de eliminación)
DELETE FROM user_data
WHERE deleted_at IS NOT NULL
  AND deleted_at < NOW() - INTERVAL '90 days';

-- Purgar logs de eventos (retención: 180 días)
DELETE FROM event_logs
WHERE created_at < NOW() - INTERVAL '180 days';

-- Vacuum y analyze después de purga
VACUUM ANALYZE sessions;
VACUUM ANALYZE user_data;
VACUUM ANALYZE event_logs;

Matriz de Clasificación y Retención de Datos

=== Matriz de Clasificación y Retención de Datos ===

| Tipo de Dato        | Clasificación  | Retención  | Almacenamiento  | Método de Purga    |
|---------------------|----------------|------------|-----------------|---------------------|
| PII de Usuario      | Confidencial   | 3 años     | RDS Cifrado     | Purga programada    |
| Registros de pago   | Restringido    | 7 años     | RDS Cifrado     | Revisión legal      |
| Logs de auditoría   | Interno        | 7 años     | S3 Glacier      | Política lifecycle  |
| Logs de aplicación  | Interno        | 90 días    | CloudWatch      | Auto-expire         |
| Datos de sesión     | Interno        | 30 días    | Redis           | TTL auto-expire     |
| Archivos temporales | Público        | 7 días     | S3 temp/        | Política lifecycle  |
| Eventos analytics   | Interno        | 2 años     | BigQuery        | Partition expire    |
| Backups             | Confidencial   | 90 días    | S3 + Glacier    | Política backup     |
| Exportes cliente    | Confidencial   | 30 días    | S3 signed URL   | Política lifecycle  |
| Datos ML training   | Interno        | 1 año      | S3 IA           | Purga programada    |

Variantes

• Política de ciclo de vida de almacenamiento de objetos en la nube: reglas de transición y expiración en S3, Azure Blob o GCP Storage — el sitio más barato donde aplicar retención.
• Política de retención de base de datos: borrar particiones viejas en lugar de filas, o correr jobs de purga donde no haya particionado.
• Política de retención de logs: los logs de app, infra y seguridad envejecen distinto — retención caliente para debugging, archivo para cumplimiento.
• Política de retención de datos de clientes: datos personales bajo GDPR y CCPA, donde el consentimiento y las solicitudes de borrado marcan los períodos.
• Política de retención de datos de salud: retención alineada con HIPAA más controles de acceso sobre información de salud protegida.
• Política de retención de datos financieros: registros fiscales y de auditoría que exigen almacenamiento a prueba de manipulación.

Lo que funciona

• Clasificá los datos antes de definir períodos de retención.
• Automatizá las transiciones del ciclo de vida usando capacidades nativas de almacenamiento o base de datos.
• Aplicá la retención más corta que satisfaga necesidades legales y de negocio.
• Mantené un inventario centralizado de almacenes de datos y reglas de retención.
• Registrá cada eliminación y acción de retención para fines de auditoría.
• Formá a los equipos en retenciones legales y excepciones.
• Revisá la política al menos anualmente y después de cambios regulatorios.
• Usá cifrado y controles de acceso para datos en retención.
• Probá los procedimientos de eliminación periódicamente para asegurar que los datos se eliminen realmente.

Errores Comunes

• Mantener todos los datos para siempre “por si acaso”.
• Eliminar datos sin confirmar el estado de retención legal.
• Olvidar backups, archivos o réplicas al eliminar datos primarios.
• Usar el mismo período de retención para todos los tipos de datos.
• Dejar excepciones y aprobaciones sin documentar.
• No registrar eventos de eliminación.
• Olvidar las copias que quedan en SaaS de terceros o en cachés.
• No revisar políticas de retención después de nuevas regulaciones.

Troubleshooting

• Los jobs de purga no corren en silencio: el scheduler (pg_cron, EventBridge, cron) se disparó pero el job falló por permisos o locks. No alertes solo sobre éxito del job: alertá también sobre fallos y sobre la antigüedad del registro más viejo.
• La eliminación no llega a backups ni réplicas: los datos primarios desaparecen pero el mismo PII sobrevive en un backup de 30 días o en una réplica de lectura. Tratá los backups como su propia clase de retención con un lag de propagación definido.
• Las reglas de ciclo de vida eliminan datos bajo retención legal: la automatización de object-lock o lifecycle ignora el flag de retención. Agregá una verificación explícita de retención al path de eliminación y probala con un fixture.
• Se olvidan los datos en SaaS de terceros: herramientas de analítica, mesas de soporte y proveedores de email guardan copias fuera de tus almacenes. Agregá los controles de retención/eliminación de cada proveedor al inventario.
• La tabla no baja de tamaño tras la purga: DELETE libera filas pero no espacio en disco. Seguí las purgas con VACUUM/OPTIMIZE o usá particiones — borrar una partición es más rápido y barato que borrar fila por fila.