Mapeo de NIS2 2024/2690 a ISO 27001 para proveedores de nube
A las 08:17 de un martes, María, CISO de un proveedor europeo de servicios gestionados, recibe la alerta que todo MSP teme. Una cuenta privilegiada de gestión remota ha activado alertas de desplazamiento imposible. Dos tenants de clientes muestran acciones administrativas anómalas. El SOC ya ha abierto un puente de incidente crítico.
A las 09:00, el director general se incorpora a la llamada. Las preguntas cambian de inmediato.
¿Estamos dentro del alcance de NIS2? ¿Nos aplica el Reglamento de Ejecución (UE) 2024/2690 de la Comisión? ¿Necesitamos emitir una alerta temprana en 24 horas? ¿A qué clientes debemos notificar? ¿Podemos demostrar que MFA, registro de eventos, segmentación, gestión de vulnerabilidades, controles de proveedores y escalado de incidentes estaban operativos antes del incidente?
La empresa de María cuenta con certificación ISO/IEC 27001:2022. Presta servicios de gestión en la nube, servicios de centro de datos y soporte de seguridad gestionada a clientes entre los que se incluyen un proveedor logístico y un banco regional. El certificado importa, pero por sí solo no responde a las preguntas operativas. El equipo jurídico dispone de un borrador del proceso de notificación. El responsable de cumplimiento tiene una hoja de cálculo. El auditor ha solicitado la Declaración de Aplicabilidad, pruebas de respuesta a incidentes, registros de acceso privilegiado, diligencia debida de proveedores, evidencias de responsabilidad compartida en la nube y supuestos de continuidad del negocio.
Este es el momento en que NIS2 deja de ser un texto jurídico y se convierte en un problema de control operativo.
Para proveedores de servicios de computación en la nube, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados y proveedores de centros de datos, NIS2 y el Reglamento de Ejecución 2024/2690 elevan el nivel desde una intención general de seguridad hasta evidencias de control inspeccionables. La gobernanza, la gestión de riesgos, el control de acceso, la política de gestión de activos, la gestión de vulnerabilidades, la respuesta a incidentes, la seguridad de proveedores, el registro de eventos, la supervisión, el cifrado, la continuidad del negocio y la resiliencia física deben operar como un único sistema.
ISO/IEC 27001:2022 es la mejor columna vertebral para ese sistema, pero solo si la organización mapea los requisitos de NIS2 en el SGSI, el registro de riesgos, la Declaración de Aplicabilidad, las políticas y el modelo de evidencias. Un certificado colgado en la pared no basta. El trabajo real consiste en construir un hilo auditable desde la regulación hasta el riesgo, desde el riesgo hasta el control, desde el control hasta la política, y desde la política hasta las evidencias operativas.
Por qué NIS2 2024/2690 cambia la conversación de cumplimiento para la nube y los MSP
NIS2 utiliza un modelo basado en sector y tamaño, pero sus categorías de infraestructura digital y gestión de servicios TIC son deliberadamente amplias. En virtud del artículo 2 y del artículo 3 de NIS2, leídos junto con el Anexo I y el Anexo II, muchas organizaciones pueden clasificarse como entidades esenciales o importantes, incluidos proveedores de servicios de computación en la nube, proveedores de servicios de centros de datos, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, proveedores DNS, registros TLD, redes de distribución de contenidos y prestadores de servicios de confianza. Los Estados miembros deben establecer y revisar periódicamente listas de entidades esenciales e importantes, con el primer plazo de inclusión fijado para el 17 de abril de 2025.
Esto importa porque los proveedores de nube, MSP, MSSP y centros de datos se sitúan dentro de las cadenas de riesgo de otras organizaciones. Un compromiso del plano de control de la nube puede afectar a miles de sistemas de clientes. Una indisponibilidad de un centro de datos puede propagarse a banca, sanidad, logística y administración pública. Una brecha de credenciales de un MSP puede convertirse en un evento de ransomware multicliente. Un fallo de detección de un MSSP puede retrasar la contención en clientes regulados.
El artículo 20 de NIS2 exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad y supervisen su implantación. El artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas basadas en un enfoque multirriesgo. La base incluye análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y desarrollo seguros, gestión y divulgación de vulnerabilidades, evaluación de la eficacia, higiene cibernética, formación, criptografía, seguridad de recursos humanos, control de acceso, política de gestión de activos, MFA o autenticación continua, comunicaciones seguras y comunicaciones de emergencia.
El artículo 23 añade una notificación escalonada de incidentes significativos, incluida una alerta temprana en un plazo de 24 horas, una notificación de incidente en un plazo de 72 horas, informes intermedios cuando se soliciten y un informe final en el plazo de un mes tras la notificación o tras la gestión del incidente cuando este siga en curso.
El Reglamento de Ejecución 2024/2690 concreta estas expectativas para los proveedores digitales pertinentes. En la práctica, autoridades, clientes y auditores no preguntarán solo si existen políticas. Preguntarán si los controles están mapeados, tienen propietario, se han probado y cuentan con evidencias.
ISO/IEC 27001:2022 convierte NIS2 en contexto operativo del SGSI
Un error común en la preparación para NIS2 es empezar con una gran lista de verificación y asignar tareas entre TI, legal, SOC, infraestructura, gestión de proveedores y cumplimiento. Eso puede generar actividad, pero a menudo falla en auditoría porque nadie puede demostrar por qué se seleccionaron los controles, cómo se relacionan con el riesgo, quién aceptó el riesgo residual y qué evidencias prueban la eficacia.
ISO/IEC 27001:2022 proporciona a los proveedores la estructura necesaria para evitar ese fallo.
Las cláusulas 4.1 a 4.4 exigen que la organización determine cuestiones internas y externas, identifique partes interesadas y sus requisitos, decida qué requisitos se abordarán mediante el SGSI y defina el alcance del SGSI, incluidas interfaces y dependencias. Para un proveedor de nube o MSP, el alcance debe considerar explícitamente NIS2, el Reglamento de Ejecución 2024/2690, anexos de seguridad de clientes, requisitos de clientes impulsados por DORA, regiones en la nube, subcontratistas, dependencias de centros de datos, plataformas de gestión remota, rutas de acceso privilegiado y obligaciones de notificación de incidentes.
Las cláusulas 5.1 a 5.3 exigen liderazgo, alineación de políticas, recursos, comunicación, responsabilidades asignadas y rendición de cuentas de la dirección. Esto respalda directamente el artículo 20 de NIS2.
Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, propietarios del riesgo, análisis de probabilidad y consecuencias, selección de controles, comparación con el Anexo A, una Declaración de Aplicabilidad, un plan de tratamiento de riesgos y aceptación formal del riesgo residual. Aquí es donde NIS2 se vuelve operativo. Cada requisito regulatorio se convierte en un factor de riesgo, una obligación de cumplimiento, un requisito de control o un requisito de evidencias.
Clarysec inicia este trabajo con Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, especialmente la fase de gestión de riesgos.
Desde el paso 13, planificación del tratamiento de riesgos y Declaración de Aplicabilidad, Zenith Blueprint indica a los equipos que creen trazabilidad entre riesgos, controles y factores regulatorios:
“Referencias cruzadas con regulaciones: si determinados controles se implantan específicamente para cumplir con el RGPD de la UE, NIS2 o DORA, puede indicarlo en el Registro de Riesgos o en las notas de la SoA. Por ejemplo, el control 8.27 (borrado seguro de datos) puede ser muy relevante para el requisito del RGPD de la UE de eliminar datos personales; podría anotar ‘Aplicable – respalda el RGPD de la UE Art.32 (seguridad del tratamiento)’. ISO no lo exige, pero ayuda a demostrar que tuvo en cuenta esos marcos.”
El paso 14, políticas de tratamiento de riesgos y referencias cruzadas regulatorias, añade la disciplina práctica de mapeo:
“Para cada regulación, si procede, puede crear una tabla de mapeo sencilla que enumere los principales requisitos de seguridad de la regulación y los controles/políticas correspondientes en su SGSI. No es obligatorio en ISO 27001, pero es un ejercicio interno útil para asegurarse de que nada queda sin cubrir.”
Esa es la diferencia entre decir “tenemos certificación ISO” y demostrar “nuestro SGSI ISO/IEC 27001:2022 aborda el Reglamento de Ejecución NIS2 2024/2690”.
Mapa unificado de controles NIS2 a ISO/IEC 27001:2022
El siguiente mapeo no es asesoramiento jurídico ni sustituye el análisis de transposición nacional. Es una arquitectura práctica de controles para proveedores que necesitan una ruta ISO/IEC 27001:2022 auditable hacia la preparación NIS2.
| Tema de NIS2 y del Reglamento de Ejecución | Mecanismo del SGSI ISO/IEC 27001:2022 | Áreas clave de control del Anexo A | Evidencias de implantación de Clarysec |
|---|---|---|---|
| Gobernanza y rendición de cuentas de la dirección | Las cláusulas 4, 5, 6 y 9 definen contexto, liderazgo, planificación de riesgos y revisión del desempeño | 5.1 Políticas de seguridad de la información, 5.2 Roles y responsabilidades de seguridad de la información, 5.31 Requisitos legales, estatutarios, regulatorios y contractuales | Alcance del SGSI, registro de partes interesadas, aprobación del consejo de administración, registro de riesgos, SoA, actas de revisión por la dirección |
| Gobernanza de servicios en la nube | Evaluación de riesgos, diligencia debida de proveedores, responsabilidad compartida y selección de controles | 5.23 Seguridad de la información para el uso de servicios en la nube, 5.19 Seguridad de la información en las relaciones con proveedores, 5.22 Supervisión, revisión y gestión de cambios de servicios de proveedores | Inventario de nube, evaluación de riesgos del proveedor, matriz de responsabilidad compartida, cláusulas contractuales, evidencias de registro de eventos en la nube |
| Acceso privilegiado de MSP y MSSP | Tratamiento de riesgos para entornos de clientes, plataformas de administración y herramientas de soporte | 5.15 Control de acceso, 5.16 Gestión de identidades, 5.18 Derechos de acceso, 8.2 Derechos de acceso privilegiado, 8.5 Autenticación segura | Registros de PAM, informes de MFA, registros de acceso remoto, configuración de bastión de acceso o pasarela de confianza cero, revisiones de acceso |
| Resiliencia del centro de datos | Análisis de impacto en el negocio, planificación de continuidad y gestión de dependencias | 5.30 Preparación de las TIC para la continuidad del negocio, 7.1 Perímetros de seguridad física, 7.2 Entrada física, 8.13 Copia de seguridad de la información, 8.14 Redundancia | BIA, registros de RTO y RPO, informe de prueba de DR, registros de acceso físico, evidencias de pruebas de energía y refrigeración |
| Notificación y escalado de incidentes | Proceso de incidentes vinculado a disparadores legales, contractuales y de notificación a clientes | 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información, 5.25 Evaluación y decisión sobre eventos de seguridad de la información, 5.26 Respuesta a incidentes de seguridad de la información, 5.27 Aprendizaje a partir de incidentes de seguridad de la información | Playbook de alerta temprana de 24 horas, flujo de trabajo de notificación de 72 horas, registro de incidentes, revisión posterior al incidente |
| Gestión y divulgación de vulnerabilidades | Tratamiento de vulnerabilidades basado en riesgos, gestión de excepciones y evaluación de eficacia | 8.8 Gestión de vulnerabilidades técnicas, 8.9 Gestión de configuraciones, 8.32 Gestión de cambios, 8.16 Actividades de supervisión | Resultados de escaneo, SLA de remediación, aprobaciones de excepciones, informes de parches, entradas de inteligencia de amenazas |
| Seguridad de la cadena de suministro | Requisitos de partes interesadas y riesgo de proveedores integrados en el SGSI | 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información en acuerdos con proveedores, 5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC, 5.22 Supervisión, revisión y gestión de cambios de servicios de proveedores | Clasificación por niveles de proveedores, cuestionarios de diligencia debida, cláusulas contractuales, derechos de auditoría, registro de subcontratistas, planes de salida |
| Registro de eventos, supervisión e investigación | Detección, evidencias, correlación temporal y soporte a incidentes | 8.15 Registro de eventos, 8.16 Actividades de supervisión, 8.17 Sincronización del reloj, 5.25 Evaluación y decisión sobre eventos de seguridad de la información | Mapa de cobertura SIEM, prueba de conservación de registros, registros de ajuste de alertas, registros de sincronización horaria, evidencias de correlación de incidentes |
| Aislamiento de red y tenants | Arquitectura segura, segmentación y rutas administrativas restringidas | 8.20 Seguridad de redes, 8.22 Segregación de redes, 8.23 Filtrado web, 8.24 Uso de criptografía | Diagramas de red, reglas de cortafuegos, grupos de seguridad en la nube, reglas VPC o de subred, resultados de pruebas de segmentación |
Este mapeo adquiere valor cuando se integra en el registro de riesgos y la Declaración de Aplicabilidad. Por ejemplo, un proveedor puede crear un escenario de riesgo denominado “El compromiso de una plataforma de gestión remota provoca acciones no autorizadas en entornos de clientes”. Los controles incluyen MFA, gestión de accesos privilegiados (PAM), segmentación, registro de eventos, gestión de vulnerabilidades, seguridad de proveedores, planificación de incidentes y procedimientos de notificación a clientes. Las notas de la SoA pueden hacer referencia al artículo 21 de NIS2, al artículo 23, al Reglamento de Ejecución 2024/2690, a contratos de clientes y a requisitos de diligencia debida de clientes DORA cuando proceda.
Gobernanza de la nube: el control ISO 5.23 es un ancla de NIS2
Para proveedores de nube y MSP que utilizan servicios en la nube para prestar servicios a clientes, el control 5.23 del Anexo A de ISO/IEC 27001:2022, Seguridad de la información para el uso de servicios en la nube, es uno de los anclajes más importantes.
Zenith Controls: la guía de cumplimiento cruzado Zenith Controls resume el control 5.23 como un control preventivo que respalda la confidencialidad, integridad y disponibilidad, vinculado a la seguridad en la relación con proveedores, la gobernanza, el riesgo del ecosistema y la protección. Cubre la gobernanza de servicios en la nube, la responsabilidad compartida, la evaluación de proveedores, inventarios, ubicación de los datos, registro de eventos, cifrado, roles de identidad, supervisión, cláusulas contractuales, riesgo de proveedores, salida de la nube y planificación de la resiliencia.
Zenith Blueprint, en la fase Controles en acción, paso 23, explica el motivo práctico:
“La nube ya no es un destino, es la opción por defecto. El control 5.23 reconoce esta realidad y exige que la seguridad de la información se aborde explícitamente en la selección, el uso y la gestión de los servicios en la nube, no como una reflexión posterior, sino como un principio de diseño desde el inicio.”
Para un MSP, toda plataforma de supervisión y gestión remota, portal de cliente, sistema de tickets, plataforma de telemetría de seguridad, servicio de copia de seguridad, directorio en la nube y consola administrativa SaaS debe estar gobernada. Para un proveedor de centro de datos, la gobernanza de la nube puede aplicarse a plataformas de supervisión, sistemas de gestión de visitantes, integraciones de control de acceso físico, sistemas de gestión remota e infraestructura de portales de clientes.
La Política de Uso de la Nube empresarial de Clarysec Cloud Usage Policy hace obligatoria la diligencia debida previa a la activación:
“Todo uso de la nube debe someterse a diligencia debida basada en riesgos antes de la activación, incluida la evaluación del proveedor, la validación de cumplimiento legal y las revisiones de Validación de controles.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.2.
Para proveedores de menor tamaño, la Cloud Usage Policy-sme Cloud Usage Policy-sme - SME crea un modelo de aprobación ligero:
“Todo uso de servicios en la nube debe ser revisado y aprobado por el Director General (DG) antes de la implantación o suscripción.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.1.
Ambos enfoques respaldan la misma expectativa de NIS2: el riesgo de dependencia de servicios en la nube debe entenderse antes de que el servicio pase a formar parte de la cadena de prestación.
Respuesta a incidentes: el reloj de 24 horas empieza antes de redactar el informe
El artículo 23 de NIS2 es exigente porque el plazo de notificación empieza desde el conocimiento de un incidente significativo, no desde el momento en que se dispone de un análisis de causa raíz perfecto. El reto para los proveedores es determinar con rapidez si un evento es significativo, qué clientes están afectados, si hay datos personales implicados, si existe impacto transfronterizo en el servicio y qué plazos contractuales han comenzado.
El control 5.24 del Anexo A de ISO/IEC 27001:2022, planificación y preparación de la gestión de incidentes de seguridad de la información, es el control de planificación. Zenith Controls lo resume como un control correctivo que respalda la confidencialidad, integridad y disponibilidad, vinculado a los conceptos de responder y recuperar, gobernanza, gestión de eventos y defensa. Incluye roles, responsabilidades, vías de escalado, protocolos de comunicación, preparación para notificaciones regulatorias, alineación con registro de eventos y supervisión, integración con continuidad del negocio y recuperación ante desastres, aprendizaje posterior al incidente y mapeo con NIS2, RGPD, DORA, ISO 22301, NIST CSF, NIST SP 800-53 y COBIT 2019.
La Incident Response Policy-sme de Clarysec Incident Response Policy-sme - SME convierte la primera decisión en un requisito sujeto a plazo:
“El Director General, con aportación del proveedor externo de TI, debe clasificar todos los incidentes por severidad en el plazo de una hora desde la notificación.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.3.1.
Esa clasificación en una hora respalda la disciplina operativa necesaria para el análisis de alerta temprana de 24 horas de NIS2, la evaluación de brecha de datos personales del RGPD, el escalado a clientes DORA y el triaje de notificaciones contractuales.
El árbol de decisión de incidentes de un proveedor debe responder a cuatro preguntas:
- ¿Existe compromiso confirmado o sospechado de la confidencialidad, integridad o disponibilidad?
- ¿El evento afecta a la prestación del servicio, entornos de clientes, clientes regulados, datos personales o funciones críticas?
- ¿Podría causar una interrupción operativa grave, pérdidas financieras o daños materiales o inmateriales?
- ¿Qué obligaciones de notificación aplican: NIS2, RGPD, obligaciones de clientes DORA, SLA contractuales o expectativas del regulador nacional?
El árbol de decisión debe probarse en ejercicios de mesa antes de un incidente real.
Gestión de vulnerabilidades: demostrar reducción del riesgo antes del impacto
NIS2 exige gestión y divulgación de vulnerabilidades. Para clientes y reguladores, la gestión de vulnerabilidades es una de las áreas de control más fáciles de medir porque produce evidencias claras: cobertura de escaneo, plazos de parcheo, aprobaciones de excepciones, análisis de vulnerabilidades explotadas y registros de remediación.
El control 8.8 del Anexo A de ISO/IEC 27001:2022, Gestión de vulnerabilidades técnicas, se resume en Zenith Controls como un control preventivo sobre confidencialidad, integridad y disponibilidad, vinculado a identificar y proteger, gestión de amenazas y vulnerabilidades, gobernanza, ecosistema, protección y defensa. Incluye identificación de vulnerabilidades, evaluación, priorización, aplicación de parches, controles compensatorios, integración de inteligencia de amenazas, divulgación de vulnerabilidades, responsabilidades sobre vulnerabilidades de nube y aplicaciones, evidencias de auditoría y plazos de remediación.
La Política de gestión de vulnerabilidades y parches empresarial de Clarysec Vulnerability and Patch Management Policy ofrece a los auditores un modelo concreto para probar:
“La organización debe clasificar todas las vulnerabilidades detectadas mediante una metodología estandarizada (p. ej., CVSS v3.x) y aplicar plazos de remediación alineados con la criticidad de la organización: 5.2.1 Crítica (CVSS 9.0-10.0): revisión inmediata; plazo máximo de aplicación de parches de 72 horas. 5.2.2 Alta (7.0-8.9): respuesta en 48 horas; plazo de aplicación de parches de 7 días naturales. 5.2.3 Media (4.0-6.9): respuesta en 5 días; plazo de aplicación de parches de 30 días naturales. 5.2.4 Baja (<4.0): respuesta en 10 días; plazo de aplicación de parches de 60 días naturales.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.2.
Para un proveedor de nube, esto debe cubrir componentes de hipervisor, imágenes de contenedor, capas de orquestación, interfaces de programación de aplicaciones orientadas al cliente, canalizaciones de CI/CD, consolas administrativas y bibliotecas de terceros. Para un MSP, la pregunta clave es si las vulnerabilidades internas están separadas de las vulnerabilidades gestionadas por el cliente y si los contratos definen la responsabilidad. Para un proveedor de centro de datos, el alcance puede incluir sistemas de gestión de edificios, sistemas de control de acceso, plataformas de supervisión, herramientas de asistencia remota en sitio e infraestructura de red.
El modelo de responsabilidad compartida debe documentarse. Un proveedor puede no ser propietario de todos los parches, pero aun así debe gestionar el riesgo, notificar al cliente cuando proceda y demostrar que se entienden los límites de responsabilidad.
Registro de eventos, supervisión y segmentación hacen investigables los incidentes
Cuando un incidente de proveedor pasa a impactar al cliente, las primeras preguntas de evidencia son simples: quién inició sesión, desde dónde, con qué privilegio, en qué tenant, qué cambió, qué registros existen y si las rutas administrativas estaban segmentadas.
La Política de registro y supervisión empresarial de Clarysec Logging and Monitoring Policy exige que los sistemas cubiertos generen los registros que necesitan los equipos de respuesta y los auditores:
“Todos los sistemas cubiertos deben generar registros que capturen: 6.1.1.1 Intentos de autenticación de usuarios y acceso 6.1.1.2 Actividades de usuarios privilegiados 6.1.1.3 Cambios de configuración 6.1.1.4 Intentos de acceso fallidos o eventos del sistema 6.1.1.5 Detecciones de malware y alertas de seguridad 6.1.1.6 Comunicaciones externas y activaciones de reglas de cortafuegos”
De la sección “Requisitos de implantación de la política”, cláusula de política 6.1.1.
Para pymes que dependen de proveedores externos, la Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME añade un requisito contractual:
“Los contratos deben exigir a los proveedores conservar los registros durante al menos 12 meses y proporcionar acceso previa solicitud.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.5.1.3.
La segmentación es igualmente importante. La Network Security Policy-sme Network Security Policy-sme - SME establece:
“Las redes internas deben segmentarse por función (p. ej., finanzas, invitados, IoT, sistemas administrativos).”
De la sección “Requisitos de implantación de la política”, cláusula de política 6.2.1.
Zenith Blueprint, en la fase Controles en acción, paso 20, proporciona el procedimiento práctico de auditoría para arquitectura de red y segmentación. Indica a los equipos que revisen y documenten la topología de red, verifiquen reglas de cortafuegos, configuraciones IPS/IDS y de acceso remoto, confirmen que los grupos de seguridad en la nube y las reglas VPC o de subred coinciden con la arquitectura prevista, enumeren servicios de red internos y externos, y validen que los sistemas sensibles no sean accesibles desde VLAN de usuarios generales o redes de invitados.
Para un MSP, las herramientas de gestión remota no deben permanecer en una red de oficina plana. Para un proveedor de centro de datos, las interfaces de gestión de energía, refrigeración, control de acceso y servicios de red de clientes deben estar aisladas y supervisadas. Para un proveedor de nube, el acceso al plano de control debe restringirse mediante identidad, red, postura de dispositivo y controles de flujo de trabajo privilegiado.
Seguridad de proveedores: el proveedor también es cliente
Los proveedores de nube, MSP, MSSP y centros de datos son proveedores para clientes regulados, pero también son clientes de proveedores de software, operadores de telecomunicaciones, proveedores de identidad, plataformas SaaS, proveedores de hardware, subcontratistas y operadores de infraestructura.
NIS2 convierte la seguridad de la cadena de suministro en un requisito central. DORA, aplicable desde el 17 de enero de 2025, sitúa la gestión del riesgo de terceros TIC en el centro para las entidades financieras. El artículo 4 y el considerando 28 de NIS2 reconocen DORA como el acto jurídico sectorial específico de la Unión para entidades financieras cuando los requisitos se solapan. Esto no elimina la presión sobre los proveedores de nube y MSP. La incrementa, porque los clientes financieros trasladan requisitos contractuales de nivel DORA, derechos de auditoría, pruebas de resiliencia, estrategias de salida y expectativas de notificación de incidentes a los contratos con proveedores.
La Política de Seguridad de Terceros y Proveedores empresarial de Clarysec Third party and supplier security policy exige acceso de terceros controlado:
“Todo Acceso de terceros debe registrarse y supervisarse y, cuando sea viable, segmentarse mediante bastiones de acceso, VPN o pasarelas de Confianza cero.”
De la sección “Requisitos de implantación de la política”, cláusula de política 6.3.2.
La Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME expresa el mínimo privilegio en términos directos:
“A los proveedores solo se les debe conceder acceso a los sistemas y datos mínimos necesarios para desempeñar su función.”
De la sección “Requisitos de implantación de la política”, cláusula de política 6.2.1.
Estas cláusulas se mapean de forma natural con los controles 5.19, 5.20, 5.21 y 5.22 del Anexo A de ISO/IEC 27001:2022. También respaldan la gobernanza de encargados del tratamiento y subencargados del RGPD, las revisiones de riesgo de terceros de DORA y los cuestionarios de auditoría de clientes.
Continuidad del negocio y resiliencia del centro de datos: demostrar los supuestos
El artículo 21 de NIS2 incluye continuidad del negocio, gestión de copias de seguridad, recuperación ante desastres y gestión de crisis. Los artículos 11 a 14 de DORA exigen políticas de continuidad del negocio TIC, planes de respuesta y recuperación, análisis de impacto en el negocio, políticas de copia de seguridad, procedimientos de restauración, objetivos de recuperación, pruebas, revisiones posteriores al incidente y comunicaciones de crisis para entidades financieras.
Para proveedores de nube y centros de datos, la continuidad no es una carpeta. Es arquitectura, capacidad, contratos, dependencias, evidencias de restauración y supuestos probados.
La Política de Continuidad del Negocio y Recuperación ante Desastres empresarial de Clarysec Business Continuity Policy and Disaster Recovery Policy exige BIA anual y revisión tras cambios significativos:
“El análisis de impacto en el negocio (BIA) debe realizarse al menos anualmente para todas las unidades críticas de la organización y revisarse ante cambios significativos en sistemas, procesos o dependencias. Los resultados del BIA deben definir: 5.2.1. Tiempo máximo de inactividad tolerable (MTD) 5.2.2. Objetivos de Tiempo de Recuperación (RTO) 5.2.3. Objetivos de Punto de Recuperación (RPO) 5.2.4. Dependencias críticas (sistemas, proveedores, personal)”
De la sección “Requisitos de gobernanza”, cláusula de política 5.2.
En un escenario de centro de datos, el BIA debe cubrir acometidas eléctricas, UPS, generadores, contratos de combustible, refrigeración, extinción de incendios, operadores de red, sistemas de acceso físico, asistencia remota en sitio, supervisión, hardware de repuesto y canales de comunicación con clientes. En un escenario de nube, debe cubrir regiones, zonas de disponibilidad, replicación, inmutabilidad de copias de seguridad, dependencias de identidad, DNS, autoridades de certificación (CA), pasarelas de interfaces de programación de aplicaciones y sistemas de soporte. En un escenario MSP, debe cubrir herramientas de gestión remota, bóvedas de acceso privilegiado, consolas EDR, sistema de tickets, repositorios documentales y comunicaciones de emergencia.
ISO 22301 puede reforzar la disciplina de gestión de la continuidad del negocio, mientras que ISO/IEC 27005:2022 respalda criterios de riesgo, planificación del tratamiento, supervisión, evidencias y mejora continua. Esto resulta útil porque la preparación NIS2 exige que la organización consolide factores legales, contractuales, operativos, de proveedores, tecnológicos, financieros, de proceso y humanos en un único proceso de riesgo.
Trazabilidad práctica del riesgo para una brecha de acceso remoto en un MSP
Un taller práctico puede comenzar con un escenario:
“El compromiso de acceso remoto privilegiado provoca acceso no autorizado a sistemas de clientes, interrupción del servicio, posible exposición de datos personales y obligaciones de notificación regulatoria.”
Cree una fila en el registro de riesgos y complete la trazabilidad.
| Campo | Ejemplo de entrada |
|---|---|
| Propietario del riesgo | Responsable de servicios gestionados |
| Activos y procesos | Plataforma de gestión remota, cuentas de administrador de clientes, bóveda privilegiada, sistema de tickets, SIEM, entornos de clientes |
| Evento de amenaza | Robo de credenciales, fatiga de MFA, robo de tokens, vulnerabilidad RMM explotada, amenaza interna maliciosa |
| Impacto | Compromiso de cliente, indisponibilidad del servicio, incumplimiento contractual, incidente significativo NIS2, brecha de datos personales del RGPD, escalado a cliente DORA |
| Controles existentes | MFA, PAM, mínimo privilegio, segmentación, registro de eventos, escaneos de vulnerabilidades, plan de respuesta a incidentes (IRP) |
| Tratamiento requerido | Reforzar el acceso condicional, aplicar administración justo a tiempo, mejorar el aislamiento de tenants, aumentar la conservación de registros, probar el playbook de notificación |
| Evidencias ISO/IEC 27001:2022 | Evaluación de riesgos, SoA, revisión de accesos, muestras de registros, informes de vulnerabilidades, ejercicio de mesa, revisión por la dirección |
| Mapeo NIS2 | Artículo 21 sobre gestión de riesgos y artículo 23 sobre notificación de incidentes, más medidas operativas del Reglamento de Ejecución |
| Mapeo de cliente | Notificación contractual, derechos de auditoría, anexo de seguridad, cuestionarios alineados con DORA cuando proceda |
| Decisión de riesgo residual | Aceptado por el propietario del riesgo tras el tratamiento, revisado trimestralmente |
Después, actualice la Declaración de Aplicabilidad. Para cada control pertinente del Anexo A, explique por qué aplica y qué tema de NIS2 respalda. Por último, recopile evidencias antes de una auditoría: informes de aplicación de MFA, listas de cuentas privilegiadas, ajustes de conservación de registros, estado de parches RMM, alertas SIEM, registros de clasificación de incidentes, aprobaciones de acceso de proveedores y resultados de ejercicios de mesa.
Cómo distintos auditores probarán el mismo entorno de control
Un SGSI integrado debe satisfacer diferentes enfoques de aseguramiento sin crear paquetes de evidencias separados para cada marco.
| Enfoque del auditor | En qué se centrará | Evidencias típicas solicitadas |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Si los requisitos de NIS2, DORA y RGPD se reflejan en el contexto, alcance, evaluación de riesgos, SoA, auditoría interna y revisión por la dirección | Alcance del SGSI, registro de partes interesadas, metodología de riesgos, registro de riesgos, SoA, plan de tratamiento, políticas, informe de auditoría interna, revisión por la dirección |
| Autoridad competente NIS2 o evaluador delegado | Si las medidas de gestión de riesgos de ciberseguridad son adecuadas y proporcionadas, y si la notificación de incidentes significativos es operativa | Mapeo NIS2, procedimiento de clasificación de incidentes, flujo de trabajo de 24 y 72 horas, supervisión del consejo de administración, evidencias de control técnico, evidencias de seguridad de proveedores |
| Evaluador de cliente DORA | Si el riesgo de terceros TIC, las pruebas de resiliencia, la notificación de incidentes, los derechos de auditoría y la planificación de salida cumplen las expectativas del sector financiero | Cláusulas contractuales, registro de subcontratistas, pruebas de resiliencia, SLA de incidentes, plan de salida, informes de auditoría, soporte sobre riesgo de concentración |
| Auditor del RGPD o revisión del DPO | Si se abordan el riesgo de brecha de datos personales, las obligaciones de encargado del tratamiento, la confidencialidad, la integridad y la responsabilidad proactiva | Registros de actividades de tratamiento, términos del contrato de encargo de tratamiento, flujo de trabajo de evaluación de brechas, registros de acceso, evidencias de cifrado, controles de conservación y supresión |
| Evaluador orientado a NIST | Si las capacidades de identificar, proteger, detectar, responder y recuperar están implantadas y medidas | Inventario de activos, controles de acceso, datos de vulnerabilidades, cobertura SIEM, playbooks de respuesta, pruebas de recuperación, métricas |
| Auditor COBIT 2019 o ISACA | Si se han establecido objetivos de gobernanza, responsabilidades, propiedad del riesgo, supervisión de controles y procesos de aseguramiento | Estatutos de gobernanza, RACI, apetito de riesgo, propiedad del control, informes de KPI/KRI, plan de aseguramiento, seguimiento de acciones correctivas |
Aquí es donde Zenith Controls ayuda como guía de cumplimiento cruzado. Para controles como 5.23, 5.24 y 8.8, conecta las expectativas de control de ISO/IEC 27001:2022 con temas de NIS2, RGPD, DORA, NIST SP 800-53, COBIT 2019, NIST CSF e ISO 22301. El objetivo no es crear programas de cumplimiento separados. El objetivo es una única arquitectura de evidencias etiquetada por control, riesgo, factor regulatorio y propietario.
El patrón de implantación de Clarysec
Para proveedores de nube, MSP, MSSP y centros de datos, el trabajo debe avanzar en cinco capas.
Primero, confirme el alcance. Determine si la organización y los servicios están dentro del alcance de NIS2, qué normas de los Estados miembros aplican, si el Reglamento de Ejecución 2024/2690 aplica a la categoría del proveedor y si los clientes imponen DORA, RGPD, NIST u obligaciones sectoriales específicas.
Segundo, construya el contexto del SGSI. Conforme a las cláusulas 4 y 5 de ISO/IEC 27001:2022, identifique partes interesadas, obligaciones legales, compromisos con clientes, dependencias de proveedores, límites del servicio y responsabilidades de gestión.
Tercero, realice la evaluación de riesgos y el tratamiento de riesgos utilizando los principios de ISO/IEC 27005:2022. Consolide NIS2, DORA, RGPD, contratos, políticas internas y riesgos del servicio en un único registro de requisitos base. Defina criterios de riesgo, propietarios, probabilidad, impacto, opciones de tratamiento, decisiones de control y aprobaciones de riesgo residual.
Cuarto, mapee los controles en la Declaración de Aplicabilidad. Use los pasos 13 y 14 de Zenith Blueprint para trazar riesgos hacia controles del Anexo A y expectativas regulatorias. Use Zenith Controls para comprender cómo controles como 5.23, 5.24, 8.8, 5.20 y 5.30 se mapean entre marcos y enfoques de auditoría.
Quinto, operacionalice las evidencias. Las políticas no bastan. La biblioteca de políticas de Clarysec proporciona requisitos exigibles para aprobación de nube, acceso de proveedores, registro de eventos, remediación de vulnerabilidades, segmentación de red, clasificación de incidentes y planificación de continuidad. El paquete de evidencias demuestra que esos requisitos funcionan.
Siguiente paso: convertir la presión de NIS2 en resiliencia preparada para auditoría
El Reglamento de Ejecución NIS2 2024/2690 no exige caos. Exige trazabilidad, propiedad y prueba.
Si es proveedor de servicios en la nube, MSP, MSSP u operador de centro de datos, empiece por sus servicios, clientes, dependencias, escenarios de incidente y obligaciones de evidencia. Después ejecute un ejercicio estructurado de mapeo NIS2 a ISO/IEC 27001:2022:
- Confirme si su entidad y sus servicios están dentro del alcance.
- Mapee los temas de NIS2 y del Reglamento de Ejecución en el alcance del SGSI.
- Actualice el registro de riesgos y la Declaración de Aplicabilidad.
- Aplique las políticas de Clarysec para uso de la nube, seguridad de proveedores, registro de eventos, gestión de vulnerabilidades, respuesta a incidentes, seguridad de redes y continuidad.
- Use Zenith Blueprint Zenith Blueprint pasos 13, 14, 20 y 23 para crear trazabilidad y evidencias operativas.
- Use Zenith Controls Zenith Controls para realizar un mapeo cruzado de controles ISO/IEC 27001:2022 frente a expectativas de NIS2, DORA, RGPD, NIST y COBIT 2019.
- Pruebe las evidencias mediante una simulación de auditoría antes de que un cliente, regulador o auditor de certificación las solicite.
Clarysec puede ayudarle a ir más allá del cumplimiento basado en listas de verificación y a construir un SGSI integrado que soporte la presión de NIS2, DORA, RGPD y auditorías de clientes. Descargue los toolkits relevantes de Clarysec, reserve un taller de mapeo o solicite una evaluación de preparación para auditoría para convertir la complejidad regulatoria en gobernanza de la seguridad defendible y resiliencia operativa.
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
