NIS2 y sus proveedores de software: qué debe hacer cada parte

01Dónde está NIS2 en otoño de 2026

La Directiva NIS2 (se abre en un sitio externo), Directiva (UE) 2022/2555, se publicó en el Diario Oficial el 27 de diciembre de 2022 y entró en vigor el 16 de enero de 2023. Los Estados miembros debían adoptar y publicar sus medidas nacionales a más tardar el 17 de octubre de 2024 y aplicarlas a partir del 18 de octubre de 2024, fecha en que quedó derogada la primera Directiva NIS.

Al tratarse de una directiva, lo que vincula a una organización es la ley nacional de transposición, no la Directiva en sí. La transposición ha sido desigual: algunos Estados miembros aplicaron su ley a tiempo, otros solo en 2025 o 2026, y la Comisión Europea ha abierto procedimientos de infracción contra los Estados que no cumplieron el plazo. El registro, los portales de notificación y las autoridades de supervisión varían, por tanto, de un país a otro.

02Entidades esenciales y entidades importantes

NIS2 se aplica a entidades públicas y privadas de los sectores del anexo I (sectores de alta criticidad: energía, transporte, banca, infraestructuras de los mercados financieros, sanidad, agua potable, aguas residuales, infraestructura digital, gestión de servicios de TIC, administración pública y espacio) y del anexo II (otros sectores críticos: servicios postales y de mensajería, gestión de residuos, sustancias químicas, alimentación, fabricación, proveedores de servicios digitales e investigación). Por regla general, abarca a medianas y grandes organizaciones. Algunas quedan incluidas con independencia de su tamaño, como los prestadores de servicios de confianza, los proveedores de servicios de DNS y las entidades de la Administración central.

El artículo 3 clasifica después estas organizaciones en dos categorías:

• Entidades esenciales: sobre todo grandes organizaciones de los sectores del anexo I, más las entidades esenciales con independencia de su tamaño, como los prestadores cualificados de servicios de confianza, los registros de nombres de dominio de primer nivel, los proveedores de servicios de DNS y las entidades de la Administración central. Se supervisan de forma proactiva, lo que puede incluir auditorías e inspecciones in situ.
• Entidades importantes: el resto de organizaciones incluidas en los anexos I y II. La supervisión es a posteriori: la autoridad actúa cuando hay indicios de incumplimiento.

Ambas categorías tienen las mismas obligaciones esenciales: medidas de gestión de riesgos (artículo 21), notificación de incidentes (artículo 23) y responsabilidad de la dirección (artículo 20). La diferencia está en la supervisión y en las multas. Por infracciones de los artículos 21 o 23, la ley nacional debe prever multas máximas de al menos 10 millones de euros o el 2 % del volumen de negocios anual mundial para las entidades esenciales, y de al menos 7 millones de euros o el 1,4 % para las importantes, aplicándose la cuantía mayor. Cada Estado miembro decide si se pueden imponer multas a las entidades de la Administración pública y en qué medida.

¿Está incluido su propio proveedor de software?

Desarrollar software no es, por sí solo, un sector de NIS2. Aun así, un proveedor puede quedar incluido directamente. El anexo I comprende a los proveedores de servicios gestionados, que NIS2 define de forma amplia: entidades que instalan, gestionan, operan o mantienen productos de TIC, redes, infraestructuras o aplicaciones para sus clientes, en sus instalaciones o a distancia. Un proveedor mediano o mayor que opera o mantiene aplicaciones para sus clientes puede estar sujeto a NIS2 por sí mismo, igual que los proveedores de servicios de computación en nube y de centros de datos. Para ellos, el Reglamento de Ejecución (UE) 2024/2690 (se abre en un sitio externo) detalla los requisitos técnicos.

La mayoría de los proveedores de software, sin embargo, se encuentran con NIS2 a través de sus clientes, que trasladan su propia obligación sobre la cadena de suministro a cláusulas contractuales, cuestionarios y auditorías. Los productos de software están además sujetos al Reglamento de Ciberresiliencia (se abre en un sitio externo), Reglamento (UE) 2024/2847: sus obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves se aplican desde el 11 de septiembre de 2026, y el resto de obligaciones desde el 11 de diciembre de 2027.

03Las diez medidas mínimas del artículo 21

El artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, basadas en un enfoque que abarque todos los peligros. Deben tener en cuenta el estado de la técnica y las normas europeas e internacionales pertinentes, y ser proporcionadas a la exposición al riesgo, al tamaño de la entidad y a la gravedad probable de los incidentes. Incluyen como mínimo:

1. 01políticas de análisis de riesgos y de seguridad de los sistemas de información;
2. 02gestión de incidentes;
3. 03continuidad de las actividades, como la gestión de copias de seguridad y la recuperación en caso de catástrofe, y gestión de crisis;
4. 04seguridad de la cadena de suministro, incluidos los aspectos de seguridad de las relaciones con proveedores y prestadores de servicios directos;
5. 05seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas de redes y de información, incluida la gestión y divulgación de vulnerabilidades;
6. 06políticas y procedimientos para evaluar la eficacia de estas medidas;
7. 07prácticas básicas de ciberhigiene y formación en ciberseguridad;
8. 08políticas y procedimientos sobre el uso de criptografía y, en su caso, cifrado;
9. 09seguridad de los recursos humanos, políticas de control de acceso y gestión de activos;
10. 10cuando proceda, autenticación multifactorial o continua y comunicaciones de voz, vídeo, texto y emergencia seguras.

Los puntos 4 y 5 son los que afectan a los proveedores. El artículo 21, apartado 3, pide a las entidades que tengan en cuenta las vulnerabilidades específicas de cada proveedor directo, la calidad global de sus productos y prácticas de ciberseguridad y sus procedimientos de desarrollo seguro. Sus clientes deben fijarse, por tanto, en cómo desarrolla usted el software, no solo en lo que entrega.

04La dirección aprueba, supervisa y responde

Según el artículo 20, los órganos de dirección de las entidades esenciales e importantes deben aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su aplicación y pueden ser considerados responsables de los incumplimientos. Sus miembros deben recibir formación, y se anima a las entidades a formar también a su personal con regularidad. En el caso de los organismos públicos, siguen aplicándose las normas nacionales sobre la responsabilidad de las instituciones públicas y de los cargos y empleados públicos.

Esto cambia la conversación con los proveedores. Una dirección que debe aprobar las medidas quiere evidencias que pueda seguir: qué proveedores sostienen qué servicios, qué riesgos quedan y qué se ha probado realmente.

05Notificar incidentes: 24 horas, 72 horas, un mes

El artículo 23 obliga a notificar los incidentes significativos al CSIRT o a la autoridad competente. Un incidente es significativo si ha causado o puede causar graves perturbaciones operativas o pérdidas económicas a la entidad, o daños materiales o inmateriales considerables a terceros. La notificación se hace por fases:

Cuando proceda, las entidades deben informar también sin demora indebida a los destinatarios de sus servicios de los incidentes significativos que puedan afectar a esos servicios. Las leyes nacionales añaden sus propios formularios y portales.

El plazo empieza a contar cuando la entidad tiene constancia del incidente. Si el incidente se origina en un sistema del proveedor, el cliente solo cumplirá las 24 horas si el proveedor lo detecta, lo identifica y lo comunica en pocas horas. La detección, los registros y un canal de notificación acordado son, por tanto, materia contractual, no solo técnica.

06Qué pide un cliente sujeto a NIS2 a su proveedor de software

En la práctica, el artículo 21 se traduce en medidas técnicas y evidencias que un proveedor debería poder mostrar sin abrir un proyecto. Estas son las que vemos con más frecuencia:

• Un ciclo de desarrollo seguro. Modelado de amenazas en los cambios relevantes, revisión por pares, pruebas de seguridad automatizadas y análisis de dependencias en el pipeline, builds firmados y una lista de materiales de software (SBOM) en cada versión.
• Gestión y divulgación de vulnerabilidades. Un canal público para notificar vulnerabilidades, tiempos de respuesta acordados según la gravedad y un aviso al cliente cuando una vulnerabilidad afecta a su entorno.
• Control de acceso del personal del proveedor. Cuentas nominativas, autenticación multifactorial, mínimo privilegio, permisos elevados con caducidad y registro de cada acción administrativa en el entorno del cliente.
• Registros y evidencias ante incidentes. Eventos de seguridad registrados con marcas de tiempo fiables, conservados durante un periodo acordado y exportables, para que el cliente pueda responder a las preguntas de la alerta temprana y del informe final.
• Cooperación ante incidentes. Un interlocutor y un canal designados, un plazo de notificación muy inferior a las 24 horas del cliente y apoyo en el análisis de causas.
• Continuidad y recuperación. Copias de seguridad cuya restauración se ha probado, objetivos de recuperación alineados con los del cliente y un procedimiento ensayado.
• Documentación de la cadena. Una relación actualizada de subcontratistas y ubicaciones de alojamiento, y de los principales componentes y servicios de terceros de los que depende la solución.
• Un plan de salida. Exportación de datos en formatos utilizables, documentación y apoyo en el traspaso, para que el cliente pueda cambiar de proveedor sin perder el control del servicio.

Nada de esto es nuevo para un equipo de ingeniería maduro. Lo que cambia con NIS2 es que el cliente debe poder demostrarlo. Nuestra página de confianza y cumplimiento describe cómo trabajamos como proveedor, con un sistema de gestión de la seguridad de la información certificado según ISO/IEC 27001.

07Una lista de comprobación para contratos y licitaciones

1. 01Vincule proveedores y servicios. Registre qué proveedores sostienen qué servicios incluidos en el ámbito y cuáles tienen acceso a sus sistemas o datos.
2. 02Clasifique por criticidad. Aplique los requisitos más exigentes a los proveedores que operan o pueden modificar sistemas críticos.
3. 03Lleve las medidas al contrato. Requisitos de seguridad, plazo y canal de notificación de incidentes, gestión de vulnerabilidades, registros y conservación, derechos de auditoría o de evidencia, reglas de subcontratación y ubicaciones.
4. 04Pida evidencias, no declaraciones. Certificados con su alcance, resultados de pruebas, una SBOM, la fecha de la última prueba de restauración.
5. 05Acuerde la salida desde el principio. Devolución de datos, apoyo en la transición y el periodo durante el cual el proveedor sigue prestando el servicio.
6. 06Ensayen juntos. Realice un ejercicio de incidente con sus proveedores críticos, incluida la alerta temprana en 24 horas.
7. 07Revise con regularidad. Proveedores, servicios y amenazas cambian; un registro de proveedores que se actualiza una vez al año está desfasado la mayor parte del año.

08La ley nacional fija los detalles

El registro, los portales de notificación, los formularios, la autoridad competente y los posibles requisitos adicionales dependen de la ley nacional. Algunos Estados miembros vinculan las medidas del artículo 21 a un marco o a una certificación nacional. Por regla general, una entidad queda sujeta al Estado miembro en el que está establecida. El artículo 26 prevé excepciones: los proveedores de comunicaciones electrónicas públicas quedan sujetos a cada país en el que prestan sus servicios, los proveedores de nube, centros de datos y servicios gestionados y otros proveedores digitales al país de su establecimiento principal, y las entidades de la Administración pública al Estado que las creó.

09Qué seguir en los próximos meses

• Su transposición nacional: plazos de registro, normas de desarrollo y orientaciones de su autoridad.
• La propuesta de la Comisión de un Ómnibus Digital (se abre en un sitio externo) de 19 de noviembre de 2025, COM(2025) 837, que canalizaría las notificaciones de incidentes de NIS2, el RGPD, DORA y otras normas a través de un punto único de entrada gestionado por ENISA. En octubre de 2026 seguía en tramitación en el Parlamento Europeo (se abre en un sitio externo)); hasta que se adopte y sea aplicable, siguen vigentes los canales y plazos actuales.
• Las evaluaciones coordinadas de riesgos de cadenas de suministro de TIC críticas a escala de la UE (artículo 22), que las entidades deben tener en cuenta al elegir las medidas sobre sus proveedores.
• El calendario del Reglamento de Ciberresiliencia para los productos de software, plenamente aplicable desde el 11 de diciembre de 2027.

Para las entidades financieras, el Reglamento de resiliencia operativa digital (DORA) sustituye a las normas de NIS2 sobre gestión de riesgos de TIC, notificación de incidentes y supervisión; consulte nuestro artículo sobre DORA y los proveedores terceros de servicios de TIC. La Comisión mantiene una visión de conjunto de NIS2 y sus actos de ejecución en su página sobre NIS2 (se abre en un sitio externo).