Definition
La mayoría de despachos no sabe si su cliente es operador de servicios esenciales bajo NIS2 hasta que el propio cliente se lo dice. Y muchos clientes tampoco lo saben. Lo descubren cuando reciben una comunicación del INCIBE o cuando el consejo, dos meses antes del cierre, pregunta de pasada si "lo de NIS2 ya está cerrado".
El alegato: dónde acaba la responsabilidad del auditor
Tesis: el auditor externo NO certifica NIS2, pero SÍ es responsable de evaluar el riesgo de error material derivado de un incidente de ciberseguridad no detectado, no documentado o no notificado.
Algunos despachos están facturando aparte una "auditoría NIS2" como servicio adicional al cierre. El contraargumento de quienes lo hacen es razonable: el cliente quiere comodidad, y si la dirección no tiene un CISO, alguien tiene que mirar la matriz de riesgos. La refutación, por lo que conozco, es que ese trabajo no es auditoría de cuentas y no debería ir en el archivo del encargo. Se confunde con la opinión y, si las cosas van mal, le han abierto expediente al socio firmante por una cosa que ni siquiera estaba en el alcance de la NIA-ES.
Veredicto: el auditor de cuentas anuales tiene tres trabajos respecto a NIS2, y solo tres. Verificar que la dirección evaluó si era OSE. Comprender si los sistemas afectados producen datos contables. Y, si hay incidente posterior al cierre, aplicar la NIA-ES 560. Lo demás es otro encargo, con otra carta y otros honorarios.
Cómo funciona en la práctica
NIS2 clasifica a las organizaciones en dos categorías reguladas: operadores de servicios esenciales (obligados desde octubre de 2024) y proveedores de servicios digitales críticos (obligados desde enero de 2025). Un operador en el sector energético, por ejemplo, debe identificar activos críticos, evaluar el riesgo de ciberseguridad inherente a esos activos, y documentar controles técnicos que reduzcan el riesgo a un nivel aceptable.
El artículo 17 enumera medidas concretas: criptografía, segmentación de redes, gestión de vulnerabilidades, planes de continuidad, pruebas de resiliencia, formación del personal. El artículo 19 añade la pieza de gobernanza: el consejo de administración debe supervisar la aplicación y eficacia de las medidas, y existir un procedimiento para notificar incidentes graves a las autoridades nacionales en un plazo máximo de 24 horas desde que la entidad tiene conocimiento del incidente.
Lo que realmente ocurre es que la política existe, la matriz de riesgos existe, el inventario de activos existe. Están todos en una carpeta del SharePoint que nadie abre desde la última auditoría interna. El consejo "supervisa" la ciberseguridad por medio de una diapositiva de cinco minutos en la última reunión del año, normalmente al final del orden del día, antes del turno de ruegos y preguntas. El director financiero firma el acta. Para muchos consejos, NIS2 es un asunto que se ha marcado la casilla y fue un trámite. La distancia entre lo escrito y lo aplicado es donde vive el riesgo de auditoría.
Por qué existe la brecha
¿Y por qué existe esa brecha? Porque la ciberseguridad se delega al departamento de IT (a veces externalizado a un proveedor que también factura el mantenimiento), el consejo firma sin leer porque nadie del consejo entiende la arquitectura SCADA, y el auditor externo no tiene capacidad técnica para discutir si la segmentación de red es adecuada. Los honorarios del encargo no incluyen un especialista TI. Cuando se incluye, normalmente es alguien junior del despacho que pasa medio día en oficinas y se va con tres pantallazos. La consecuencia: la documentación termina con papeles flojos y la dirección lo sabe, pero nadie tiene incentivo para señalarlo.
El verdadero riesgo de auditoría bajo NIS2 no son los incidentes — son las decisiones de no notificar que la dirección tomó sin documentar el porqué.
Dónde encaja con la NIA-ES
El auditor externo no certifica el cumplimiento de NIS2; ese rol corresponde a las autoridades nacionales competentes (en España, INCIBE como CSIRT de referencia, junto a CCN-CERT y AEPD según el sector). 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 comprometió la integridad de los sistemas que producen datos contables, hay que evaluar si los saldos 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 y antes de la firma del informe, debe evaluarse si el evento requiere ajuste o divulgación en las notas.
Aquí es donde dos auditores razonables pueden discrepar. El Socio A sostiene que cualquier incidente de ciberseguridad ocurrido tras el cierre y notificado al INCIBE requiere mención en notas, porque el usuario de los estados financieros tiene derecho a conocer la exposición operativa de la entidad y porque la propia notificación regulatoria es un hecho objetivo. El Socio B responde que la NIA-ES 560 habla de relevancia para los usuarios y materialidad: si el incidente afectó únicamente a redes de control industrial sin tocar el ERP financiero, sin coste de remediación significativo y sin sanción esperable, la divulgación es ruido y no señal. Ambas posiciones tienen base. En mi caso, me inclino por el Socio B cuando la evaluación de la dirección está documentada y es defendible, y por el Socio A cuando esa evaluación falta o es genérica. La diferencia, en realidad, no es de criterio sino de evidencia disponible.
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 esencial bajo NIS2.
Situación: En la auditoría del ejercicio 2024, el auditor revisa la clasificación de la entidad como OSE conforme al artículo 2 de la Directiva. La dirección ha establecido medidas 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 la 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 esencial 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 (CNI/CCN-CERT 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 las medidas de seguridad documentadas
El auditor obtiene la documentación (política de ciberseguridad, inventario de activos críticos, matriz de riesgos). Verifica que la dirección ha llevado a cabo, como mínimo: identificación de activos críticos para la continuidad de servicio, evaluación de riesgos de ciberseguridad inherentes a esos activos, y documentación de los controles aplicados.
En el caso de Distribuidora Ibérica, el auditor prueba: - 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.
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 los procedimientos de notificación de incidentes
El auditor verifica que existe un procedimiento escrito para notificar incidentes graves a las autoridades competentes (INCIBE-CERT, CCN-CERT, AEPD según el caso) en el plazo de 24 horas. Obtiene el registro de incidentes de 2024: se registraron 3 incidentes menores (intentos de acceso no autorizado bloqueados por firewall), ninguno calificado 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."
La complicación
En enero de 2025, mientras el equipo terminaba pruebas sustantivas, un mensaje en un foro técnico mencionaba un "incidente operativo" en Distribuidora Ibérica del 18 de octubre de 2024. No aparecía en el registro de incidentes que la dirección había facilitado. El auditor solicitó aclaración. La respuesta del CISO: hubo una alarma SCADA por una pérdida momentánea de comunicación con una subestación, restablecida en 14 minutos, sin afectación de servicio. La dirección lo evaluó internamente y concluyó que no era un incidente grave a efectos del artículo 23 de NIS2; por eso no figuraba en el registro formal.
¿Era grave? La dirección dijo que no. El papel del auditor no es sustituir el juicio técnico de un ingeniero de redes que sabe lo que es una pérdida de 14 minutos en un anillo de media tensión. El papel del auditor es comprobar si la evaluación se hizo, si quedó documentada con criterio razonable y si la decisión de no notificar fue defendible en su momento. El auditor pidió el correo interno del 18 de octubre, el log del SCADA, y la nota del CISO al consejero delegado. Estaban. La decisión, registrada el 19 de octubre, no era brillante pero era trazable. Conclusión: no se modifica el riesgo evaluado, pero se añade un comentario en el papel de trabajo sobre la integridad del registro de incidentes.
Paso 4: evaluación del riesgo de error material en estados financieros
El auditor considera dos preguntas. ¿Podrían los sistemas de información comprometidos por un incidente no detectado generar un error material en los estados financieros? ¿Existen hechos posteriores al cierre que deberían divulgarse conforme a NIA-ES 560?
En este caso, la entidad opera sistemas separados: ERP Oracle financiero, segregado de la red de control industrial; SCADA y sistemas de tiempo real en el lado operativo. 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 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 del encargo: la dirección identificó correctamente su estatus de operador esencial, documentó medidas proporcionales al riesgo conforme al artículo 17, y aplicó procedimientos de notificación 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.
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 (INCIBE, CCN-CERT, AEPD en España según el sector; 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 competente verifica el cumplimiento de NIS2 mediante inspecciones regulatorias separadas. El auditor de cuentas anuales puede observar evidencia de que la dirección llevó a cabo medidas y documentó el cumplimiento, pero no es responsabilidad suya certificar que cada medida técnica cumple la Directiva.
- Asumir que un incidente notificado a las autoridades genera automáticamente una divulgación obligatoria en notas. Conforme a NIA-ES 560, un evento posterior requiere ajuste o divulgación si es relevante para los usuarios. Un incidente notificado al INCIBE 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. El auditor debe ejercer juicio profesional; no existe una regla automática.
- Interpretar "medidas proporcionales al riesgo" como "medidas mínimas predefinidas en un checklist". El artículo 17 exige medidas proporcionales al riesgo inherente a los activos críticos de cada entidad. Esto implica que una entidad puede, legítimamente, aplicar un conjunto de medidas distinto del de otra basándose en su evaluación de riesgos. El auditor debe verificar que la dirección ejecutó un análisis creíble (no un checklist administrativo), identificó riesgos importantes, y documentó las medidas que aplicó como respuesta. Una matriz que lista 50 riesgos sin priorización, o medidas que responden a una lista genérica sin conexión a los riesgos identificados, 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 la amplía de forma notable en cinco aspectos.
Cobertura de sectores. NIS1 se aplicaba a operadores de servicios esenciales en 7 sectores (energía, transporte, agua, sanidad, finanzas, infraestructura digital, administración pública). NIS2 expande la cobertura a más de una decena de sectores, incluidos servicios postales, gestión de residuos, fabricación de productos críticos, alimentación y administración pública subcentral.
Umbrales de tamaño. 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 la carga regulatoria para las más pequeñas pero ampliando la cobertura global.
Requisitos técnicos. NIS1 establecía medidas generales. NIS2 especifica medidas concretas: criptografía, pruebas de seguridad, gestión de vulnerabilidades, plan de continuidad, formación del personal, supervisión por la dirección. El artículo 17 las enumera de forma explícita; NIS1 no.
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 las medidas. NIS1 no imponía este requisito de gobernanza. En NIS2, el auditor puede identificar riesgo de fraude o error derivado de debilidad de supervisión a nivel de dirección (en línea con NIA-ES 240.A11 sobre el riesgo de fraude en el procesamiento de transacciones cuando los sistemas no se supervisan adecuadamente).
Plazos de notificación. NIS1 requería notificación "sin demora indebida". NIS2 lo concreta en un máximo de 24 horas desde que la entidad tiene conocimiento de un incidente grave, con notificación final en 72 horas e informe completo en un mes. Reduce ambigüedad y aumenta exigencia operativa.
El auditor debe distinguir entre ambas porque algunas organizaciones aún operan bajo NIS1 (hasta octubre de 2024 para operadores esenciales, 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 un punto que conviene dejar trazado en el archivo.
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 del 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.
---