Evidencias de las MTO del artículo 32 del RGPD de la UE con ISO, NIS2 y DORA
El correo llega a la bandeja de entrada del CISO con el peso habitual de una oportunidad que podría cambiar el trimestre de la empresa.
Un gran cliente potencial empresarial solicita evidencias de “medidas técnicas y organizativas del artículo 32 del RGPD de la UE, mapeadas a ISO 27001:2022, NIS2 y DORA cuando sea aplicable”. Al mismo tiempo, el área legal ha informado al Consejo de Administración sobre la responsabilidad de la dirección en NIS2 y las expectativas de resiliencia operativa de DORA. La instrucción del Consejo de Administración parece sencilla: demostrar el cumplimiento, evitar trabajo duplicado y no convertirlo en tres proyectos separados.
La empresa tiene controles. La autenticación multifactor (MFA) está habilitada. Las copias de seguridad se ejecutan. Los desarrolladores revisan el código. El equipo de privacidad mantiene los registros de actividades de tratamiento. El equipo de infraestructura realiza análisis de vulnerabilidades. Los proveedores se revisan durante el proceso de adquisición. Pero cuando el cliente potencial solicita evidencias, la respuesta se fragmenta.
El informe del proveedor de identidad está en un lugar. Los registros de copias de seguridad están en otro. El registro de riesgos no se ha actualizado desde la última versión del producto. Las evidencias de seguridad de proveedores permanecen en correos electrónicos de compras. Existen notas de ejercicios de mesa de respuesta a incidentes, pero nadie puede demostrar que las lecciones aprendidas se hayan reincorporado al tratamiento de riesgos. El Consejo de Administración aprobó gasto en seguridad, pero la aprobación no está vinculada a un riesgo de las TIC ni a una decisión de control documentada.
Ese es el problema real de las medidas técnicas y organizativas del artículo 32 del RGPD de la UE, comúnmente denominadas MTO. La mayoría de las organizaciones no fallan porque no tengan controles. Fallan porque no pueden demostrar que los controles están basados en riesgos, aprobados, implementados, supervisados y mejorados.
La responsabilidad proactiva del RGPD de la UE hace explícita esa expectativa. El artículo 5 del RGPD de la UE exige que los datos personales se protejan con una seguridad adecuada frente al tratamiento no autorizado o ilícito y frente a la pérdida, destrucción o daño accidental. Article 5(2) hace al responsable del tratamiento responsable de demostrar el cumplimiento. Las definiciones del RGPD de la UE también importan. Los datos personales tienen un alcance amplio, el tratamiento cubre prácticamente cualquier operación sobre datos, la seudonimización es una salvaguarda reconocida, y una brecha de datos personales incluye la destrucción, pérdida, alteración, divulgación no autorizada o acceso accidental o ilícito.
Por tanto, un expediente de evidencias del artículo 32 no puede ser una carpeta de capturas de pantalla aleatorias. Debe ser un sistema de control vivo.
El enfoque de Clarysec consiste en convertir las MTO del artículo 32 del RGPD de la UE en un motor de evidencias trazable construido sobre ISO/IEC 27001:2022 ISO/IEC 27001:2022, reforzado por la gestión de riesgos de ISO/IEC 27005:2022 y referenciado de forma cruzada con las obligaciones de NIS2 y DORA cuando sean aplicables. El objetivo no es generar documentación por sí misma. El objetivo es preparar a la organización para auditorías antes de que un cliente, auditor, regulador o miembro del Consejo de Administración formule la pregunta difícil.
Por qué las MTO del artículo 32 del RGPD de la UE fallan en la práctica
El artículo 32 se malinterpreta a menudo como una lista de herramientas de seguridad: cifrado, copias de seguridad, registro de eventos, control de acceso y respuesta a incidentes. Estas medidas son importantes, pero solo son defendibles cuando son adecuadas al riesgo y están conectadas con el ciclo de vida de los datos personales.
Para una empresa SaaS que trata datos de empleados de clientes, “usamos cifrado” no es suficiente. Un auditor puede preguntar qué datos protege el cifrado, dónde se exige, cómo se gestionan las claves, si las copias de seguridad están cifradas, si los datos de producción están enmascarados en las pruebas, quién puede eludir los controles y cómo se aprueban las excepciones.
La Política de Protección de Datos y Privacidad empresarial de Clarysec recoge el principio operativo:
“Implementar medidas técnicas y organizativas (MTO) que protejan la confidencialidad, integridad y disponibilidad de la información personal identificable (PII) durante todo su ciclo de vida.”
Fuente: Política de Protección de Datos y Privacidad, Objetivos, cláusula de política 3.3. Política de Protección de Datos y Privacidad
La expresión “durante todo su ciclo de vida” es donde muchos programas de MTO se debilitan. Los datos personales pueden estar protegidos en producción, pero copiarse a sistemas de analítica, registros, exportaciones de soporte, entornos de prueba, copias de seguridad, plataformas de proveedores y dispositivos de empleados. Cada ubicación crea riesgos de seguridad y privacidad.
El artículo 6 del RGPD de la UE exige una base jurídica para el tratamiento, incluido el consentimiento, el contrato, la obligación legal, los intereses vitales, la misión de interés público o los intereses legítimos. Cuando los datos se reutilizan para una finalidad ulterior, deben considerarse la compatibilidad y salvaguardas como el cifrado o la seudonimización. Para datos de mayor riesgo, aumenta la carga probatoria. El artículo 9 del RGPD de la UE impone límites estrictos a las categorías especiales de datos personales, como datos de salud, datos biométricos utilizados para identificación y otra información sensible. El artículo 10 restringe los datos relativos a condenas e infracciones penales.
Para pymes, Clarysec expresa el tratamiento de riesgos en términos prácticos:
“Deben implementarse controles para reducir los riesgos identificados, incluido el cifrado, la anonimización, la eliminación segura y las restricciones de acceso”
Fuente: Política de Protección de Datos y Privacidad para pymes, Tratamiento de riesgos y excepciones, cláusula de política 7.2.1. Política de Protección de Datos y Privacidad - pyme
Esa es una configuración de referencia sólida para las MTO. Para estar preparado para auditorías, cada control también debe estar vinculado a un riesgo, un propietario, un requisito de política, un elemento de evidencia y una cadencia de revisión.
ISO 27001:2022 es la columna vertebral de las evidencias del artículo 32
ISO 27001:2022 encaja bien con el artículo 32 del RGPD de la UE porque trata la seguridad como un sistema de gestión, no como una lista de verificación de controles desconectados. Exige un Sistema de Gestión de la Seguridad de la Información, o SGSI, diseñado para preservar la confidencialidad, integridad y disponibilidad mediante la gestión de riesgos.
El primer movimiento crítico es el alcance. Las cláusulas 4.1 a 4.4 de ISO 27001:2022 exigen que la organización comprenda las cuestiones internas y externas, identifique las partes interesadas y sus requisitos, determine qué requisitos serán abordados por el SGSI y defina el alcance del SGSI, incluidas interfaces y dependencias con organizaciones externas. Para las MTO del artículo 32, el alcance del SGSI debe reflejar el tratamiento de datos personales, las obligaciones con clientes, los encargados del tratamiento, los subencargados, las plataformas en la nube, el trabajo remoto, las funciones de soporte y los entornos de producto.
El segundo movimiento es el liderazgo. Las cláusulas 5.1 a 5.3 exigen compromiso de la alta dirección, una Política de Seguridad de la Información, recursos, roles y responsabilidades, e informes de desempeño. Esto importa porque el artículo 32 del RGPD de la UE, NIS2 y DORA dependen del gobierno. Un control sin propiedad, financiación o revisión es una evidencia débil.
La Política de Seguridad de la Información empresarial de Clarysec lo deja explícito:
“El SGSI deberá incluir límites del alcance definidos, una metodología de evaluación de riesgos, objetivos medibles y controles documentados justificados en la Declaración de Aplicabilidad (SoA).”
Fuente: Política de Seguridad de la Información, Requisitos de implementación de la política, cláusula de política 6.1.2. Política de Seguridad de la Información
La misma política establece la expectativa de evidencia:
“Todos los controles implementados deberán ser verificables mediante auditoría, estar respaldados por procedimientos documentados y contar con evidencias conservadas de su funcionamiento.”
Fuente: Política de Seguridad de la Información, Requisitos de implementación de la política, cláusula de política 6.6.1.
A continuación, las cláusulas 6.1.1 a 6.1.3 de ISO 27001:2022 exigen evaluación de riesgos, tratamiento de riesgos, una Declaración de Aplicabilidad, aprobación del riesgo residual y responsabilidad del propietario del riesgo. La cláusula 6.2 exige objetivos medibles. Las cláusulas 7.5, 9.1, 9.2, 9.3 y 10.2 exigen información documentada, supervisión, auditoría interna, revisión por la dirección y acción correctiva.
Para el artículo 32 del RGPD de la UE, esto crea una estructura defendible.
| Pregunta de evidencia del artículo 32 del RGPD de la UE | Respuesta de evidencia de ISO 27001:2022 |
|---|---|
| ¿Cómo decidió qué MTO son adecuadas? | Criterios de evaluación de riesgos, registro de riesgos, puntuación de probabilidad e impacto, plan de tratamiento de riesgos |
| ¿Qué controles aplican y por qué? | Declaración de Aplicabilidad con justificaciones de inclusión y exclusión |
| ¿Quién aprobó el riesgo residual? | Aprobación del propietario del riesgo y aprobación formal de la dirección |
| ¿Están operando los controles? | Registros, tickets, registros de revisión, resultados de pruebas, informes de supervisión |
| ¿Se revisan los controles? | Informes de auditoría interna, actas de revisión por la dirección, registro de acciones correctivas |
| ¿Se consideran los riesgos relativos a datos personales? | Entradas de riesgo de protección de datos, requisitos de privacidad en el alcance, EIPD o evaluación equivalente cuando aplique |
ISO/IEC 27005:2022 refuerza esta estructura. Recomienda que las organizaciones identifiquen requisitos procedentes del Anexo A de ISO 27001:2022, regulaciones, contratos, estándares sectoriales, reglas internas y controles existentes, y los incorporen a la evaluación y el tratamiento de riesgos. También exige criterios de riesgo y criterios de aceptación que consideren factores legales, regulatorios, operativos, de proveedores, tecnológicos y humanos, incluida la privacidad.
La Política de Gestión de Riesgos de Clarysec se alinea directamente:
“Debe mantenerse un proceso formal de gestión de riesgos conforme a ISO/IEC 27005 e ISO 31000, que cubra identificación, análisis, evaluación, tratamiento, seguimiento y comunicación del riesgo.”
Fuente: Política de Gestión de Riesgos, Requisitos de gobierno, cláusula de política 5.1. Política de Gestión de Riesgos
Para pymes, el mismo requisito se vuelve simple y accionable:
“Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.”
Fuente: Política de Gestión de Riesgos para pymes, Requisitos de gobierno, cláusula de política 5.1.2. Política de Gestión de Riesgos - pyme
Esa frase es una prueba rápida de preparación para auditorías. Si un riesgo no tiene propietario o plan de tratamiento, todavía no es un riesgo preparado para evidencias.
El puente de Clarysec: riesgo, SoA, controles y regulaciones
La hoja de ruta de 30 pasos para auditores de Clarysec, Zenith Blueprint Zenith Blueprint, trata el cumplimiento como trabajo de trazabilidad. En la fase de gestión de riesgos, el paso 13 se centra en la planificación del tratamiento de riesgos y la Declaración de Aplicabilidad. Explica que las organizaciones deben mapear los controles a los riesgos, añadir referencias de controles del Anexo A a las entradas de tratamiento de riesgos, referenciar regulaciones externas y obtener aprobación de la dirección.
El Zenith Blueprint es directo sobre el papel de la SoA:
“La SoA es, en la práctica, un documento puente: vincula su evaluación/tratamiento de riesgos con los controles reales que tiene. Al completarla, también verifica si omitió algún control.”
Fuente: Zenith Blueprint: hoja de ruta de 30 pasos para auditores, fase de gestión de riesgos, paso 13: planificación del tratamiento de riesgos y Declaración de Aplicabilidad (SoA). Zenith Blueprint
El paso 14 del Zenith Blueprint añade la capa de referencias cruzadas regulatorias. Recomienda a las organizaciones documentar cómo los requisitos del RGPD de la UE, NIS2 y DORA están cubiertos por políticas y controles. Para el RGPD de la UE, enfatiza la protección de datos personales en las evaluaciones y tratamientos de riesgos, incluido el cifrado como medida técnica y la respuesta ante brechas como parte del entorno de control. Para NIS2, destaca la evaluación de riesgos, la seguridad de redes, el control de acceso, la gestión de incidentes y la continuidad del negocio. Para DORA, apunta a la gestión del riesgo de las TIC, la respuesta a incidentes, la notificación y la supervisión de terceros de TIC.
Ese es el núcleo del método de Clarysec: un SGSI, un registro de riesgos, una SoA, una biblioteca de evidencias y múltiples resultados de cumplimiento.
Zenith Controls: la guía de cumplimiento cruzado Zenith Controls lo respalda ayudando a las organizaciones a utilizar los temas de control de ISO/IEC 27002:2022 ISO/IEC 27002:2022 como anclajes de cumplimiento cruzado. Para el artículo 32 del RGPD de la UE, los anclajes más importantes suelen incluir Privacidad y protección de PII, control 5.34; Revisión independiente de la seguridad de la información, control 5.35; y Uso de criptografía, control 8.24.
| Anclaje de control de ISO/IEC 27002:2022 en Zenith Controls | Por qué importa para las MTO del artículo 32 | Ejemplos de evidencias |
|---|---|---|
| 5.34 Privacidad y protección de PII | Conecta los controles de seguridad de la información con el tratamiento de datos personales y las obligaciones de privacidad | Inventario de datos, evaluación de riesgos de privacidad, plazos de conservación, registros de contratos de tratamiento de datos (DPA), revisiones de acceso |
| 5.35 Revisión independiente de la seguridad de la información | Demuestra aseguramiento objetivo, auditabilidad y mejora | Informe de auditoría interna, evaluación externa, registro de acciones correctivas, revisión por la dirección |
| 8.24 Uso de criptografía | Protege la confidencialidad e integridad de los datos en tránsito, en reposo y en copias de seguridad | Estándar de cifrado, registros de gestión de claves, evidencias de cifrado de disco, configuración TLS, cifrado de copias de seguridad |
NIS2 convierte las MTO en una cuestión de ciberseguridad del Consejo de Administración
Muchas organizaciones tratan las MTO del RGPD de la UE como una responsabilidad del equipo de privacidad. NIS2 cambia la conversación.
NIS2 aplica a muchas entidades medianas y grandes de sectores enumerados y, en algunos casos, con independencia del tamaño. Los sectores digitales y tecnológicos cubiertos incluyen proveedores de computación en la nube, proveedores de centros de datos, redes de distribución de contenidos, proveedores de servicios DNS, registros TLD, prestadores de servicios de confianza, proveedores públicos de comunicaciones electrónicas, proveedores de servicios gestionados, proveedores de servicios gestionados de seguridad, mercados en línea, motores de búsqueda y plataformas de redes sociales. La aplicabilidad para SaaS y pymes tecnológicas depende del sector, el tamaño, la designación por el Estado miembro y el impacto sistémico o transfronterizo.
Article 20 de NIS2 sitúa la responsabilidad de ciberseguridad en los órganos de administración. Deben aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su implementación y recibir formación. Las entidades esenciales pueden enfrentarse a multas administrativas de al menos 10 millones de euros o al menos el 2 por ciento del volumen de negocios anual mundial. Las entidades importantes pueden enfrentarse a multas de al menos 7 millones de euros o al menos el 1,4 por ciento.
Article 21 de NIS2 es directamente relevante para las MTO del artículo 32 porque exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Estas medidas deben considerar el estado de la técnica, las normas europeas e internacionales, el coste, la exposición, el tamaño, la probabilidad, la severidad y el impacto social o económico. Las áreas requeridas incluyen análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y desarrollo seguros, gestión de vulnerabilidades, evaluación de la eficacia, higiene cibernética, formación, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos, MFA o autenticación continua, y comunicaciones seguras cuando proceda.
Article 23 de NIS2 añade notificación de incidentes por fases: alerta temprana en un plazo de 24 horas, notificación de incidente en un plazo de 72 horas, actualizaciones intermedias cuando se soliciten, e informe final a más tardar un mes después de la notificación de 72 horas. Si una brecha de datos personales también califica como incidente significativo de NIS2, su expediente de evidencias debe respaldar tanto las decisiones de notificación de privacidad como las de ciberseguridad.
DORA eleva el listón de la resiliencia financiera y de los proveedores de TIC
DORA aplica desde el 17 de enero de 2025 y crea un marco normativo del sector financiero para la resiliencia operativa digital. Cubre la gestión del riesgo de las TIC, la notificación de incidentes importantes relacionados con las TIC, las pruebas de resiliencia operativa, el intercambio de información sobre ciberamenazas y vulnerabilidades, el riesgo de terceros de TIC, los requisitos contractuales para proveedores de TIC, la supervisión de proveedores terceros críticos de servicios de TIC y la supervisión.
Para las entidades financieras también identificadas bajo normas nacionales de NIS2, DORA opera como el acto jurídico sectorial específico de la Unión para las obligaciones solapadas de gestión de riesgos de ciberseguridad y notificación de incidentes. En la práctica, las entidades financieras cubiertas deben priorizar DORA para esas áreas solapadas, manteniendo la coordinación con las autoridades competentes de NIS2 y los CSIRT cuando corresponda.
Para las evidencias del artículo 32 del RGPD de la UE, DORA importa de dos formas. Primero, las empresas fintech pueden estar directamente dentro del alcance como entidades financieras, incluidas entidades de crédito, entidades de pago, proveedores de servicios de información sobre cuentas, entidades de dinero electrónico, empresas de servicios de inversión, proveedores de servicios de criptoactivos, centros de negociación y proveedores de servicios de financiación participativa. Segundo, los proveedores SaaS, de nube, datos, software y servicios gestionados pueden ser tratados por clientes financieros como proveedores terceros de servicios de TIC porque DORA define los servicios de TIC de forma amplia.
Article 5 de DORA exige gobierno y controles internos para la gestión del riesgo de las TIC, con el órgano de administración definiendo, aprobando, supervisando y manteniendo la responsabilidad sobre los acuerdos de riesgo de las TIC. Article 6 exige un marco documentado de gestión del riesgo de las TIC, que incluya estrategias, políticas, procedimientos, protocolos de TIC y herramientas para proteger la información y los activos de TIC. Article 17 exige un proceso de gestión de incidentes relacionados con las TIC que cubra detección, gestión, notificación, registro, causa raíz, indicadores de alerta temprana, clasificación, roles, comunicaciones, escalado y respuesta. Article 19 exige que los incidentes graves relacionados con las TIC se notifiquen a las autoridades competentes.
Articles 28 y 30 de DORA convierten el riesgo de terceros de TIC en un dominio de control regulado. Las entidades financieras siguen siendo responsables del cumplimiento cuando usan servicios de TIC. Necesitan una estrategia de riesgo de terceros, registros contractuales, evaluaciones de criticidad, diligencia debida, revisión del riesgo de concentración, derechos de auditoría e inspección, activadores de terminación, estrategias de salida y disposiciones contractuales que cubran ubicaciones de datos, disponibilidad, autenticidad, integridad, confidencialidad, asistencia en incidentes, recuperación, niveles de servicio y cooperación con autoridades.
Para el artículo 32, esto significa que los proveedores forman parte del expediente de MTO. No puede demostrarse la seguridad del tratamiento si los encargados críticos, las plataformas en la nube, los proveedores de analítica, las herramientas de soporte y los proveedores de TIC no están controlados.
Construcción práctica en una semana de evidencias del artículo 32
Un expediente de evidencias sólido empieza con un escenario de riesgo claro.
Use este ejemplo: “Acceso no autorizado a datos personales de clientes en la aplicación de producción”.
Cree o actualice la entrada de riesgo. Incluya descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento. Asigne el propietario al responsable de ingeniería, responsable de seguridad o rol equivalente con responsabilidad. Califique la probabilidad en función del modelo de acceso, la superficie de ataque expuesta, las vulnerabilidades conocidas y los incidentes previos. Califique el impacto en función del volumen de datos personales, sensibilidad, contratos con clientes, consecuencias del RGPD de la UE y posible impacto de servicio en NIS2 o DORA.
Seleccione tratamientos como MFA para acceso privilegiado, control de acceso basado en roles, revisiones de acceso trimestrales, cifrado en reposo, TLS, análisis de vulnerabilidades, registro de eventos, alertas, copia de seguridad segura, procedimientos de respuesta a incidentes y enmascaramiento de datos en entornos no productivos.
Después, mapee el riesgo a la SoA. Añada referencias de ISO/IEC 27002:2022 como 5.34 Privacidad y protección de PII, 8.24 Uso de criptografía, 5.15 Control de acceso, 5.18 Derechos de acceso, 8.13 Copia de seguridad de la información, 8.15 Registro de eventos, 8.16 Actividades de supervisión, 8.8 Gestión de vulnerabilidades técnicas, 8.25 Ciclo de vida de desarrollo seguro y 8.10 Supresión de información cuando aplique. Añada notas que muestren cómo estos controles respaldan el artículo 32 del RGPD de la UE, Article 21 de NIS2 y la gestión del riesgo de las TIC de DORA cuando sea relevante.
Para el mapeo regulatorio, mantenga los nombres de los controles exactos y evite forzar equivalencias falsas.
| Control ISO/IEC 27002:2022 | Nombre del control | Motivo de inclusión | Mapeo regulatorio |
|---|---|---|---|
| 8.24 | Uso de criptografía | Protege la confidencialidad e integridad de los datos personales en tránsito, en reposo y en copias de seguridad | Art. 32 del RGPD de la UE; Art. 21(2)(h) de NIS2 |
| 5.20 | Tratamiento de la seguridad de la información en acuerdos con proveedores | Garantiza que las obligaciones de seguridad de proveedores estén definidas contractualmente y sean exigibles | Controles de encargados del tratamiento del RGPD de la UE; Art. 21(2)(d) de NIS2; Art. 28 y Art. 30 de DORA |
| 5.24 | Planificación y preparación de la gestión de incidentes de seguridad de la información | Establece preparación para detección, escalado, evaluación y notificación | Responsabilidad proactiva ante brechas del RGPD de la UE; Art. 23 de NIS2; Art. 17 y Art. 19 de DORA |
| 8.13 | Copia de seguridad de la información | Respalda la disponibilidad, la restauración y la resiliencia tras una interrupción o pérdida de datos | Art. 32 del RGPD de la UE; Art. 21(2)(c) de NIS2; expectativas de continuidad de TIC de DORA |
| 8.10 | Supresión de información | Respalda la eliminación segura, la aplicación de la conservación y la minimización de datos | Limitación del plazo de conservación del RGPD de la UE y Art. 32; requisitos contractuales de clientes |
Ahora construya la carpeta de evidencias. La Política de Auditoría y Seguimiento del Cumplimiento para pymes de Clarysec proporciona una regla sencilla:
“Todas las evidencias deben almacenarse en una carpeta de auditoría centralizada.”
Fuente: Política de Auditoría y Seguimiento del Cumplimiento para pymes, Requisitos de implementación de la política, cláusula de política 6.2.1. Política de Auditoría y Seguimiento del Cumplimiento - pyme
Para este único escenario de riesgo, la carpeta debe contener:
| Elemento de evidencia | Qué almacenar | Por qué importa |
|---|---|---|
| Entrada de riesgo | Descripción del riesgo, propietario, puntuación, plan de tratamiento y decisión de riesgo residual | Demuestra la selección de MTO basada en riesgos |
| Extracto de SoA | Controles aplicables y notas de RGPD de la UE, NIS2 y DORA | Muestra la trazabilidad desde el riesgo hasta el control |
| Revisión de acceso | Usuarios revisados, decisiones, retiradas y excepciones | Demuestra el funcionamiento del control de acceso |
| Informe de MFA | Exportación que muestre la aplicación de MFA para privilegios elevados | Respalda la evidencia de autenticación |
| Evidencia de cifrado | Registro de configuración, nota de arquitectura o registro de gestión de claves | Respalda la confidencialidad y la integridad |
| Registro de vulnerabilidades | Último análisis, tickets de remediación y excepciones aceptadas | Respalda la reducción del riesgo técnico |
| Prueba de registro de eventos | Muestra de evento SIEM, regla de alerta y configuración de conservación | Respalda la detección y la investigación |
| Prueba de copia de seguridad | Resultado de prueba de restauración y registro de cobertura de copias de seguridad | Respalda la disponibilidad y la resiliencia |
| Ejercicio de incidente | Notas del ejercicio de mesa, registro de incidente de prueba o registro de lecciones aprendidas | Respalda la preparación de respuesta |
| Aprobación de la dirección | Actas de reunión, aprobación formal o registro de aceptación del riesgo | Respalda la responsabilidad proactiva y la proporcionalidad |
Las evidencias de acceso no deben limitarse a capturas de pantalla. La Política de Control de Acceso para pymes añade un requisito operativo útil:
“El responsable de TI debe documentar los resultados de la revisión y las acciones correctivas.”
Fuente: Política de Control de Acceso para pymes, Requisitos de gobierno, cláusula de política 5.5.3. Política de Control de Acceso - pyme
Las evidencias de copias de seguridad deben demostrar capacidad de recuperación, no solo trabajos correctos. La Política de Copias de Seguridad y Restauración para pymes establece:
“Las pruebas de restauración se realizan al menos trimestralmente, y los resultados se documentan para verificar la capacidad de recuperación”
Fuente: Política de Copias de Seguridad y Restauración para pymes, Requisitos de gobierno, cláusula de política 5.3.3. Política de Copias de Seguridad y Restauración - pyme
Esto proporciona un ciclo completo de evidencias: la regulación crea el requisito, el riesgo explica por qué importa, la SoA selecciona el control, la política define la operación y las evidencias conservadas demuestran que el control funciona.
Controles en acción: convertir la política en prueba operativa
La fase de Controles en acción del Zenith Blueprint, paso 19, se centra en la verificación técnica. Recomienda revisar el cumplimiento de seguridad de endpoints, la gestión de identidades y accesos, las configuraciones de autenticación, la seguridad del control de código fuente, la capacidad y disponibilidad, la gestión de vulnerabilidades y parches, las configuraciones de referencia seguras, la protección contra software malicioso, la supresión y minimización de datos, el enmascaramiento y los datos de prueba, DLP, la copia de seguridad y restauración, la redundancia, el registro y supervisión, y la sincronización horaria.
Para las MTO del artículo 32 del RGPD de la UE, el paso 19 es donde el lenguaje abstracto de control se convierte en prueba. Un expediente de evidencias sólido debe mostrar que:
- El cifrado de endpoints está habilitado y supervisado.
- Los usuarios privilegiados tienen MFA.
- Los procesos de altas, cambios y bajas se concilian con los registros de recursos humanos.
- Las cuentas de servicio están documentadas y restringidas.
- Los repositorios de código tienen control de acceso y se realiza escaneo de secretos.
- Se realizan análisis de vulnerabilidades y se hace seguimiento hasta la remediación.
- Los datos de producción no se copian informalmente en entornos de prueba.
- Se aplican políticas de borrado seguro y conservación.
- Las alertas DLP se revisan.
- Las pruebas de restauración de copias de seguridad demuestran la capacidad de recuperación.
- Los registros están centralizados, se conservan y son revisables.
- La sincronización horaria respalda una investigación de incidentes fiable.
La clave es la vinculación. Un informe de parches sin referencia a un riesgo, una política y la SoA es un artefacto de TI. Un informe de parches vinculado al artículo 32 del RGPD de la UE, Article 21 de NIS2, la gestión del riesgo de las TIC de DORA y un plan de tratamiento de riesgos de ISO 27001:2022 es evidencia preparada para auditoría.
Un expediente de evidencias, múltiples lentes de auditoría
Las mismas evidencias de MTO se leerán de forma distinta por diferentes partes interesadas. Un revisor de privacidad puede centrarse en datos personales, necesidad, proporcionalidad y responsabilidad proactiva. Un auditor de ISO 27001 puede centrarse en alcance, tratamiento de riesgos, SoA y evidencias de operación. Una autoridad NIS2 puede centrarse en la supervisión de la dirección, las medidas del Article 21 y la preparación para notificación del Article 23. Un supervisor DORA o cliente financiero puede centrarse en el gobierno del riesgo de las TIC, las pruebas de resiliencia y las dependencias de terceros.
Clarysec usa Zenith Controls como guía de cumplimiento cruzado para esta traducción.
| Audiencia | Qué preguntará | Cómo deben responder las evidencias |
|---|---|---|
| Revisor de privacidad del RGPD de la UE | ¿Son las MTO adecuadas al riesgo de datos personales y puede demostrarse la responsabilidad proactiva? | Registro de riesgos, inventario de datos, controles de privacidad, registros de conservación, restricciones de acceso, evidencias de cifrado y registros de evaluación de brechas |
| Auditor de ISO 27001:2022 | ¿Está el SGSI delimitado, basado en riesgos, implementado, supervisado y mejorado? | Alcance, metodología de riesgos, SoA, auditoría interna, revisión por la dirección y acciones correctivas |
| Revisor de NIS2 | ¿Las medidas de ciberseguridad están aprobadas, son proporcionadas y cubren las áreas del Article 21? | Aprobación del Consejo de Administración, políticas de seguridad, gestión de incidentes, continuidad, riesgo de proveedores, formación, MFA y gestión de vulnerabilidades |
| Supervisor DORA o cliente financiero | ¿Está el riesgo de las TIC gobernado, probado y es resiliente, incluido el riesgo de terceros de TIC? | Marco de riesgo de las TIC, estrategia de resiliencia, proceso de incidentes, evidencias de pruebas, registro de proveedores y planes de salida |
| Evaluador orientado a NIST | ¿Puede la organización identificar, proteger, detectar, responder y recuperar usando evidencias repetibles? | Inventario de activos y datos, controles de protección, registros de supervisión, registros de respuesta y pruebas de recuperación |
| Auditor de COBIT 2019 o ISACA | ¿El gobierno es responsable, medido y alineado con los objetivos empresariales? | Roles, informes de gestión, apetito de riesgo, métricas de desempeño, resultados de aseguramiento y acciones de mejora |
Esto evita trabajo de cumplimiento duplicado. En lugar de construir paquetes de evidencias separados para RGPD de la UE, NIS2 y DORA, construya un único expediente de evidencias de control y etiquete cada elemento según las obligaciones que respalda.
Deficiencias comunes en los programas de MTO del artículo 32
La deficiencia más común es la orfandad de controles. Una empresa tiene un control, como el cifrado, pero no puede explicar qué riesgo trata, qué política lo exige, quién es su propietario o cómo se revisa.
La segunda deficiencia es la debilidad de las evidencias de proveedores. Bajo el RGPD de la UE, los encargados del tratamiento y los subencargados importan. Bajo NIS2, la seguridad de la cadena de suministro forma parte de la gestión de riesgos de seguridad de la información. Bajo DORA, el riesgo de terceros de TIC es un dominio regulado con registros, diligencia debida, salvaguardas contractuales, derechos de auditoría y planificación de salida. Una hoja de cálculo de proveedores no es suficiente si las dependencias críticas no se evalúan y controlan en función del riesgo.
La tercera deficiencia son las evidencias de incidentes. Las organizaciones suelen tener un plan de respuesta a incidentes, pero no pruebas de que la clasificación, el escalado, la notificación a autoridades y la comunicación con clientes se hayan probado. NIS2 y DORA elevan las expectativas en este punto, y la evaluación de brechas de datos personales del RGPD de la UE debe integrarse en el mismo flujo de trabajo.
La cuarta deficiencia es la prueba de copias de seguridad. Un trabajo de copia de seguridad correcto no demuestra capacidad de recuperación. Una prueba de restauración documentada sí.
La quinta deficiencia es la revisión por la dirección. Las MTO del artículo 32 deben ser proporcionales al riesgo. Si la dirección nunca revisa riesgos, incidentes, problemas de proveedores, presupuesto, hallazgos de auditoría y riesgo residual, resulta difícil demostrar la proporcionalidad.
El kit final preparado para auditoría
La fase de Auditoría, revisión y mejora del Zenith Blueprint, paso 30, proporciona la lista de verificación final de preparación. Incluye el alcance y contexto del SGSI, la Política de Seguridad de la Información firmada, los documentos de evaluación y tratamiento de riesgos, la SoA, las políticas y procedimientos del Anexo A, registros de formación, registros operativos, informe de auditoría interna, registro de acciones correctivas, actas de revisión por la dirección, evidencias de mejora continua y registros de obligaciones de cumplimiento.
La Política de Auditoría y Seguimiento del Cumplimiento empresarial de Clarysec declara el propósito de esta disciplina:
“Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos regulatorios, procedimientos legales o solicitudes de aseguramiento de clientes.”
Fuente: Política de Auditoría y Seguimiento del Cumplimiento, Objetivos, cláusula de política 3.4. Política de Auditoría y Seguimiento del Cumplimiento
Un expediente maduro de evidencias de MTO del artículo 32 debe incluir:
| Categoría de evidencia | Contenido mínimo preparado para auditoría |
|---|---|
| Gobierno | Alcance del SGSI, aprobación de políticas, roles, objetivos, actas de revisión por la dirección |
| Riesgo | Metodología de riesgos, registro de riesgos, plan de tratamiento, aprobaciones de riesgo residual |
| SoA | Controles aplicables, exclusiones, justificaciones y mapeo regulatorio |
| Privacidad | Inventario de datos, controles de PII, evidencias de conservación, EIPD o evaluación de riesgos de privacidad cuando aplique |
| Controles técnicos | MFA, revisiones de acceso, cifrado, gestión de vulnerabilidades, registro de eventos, supervisión y evidencias de desarrollo seguro |
| Resiliencia | Cobertura de copias de seguridad, pruebas de restauración, planes de continuidad, ejercicios de incidentes y métricas de recuperación |
| Aseguramiento de proveedores | Registro de proveedores, diligencia debida, cláusulas contractuales, supervisión, derechos de auditoría y planificación de salida |
| Mejora | Auditorías internas, acciones correctivas, lecciones aprendidas y revisiones de eficacia de controles |
Próximos pasos: construir evidencias de MTO del artículo 32 con Clarysec
Si necesita demostrar medidas técnicas y organizativas del artículo 32 del RGPD de la UE, no empiece recopilando capturas de pantalla aleatorias. Empiece por la trazabilidad.
- Defina el alcance del SGSI y los límites del tratamiento de datos personales.
- Identifique requisitos del RGPD de la UE, NIS2, DORA, contractuales y de clientes.
- Construya criterios de riesgo usando ISO/IEC 27005:2022 y un apetito de riesgo aprobado por la dirección.
- Cree o actualice el registro de riesgos.
- Mapee cada tratamiento a los controles de ISO 27001:2022 y a la SoA.
- Use Zenith Controls para referenciar de forma cruzada controles de privacidad, criptografía, proveedores, incidentes y revisión independiente en todas las expectativas de cumplimiento.
- Siga el paso 13 y el paso 14 del Zenith Blueprint para conectar riesgos, controles y obligaciones regulatorias.
- Use el paso 19 del Zenith Blueprint para verificar los controles técnicos en operación.
- Use el paso 30 del Zenith Blueprint para ensamblar el expediente final de evidencias preparado para auditoría.
- Almacene todas las evidencias de forma centralizada, etiquételas por riesgo y tema de control, y mantenga visibles las acciones correctivas.
Clarysec puede ayudarle a convertir el artículo 32 del RGPD de la UE de una obligación de cumplimiento vaga en un sistema de evidencias defendible y basado en riesgos, alineado con ISO 27001:2022, NIS2 y DORA.
Empiece con Zenith Blueprint, refuércelo con las políticas de Clarysec y use Zenith Controls para que cada MTO sea trazable, verificable y esté preparada para auditoría.
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
