Gobernanza del ciclo de vida de los datos ISO 27001 para 2026

María, directora de seguridad de la información de una fintech en rápido crecimiento, tuvo uno de esos viernes por la tarde que convierten una brecha de cumplimiento en un problema para el consejo de administración.
La empresa acababa de expandirse a nuevos mercados de la UE. Los ingresos aumentaban, la incorporación de clientes se aceleraba y cada semana se añadían nuevas herramientas SaaS. Entonces llegaron tres mensajes casi al mismo tiempo.
El equipo jurídico advirtió que las autoridades de protección de datos estaban intensificando la aplicación del RGPD de la UE en materia de limitación del plazo de conservación. Cumplimiento le recordó que las obligaciones de riesgo relacionado con las TIC de DORA ya eran una realidad operativa. El consejo preguntó si la exposición de la organización a NIS2, incluidos los requisitos de proveedores y ciberhigiene, estaba bajo control.
Después, un cliente solicitó la supresión de su cuenta y de todos los datos personales asociados.
La solicitud, aparentemente sencilla, se convirtió en una carrera interfuncional. Jurídico indicó que algunos registros podían ser necesarios para una disputa contractual. Finanzas señaló que los registros exigidos por ley debían conservarse. Producto confirmó que los datos del cliente existían en la base de datos de producción, la plataforma de analítica, los tickets de soporte, el almacenamiento de objetos, los registros de Kubernetes, las instantáneas de bases de datos y una herramienta de éxito de cliente de un tercero. Ingeniería de nube preguntó qué copias de seguridad contenían esos datos. El DPO preguntó si alguna copia seguía tratándose fuera de la UE. María pidió evidencias.
Finalmente, alguien dijo la frase que dejó al descubierto el problema real:
“No tenemos un único lugar donde este ciclo de vida sea visible.”
Ese es el problema de la gobernanza del ciclo de vida de los datos en 2026. No se trata solo de conservación de datos. Abarca clasificación, propiedad, base jurídica, acceso, ubicación, replicación, conservación de copias de seguridad, retención legal, baja de servicios en la nube, borrado por proveedores, revisión de archivos, evidencias de incidentes y eliminación jurídicamente defendible.
Para pymes, fintechs, proveedores de servicios gestionados, empresas cloud-first y organizaciones reguladas, el riesgo ya no es que falten datos. El riesgo es que los datos estén en todas partes: duplicados, obsoletos, con permisos excesivos, clasificados de forma insuficiente e imposibles de demostrar como eliminados.
Un programa maduro de gobernanza del ciclo de vida de los datos ISO 27001 transforma esa carrera improvisada en un flujo de trabajo controlado.
Por qué cambió la gobernanza del ciclo de vida de los datos en 2026
El RGPD de la UE, NIS2 y DORA suelen tratarse como tres listas de verificación de cumplimiento separadas. Ese es el modelo operativo equivocado. Son expresiones regulatorias distintas del mismo requisito de negocio: conocer los datos, protegerlos conforme al riesgo, conservarlos por el motivo correcto y demostrar qué ocurrió con ellos.
El Article 5 del RGPD de la UE exige que los datos personales se traten de forma lícita, leal y transparente, se recojan con fines determinados, se limiten a lo necesario, sean exactos, se conserven solo durante el tiempo necesario y se protejan frente al tratamiento no autorizado o ilícito, la pérdida accidental, la destrucción o el daño. El Article 5(2) añade responsabilidad proactiva, lo que significa que el responsable del tratamiento debe poder demostrar el cumplimiento. Por tanto, la gobernanza de la conservación del RGPD de la UE no es un ejercicio de hoja de cálculo. Requiere evidencias operativas.
NIS2 convierte la ciberseguridad en una cuestión del órgano de dirección. El Article 20 establece expectativas de gobernanza para los órganos de dirección, mientras que el Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Estas incluyen análisis de riesgos, políticas de seguridad de los sistemas de información, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, evaluación de la eficacia, ciberhigiene, formación, criptografía, control de acceso y gestión de activos. Los datos desconocidos u obsoletos no son solo un problema de privacidad. Son un problema de superficie de ataque.
DORA convierte la gestión del riesgo relacionado con las TIC, la resiliencia operativa y el riesgo de terceros proveedores de servicios TIC en obligaciones directamente exigibles para las entidades financieras. Los Articles 5 y 6 atribuyen responsabilidad al órgano de dirección y exigen un marco documentado de gestión del riesgo relacionado con las TIC. DORA también espera que las entidades financieras protejan la disponibilidad, autenticidad, integridad y confidencialidad de los datos, mantengan capacidades de gestión de incidentes, prueben la resiliencia y gobiernen las dependencias de terceros proveedores de servicios TIC.
DORA actúa, con carácter general, como el régimen sectorial específico para las obligaciones solapadas de ciberseguridad operativa de las entidades financieras, mientras que NIS2 sigue siendo relevante para el ecosistema más amplio, incluidos proveedores de servicios en la nube, proveedores de servicios gestionados y muchas organizaciones de infraestructura digital. Esto importa porque una fintech puede estar directamente sujeta a DORA, mientras que su proveedor SaaS o de servicios gestionados puede estar dentro del perímetro NIS2.
ISO/IEC 27001:2022 es el sistema de gestión que puede integrar estas obligaciones. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, las partes interesadas, los requisitos legales y contractuales y el alcance del SGSI. Las cláusulas 5.1 a 5.3 exigen liderazgo, roles y responsabilidades. Las cláusulas 6.1.2 y 6.1.3 exigen evaluación de riesgos de seguridad de la información, tratamiento de riesgos, selección de controles, comparación con el Anexo A e información documentada conservada.
Esta estructura explica por qué ISO 27001 no es “otra lista de verificación”. Es el sistema operativo de la gobernanza del ciclo de vida de los datos.
El modelo de ciclo de vida: siete preguntas que todo propietario de datos debe responder
Un modelo práctico de gobernanza del ciclo de vida de los datos debe responder siete preguntas para cada categoría de datos importante:
- ¿Qué datos son?
- ¿Por qué los tratamos?
- ¿Quién es su propietario?
- ¿Qué nivel de sensibilidad tienen?
- ¿Dónde residen y dónde se replican?
- ¿Durante cuánto tiempo deben conservarse o quedar suspendidos de borrado?
- ¿Cómo los protegemos, revisamos, borramos y demostramos lo ocurrido?
El enfoque de Clarysec conecta estas preguntas con los controles ISO 27001 y las evidencias operativas. En Zenith Blueprint: hoja de ruta de 30 pasos para auditores, la fase Controls in Action trata el inventario de activos y la clasificación como bases operativas, no como documentación formal sin uso. El paso 22 explica que el inventario debe incluir activos físicos, activos digitales, activos lógicos, activos relacionados con servicios y personas en términos de responsabilidades, acceso y exposición.
El Zenith Blueprint establece:
“Cada activo debe tener un propietario definido, no la persona que lo usa, sino quien rinde cuentas de su uso, protección y ciclo de vida.”
Esa frase es el punto de inflexión. La gobernanza del ciclo de vida de los datos falla cuando la propiedad se asigna a “TI” o “el negocio”. Funciona cuando un propietario responsable nominal puede aprobar la clasificación, la conservación, el acceso, las decisiones de retención legal, la revisión de archivos y las evidencias de borrado.
La Política de Gestión de Activos - pyme de Clarysec refuerza la misma disciplina:
“La propiedad, el propósito, los privilegios de acceso y los plazos de revisión deben documentarse.”
Este requisito aparece en la Política de Gestión de Activos - pyme, sección “Requisitos de implementación de la política”, cláusula 6.6.2. Sin propiedad y propósito, la conservación se convierte en una conjetura y el borrado en una actividad peligrosa.
La clasificación es el primer control de conservación
Muchas organizaciones intentan crear calendarios de conservación antes de disponer de una clasificación fiable. Normalmente, eso falla.
Si una exportación de soporte al cliente, un documento de recursos humanos, un registro de transacción o un registro de aplicación no está clasificado, la organización no puede decidir de forma coherente quién debe acceder a él, dónde puede almacenarse, si puede utilizarse en pruebas, con qué solidez debe cifrarse, si requiere protección por retención legal o cómo debe borrarse.
La Política de Clasificación y Etiquetado de Datos - pyme de Clarysec es directa:
“Todos los documentos, archivos y sistemas deben clasificarse tan pronto como se creen o reciban.”
Esto aparece en la Política de Clasificación y Etiquetado de Datos - pyme, sección “Requisitos de implementación de la política”, cláusula 6.1.1.
La Política de Clasificación y Etiquetado de Datos empresarial conecta la clasificación con toda la cadena de tratamiento:
“Todo el manejo, transmisión, acceso, almacenamiento y eliminación de la información debe ajustarse a su nivel de clasificación. Como mínimo:”
Esto aparece en la Política de Clasificación y Etiquetado de Datos, sección “Requisitos de implementación de la política”, cláusula 6.3.1.
El Zenith Blueprint añade orientación de implementación para el control ISO/IEC 27002:2022 5.12, Clasificación de la información. Un esquema de clasificación debe definir niveles como Público, Uso interno, Confidencial y Restringido, incluir criterios basados en el daño derivado del acceso no autorizado, la pérdida o la modificación, aplicarse a todas las formas de información y permanecer independiente del formato o la ubicación de almacenamiento.
En términos sencillos, la clasificación sigue al contenido, no a la ubicación de almacenamiento.
Un conjunto de datos restringido no pasa a tener menor riesgo porque se haya movido de una base de datos a una herramienta SaaS de analítica. Un registro sujeto a retención legal no pierde su condición porque se haya exportado a CSV. Los datos personales no dejan de estar regulados porque aparezcan dentro de un mensaje de registro.
La clasificación debe convertirse en metadatos del registro de activos, el registro de conservación, el mapa de datos, la revisión de accesos, la lista de verificación de incorporación a la nube y el registro de eliminación.
La columna vertebral de controles ISO 27001 para la gobernanza del ciclo de vida
Los programas de ciclo de vida de los datos más eficaces tienen una columna vertebral de controles. Esa columna conecta controles ISO/IEC 27002:2022 con evidencias operativas.
Zenith Controls: guía de cumplimiento cruzado de Clarysec proporciona la guía de cumplimiento cruzado para este trabajo. Para la gobernanza del ciclo de vida de los datos, tres controles son centrales: 5.33 Protección de registros, 5.34 Privacidad y protección de información de identificación personal (PII), y 8.10 Borrado de información.
En Zenith Controls, el control ISO/IEC 27002:2022 5.33, Protección de registros, se describe mediante atributos de controles preventivos que apoyan la confidencialidad, la integridad y la disponibilidad, con capacidades operativas en jurídico y cumplimiento, gestión de activos y protección de la información. Se conecta con copia de seguridad, clasificación, eliminación segura de equipos, requisitos legales y regulatorios, cumplimiento de políticas, control de acceso y respuesta a incidentes.
El control 5.34, Privacidad y protección de información de identificación personal (PII), apoya la confidencialidad, la integridad y la disponibilidad. Zenith Controls lo vincula con inventario de activos, enmascaramiento de datos, seguridad en la nube, clasificación, transferencia de información, control de acceso, gestión de identidades y revisión de seguridad de proyectos y cambios.
El control 8.10, Borrado de información, es preventivo y se centra en la confidencialidad. Zenith Controls lo conecta con etiquetado, transferencia de información, propiedad intelectual, acceso privilegiado, enmascaramiento de datos, prevención de pérdida de datos (DLP), protección de registros, gestión de configuraciones y cumplimiento de políticas y estándares.
En conjunto, estos controles crean la cadena del ciclo de vida.
| Etapa del ciclo de vida | Enfoque principal de control ISO/IEC 27002:2022 | Qué debe demostrar la organización |
|---|---|---|
| Crear o recibir datos | 5.9 inventario, 5.12 clasificación | Los datos están identificados, clasificados y asignados a un propietario responsable |
| Usar y compartir datos | 5.14 transferencia de información, 5.15 control de acceso, 5.16 gestión de identidades | El acceso y la transferencia corresponden a la sensibilidad, el rol y el propósito |
| Almacenar y archivar datos | 5.33 protección de registros, 8.13 copia de seguridad de información | Los registros están protegidos, son recuperables y tienen controles de integridad |
| Tratar PII | 5.34 privacidad y protección de información de identificación personal (PII) | La información de identificación personal (PII) se minimiza, se protege y se gobierna conforme a una finalidad lícita |
| Usar nube y SaaS | 5.23 servicios en la nube, 5.19 relaciones con proveedores | Se conocen los controles del proveedor, las ubicaciones, los contratos y las obligaciones de borrado |
| Conservar o suspender el borrado | 5.31 requisitos legales, 5.33 protección de registros | Se aplican calendarios de conservación y retenciones legales |
| Borrar o eliminar | 8.10 borrado de información, 7.14 eliminación segura o reutilización de equipos | El borrado es seguro, completo, registrado y verificado |
Esta tabla no es solo para auditores. Es un modelo operativo para CISO, DPO, responsables de cumplimiento y propietarios de negocio que necesitan un lenguaje común de gobernanza para privacidad, ciberseguridad y resiliencia.
Construir el registro de conservación antes del proceso de borrado
Un proceso de borrado sin un registro de conservación es peligroso. Puede eliminar registros que deben preservarse, omitir datos que deberían borrarse o no distinguir entre borrado operativo y suspensión por retención legal.
La Política de conservación de datos y eliminación segura - pyme de Clarysec establece la base:
“Se establece y mantiene un registro de conservación que enumera las categorías clave de registros, los requisitos legales y los períodos de conservación asignados.”
Esto aparece en la Política de conservación de datos y eliminación segura - pyme, sección “Requisitos de gobernanza”, cláusula 5.1.1.
Para programas empresariales, la Política de conservación y eliminación de datos de Clarysec define el objetivo:
“Establecer y aplicar calendarios de conservación coherentes basados en la clasificación de la información, el tipo de activo, las leyes aplicables y la exposición al riesgo.”
Esto aparece en la Política de conservación y eliminación de datos, sección “Objetivos”, cláusula 3.3.
Un registro de conservación utilizable debe conectar realidades legales, operativas, de seguridad y de nube.
| Campo del registro de conservación | Por qué importa |
|---|---|
| Categoría de registro | Agrupa los datos en clases de ciclo de vida, como recursos humanos, clientes, registros de seguridad o registros financieros |
| Propietario de negocio | Asigna responsabilidad sobre las decisiones de conservación y borrado |
| Sistema o repositorio | Identifica dónde reside el registro fehaciente |
| Réplicas y sistemas posteriores | Captura herramientas de analítica, exportaciones SaaS, registros, almacenes de datos y copias de seguridad |
| Clasificación | Determina el nivel de protección, acceso y rigor del borrado |
| Indicador de PII o categoría especial | Apoya decisiones de RGPD de la UE, EIPD y controles de privacidad |
| Base jurídica o finalidad del tratamiento | Vincula la conservación con la responsabilidad proactiva del RGPD de la UE |
| Período de conservación | Define la duración normal del ciclo de vida |
| Estado de retención legal | Evita la destrucción indebida |
| Método de borrado | Define borrado seguro, borrado criptográfico, anonimización o destrucción física |
| Ubicación de evidencias | Apunta a registros de eliminación, tickets, certificados o informes automatizados |
| Frecuencia de revisión | Evita calendarios obsoletos y deriva de archivo |
Un registro de conservación de una fintech pequeña podría incluir:
| Tipo de registro | Clasificación | Período de conservación | Base legal o justificación | Método de eliminación |
|---|---|---|---|---|
| Documentos KYC de clientes | PII Confidencial | 5 años tras el cierre de la cuenta | Expectativa de conservación de AMLD Article 40 | Borrado criptográfico |
| Registros de auditoría del sistema | Confidencial | 12 meses continuos | Riesgo relacionado con las TIC, investigación de incidentes y evidencias DORA | Sobrescritura segura o caducidad gestionada de registros |
| Registros de consentimiento de marketing | PII de uso interno | Consentimiento activo más 1 año | Evidencia de consentimiento de GDPR Article 7 | Borrado estándar con pista de auditoría |
| Documentos sujetos a retención legal | Variable | Hasta que se levante la retención | Preservación legal, de investigación o de auditoría | No se permite la eliminación |
El punto importante es que la conservación debe basarse en riesgos y estar respaldada por evidencias. La limitación del plazo de conservación del RGPD de la UE exige que los datos personales no se conserven más tiempo del necesario, pero también permite la conservación cuando exista una obligación lícita o una necesidad legítima. NIS2 espera gestión de activos, control de acceso y ciberhigiene. DORA espera gestión documentada del riesgo relacionado con las TIC y disciplina de continuidad. El registro de conservación es donde estas obligaciones se convierten en decisiones.
Las retenciones legales deben integrarse en los sistemas, no gestionarse por correo electrónico
Un programa maduro de ciclo de vida debe borrar los datos cuando ya no sean necesarios, pero no debe borrar registros sujetos a retención legal, investigación o preservación de auditoría.
La Política de conservación de datos y eliminación segura - pyme es explícita:
“Ningún registro sujeto a retención legal y suspensión del borrado puede destruirse ni alterarse, aunque su período de conservación haya vencido.”
Esto aparece en la Política de conservación de datos y eliminación segura - pyme, sección “Requisitos de implementación de la política”, cláusula 6.3.4.
La Política de conservación y eliminación de datos empresarial aplica el mismo principio de gobernanza:
“Si se emite una retención legal y suspensión del borrado (por ejemplo, litigio pendiente, investigación o auditoría), los datos que de otro modo estarían sujetos a destrucción deben preservarse más allá de su período normal de conservación.”
Esto aparece en la Política de conservación y eliminación de datos, sección “Requisitos de implementación de la política”, cláusula 6.4.1.
La retención legal no debe ser un correo electrónico que puede llegar o no a los administradores de sistemas. Debe ser un estado en el registro de conservación, vinculado a sistemas, categorías de registros, custodios y automatización del borrado.
Un flujo de trabajo de retención legal defendible incluye:
- Desencadenante, como litigio, requerimiento regulatorio, incidente de seguridad, auditoría o investigación interna
- Propietario de la retención, normalmente jurídico o cumplimiento
- Categorías de registros, sistemas y custodios afectados
- Instrucciones de suspensión para trabajos de borrado, caducidad de copias de seguridad y depuración de archivos
- Restricciones de acceso para preservar la integridad
- Revisión periódica de la retención
- Aprobación de liberación y retorno documentado a la conservación normal
- Evidencia de qué se preservó, por quién y cuándo
Esto es especialmente importante durante la respuesta a incidentes. Registros, imágenes, exportaciones y comunicaciones pueden requerir preservación aunque la conservación normal haya vencido. El borrado debe estar lo bastante controlado como para detenerse, justificarse y reanudarse.
El borrado en nube y SaaS es donde se rompe la gobernanza del ciclo de vida
En 2026, la mayoría de las organizaciones no pierden el control del ciclo de vida en su base de datos principal. Lo pierden en buckets de almacenamiento en la nube, exportaciones SaaS, plataformas de soporte, adjuntos de CRM, espacios de colaboración, registros de API, almacenes de datos, instantáneas y bóvedas de copias de seguridad.
El Zenith Blueprint, fase Controls in Action, paso 23, que cubre el control ISO/IEC 27002:2022 5.23, Seguridad de la información para el uso de servicios en la nube, advierte que los proveedores de servicios en la nube protegen la infraestructura, pero el cliente sigue siendo responsable de los datos, las configuraciones, las políticas de acceso y la preparación para la respuesta a incidentes. Buckets mal configurados, paneles públicos y permisos IAM excesivos en la nube son fallos de gobernanza, no fallos del proveedor.
También establece que el uso de la nube debe tratarse como parte del SGSI. Las organizaciones deben clasificar los servicios en la nube, comprender los datos tratados o almacenados en ellos, evaluar la postura del proveedor, establecer cláusulas contractuales y gestionar cambios o ampliaciones de alcance.
La Política de Uso de la Nube - pyme de Clarysec lo traduce en requisitos de baja:
“Confirmación de procedimientos de borrado seguro antes del cierre de la cuenta”
Esto aparece en la Política de Uso de la Nube - pyme, sección “Requisitos de implementación de la política”, cláusula 6.3.5.
La Política de Uso de la Nube empresarial exige gobernanza sobre:
“Propiedad de los datos y devolución o borrado tras la terminación”
Esto aparece en la Política de Uso de la Nube, sección “Requisitos de gobernanza”, cláusula 5.4.1.
Para las entidades financieras reguladas por DORA, esto no es higiene opcional. El DORA Article 28 exige gestión del riesgo de terceros proveedores de servicios TIC, un registro de acuerdos contractuales de TIC, diligencia debida precontractual, consideración del riesgo de concentración, derechos de auditoría y acceso, derechos de terminación y estrategias de salida para servicios TIC que soporten funciones críticas o importantes. El Article 30 exige términos contractuales que cubran descripciones de servicios, ubicaciones de tratamiento y almacenamiento, protecciones de disponibilidad, autenticidad, integridad y confidencialidad, acceso a datos, recuperación, devolución, asistencia ante incidentes y soporte de transición.
Para entidades NIS2, las decisiones sobre proveedores deben considerar la ciberseguridad de la cadena de suministro y las vulnerabilidades y resiliencia de productos y servicios. Por tanto, la gobernanza del ciclo de vida de los datos debe extenderse a los proveedores, no detenerse en la aprobación de contratación.
Un sprint de una semana para crear un paquete de controles de ciclo de vida
No empieces intentando mapear todos los sistemas de la empresa. Empieza con un flujo de datos de alto riesgo y crea un paquete de controles repetible.
Día 1: Seleccionar un flujo de datos de alto riesgo
Selecciona un flujo de datos significativo, como incorporación de clientes, baja de empleados, gestión de disputas de pago, gestión de tickets de soporte o registro de seguridad.
Para una fintech, la incorporación de clientes es una opción sólida porque puede incluir documentos de identidad, PII, registros de transacciones, señales de fraude, proveedores terceros de verificación, almacenamiento en la nube, acceso de soporte y conservación regulatoria.
Día 2: Construir el miniinventario de activos y datos
Usa el Zenith Blueprint, fase Controls in Action, paso 22, control ISO/IEC 27002:2022 5.9, para capturar activos físicos, digitales, lógicos, relacionados con servicios y basados en responsabilidades.
Documenta las categorías de datos recopiladas, los sistemas de registro, las plataformas SaaS que reciben copias, API, integraciones, roles de usuario, funciones privilegiadas, ubicaciones de copias de seguridad, ubicaciones de archivo, propietario de los datos, propietario del sistema, clasificación, indicadores de PII y dependencias de proveedores.
El objetivo no es la perfección. El objetivo es revelar puntos de replicación ocultos.
Día 3: Aplicar la lógica de clasificación y acceso
Aplica la Política de Clasificación y Etiquetado de Datos y clasifica cada categoría de datos. Después, verifica si los permisos de acceso reflejan la clasificación.
Los documentos restringidos de identidad de clientes no deberían estar ampliamente accesibles mediante herramientas de soporte. Los registros de seguridad que contienen identificadores no deberían exportarse de forma informal a hojas de cálculo no gestionadas. El acceso debe corresponder al rol, propósito, aprobación y evidencias de revisión.
Día 4: Crear entradas de conservación y retención legal
Usa la Política de conservación y eliminación de datos y la Política de conservación de datos y eliminación segura - pyme para crear entradas de conservación para cada categoría de registro. Incluye base jurídica, finalidad de negocio, requisito legal, período de conservación, método de borrado y estado de retención legal.
Si existe una disputa, incidente o investigación activa, marca la suspensión del borrado y registra al aprobador.
Día 5: Verificar el borrado en nube y proveedores
Usa la Política de Uso de la Nube y la Política de Uso de la Nube - pyme para revisar cada proveedor cloud o SaaS del flujo.
Confirma las condiciones de propiedad de los datos, devolución o borrado al terminar, plazos de borrado, comportamiento de borrado de copias de seguridad, implicaciones de subencargados, evidencias de borrado y obligaciones de asistencia ante incidentes.
Para entornos DORA, actualiza el registro de terceros proveedores de servicios TIC y el plan de salida. Para entornos NIS2, documenta las consideraciones de riesgo de proveedores y las dependencias de ciberhigiene.
Día 6: Definir evidencias y supervisión
Las evidencias no deben crearse después de la solicitud de auditoría. Defínelas durante el diseño del proceso.
La Política de conservación y eliminación de datos exige que la eliminación quede:
“Registrada en el registro de eliminación, incluido el identificador del activo, la clasificación, el método y el operador”
Esto aparece en la Política de conservación y eliminación de datos, sección “Requisitos de implementación de la política”, cláusula 6.5.3.2.
Un paquete sólido de evidencias incluye entradas del registro de conservación, resultados de revisiones de acceso, tickets de borrado, registros del registro de eliminación, confirmaciones de borrado en la nube, aprobaciones de retención legal, ajustes de conservación de copias de seguridad, cláusulas contractuales de proveedores y registros de revisión de archivo.
Día 7: Actualizar riesgos y la Declaración de Aplicabilidad
Actualiza el registro de riesgos ISO 27001 y la Declaración de Aplicabilidad. Si la revisión del ciclo de vida encontró exportaciones SaaS no gestionadas, conservación indefinida de copias de seguridad, acceso excesivo, términos de borrado poco claros o falta de propiedad, esos son riesgos que requieren tratamiento.
Este sprint de una semana crea un paquete de controles de ciclo de vida repetible. Repítelo para el siguiente flujo de datos y después para el siguiente.
Mapeo de cumplimiento cruzado: un programa de ciclo de vida, muchas obligaciones
El valor de la gobernanza del ciclo de vida de los datos ISO 27001 es que las mismas evidencias pueden apoyar expectativas de privacidad, ciberhigiene, riesgo relacionado con las TIC y auditoría.
| Área de obligación | Contribución de la gobernanza del ciclo de vida |
|---|---|
| RGPD de la UE | Apoya la base jurídica, la minimización, la limitación del plazo de conservación, la integridad y confidencialidad, la gestión de supresión y las evidencias de responsabilidad proactiva |
| NIS2 | Apoya el análisis de riesgos, las políticas de seguridad, la ciberhigiene, la gestión de activos, el control de acceso, la seguridad de proveedores, la continuidad y la preparación ante incidentes |
| DORA | Apoya la gobernanza del riesgo relacionado con las TIC, la confidencialidad e integridad de los datos, los registros de incidentes, las pruebas de resiliencia, los registros de terceros, la planificación de salida y los controles contractuales |
| NIST CSF 2.0 | Apoya los resultados GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER mediante perfiles, inventarios de datos, gestión de accesos, supervisión y recuperación |
| COBIT 2019 | Apoya la gobernanza de registros, riesgo, operaciones, información en reposo, privacidad y supervisión del cumplimiento |
NIST CSF 2.0 resulta útil para la comunicación con la alta dirección porque su función GOVERN espera que las obligaciones legales, regulatorias, contractuales y de privacidad se comprendan y gestionen, que se establezca el apetito de riesgo, que la responsabilidad del liderazgo sea clara, que las políticas se apliquen y que los resultados se revisen. Sus resultados de gestión de activos requieren inventarios y gestión del ciclo de vida de hardware, software, sistemas, servicios y datos.
COBIT 2019 añade lenguaje de gobernanza para consejos de administración y comités de auditoría. Zenith Controls mapea Protección de registros con procesos COBIT como gestionar copias de seguridad y restauración, gestionar la seguridad de la información en reposo y gestionar registros. Mapea Privacidad y protección de PII con privacidad, protección de la información y gobernanza del programa de privacidad. Mapea Borrado de información con objetivos de riesgo y operaciones, reforzando el borrado como un proceso gobernado y no como una tarea ad hoc de limpieza.
Qué probarán realmente los auditores
Un programa de gobernanza del ciclo de vida solo es creíble si supera las pruebas de auditoría.
Un auditor ISO/IEC 27001:2022 comenzará por el alcance, los requisitos de las partes interesadas, los riesgos, la Declaración de Aplicabilidad, la información documentada y las evidencias de control operativo. Para la gobernanza del ciclo de vida, cabe esperar muestreo. El auditor puede seleccionar un contrato, un registro de recursos humanos, un conjunto de registros o un registro financiero y trazarlo desde su creación, almacenamiento, copia de seguridad, acceso y eliminación.
Usando la perspectiva de auditoría de Zenith Controls para Protección de registros, los auditores comprueban si los registros dentro del alcance están identificados, si existen calendarios de conservación, cómo se almacenan los registros, cómo se controla el acceso y cómo se protege la integridad.
Para Borrado de información, Zenith Controls explica que los auditores revisan políticas de conservación y borrado, métodos de borrado, responsabilidades, registros de borrado, pistas de auditoría, certificados de destrucción de soportes y evidencias de herramientas de sanitización. También examinan si las copias de seguridad y los archivos están cubiertos.
Un auditor de privacidad o PII revisará políticas de privacidad, inventarios de datos, EIPD o evaluaciones de impacto sobre la privacidad, registros de formación y medidas técnicas como cifrado en reposo y en tránsito. Puede tomar como muestra una solicitud de derechos de los interesados, confirmar dónde existen los datos relevantes, verificar si se aplicó el borrado o la restricción, y comprobar que las excepciones como la retención legal estén justificadas.
Un evaluador orientado a NIST puede examinar la alineación con resultados de NIST CSF y controles técnicos como NIST SP 800-53 AU-11 Audit Record Retention, además de prácticas de saneamiento de medios basadas en NIST SP 800-88. Puede probar la restauración de copias de seguridad, inspeccionar reglas de conservación de registros, verificar el cifrado y comprobar si se minimiza la PII innecesaria.
Un auditor COBIT o ISACA se centrará en los procesos de gobernanza y la calidad de las evidencias. Preguntará quién es propietario de los registros, si los controles de procesos de negocio preservan la integridad, si la supervisión del cumplimiento detecta sobreconservación y si las operaciones incluyen tareas de borrado seguro.
Patrones comunes de fallo en la gobernanza del ciclo de vida
Clarysec observa con frecuencia los mismos patrones en pymes y organizaciones reguladas.
El primero es clasificación sin aplicación. Los datos se etiquetan como confidenciales, pero los derechos de acceso, el uso compartido en SaaS, las exportaciones y los métodos de borrado no cambian.
El segundo es conservación sin réplicas. El calendario cubre el sistema principal, pero no registros, copias de seguridad, almacenes de datos, exportaciones de soporte, hojas de cálculo o plataformas de terceros.
El tercero es baja de servicios en la nube sin prueba. El contrato dice que los datos se borrarán, pero nadie conoce el método de borrado, el plazo, el comportamiento de las copias de seguridad o el formato de las evidencias.
El cuarto es retención legal por correo electrónico. Jurídico envía instrucciones, pero los trabajos de borrado continúan porque ningún sistema operativo consume el estado de retención.
El quinto son evidencias de auditoría a posteriori. Los equipos reconstruyen manualmente evidencias de borrado y conservación, generando incoherencias y dudas evitables.
El sexto es resurrección desde copias de seguridad. Datos borrados de producción reaparecen durante restauraciones o pruebas porque la lógica de conservación y depuración de copias de seguridad nunca se alineó con la política de conservación de datos.
Cada fallo puede prevenirse cuando clasificación, inventario, conservación, gobernanza de nube, borrado y evidencias se diseñan como un único ciclo de vida.
El modelo operativo de gobernanza del ciclo de vida de los datos de Clarysec
El modelo de Clarysec es directo: establecer una columna vertebral de controles de ciclo de vida y adjuntarle obligaciones regulatorias y evidencias.
La columna vertebral de controles incluye:
- Inventario de activos y datos
- Propiedad y finalidad
- Clasificación y etiquetado
- Base jurídica y finalidad del tratamiento
- Registro de conservación
- Retención legal y suspensión del borrado
- Cláusulas de ciclo de vida para nube y proveedores
- Gobernanza de control de acceso y acceso privilegiado
- Reglas de copia de seguridad y archivo
- Borrado seguro y registro de eliminación
- Registro, supervisión y evidencias de incidentes
- Revisión periódica y actualizaciones de tratamiento de riesgos
El Zenith Blueprint proporciona la hoja de ruta de implementación mediante pasos Controls in Action para inventario, clasificación, gobernanza de la nube y borrado de información. Zenith Controls proporciona la guía de cumplimiento cruzado que muestra cómo los controles ISO/IEC 27002:2022 se conectan con el RGPD de la UE, NIS2, DORA, NIST, COBIT, ISO/IEC 27701, ISO/IEC 27018, ISO/IEC 27017, ISO/IEC 27040, ISO 15489 e ISO 22301. Las políticas de Clarysec proporcionan las cláusulas operativas que los equipos pueden implantar de inmediato.
La gobernanza del ciclo de vida no puede residir solo en privacidad, seguridad o TI. Debe ser un sistema de gestión compartido.
Si tu organización no puede responder dónde residen los datos regulados, quién es su propietario, cuánto tiempo se conservan, qué impide el borrado durante una retención legal, cómo se eliminan los datos SaaS y qué evidencias demuestran la eliminación, ahora es el momento de corregirlo.
Empieza con un flujo de datos de alto riesgo. Usa Zenith Blueprint: hoja de ruta de 30 pasos para auditores para construir la base de inventario y clasificación. Usa Zenith Controls: guía de cumplimiento cruzado para mapear Protección de registros, Privacidad y protección de PII y Borrado de información en RGPD de la UE, NIS2, DORA, NIST y COBIT. Después, implanta las políticas pertinentes de Clarysec, incluidas la Política de Clasificación y Etiquetado de Datos, la Política de conservación y eliminación de datos, la Política de Uso de la Nube y sus equivalentes para pymes cuando proceda.
El objetivo práctico no es conservar menos datos a ciegas. Es conservar los datos correctos, por el motivo correcto, bajo los controles adecuados, durante el tiempo adecuado, con evidencias que resistan ante clientes, reguladores, auditores y el consejo de administración.
Descarga los toolkits de políticas de Clarysec, mapea tus controles con Zenith Controls o usa el Zenith Blueprint para ejecutar tu primer sprint de controles de ciclo de vida antes de que la próxima solicitud de borrado se convierta en un hallazgo de auditoría.
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council