Evidencia para el registro NIS2 en ISO 27001:2022

El correo llegó a la bandeja de entrada de Anna con un golpe seco que sonó más a sirena que a notificación. Como directora de seguridad de la información (CISO) de CloudFlow, un proveedor B2B de SaaS en rápido crecimiento que presta servicio a clientes de toda la UE, estaba acostumbrada a cuestionarios de seguridad, auditorías de compras y auditorías de seguimiento de ISO 27001. Este mensaje era distinto.

El asunto decía: “Solicitud de información relativa a la transposición nacional de la Directiva (UE) 2022/2555 (NIS2)”. La autoridad nacional de ciberseguridad quería que CloudFlow confirmara su clasificación, preparara la información de registro de la entidad, identificara los servicios dentro del alcance y estuviera en condiciones de demostrar sus medidas de gestión de riesgos de ciberseguridad.

Anna tenía un certificado ISO 27001:2022 enmarcado en la pared. El equipo comercial lo utilizaba en operaciones con grandes clientes. El órgano de administración había aprobado la Política de Seguridad de la Información. La auditoría interna había cerrado recientemente dos hallazgos. Pero la pregunta que tenía delante era más precisa que el estado de certificación.

¿Podía CloudFlow demostrar, de forma rápida y defendible, que su SGSI ISO 27001:2022 cubría las obligaciones de NIS2?

Ahí es donde muchas organizaciones se equivocan. Tratan el registro de entidad NIS2 como una presentación administrativa, similar a actualizar un registro mercantil o un portal tributario. No lo es. El registro es la puerta de entrada a la visibilidad supervisora. Una vez cruzada esa puerta, la autoridad competente puede solicitar la justificación del alcance, registros de aprobación del órgano de administración, procedimientos de notificación de incidentes, evidencias de riesgo de proveedores, puntos de contacto, métricas de eficacia de los controles y pruebas de que la organización sabe qué servicios son críticos.

Para proveedores SaaS, servicios en la nube, servicios gestionados, seguridad gestionada, centros de datos, infraestructura digital y determinados proveedores del sector financiero, la pregunta real ya no es “¿tenemos una política de seguridad?”. Es “¿podemos mostrar una cadena de evidencias desde la obligación legal hasta el alcance del SGSI, el tratamiento de riesgos, la operación de controles y la supervisión por la dirección?”.

El programa más sólido de preparación ante la aplicación de NIS2 no es una hoja de cálculo paralela. Es un modelo de evidencias trazable dentro de ISO 27001:2022.

El registro NIS2 es, en realidad, un problema de evidencias

NIS2 se aplica ampliamente a entidades públicas o privadas de los sectores enumerados en el anexo I y el anexo II que cumplen o superan el umbral pertinente de empresa mediana. También alcanza a determinadas entidades con independencia de su tamaño, incluidos proveedores de redes o servicios públicos de comunicaciones electrónicas, prestadores de servicios de confianza, registros de TLD, proveedores de servicios DNS, proveedores únicos de servicios esenciales y entidades cuya perturbación pueda afectar a la seguridad pública, la salud pública, el riesgo sistémico o la criticidad nacional o regional.

Para las empresas tecnológicas, las categorías digitales son especialmente importantes. El anexo I incluye infraestructura digital, como proveedores de servicios de computación en la nube, proveedores de servicios de centros de datos, proveedores de redes de distribución de contenidos, prestadores de servicios de confianza, proveedores de servicios DNS y proveedores de redes o servicios públicos de comunicaciones electrónicas. El anexo I también incluye la gestión de servicios TIC para servicios de empresa a empresa, incluidos proveedores de servicios gestionados y proveedores de servicios de seguridad gestionados. El anexo II incluye proveedores digitales, como mercados en línea, motores de búsqueda en línea y plataformas de servicios de redes sociales.

Esto significa que una organización puede entrar en el alcance de NIS2 sin considerarse a sí misma “infraestructura crítica”. Una empresa B2B SaaS con funcionalidad de seguridad gestionada, una plataforma en la nube que da soporte a clientes regulados o un proveedor adyacente al sector fintech pueden necesitar de pronto un expediente de registro, un modelo de contacto con la autoridad competente y una narrativa de controles defendible.

NIS2 también distingue entre entidades esenciales e importantes. Las entidades esenciales suelen estar sujetas a un modelo de supervisión más proactivo, mientras que las entidades importantes se supervisan normalmente tras evidencias de incumplimiento o incidentes. La distinción importa, pero no elimina la necesidad de preparación. Ambas categorías necesitan gobernanza, gestión de riesgos, notificación de incidentes, seguridad de proveedores y evidencias.

Las entidades financieras también deben considerar DORA. El artículo 4 de NIS2 reconoce que, cuando un acto jurídico sectorial específico de la Unión imponga obligaciones de gestión de riesgos de ciberseguridad y de notificación de incidentes al menos equivalentes, esas normas sectoriales se aplican a los ámbitos correspondientes. DORA es aplicable desde el 17 de enero de 2025 y establece la gestión del riesgo de las TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital, el intercambio de información, la gestión del riesgo de terceros de TIC, los controles contractuales y la supervisión de proveedores terceros críticos de servicios de TIC. Para las entidades financieras sujetas, DORA es el marco principal de ciberresiliencia para los requisitos solapados, pero las interfaces con NIS2 y la coordinación con las autoridades nacionales pueden seguir siendo relevantes.

La lección es simple. No espere al campo del portal ni al correo del regulador para construir evidencias. Cada respuesta de registro implica una futura pregunta de auditoría.

Empiece por el alcance del SGSI, no por el formulario del portal

ISO 27001:2022 es útil porque obliga a la organización a definir el contexto, las partes interesadas, las obligaciones regulatorias, el alcance, los riesgos, los planes de tratamiento, la operación de controles, la supervisión, la auditoría interna, la revisión por la dirección y la mejora.

Las cláusulas 4.1 a 4.4 exigen que la organización determine las cuestiones internas y externas, identifique las partes interesadas y sus requisitos, decida qué requisitos se abordan mediante el SGSI, defina el alcance del SGSI teniendo en cuenta interfaces y dependencias, documente dicho alcance y opere los procesos del SGSI.

Para NIS2, ese alcance debe responder a preguntas prácticas:

• ¿Qué servicios en la UE, entidades jurídicas, filiales, plataformas, componentes de infraestructura y unidades de negocio son relevantes?
• ¿Qué categoría del anexo I o del anexo II puede aplicar?
• ¿La organización es esencial, importante, está sujeta a DORA, está fuera de alcance o pendiente de clasificación nacional?
• ¿Qué servicios son críticos para clientes, seguridad pública, estabilidad financiera, sanidad, infraestructura digital u otros sectores regulados?
• ¿Qué proveedores de servicios en la nube, MSP, MSSP, centros de datos, subcontratistas y otros proveedores dan soporte a esos servicios?
• ¿Qué Estados miembros, autoridades competentes, CSIRT, autoridades de protección de datos y supervisores financieros pueden ser relevantes?

Zenith Blueprint: hoja de ruta de 30 pasos para auditoría de Clarysec Zenith Blueprint sitúa este trabajo al inicio, en el paso 2, necesidades de las partes interesadas y alcance del SGSI. Indica a las organizaciones que identifiquen reguladores y autoridades, revisen requisitos legales y regulatorios, revisen contratos y acuerdos, realicen entrevistas con partes interesadas y consideren las normas sectoriales esperadas.

Elemento de acción 4.2: Compile una lista de todas las partes interesadas significativas y anote sus requisitos relacionados con la seguridad de la información. Sea exhaustivo: piense en cualquiera que pudiera reclamar o sufrir consecuencias si su seguridad fallara o si careciera de un determinado control. Esta lista orientará aquello que debe cumplir o satisfacer mediante su SGSI y alimentará la evaluación de riesgos y la selección de controles.

Ese es el punto de partida correcto para el registro NIS2. Antes de presentar la información, cree un breve memorando de alcance NIS2 que conecte el modelo de negocio con las categorías del anexo I o del anexo II, documente las hipótesis de tamaño y servicio, registre la interpretación del derecho nacional, identifique a las autoridades competentes y señale si también aplican DORA, el RGPD de la UE, contratos con clientes o normas sectoriales.

La Política de Cumplimiento Legal y Normativo para pymes de Clarysec Política de Cumplimiento Legal y Normativo - pyme define claramente el propósito:

“Esta política define el enfoque de la organización para identificar, cumplir y demostrar el cumplimiento de obligaciones legales, regulatorias y contractuales.”

Para programas de mayor tamaño, la Política de Cumplimiento Legal y Normativo de Clarysec Política de Cumplimiento Legal y Normativo es aún más explícita:

“Todas las obligaciones legales y regulatorias deben mapearse a políticas, controles y responsables específicos dentro del Sistema de Gestión de la Seguridad de la Información (SGSI).”

Esa frase es la base de la preparación ante la aplicación. Si un regulador pregunta cómo se identificaron las obligaciones de NIS2, la respuesta no debe ser “nos asesoró el equipo legal”. La respuesta debe ser un registro documentado, vinculado al alcance, los riesgos, los responsables de controles, los procedimientos, las evidencias conservadas y la revisión por la dirección.

Construya la cadena de evidencias NIS2 dentro de ISO 27001:2022

El artículo 21 de NIS2 exige que las entidades esenciales e importantes implanten medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que afectan a las redes y sistemas de información utilizados para las operaciones o la prestación del servicio. Las medidas deben tener en cuenta el estado de la técnica, las normas europeas e internacionales pertinentes cuando proceda, el coste, la exposición al riesgo, el tamaño, la probabilidad y gravedad de los incidentes, y el impacto social y económico.

El artículo 21(2) enumera áreas mínimas, incluidas las políticas de análisis de riesgos y seguridad de los sistemas de información, la gestión de incidentes, la continuidad del negocio, las copias de seguridad, la recuperación ante desastres, la gestión de crisis, la seguridad de la cadena de suministro, la adquisición y el desarrollo seguros, la gestión de vulnerabilidades, la evaluación de la eficacia, la ciberhigiene, la formación, la criptografía, la seguridad de recursos humanos, el control de acceso, la gestión de activos, la autenticación multifactor o continua, y las comunicaciones seguras cuando proceda.

ISO 27001:2022 se ajusta de forma natural a esa estructura. Las cláusulas 6.1.1 a 6.1.3 exigen la evaluación de riesgos y el tratamiento de riesgos, incluidos los criterios de aceptación del riesgo, los responsables del riesgo, el análisis de probabilidad y consecuencias, un plan de tratamiento de riesgos, la comparación con los controles del anexo A y una Declaración de Aplicabilidad. La cláusula 8 exige planificación y control operacional, evidencias de que los procesos operaron según lo previsto, control de cambios, control de procesos proporcionados externamente, evaluaciones de riesgos recurrentes y resultados documentados del tratamiento. La cláusula 9.1 exige seguimiento, medición, análisis y evaluación. La cláusula 9.2 exige auditoría interna. La cláusula 10.2 exige actuar sobre no conformidades y acciones correctivas.

La Política de Gestión de Riesgos de Clarysec Política de Gestión de Riesgos - pyme convierte esto en una regla operativa:

“Todos los riesgos identificados deben registrarse en el Registro de Riesgos.”

La Política de Gestión de Riesgos empresarial Política de Gestión de Riesgos conecta el tratamiento de riesgos con la selección de controles de ISO 27001:2022:

“Las decisiones de control resultantes del proceso de tratamiento del riesgo deberán reflejarse en la SoA.”

Esto importa porque las evidencias NIS2 deben ser trazables. Si una autoridad pregunta por qué existe un control, señale la obligación, el riesgo, la decisión de tratamiento, el responsable del control, la entrada de la SoA, el procedimiento y la evidencia. Si la autoridad pregunta por qué no se seleccionó un control, señale la justificación en la SoA, la aceptación del riesgo aprobada y la revisión por la dirección.

La mejor cadena de evidencias es aburrida en el mejor sentido. Cada obligación tiene un responsable. Cada responsable tiene un control. Cada control tiene evidencias. Cada excepción tiene aprobación. Cada hallazgo de auditoría tiene una acción correctiva.

Incorpore la gobernanza del artículo 20 a las evidencias del órgano de administración

El artículo 20 de NIS2 lleva la ciberseguridad al órgano de administración. Los órganos de dirección deben aprobar las medidas de gestión de riesgos de ciberseguridad adoptadas para el artículo 21, supervisar su implantación y pueden ser considerados responsables de las infracciones. Los miembros de los órganos de dirección deben recibir formación, y se anima a las entidades a proporcionar formación periódica en ciberseguridad a los empleados.

Un órgano de administración no puede limitarse a delegar NIS2 en TI. Las evidencias deben mostrar que la dirección comprendió el análisis de alcance NIS2, aprobó el enfoque de gestión de riesgos, revisó los riesgos materiales, asignó recursos, supervisó la implantación, revisó incidentes y ejercicios, y recibió formación.

Las cláusulas 5.1 a 5.3 de ISO 27001:2022 respaldan ese modelo de gobernanza al exigir compromiso de la Alta Dirección, alineación de los objetivos de seguridad de la información con la estrategia de la organización, integración de los requisitos del SGSI en los procesos de la organización, recursos, comunicación, rendición de cuentas e informes de desempeño del SGSI a la Alta Dirección.

La Política de Funciones y Responsabilidades de Gobernanza de Clarysec Política de Funciones y Responsabilidades de Gobernanza define la función de enlace de seguridad como aquella que:

“Actúa como enlace principal con auditores, reguladores y alta dirección en asuntos de seguridad de la información.”

Esa función debe nombrarse en el paquete de evidencias de registro NIS2. No debe quedar implícita. Autoridades, auditores y clientes quieren saber quién coordina el contacto regulatorio, quién es responsable de la notificación de incidentes, quién mantiene el registro legal, quién actualiza los contactos de autoridades y quién informa al órgano de administración.

Un conjunto práctico de evidencias de gobernanza incluye:

• Aprobación por el órgano de administración del marco de gestión de riesgos de ciberseguridad.
• Actas de revisión por la dirección que cubran alcance NIS2, riesgos, incidentes, proveedores y preparación.
• Registros de formación de miembros del órgano de dirección y empleados.
• Una matriz RACI para obligaciones NIS2, controles ISO 27001:2022, notificación de incidentes, aseguramiento de proveedores y comunicación regulatoria.
• Evidencias de que las obligaciones NIS2 se incluyen en la auditoría interna y en la supervisión del cumplimiento.
• Seguimiento de acciones correctivas para deficiencias, riesgos vencidos, excepciones y pruebas fallidas.

Los artículos 32 y 33 también hacen importante la calidad de las evidencias al identificar factores de infracción grave, como incumplimientos repetidos, falta de notificación o de subsanación de incidentes significativos, falta de corrección de deficiencias tras instrucciones vinculantes, obstrucción de auditorías o supervisión, e información falsa o gravemente inexacta. Una evidencia débil puede convertirse en un problema de aplicación incluso cuando existen controles técnicos.

Prepare evidencias de contacto con autoridades y notificación de incidentes antes de las 02:00

Los fallos más dolorosos de notificación de incidentes suelen empezar con una pregunta básica: “¿A quién notificamos?”. Durante un ransomware, un fallo de DNS, un compromiso en la nube o una exposición de datos, los equipos pierden tiempo buscando el CSIRT correcto, la autoridad competente, la autoridad de protección de datos, el supervisor financiero, el canal de las fuerzas y cuerpos de seguridad, la plantilla para clientes y el aprobador interno.

El artículo 23 de NIS2 exige la notificación sin dilación indebida de incidentes significativos que afecten a la prestación de servicios. Un incidente significativo es aquel que ha causado o podría causar una perturbación operativa grave o pérdidas financieras, o que ha afectado o podría afectar a terceros causando daños materiales o inmateriales considerables. El calendario es escalonado: alerta temprana dentro de las 24 horas desde que se tenga conocimiento, notificación del incidente dentro de las 72 horas, actualizaciones intermedias a petición y un informe final dentro del mes posterior a la notificación de 72 horas o tras la gestión del incidente en el caso de incidentes en curso. Cuando proceda, los destinatarios del servicio también deben ser informados de incidentes significativos o amenazas cibernéticas significativas y de las medidas de protección.

Zenith Blueprint, en la fase Controles en acción, paso 22, trata el contacto con las autoridades como preparación, no como pánico:

El principio es sencillo: si su organización fuera objetivo de un ciberataque, estuviera implicada en una violación de seguridad de datos o estuviera bajo investigación, ¿quién llamaría a las autoridades? ¿Cómo sabría qué decir? ¿Bajo qué condiciones se iniciaría ese contacto? Estas preguntas deben responderse por adelantado, no después de los hechos.

Zenith Controls: guía de cumplimiento transversal de Clarysec Zenith Controls cubre el control 5.5 de ISO/IEC 27002:2022, contacto con autoridades. Clasifica el control como preventivo y correctivo, vinculado a confidencialidad, integridad y disponibilidad, y conectado con los conceptos Identify, Protect, Respond y Recover. También vincula el control 5.5 con los controles ISO/IEC 27002:2022 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información, 6.8 Notificación de eventos de seguridad de la información, 5.7 Inteligencia de amenazas, 5.6 Contacto con grupos de interés especial y 5.26 Respuesta a incidentes de seguridad de la información.

Desde una perspectiva de cumplimiento transversal, Zenith Controls mapea el contacto con autoridades al artículo 23 de NIS2, la notificación de violaciones de seguridad conforme al RGPD de la UE, la notificación de incidentes de DORA, NIST SP 800-53 IR-6 Notificación de incidentes y las prácticas de escalado externo de COBIT 2019. Un único registro de contactos de autoridades puede servir a múltiples obligaciones si está diseñado correctamente.

La Política de Respuesta a Incidentes de Clarysec Política de Respuesta a Incidentes - pyme explicita el triaje jurídico:

“Cuando estén implicados datos de clientes, la Dirección General debe evaluar las obligaciones legales de notificación en función de la aplicabilidad del RGPD de la UE, NIS2 o DORA.”

Un paquete sólido de evidencias de contactos con autoridades debe incluir:

• Datos de contacto de la autoridad competente y del CSIRT por Estado miembro y servicio.
• Contactos de autoridades de protección de datos para la notificación de violaciones de seguridad de datos personales conforme al RGPD de la UE.
• Contactos de supervisores financieros si aplica DORA.
• Vías de contacto con fuerzas y cuerpos de seguridad y unidades de ciberdelincuencia.
• Comunicadores internos autorizados y suplentes.
• Umbrales de incidentes para NIS2, el RGPD de la UE, DORA, contratos con clientes y ciberseguro.
• Plantillas de alerta temprana de 24 horas, notificación de 72 horas, actualización intermedia e informe de un mes.
• Registros de ejercicios de mesa que prueben la notificación externa.
• Registros de notificaciones anteriores, decisiones de no notificar y justificación legal.

Mapee el artículo 21 de NIS2 a controles ISO 27001 y evidencias de políticas

Un certificado por sí solo no responde a la pregunta de un regulador. Un mapeo de controles sí. La siguiente tabla proporciona a los equipos de seguridad y cumplimiento un puente práctico entre las áreas del artículo 21 de NIS2, los controles ISO/IEC 27002:2022, los anclajes de políticas de Clarysec y las evidencias.

Zenith Controls de Clarysec también cubre el control 5.31 de ISO/IEC 27002:2022, requisitos legales, estatutarios, regulatorios y contractuales, como control preventivo con impacto en confidencialidad, integridad y disponibilidad. Vincula 5.31 con la privacidad y protección de PII, la conservación de registros, la revisión independiente y el cumplimiento de políticas internas. También mapea 5.31 a la responsabilidad proactiva del RGPD de la UE, el cumplimiento de la cadena de suministro NIS2, la gestión del riesgo de las TIC de DORA, la gobernanza de NIST CSF, los controles de programa de NIST SP 800-53 y la supervisión del cumplimiento externo de COBIT 2019.

“El control 5.31 garantiza que todos los requisitos legales, regulatorios, estatutarios y contractuales relevantes relacionados con la seguridad de la información se identifiquen, documenten y gestionen de forma continua.”

Eso es exactamente lo que una autoridad nacional quiere ver después del registro: no solo que NIS2 figure en una lista, sino que la organización disponga de un mecanismo vivo para identificar, mapear, implantar, supervisar y actualizar obligaciones.

No separe NIS2 de DORA, el RGPD de la UE, los proveedores y la nube

Las evidencias NIS2 rara vez existen de forma aislada.

El artículo 21(2)(d) de NIS2 exige seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad de las relaciones con proveedores y proveedores de servicios. El artículo 21(3) exige que las decisiones de riesgo de proveedores tengan en cuenta vulnerabilidades, la calidad general del producto, las prácticas de ciberseguridad, los procedimientos de desarrollo seguro y las evaluaciones coordinadas de riesgos de la cadena de suministro de la UE que sean pertinentes.

El anexo A de ISO 27001:2022 proporciona el puente operativo mediante A.5.19 a A.5.23. Para organizaciones SaaS y en la nube, estos controles suelen determinar si las evidencias de registro son superficiales o defendibles.

DORA endurece la perspectiva de proveedores para las entidades financieras. Los artículos 28 a 30 exigen gestión del riesgo de terceros de TIC, un registro de contratos de servicios TIC, distinción de servicios que soportan funciones críticas o importantes, evaluación de riesgos precontractual, diligencia debida, requisitos contractuales de seguridad, derechos de auditoría e inspección, derechos de terminación, estrategias de salida probadas, evaluación de subcontratación, transparencia sobre la ubicación de los datos, asistencia en incidentes, cooperación con autoridades y acuerdos de transición. Si un proveedor SaaS presta servicio a clientes regulados por DORA, sus contratos y su paquete de aseguramiento pueden ser examinados aunque él mismo no sea la entidad financiera.

Por tanto, la Política de Seguridad de Terceros y Proveedores - pyme de Clarysec Política de Seguridad de Terceros y Proveedores - pyme debe vincularse al paquete de evidencias NIS2. La preparación de proveedores debe incluir:

• Inventario de proveedores y clasificación de criticidad.
• Diligencia debida de proveedores y evaluaciones de riesgos.
• Cláusulas contractuales sobre seguridad, asistencia en incidentes, derechos de auditoría, ubicación de datos, subcontratación y salida.
• Matrices de responsabilidad compartida en la nube.
• Registros de supervisión de proveedores críticos.
• Pruebas de salida y recuperación para servicios críticos.
• Procedimientos de notificación y escalado de incidentes de proveedores.

El RGPD de la UE también debe integrarse. Un incidente significativo NIS2 también puede ser una violación de seguridad de datos personales si se comprometen datos de clientes, empleados o usuarios. El RGPD de la UE exige que los responsables del tratamiento demuestren responsabilidad proactiva y, cuando se alcancen los umbrales de notificación, notifiquen a la autoridad de control dentro de las 72 horas desde que tengan conocimiento de una violación de seguridad de los datos personales. Su flujo de trabajo de respuesta a incidentes debe evaluar en paralelo las obligaciones de NIS2, el RGPD de la UE, DORA, contractuales y frente a clientes.

Prepare un paquete de evidencias NIS2 en una semana

Un proveedor SaaS, MSP, MSSP, proveedor de nube o empresa de infraestructura digital puede avanzar sustancialmente en una semana enfocada.

Día 1, clasifique la entidad y los servicios. Utilice la declaración del alcance del SGSI y el registro de partes interesadas. Añada un memorando de alcance NIS2 que identifique categorías del anexo I o del anexo II, servicios en la UE, Estados miembros, clientes, dependencias, hipótesis de tamaño y si aplican DORA o normas sectoriales. Registre la incertidumbre de clasificación como un riesgo si la interpretación legal no es definitiva.

Día 2, actualice el registro de obligaciones legales y regulatorias. Añada los artículos 20, 21 y 23 de NIS2, los requisitos de registro conforme al derecho nacional, las obligaciones de violación de seguridad del RGPD de la UE, las obligaciones de DORA cuando sean relevantes y los principales requisitos contractuales de notificación. Mapee cada obligación a una política, responsable, control, fuente de evidencias y frecuencia de revisión.

Día 3, actualice la evaluación de riesgos y el tratamiento. Incluya el impacto legal, regulatorio, operativo, de proveedores, financiero, reputacional y social en los criterios de riesgo. Añada riesgos como falta de registro, clasificación incorrecta de la entidad, omisión de la alerta temprana de 24 horas, contactos de autoridades no disponibles, indisponibilidad de un proveedor que afecte a servicios críticos, supervisión insuficiente por el órgano de administración e incapacidad para evidenciar la eficacia del control.

Día 4, actualice la SoA. Confirme los controles relevantes para NIS2, incluidos A.5.5 contacto con autoridades, A.5.19 a A.5.23 controles de proveedores y nube, A.5.24 a A.5.28 controles de incidentes, A.5.29 seguridad durante interrupciones, A.5.30 preparación de las TIC para la continuidad del negocio, A.5.31 requisitos legales, A.5.34 privacidad, A.8.8 gestión de vulnerabilidades, A.8.13 copias de seguridad, A.8.15 registro de eventos, A.8.16 actividades de monitorización, A.8.24 criptografía y controles de desarrollo seguro A.8.25 a A.8.32.

Día 5, pruebe la notificación de incidentes. Ejecute un ejercicio de mesa: una configuración incorrecta en la nube expone datos de clientes e interrumpe el servicio en dos Estados miembros. Inicie el reloj. ¿Puede el equipo clasificar el evento, evaluar umbrales del RGPD de la UE, NIS2, DORA, contractuales y de clientes, preparar una alerta temprana de 24 horas, redactar una notificación de 72 horas, preservar evidencias y asignar el análisis de causa raíz?

Día 6, recopile evidencias. Cree una carpeta preparada para el regulador con el memorando de alcance, el registro legal, el registro de riesgos, la SoA, la lista de contactos de autoridades, el procedimiento de actuación ante incidentes, el registro de proveedores, actas del órgano de administración, registros de formación, registros de eventos, informes de monitorización, pruebas de copias de seguridad, informes de vulnerabilidades, alcance de auditoría interna y registro de acciones correctivas.

Día 7, revisión por la dirección. Presente el paquete de preparación a la dirección. Registre aprobaciones, riesgos residuales, acciones abiertas, plazos, recursos y responsabilidad de los propietarios. Si el registro es exigible, adjunte el índice de evidencias al registro de decisión de registro.

La Política de Auditoría y Supervisión del Cumplimiento para pymes de Clarysec Política de Auditoría y Supervisión del Cumplimiento - pyme anticipa esta necesidad:

“Las evidencias deben alinearse con las obligaciones de NIS2 cuando la organización haya sido designada como entidad importante o entre de otro modo en el alcance del derecho nacional.”

La Política de Auditoría y Supervisión del Cumplimiento empresarial Política de Auditoría y Supervisión del Cumplimiento establece el objetivo:

“Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos regulatorios, procedimientos legales o solicitudes de aseguramiento de clientes.”

Ese es el objetivo: evidencias defendibles antes de que llegue la solicitud.

Prepárese para diferentes enfoques de auditoría

Un auditor de certificación, una autoridad nacional, un auditor de cliente, un auditor de privacidad y un equipo de aseguramiento de proveedores no harán preguntas idénticas. Un paquete sólido de evidencias NIS2 funciona para todos ellos.

Para el control 5.5 de ISO/IEC 27002:2022, los auditores suelen esperar contactos de autoridades documentados, responsabilidades asignadas, mantenimiento de contactos, procedimientos de respuesta a incidentes y claridad basada en escenarios. Una simple pregunta de auditoría puede revelar la madurez: “En caso de ransomware, ¿quién contacta con las fuerzas y cuerpos de seguridad o con el CSIRT nacional?”. Si la respuesta depende de que alguien recuerde un nombre, el control no está preparado.

La Política de Registro de Eventos y Monitorización de Clarysec Política de Registro de Eventos y Monitorización - pyme refuerza la expectativa probatoria:

“Los registros deben estar disponibles y ser comprensibles para auditores externos o reguladores previa solicitud.”

La Política de Seguridad de la Información de Clarysec Política de Seguridad de la Información establece el estándar empresarial más amplio:

“Todos los controles implantados deberán ser auditables, estar respaldados por procedimientos documentados y por evidencias conservadas de su operación.”

Esa es la prueba de auditoría en una sola frase. Si un control no puede evidenciarse, tendrá poco peso cuando una autoridad competente solicite pruebas.

Lista de verificación final de evidencias de registro NIS2

Use esta lista de verificación antes del registro o antes de responder a una solicitud de una autoridad nacional.

• Documente el análisis de alcance NIS2, incluida la justificación del anexo I o del anexo II, descripciones de servicios, hipótesis de tamaño, presencia en Estados miembros y clasificación de la entidad.
• Identifique si DORA aplica directamente o indirectamente a través de clientes del sector financiero y contratos de servicios TIC.
• Actualice el alcance del SGSI para incluir servicios relevantes, dependencias, procesos externalizados e interfaces regulatorias.
• Añada NIS2, el RGPD de la UE, DORA, normas sectoriales y requisitos contractuales al registro de obligaciones legales y regulatorias.
• Mapee cada obligación a políticas, controles, responsables, evidencias, frecuencia de revisión e informes a la dirección.
• Confirme la aprobación y supervisión por el órgano de administración de las medidas de gestión de riesgos de ciberseguridad.
• Mantenga registros de formación en ciberseguridad de la dirección y empleados.
• Actualice los criterios de riesgo para incluir impacto regulatorio, interrupción del servicio, daño al cliente, impacto transfronterizo y dependencia de proveedores.
• Registre los riesgos relacionados con NIS2 en el registro de riesgos y vincúlelos a planes de tratamiento.
• Actualice la SoA con los controles del anexo A relevantes para NIS2 y su estado de implantación.
• Mantenga listas de contactos de autoridades y procedimientos de notificación para CSIRT, autoridades competentes, autoridades de protección de datos, supervisores financieros y fuerzas y cuerpos de seguridad.
• Pruebe el flujo de trabajo de alerta temprana de 24 horas, notificación de 72 horas, actualización intermedia e informe final de un mes.
• Mantenga evidencias de proveedores y nube, incluidas diligencia debida, contratos, derechos de auditoría, supervisión, subcontratación y planes de salida.
• Evidencie la eficacia del control mediante registros, métricas, auditorías, paneles, resultados de pruebas y acciones correctivas.
• Prepare un índice de evidencias para poder responder rápidamente a cualquier solicitud de reguladores, clientes o auditores.

El siguiente paso con Clarysec

El registro de entidad NIS2 no es la línea de meta. Es el punto en el que su organización se vuelve visible para la supervisión nacional de ciberseguridad. La pregunta correcta no es “¿podemos registrarnos?”. La pregunta correcta es “si la autoridad solicita evidencias después del registro, ¿podemos producir una narrativa coherente ISO 27001:2022 en horas, no en semanas?”.

Clarysec ayuda a las organizaciones a construir esa narrativa mediante Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls y conjuntos prácticos de políticas ISO 27001:2022 que conectan obligaciones legales, tratamiento de riesgos, notificación de incidentes, seguridad de proveedores, registro de eventos, monitorización, evidencias de auditoría y rendición de cuentas de la dirección.

Ejecute una revisión de brechas de evidencias NIS2 frente a su SGSI actual. Empiece por el memorando de alcance, el registro legal, el registro de riesgos, la SoA, la lista de contactos de autoridades, el flujo de trabajo de notificación de incidentes, el registro de proveedores y la carpeta de evidencias de auditoría. Si esos artefactos están incompletos o desconectados, Clarysec puede ayudarle a convertirlos en un paquete de evidencias preparado para el regulador antes de que su autoridad nacional lo solicite.