NIS2
Seguridad de la cadena de suministro en NIS2: obligaciones y due diligence que resisten una auditoría
22 min lectura
Imagen generada por IALa mayoría de los incidentes de terceros no empiezan con una intrusión cinematográfica en el proveedor más crítico. Empiezan con algo menos espectacular y bastante más frecuente: una cuenta con privilegios excesivos, un componente sin parchear, una dependencia de software que nadie inventarió o un contrato que habla de seguridad con la precisión de un horóscopo.
La Directiva NIS2 obliga a cambiar ese enfoque. Su artículo 21.2.d incluye expresamente la seguridad de la cadena de suministro entre las medidas de gestión del riesgo de ciberseguridad. Para las entidades esenciales e importantes, la cuestión ya no es si existe un proveedor TIC crítico, sino si la organización puede explicar quién tiene acceso a sus sistemas, qué riesgo introduce cada tercero, qué controles exige y qué ocurre cuando el proveedor incumple.
La diferencia parece semántica. No lo es. Una certificación ISO 27001 puede ser una pieza de evidencia; no es una dispensa de responsabilidad. Un cuestionario anual puede aportar información; no sustituye la monitorización. Y una cláusula contractual que permite auditar al proveedor no sirve de mucho si nadie audita, nadie revisa los hallazgos y nadie tiene autoridad para bloquear una renovación.
Este es el núcleo del problema para un CISO europeo en 2026: NIS2 no permite externalizar el riesgo junto con el servicio. La responsabilidad por la seguridad de la entidad sigue dentro de la entidad, aunque el servidor, el código, el centro de operaciones o la mesa de soporte estén fuera.
Qué exige realmente el artículo 21 de NIS2
El artículo 21.1 exige que las entidades esenciales e importantes adopten medidas técnicas, operativas y organizativas proporcionadas para gestionar los riesgos que amenacen la seguridad de las redes y sistemas de información utilizados en sus operaciones o en la prestación de sus servicios. La obligación no se limita a prevenir ataques: también cubre la gestión de incidentes, la continuidad, la recuperación ante desastres, la gestión de crisis y la evaluación de la eficacia de las medidas.
La cadena de suministro aparece de forma concreta en el artículo 21.2.d. La entidad debe abordar la seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. El texto añade que deben tenerse en cuenta las vulnerabilidades específicas de cada proveedor y la calidad general de los productos y prácticas de ciberseguridad de sus proveedores, incluidos sus procedimientos de desarrollo seguro.
Hay dos consecuencias prácticas que suelen perderse en los resúmenes legislativos.
La primera: el análisis no termina en el proveedor que firma el contrato. NIS2 habla de la cadena de suministro y obliga a mirar, al menos en la medida razonable y proporcional, a las dependencias que sostienen el servicio. Un proveedor de software puede subcontratar el alojamiento; el proveedor de alojamiento puede depender de una plataforma de identidad; el integrador puede utilizar una herramienta de acceso remoto de un cuarto actor. No es realista convertir cada relación comercial en una investigación de inteligencia nacional, pero sí lo es exigir visibilidad sobre las dependencias que pueden interrumpir el servicio o acceder a información sensible.
La segunda: el riesgo debe evaluarse por proveedor y por servicio, no por etiqueta corporativa. Una empresa de limpieza sin acceso lógico no merece el mismo tratamiento que un proveedor de administración de identidades. Tampoco un SaaS de recursos humanos debe clasificarse igual que una plataforma que procesa transacciones o mantiene las claves de firma. El catálogo de proveedores es una lista; el riesgo nace de los accesos, las dependencias y el impacto operativo.
El artículo 21.2 incluye otras medidas conectadas directamente con la cadena de suministro. El apartado a exige políticas de análisis de riesgos y seguridad de los sistemas de información. El b aborda la gestión de incidentes. El c se refiere a la continuidad de negocio y la gestión de crisis. El e contempla la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, incluida la gestión y divulgación de vulnerabilidades. El f trata de evaluar la eficacia de las medidas de gestión del riesgo. Y el h incluye el uso de criptografía y, cuando proceda, cifrado.
Leído como un conjunto, el artículo 21 no pide una carpeta de contratos. Pide un sistema de control que conecte compras, arquitectura, seguridad, continuidad, privacidad, legal y dirección.
La due diligence no es un cuestionario: es una decisión de riesgo
El error más extendido consiste en enviar a todos los proveedores el mismo cuestionario de 300 preguntas y llamar al resultado due diligence. El método tiene dos defectos: consume tiempo donde no hace falta y obtiene respuestas poco fiables donde sí hace falta. Un proveedor pequeño puede contestar “sí” a todo porque no entiende la pregunta; un proveedor global puede entregar un paquete de documentos impecable que no responde a la configuración concreta contratada.
Una evaluación útil debe producir una decisión: aprobar, aprobar con condiciones, exigir remediación antes de contratar, limitar el alcance del servicio o rechazar la relación. Para llegar ahí, conviene separar cuatro dimensiones.
1. Criticidad del servicio
La primera pregunta no es “¿es un proveedor TIC?”. Es “¿qué sucede si este servicio deja de funcionar durante cuatro horas, veinticuatro horas o una semana?”. La respuesta debe traducirse a impacto operativo, regulatorio, financiero y sobre terceros.
Un proveedor que aloja un portal corporativo público puede tener una criticidad moderada. Un proveedor que gestiona autenticación multifactor, pagos, compensación, expedientes clínicos, comunicaciones de emergencia o copias de seguridad inmutables puede ser crítico aunque su contrato anual sea relativamente pequeño. El precio no es una métrica de resiliencia.
La clasificación debe incluir el objetivo de tiempo de recuperación —RTO—, el objetivo de punto de recuperación —RPO—, la tolerancia máxima a la indisponibilidad, la sensibilidad de los datos y la posibilidad de sustituir el servicio. Si el proveedor no puede ser reemplazado en semanas o meses, esa dependencia debe quedar visible para el comité de riesgos, no enterrada en procurement.
2. Acceso y concentración
El segundo eje es el acceso. Hay una diferencia decisiva entre un proveedor que recibe ficheros una vez al mes y otro que mantiene acceso privilegiado permanente a la red, a la consola cloud o a las identidades de administración.
La evaluación debería registrar, como mínimo, si existe acceso humano o máquina, si es privilegiado, desde qué ubicaciones, con qué autenticación, durante cuánto tiempo, con qué segmentación y quién revisa los permisos. También debe identificar la concentración: varias unidades de negocio pueden depender del mismo proveedor sin saberlo; dos proveedores aparentemente distintos pueden utilizar el mismo hyperscaler o la misma plataforma de gestión remota.
El artículo 21.2.a no prescribe una matriz concreta, pero obliga a que el análisis de riesgos sea operativo. Una matriz que asigna “riesgo alto” sin vincularlo a controles, propietario y fecha de revisión es decoración administrativa.
3. Capacidad de seguridad verificable
La tercera dimensión es la madurez real. ISO/IEC 27001 puede demostrar que existe un sistema de gestión certificado dentro de un alcance determinado. No demuestra automáticamente que el servicio contratado esté incluido en ese alcance, que el proveedor aplique MFA a todos los administradores, que sus registros se conserven durante el periodo necesario o que sus subcontratistas mantengan controles equivalentes.
La evidencia debe adecuarse al riesgo. Para un servicio de bajo impacto puede bastar una declaración de controles, una política de seguridad y la confirmación de requisitos básicos. Para un proveedor crítico, el expediente debería examinar, según proceda:
- el alcance exacto de ISO/IEC 27001 o del informe SOC 2, con fecha y entidad certificadora o auditora;
- la gestión de vulnerabilidades, incluidos los plazos de corrección por severidad y la exposición a vulnerabilidades conocidas;
- la autenticación multifactor, el acceso privilegiado y la segregación de entornos;
- las pruebas de restauración de copias de seguridad, continuidad y recuperación;
- la notificación de incidentes y el acceso a información suficiente para que el cliente cumpla sus propios plazos regulatorios;
- la gestión de subcontratistas, cambios relevantes y dependencias de software de terceros;
- la seguridad del desarrollo, revisión de código, análisis de dependencias y divulgación coordinada de vulnerabilidades.
La evidencia tiene que ser contemporánea. Un certificado emitido hace tres años no prueba el estado actual de un servicio cloud que ha cambiado seis veces desde entonces.
4. Capacidad de respuesta y salida
Un proveedor puede tener controles razonables y aun así ser inaceptable si no coopera durante una crisis. La due diligence debe probar cómo se escalaría un incidente a las dos de la madrugada, qué información se recibiría, quién puede aislar un sistema y cuánto tardaría el proveedor en preservar evidencias.
La salida merece el mismo nivel de atención. El contrato debe contemplar devolución o destrucción de datos, asistencia de migración, formatos exportables, revocación de accesos, eliminación de claves, conservación de evidencias y continuidad durante la transición. Un servicio del que nadie puede salir no es resiliente; es una dependencia con facturación mensual.
Qué debe contener el contrato con el proveedor
El artículo 21 no funciona sin contratos que conviertan las expectativas de seguridad en obligaciones comprobables. La redacción debe ser suficientemente precisa para permitir una auditoría y suficientemente flexible para cubrir cambios tecnológicos. “El proveedor mantendrá medidas de seguridad adecuadas” rara vez supera la primera conversación seria con un auditor.
Para servicios relevantes, el acuerdo debería definir al menos:
- el servicio, los activos, los entornos y los datos cubiertos;
- los controles mínimos exigibles, incluidos MFA, gestión de privilegios, cifrado, registro, segmentación y parcheado;
- la clasificación de incidentes y los canales de notificación;
- los tiempos de aviso, actualización, contención y entrega de información;
- los derechos de auditoría, las evidencias aceptables y el tratamiento de deficiencias;
- la obligación de comunicar cambios materiales en arquitectura, ubicación de datos, subcontratistas o controles;
- las condiciones para utilizar subcontratistas y la responsabilidad del proveedor sobre ellos;
- los requisitos de continuidad, pruebas y recuperación;
- la asistencia en investigaciones, requerimientos de autoridades y análisis forense;
- la terminación, reversibilidad, portabilidad y eliminación segura de información.
La notificación de incidentes merece una precisión especial. NIS2 artículo 23 establece obligaciones de comunicación de incidentes significativos a los equipos de respuesta a incidentes de seguridad informática —CSIRT— o a la autoridad competente. La entidad afectada debe poder cumplir los plazos regulatorios aunque el proveedor todavía esté “investigando internamente”. Por eso el contrato debe obligar a una notificación temprana de hechos potencialmente relevantes, no solo de incidentes ya confirmados como significativos.
El artículo 23 contempla una alerta temprana en un plazo de 24 horas desde que la entidad tenga conocimiento del incidente significativo y una notificación del incidente en un plazo de 72 horas, seguida de un informe final, salvo que las circunstancias aplicables indiquen otra cosa. El proveedor no tiene que presentar necesariamente la notificación regulatoria en nombre del cliente, pero sí debe entregar la información que permita hacerlo sin esperar a que su comité jurídico cierre el expediente.
En los servicios cloud y gestionados, conviene distinguir entre tiempo de detección, tiempo de aviso al cliente y tiempo de entrega de datos técnicos. Un proveedor puede avisar en 24 horas y, aun así, dejar al cliente sin registros, indicadores de compromiso o lista de cuentas afectadas durante una semana. Desde el punto de vista de la resiliencia, eso no es una respuesta rápida; es una notificación con retraso operativo.
La subcontratación: donde muchos contratos pierden los dientes
La cadena de suministro se vuelve opaca cuando el proveedor directo conserva el control comercial pero no el control técnico. La entidad contrata a un integrador; el integrador utiliza un proveedor de software; el software se ejecuta sobre un hyperscaler; el soporte se presta desde otra jurisdicción. Si el contrato solo permite conocer al proveedor directo, la organización puede descubrir la dependencia cuando el servicio ya está degradado.
La cláusula de subcontratación debe exigir información suficiente sobre los terceros que puedan acceder a datos, administrar sistemas o afectar a la continuidad. No siempre será necesario aprobar individualmente a cada subcontratista. Sí debería existir un mecanismo para objetar cambios relevantes, recibir aviso con antelación razonable y obtener una solución cuando el nuevo tercero eleve el riesgo por encima del apetito aprobado.
El proveedor directo debe mantener la responsabilidad contractual por la seguridad de sus subcontratistas. La respuesta “eso lo gestiona nuestro proveedor cloud” no puede cerrar la conversación. Puede explicar una arquitectura; no extingue una obligación.
Para servicios con alta concentración, la entidad debería exigir un mapa de dependencias actualizado. No hace falta convertirlo en un diagrama artístico: basta con identificar los componentes cuya caída puede impedir prestar el servicio, la región o regiones de operación, las alternativas disponibles y los puntos únicos de fallo. Esta información permite decidir si el riesgo se reduce mediante redundancia, controles compensatorios, una segunda fuente o aceptación formal por la dirección.
Monitorizar: el control que separa el cumplimiento real del archivo muerto
La evaluación inicial caduca. Los proveedores cambian de propietario, trasladan operaciones, incorporan nuevas herramientas, modifican sus APIs y sufren incidentes. Una revisión anual puede ser razonable para un proveedor de bajo riesgo; para una plataforma privilegiada o crítica, no basta por sí sola.
La monitorización debe combinar señales contractuales, técnicas y operativas. Entre las señales útiles están los cambios en el alcance de certificaciones, vulnerabilidades críticas que afecten al producto, interrupciones repetidas, incumplimientos de SLA, rotación anormal de subcontratistas, cambios de jurisdicción, hallazgos de auditoría pendientes y degradación de la capacidad de soporte.
La inteligencia sobre vulnerabilidades debe conectarse con el inventario de proveedores y productos. Si un proveedor utiliza una biblioteca vulnerable, la pregunta no es solo si ha publicado un comunicado. Hay que saber si el componente está presente en el servicio contratado, si es explotable en esa configuración, qué mitigación existe, qué versión se ha desplegado y qué evidencias permiten cerrar el riesgo.
El artículo 21.2.e, al referirse a la seguridad en la adquisición, desarrollo y mantenimiento y a la gestión y divulgación de vulnerabilidades, ofrece una base clara para exigir este circuito. La organización debe poder demostrar que recibe información, la analiza, decide y verifica la remediación. Un boletín reenviado por correo electrónico no es un proceso de gestión de vulnerabilidades.
Los indicadores deben servir para tomar decisiones. Algunos ejemplos son el porcentaje de proveedores críticos con revisión vigente, el número de accesos privilegiados de terceros sin uso reciente, el tiempo medio de revocación al terminar un contrato, el porcentaje de hallazgos vencidos, la cobertura de pruebas de restauración y el tiempo transcurrido entre la detección de un incidente del proveedor y la notificación interna.
No conviene convertir cada indicador en un objetivo cosmético. Una organización puede presumir de tener el 100% de los certificados recopilados y seguir sin saber quién puede modificar su directorio de identidades. El indicador correcto no es el que queda bien en la presentación al comité; es el que revela una decisión pendiente.
La relación con DORA: solapamiento útil, no doble burocracia
Para bancos, aseguradoras, empresas de inversión, entidades de pago y otros operadores financieros incluidos en el ámbito de DORA, la diligencia sobre terceros TIC tiene una segunda capa regulatoria. El Reglamento (UE) 2022/2554 es aplicable desde el 17 de enero de 2025 y sus artículos 28 a 30 regulan la gestión del riesgo de terceros TIC y los elementos contractuales esenciales.
DORA artículo 28 exige que las entidades financieras gestionen el riesgo TIC de terceros como parte integral del riesgo TIC. El artículo 29 trata de la estrategia de salida y el artículo 30 detalla los elementos contractuales para servicios TIC. Entre ellos figuran descripciones claras del servicio, requisitos de disponibilidad, integridad, seguridad, protección de datos, acceso y recuperación, así como derechos de auditoría y terminación.
La diferencia práctica con NIS2 está en el grado de formalización y en el foco sectorial. NIS2 establece una obligación horizontal para sectores esenciales e importantes. DORA añade un régimen financiero específico, incluidos registros de información sobre acuerdos contractuales de servicios TIC y un marco de supervisión para proveedores terceros TIC críticos en el artículo 31. La entidad financiera no puede utilizar el cumplimiento de NIS2 como sustituto automático del cumplimiento de DORA.
La buena noticia es que el trabajo puede integrarse. Un único inventario de terceros puede incorporar la clasificación NIS2, la criticidad DORA, el tipo de acceso, los datos tratados, los subcontratistas, la ubicación, los RTO y RPO, los derechos de auditoría y la estrategia de salida. Lo absurdo sería mantener un Excel para seguridad, otro para compras, otro para privacidad y otro para DORA, todos con nombres de proveedor ligeramente distintos y ninguno con el propietario correcto.
La intersección también alcanza al RGPD. Cuando el proveedor trata datos personales por cuenta de la entidad, el artículo 28 del RGPD exige un contrato de encargado con instrucciones documentadas, confidencialidad, medidas de seguridad, apoyo en derechos y brechas, y condiciones para subencargados. El artículo 32 exige medidas técnicas y organizativas apropiadas al riesgo. DORA y NIS2 no sustituyen esas obligaciones; tampoco el artículo 28 del RGPD cubre por sí solo la continuidad, la concentración o la reversibilidad de un servicio TIC crítico.
ISO 27001, SOC 2 y la tentación del sello mágico
Las certificaciones y los informes independientes son herramientas valiosas porque reducen la asimetría de información entre cliente y proveedor. Pero su valor depende del alcance, la fecha, el tipo de evaluación y las excepciones encontradas.
ISO/IEC 27001 certifica un sistema de gestión de seguridad de la información. La entidad debe comprobar qué sociedades, servicios, ubicaciones y controles aparecen en el alcance. Un certificado de la matriz no prueba necesariamente la seguridad de la filial que presta el servicio. Un certificado que cubre procesos corporativos puede no cubrir la plataforma productiva contratada.
Un informe SOC 2 tampoco es una certificación general de seguridad. El cliente debe revisar los criterios incluidos, el periodo cubierto, las pruebas realizadas y las excepciones. Un informe de tipo I describe el diseño de controles en una fecha; un tipo II aporta evidencia sobre su funcionamiento durante un periodo. La diferencia importa cuando se está evaluando un proveedor con acceso privilegiado.
La due diligence debería usar estos documentos como evidencia de un control concreto y no como conclusión global. Después hay que formular preguntas específicas: ¿el entorno contratado está incluido? ¿se han producido excepciones? ¿qué plan de remediación existe? ¿qué controles dependen de los clientes? ¿qué subcontratistas aparecen en el informe? ¿cómo se confirma que la configuración de nuestra cuenta respeta esos controles?
La ironía es que cuanto más grande es el proveedor, más extensa suele ser su biblioteca de compliance y más fácil resulta confundir volumen documental con seguridad. Un paquete de 600 páginas puede ocultar una respuesta de dos líneas que nadie ha validado.
Qué evidencias debería conservar la entidad
NIS2 no exige una lista universal de documentos con un formato único, pero el artículo 21.2.f obliga a evaluar la eficacia de las medidas. Si la organización no conserva evidencias de cómo tomó y revisó sus decisiones, tendrá dificultades para demostrar eficacia ante una autoridad, un auditor o su propio consejo.
El expediente de un proveedor crítico debería permitir reconstruir la decisión sin depender de la memoria del responsable de compras. Como mínimo, debería contener la clasificación de riesgo y su justificación, el servicio y los activos afectados, el acceso concedido, la evaluación inicial, las evidencias revisadas, las excepciones aceptadas, el propietario interno, las obligaciones contractuales, el plan de remediación y la fecha de próxima revisión.
También conviene conservar las actas o decisiones de aceptación de riesgo. Si la entidad mantiene una excepción porque no puede migrar el servicio hasta dentro de nueve meses, esa decisión debe tener una autoridad responsable, controles compensatorios y una fecha de vencimiento. “Pendiente de revisar” durante cuatro años no es una excepción; es una política de abandono con formato de estado.
Para los incidentes, la trazabilidad debe incluir el aviso del proveedor, las horas de recepción y escalado, el análisis de impacto, las decisiones sobre comunicación a la autoridad, las medidas de contención, la evidencia preservada y las lecciones incorporadas al contrato o al control. El artículo 20 de NIS2 atribuye a los órganos de gestión responsabilidades sobre las medidas de ciberseguridad y prevé formación para sus miembros. El consejo no necesita convertirse en un equipo de respuesta, pero sí debe poder demostrar que supervisa el riesgo y que entiende las dependencias que acepta.
El gobierno interno: compras no puede ser el propietario del riesgo
La seguridad de proveedores falla cuando se trata como un trámite de procurement. Compras puede negociar precio, condiciones y remedios contractuales; no puede determinar por sí sola si un proveedor de identidad puede mantener acceso privilegiado permanente.
El modelo más sólido asigna responsabilidades distintas. El propietario del servicio define el impacto de una interrupción. Seguridad evalúa controles técnicos y exposición. Privacidad analiza datos personales y transferencias. Legal traduce requisitos regulatorios y remedios en contrato. Compras gestiona el proceso comercial. Continuidad prueba la recuperación. El órgano de gestión acepta el riesgo residual cuando supera el umbral delegado.
La separación no debe convertirse en una cadena de aprobaciones sin dueño. Una entidad necesita una regla clara para detener una contratación, imponer una condición o elevar el riesgo. También necesita distinguir entre proveedores TIC, proveedores operativos no TIC y proveedores que, aunque no administren sistemas, tienen acceso físico o lógico suficiente para afectar a la disponibilidad o confidencialidad.
La formación del artículo 20 no debería consistir en una presentación anual sobre phishing. Para los miembros del órgano de gestión, el contenido útil es otro: concentración de proveedores, dependencia de subcontratistas, resultados de pruebas de recuperación, incidentes abiertos, excepciones vencidas y decisiones que requieren apetito de riesgo. La gobernanza empieza cuando alguien pregunta qué ocurriría si el proveedor no vuelve a estar disponible, no cuando se firma el acta de la reunión.
Un modelo operativo que puede defenderse ante el regulador
Una organización puede convertir estas obligaciones en un ciclo manejable si evita tratar la revisión del proveedor como un evento aislado.
Primero, debe mantener un inventario vivo de servicios y dependencias, no solo de contratos. El registro debe identificar quién presta el servicio, qué unidad lo utiliza, qué datos procesa, qué accesos mantiene, qué sistemas soporta y qué sustitutos existen.
Después debe aplicar una clasificación coherente. La criticidad debe combinar impacto, accesos, sustituibilidad, concentración, jurisdicción, sensibilidad de datos y dependencia tecnológica. No todas las dimensiones tienen que producir una puntuación matemática, pero sí una decisión repetible y explicable.
La evaluación debe generar requisitos proporcionales. Un proveedor crítico puede necesitar pruebas de recuperación, auditoría independiente, notificación en horas, revisión de subcontratistas y asistencia de salida. Un proveedor de bajo riesgo puede someterse a un proceso más ligero. La proporcionalidad no consiste en bajar el listón para todos; consiste en poner el listón correcto en cada servicio.
La contratación debe incorporar controles verificables y remedios. Si el proveedor no acepta auditorías presenciales, puede ofrecer informes independientes, evidencias de control, entrevistas y pruebas específicas. Pero la alternativa debe preservar la capacidad de verificar. Un derecho de auditoría inutilizable por coste, preaviso o restricciones de alcance no es un derecho eficaz.
La operación debe monitorizar indicadores y cambios. Una renovación automática no puede activar automáticamente la renovación del riesgo. El propietario debe revisar si el servicio, el acceso, la arquitectura y el impacto siguen siendo los mismos.
Por último, la entidad debe probar la salida y la respuesta. Un ejercicio de continuidad que excluye al proveedor crítico es una simulación de la realidad. El proveedor debe participar en las pruebas que afectan al servicio, entregar resultados y corregir deficiencias. Si se niega, la negativa es en sí misma información de riesgo.
Qué debería hacer ahora un CISO o responsable de cumplimiento
La primera acción no es comprar una plataforma de third-party risk management. Es seleccionar una muestra de proveedores realmente relevantes y comprobar si la organización puede responder, con evidencias, a seis preguntas:
- ¿Qué servicio presta el proveedor y cuál es el impacto máximo de su indisponibilidad?
- ¿Qué accesos tiene, quién los utiliza y cómo se revocan?
- ¿Qué subcontratistas y dependencias pueden interrumpir el servicio?
- ¿Qué controles se han verificado y qué excepciones siguen abiertas?
- ¿Cuánto tardaría el proveedor en avisar y aportar información durante un incidente?
- ¿Cómo se recuperaría o sustituiría el servicio si el contrato terminara mañana?
Si la respuesta a dos o tres preguntas depende de “tendremos que preguntarlo”, el inventario no está maduro. Si depende de que un proveedor envíe una certificación genérica, la due diligence tampoco.
La segunda acción es comparar el contrato con la operación real. ¿El contrato exige aviso en cuatro horas, pero el equipo de seguridad solo tiene un buzón revisado en horario laboral? ¿Se exige MFA, pero nadie revisa los accesos de soporte? ¿Existe derecho de auditoría, pero el proveedor nunca ha entregado una evidencia técnica? Las contradicciones entre contrato y operación son hallazgos prioritarios porque suelen sobrevivir a las revisiones documentales.
La tercera es llevar al comité de riesgo las dependencias que no pueden remediarse de inmediato. La dirección puede aceptar un riesgo residual; no debería aceptarlo por desconocimiento. El artículo 20 de NIS2 refuerza precisamente esa responsabilidad del órgano de gestión.
La prueba definitiva: qué ocurre el día del incidente
La cadena de suministro no se evalúa de verdad cuando el proveedor responde a un cuestionario. Se evalúa cuando una vulnerabilidad afecta a su plataforma, cuando un administrador externo es comprometido o cuando el servicio deja de estar disponible y la entidad necesita saber qué puede aislar, qué debe comunicar y cuánto tardará en recuperarse.
NIS2 artículo 21 obliga a conectar prevención, respuesta y continuidad. El artículo 23 impone plazos de notificación de incidentes significativos. El artículo 20 coloca la responsabilidad de supervisión en el órgano de gestión. Juntos dibujan una obligación bastante más exigente que “tener proveedores homologados”.
Para un CISO, la señal de madurez no es el número de evaluaciones completadas. Es la capacidad de responder con precisión cuando el proveedor falla: qué servicio está afectado, qué datos y sistemas dependen de él, qué controles siguen funcionando, qué alternativa existe, qué evidencia se conserva y quién decide la comunicación.
Ese es el estándar que debería guiar la due diligence en 2026. No se trata de convertir cada contrato en una auditoría interminable ni de exigir a una pyme el mismo aparato de control que a un proveedor cloud global. Se trata de dejar de llamar “gestión de terceros” a una carpeta de certificados y construir un mecanismo que permita elegir, supervisar y abandonar proveedores sin descubrir el riesgo cuando ya es demasiado tarde.