Directiva NIS2

Cómo funciona

La Directiva NIS2 clasifica a las organizaciones en dos categorías reguladas: operadores de servicios necesaries (obligados desde octubre de 2024) y proveedores de servicios digitales críticos (obligados desde enero de 2025). Un operador de servicio necesari en el sector energético, por ejemplo, debe identificar activos críticos, evaluar riesgos de ciberseguridad inherentes a esos activos, y documentar controles técnicos que reduzcan el riesgo a un nivel aceptable.
La Directiva NIS2 artículo 17 exige que los operadores apliquen medidas de seguridad proporcionales al riesgo: criptografía, segmentación de redes, gestión de vulnerabilidades, planes de continuidad, pruebas de resiliencia y formación del personal. El artículo 19 especifica que la dirección debe asegurar la supervisión de estas medidas a nivel de consejo, y que exista un procedimiento para notificar incidentes graves a las autoridades nacionales en un plazo máximo de 24 horas desde que la entidad tenga conocimiento del incidente.
El auditor externo no certifica el cumplimiento de NIS2 (ese es un rol regulatorio de las autoridades nacionales competentes). Sin embargo, en el contexto de la auditoría de estados financieros bajo NIA-ES, el auditor evalúa si existe un riesgo material de fraude o error derivado de un incidente de ciberseguridad no detectado o no divulgado. La NIA-ES 240.A11 requiere que el auditor considere el riesgo de fraude en el procesamiento de transacciones e información financiera; si un incidente de ciberseguridad comprometió la integridad de los sistemas que producen datos contables, el auditor debe evaluar si los saldos de los estados financieros pueden no ser íntegros.
muchas organizaciones sujetas a NIS2 también están obligadas a reportar hechos posteriores (eventos de ciberseguridad ocurridos después del cierre pero antes de la aprobación de cuentas) conforme a la NIA-ES 560. Si una entidad sufrió un incidente significativo tras el cierre pero antes de la firma del informe de auditoría, debe evaluarse si el evento requiere ajuste o divulgación en las notas.

Ejemplo práctico: Operador de red de distribución eléctrica

Entidad: Distribuidora Ibérica de Energía S.A., Sevilla, facturación anual de 380 millones de euros, operador de servicio necesari bajo NIS2.
Situación: En la auditoría del ejercicio 2024, el auditor identifica que la entidad clasificó correctamente su estatus como operador necesari (artículo 2, Directiva NIS2). La dirección implementó medidas de seguridad documentadas: segregación física de redes de control industrial, sistema de gestión de acceso basado en roles, copias de seguridad diarias en almacenamiento desconectado de la red principal, y plan de continuidad probado semestralmente.
Paso 1: Evaluación de clasificación regulatoria
El auditor verifica que la dirección identificó correctamente su estatus. La entidad suministra red de distribución eléctrica a más de 200.000 usuarios; según el artículo 2(b) de NIS2, esto la clasifica como operadora de servicio necesari en el sector energía.
Documentación en el papel de trabajo: "Se confirmó la autoclasificación de la entidad como OSE mediante análisis de: (1) resolución de designación de autoridad nacional competente (AEPD y Secretaría de Estado de Digitalización), (2) cobertura de usuarios (>100.000), (3) sectores servidos (energía). Sin discrepancias."
Paso 2: Evaluación de medidas de seguridad documentadas
El auditor obtiene la documentación de medidas de seguridad (política de ciberseguridad, inventario de activos críticos, matriz de riesgos). Verifica que la dirección llevó a cabo, como mínimo: (a) identificación de activos críticos para la continuidad de servicio, (b) evaluación de riesgos de ciberseguridad inherentes a esos activos, (c) documentación de controles implementados.
En el caso de Distribuidora Ibérica, el auditor prueba:
Documentación: "Se obtuvieron y analizaron documentos de medidas de seguridad de NIS2 (política, inventario de activos críticos, matriz de riesgos, registros de pruebas de resiliencia). No se identificaron discrepancias entre la política documentada y la aplicación observada en pruebas de control."
Paso 3: Evaluación de procedimientos de notificación de incidentes
El auditor verifica que existe un procedimiento escrito para notificar incidentes de ciberseguridad grave a las autoridades competentes (AEPD, CNI, INCIBE) en el plazo de 24 horas desde que la entidad tiene conocimiento. Obtiene el registro de incidentes de 2024: se registraron 3 incidentes menores (intentos de acceso no autorizado bloqueados por firewall), ninguno calificó como grave. La dirección documentó que evaluó cada incidente, determinó que no comprometía la disponibilidad, integridad o confidencialidad de activos críticos, y consideró que no requería notificación regulatoria.
Documentación: "Se revisó el procedimiento de notificación de incidentes (versión 2.1, aprobado 15.03.2024). Se analizó el registro de incidentes de enero a noviembre de 2024 (3 registros); en cada caso, se verificó que la dirección evaluó el incidente, documentó la decisión sobre si calificaba como grave, y en caso negativo, fundamentó por qué no requería notificación a autoridades. Conclusión: procedimiento presente y aplicado de forma consistente."
Paso 4: Evaluación del riesgo de error material en estados financieros
El auditor considera: (a) ¿podrían los sistemas de información comprometidos por un incidente de ciberseguridad no detectado generar un error material en los estados financieros? (b) ¿existen hechos posteriores al cierre que deberían divulgarse conforme a NIA-ES 560?
En este caso, la entidad opera sistemas separados para contabilidad (ERP Oracle financiero, segregado de red de control industrial) y control de red eléctrica (SCADA, sistemas de tiempo real). El auditor verifica que no existe acceso cruzado. Los tres incidentes de 2024 se produjeron en intentos de acceso a SCADA; ninguno afectó a sistemas financieros. Riesgo de error material en estados financieros derivado de ciberseguridad: bajo.
Documentación: "Se evaluó el riesgo de que un incidente de ciberseguridad pudiera materialmente distorsionar los saldos de los estados financieros. Conclusión: riesgo bajo, en virtud de: (1) segregación de sistemas (ERP financiero desconectado de redes de control industrial), (2) sin incidentes que afectaran sistemas contables en 2024, (3) pruebas de control muestran procedimientos de acceso funcionando como se diseñaron. No se requiere ajuste de riesgo inherente. Riesgo de auditoría para ciclo de sistemas de información: bajo."
Conclusión: El auditor concluyó que la dirección identificó correctamente su estatus de operador necesari bajo NIS2, documentó medidas de seguridad proporcionales al riesgo conforme al artículo 17, y aplicó procedimientos de notificación de incidentes según el artículo 19. No se identificaron deficiencias de control que indicaran un riesgo material no mitigado. El incidente de ciberseguridad no fue un factor material en la auditoría de los estados financieros 2024.

Inventario de activos críticos (servidores de control, SCADA, centros de datos): presente, fecha 30.09.2024.
Matriz de riesgos de ciberseguridad: identificados 47 riesgos iniciales, 42 mitigados mediante controles técnicos, 5 asumidos por la dirección con justificación documentada.
Pruebas de resiliencia: simulacros de recuperación ante desastre en Q2 2024 (13 de junio) y Q4 2024 (8 de noviembre); documentos de resultados, acciones correctivas identificadas y cerradas.

Qué revisores y auditores entienden mal

Confundir el rol del auditor externo con el del regulador NIS2. La Directiva es responsabilidad de la dirección y de las autoridades nacionales de supervisión (AEPD, CNI, INCIBE en España; equivalentes en otros países). El auditor externo no "audita NIS2" en el sentido de certificar cumplimiento. Evalúa si existe un riesgo material de error o fraude en los estados financieros derivado de debilidades de ciberseguridad documentadas. La Autoridad de Protección de Datos (AEPD) es la que verifica el cumplimiento de NIS2 mediante auditorías regulatorias separadas. El auditor de cuentas anuales puede observar evidencia de que la dirección llevó a cabo medidas de ciberseguridad y documentó el cumplimiento, pero no es responsabilidad suya certificar que cada medida técnica cumple la Directiva.
Asumir que un incidente de ciberseguridad reportado a las autoridades automáticamente genera una divulgación obligatoria en las notas de los estados financieros. Conforme a NIA-ES 560, un evento posterior requiere ajuste o divulgación si es relevante para los usuarios de los estados financieros. Un incidente de ciberseguridad notificado a la AEPD tras el cierre pero antes de la aprobación de cuentas requiere evaluación de materialidad. Si afectó sistemas críticos, comprometió datos financieros, o generará costes de remediación significativos, probablemente requiera divulgación. Si fue un intento de acceso bloqueado por controles existentes, sin consecuencias financieras o de cumplimiento, probablemente no requiera divulgación. El auditor debe ejercer juicio profesional; no existe una regla automática.
Interpretar "medidas proporcionales al riesgo" como equivalente a "medidas mínimas predefinidas en un checklist." El artículo 17 de NIS2 exige medidas proporcionales al riesgo inherente a los activos críticos de cada entidad. Esto implica que una entidad puede, legítimamente, implementar un conjunto de medidas diferente de otra basándose en su evaluación de riesgos. El auditor debe verificar que la dirección ejecutó un análisis de riesgos creíble (no un checklist administrativo), identificó riesgos importantes, y documentó las medidas que implementó como respuesta. Una matriz de riesgos que lista 50 riesgos sin priorización, o medidas que responden a una lista genérica sin conexión a los riesgos identificados en el análisis de la entidad, señala debilidad de proceso.

Comparación: NIS2 vs. NIS1

La Directiva NIS1 (2016/1148/UE) fue la primera normativa europea unificada de ciberseguridad. NIS2 la reemplaza y amplía de forma notable en cuatro aspectos:
Cobertura: NIS1 se aplicaba a operadores de servicios necesaries en 7 sectores (energía, transporte, agua, sanidad, finanzas, infraestructura digital, administración pública). NIS2 expande esto a 11 sectores, incluidos nuevos como espacios públicos, administración local y algunos servicios digitales críticos no regulados antes.
Umbrales de personal: NIS1 no tenía umbrales claros para pequeñas entidades en sectores cubiertos. NIS2 introduce excepciones para microempresas (menos de 10 empleados y menos de 2 millones de euros de facturación) en algunos sectores, reduciendo el cumplimiento regulatorio para las más pequeñas, pero ampliando la cobertura global.
Requisitos técnicos: NIS1 establecía medidas generales. NIS2 especifica medidas técnicas concretas: criptografía, pruebas de seguridad, gestión de vulnerabilidades, plan de continuidad, formación de personal, supervisión por la dirección. El artículo 17 de NIS2 lista estas 11 medidas; NIS1 no las enumeraba tan explícitamente.
Supervisión por la dirección: NIS2 artículo 19 obliga a que el consejo de administración supervise la aplicación y eficacia de medidas de ciberseguridad. NIS1 no imponía este requisito de gobernanza explícito. Esto significa que en NIS2, el auditor puede identificar riesgos de fraude o error derivados de debilidad de supervisión a nivel de dirección (contradicción de NIA-ES 240.A11 sobre el riesgo de fraude en el procesamiento de transacciones si los sistemas de información no son supervisados adecuadamente).
Plazos de notificación: NIS1 requería notificación "sin demora indebida." NIS2 lo especifica como máximo 24 horas desde que la entidad tiene conocimiento de un incidente grave. Esto reduce ambigüedad pero aumenta exigencia operativa.
El auditor debe distinguir entre ambas porque algunas organizaciones aún operan bajo NIS1 (hasta octubre de 2024 para operadores necesaries, enero de 2025 para algunos proveedores de servicios digitales). Verificar que la dirección aplicó la normativa correcta para su fecha de transición es importante.

Términos relacionados

---

Hechos posteriores (NIA-ES 560): Eventos de ciberseguridad ocurridos tras el cierre pero antes de la aprobación de cuentas pueden ser hechos posteriores cuya divulgación es obligatoria si son relevantes.
Riesgo de fraude (NIA-ES 240): El auditor considera si debilidades de ciberseguridad que comprometen sistemas de información aumentan el riesgo de fraude no detectado en transacciones o saldos.
Control interno (NIA-ES 315): Las medidas de ciberseguridad de NIS2 son parte del control interno de la entidad; el auditor evalúa su eficacia como parte de la comprensión de control de sistemas de información.
Riesgo inherente (NIA-ES 315): El riesgo inherente a activos críticos de ciberseguridad antes de cualquier control es el que la dirección evalúa conforme al artículo 17 de NIS2.
Evaluación de riesgos (NIA-ES 315): La matriz de riesgos de ciberseguridad que la dirección documenta conforme a NIS2 es el procedimiento de evaluación de riesgos requerido por NIA-ES 315.
Divulgación en notas (NIA-ES 706): Si un incidente de ciberseguridad significativo tras el cierre requiere divulgación, el auditor verifica que la descripción en notas es clara y precisa.