NIS2 y la cadena de suministro: lo que de verdad obliga a hacer con tus proveedores

El proveedor no sale en tu organigrama, no se sienta en tu comite de riesgos y probablemente tampoco aparece en las presentaciones del consejo. Aun asi, puede ser el punto exacto por el que entre el incidente que te obligue a notificar, contener, documentar y dar explicaciones. Ese es el problema real que NIS2 coloca sobre la mesa cuando habla de cadena de suministro y relaciones con proveedores.

La tentacion habitual consiste en leer el articulo 21 de la Directiva (UE) 2022/2555, ver la referencia a la seguridad de la cadena de suministro y concluir que basta con pedir cuatro politicas, una certificacion bonita y una clausula contractual reciclada. No basta. Pero conviene no exagerar lo que dice la norma. NIS2 impone una obligacion clara de gestionar riesgos de ciberseguridad en la cadena de suministro y en las relaciones con proveedores. Lo que no hace, al menos no en el propio articulo 21, es entregar una checklist universal cerrada con el mismo nivel de detalle para todos los terceros y todos los sectores.

Aqui esta el matiz que separa el cumplimiento serio del teatro documental. La directiva obliga. El detalle operativo lo tiene que construir cada entidad segun su exposicion, su dependencia tecnologica y el impacto potencial sobre los servicios que presta. Si esperabas que Bruselas hiciera por ti el inventario, la segmentacion, el modelo de seguimiento y los criterios de escalado, malas noticias: eso sigue siendo trabajo interno.

Lo que NIS2 si dice, y donde lo dice

El ancla juridica principal esta en el articulo 21 de NIS2, dedicado a las medidas de gestion de riesgos de ciberseguridad. El apartado 2 enumera los elementos minimos que deben cubrir esas medidas. Entre ellos, el articulo 21.2.d menciona expresamente la seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. Esa ultima expresion importa mucho: proveedores o prestadores de servicios directos.

No es una palabra metida por accidente. Delimita el punto de apoyo juridico inmediato de la directiva: la relacion de la entidad con aquellos terceros con los que contrata o de los que depende de forma directa para componentes, sistemas o servicios relevantes. A eso se suma el enfoque general del articulo 21.1, que exige medidas tecnicas, operativas y de organizacion apropiadas y proporcionadas para gestionar los riesgos que amenacen la seguridad de redes y sistemas de informacion.

Tambien conviene leer el considerando 79, porque aclara la logica del legislador: las entidades deben evaluar las vulnerabilidades especificas de cada proveedor y la calidad general de sus productos y practicas de ciberseguridad, incluidas sus practicas de desarrollo seguro. No convierte esa evaluacion en una lista uniforme para todo proveedor imaginable, pero deja poco espacio para la pasividad. El mensaje es bastante simple: si tu servicio depende de terceros, tu analisis de riesgo no puede fingir que esos terceros son una nota a pie de pagina.

El considerando 79 añade otro elemento relevante. Habla de un enfoque coordinado respecto de los riesgos de la cadena de suministro y reconoce que factores como el grado de dependencia respecto de proveedores, incluida la dependencia de proveedores con situaciones de monopolio, pueden aumentar la exposicion. Es decir, NIS2 no trata la cadena de suministro como un anexo administrativo. La trata como una superficie de riesgo que puede comprometer la continuidad y la seguridad del servicio.

Lo que la directiva no te regala: una lista cerrada para terceros

Conviene pinchar una burbuja bastante extendida en departamentos de compliance y en no pocas presentaciones de PowerPoint. NIS2 no contiene, en el articulo 21, un paquete textual y autosuficiente que diga: para proveedores criticos debes hacer evaluacion previa en estos terminos exactos, imponer estas clausulas concretas, exigir estas evidencias, revisar con esta frecuencia y desplegar estos controles tecnicos determinados. La norma va por principios y categorias de medidas. El diseño fino depende del riesgo.

Eso no rebaja la exigencia. La complica, que no es lo mismo. Porque una obligacion abierta y proporcional obliga a pensar. Y pensar, en compliance, suele ser bastante menos comodo que copiar una plantilla.

Por eso hay dos errores frecuentes. El primero es leer NIS2 como si fuera una invitacion a “tener algo” sobre proveedores. El segundo es vender como mandato literal de la directiva lo que en realidad es una traduccion operativa razonable, pero propia, de sus principios. Entre ambos extremos esta la posicion util: distinguir con honestidad entre lo que exige el texto y lo que una entidad prudente deberia construir para poder defender que su gestion del riesgo es apropiada y proporcionada.

Cadena de suministro: la obligacion existe, pero la arquitectura la pones tu

Si uno se queda solo en el titular, podria pensar que la cadena de suministro es un subapartado mas dentro de NIS2. No lo es. Funciona como una prueba de madurez. Resulta relativamente facil redactar una politica general de seguridad. Resulta bastante mas dificil demostrar que sabes de que terceros dependes, que entiendes para que sirven, que has valorado su impacto en tus redes y sistemas, y que has integrado ese analisis en decisiones de compra, continuidad, acceso y respuesta a incidentes.

El articulo 21.2 no se agota en la letra d. Incluye, entre otras materias, politicas de analisis de riesgos y seguridad de sistemas de informacion (art. 21.2.a), gestion de incidentes (art. 21.2.b), continuidad de las actividades y gestion de crisis (art. 21.2.c), seguridad en la adquisicion, desarrollo y mantenimiento de redes y sistemas, incluida la gestion y divulgacion de vulnerabilidades (art. 21.2.e), politicas y procedimientos para evaluar la eficacia de las medidas de gestion de riesgos (art. 21.2.f), practicas basicas de ciberhigiene y formacion (art. 21.2.g), politicas y procedimientos relativos al uso de criptografia y, cuando proceda, cifrado (art. 21.2.h), seguridad de recursos humanos, control de acceso y gestion de activos (art. 21.2.i), y el uso de autenticacion multifactor o soluciones de autenticacion continua, comunicaciones seguras y sistemas de comunicaciones de emergencia cuando proceda (art. 21.2.j).

La lectura correcta no es que cada una de esas letras se aplique de forma aislada. Es que la relacion con proveedores atraviesa varias de ellas. Si un tercero opera, mantiene, desarrolla, aloja o conecta sistemas que soportan tu servicio, la cadena de suministro ya no se limita a la compra. Toca incidentes, continuidad, accesos, vulnerabilidades, autenticacion y activos. La directiva no lo empaqueta en una frase unica. Pero la estructura del articulo 21 obliga a verlo como un problema transversal.

“El proveedor lo lleva”: una defensa floja, aunque la directiva no lo formule asi

Hay una frase que aparece demasiado en reuniones internas: “eso lo gestiona el proveedor”. Puede ser cierta desde un punto de vista operativo. Juridicamente, bajo NIS2, no resuelve gran cosa por si sola. Lo que la directiva exige a las entidades esenciales e importantes es que adopten medidas apropiadas y proporcionadas para gestionar los riesgos de ciberseguridad que afecten a las redes y sistemas que utilizan para sus operaciones o para la prestacion de sus servicios, como indica el articulo 21.1.

Traducido a castellano no regulatorio: externalizar una funcion o consumir un servicio no elimina la necesidad de valorar el riesgo que esa dependencia introduce en tus operaciones. La directiva no necesita decir literalmente que “el riesgo sigue siendo tuyo” para producir ese efecto practico. Le basta con imponer a la entidad la obligacion de gestionar esos riesgos y con incluir expresamente las relaciones con proveedores directos dentro del perimetro de las medidas minimas.

La diferencia importa porque evita dos lecturas igual de malas. La primera, muy comun, es pensar que una buena SLA equivale a una buena postura de ciberseguridad. No equivale. La segunda es cargar sobre NIS2 afirmaciones demasiado rotundas que el texto no formula con esas palabras. Mejor decirlo con precision: la directiva coloca sobre la entidad obligada el deber de adoptar medidas de gestion de riesgos, incluso cuando parte de la tecnologia o del servicio dependa de terceros. Eso es mas juridicamente limpio y, de paso, mas util.

El punto delicado: proveedores directos si, subproveedores no de forma expresa

La referencia del articulo 21.2.d a los proveedores o prestadores de servicios directos tiene una consecuencia practica inmediata: la base textual mas clara de NIS2 se concentra en esa primera capa de la cadena contractual. Esto no significa que los subproveedores sean irrelevantes. Significa algo mas incomodo: que la obligacion expresa de la directiva, tal como esta redactada ahi, no desarrolla con el mismo detalle la visibilidad exigible sobre capas posteriores.

En la practica, eso obliga a hilar fino. Una entidad puede razonablemente concluir, como parte de su analisis de riesgos bajo el articulo 21.1 y de su aproximacion a la cadena de suministro bajo el articulo 21.2.d, que necesita conocer dependencias ulteriores cuando estas afecten a la seguridad, disponibilidad o integridad del servicio. Lo que no conviene hacer es presentar esa expectativa como si la directiva contuviera una obligacion autonoma y expresa, formulada en esos terminos, de mapear subproveedores criticos en todos los casos.

La distincion no es academica. Cambia la forma de redactar politicas, contratos y reportes internos. Si vendes al consejo o al regulador una obligacion legal que no aparece asi en el texto, te expones a dos problemas: mala interpretacion normativa y mala priorizacion operativa. Si, en cambio, explicas que cierta visibilidad adicional sobre dependencias ulteriores se justifica por analisis de riesgo, continuidad o exposicion de acceso, la posicion es mucho mas solida.

Dicho sin rodeos: NIS2 te da un suelo claro respecto del proveedor directo. Sobre capas posteriores, la entidad tendra que justificar por que necesita determinadas salvaguardas o informacion adicional a la luz de su riesgo real. Y eso, bien trabajado, puede ser mas defendible que una checklist sobreactuada.

Que deberia mirar una entidad sin fingir que todo viene dictado por NIS2

La pregunta util no es “que lista cerrada impone la directiva para todo proveedor critico”, porque esa lista, en esos terminos, no esta en el articulo 21. La pregunta correcta es otra: que elementos permiten demostrar que la entidad ha tratado la relacion con el proveedor como una cuestion de riesgo de ciberseguridad y no solo de compras o de legal.

A partir del texto de NIS2, la respuesta debe construirse conectando la relacion con terceros con las categorias de medidas del articulo 21. Eso apunta, como minimo, a varias capas de trabajo.

• Analisis de riesgo previo y continuo: no porque el articulo 21.2.d use esas palabras exactas como un paquete, sino porque el articulo 21.1 exige medidas apropiadas y proporcionadas basadas en riesgos, y el articulo 21.2.a obliga a contar con politicas de analisis de riesgos y seguridad de sistemas de informacion.
• Tratamiento de accesos y activos: si el proveedor administra sistemas, procesa informacion o accede a entornos sensibles, entran en juego el articulo 21.2.i sobre control de acceso y gestion de activos, y el articulo 21.2.j cuando proceda sobre autenticacion multifactor, comunicaciones seguras y mecanismos relacionados.
• Continuidad e incidente: si una caida, compromiso o indisponibilidad del proveedor puede afectar al servicio, el articulo 21.2.b sobre gestion de incidentes y el 21.2.c sobre continuidad y gestion de crisis dejan de ser asuntos internos y pasan a depender tambien de como esta organizada esa relacion externa.
• Adquisicion y mantenimiento: cuando el proveedor suministra tecnologia, software, integracion o mantenimiento, el articulo 21.2.e obliga a mirar seguridad en adquisicion, desarrollo y mantenimiento, incluida la gestion y divulgacion de vulnerabilidades.
• Revision de eficacia: no basta con firmar controles sobre el papel. El articulo 21.2.f exige politicas y procedimientos para evaluar la eficacia de las medidas de gestion de riesgos.

Fijate en la diferencia. No estoy diciendo que NIS2 imponga literalmente una lista cerrada de “evidencia de controles, derecho de auditoria, restricciones de subcontratacion, MFA, logs, pruebas de continuidad y plan de salida” para todos los proveedores relevantes. Eso seria ir mas alla del texto. Lo que si puede afirmarse con respaldo es que, para poder cumplir de forma defendible con las categorias del articulo 21, muchas entidades necesitaran traducir esas categorias en requisitos contractuales, verificaciones o mecanismos de gobierno adaptados al tipo de servicio y al riesgo de la relacion.

Ese paso es de la entidad. Y ahi es donde se separa la interpretacion juridica seria del corta-y-pega de compliance.

El contrato no sustituye al control, pero tampoco es decorado

Como el articulo 21.2.d habla de las relaciones entre la entidad y sus proveedores directos, el contrato se convierte en una pieza inevitable. No porque NIS2 detalle una clausula modelo. Simplemente porque, sin articulacion contractual minima, muchas de las expectativas operativas derivadas del articulo 21 quedan en el aire.

Piensa en algo muy basico. Si necesitas gestionar incidentes conforme al articulo 21.2.b, tendras que saber como y cuando te informa el proveedor de eventos que afecten a tus redes o sistemas. Si debes asegurar continuidad y gestion de crisis bajo el articulo 21.2.c, interesara entender dependencias, tiempos de recuperacion o puntos de fallo. Si la seguridad en adquisicion, desarrollo y mantenimiento forma parte del articulo 21.2.e, no da exactamente igual como se corrigen vulnerabilidades, como se comunican y como se despliegan cambios en componentes que tu entidad utiliza. Si el control de accesos entra por el articulo 21.2.i y la autenticacion multifactor cuando proceda por el 21.2.j, la manera en que el proveedor accede o administra entornos conectados deja de ser un detalle tecnico menor.

La directiva no dicta el clausulado. Pero empuja a que el contrato deje de ser un documento de procurement con una pagina final de “seguridad y privacidad” metida a ultima hora. Si el tercero es relevante para la seguridad del servicio, la relacion juridica tiene que soportar, de algun modo verificable, lo que la entidad necesita para cumplir con sus medidas de gestion de riesgos.

Y no, pedir una certificacion y archivar el PDF no convierte automaticamente ese contrato en robusto. Ojala fuera tan barato.

Evaluar vulnerabilidades del proveedor: lo que dice el considerando 79 y lo que implica

Uno de los pasajes mas utiles de NIS2 para salir del formalismo esta en el considerando 79. Ahi se dice que las entidades deben evaluar las vulnerabilidades especificas de cada proveedor y prestador de servicios directo y la calidad general de sus productos y practicas de ciberseguridad. Tambien menciona sus practicas de desarrollo seguro. Este considerando no crea, por si solo, una lista cerrada de pruebas ni un procedimiento uniforme. Pero corrige una lectura demasiado superficial del articulo 21.2.d.

La cadena de suministro no se cubre solo sabiendo quien es el proveedor. Tampoco solo preguntando si tiene una politica de seguridad. La referencia a vulnerabilidades especificas y a la calidad de productos y practicas apunta a una evaluacion material. Es decir, a una mirada que distingue entre proveedores segun el tipo de tecnologia, el nivel de acceso, la criticidad funcional, la dependencia operativa y la superficie de ataque que introducen.

Eso tiene consecuencias practicas inmediatas.

Primero, el mismo cuestionario para todos suele servir de poco. Un despacho que presta un servicio acotado y sin acceso tecnologico no plantea el mismo riesgo que un proveedor que administra identidades, integra sistemas industriales, mantiene software expuesto o aloja componentes esenciales. Segundo, la evaluacion no deberia reducirse a una fotografia de onboarding. Si el articulo 21.2.f exige evaluar la eficacia de las medidas de gestion de riesgos, la relacion con proveedores no puede quedarse congelada en el momento de la firma. Tercero, cuando el proveedor forma parte del ciclo de desarrollo, mantenimiento o correccion de vulnerabilidades, la frontera entre “riesgo de terceros” y “seguridad del sistema propio” se vuelve mucho mas porosa de lo que algunas organizaciones quieren admitir.

Lo que cambia en la gobernanza interna

NIS2 no es solo un texto para el equipo tecnico. El articulo 20 aprieta a los organos de direccion: deben aprobar las medidas de gestion de riesgos de ciberseguridad, supervisar su aplicacion y pueden ser responsables de infracciones por parte de la entidad. Ademas, el articulo 20.2 exige que los miembros de los organos de direccion sigan formacion para identificar riesgos y evaluar practicas de gestion de riesgos de ciberseguridad.

Esto altera la conversacion sobre proveedores. Ya no basta con que compras negocie precio, legal revise responsabilidad y tecnologia valide la integracion. Si la cadena de suministro entra en el articulo 21.2.d y el organo de direccion debe aprobar y supervisar las medidas del articulo 20, el modelo de terceros deja de ser un asunto lateral. Se convierte en una cuestion de gobierno.

La pregunta incomoda para muchas entidades es sencilla: puede el consejo explicar, con cierto detalle, que criterios usa la organizacion para distinguir entre un proveedor ordinario y uno cuya falla o compromiso alteraria la seguridad del servicio? Si la respuesta es no, el problema no es solo documental. Es de gobernanza.

Lo mismo vale para la rendicion de cuentas interna. Si una entidad no puede mostrar quien decide la criticidad del proveedor, quien valida el nivel de exigencia, quien asume excepciones y quien revisa la eficacia del modelo, estara vendiendo madurez donde en realidad hay dispersion. Y NIS2, con su mezcla de obligaciones de gestion de riesgos y responsabilidad del organo de direccion, castiga especialmente bien esa clase de ilusion administrativa.

Notificacion de incidentes: cuando el tercero desencadena tus plazos

El riesgo de terceros bajo NIS2 no termina en la fase de evaluacion. Tambien se proyecta sobre las obligaciones de notificacion de incidentes del articulo 23. Las entidades esenciales e importantes deben comunicar sin demora indebida incidentes significativos, con una alerta temprana en el plazo de 24 horas desde que tengan conocimiento de ellos, una notificacion de incidente en 72 horas y un informe final en el plazo de un mes, segun el esquema del articulo 23.4.

Que tiene que ver esto con proveedores? Todo. Si el incidente nace en un tercero o se detecta a traves de un tercero, la entidad necesita saber con rapidez que ha pasado, que activos o servicios estan afectados, si existe compromiso de integridad, confidencialidad o disponibilidad, y que medidas de contencion o recuperacion se estan aplicando. NIS2 no dice que todo proveedor deba asumir un formato de notificacion concreto en tu contrato. Pero si tus plazos legales dependen de informacion que otro controla, confiar en la buena voluntad del proveedor no es una estrategia; es una apuesta.

Esto enlaza con un fallo muy habitual. Muchas organizaciones trabajan el reporting regulatorio como si empezara el dia del incidente. Error. Empieza mucho antes, en el diseño de la relacion con terceros, en la identificacion de contactos, en los circuitos de escalado, en la clasificacion de activos y en la capacidad de obtener informacion util antes de que el reloj legal empiece a correr. El articulo 23 no menciona procurement, pero procurement deberia estar tomandolo muy en serio.

Proporcionalidad no significa blandura

Una de las salidas faciles para minimizar el esfuerzo es agarrarse a la palabra “proporcionadas” del articulo 21.1. Como la directiva habla de medidas apropiadas y proporcionadas, algunos leen ahi un salvoconducto para dejar casi todo en politicas generales. Mala lectura.

La proporcionalidad en NIS2 se refiere, entre otros factores, al grado de exposicion de la entidad a riesgos, su tamaño, la probabilidad de ocurrencia de incidentes y su gravedad, incluido su impacto social y economico. No es una invitacion a bajar la guardia, sino a ajustar el modelo al riesgo real. Una entidad con alta dependencia tecnologica, interconexiones complejas o servicios esenciales soportados por terceros no puede esconderse detras de la proporcionalidad para justificar un tratamiento superficial de la cadena de suministro.

De hecho, la proporcionalidad bien entendida suele producir un efecto contrario al que algunos esperan: cuanto mayor es la dependencia de un proveedor para la prestacion segura del servicio, mas dificil resulta defender un enfoque ligero. La directiva no te da una formula matematica. Te deja algo peor: la necesidad de argumentar por que tus medidas son suficientes para tu perfil de riesgo concreto.

Y esa argumentacion, si llega una inspeccion o un incidente serio, no se gana con adjetivos. Se gana con evidencias, decisiones trazables y una logica de control que tenga sentido cuando se aplica al mundo real.

Lo que muchas empresas siguen haciendo mal

Despues de leer decenas de programas de terceros, el patron se repite con una constancia casi artistica. Se clasifica al proveedor por gasto, no por impacto operativo. Se centraliza la due diligence en compras. Se mezclan privacidad, seguridad, continuidad y cumplimiento en un formulario unico que sirve tanto para un servicio trivial como para una dependencia estructural. Se presume que una certificacion resuelve preguntas que en realidad ni siquiera formula. Y se considera “completado” el riesgo de terceros cuando el expediente tiene suficientes anexos para impresionar a auditoria interna.

NIS2 no prohíbe esas malas practicas con una frase literal, pero las deja bastante mal paradas. Si el articulo 21.2.d obliga a cubrir la seguridad de la cadena de suministro y las relaciones con proveedores directos, y el considerando 79 pide evaluar vulnerabilidades especificas y la calidad de productos y practicas de ciberseguridad, tratar a todos los terceros con una plantilla indiferenciada empieza a parecer menos una metodologia y mas una renuncia.

El otro error serio es separar por completo el mundo del tercero del mapa de activos y servicios. Si no puedes enlazar un proveedor con sistemas concretos, funciones concretas, privilegios concretos o dependencias concretas, tu capacidad de responder a un incidente o de valorar impacto quedara dañada justo cuando mas la necesites. NIS2 no resuelve ese problema por ti. Solo hace mas visible lo caro que puede salir mantenerlo.

Sin comparaciones comodas con otros marcos

Aqui conviene ser disciplinado. Muchas organizaciones operan con varios marcos a la vez y sienten la tentacion de interpretar NIS2 a traves de regulaciones o estandares mas detallados sobre terceros. Esa comparacion puede ser util internamente, pero no hace falta invocarla para entender el texto de NIS2, y menos aun si no vas a respaldarla con la fuente correspondiente.

Para este analisis basta una conclusion mas sobria y mejor anclada: NIS2 formula una obligacion clara de gestionar el riesgo de ciberseguridad en la cadena de suministro y en las relaciones con proveedores directos, pero deja amplio margen a la entidad para concretar los controles, criterios y mecanismos de supervision que necesita en funcion de su riesgo. Ese margen no es una licencia para la improvisacion. Es una responsabilidad de diseño.

Lo mismo ocurre con certificaciones, sellos o marcos de buenas practicas. Pueden formar parte de la evaluacion de un proveedor, pero el texto que hemos citado de NIS2 no convierte una certificacion concreta en pasaporte de suficiencia. La directiva habla de vulnerabilidades especificas, calidad de productos y practicas de ciberseguridad, y de medidas apropiadas y proporcionadas. Eso obliga a mirar mas alla de la pegatina.

Como defender un enfoque serio ante auditoria, consejo o regulador

Si tu entidad quiere estar en una posicion defendible bajo NIS2, la clave no esta en afirmar que la directiva ordena una lista exacta que en realidad no ordena. La clave esta en demostrar coherencia entre riesgo, dependencia y medida aplicada.

Eso exige, como minimo, cinco cosas muy concretas, todas ellas inferibles del tejido del articulo 21 y de la gobernanza del articulo 20.

• Inventario util: no una base de datos decorativa de proveedores, sino un mapa que permita saber que terceros se conectan con que activos, procesos o servicios.
• Criterios de criticidad: documentados y aplicados de forma consistente, de modo que pueda justificarse por que ciertas relaciones exigen mas escrutinio que otras.
• Relacion entre clasificacion y medida: si dos proveedores reciben distinto tratamiento, la organizacion debe poder explicar por que, conectando esa diferencia con acceso, dependencia, impacto o exposicion.
• Mecanismos de seguimiento: el articulo 21.2.f no casa bien con un modelo en el que toda la evaluacion se hace una sola vez al inicio y nunca se revisa.
• Escalado a gobierno: si la cadena de suministro es relevante para la seguridad del servicio, el organo de direccion debe recibir una vision intelligible del riesgo, las excepciones y los puntos de concentracion o dependencia.

Fijate en la logica: no se trata de recitar un catecismo de terceros. Se trata de demostrar que la gestion de proveedores forma parte del sistema de gestion de riesgos de ciberseguridad y no es un proceso satelite gestionado con inercias de compras.

Ese es, a mi juicio, el nucleo interpretativo mas solido de NIS2 en esta materia. Y tambien el que mas duele, porque obliga a coordinar funciones que normalmente viven en silos y a abandonar el consuelo burocratico de “tenemos una politica”.

La conclusion incomoda

La cadena de suministro se ha convertido en el lugar favorito del regulador para recordarle a las empresas algo bastante poco romantico: tus dependencias tambien forman parte de tu superficie de riesgo. NIS2 no te ofrece una checklist cerrada para cada proveedor relevante, ni formula todas las consecuencias operativas con el detalle que algunos querrian. Lo que si hace, de forma inequívoca, es meter la seguridad de la cadena de suministro y las relaciones con proveedores directos dentro del corazon de las medidas de gestion de riesgos de ciberseguridad, en el articulo 21.2.d.

Ese detalle basta para desmontar varias excusas clasicas. No puedes tratar el riesgo de terceros como una derivada contractual marginal. No puedes asumir que el proveedor “ya se ocupa”. No puedes separar adquisicion, continuidad, incidentes, accesos y vulnerabilidades como si fueran compartimentos estancos. Y tampoco deberias adornar la directiva con obligaciones textuales que no aparecen asi en la fuente, porque una buena estrategia regulatoria empieza por interpretar bien el alcance real de la norma.

La pregunta final no es si NIS2 te obliga a vigilar a tus proveedores. Eso ya esta bastante claro. La pregunta util es otra: puedes demostrar, con trazabilidad y criterio, que distingues entre terceros anodinos y terceros cuya debilidad podria comprometer la seguridad de tus operaciones o de tus servicios? Si no puedes, el problema no es semantico. Es estructural. Y cuanto mas dependas de otros para funcionar, menos margen te deja NIS2 para fingir que no lo ves.