Clasificación de datos para ISO 27001, GDPR, NIS2 y DORA
El momento de auditoría de 2026: «Muéstreme las evidencias»
Es febrero de 2026 y la reunión trimestral del consejo de administración de una empresa fintech SaaS de rápido crecimiento no transcurre con la fluidez que el CISO esperaba.
La empresa ha obtenido recientemente la certificación ISO/IEC 27001:2022. Cuenta con MFA, protección de endpoints, escaneos de vulnerabilidades, revisiones de acceso, procedimientos de respuesta a incidentes y un informe pulido de preparación para DORA. Entonces, el CEO formula la pregunta que cambia el tono de la sala.
«Nuestro inversor principal pregunta cómo podemos demostrar que los datos financieros de clientes están protegidos de forma coherente en AWS, Azure, nuestra plataforma SaaS de soporte y el almacén analítico. Si un auditor extrae un archivo del almacenamiento de objetos y otro de una carpeta de colaboración, ¿cómo sabemos que ambos están gobernados por las mismas reglas?»
El CISO abre el registro de activos. Enumera bases de datos, cuentas en la nube, aplicaciones, plataformas SaaS y ubicaciones de almacenamiento. Pero el campo de clasificación está incompleto. Algunas carpetas están nombradas por departamento, no por sensibilidad. Las exportaciones de clientes conviven con archivos internos de reporting. Algunas hojas de cálculo de soporte contienen identificadores de clientes, referencias de pago y notas de caso, pero están etiquetadas como «internas». Existen reglas de DLP, pero solo se activan ante patrones evidentes. La política de nube establece que los datos personales de la UE deben permanecer en regiones aprobadas, pero el equipo no puede demostrar que las reglas de residencia de los datos se basen en metadatos de clasificación.
Entonces, el responsable de cumplimiento añade el ángulo regulatorio: «¿Esto satisfará GDPR Article 32, NIS2 Article 21 y las evidencias de riesgo TIC de DORA?»
La respuesta honesta es: todavía no.
Esta es la brecha de 2026 a la que se enfrentan muchas organizaciones. Tienen controles de seguridad, pero no la capa de gobierno que indica a cada control qué debe proteger, con qué nivel de rigor y cómo debe demostrarse. Esa capa de gobierno es la clasificación de datos y el etiquetado de la información.
En términos de ISO/IEC 27001:2022, la clasificación y el etiquetado no son prácticas cosméticas de gestión documental. Son el puente operativo entre evaluación de riesgos, control de acceso, cifrado, conservación, DLP, residencia de datos en la nube, diligencia debida de proveedores, supervisión y notificación de incidentes. En el modelo de implantación de Clarysec, se sitúan en el centro de la cadena de evidencias del SGSI: inventariar el activo, asignar un propietario, clasificarlo, etiquetarlo, aplicar reglas de manejo, supervisar excepciones y mostrar la trazabilidad a los auditores.
Por qué la clasificación y el etiquetado son ahora controles de nivel consejo
Reguladores y clientes esperan cada vez más que las organizaciones demuestren que las medidas de seguridad son adecuadas a la sensibilidad de los datos, la criticidad del servicio y el impacto que un fallo tendría en las operaciones de la organización.
GDPR lo hace explícito mediante la responsabilidad proactiva. Article 5 exige que los datos personales se traten de forma lícita, leal y transparente, se limiten a lo necesario, se conserven solo durante el tiempo requerido y se protejan mediante medidas técnicas y organizativas adecuadas. El responsable del tratamiento también debe poder demostrar el cumplimiento. GDPR Article 32 resulta difícil de evidenciar si no se conoce qué sistemas tratan datos personales, qué datos son de alto riesgo o de categoría especial, dónde se almacenan y qué salvaguardas aplican.
NIS2 eleva el listón del gobierno. Article 20 exige que los órganos de dirección de entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, seguridad en la adquisición y el desarrollo, evaluación de la eficacia, higiene cibernética, formación, criptografía, seguridad de recursos humanos, control de acceso y gestión de activos. La clasificación no es una casilla independiente en esa lista. Es el sistema de decisión que hace que esas medidas sean proporcionadas.
DORA aplica la misma lógica a las entidades financieras y a los ecosistemas fintech. Desde el 17 de enero de 2025, DORA exige un marco de gestión del riesgo TIC documentado, responsabilidad del órgano de dirección, políticas de confidencialidad, integridad, disponibilidad y autenticidad, clasificación de incidentes, pruebas de resiliencia y gestión del riesgo de terceros TIC. Para las entidades financieras sujetas a DORA, DORA puede operar como el acto jurídico sectorial de la Unión que sustituye obligaciones solapadas de gestión de riesgos y notificación de NIS2, pero la expectativa de evidencias sigue siendo la misma: mostrar cómo se identifican, protegen, prueban, supervisan y gobiernan la información crítica y los activos TIC.
ISO/IEC 27001:2022 es especialmente adecuada como sistema operativo para estas evidencias. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, los requisitos de las partes interesadas, las obligaciones regulatorias y contractuales y las interfaces con otras organizaciones. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, selección de controles, una Declaración de Aplicabilidad y evidencias conservadas. ISO/IEC 27001:2022
Si GDPR, NIS2 y DORA preguntan: «¿Por qué aplicaron estas medidas?», ISO/IEC 27001:2022 ayuda a responder: «Porque estos activos, tipos de datos, riesgos, obligaciones y decisiones de tratamiento nos llevaron hasta aquí».
La clasificación es la decisión de riesgo. El etiquetado es la señal operativa.
Clarysec separa clasificación y etiquetado porque los auditores también lo hacen.
La clasificación es el acto de decidir la sensibilidad, el valor y la criticidad de la información. El etiquetado es el acto de hacer que esa decisión sea visible, persistente y aplicable en las operaciones diarias.
La Política de Clasificación y Etiquetado de Datos - SME de Clarysec establece claramente el propósito:
Esta política define cómo debe clasificarse y etiquetarse toda la información manejada por la organización para garantizar que su confidencialidad, integridad y disponibilidad se mantengan durante todo su ciclo de vida.
La misma Política de Clasificación y Etiquetado de Datos - SME exige a las organizaciones:
Exigir que cada activo de datos se clasifique según su sensibilidad y se etiquete en consecuencia para orientar su manejo, almacenamiento y acceso adecuados.
Para entornos empresariales, la P13 Política de Clasificación y Etiquetado de Datos de Clarysec define el modelo mínimo de clasificación:
La organización debe mantener un esquema de clasificación estandarizado con niveles claramente definidos. Como mínimo, deben utilizarse los siguientes niveles de clasificación: 5.1.1 Público: Información destinada a publicación abierta y distribución sin restricciones 5.1.2 Interno: Información no pública de la organización no destinada a divulgación externa 5.1.3 Confidencial: Datos sensibles de la organización, contractuales o de clientes que requieren control de acceso estricto 5.1.4 Restringido (o altamente confidencial): Información crítica o regulada cuya divulgación no autorizada podría causar daños significativos o responsabilidad legal
Esa distinción importa. Una clasificación «Confidencial» puede requerir cifrado, acceso basado en roles y salvaguardas contractuales. Una clasificación «Restringido» puede activar MFA, aprobación del CISO para el intercambio externo, registro ampliado, gobernanza de conservación más estricta, segregación y escalado prioritario de incidentes.
La política empresarial es explícita sobre el etiquetado operativo:
Todos los activos de información deben etiquetarse de una manera que sea: 6.2.1.1 Persistente: No fácilmente eliminable ni anulable 6.2.1.2 Visible: Clara para los usuarios en el punto de uso 6.2.1.3 Legible por máquina: Cuando sea posible, debe admitirse el etiquetado basado en metadatos
Las etiquetas legibles por máquina son el punto en el que el programa madura desde la concienciación hasta la aplicación efectiva. Si las etiquetas están basadas en metadatos, las plataformas en la nube, los sistemas DLP, las pasarelas de correo electrónico, las herramientas de identidad, las reglas SIEM, las plataformas CASB y los motores de conservación pueden actuar sobre ellas. Si las etiquetas son solo un pie de página en un documento, pueden ayudar a los usuarios, pero no pueden aplicar reglas de forma fiable a escala.
Dónde encaja la clasificación en la hoja de ruta de Clarysec
El Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec sitúa la clasificación en una fase temprana del ciclo de vida de la gestión de riesgos, no después del despliegue tecnológico. En la fase de gestión de riesgos, paso 9, «Identificación de activos, amenazas y vulnerabilidades», la hoja de ruta dirige a los equipos a inventariar los activos de información y registrar propietario, ubicación y clasificación.
Esto evita un fallo habitual: tener un inventario de nube, pero no un inventario de información. Una base de datos, un tenant SaaS o un almacén de datos son activos tecnológicos. Los registros de clientes, expedientes de empleados, registros de pagos, conjuntos de datos de entrenamiento de modelos, transcripciones de soporte y evidencias de incidentes que contienen son activos de información. La clasificación vive en ese nivel de información.
La guía de Zenith Blueprint sobre el control 5.12 de ISO/IEC 27002:2022, Clasificación de la información, explica el principio:
Todo control de seguridad de la información escrito alguna vez —restricción de acceso, cifrado, copia de seguridad, supervisión o eliminación— presupone una cosa: que la organización sabe qué está protegiendo. El control 5.12 exige que la información se clasifique en función de su valor, sensibilidad y criticidad, constituyendo la base de todas las decisiones posteriores dentro del SGSI.
Para el control 5.13 de ISO/IEC 27002:2022, Etiquetado de la información, la misma hoja de ruta convierte la clasificación en conducta diaria:
El etiquetado es la forma de convertir una política abstracta en realidad operativa. Es el momento en el que un usuario, al ver un documento, correo electrónico, campo de base de datos o informe impreso, puede identificar de un vistazo: qué es esa información, cuán sensible es y cómo debe tratarse.
La conexión final de la hoja de ruta aparece en el paso 13, «Planificación del tratamiento de riesgos y Declaración de Aplicabilidad». Zenith Blueprint describe la SoA como el puente entre riesgos, tratamientos y controles. Aquí es donde la clasificación se convierte en trazabilidad de auditoría. Un escenario de riesgo como «divulgación no autorizada de datos financieros de clientes desde almacenamiento compartido en la nube» puede mapearse con clasificación, etiquetado, control de acceso, cifrado, registro de eventos, DLP, uso de la nube, requisitos de proveedores y respuesta a incidentes.
Las relaciones de control que los auditores esperan ver
En Zenith Controls: la guía de cumplimiento cruzado de Clarysec, el control 5.12 de ISO/IEC 27002:2022, Clasificación de la información, se mapea como control preventivo que respalda la confidencialidad, la integridad y la disponibilidad. Se asocia con el concepto de ciberseguridad Identificar, la capacidad operativa de protección de la información y los dominios de seguridad Protección y Defensa.
Para el control 5.13 de ISO/IEC 27002:2022, Etiquetado de la información, Zenith Controls mapea el control como preventivo, centrado en Proteger, con las mismas propiedades de seguridad de la información y la misma capacidad operativa de protección de la información.
La idea crítica es que la clasificación y el etiquetado no están aislados. Hacen defendibles los controles adyacentes.
| Área de control de ISO/IEC 27002:2022 | Por qué depende de la clasificación o del etiquetado | Evidencias que puede solicitar un auditor |
|---|---|---|
| 5.9 Inventario de información y otros activos asociados | Los metadatos de clasificación deben ser un campo central del inventario de activos | Registro de activos que muestre propietario, ubicación, estado del ciclo de vida y clasificación |
| 5.12 Clasificación de la información | Define sensibilidad, valor y criticidad | Esquema de clasificación aprobado, criterios, ejemplos y registros de revisión |
| 5.13 Etiquetado de la información | Hace visible y aplicable la clasificación | Configuración de etiquetas, muestras de archivos etiquetados, etiquetas de correo electrónico, tags SaaS y guía para usuarios |
| 5.14 Transferencia de información | Determina si se requiere intercambio externo, cifrado o aprobación | Reglas de transferencia por clasificación, canales aprobados y registros de excepciones |
| 5.15 Control de acceso | Los permisos de acceso deben seguir los límites de clasificación | Matriz de roles, revisiones de acceso, reglas de acceso privilegiado e historial de aprobaciones |
| 5.25 Evaluación y decisión sobre eventos de seguridad de la información | La severidad del incidente depende en parte de la sensibilidad de los datos afectados | Criterios de triaje de incidentes que utilizan clasificación y criticidad del servicio |
| 5.34 Privacidad y protección de PII | Las categorías de datos personales requieren un manejo específico de privacidad | Registro de PII, mapeo de base jurídica, reglas de conservación y controles de encargados del tratamiento |
| 8.15 Registro de eventos | El acceso a datos Restringidos requiere mayor trazabilidad | Registros de acceso a datos, ajustes de conservación de registros y evidencias de revisión |
| 8.16 Actividades de supervisión | La prioridad de supervisión cambia cuando se accede a datos Restringidos | Casos de uso de SIEM, umbrales de alerta y registros de escalado |
Zenith Controls mapea el control 5.12 con GDPR Article 32 y Recital 83, NIS2 Article 21(2)(a) y 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 y PM-11, FIPS 199 y NIST SP 800-60, y COBIT 2019 DSS06.06 y APO13.01. Mapea el control 5.13 con GDPR Article 32, NIS2 Article 21(2)(a) y 21(2)(f), DORA Article 9(1) y 9(2), NIST SP 800-53 MP-3 y COBIT 2019 DSS06.06.
Esto significa que un único conjunto de evidencias puede responder a múltiples preguntas de aseguramiento.
| Impulsor de cumplimiento | Contribución de la clasificación y el etiquetado | Prueba práctica |
|---|---|---|
| GDPR Article 32 | Muestra qué datos personales requieren salvaguardas de confidencialidad, integridad, disponibilidad y resiliencia | Clasificación de PII, reglas de cifrado, restricciones de acceso, mapeo de conservación y criterios de triaje de brechas |
| NIS2 Article 21 | Respalda análisis de riesgos, políticas de seguridad, evaluación de la eficacia, control de acceso, gestión de activos y medidas proporcionadas | Política aprobada por la dirección, inventario de activos, formación, métricas de revisión y reglas de manejo probadas |
| Gestión del riesgo TIC de DORA | Respalda la identificación y protección de información y activos TIC, la clasificación de incidentes y el riesgo de terceros TIC | Registro de activos TIC, criticidad de los datos, requisitos contractuales de proveedores, alcance de pruebas y criterios de severidad de incidentes |
| NIST CSF 2.0 | Respalda resultados de GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER | Perfiles actuales y objetivo con deficiencias de clasificación y acciones de remediación priorizadas |
| COBIT 2019 | Respalda controles de gobierno y de proceso para seguridad, manejo de datos y operación de controles | Objetivos de control, propiedad del proceso, pruebas de aseguramiento y gestión de excepciones |
El registro de activos es donde la clasificación se convierte en evidencia
Muchos programas de clasificación fallan porque el esquema de clasificación existe solo en una política. El enfoque de Clarysec comienza con el inventario de activos.
La P12 Política de Gestión de Activos de Clarysec exige que el inventario de activos incluya el nivel de clasificación como campo mínimo:
El inventario de activos debe contener, como mínimo: 5.3.1 Identificador, categoría y tipo de activo 5.3.2 Número de serie o etiqueta única (para activos físicos) 5.3.3 Versión de software o clave de licencia (para activos de software) 5.3.4 Propietario del activo 5.3.5 Nivel de clasificación (Público, Interno, Confidencial, Restringido) 5.3.6 Ubicación (física, virtual, nube) 5.3.7 Estado del ciclo de vida (activo, en mantenimiento, retirado)
Esto se alinea directamente con la planificación de riesgos de ISO/IEC 27001:2022. Si no puede identificar el activo de información, su propietario, ubicación y clasificación, no puede evaluar de forma coherente la probabilidad, el impacto, la prioridad de tratamiento o el riesgo residual. Tampoco puede decidir con confianza si un acuerdo con un proveedor, un servicio en la nube o una integración SaaS afecta a información regulada.
Para GDPR, esto respalda la responsabilidad proactiva. Los registros de actividades de tratamiento de Article 30 y las medidas de seguridad de Article 32 ganan credibilidad cuando el registro de activos identifica dónde se tratan los datos personales y cómo se protegen. Para DORA, el mismo registro respalda la criticidad de activos y servicios TIC, el alcance de las pruebas de resiliencia y el análisis de dependencias de terceros. Para NIS2, respalda análisis de riesgos, control de acceso y gestión de activos.
| Campo | Entrada de ejemplo |
|---|---|
| Nombre del activo | Base de datos de facturación de clientes |
| Propietario del activo | Responsable de ingeniería de plataforma |
| Proceso de la organización | Facturación de suscripciones y emisión de facturas |
| Ubicación | Región de nube de la UE, servicio de base de datos gestionado |
| Clasificación | Restringido |
| Categorías de datos | Identificadores de clientes, datos de contacto de facturación, referencias de transacciones |
| Relevancia para GDPR | Datos personales, contextos de responsable y encargado del tratamiento |
| Criticidad | Respalda operaciones de ingresos y servicio al cliente |
| Controles clave | MFA, cifrado en reposo, cifrado en tránsito, aprobación de acceso privilegiado, registro de auditoría, pruebas de copia de seguridad |
| Dependencia de proveedor | Proveedor de base de datos en la nube, procesador de pagos |
| Cadencia de revisión | Revisión de acceso trimestral, revisión anual de clasificación, revisión ante cambio del sistema |
Este tipo de registro cambia el tono de una auditoría. En lugar de decir «creemos que los datos sensibles están protegidos», la organización puede mostrar qué datos son, quién los posee, por qué son Restringidos, qué controles aplican y cuándo se revisaron por última vez esos controles.
Las etiquetas deben impulsar las reglas de manejo en la nube y SaaS
La mayoría de los datos sensibles se mueven hoy por plataformas en la nube, aplicaciones SaaS, canalizaciones analíticas y herramientas de colaboración. Una política que indique a los usuarios «manejar los datos confidenciales con cuidado» no basta.
La P27 Política de Uso de la Nube de Clarysec conecta directamente el uso de la nube con la clasificación y la residencia de los datos:
Clasificación y residencia de los datos 6.6.1 Ningún dato podrá trasladarse a una plataforma en la nube sin clasificación conforme a la Política de Clasificación y Etiquetado de Datos (P13). 6.6.2 Los requisitos de residencia de los datos deben aplicarse contractualmente (por ejemplo, almacenamiento solo en la UE para datos regulados por GDPR). 6.6.3 Las transferencias transfronterizas de datos deben cumplir GDPR Chapter V y, cuando corresponda, DORA Article 28.
Esto importa porque el riesgo en la nube suele entrar por conveniencia. Un equipo exporta un conjunto de datos a una nueva herramienta analítica. Ventas sincroniza listas de clientes con una plataforma de automatización. Un desarrollador copia datos de producción a un entorno de prueba. Sin clasificación y etiquetado, estas acciones pueden no activar revisión legal, aprobación de seguridad o comprobaciones de proveedores.
La Política de Clasificación y Etiquetado de Datos - SME ofrece a organizaciones más pequeñas un patrón simple de implantación:
Las carpetas compartidas o unidades en la nube deben usar nombres de carpeta o etiquetas para indicar la clasificación (por ejemplo, «/Clients_Confidential»).
En entornos maduros, los nombres de carpeta deben complementarse con etiquetas legibles por máquina, políticas de acceso condicional, bloqueos de intercambio externo, cifrado, etiquetas de conservación, reglas DLP y registro de eventos. El objetivo no es simplemente etiquetar información. El objetivo es hacer que la etiqueta sea accionable.
Una etiqueta «Restringido» puede activar bloqueos de intercambio externo, cifrado en reposo y en tránsito, MFA, restricciones de descarga en dispositivos no gestionados, conservación de registros de auditoría, alertas SIEM, reglas de conservación, límites de ubicación de proveedores y escalado de severidad de incidentes.
La P13 Política de Clasificación y Etiquetado de Datos establece la base:
Todo manejo de datos, transmisión, acceso, almacenamiento y eliminación de información debe alinearse con su nivel de clasificación. Como mínimo: 6.3.1.1 Público: Puede divulgarse libremente; no requiere manejo especial 6.3.1.2 Interno: Compartido dentro de la organización; almacenado en sistemas internos seguros 6.3.1.3 Confidencial: 6.3.1.3.1 Acceso restringido únicamente a personal autorizado 6.3.1.3.2 Debe cifrarse en tránsito y en reposo 6.3.1.3.3 Solo puede compartirse externamente bajo un NDA o salvaguardas contractuales equivalentes 6.3.1.4 Restringido: 6.3.1.4.1 Aplican los requisitos de seguridad más estrictos 6.3.1.4.2 Se requieren controles de acceso sólidos, autenticación multifactor y registro de auditoría 6.3.1.4.3 Segregación física y lógica cuando sea viable 6.3.1.4.4 El intercambio externo está prohibido sin aprobación del CISO
Cada etiqueta tiene un comportamiento. Cada comportamiento tiene un control. Cada control tiene evidencias.
Un ejemplo práctico de aplicación
Considere a un analista fintech que crea Q3_2026_Customer_Churn_Analysis.xlsx. La hoja de cálculo incluye identificadores de clientes, volúmenes de transacción y puntuación predictiva de abandono.
El analista la clasifica como Confidencial porque contiene datos de clientes y análisis estratégico. Utilizando la herramienta de protección de la información de la empresa, el analista aplica la etiqueta Confidencial. Como la etiqueta es persistente, visible y legible por máquina, los controles se activan automáticamente.
El archivo se cifra en reposo en el dispositivo y en el almacenamiento en la nube. Un encabezado visible lo marca como Confidencial. Cuando el analista intenta sincronizarlo con una unidad personal en la nube, una regla DLP bloquea la acción y registra el intento. Cuando el analista intenta enviarlo por correo electrónico a un dominio externo que no es socio, la pasarela de correo electrónico pone el mensaje en cuarentena y alerta a operaciones de seguridad. Si el archivo se reclasifica posteriormente como Restringido porque contiene datos regulados de transacciones financieras, el intercambio externo se deshabilita salvo que el CISO o el propietario de la información aprueben la excepción.
Esta es la prueba que quería el CEO. Es trazable, automatizada y está vinculada a una política aprobada por el consejo de administración. También se alinea con la P27 Política de Uso de la Nube, porque no se permite ningún movimiento a la nube sin clasificación y las transferencias transfronterizas deben cumplir GDPR Chapter V y, cuando corresponda, DORA Article 28.
Construya una matriz de clasificación a controles en una semana
Un programa completo requiere tiempo, pero un sprint focalizado puede crear la columna vertebral de evidencias antes de una auditoría, una revisión de cliente o una evaluación regulatoria.
Día 1: Confirmar el esquema de clasificación
Empiece con cuatro niveles: Público, Interno, Confidencial y Restringido. Use la P13 Política de Clasificación y Etiquetado de Datos como base. Defina criterios usando impacto en las operaciones de la organización, impacto legal, sensibilidad contractual, riesgo de datos personales, criticidad del servicio y perjuicio financiero.
| Clasificación | Ejemplos habituales | Lógica de riesgo |
|---|---|---|
| Público | Contenido de marketing aprobado, comunicados de prensa, ofertas de empleo | Destinado a distribución sin restricciones |
| Interno | Procedimientos internos, notas de proyecto, anuncios internos | Información no pública de la organización |
| Confidencial | Contratos de clientes, expedientes de recursos humanos, información financiera no pública | Datos sensibles de la organización, contractuales o de clientes |
| Restringido | Datos personales de categoría especial, datos de pago, secretos de autenticación, bases de datos de clientes de producción | Información crítica o regulada con impacto legal u operativo significativo |
Día 2: Seleccionar diez activos de información críticos
Use el paso 9 de Zenith Blueprint. Incluya una base de datos de clientes, sistema de tickets de soporte, plataforma de recursos humanos, proveedor de identidad, exportación de pagos, almacén de datos, bucket de almacenamiento de objetos, carpeta de reporting del consejo de administración, repositorio de código fuente y repositorio de evidencias de incidentes. Registre propietario, ubicación, clasificación y relevancia para GDPR.
Día 3: Mapear reglas de manejo
Defina requisitos de manejo para acceso, almacenamiento, transferencia, supervisión y eliminación.
| Clasificación | Acceso | Almacenamiento | Transferencia | Supervisión | Eliminación |
|---|---|---|---|---|---|
| Público | Roles de publicación abiertos o aprobados | Canales públicos aprobados | Sin restricción especial tras la aprobación | Supervisión básica de integridad | Eliminación estándar |
| Interno | Empleados y contratistas aprobados | Sistemas gestionados | Canales internos | Registros de acceso estándar | Calendario de conservación estándar |
| Confidencial | Acceso por necesidad de conocer | Repositorios seguros aprobados | Cifrado y NDA o salvaguardas contractuales | Revisión de acceso y alertas DLP | Borrado seguro |
| Restringido | Mínimo privilegio con MFA y aprobación del propietario | Sistemas segregados o bastionados | Intercambio externo prohibido salvo aprobación | Registro de auditoría reforzado y alertas SIEM | Destrucción segura verificada |
Día 4: Configurar una ruta de aplicación técnica
Elija una plataforma, como un repositorio documental en la nube, un sistema de correo electrónico o un servicio de almacenamiento de objetos. Implemente etiquetas visibles y legibles por máquina. Configure una regla para datos Confidenciales y otra para datos Restringidos. Por ejemplo, exija cifrado para correos externos Confidenciales y bloquee el intercambio externo de archivos Restringidos.
Día 5: Actualizar el registro de riesgos y la SoA
Use el paso 13 de Zenith Blueprint. Añada los controles de clasificación y etiquetado a la Declaración de Aplicabilidad. Vincúlelos a riesgos como divulgación no autorizada, configuración incorrecta de la nube, sobreexposición frente a proveedores, fallo de conservación de datos y subnotificación de incidentes.
Día 6: Probar el control
Cree un archivo de prueba etiquetado como Restringido. Intente compartirlo externamente desde un dispositivo no gestionado. Confirme si la herramienta bloquea, advierte, registra o escala. Capture capturas de pantalla, entradas de registro y evidencias de tickets. Si el control falla, registre la excepción y el plan de remediación.
Día 7: Formar a los usuarios de primera línea
La formación debe ser específica por rol. Los desarrolladores deben saber cuándo no pueden usarse datos de producción en entornos de prueba. Recursos humanos debe entender por qué los expedientes de empleados son Confidenciales o Restringidos. Ventas debe saber por qué las exportaciones de clientes no pueden cargarse en herramientas SaaS no aprobadas. La alta dirección debe entender por qué los paquetes para el consejo de administración, los expedientes de adquisición y los datos de inversores requieren un manejo más estricto.
Este sprint no completa todo el programa, pero crea la columna vertebral de evidencias: política, inventario, etiquetas, reglas de manejo, aplicación técnica, trazabilidad del riesgo y formación.
Cómo probarán los auditores la clasificación y el etiquetado
Los auditores rara vez prueban la clasificación de forma aislada. Siguen los datos.
Un auditor de ISO/IEC 27001:2022 conectará la clasificación con el alcance del SGSI, los requisitos de partes interesadas, las obligaciones legales y contractuales, la evaluación de riesgos y la Declaración de Aplicabilidad. Esperará evidencias para los controles 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 de ISO/IEC 27002:2022 y los controles técnicos pertinentes. Las evidencias habituales incluyen políticas aprobadas, registros del inventario de activos, entradas del registro de riesgos, muestras etiquetadas, reglas de manejo, revisiones de acceso, hallazgos de auditoría interna y acciones correctivas.
Un revisor de GDPR se centrará en los datos personales. Preguntará si los datos personales están identificados, si los datos de categoría especial se distinguen, si las reglas de conservación se alinean con la finalidad y si las medidas de seguridad de Article 32 son adecuadas. La clasificación ayuda a separar la información ordinaria de la organización de los datos personales, datos personales sensibles, datos confidenciales de clientes y registros regulados. El etiquetado ayuda a los equipos operativos a evitar divulgaciones accidentales, conservación excesiva y transferencias no autorizadas.
Un evaluador de NIST CSF 2.0 probablemente encuadrará la clasificación bajo GOVERN, IDENTIFY y PROTECT. Puede preguntar si los perfiles actuales y objetivo definen el descubrimiento de datos sensibles, si la aplicación de etiquetas funciona en sistemas SaaS y en la nube, si los proveedores manejan los datos de acuerdo con la clasificación y si las prioridades de supervisión se ajustan en función de la sensibilidad.
Un auditor de COBIT 2019 o de estilo ISACA enfatizará objetivos de gobierno, propiedad de procesos, diseño de controles y eficacia operativa. Zenith Controls mapea el control de inventario 5.9 con COBIT 2019 BAI09.01, BAI09.02 y DSS05.04, y referencia ISACA ITAF 2204 y 2301. Para clasificación, Zenith Controls mapea el control 5.12 con COBIT 2019 DSS06.06 y APO13.01, mientras que el etiquetado se mapea con DSS06.06. El auditor preguntará quién es propietario del proceso, cómo se aprueban las excepciones, si se supervisa el desempeño y si la dirección recibe informes.
Un revisor centrado en DORA preguntará qué activos de información respaldan funciones críticas o importantes, qué datos son Restringidos, qué proveedores terceros TIC almacenan o transmiten esos datos, si los contratos definen ubicaciones y medidas de seguridad, si las pruebas se acotan a datos críticos y si los incidentes se clasifican parcialmente por pérdida de datos en disponibilidad, autenticidad, integridad y confidencialidad.
Si las respuestas proceden de un único modelo de evidencias de activos y proveedores impulsado por la clasificación, las auditorías se vuelven más rápidas, más coherentes y más defendibles.
Patrones habituales de fallo
Los fallos de clasificación suelen producirse porque las organizaciones tratan las etiquetas como herramientas de concienciación en lugar de señales de control.
Primero, clasifican documentos, pero no bases de datos, interfaces de programación de aplicaciones, registros, copias de seguridad, exportaciones o registros SaaS. Los datos sensibles en una salida de depuración pueden ser tan perjudiciales como los datos sensibles en una hoja de cálculo.
Segundo, etiquetan información, pero no conectan las etiquetas con el control de acceso. Una etiqueta Restringido con acceso abierto demuestra que la organización conocía la sensibilidad y no aplicó la regla de manejo.
Tercero, las migraciones a la nube se producen antes de la clasificación. Los equipos trasladan datos a nuevas herramientas SaaS sin confirmar residencia de los datos, términos de proveedores, acceso de subencargados, requisitos de transferencias transfronterizas o derechos de supresión. La P27 Política de Uso de la Nube aborda directamente este punto al prohibir el traslado a plataformas en la nube sin clasificación.
Cuarto, los planes de respuesta a incidentes ignoran la clasificación. Si los criterios de severidad no incluyen la sensibilidad de los datos, los equipos de incidentes pierden tiempo descubriendo qué se vio afectado durante una crisis. El análisis de brechas de GDPR, la gestión de incidentes de NIS2 y la clasificación de incidentes de DORA se benefician de un contexto de datos rápido.
Quinto, la SoA no explica por qué los controles de clasificación y etiquetado son aplicables. La organización puede haber implantado etiquetas, pero la SoA no las conecta con GDPR Article 32, NIS2 Article 21, el riesgo TIC de DORA, los contratos con clientes o escenarios de riesgo específicos.
Informes a la dirección: hacer visible la clasificación
NIS2 y DORA convierten la ciberseguridad en una cuestión de responsabilidad de la dirección. ISO/IEC 27001:2022 también exige compromiso de liderazgo, alineación de políticas, recursos, roles e informes de desempeño. Por tanto, las métricas de clasificación deben llegar a la revisión por la dirección.
Entre las métricas útiles se incluyen:
- Porcentaje de activos de información críticos con propietarios asignados.
- Porcentaje de activos con clasificación aprobada.
- Número de activos Restringidos sin registro ampliado.
- Número de repositorios Confidenciales o Restringidos con intercambio externo habilitado.
- Porcentaje de proveedores que tratan datos Confidenciales o Restringidos con cláusulas contractuales actualizadas.
- Número de excepciones de clasificación y acciones de remediación vencidas.
- Incidentes DLP por etiqueta.
- Finalización de revisiones de acceso para activos Restringidos.
- Ubicaciones de almacenamiento en la nube para datos regulados por GDPR.
- Ejercicios de respuesta a incidentes que usaron criterios de severidad basados en clasificación.
Estas métricas respaldan la revisión por la dirección de ISO/IEC 27001:2022, la supervisión de la dirección exigida por NIS2, los informes de gobierno de DORA y el aseguramiento de clientes. También hacen que la clasificación sea comprensible para la alta dirección. El liderazgo puede actuar más rápido cuando observa que múltiples repositorios Restringidos carecen de recuperación probada o que proveedores críticos tratan datos de clientes sin almacenamiento confirmado en la UE.
De la política a la prueba
El patrón de implantación de Clarysec está guiado por evidencias:
- Defina el esquema de clasificación en la P13 Política de Clasificación y Etiquetado de Datos o comience con la Política de Clasificación y Etiquetado de Datos - SME.
- Añada la clasificación al inventario de activos utilizando la P12 Política de Gestión de Activos.
- Aplique restricciones de nube y requisitos de residencia de los datos mediante la P27 Política de Uso de la Nube.
- Use el paso 9 de Zenith Blueprint para identificar activos de información, propietarios, ubicaciones y sensibilidad.
- Use el paso 13 de Zenith Blueprint para mapear riesgos con controles en la SoA.
- Use el paso 22 de Zenith Blueprint para implantar los controles 5.12 y 5.13 de ISO/IEC 27002:2022 en las operaciones diarias.
- Use Zenith Controls para mapear las mismas evidencias con GDPR, NIS2, DORA, NIST CSF, COBIT 2019 y normas de apoyo.
- Pruebe la aplicación de etiquetas, las restricciones de acceso, el registro de eventos, DLP y el triaje de incidentes.
- Informe del desempeño de clasificación a la dirección.
- Revise la clasificación tras cambios importantes en sistemas, procesos, proveedores o regulaciones.
Esto funciona porque la clasificación se convierte en el lenguaje común entre valor para la organización, obligación legal, control técnico y evidencia de auditoría.
Si su organización se está preparando para la certificación ISO/IEC 27001:2022, aseguramiento de GDPR, preparación para NIS2, diligencia debida de clientes DORA o una auditoría de cumplimiento combinada, empiece con una pregunta:
¿Puede mostrar, para cada activo de información crítico, qué es, quién lo posee, dónde está, cómo está clasificado, cómo está etiquetado, quién puede acceder a él, cómo está protegido, cuánto tiempo se conserva, qué proveedor lo toca y qué ocurre si queda expuesto?
Si la respuesta es todavía no, Clarysec puede ayudarle a construir la cadena de evidencias de forma rápida y defendible.
Use la Política de Clasificación y Etiquetado de Datos - SME, la P13 Política de Clasificación y Etiquetado de Datos, la P12 Política de Gestión de Activos, la P27 Política de Uso de la Nube, Zenith Blueprint: hoja de ruta de 30 pasos para auditores y Zenith Controls: la guía de cumplimiento cruzado para convertir la clasificación de una política estática en una capa operativa de control para GDPR Article 32, la gestión de riesgos cibernéticos de NIS2 y las evidencias de riesgo TIC de DORA.
El mejor momento para clasificar los datos fue antes de que llegara la solicitud de auditoría. El siguiente mejor momento es antes de la próxima migración a la nube, incorporación de proveedores, cuestionario de cliente o incidente.
Frequently Asked Questions
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
