Concepto de retención y eliminación para la documentación de TI: aplicar plazos de conservación conformes a requisitos de compliance

Un concepto de retención y eliminación para la documentación de TI parece a primera vista «papeleo». Sin embargo, en auditorías, ante incidentes de seguridad o cambios de personal queda claro rápidamente: sin plazos de conservación definidos, sin reglas de eliminación trazables y sin responsabilidades claras, la documentación se convierte en un riesgo. Una conservación demasiado prolongada aumenta la superficie de ataque, el volumen de datos y el esfuerzo de eDiscovery; una eliminación prematura pone en riesgo la capacidad de prueba, la continuidad operativa y obligaciones legales.

Este artículo describe cómo la dirección de TI, Compliance, Protección de Datos y Security deben diseñar un concepto de retención y eliminación para la documentación de TI que siga siendo practicable en el día a día: con una lógica de decisión clara, gobernanza, perspectiva de auditoría, elementos de plantilla, bloques técnicos de implementación y mecanismos de control. El enfoque está en tipos de documentación que realmente existen en las empresas: documentación de sistemas y arquitectura, manuales de operación, evidencias de cambios y aprobaciones, conceptos de permisos, registros, runbooks, comprobantes de proveedores así como entradas de tickets y de la base de conocimientos.

Por qué la documentación de TI necesita reglas de retención propias

La documentación de TI no es un conjunto de datos homogéneo. A menudo contiene contenidos mixtos: información técnica (configuraciones, IPs, topologías), material relevante para la seguridad (material de claves, accesos de emergencia), datos personales (nombres en tickets, contactos, hilos de correo) y, en ocasiones, referencias contractuales o financieras (aceptaciones, pruebas de prestación). Precisamente esta mezcla complica la retención: no existe un único plazo de conservación aplicable a todos.

Conflictos típicos que surgen en la práctica sin un concepto:

• Auditoría vs. minimización: La auditoría y el ISMS (Informationssicherheits-Managementsystem) requieren evidencias; la protección de datos exige minimización de datos y conservación con finalidad determinada.
• Base de conocimiento vs. Security: Operaciones quiere runbooks completos; Security no quiere contraseñas permanentes, tokens de emergencia ni planes de ataque explotables en texto claro.
• Historial de cambios vs. esfuerzo de mantenimiento: La trazabilidad exige historial; los equipos pierden tiempo si los documentos antiguos no están correctamente etiquetados o no se retiran automáticamente.

Un concepto de retención y eliminación no resuelve estos conflictos con «más reglas», sino mediante categorías decidibles y ciclos de vida automatizables —con excepciones definidas (p. ej., Legal Hold) y controles verificables.

Clasificación normativa y regulatoria: qué impulsa realmente

Para la documentación de TI operan varios tipos de requisitos. Importante: por lo general imponen obligaciones de trazabilidad y objetivos de protección, pero rara vez un número concreto «X años» aplicable a todos los documentos. Por ello deben traducirse a un reglamento interno.

Protección de datos (DSGVO): limitación del almacenamiento y obligaciones de eliminación

El RGPD exige, entre otras cosas, limitación del almacenamiento (no conservar los datos más tiempo del necesario) y integridad/confidencialidad. Para la documentación de TI esto es relevante en cuanto contiene datos personales (p. ej. tickets de incidentes, registros con IDs de usuario, listas de contactos). Consecuencia práctica: necesita una clasificación de datos, una finalidad vinculada y reglas de eliminación o anonimización que se puedan aplicar técnicamente.

Obligaciones de auditoría y pruebas: trazabilidad, inmutabilidad, localizabilidad

Independientemente del sector, los auditores internos/externos exigen para los procesos TI esenciales evidencias: aprobaciones, documentación de cambios, conceptos de permisos, pruebas de contingencia, acreditaciones de proveedores, seguimiento de riesgos y de medidas. «Revisionssicher» significa en esencia: los documentos son localizables, completos, cronológicamente clasificables y están protegidos contra manipulaciones no detectadas (p. ej. mediante versionado, firmas/hashes o almacenamiento WORM, es decir «write once, read many»).

ISMS/Seguridad de la información: necesidad de protección y eliminación controlada

Un ISMS (p. ej. según la lógica de ISO 27001) requiere procesos documentados, roles, tratamiento de riesgos y evidencias, pero sobre todo: un trato conforme al nivel de protección de la información. Para la documentación eso implica: clasificar, controlar accesos, registrar acciones (Audit-Log) y eliminación segura (borrado, si procede borrado criptográfico). El borrado no debe significar solo “desaparecer”, sino que debe ser demostrable y reproducible.

Aclarar el alcance: ¿Qué artefactos cuentan como documentación de TI?

Antes de debatir plazos, hay que definir el alcance. En los proyectos esto es uno de los errores más comunes: los equipos piensan en páginas de wiki, los auditores en todo lo que documente una decisión o una operación de funcionamiento.

Un alcance práctico para un concepto de retención y eliminación normalmente incluye típicamente:

• Documentación de sistemas y arquitectura: arquitectura objetivo/real, descripciones de interfaces (API), flujos de datos, diagramas de red.
• Documentación operativa: runbooks, manuales de emergencia, instrucciones de Backup/RESTore, reglas de monitorización y alarmas.
• Evidencias de cambio y de release: requests, evaluaciones de riesgo, aprobaciones, recepciones, decisiones de rollback.
• Documentos de seguridad y permisos: conceptos de roles y derechos, recertificaciones, estándares de hardening, autorizaciones de excepción.
• Tickets y base de conocimiento: incidentes, problemas, solicitudes de servicio, errores conocidos, análisis de causa raíz.
• Evidencias de proveedores y operación: SLAs, ventanas de mantenimiento, acreditaciones de seguridad, registros de comunicación.

No todo se trata igual: en particular los tickets suelen contener datos personales y deberían tener plazos distintos que las decisiones de arquitectura o los conceptos de contingencia.

Lógica de decisión: De la clase de documento al período de conservación

En vez de negociar documentos individuales, funciona una matriz de retención: categoría de documento → necesidad de protección → propósito/evidencia → periodo de conservación → modo de eliminación/archivo → rol responsable → regla de Legal Hold.

Cuatro preguntas que deciden cada categoría

1. ¿Qué obligación o qué propósito exige la conservación? (p. ej. evidencia de cambios, seguridad operativa, cuestiones contractuales/ de responsabilidad)
2. ¿Cuál es la necesidad de protección? (confidencialidad/integridad/disponibilidad; especialmente crítico en accesos de administrador, material de claves, información sobre vulnerabilidades)
3. ¿Con qué rapidez queda obsoleto el contenido? (Los runbooks pueden volverse incorrectos y peligrosos tras una migración de plataforma)
4. ¿Cómo se detecta el „End of Life“? (Sistema fuera de servicio, contrato finalizado, ticket cerrado + X meses, cambio sustituido)

Perfiles de retención típicos para documentación TI (como plantilla)

Los perfiles siguientes están formulados deliberadamente como ayuda para la toma de decisiones. Debe ajustar los plazos concretos a su normativa interna, su sector y sus contratos. Lo importante es la lógica subyacente: la relevancia como prueba y el riesgo determinan la conservación, no la conveniencia.

• Decisiones de arquitectura y fundamentos del sistema: conservación al menos durante el ciclo de vida del sistema más un periodo de transición definido, ya que sirven para respaldar migraciones, análisis de incidentes y cuestiones de responsabilidad. Archivado con historial de versiones, indicación clara «válido hasta» y «reemplazado por».
• Runbooks de operación y procesos de emergencia: conservar mientras sean válidos; las versiones antiguas solo si se requieren como evidencia (p. ej., para auditorías de simulacros). En caso contrario, eliminarlas de forma controlada, porque las instrucciones desactualizadas pueden causar daños reales en situaciones críticas.
• Evidencias de cambios y aprobaciones: conservación conforme a los sistemas de control internos y ciclos de revisión; a menudo se requieren varios años para que los auditores puedan evaluar la eficacia de los controles. Aquí la inmutabilidad/integridad es especialmente importante.
• Tickets (Incidente/Servicio): diferenciar: incidentes puramente técnicos sin datos personales frente a tickets con datos personales. Para estos últimos establecer reglas claras de borrado/anonimización tras el cumplimiento del propósito y el vencimiento de períodos de garantía/necesidades de evidencia. Adjuntos (logs, capturas de pantalla) deben considerarse por separado.
• Excepciones de seguridad y permisos temporales: retención corta para contenidos operativos, pero conservación de la autorización como evidencia por más tiempo. Contenidos como contraseñas de emergencia no deben formar parte de la documentación permanente, sino almacenarse en sistemas controlados y específicos (p. ej., bóveda de contraseñas) con su propia política de retención.

Gobernanza: roles, responsabilidades y aprobaciones

Sin gobernanza, un concepto de borrado queda en teoría. Es fundamental que la retención no la decida «TI» en solitario, sino que se gestione como un control compartido entre TI, Compliance/Revision, protección de datos y seguridad de la información.

Modelo de roles (compatible con RACI)

• Responsable de la categoría de documentos (Business/IT): define el propósito, los requisitos mínimos de contenido y los criterios de «End of Life».
• Responsable de seguridad de la información: establece la clasificación, el modelo de acceso, las medidas de protección y los métodos seguros de borrado.
• Protección de datos (si hay datos personales): revisa la limitación del propósito, la limitación de almacenamiento y las medidas de anonimización/p seudonimización.
• Compliance/Revision: define los requisitos de evidencia, la conservación mínima, las trazas de auditoría y la lógica de muestreo.
• Operación TI/Equipos de plataforma: implementan las políticas técnicas (almacenamiento de archivo, etiquetas de retención, copias de seguridad, registro de eventos).
• Legal (en caso de Legal Hold): gestiona excepciones, periodos de bloqueo y la autorización para reanudar el borrado.

Gestión de cambios para las reglas de retención

Las políticas de retención son relevantes para el control. Los cambios deben tratarse como cambios de configuración: solicitud documentada, justificación, evaluación de riesgo, aprobación e historial de versiones. Esto reduce hallazgos de auditoría del tipo «la retención se cambió de forma ad hoc».

Implementación técnica: desde etiquetas hasta borrado seguro

Un concepto de retención y eliminación rara vez fracasa por falta de herramientas, sino por la ausencia de metadatos y de límites de sistema coherentes. Por tanto, la implementación debe ser pragmática: pocos mecanismos robustos que funcionen en todos los repositorios relevantes.

Metadatos como factor clave: sin clasificación no hay automatización

Como mínimo son necesarios:

• Categoría de documento (p. ej., «registro de cambios», «Runbook», «arquitectura»)
• Responsable (rol/equipo, no solo persona)
• Clase de protección (p. ej., interno, confidencial, estrictamente confidencial)
• Estado de vigencia (borrador, vigente, reemplazado, fuera de servicio)
• Etiqueta de retención (Policy-ID) y fecha de inicio (p. ej., «ticket cerrado el …»)

Si su documentación vive en varios sistemas (wiki, DMS, sistema de tickets, Git, fileshares), estos metadatos deben ser o bien representables entre sistemas o bien debe definir de forma consciente qué sistemas son «System of Record» para cada categoría.

Archivo vs. Copia de seguridad vs. Repositorio en vivo: suposiciones frecuentes

En auditorías, «tenemos copias de seguridad» no sustituye la archivación. Una copia de seguridad sirve para la recuperación, no para la conservación dirigida y a largo plazo. A la inversa, un archivo no es un plan de recuperación ante desastres. Guía práctica:

• Repositorio en vivo: documentación operativa y actual; acceso rápido, modificaciones permitidas.
• Archivo: para evidencias; más bien inmutable, versionado, con registro de auditoría; búsqueda y exportación dirigidas posibles.
• Copia de seguridad: respaldo en un punto del tiempo; incluye también datos eliminados hasta que expire la retención de las copias.

Para los conceptos de eliminación es especialmente importante cómo se tratan las copias de seguridad: la eliminación en el repositorio en vivo no implica la supresión inmediata de las copias. Eso debe describirse de forma transparente en el concepto («eliminación efectiva en producción inmediata, eliminación completa de las copias tras X días/meses»).

Eliminación segura y «eliminación criptográfica»

En sistemas cloud y de almacenamiento, sobrescribir físicamente a menudo no es práctico o posible. En su lugar se utiliza frecuentemente la eliminación criptográfica: los datos se almacenan cifrados de modo que la eliminación de la clave hace que los datos sean prácticamente ilegibles. Esto sólo es fiable si la gestión de claves, el control de accesos y la generación de evidencias están en orden (p. ej., roles separados, ciclo de vida de claves documentado, registro de eventos).

Ejemplo: lógica de la política como borrador copiable (sin dependencia de herramientas)

Si documenta la retención como «política como texto», evita los silos de herramientas. El siguiente borrador puede servir como punto de partida para un documento de directrices interno.

POLICY-ID: DOC-RET-CHG-001
Kategorie: Registros de cambio y aprobación
Zweck: Nachvollziehbarkeit von Änderungen, Prüfbarkeit interner Kontrollen
Schutzklasse: Vertraulich
Aufbewahrung: 6 Jahre ab Abschluss des Changes (Status: geschlossen)
Ablage: Archivspeicher (unveränderbar), Referenzlink aus Ticketing/Wiki
Löschmodus: automatisiert nach Ablauf, außer bei Legal Hold
Legal Hold: Sperre durch Legal/Compliance, dokumentierter Start/Ende
Nachweis: Audit-Log der Archivierung und Löschung, monatlicher Report
Owner: IT Service Management
Freigabe Retention-Regel: Compliance + Informationssicherheit

Ejemplo: reglas de eliminación y anonimización para tickets (borrador copiable)

Los sistemas de ticketing son relevantes para auditoría, pero también contienen datos personales. A menudo es sensato combinar ambos enfoques: conservar los hechos técnicos y minimizar los contenidos personales.

POLICY-ID: DOC-RET-TCK-002
Kategorie: Incident- und Service-Tickets
Unterkategorie A: Tickets ohne personenbezogene Daten
  Aufbewahrung: 3 Jahre ab Schließung
  Löschmodus: automatisiert
Unterkategorie B: Tickets mit personenbezogenen Daten (z. B. Nutzeranfragen)
  Aufbewahrung: 12 Monate ab Schließung
  Maßnahme: Anonymisierung von Namen/E-Mail, Entfernen personenbezogener Anhänge
  Technische Kerndaten bleiben: Kategorie, System, Zeitstempel, Maßnahmen, RCA-Referenz
Unterkategorie C: sicherheitsrelevante Incidents (IR/Forensik)
  Aufbewahrung: nach IR- und Rechtsvorgaben; standardmäßig länger, strenge Zugriffskontrolle
Legal Hold: möglich in allen Unterkategorien
Owner: Service Desk / Incident Management
Freigabe: Datenschutz + Informationssicherheit + Compliance

Perspectiva de auditoría: qué evidencias esperan los revisores

En las auditorías rara vez se trata de si sus plazos son «bonitos», sino de si están justificados, implementados y controlados. Expectativas típicas:

• Matriz de retención documentada con categorías, plazos, responsables y excepciones.
• Prueba de la aplicación técnica: configuración del sistema, etiquetas, flujos de trabajo, permisos.
• Registros de auditoría: quién creó/modificó/eliminó qué; en áreas sensibles deben ser inmutables.
• Pruebas por muestreo: documentos/tickets individuales se revisan hacia atrás (existencia, integridad, estado de eliminación tras el plazo).
• Proceso de retención legal: desencadenante claro, autorizaciones, fin del bloqueo, comunicación documentada.

Un punto de control interno útil es una revisión trimestral de retención: no como una reunión de comité, sino como un procedimiento basado en informes (principales categorías, excepciones, retrasos en eliminaciones, etiquetas faltantes, sistemas sin aplicación).

Consecuencias en costes y operación: dónde la retención realmente mueve dinero y riesgo

La retención a menudo se asocia solo con el espacio de almacenamiento. Sin embargo, el mayor impacto reside en la operación, la seguridad y el esfuerzo de auditoría.

Costes directos

• Almacenamiento y ventanas de backup: más datos alargan los tiempos de copia de seguridad e incrementan los riesgos de RTO/RPO (tiempo de recuperación y pérdida máxima de datos).
• Costes de licencias/SaaS: muchos sistemas cobran según volumen o usuarios; los adjuntos históricos y los duplicados aumentan los costes.
• eDiscovery/búsqueda: cuanto mayor sea la montaña de datos, más cara será cada búsqueda en caso de litigio o auditoría.

Riesgos indirectos

• Superficie de ataque: planos de red antiguos, credenciales, análisis de vulnerabilidades o guías «Quick Fix» son valiosos para un atacante.
• Errores operativos: runbooks obsoletos y páginas «muertas» de Confluence conducen a actuaciones incorrectas bajo estrés.
• Hallazgos de auditoría: la falta de conceptos de eliminación y responsabilidades poco claras son observaciones recurrentes.

Plan de implementación pragmático en 6 pasos

La implementación funciona mejor de forma iterativa. El objetivo no es «perfecto», sino controlable y ampliable.

1. Definir inventario & sistemas: ¿Dónde se encuentra la documentación de TI (wiki, DMS, ticketing, fileshare, Git, CMDB)? ¿Qué categorías son críticas?
2. Definir clasificación y categorías: 8–15 categorías suelen ser suficientes para empezar. Demasiadas categorías impiden la automatización.
3. Decidir la matriz de retención: plazos, disparadores, responsable, Legal Hold, modo archivo/eliminación.
4. Priorizar la aplicación técnica: comience por donde el volumen y el riesgo son altos (adjuntos de tickets, runbooks antiguos, excepciones de seguridad).
5. Establecer controles e informes: informes mensuales/trimestrales, muestreos, KPIs (cobertura de etiquetas, retraso en eliminaciones, casos de Legal Hold).
6. Formación y transferencia operativa: instrucciones breves de actuación para autores y operadores („¿qué etiqueta cuándo?“), además de una escalación clara.

Lista de verificación: concepto de retención y eliminación para documentación de TI (auditable)

• Ámbito definido: tipos de documentos, sistemas, «System of Record» por categoría
• Modelo de categorías y clases de protección aprobado
• Matriz de retención: plazo, disparador, archivo/eliminación, responsable, aprobaciones, Legal Hold
• Estándar de metadatos: campos obligatorios y validación
• Aplicación técnica implementada en los sistemas centrales (etiquetas/políticas/flujos de trabajo)
• Retención de copias de seguridad y efecto de eliminación documentados de forma transparente
• Registros de auditoría y mecanismos de integridad (versionado, hash/firma o WORM) definidos
• Proceso para excepciones y Legal Hold establecido
• Plan de control: informes, muestreos, frecuencia de revisión, responsabilidades
• Guías de incorporación/autores para documentos nuevos y adjuntos de tickets

Errores frecuentes y cómo evitarlos

«Conservarlo todo, así estaremos seguros»

A menudo ocurre lo contrario: aumenta la superficie de ataque y la carga de auditoría. La seguridad surge de cadenas de prueba claras y una reducción controlada, no de la acumulación ilimitada.

«La eliminación es asunto de la herramienta»

Las herramientas solo pueden ejecutar lo que usted define como categorías, metadatos y disparadores. Sin puntos de inicio claros („¿a partir de cuándo empieza el plazo?“) la eliminación queda al azar.

«Las copias de seguridad resuelven la retención»

Las copias de seguridad son puntuales y difíciles de borrar selectivamente. Por eso, un buen concepto describe explícitamente cómo interactúan la eliminación y la retención de copias de seguridad.

«Ninguna responsabilidad porque es ’solo documentación’»

Precisamente la documentación de TI contiene conocimiento operativo y de seguridad. Sin un responsable no hay una decisión sólida sobre cuándo algo puede eliminarse o debe conservarse.

Conclusión: la retención es un instrumento de control, no un proyecto de archivo

Un concepto de retención y eliminación para la documentación de TI tiene éxito cuando logra tres cosas a la vez: mantiene evidencias disponibles para auditoría y operación, reduce los volúmenes de datos innecesarios y disminuye los riesgos de seguridad mediante la eliminación controlada. La clave está en pocas categorías claras, disparadores fiables, una matriz de retención apta para gobernanza y la aplicación técnica incluida la generación de informes.

Si aborda el tema, no empiece por „fijar años“, sino por el alcance, las categorías y las responsabilidades. Los plazos derivan entonces del propósito, la necesidad de evidencia y el nivel de protección — y pueden cumplirse realmente en la operación.

Para este tema también son importantes los plazos de conservación de la documentación de TI y el concepto de eliminación de la documentación. El artículo sitúa estos aspectos de forma clara y muestra en qué hay que fijarse en la práctica.