Retención y borrado de datos: política mínima que reduce riesgo, coste y exposición en incidentes

Una política mínima de retención y borrado no es un ejercicio teórico de compliance. Es una herramienta de control operativo. Cuando una organización conserva más datos de los que necesita, no solo consume almacenamiento: amplía la superficie de exposición, dificulta responder en incidentes, arrastra duplicidades y vuelve más costoso cualquier cambio tecnológico.

En términos de riesgo, más datos retenidos implican más material potencialmente afectado si ocurre una brecha, un acceso indebido o una exfiltración. En términos de coste, aumentan las búsquedas, migraciones, copias, indexaciones y esfuerzos de clasificación. En términos de negocio, se pierde agilidad: cuesta más localizar información útil, más eliminar la que ya no aporta valor, y se instala una cultura de acumulación donde nadie sabe qué puede borrarse y quién debe decidirlo.

La ventaja de una política mínima es que reduce el debate abstracto. En lugar de intentar responder de golpe a “qué hacemos con todos los datos de la empresa”, obliga a responder algo más práctico: qué categorías existen, para qué se usan, quién es su dueño, cuánto tiempo tiene sentido conservarlas y qué proceso se sigue cuando hay una excepción. Ese enfoque da resultados visibles sin esperar a una gran iniciativa de transformación.

Acciones recomendadas

1. Definir, como referencia, 8 a 12 categorías de datos con un responsable de negocio por cada una, evitando dejar la decisión solo en IT o seguridad.
2. Crear una matriz de retención que incluya propósito, ubicación principal, criterio de conservación, evento de borrado y aprobador de excepciones.
3. Empezar por 2 o 3 repositorios con mayor volumen o impacto, como correo, almacenamiento colaborativo y CRM, con reglas concretas y ejecutables.
4. Diseñar un circuito de excepciones con justificación, responsable, fecha de caducidad y revisión periódica para evitar acumulación indefinida.
5. Alinear desde el inicio a legal, privacidad y seguridad sobre retención legal (legal hold), solicitudes especiales y limitaciones técnicas, especialmente en backups.
6. Medir resultados con pocos indicadores: repositorios con regla aplicada, volumen reducido, duplicidades detectadas e incidencias por borrado mal gestionado.
7. Revisar trimestralmente la matriz y los repositorios priorizados para ajustar reglas, eliminar fricciones y ampliar cobertura por fases.

Principios de una política mínima

El primer principio es el propósito. Si un conjunto de datos no tiene una finalidad operativa, contractual, analítica o de control claramente identificable, su permanencia debería ser cuestionada. Muchas acumulaciones sobreviven por inercia, no por necesidad. El simple hecho de preguntar “¿para qué lo conservamos?” ya elimina una parte relevante del volumen sobrante.

El segundo principio es la minimización operativa. No se trata solo de recoger menos datos, sino de conservar menos tiempo y en menos sitios. Una empresa puede tener una base principal correctamente gobernada y, a la vez, decenas de copias de trabajo, exportaciones puntuales, adjuntos reenviados y archivos locales que multiplican el riesgo. La retención efectiva exige mirar también los lugares donde el dato se reproduce.

El tercer principio es la trazabilidad de las excepciones. Siempre habrá casos en los que deba conservarse más tiempo cierta información: una investigación interna, una disputa contractual, una revisión regulatoria o una necesidad documentada de negocio. El error no es conceder excepciones; el error es permitir que sean informales, sin responsable y sin fecha de expiración. Una excepción sin caducidad suele convertirse en norma de facto.

El cuarto principio es el realismo técnico. Borrar en producción no equivale a borrar en todo el ecosistema al instante. Puede haber réplicas, cachés, retenciones propias del SaaS, snapshots y backups con ciclos definidos. Una política seria no promete lo que la tecnología no puede cumplir de inmediato. Define qué se borra de sistemas activos, cómo expiran las copias de respaldo y cómo se documentan esas limitaciones.

La matriz de retención: la herramienta que evita debates infinitos

La pieza más útil para poner orden no es un documento extenso, sino una matriz clara. Debe ser legible, editable y comprensible por responsables de negocio, no solo por especialistas. Su función es convertir principios en decisiones repetibles.

Una matriz mínima puede incluir estas columnas: categoría de dato, descripción, responsable de negocio, sistema o repositorio principal, propósito de conservación, evento que inicia el plazo, criterio de retención, acción al finalizar el plazo, responsable de ejecución, tratamiento de excepciones y notas sobre backups o copias derivadas. No hace falta entrar inicialmente en microcasuísticas. Lo importante es que cada categoría tenga una regla base.

Por ejemplo, en RR. HH. puede distinguirse entre candidaturas, documentación de contratación, nóminas, expedientes de desempeño y registros de formación. En finanzas, entre facturación, órdenes, justificantes y conciliaciones. En ventas, entre leads sin actividad, oportunidades cerradas y clientes activos. En soporte, entre tickets y grabaciones si las hubiera. En seguridad e IT, entre logs operativos, inventarios y trazas de acceso. La utilidad del enfoque por categorías es que permite avanzar sin esperar a inventariar cada archivo de la empresa.

No conviene convertir la matriz en un tratado jurídico. Los plazos concretos que puedan tener implicaciones legales deben validarse con legal o DPO. El valor de la matriz, a nivel operativo, es otro: establecer la diferencia entre “esto sí debemos conservar”, “esto puede eliminarse cuando deje de servir” y “esto requiere una revisión específica antes de borrarse”.

Cómo aterrizar las categorías más habituales

En RR. HH., el reto suele ser la dispersión. Parte de la información vive en el sistema principal, pero otra parte se queda en correo, carpetas compartidas y herramientas de selección. La política mínima debe identificar qué repositorio es el sistema de referencia y limitar la permanencia de duplicados. Las candidaturas, por ejemplo, suelen ser un foco clásico de acumulación innecesaria cuando nadie elimina CV, notas de entrevistas o exportaciones de procesos cerrados.

En finanzas, el problema no suele ser solo cuánto se conserva, sino cuántas copias se generan durante el trabajo diario. Facturas y documentación asociada pueden quedar replicadas en ERP, correo, carpetas por proveedor y archivos locales. La regla mínima debe distinguir entre el registro oficial y las copias operativas, para que la conservación del primero no sirva de excusa para retener indefinidamente todas las demás.

En ventas y CRM, la fricción aparece con leads antiguos, oportunidades cerradas o contactos sin actividad real. Muchos equipos prefieren no borrar por miedo a perder una oportunidad futura, pero el coste de mantener registros envejecidos, incompletos o duplicados también es alto: sesga análisis, empeora segmentaciones y complica solicitudes de acceso o supresión. Una política mínima ayuda a decidir cuándo un lead deja de ser útil y qué hacer con la información asociada.

En soporte, conviene separar la necesidad de conservar histórico útil para calidad o análisis de la tentación de guardar todo. Tickets, adjuntos y grabaciones pueden tener valor por un tiempo, pero no todo ese valor es permanente. La pregunta operativa es cuándo ese histórico deja de mejorar el servicio y pasa a ser simplemente volumen.

En seguridad e IT, logs y backups merecen un tratamiento específico. Los logs no son “guardar todo para siempre”; su utilidad suele estar ligada a monitorización, investigación y evidencias operativas durante una ventana concreta. Los backups, por su parte, existen para recuperación, no para convertirse en archivo histórico sin control. Confundir recuperación con archivo es una de las causas más frecuentes de retención desordenada.

Implementación realista: dónde se borra y cómo se sostiene

Las políticas fracasan cuando se redactan como si todos los sistemas respondieran igual. No es lo mismo borrar en un SaaS con políticas nativas, que en un almacenamiento compartido, que en equipos gestionados por usuarios. La implementación debe mapear, al menos, tres capas: sistemas principales, repositorios secundarios y copias de seguridad.

En los sistemas principales, la prioridad es activar reglas nativas cuando existan: archivado, expiración, eliminación automatizada, purga de registros cerrados o anonimización. En repositorios secundarios, la prioridad es reducir copias, restringir exportaciones y acordar rutinas de limpieza. En equipos, la prioridad es limitar almacenamiento local innecesario y reforzar prácticas para que ciertos datos no acaben fuera del entorno previsto.

Una empresa no necesita esperar a tener automatización completa para empezar. Puede iniciar con reglas semimanuales en pocos dominios bien delimitados. Lo importante es que cada acción tenga responsable, evidencia y una frecuencia definida. La combinación de reglas automatizadas donde sea posible y revisiones operativas donde todavía no lo sea suele ser más efectiva que una gran promesa de automatización futura.

Los backups requieren un mensaje especialmente claro. Si un dato se elimina de producción hoy, no significa necesariamente que desaparezca ese mismo día de todas las copias existentes. Las copias de respaldo tienen ciclos propios y deben gestionarse con criterios de expiración y restauración controlada. La política debe dejar claro que el borrado se ejecuta en sistemas activos y que las copias seguirán su ciclo definido, evitando restauraciones indiscriminadas que reintroduzcan datos eliminados salvo necesidad justificada.

Legal hold y situaciones de “no borrar”

Una política mínima no equivale a borrar sin pensar. Existen situaciones en las que debe suspenderse temporalmente la eliminación ordinaria: investigaciones internas, conflictos, requerimientos regulatorios, revisiones forenses o instrucciones expresas del área legal. El mecanismo habitual para esto es el legal hold o la orden equivalente de preservación.

La clave es tratarlo como un proceso excepcional, no como una etiqueta genérica. Debe quedar claro qué datos quedan afectados, quién autoriza la preservación, desde cuándo aplica, cuándo se revisa y cómo se levanta. Si no se hace así, el legal hold se convierte en un argumento permanente para no eliminar nada.

Un checklist útil incluye: motivo de la preservación, alcance concreto, sistemas afectados, responsable de negocio, validación de legal, fecha de revisión y criterio de levantamiento. Esto evita dos extremos igual de dañinos: borrar cuando no debe borrarse o congelar datos indefinidamente por pura cautela.

Gobierno: quién decide y cómo se mide

El mayor bloqueo en retención y borrado no suele ser técnico. Es de propiedad. Nadie quiere asumir la decisión final, así que todo se conserva. Por eso una política mínima debe asignar responsabilidades explícitas por categoría. El responsable no ejecuta necesariamente el borrado, pero sí decide la regla base, aprueba excepciones y responde por su revisión.

El modelo funciona mejor cuando cada categoría tiene un responsable de negocio, un apoyo técnico para su aplicación y una revisión coordinada por privacidad, compliance o gobierno del dato. Esta estructura evita que la política quede encerrada en seguridad o IT sin patrocinio real de las áreas que generan y usan la información.

Las métricas también deben ser mínimas, no sofisticadas. Algunas de las más útiles son: porcentaje de categorías con responsable asignado, porcentaje de repositorios priorizados con regla activa, número de excepciones vigentes con fecha de caducidad, volumen aproximado reducido en repositorios objetivo, incidencias por eliminación mal gestionada y número de copias o duplicados detectados fuera del sistema oficial. Estas medidas permiten mostrar avance sin construir un programa analítico desproporcionado.

La revisión trimestral suele ser un buen equilibrio. Es suficiente para corregir desajustes, retirar excepciones vencidas y ampliar la cobertura a nuevas categorías o herramientas. Revisar menos puede consolidar errores; revisar demasiado a menudo puede agotar a los equipos y convertir el gobierno en burocracia.

Errores comunes que frenan el avance

El primer error es perseguir una retención perfecta antes de actuar. Esperar a tener todo inventariado, todos los plazos resueltos y todos los sistemas conectados es una receta para la parálisis. Es mejor empezar con una versión mínima, bien gobernada y ampliable.

El segundo error es dejar el tema solo en manos de IT. IT puede aplicar reglas, pero no siempre puede decidir el valor residual de la información. Sin responsabilidad de negocio, la política termina siendo débil o inaplicable.

El tercer error es olvidar copias, exportaciones y repositorios paralelos. Muchas organizaciones fijan reglas para el sistema principal y descuidan los datos que salen de él. Ahí es donde la exposición real suele multiplicarse.

El cuarto error es prometer borrado instantáneo o absoluto. Esto genera expectativas incorrectas y puede volverse en contra cuando se descubren límites técnicos normales en backups o réplicas.

El quinto error es tolerar excepciones eternas. Si una excepción no tiene fecha, responsable y revisión, deja de ser excepción y se transforma en deuda operativa.

Plan de implantación en 90 días

En un horizonte de 30 días, la prioridad es acordar categorías, nombrar responsables y aprobar la estructura de la matriz. También conviene identificar los repositorios de mayor volumen o mayor sensibilidad. No hace falta precisión absoluta; basta con una priorización razonable y compartida.

Entre los días 30 y 60, el foco debe estar en definir las reglas mínimas para esas categorías y activar una primera oleada en dos o tres repositorios. En esta fase, importa más hacer aplicable una regla sencilla que diseñar un marco perfecto. También es el momento de acordar el circuito de excepciones y el checklist de legal hold.

Entre los días 60 y 90, la organización debería medir resultados iniciales, ajustar fricciones, documentar limitaciones técnicas y preparar la siguiente fase de expansión. Si al cabo de ese periodo ya existen responsables claros, reglas activas en los repositorios principales y excepciones controladas, el programa habrá superado la barrera más difícil: pasar de la intención al hábito.

Glosario mínimo

Retención: criterio que define cuánto tiempo se conserva una categoría de datos según su finalidad y contexto operativo.

Borrado: eliminación del dato de sistemas activos conforme a la política aplicable, sin asumir necesariamente desaparición instantánea de todas las copias técnicas.

Anonimización: tratamiento por el cual el dato deja de poder vincularse razonablemente a una persona o entidad concreta para el uso previsto.

Responsable del dato: responsable de negocio que decide la utilidad, reglas base y excepciones de una categoría de información.

Excepción: autorización temporal y justificada para conservar datos fuera de la regla general.

Legal hold: instrucción formal para suspender temporalmente el borrado ordinario por una necesidad legal, investigativa o regulatoria.

La conclusión operativa es simple: la mejor política de retención no es la más extensa, sino la que consigue que la organización deje de guardar información sin propósito. Menos datos inútiles significa menos exposición potencial, menos coste de gestión y menos caos cuando llega una auditoría, una incidencia o una decisión difícil. Una política mínima bien gobernada no resuelve todo, pero sí cambia algo decisivo: por fin alguien sabe qué conservar, qué eliminar y bajo qué condiciones hacer una excepción.