La directiva NIS2 obliga a las entidades esenciales e importantes a gestionar de forma activa la ciberseguridad de su cadena de suministro, lo que se traduce en exigencias concretas a los proveedores: cláusulas contractuales de seguridad, evaluaciones periódicas, obligaciones de notificación de incidentes y capacidad de auditoría. Para el departamento de compras esto significa incorporar criterios de ciberseguridad en la homologación, el contrato y el seguimiento continuo de cada proveedor tecnológico relevante. En España, a septiembre de 2026, NIS2 sigue sin transponerse: el Gobierno aprobó en enero de 2025 el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, que no se ha publicado en el BOE. Mientras tanto sigue vigente el Real Decreto-ley 12/2018 (NIS1).

Durante años, la ciberseguridad fue un asunto que muchas organizaciones consideraban competencia exclusiva del departamento de IT o de seguridad de la información. La cadena de suministro digital se contrataba con criterios de precio, funcionalidad y nivel de servicio, y el riesgo cibernético del proveedor quedaba, en el mejor de los casos, como una casilla más en un cuestionario. La directiva NIS2 cambia esa lógica de raíz: convierte la seguridad de los proveedores en una obligación regulatoria con consecuencias legales para la entidad que los contrata. Y eso coloca al área de compras y procurement en primera línea, porque es quien selecciona, homologa, contrata y evalúa a esos proveedores. Este artículo explica qué exige NIS2 respecto a la cadena de suministro, qué controles pedir a tus proveedores tecnológicos y cómo gestionarlo desde el proceso de compras, con un enfoque práctico pensado para responsables que tienen que traducir la norma en cláusulas, criterios y decisiones cotidianas.

Qué es la directiva NIS2 en una frase

NIS2 (Directiva UE 2022/2555, relativa a las medidas destinadas a garantizar un elevado nivel común de ciberseguridad en toda la Unión) es la norma europea que eleva y armoniza las exigencias de ciberseguridad para un amplio conjunto de sectores considerados críticos o importantes, sustituyendo y ampliando de forma considerable a la anterior directiva NIS de 2016.

La clave para entenderla desde compras es que NIS2 no se limita a proteger los sistemas propios de la entidad obligada. Reconoce explícitamente que una organización puede tener sus sistemas perfectamente protegidos y aun así verse comprometida a través de un proveedor: un software de terceros con una vulnerabilidad, un servicio gestionado con accesos mal controlados, un proveedor de la nube con una configuración deficiente. Por eso la directiva incorpora la seguridad de la cadena de suministro como uno de los pilares de las medidas de gestión de riesgos que exige. Dicho de otro modo: la norma parte de que el perímetro de seguridad de una empresa moderna incluye a sus proveedores, y responsabiliza a la entidad de gestionar ese riesgo aguas arriba.

A quién afecta y desde cuándo

NIS2 distingue dos grandes categorías de sujetos obligados: las entidades esenciales y las entidades importantes. La diferencia entre ambas no cambia demasiado las medidas de seguridad que deben aplicar, pero sí afecta al régimen de supervisión (más proactivo para las esenciales) y, en la práctica, a la intensidad del escrutinio regulatorio. La clasificación depende del sector de actividad y del tamaño de la organización, con umbrales basados en empleados, volumen de negocios y balance: como regla general, la directiva se aplica a medianas y grandes empresas (50 o más empleados, o más de 10 millones de euros de volumen de negocios y de balance) de esos sectores, con excepciones que incluyen a ciertas entidades cualquiera que sea su tamaño.

El abanico sectorial se amplía notablemente respecto a la NIS original. Entre los sectores de alta criticidad se incluyen, a grandes rasgos, energía, transporte, banca, infraestructuras de los mercados financieros, sanidad, agua potable y residuales, infraestructura digital, gestión de servicios TIC (business-to-business), administración pública y espacio. A ellos se suman otros sectores críticos como servicios postales, gestión de residuos, fabricación y distribución de productos químicos, producción y distribución de alimentos, fabricación de determinados productos (dispositivos médicos, electrónica, maquinaria, vehículos), proveedores digitales (mercados en línea, motores de búsqueda, plataformas de redes sociales) e investigación.

Aquí conviene una precaución importante para compras: aunque tu organización no esté directamente incluida en el ámbito de NIS2, es muy probable que uno o varios de tus clientes sí lo estén, y que te trasladen sus exigencias por vía contractual. Del mismo modo, muchos de tus proveedores tecnológicos pueden ser a su vez sujetos obligados. El efecto cascada es real: la norma se propaga por la cadena de suministro a través de los contratos, con independencia de la clasificación formal de cada empresa.

Sobre el calendario, hay que ser prudente. La directiva europea fijó como fecha de transposición por los Estados miembros octubre de 2024, pero España no la ha transpuesto aún: el Consejo de Ministros aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad el 14 de enero de 2025, y la ley no se ha publicado en el BOE a septiembre de 2026. Mientras tanto sigue aplicándose el Real Decreto-ley 12/2018, que transpuso la primera directiva NIS. Esto significa que el texto nacional definitivo (con sus umbrales concretos, autoridades competentes, plazos de registro y régimen sancionador exacto) no está aprobado todavía y puede cambiar durante la tramitación parlamentaria. Recomendación práctica: no des por buena una fecha o un detalle concreto sin verificar el estado real de la transposición española en el momento en que planifiques. Consulta el texto legal vigente, las guías de la autoridad competente y el criterio de tu asesoría jurídica. En un terreno regulatorio en movimiento, trabajar con información desactualizada es un riesgo en sí mismo.

Qué exige NIS2 sobre la seguridad de la cadena de suministro

Dentro del catálogo de medidas de gestión de riesgos que NIS2 impone a las entidades obligadas, la seguridad de la cadena de suministro aparece de forma expresa. La norma pide a las entidades que adopten medidas adecuadas y proporcionadas para gestionar los riesgos que se derivan de sus relaciones con proveedores y prestadores de servicios directos. Esto no es una recomendación genérica: es una obligación cuyo incumplimiento puede acarrear responsabilidad para la entidad.

En concreto, la gestión del riesgo de la cadena de suministro bajo NIS2 abarca varios frentes que compras debe conocer:

• Evaluación de la seguridad de cada proveedor directo. La entidad debe considerar las prácticas de ciberseguridad de sus proveedores y la calidad general de sus productos y servicios, no solo el precio o la funcionalidad.
• Análisis de las vulnerabilidades específicas de cada proveedor. No todos los proveedores presentan el mismo riesgo. Uno que gestiona sistemas críticos o que tiene acceso privilegiado a datos sensibles requiere un escrutinio distinto al de un proveedor de bajo impacto.
• Calidad del ciclo de desarrollo y prácticas de seguridad del proveedor. Especialmente relevante para proveedores de software: cómo desarrollan, cómo gestionan las vulnerabilidades, cómo parchean, qué garantías ofrecen sobre el ciclo de vida seguro del producto.
• Traslación de requisitos por contrato. La entidad debe asegurarse de que sus exigencias de seguridad se reflejan en los acuerdos con proveedores, de forma que sean exigibles y verificables.

Es importante subrayar el alcance. NIS2 habla de los proveedores y prestadores directos, pero la lógica del riesgo obliga a mirar más allá cuando un proveedor de segundo o tercer nivel puede tener impacto material (por ejemplo, un subcontratista que hospeda datos críticos). La proporcionalidad es el principio rector: no se trata de auditar a todos los proveedores con la misma intensidad, sino de priorizar en función de la criticidad del servicio y del acceso que cada proveedor tiene a tus sistemas y datos.

Qué controles pedir a los proveedores tecnológicos

Aquí es donde la teoría se convierte en trabajo concreto de compras. Traducir NIS2 a exigencias verificables sobre los proveedores implica actuar en tres momentos: la selección y homologación, el contrato y el seguimiento. Veamos qué controles concretos tienen sentido, entendiendo que deben calibrarse según la criticidad de cada proveedor.

En cuanto a gobernanza y organización de la seguridad, conviene pedir al proveedor evidencia de que la ciberseguridad está gestionada de forma seria: existencia de una política de seguridad de la información, responsable identificado, y preferiblemente certificaciones reconocidas como ISO/IEC 27001 o el Esquema Nacional de Seguridad cuando aplique. Una certificación no es garantía absoluta, pero es una señal razonable de madurez y ahorra parte del trabajo de verificación.

En cuanto a controles técnicos, las exigencias típicas incluyen cifrado de datos en tránsito y en reposo, gestión de accesos con principio de mínimo privilegio y autenticación multifactor, segmentación de red, gestión de vulnerabilidades y parcheo con plazos definidos, copias de seguridad y capacidad de recuperación, y registro y monitorización de eventos de seguridad. Para proveedores de software, añade prácticas de desarrollo seguro y gestión del ciclo de vida de las vulnerabilidades del producto.

En cuanto a la notificación de incidentes, este es probablemente el punto más importante desde el ángulo de NIS2. La directiva impone a las entidades obligadas plazos estrictos para notificar incidentes significativos a la autoridad (una alerta temprana en 24 horas, una notificación del incidente en 72 horas y un informe final en el plazo de un mes, según el art. 23). Pero una entidad no puede cumplir esos plazos si su proveedor tarda semanas en avisarle de que ha sufrido una brecha. Por eso es imprescindible que el contrato con el proveedor establezca obligaciones de notificación de incidentes hacia ti, con plazos que te permitan a su vez cumplir con tus propios plazos regulatorios. Un plazo de notificación del proveedor de 24 horas desde la detección es una referencia habitual y razonable para servicios críticos.

La siguiente tabla resume, a modo orientativo, controles y exigencias por tipo de proveedor según su nivel de criticidad. Sirve como punto de partida para diseñar tu propio esquema de homologación.

Ninguna de estas exigencias debe aplicarse de forma mecánica. El objetivo es la proporcionalidad: exigir mucho donde el riesgo es alto y aligerar donde es bajo, de modo que el proceso sea sostenible y no se convierta en un cuello de botella burocrático que ralentice todas las compras por igual.

Cláusulas contractuales: el instrumento clave

El contrato es la herramienta a través de la cual las exigencias de NIS2 se vuelven vinculantes y verificables. Sin cláusulas adecuadas, todo lo anterior queda en buenas intenciones. Las cláusulas de ciberseguridad que conviene incorporar (calibrando su intensidad según la criticidad del proveedor) suelen cubrir:

• Obligaciones de seguridad mínimas: compromiso del proveedor de mantener medidas técnicas y organizativas concretas, idealmente referenciadas a un anexo de seguridad o a un estándar reconocido.
• Notificación de incidentes: plazo, canal, contenido mínimo de la notificación y obligación de cooperación en la respuesta e investigación.
• Derecho de auditoría y verificación: posibilidad de auditar al proveedor directamente o mediante un tercero, o de exigir informes de auditoría externa (por ejemplo, SOC 2 o certificaciones vigentes).
• Gestión de la subcontratación: obligación de informar sobre subcontratistas relevantes, aprobación previa cuando proceda, y traslado en cascada de las obligaciones de seguridad a esos subcontratistas.
• Continuidad de negocio y recuperación: compromisos sobre disponibilidad, planes de continuidad y objetivos de recuperación.
• Ubicación y tratamiento de los datos: especialmente cuando hay implicaciones de protección de datos, que se solapan con las de ciberseguridad.
• Consecuencias del incumplimiento: penalizaciones, derecho de resolución y, cuando proceda, indemnización, para que las obligaciones tengan fuerza real.
• Cooperación regulatoria: obligación del proveedor de colaborar cuando la autoridad competente requiera información o cuando la entidad deba cumplir sus propios deberes de notificación.

Merece la pena coordinar este trabajo con quien ya redacta las cláusulas de sostenibilidad y cumplimiento en tus contratos, porque el enfoque metodológico es muy similar. Si quieres una referencia sobre cómo estructurar obligaciones exigibles y verificables en los contratos con proveedores, resulta útil revisar el planteamiento de las cláusulas ESG en contratos con proveedores: la lógica de traducir un requisito en obligación medible, con evidencias y consecuencias, es idéntica cuando pasamos del terreno ambiental y social al de la ciberseguridad.

Cómo gestionarlo desde compras: homologación y evaluación continua

NIS2 no se cumple con una acción puntual, sino con un proceso sostenido en el tiempo. Desde compras, la forma más eficaz de encajarlo es integrar la ciberseguridad en el ciclo de vida del proveedor, en lugar de tratarla como un trámite aislado. Esto implica actuar en varias fases.

En la homologación, incorpora criterios de ciberseguridad como parte del proceso de alta y evaluación de proveedores. Un cuestionario de seguridad proporcionado a la criticidad del servicio, la solicitud de certificaciones o evidencias, y una puntuación que influya en la decisión de homologación. La ciberseguridad deja de ser un anexo que nadie lee para convertirse en un criterio de selección con peso real. Es recomendable clasificar previamente a cada proveedor por su nivel de acceso e impacto, de manera que el esfuerzo de homologación se concentre donde importa.

En la contratación, asegúrate de que las cláusulas descritas en el apartado anterior se incorporan de forma sistemática, con plantillas y anexos de seguridad estandarizados que agilicen la negociación y garanticen que no se olvida ningún punto crítico.

En el seguimiento, establece una reevaluación periódica. La seguridad de un proveedor no es estática: cambia con el tiempo, con las incorporaciones de nuevos subcontratistas, con la aparición de nuevas vulnerabilidades y con la evolución de su propia madurez. Una evaluación continua, con frecuencia proporcional al riesgo, permite detectar degradaciones antes de que se conviertan en incidentes. Aquí ayuda mucho disponer de un sistema que centralice la información de proveedores, sus certificaciones, sus fechas de caducidad, sus incidentes y sus reevaluaciones, de modo que el seguimiento no dependa de hojas de cálculo dispersas.

En la respuesta a incidentes, ten previsto el flujo: cuando un proveedor notifica un incidente, ¿quién lo recibe en tu organización?, ¿cómo se escala?, ¿cómo se coordina con la obligación de notificar a la autoridad en plazo? Un proceso ensayado marca la diferencia entre cumplir los plazos regulatorios y quedarse fuera de ellos por pura descoordinación interna.

Un checklist práctico para compras

Para pasar de la teoría a la acción, este checklist resume las tareas fundamentales que el área de compras puede impulsar para alinear su gestión de proveedores con las exigencias de NIS2 en materia de cadena de suministro:

• Identificar y clasificar a los proveedores tecnológicos por su nivel de acceso a sistemas y datos, y por la criticidad del servicio que prestan.
• Incorporar un cuestionario de ciberseguridad proporcionado al proceso de homologación y alta de proveedores.
• Solicitar y registrar certificaciones (ISO 27001, ENS u otras) y sus fechas de vigencia.
• Incluir de forma sistemática cláusulas de seguridad, notificación de incidentes, auditoría y subcontratación en los contratos.
• Fijar plazos de notificación de incidentes que te permitan cumplir tus propios plazos regulatorios.
• Definir internamente el flujo de recepción y escalado de incidentes notificados por proveedores.
• Establecer una reevaluación periódica con frecuencia proporcional al riesgo de cada proveedor.
• Coordinar con IT/seguridad, legal y protección de datos para evitar duplicidades y lagunas.
• Mantener trazabilidad documental de todas las evaluaciones y evidencias, por si la autoridad la requiere.
• Verificar periódicamente el estado de la transposición española de NIS2 y ajustar el enfoque al marco vigente.

Sanciones: a grandes rasgos

NIS2 refuerza de forma notable el régimen sancionador respecto a la norma anterior, y ese es uno de los motivos por los que ha ganado tanta atención en los comités de dirección. La directiva prevé multas administrativas que pueden alcanzar importes significativos, con umbrales diferenciados para entidades esenciales e importantes, calculados como un porcentaje del volumen de negocio anual o como una cifra fija, aplicándose la mayor de ambas. La directiva fija los máximos mínimos que deben prever los Estados: al menos 10 millones de euros o el 2 % del volumen de negocios mundial anual para las entidades esenciales, y al menos 7 millones o el 1,4 % para las importantes, aplicándose la cifra mayor (art. 34). La ley española podrá concretarlos, pero no rebajarlos.

Más allá de las multas, hay dos elementos que conviene tener presentes. El primero es que NIS2 introduce la posibilidad de exigir responsabilidad a los órganos de dirección por el incumplimiento de las obligaciones de gestión de riesgos, incluida, solo para las entidades esenciales, la posibilidad de suspender temporalmente del ejercicio de funciones directivas a los responsables en casos graves (art. 32.5). Esto eleva la ciberseguridad de la cadena de suministro a la categoría de asunto de gobierno corporativo, no de mera operativa técnica. El segundo es que, además de la sanción económica, un incidente originado en un proveedor mal gestionado conlleva costes reputacionales, operativos y de relación con clientes que suelen superar con creces a la propia multa.

La conclusión para compras es clara: gestionar bien el riesgo cibernético de los proveedores no es solo evitar una sanción, es proteger la continuidad y la reputación de la organización. Y, como en cualquier régimen sancionador, poder demostrar diligencia (evidencias de que se evaluó, se contrató y se supervisó adecuadamente a los proveedores) es una de las mejores defensas.

NIS2 frente al riesgo ciber del mapa de riesgos de proveedores

Es fácil confundir el enfoque de NIS2 con la gestión general del riesgo de proveedores, pero conviene distinguirlos porque operan en planos diferentes y se complementan. En un mapa de riesgos de proveedores, el riesgo cibernético es uno más entre varios: conviven con el riesgo financiero, el operativo, el de dependencia o concentración, el geográfico, el reputacional, el ESG y el de cumplimiento. El mapa de riesgos es una herramienta de gestión que ayuda a priorizar y a tomar decisiones informadas, pero no impone por sí mismo obligaciones legales específicas; es un ejercicio de buen gobierno que cada organización calibra según su apetito de riesgo.

NIS2, en cambio, es una obligación regulatoria. No te deja elegir si gestionas o no el riesgo cibernético de tus proveedores directos: te obliga a hacerlo, con medidas adecuadas y proporcionadas, y con consecuencias legales si no lo haces. La ciberseguridad de la cadena de suministro deja de ser una casilla en un mapa para convertirse en un deber jurídico con supervisión, notificación de incidentes y régimen sancionador asociados.

La forma inteligente de encajar ambos es entender que NIS2 marca un suelo obligatorio dentro del capítulo de riesgo cibernético de tu mapa de riesgos. El mapa te da la visión panorámica y te ayuda a priorizar dónde poner recursos; NIS2 te dice qué es lo mínimo innegociable para los proveedores que caen bajo su ámbito. La siguiente tabla resume las diferencias.

En la práctica, lo eficiente es no gestionar estos dos planos por separado. Integra los criterios de NIS2 dentro de tu modelo de evaluación de riesgo de proveedores, de forma que la homologación, la contratación y el seguimiento cubran a la vez las buenas prácticas de gestión y las obligaciones legales. Así evitas duplicar procesos y garantizas que el cumplimiento normativo se apoya en una estructura que ya usas para tomar decisiones de compra.

Errores frecuentes al abordar NIS2 desde compras

Al implantar estas exigencias, hay patrones de error que se repiten y que conviene anticipar. El primero es tratar NIS2 como un asunto exclusivo de IT: si compras no se implica, las cláusulas nunca llegan a los contratos y las evaluaciones no se sistematizan. El segundo es la sobreexigencia indiscriminada, pedir a todos los proveedores lo mismo con independencia de su criticidad, lo que genera fricción, encarece y termina por desactivarse en la práctica. El tercero es confundir tener una certificación con estar seguro: una certificación es una señal, no una garantía, y no exime de la evaluación proporcionada del riesgo real.

Un cuarto error habitual es olvidar la cadena de segundo nivel: el proveedor directo puede estar bien gestionado pero apoyarse en un subcontratista crítico sin controles. Por eso las cláusulas de gestión de la subcontratación son tan importantes. Y un quinto error, muy relacionado con el contexto actual, es asumir un calendario o unos detalles de la transposición que luego cambian. En un marco regulatorio en movimiento como el español en 2026, la disciplina de verificar el estado vigente antes de tomar decisiones es parte del propio cumplimiento.

Preguntas frecuentes

¿NIS2 obliga directamente a mis proveedores o me obliga a mí a controlarlos?

Ambas cosas pueden darse a la vez, pero son planos distintos. Si tu organización es una entidad esencial o importante bajo NIS2, la norma te obliga a ti a gestionar el riesgo de tu cadena de suministro, lo que se traduce en controlar y exigir seguridad a tus proveedores por vía contractual. Si además tus proveedores son ellos mismos sujetos obligados, tendrán sus propias obligaciones directas. En la práctica, gran parte del efecto de NIS2 sobre los proveedores llega precisamente a través de las exigencias que sus clientes obligados les trasladan en los contratos.

¿Desde cuándo tengo que cumplir NIS2 en España?

La directiva europea fijó octubre de 2024 como plazo de transposición para los Estados miembros, pero en España, a septiembre de 2026, solo existe el anteproyecto de ley aprobado en enero de 2025, sin publicar en el BOE. Esto significa que las fechas, umbrales y detalles definitivos dependen del texto nacional, que conviene verificar en el momento de planificar. La recomendación práctica es no esperar a que se cierre todo el detalle para empezar a preparar la gestión de proveedores, porque los principios centrales de la norma ya son conocidos, pero sí confirmar el calendario y el alcance exacto con el texto vigente y con tu asesoría jurídica.

¿Qué debe incluir como mínimo la cláusula de notificación de incidentes con un proveedor?

Como mínimo debe fijar un plazo de notificación desde la detección del incidente (para servicios críticos, 24 horas es una referencia razonable), el canal y el destinatario en tu organización, el contenido mínimo de la comunicación inicial y la obligación de facilitar información adicional a medida que se investiga. Es clave que el plazo del proveedor te deje margen suficiente para cumplir tus propios plazos regulatorios de notificación a la autoridad. Conviene añadir también la obligación de cooperar en la respuesta, la contención y la investigación del incidente.

¿Tengo que auditar a todos mis proveedores tecnológicos?

No, y hacerlo sería insostenible. El principio de NIS2 es la proporcionalidad. Clasifica a tus proveedores por su nivel de acceso a sistemas y datos y por la criticidad del servicio, y reserva las auditorías o los test de intrusión periódicos para los proveedores críticos. Para los de impacto medio suele bastar con evidencias documentales o informes de auditoría externa, y para los de bajo impacto con una autoevaluación o cuestionario. El objetivo es concentrar el esfuerzo donde el riesgo lo justifica.

¿En qué se diferencia esto de lo que ya hago con el mapa de riesgos de proveedores?

El mapa de riesgos es una herramienta de gestión donde el riesgo cibernético convive con el financiero, el operativo, el ESG o el de dependencia, y su uso es voluntario y adaptable al apetito de riesgo de cada organización. NIS2 es una obligación regulatoria centrada en la ciberseguridad, con supervisión, notificación obligatoria de incidentes y sanciones. Lo más eficiente es integrar las exigencias de NIS2 dentro del capítulo cibernético de tu mapa de riesgos, de modo que NIS2 marque el suelo obligatorio y el mapa te dé la visión completa para priorizar recursos.

Si quieres homologar, contratar y supervisar a tus proveedores tecnológicos con criterios de ciberseguridad alineados con NIS2, y centralizar evaluaciones, cláusulas e incidentes en un único sistema, descubre cómo puede ayudarte la plataforma de itbid.