La Directiva NIS2 sobre ciberseguridad lleva varios años en vigor a nivel europeo. No se limita a exigir a las organizaciones europeas que adquieran nuevas herramientas de seguridad. Exige que el riesgo de ciberseguridad se gestione mediante procesos técnicos, operativos y organizativos verificables: desde la gestión de incidentes hasta la continuidad operativa, pasando por el control de cambios y la seguridad de la cadena de suministro.
La clave es la siguiente: muchos de estos procesos ya existen dentro del IT Service Management. El problema es que, en numerosas organizaciones, el cumplimiento de la NIS2 sigue tratándose como un proyecto aislado, delegado casi exclusivamente en los equipos de ciberseguridad, gestión de riesgos o asesoría jurídica.
Mientras tanto, una parte considerable de las evidencias requeridas por los reguladores sigue produciéndose cada día en el service desk, en los workflows de incident management, en los procesos de change management y en los sistemas de gestión de proveedores.
En consecuencia, el verdadero reto al que se enfrentan muchas empresas no consiste en crear nuevos controles desde cero. Consiste en conectar las obligaciones normativas —como las derivadas de la Directiva NIS2— y los requisitos de cumplimiento con los procesos ITSM ya existentes, aumentar su nivel de madurez y transformar los datos operativos en evidencias de cumplimiento fiables.
En esto nos centraremos en el artículo.
Del requisito normativo a la gobernanza operativa
Retrocedamos un poco para contextualizar la cuestión con un caso concreto. La Directiva NIS2, formalmente Directiva UE 2022/2555, entró en vigor el 16 de enero de 2023. Los Estados miembros debían transponerla antes del 17 de octubre de 2024 y las nuevas normas europeas comenzaron a aplicarse a partir del 18 de octubre de 2024 a través de las respectivas normativas nacionales. Para las organizaciones que operan en varios países europeos, también es necesario comprobar cómo se ha transpuesto específicamente la Directiva en cada jurisdicción.
El ámbito de aplicación es mucho más amplio que el de la anterior NIS. Comprende organizaciones públicas y privadas pertenecientes a 18 sectores críticos, entre ellos energía, transporte, sanidad, infraestructuras digitales, servicios en la nube, centros de datos, servicios TIC gestionados, administración pública, producción industrial e investigación.
Pero el cambio más importante no tiene que ver únicamente con el número de entidades afectadas.
La Directiva NIS2 integra la ciberseguridad en la gobernanza empresarial. Los órganos de gestión deben aprobar y supervisar las medidas de gestión del riesgo de ciberseguridad y pueden ser llamados a responder de las carencias de la organización. Por tanto, la seguridad ya no puede quedar confinada al SOC ni delegarse en un grupo reducido de especialistas. Debe formar parte del funcionamiento habitual de la organización.
Y es precisamente aquí donde entra en juego el ITSM.
Por qué el cumplimiento normativo pasa por el IT Service Management
Un entorno ITSM maduro se articula en torno a una serie de principios que encajan directamente con las exigencias de una directiva como la NIS2:
- responsabilidades definidas;
- clasificación y priorización de los eventos;
- escalado basado en reglas;
- SLA y umbrales temporales;
- aprobación y seguimiento de los cambios;
- conocimiento de los activos y servicios implicados;
- supervisión del rendimiento de los proveedores;
- documentación completa de las actividades;
- mejora continua.
Un ticket gestionado correctamente no es solo una solicitud operativa. Es una secuencia documentada de decisiones, responsabilidades, comunicaciones y acciones.
Del mismo modo, un change record no es simplemente la autorización para instalar una nueva versión de software. Puede servir como evidencia de que la organización ha evaluado los riesgos, analizado el impacto, definido un plan de rollback y obtenido las aprobaciones necesarias.
Es el mismo principio ya abordado en nuestro artículo anterior dedicado a la integración de la IA en el ITSM a la luz del EU AI Act [insertar enlace]: cuanto más se integra la tecnología en los procesos empresariales, mayor es la necesidad de definir responsables, controles, documentación y audit trails.
En ambos casos, la plataforma ITSM puede convertirse en el puente entre las políticas y la operativa. Es en ese punto cuando el cumplimiento normativo deja de ser un conjunto de documentos y pasa a formar parte de los procesos operativos.
Incident management: cumplir los plazos empieza en el primer ticket
Veamos ahora otro ejemplo más concreto de la Directiva NIS2. Esta introduce un proceso de notificación en varias fases para los incidentes significativos. En líneas generales, se prevén:
- un early warning en un plazo de 24 horas desde que se tenga conocimiento del incidente;
- una notificación en un plazo de 72 horas, que incluye una primera evaluación;
- un informe final en el plazo de un mes, con detalles sobre el impacto, las causas y las medidas correctivas adoptadas.
Cumplir estos plazos no depende únicamente de la capacidad del equipo de seguridad. Depende de lo que ocurre en los primeros minutos en el service desk.
El workflow de incident management debe, ante todo, distinguir de forma fiable un problema técnico habitual de un posible incidente de seguridad. A continuación, debe recopilar de inmediato la información necesaria: servicio implicado, activos afectados, usuarios involucrados, origen de la notificación, nivel de criticidad, posible propagación, dependencias e impacto en el negocio.
La clasificación no puede depender exclusivamente del criterio de cada operador. Se necesitan categorías compartidas, matrices de prioridad y reglas de escalado.
Un ticket potencialmente relevante en el marco de la NIS2 debería activar automáticamente:
- la notificación al responsable de ciberseguridad;
- la implicación del incident manager;
- la creación de una cronología verificable;
- la aplicación de SLA coherentes con los plazos normativos;
- la conservación de las evidencias técnicas y de las decisiones adoptadas;
- el inicio del workflow de comunicación con la dirección y los equipos jurídico y de cumplimiento.
Una solución de Incident Management Automation como la de EasyVista permite centralizar el registro, la clasificación, la asignación y el seguimiento de los incidentes, reduciendo el riesgo de que un incidente grave quede perdido en un correo electrónico, un chat o una cola genérica.
Este es un primer paso concreto hacia el cumplimiento normativo.
Change management: ningún cambio sin una evaluación del riesgo
No todos los incidentes derivan de un ataque externo. Una parte significativa de los problemas surge de cambios mal planificados, configuraciones erróneas, actualizaciones incompletas o cambios introducidos sin una evaluación adecuada de las dependencias.
Por ello, el change management es uno de los vínculos más importantes entre la Directiva NIS2, el cumplimiento ITSM y la gestión cotidiana de los servicios.
Un workflow preparado para responder a los requisitos de cumplimiento debería documentar, como mínimo:
- el motivo y el objetivo del cambio;
- servicios, activos y configuraciones implicados;
- evaluación del impacto operativo y de seguridad;
- dependencias técnicas;
- aprobaciones recibidas;
- plan de pruebas;
- ventana de implementación;
- plan de rollback;
- resultado del cambio;
- posibles incidentes o vulnerabilidades posteriores.
Los cambios estándar y de bajo riesgo pueden automatizarse. En cambio, aquellos que afecten a servicios esenciales, accesos privilegiados, configuraciones de seguridad o componentes expuestos deben contemplar controles más robustos y, cuando sea necesario, la implicación de los responsables de seguridad.
Supplier management: la cadena de suministro debe integrarse en los workflows ITSM
La seguridad de la cadena de suministro es uno de los pilares de la Directiva NIS2.
Las organizaciones deben considerar no solo los riesgos presentes en sus propios sistemas, sino también los asociados a los proveedores directos de productos y servicios TIC. Los proveedores de nube, los managed service providers, los software vendors, los partners de soporte y los outsourcers pueden representar dependencias esenciales para la prestación de los servicios.
Ya no basta con incluir una cláusula genérica en el contrato.
En consecuencia, el supplier management debería incluir:
- un inventario actualizado de los proveedores y los servicios prestados;
- la clasificación de los vendors por criticidad;
- el mapeo entre proveedor, contrato, servicio y activo;
- requisitos mínimos de seguridad;
- plazos obligatorios de notificación de incidentes;
- derechos de verificación y auditoría;
- procedimientos de escalado;
- evaluaciones periódicas del riesgo.
Entonces, ¿qué significa ser «compliance-ready» en el ITSM?
No hay una respuesta única a esta pregunta.
Estar preparado para el cumplimiento normativo no significa poder declarar que una plataforma, por sí sola, «garantiza el cumplimiento de la Directiva NIS2».
La conformidad depende de la interacción entre personas, procesos, tecnologías, gobernanza y medidas de seguridad. Una plataforma ITSM, sin embargo, puede proporcionar la arquitectura operativa necesaria para aplicar los controles y producir las evidencias correspondientes.
Un entorno ITSM preparado para el cumplimiento debería ser capaz de responder con rapidez a preguntas muy concretas:
- ¿Quién clasificó este incidente y con qué criterios?
- ¿Cuándo comenzó el cómputo de las 24 horas?
- ¿Qué servicios y activos estuvieron implicados?
- ¿Quién autorizó un cambio crítico?
- ¿Qué evaluación del riesgo se realizó?
- ¿Qué proveedor era responsable del componente?
- ¿Qué acciones correctivas se completaron?
- ¿Cómo se verificaron?
- ¿Qué cambió tras la post-incident review?
La capacidad de responder a estas preguntas no debe depender de la memoria de las personas. Debe quedar reflejada directamente en los workflows, los registros y los audit trails.
Por eso, productos como EV Service Manager permiten estructurar los procesos de service management, centralizar la información y automatizar actividades de asignación, escalado, aprobación y reporting.
Conclusiones
La Directiva NIS2, al igual que otras normativas europeas, no debería crear una segunda infraestructura de procesos que funcione en paralelo a las operaciones de TI.
El incident management, el change management, el problem management, el asset management y el supplier management son ya el tejido que articula la gestión de los servicios. Separar el cumplimiento normativo de estos procesos significa duplicar las actividades, aumentar los costes y producir evidencias fragmentadas.
Integrarlo en el IT Service Management significa, en cambio, transformar cada ticket, aprobación, escalado y verificación en una parte coherente de la gobernanza.
El resultado es una doble ventaja. Por un lado, la organización mejora su capacidad de demostrar su conformidad. Por otro, se vuelve realmente más resiliente: detecta antes los incidentes, coordina mejor la respuesta, controla los cambios, conoce las dependencias y gestiona a los proveedores de forma más rigurosa.
FAQ
¿Qué es la Directiva NIS2?
La NIS2 es la directiva europea que ha reforzado y ampliado las obligaciones de ciberseguridad aplicables a las organizaciones que operan en sectores críticos. Introduce requisitos relativos a la gestión del riesgo, la respuesta y notificación de incidentes, la continuidad operativa, la seguridad de la cadena de suministro y la responsabilidad de los órganos de gestión.
¿De qué manera el ITSM apoya el cumplimiento normativo europeo?
El ITSM ofrece procesos estructurados para registrar, clasificar, asignar, supervisar y documentar incidentes, cambios, problemas, activos y actividades de los proveedores. Estos procesos ayudan a aplicar, por ejemplo, controles exigidos por la NIS2 y a producir audit trails y evidencias verificables.
¿Una plataforma ITSM garantiza automáticamente el cumplimiento normativo europeo?
No. Ningún software garantiza por sí solo la conformidad. Una plataforma ITSM puede, sin embargo, ayudar a aplicar los procesos, automatizar los controles, recopilar información, facilitar la colaboración entre equipos y generar las evidencias necesarias.
