A NIS2 e os seus provedores de software: o que teñen que facer as dúas partes

01En que punto está a NIS2 no outono de 2026

A Directiva NIS2 (abre un sitio web externo), a Directiva (UE) 2022/2555, publicouse no Diario Oficial o 27 de decembro de 2022 e entrou en vigor o 16 de xaneiro de 2023. Os Estados membros tiñan que adoptar e publicar as súas medidas nacionais como tarde o 17 de outubro de 2024 e aplicalas desde o 18 de outubro de 2024, o día en que quedou derrogada a primeira Directiva NIS.

Como a NIS2 é unha directiva, o que obriga a unha organización é a lei nacional que a traspón. A transposición foi desigual: algúns Estados membros aplicaron a súa lei a tempo, outros só en 2025 ou 2026, e a Comisión Europea abriu procedementos de infracción contra os que non cumpriron o prazo. Por iso as obrigas de rexistro, os portais de notificación e as autoridades de supervisión varían de país a país.

A transposición da NIS2 en España segue pendente. O Consello de Ministros aprobou o 14 de xaneiro de 2025 o anteproxecto de lei de coordinación e gobernanza da ciberseguridade, e a referencia do Consello de Ministros do 17 de marzo de 2026 aínda o describe como unha lei que tramita o Ministerio do Interior. O 6 de novembro de 2026 non hai proxecto de lei no Congreso nin lei publicada no BOE. O 8 de xullo de 2026, a Comisión Europea decidiu levar España ante o Tribunal de Xustiza da UE por non comunicar as medidas de transposición.

02O que se aplica hoxe en España

Mentres non haxa lei de transposición, segue en vigor o Real decreto-lei 12/2018 (abre un sitio web externo), do 7 de setembro, de seguridade das redes e sistemas de información, que traspuxo a primeira Directiva NIS e que desenvolve o Real decreto 43/2021. Os equipos de resposta a incidentes de referencia son o CCN-CERT para o sector público e o INCIBE-CERT para as demais entidades.

Para quen traballa co sector público, a norma con máis efecto práctico é o Esquema nacional de seguridade (ENS). O Real decreto 311/2022 (abre un sitio web externo), do 3 de maio, aplícase a todo o sector público e, segundo o seu artigo 2.3, tamén aos sistemas de información das entidades privadas que, en virtude dun contrato, prestan servizos ou proporcionan solucións ás entidades do sector público para o exercicio das súas competencias, incluída a obriga de ter unha política de seguridade. Os pregos deben esixir a conformidade co ENS, por exemplo mediante declaracións ou certificacións de conformidade, e esa esixencia esténdese á cadea de subministración do contratista na medida en que o requira a análise de riscos. Un concello ou unha consellería que contrata software xa ten, polo tanto, un marco que cobre parte do que a NIS2 pide para a cadea de subministración.

Á parte da NIS2, o proxecto de lei de protección e resiliencia das entidades críticas (Congreso, expediente 121/000088) tampouco está aprobado.

03Entidades esenciais e importantes

A NIS2 aplícase ás entidades públicas e privadas dos sectores do anexo I (alta criticidade: enerxía, transporte, banca, infraestruturas dos mercados financeiros, sanidade, auga potable, augas residuais, infraestrutura dixital, xestión de servizos TIC, administración pública e espazo) e do anexo II (outros sectores críticos: servizos postais e de mensaxería, xestión de residuos, produtos químicos, alimentación, fabricación, provedores dixitais e investigación). Como regra xeral, cobre as organizacións medianas e grandes. Algunhas están incluídas sexa cal sexa o seu tamaño, como os prestadores de servizos de confianza, os provedores de servizos DNS e as entidades da administración central.

O artigo 3 clasifica despois estas organizacións en dúas categorías:

• Entidades esenciais: sobre todo organizacións grandes dos sectores do anexo I, máis as que son esenciais sexa cal sexa o seu tamaño, como os prestadores cualificados de servizos de confianza, os rexistros de nomes de dominio de primeiro nivel, os provedores de servizos DNS e as entidades da administración central. A súa supervisión é proactiva e pode incluír auditorías e inspeccións no lugar.
• Entidades importantes: as demais organizacións incluídas nos anexos I e II. A supervisión é a posteriori: a autoridade actúa cando hai indicios de que a entidade non cumpre.

As dúas categorías teñen as mesmas obrigas básicas: medidas de xestión de riscos (artigo 21), notificación de incidentes (artigo 23) e responsabilidade da dirección (artigo 20). A diferenza está na supervisión e nas multas. Polas infraccións dos artigos 21 ou 23, a lei nacional debe permitir multas máximas de polo menos 10 millóns de euros ou o 2 por cento do volume de negocios anual mundial para as entidades esenciais, e de polo menos 7 millóns de euros ou o 1,4 por cento para as importantes, a cantidade que sexa maior. Os Estados membros deciden se se aplican multas ás entidades da administración pública, e en que medida.

Está o seu provedor de software incluído na NIS2?

Escribir software non é, por si mesmo, un sector NIS2. Aínda así, un provedor pode estar incluído directamente. O anexo I cobre os provedores de servizos xestionados, e a NIS2 defíneos de forma ampla: entidades que instalan, xestionan, operan ou manteñen produtos, redes, infraestruturas ou aplicacións TIC para os seus clientes, nas instalacións destes ou a distancia. Un provedor mediano ou grande que opera ou mantén aplicacións para os seus clientes pode, polo tanto, quedar suxeito á NIS2 por si mesmo, igual que os provedores de servizos de nube e de centros de datos. Para estes provedores, o Regulamento de execución (UE) 2024/2690 (abre un sitio web externo) detalla os requisitos técnicos.

Con todo, a maioría dos provedores de software atópanse coa NIS2 a través dos seus clientes, que converten o seu propio deber sobre a cadea de subministración en cláusulas contractuais, cuestionarios e auditorías. Os produtos de software tamén están cubertos polo Regulamento de ciberresiliencia (abre un sitio web externo), o Regulamento (UE) 2024/2847: as súas obrigas de notificación de vulnerabilidades explotadas activamente e de incidentes graves aplícanse desde o 11 de setembro de 2026, e as demais obrigas desde o 11 de decembro de 2027.

04As dez medidas mínimas do artigo 21

O artigo 21 esixe medidas técnicas, operativas e organizativas adecuadas e proporcionadas, baseadas nun enfoque que contemple todos os riscos. Deben reflectir o estado da técnica e as normas europeas e internacionais pertinentes, e ser proporcionadas á exposición da entidade ao risco, ao seu tamaño e á gravidade probable dos incidentes. Como mínimo, inclúen:

1. 01políticas de análise de riscos e de seguridade dos sistemas de información;
2. 02xestión de incidentes;
3. 03continuidade das actividades, como a xestión das copias de seguridade e a recuperación en caso de desastre, e xestión de crises;
4. 04seguridade da cadea de subministración, incluídos os aspectos de seguridade das relacións con provedores directos e prestadores de servizos;
5. 05seguridade na adquisición, o desenvolvemento e o mantemento de redes e sistemas de información, incluídas a xestión e a divulgación de vulnerabilidades;
6. 06políticas e procedementos para avaliar a eficacia destas medidas;
7. 07prácticas básicas de ciberhixiene e formación en ciberseguridade;
8. 08políticas e procedementos sobre criptografía e, cando proceda, cifrado;
9. 09seguridade dos recursos humanos, políticas de control de acceso e xestión de activos;
10. 10autenticación multifactor ou continua, e comunicacións de voz, vídeo e texto e de emerxencia seguras, cando proceda.

Os puntos 4 e 5 son os que afectan os provedores. O artigo 21.3 pídelles ás entidades que teñan en conta as vulnerabilidades específicas de cada provedor directo, a calidade global dos seus produtos e das súas prácticas de ciberseguridade e os seus procedementos de desenvolvemento seguro. Espérase que os seus clientes miren como constrúe vostede o software, non só o que entrega.

05A dirección aproba, supervisa e responde

Segundo o artigo 20, os órganos de dirección das entidades esenciais e importantes deben aprobar as medidas de xestión dos riscos de ciberseguridade, supervisar a súa aplicación e poden ser responsables das infraccións. Os seus membros deben recibir formación, e anímase as entidades a formar tamén o seu persoal con regularidade. Nos organismos públicos seguen aplicándose as normas nacionais sobre a responsabilidade das institucións e do persoal público.

Isto cambia a conversa cos provedores. Unha dirección que ten que aprobar as medidas quere probas que poida seguir: que provedores sosteñen que servizos, que riscos quedan e que se probou de verdade.

06Notificación de incidentes: 24 horas, 72 horas, un mes

O artigo 23 obriga as entidades a notificar os incidentes significativos ao seu CSIRT ou á autoridade competente. Un incidente é significativo se causou ou pode causar unha perturbación operativa grave ou perdas económicas para a entidade, ou danos materiais ou inmateriais considerables a outras persoas. A notificación faise por fases:

Cando proceda, as entidades tamén deben informar sen demora indebida as persoas destinatarias dos seus servizos dos incidentes significativos que poidan afectar eses servizos. As leis nacionais engaden os seus propios formularios e portais.

O prazo comeza a contar cando a entidade ten coñecemento do incidente. Se o incidente comeza nun sistema do provedor, o cliente só pode cumprir o prazo de 24 horas se o provedor o detecta, o recoñece e o comunica en poucas horas. A detección, os rexistros e unha canle de aviso acordada son, polo tanto, cláusulas do contrato, e non só detalles de enxeñaría.

07O que lle pedirá ao seu provedor de software un cliente suxeito á NIS2

Na práctica, o artigo 21 tradúcese en medidas técnicas e probas que un provedor debería poder mostrar sen abrir un proxecto novo. As que vemos con máis frecuencia:

• Un ciclo de vida de desenvolvemento seguro. Modelado de ameazas para os cambios relevantes, revisión por pares, probas de seguridade automáticas e análise de dependencias na cadea de integración, compilacións asinadas e unha lista de materiais de software (SBOM) para cada versión.
• Xestión e divulgación de vulnerabilidades. Unha vía publicada para comunicar vulnerabilidades, tempos de resposta acordados segundo a gravidade e un aviso ao cliente cando unha vulnerabilidade afecta o seu contorno.
• Control de acceso para o persoal do provedor. Contas nominativas, autenticación multifactor, privilexio mínimo, accesos elevados limitados no tempo e un rexistro de cada acción administrativa no contorno do cliente.
• Rexistros e probas sobre incidentes. Eventos relevantes para a seguridade rexistrados con marcas de tempo fiables, conservados durante un período acordado e exportables, para que o cliente poida responder ás preguntas da alerta temperá e do informe final.
• Cooperación ante incidentes. Unha persoa de contacto e unha canle designadas, un tempo de aviso ben dentro das 24 horas do cliente e apoio na análise da causa raíz.
• Continuidade e recuperación. Copias de seguridade comprobadas restaurándoas, obxectivos de recuperación aliñados cos do cliente e un procedemento ensaiado.
• Documentación da cadea de subministración. Unha lista actualizada de subcontratistas e de localizacións de aloxamento, e dos principais compoñentes e servizos de terceiros dos que depende a solución.
• Un plan de saída. Exportación de datos en formatos utilizables, documentación e apoio no traspaso, para que o cliente poida cambiar de provedor sen perder o control do servizo.

Nada disto é novo para os equipos de enxeñaría maduros. O que cambia coa NIS2 é que o cliente ten que poder demostralo. No sector público español, ademais, respondemos aos pregos punto por punto e documentamos o cumprimento do ENS que esixe o contrato. A nosa páxina sobre confianza e cumprimento normativo describe como traballamos como provedor, incluído o noso sistema de xestión da seguridade da información con certificación ISO/IEC 27001.

08Unha lista de comprobación para contratos e compras

1. 01Relacionar provedores e servizos. Rexistre que provedores sosteñen que servizos incluídos no ámbito, e cales teñen acceso aos seus sistemas ou datos.
2. 02Clasificar por criticidade. Aplique os requisitos máis esixentes aos provedores que operan ou poden modificar sistemas críticos.
3. 03Levar as medidas ao contrato. Requisitos de seguridade, tempo e canle de aviso de incidentes, xestión de vulnerabilidades, rexistros e conservación, dereitos de auditoría ou de acceso a probas, normas de subcontratación e localizacións.
4. 04Pedir probas, non declaracións. Certificados co seu alcance, resultados de probas, unha SBOM, a data da última proba de restauración.
5. 05Acordar a saída desde o principio. Devolución dos datos, apoio na transición e o período durante o que o provedor mantén o servizo en funcionamento.
6. 06Ensaiar xuntos. Faga un exercicio de incidentes cos provedores críticos, incluída a alerta temperá de 24 horas.
7. 07Revisar con regularidade. Os provedores, os servizos e as ameazas cambian; un rexistro de provedores que se actualiza unha vez ao ano está desfasado a maior parte do ano.

09A lei nacional decide os detalles

O rexistro, os portais de notificación, os formularios, a autoridade competente e calquera requisito adicional dependen da lei nacional. Algúns Estados membros vinculan as medidas do artigo 21 a un marco ou a unha certificación nacional. En España, todo iso dependerá da lei que traspoña a NIS2; mentres non se aprobe, as obrigas vixentes son as do Real decreto-lei 12/2018 e, para quen traballa co sector público, as do ENS. Como regra xeral, unha entidade queda suxeita ao Estado membro onde está establecida. O artigo 26 establece excepcións: os provedores de comunicacións electrónicas públicas quedan suxeitos a cada país onde prestan servizos; os provedores de nube, de centros de datos e de servizos xestionados, e varios outros provedores dixitais, ao país do seu establecemento principal; e as entidades da administración pública, ao Estado que as creou.

10Que seguir nos próximos meses

• A tramitación en España: a aprobación do proxecto de lei polo Consello de Ministros, a súa chegada ás Cortes e o procedemento ante o Tribunal de Xustiza.
• A proposta Ómnibus dixital (abre un sitio web externo) da Comisión, do 19 de novembro de 2025, COM(2025) 837, que canalizaría as notificacións de incidentes da NIS2, do RXPD, de DORA e doutras normas a través dun punto único de entrada xestionado pola ENISA. En outubro de 2026 aínda estaba no Parlamento Europeo (abre un sitio web externo)); ata que se adopte e se aplique, seguen vixentes as canles e os prazos actuais.
• As avaliacións de riscos coordinadas da UE sobre as cadeas de subministración TIC críticas previstas no artigo 22, que as entidades deben ter en conta ao escoller as medidas sobre os seus provedores.
• O calendario do Regulamento de ciberresiliencia para os produtos de software, con aplicación plena desde o 11 de decembro de 2027.

Para as entidades financeiras, o Regulamento de resiliencia operativa dixital (DORA) substitúe as normas da NIS2 sobre xestión de riscos TIC, notificación de incidentes e supervisión; consulte a nosa análise sobre DORA e os provedores terceiros de servizos TIC. A Comisión mantén unha visión de conxunto da NIS2 e dos seus actos de execución na súa páxina sobre a Directiva NIS2 (abre un sitio web externo).