El riesgo de la cadena de suministro es un programa, no una lista de auditoría
La lista de proveedores estaba en verde antes de la auditoría. Entonces apareció el acceso de administrador de un subcontratista del proveedor de hosting del ERP en un sistema de tickets que no constaba ni en el contrato ni en el registro. NIS2 y DORA no exigen un archivo de cuestionarios marcados, sino un proceso que mantenga sincronizados de forma continua los contratos, los datos y los accesos.
Lo más importante en resumen
- Núcleo legal: El párrafo 30 de la BSIG exige la seguridad de la cadena de suministro para los proveedores directos, el artículo 21 de NIS2 requiere una gestión continua de riesgos. Un registro por sí solo no lo cumple.
- DORA es más estricto: En el sector financiero rige desde el 17 de enero de 2025 un registro de terceros de TIC con notificación anual, estrategias de salida y supervisión continua. El 18 de noviembre de 2025, la autoridad de supervisión designó a 19 proveedores críticos.
- Una instantánea no basta: El estado del cuestionario de ayer no cubre el cambio de subcontratista de hoy. La categorización por criticidad y el monitoreo continuo sustituyen a la auditoría anual.
- La responsabilidad decide: Sin un propietario claro para cada paso del proceso y la conexión al registro de riesgos empresariales, el riesgo de proveedores sigue siendo un ticket de compras en lugar de un tema para la dirección.
Relacionado:TrapDoor: Ataque a la cadena de suministro en npm, PyPI y Crates / DORA y NIS2: Por qué chocan las auditorías de los bancos
Lo que el párrafo 30 exige realmente para la cadena de suministro
¿Qué es la Gestión de Riesgos de Terceros? La Gestión de Riesgos de Terceros es el proceso continuo mediante el cual una organización identifica, evalúa, contractualiza y supervisa los riesgos de seguridad de sus proveedores de servicios, proveedores de software y sus subcontratistas. Abarca desde la incorporación hasta el control continuo y la baja.
El párrafo 30 apartado 2 número 4 de la BSIG menciona expresamente la seguridad de la cadena de suministro como medida obligatoria. El foco se centra en las relaciones con los proveedores directos. No se refiere a toda la cadena hasta la materia prima. Esa es la buena noticia para el Mittelstand: se trata de los socios contractuales directos que tienen acceso a sistemas o datos.
La noticia menos cómoda aparece en el apartado 1 y en la plantilla europea. Las medidas deben ser adecuadas, proporcionadas y eficaces, y además existe una obligación de documentación. El artículo 21 de NIS2 exige una gestión continua de riesgos para todos los sistemas de red y de información que utiliza la operación. El considerando 85 de la directiva menciona expresamente la nube, la seguridad gestionada y el software. Un registro que se crea una vez al año no cumple esta obligación.
DORA convierte el registro en una obligación permanente
Quienes trabajan en el sector financiero conocen el estándar más estricto. DORA es de aplicación obligatoria desde el 17 de enero de 2025. Para las empresas financieras se aplica como derecho especial en lugar de las obligaciones de cadena de suministro de NIS2. Ambos regímenes no se aplican en paralelo a la misma empresa. El artículo 28 deja la responsabilidad íntegramente en la empresa financiera, incluso cuando el servicio está externalizado.
El registro de la información no es un Excel que se rellena una vez. Se mantiene a nivel de entidad y de grupo, se notifica anualmente a la autoridad de supervisión y debe estar disponible completo a petición. Antes de cada contrato para una función crítica se realiza una Due Diligence, además del análisis de riesgos de concentración y las estrategias de salida. El artículo 30 prescribe contenidos contractuales concretos: regulaciones de subcontratistas, ubicación del tratamiento de datos, derechos de auditoría y obligaciones de notificación ante cambios sustanciales.
La seriedad con la que la autoridad de supervisión lo toma quedó patente el 18 de noviembre de 2025. Las autoridades europeas de supervisión EBA, EIOPA y ESMA publicaron la primera lista de proveedores críticos de servicios TIC de terceros, 19 proveedores, entre ellos varios grandes proveedores de nube y SAP. Estos proveedores están ahora bajo supervisión directa de la UE. El riesgo de la cadena de suministro se regula a nivel de sistema, mucho más allá del contrato individual.
Por qué el cuestionario anual no cierra la brecha
Una vez archivé un cuestionario de proveedor con un visto bueno verde en ISO 27001 y di el asunto por cerrado. Cuatro meses después, el proveedor cambió a su subcontratista de hosting. El cuestionario seguía verde, la realidad ya no. Exactamente esta discrepancia temporal es el problema.
El texto normativo se refiere a un ciclo. No le basta una verificación única. El párrafo 30 número 6 exige una evaluación de la eficacia, el artículo 30 de DORA exige supervisión continua en los contratos críticos. No todos los proveedores necesitan la misma profundidad. Una categorización según el acceso a sistemas, la sensibilidad de los datos y la dependencia de disponibilidad separa a los socios Tier A de la larga lista de proveedores de servicios no críticos.
A esto se suma un problema de datos. Una encuesta sectorial sobre Gestión de Riesgos de Terceros de 2026 sugiere que solo una minoría de los programas está plenamente integrada en el Enterprise Risk Management y aún menos organizaciones califican su calidad de datos como alta. Los valores exactos dependen de la metodología. El diagnóstico se mantiene: sin un registro limpio no hay una decisión de categorización fiable. Sin conexión al ERM, el riesgo queda atascado en el ticket de compras en lugar de en el informe trimestral de la dirección.
La siguiente tabla contrapone las dos formas de pensar.
| Dimensión | Lista de auditoría (instantánea) | Programa (continuo) |
|---|---|---|
| Frecuencia | Una vez al año, antes de la auditoría | Continuo, activado por cambios contractuales y de sistemas |
| Alcance | Todos los proveedores tratados por igual | Categorización por criticidad, Tier A intensivo |
| Subcontratistas | No registrados | Cláusulas de cascada, cuarta parte en el registro |
| Integración | Ticket de compras | Registro de riesgos empresariales, informe a la dirección |
| Evidencia | Archivo de cuestionarios | Registro mantenido, historial de monitoreo, evaluación de eficacia |
Cinco pilares que convierten el control en un programa
Un programa sólido no necesita una gran plataforma, necesita propietarios claros para cada paso del proceso. Cinco pilares bastan para empezar.
Política y categorización. Una matriz de criticidad según acceso, datos y disponibilidad determina quién es Tier A y con qué frecuencia se audita. El propietario es el área de Riesgos o el CISO, implementado por un responsable de TPRM.
Evaluación de incorporación. La Due Diligence precede al contrato. Después, el acceso suele estar ya activo. Las evidencias de seguridad, las preguntas sobre ubicación y la verificación de conflictos deben aclararse antes de que el acceso se active. El artículo 28 de DORA lo convierte en obligación para las funciones críticas.
Supervisión continua. Mantenimiento del registro, recertificación según riesgo y un canal para notificaciones de incidentes del proveedor. Aquí vive o muere el programa. Un cambio de contrato en el proveedor debe generar una señal. Una nota silenciosa no basta.
Baja. Revocación de accesos, devolución o eliminación de datos y un fin de contrato documentado. El punto ciego más frecuente son los accesos que permanecen activos después de finalizado el proyecto.
Cuarta parte y transparencia del software. Los subcontratistas pertenecen a los campos del registro, el software crítico necesita una lista de materiales según el principio SBOM. Esta lista de materiales no es una obligación normativa expresa, pero ayuda a trasladar la gestión de vulnerabilidades del párrafo 30 número 5 de la BSIG hasta la cadena de suministro.
Por encima de todo está la dirección. El párrafo 38 de la BSIG la obliga a la implementación y supervisión. Un programa de TPRM sin una revisión visible por la dirección es una portada de CISO sin valor de gobernanza. El proveedor de servicios de instalaciones con acceso a la sala de servidores es Tier A, aunque compras lo clasifique solo bajo servicios de edificio. Precisamente estas clasificaciones deciden sobre el riesgo.
El punto de partida: por dónde empezar esta semana
El camino del cuestionario al programa no requiere un gran salto. Cinco pasos aportan estructura sin bloquear la operación. Primero: identificar a los proveedores Tier A, es decir, todos aquellos con acceso a sistemas o datos críticos. Segundo: contrastar el registro con la realidad e incorporar los subcontratistas que falten. Tercero: asignar a cada socio Tier A un propietario y un ritmo de supervisión. Cuarto: revisar las cláusulas contractuales sobre derechos de auditoría, subcontratistas y obligaciones de notificación. Quinto: elevar los riesgos de proveedores como entradas al registro de riesgos empresariales, con informe trimestral a la dirección.
Esto no es un proyecto con fecha de finalización. Es un modo operativo. Quien lo ha establecido una vez, supera la siguiente auditoría de forma incidental, porque la evidencia es un subproducto de la operación en curso.
Preguntas frecuentes
Cada pregunta está cerrada. Al tocarla se desbloquea la respuesta.
¿Basta un directorio de proveedores para el cumplimiento de NIS2?
No. El párrafo 30 de la BSIG y el artículo 21 de NIS2 exigen medidas adecuadas, eficaces y gestionadas de forma continua. Un directorio por sí solo no basta. Un registro estático sin categorización, supervisión y evaluación de eficacia no cubre la obligación de gestión de riesgos.
¿Qué diferencia a DORA de las obligaciones de cadena de suministro de NIS2?
DORA se aplica desde el 17 de enero de 2025 en el sector financiero y tiene prioridad allí. Exige un registro formal de terceros de TIC con notificación anual, estrategias de salida y contenidos contractuales detallados según el artículo 30. NIS2 establece el marco de forma más amplia, pero menos formalizada.
¿Debemos registrar a los subcontratistas de nuestros proveedores de servicios?
En el sector financiero sí, en cuanto afecten a funciones críticas o importantes. El artículo 30 de DORA y las especificaciones técnicas del registro exigen cláusulas de cascada y el registro de subcontratistas relevantes. Bajo NIS2, el párrafo 30 número 4 se refiere principalmente a los proveedores directos; la obligación expresa de registrar subcontratistas es una particularidad de DORA.
¿Con qué frecuencia debemos reevaluar a los proveedores?
No existe una frecuencia fija para todos. El ritmo depende del nivel: proveedores críticos con acceso a sistemas de forma estrecha y orientada a eventos; proveedores de servicios no críticos con menor frecuencia. Los desencadenantes son cambios contractuales, cambios de subcontratistas e incidentes de seguridad.
¿Qué es un SBOM y por qué pertenece al TPRM?
Un SBOM es una lista de materiales de los componentes de software de un producto, a menudo en formato CycloneDX o SPDX. Muestra qué bibliotecas proceden de la cadena de suministro y apoya así la gestión de vulnerabilidades del párrafo 30 número 5. No está prescrito un SBOM, pero se ha establecido como práctica. Sin esta transparencia, el origen del software sigue siendo un punto ciego.
Selección de la redacción
RecomendadoPuerta trasera: Ataque coordinado a la cadena de suministro en npm, PyPI y Crates – qué debenRecomendadoDORA y NIS2: Por qué las auditorías bancarias ahora chocanRecomendadoDonde la pequeña y mediana empresa todavía está técnicamente rezagada en NIS2
Más de la red MBF Media
Digital ChiefsGeopol?tica y datacenters: lo que los CIO deben asegurarMyBusinessFutureReglamento de IA de la UE a partir de agosto de 2026: lo que las pymes deben etiquetar ahoracloudmagazinXFS4IoT se encuentra con la nube: El cajero automático se convierte en plataforma
