Diligencia debida de proveedores CRA: cuestionario y alertas

La diligencia debida sobre componentes es una obligación del fabricante en virtud del artículo 13, apartado 5 del Reglamento de Ciberresiliencia. Texto íntegro:

"A efectos del cumplimiento de lo dispuesto en el apartado 1, los fabricantes ejercerán la diligencia debida al integrar componentes procedentes de terceros de modo que estos componentes no comprometan la seguridad del producto con elementos digitales, también cuando se integren componentes de programas informáticos libres y de código abierto que no se hayan comercializado en el transcurso de una actividad comercial."

Esta página es el complemento operativo al bloque de obligaciones del fabricante. El marco normativo, los límites de cada rol y las comprobaciones del lado del importador están en las guías del clúster: fabricante, importador, distribuidor y quién debe cumplir. Lo que viene a continuación es el cuestionario, los manuales por tipo de proveedor que las páginas del clúster no cubren (FOSS, nube, solo hardware, custodios de OSS, firmware COTS modificado) y los escenarios operativos que afectan a los equipos en la compra real: proveedores que no responden, componentes compartidos aguas arriba, retrasos posteriores a una fusión o adquisición y visibilidad en cadenas de varios niveles.

Por qué importa la diligencia debida de proveedores

Aunque seas fabricante de tu propio producto, lo que sale por la puerta incluye componentes de proveedores: librerías de software de terceros, componentes de hardware, módulos de firmware, servicios en la nube. Las vulnerabilidades de esos componentes pasan a ser tus vulnerabilidades, y tu evaluación de la conformidad debe tener en cuenta los riesgos de la cadena de suministro.

El artículo 13, apartado 5, hace explícita esa evaluación. El Reglamento no impone un formato de cuestionario, pero un cuestionario escrito es la forma práctica de documentar que comprobaste la seguridad del componente, la gestión de vulnerabilidades, la disponibilidad de SBOM, los compromisos de soporte y las vías de respuesta del proveedor antes de integrarlo. Sin registros fechados, no tienes nada que contar a una autoridad de vigilancia del mercado sobre cómo se trató el riesgo a nivel de componente.

Si en un producto concreto también actúas como importador (introduces en la UE el producto de un fabricante no establecido en la UE), las cuatro comprobaciones previas al mercado del importador son un deber de verificación distinto. Esta guía se centra en la diligencia sobre componentes del lado del fabricante.

Marco de diligencia debida

Enfoque por niveles

No todos los proveedores requieren el mismo nivel de escrutinio:

EVALUACIÓN POR NIVELES DE PROVEEDOR

NIVEL 1 (Críticos):
- Componentes con funciones de seguridad (cripto, autenticación, cortafuegos)
- Dependencias de software centrales
- Hardware con firmware
Evaluación: cuestionario completo + revisión documental + monitorización continua

NIVEL 2 (Significativos):
- Componentes de funcionalidad principal
- Elementos conectados a red
- Componentes de tratamiento de datos
Evaluación: cuestionario estándar + revisión documental

NIVEL 3 (Estándar):
- Componentes sin función de seguridad
- Librerías de utilidad
- Hardware periférico
Evaluación: cuestionario básico + comprobaciones puntuales

NIVEL 4 (Mínimo):
- Componentes commodity
- OSS consolidado
- Hardware no conectado
Evaluación: verificación básica + inclusión en SBOM

Áreas de evaluación

Tu diligencia debida debe cubrir:

El marco es genérico, pero las pruebas que cada tipo de proveedor puede producir realmente varían. Las cinco secciones siguientes recorren las formas de proveedor más habituales y la vía de diligencia que encaja con cada una.

Diligencia debida específica para componentes FOSS

El artículo 13, apartado 5, nombra los componentes FOSS de forma explícita: componentes de programas informáticos libres y de código abierto que no se hayan comercializado en el transcurso de una actividad comercial. El deber jurídico se aplica con independencia de que medie dinero. Un cuestionario firmado con sangre por un proveedor comercial no es el modelo cuando aguas arriba hay un proyecto de GitHub con tres mantenedores.

Para los componentes FOSS no comerciales, el conjunto de pruebas pasa de documentos atestiguados por el proveedor a señales observables del proyecto que tú mismo puedes recoger.

LISTA DE COMPROBACIÓN DE DILIGENCIA SOBRE COMPONENTES FOSS

SALUD DEL PROYECTO:
[ ] Commits activos en los últimos 90 días
[ ] Número de contribuidores distintos (>1 = alivio del bus-factor)
[ ] Cadencia de releases declarada u observable
[ ] El issue tracker responde (tiempo mediano hasta el primer comentario)

POSTURA DE SEGURIDAD:
[ ] SECURITY.md con dirección de divulgación
[ ] Política CVD (canal privado de avisos de seguridad, no solo una issue)
[ ] Histórico de CVE revisado (NVD, GitHub Security Advisories, OSV)
[ ] Los ingredientes del SBOM son a su vez reconocibles, no forks profundos

LICENCIA Y PROCEDENCIA:
[ ] El identificador SPDX coincide con lo que declaran los metadatos del paquete
[ ] Sin dependencias transitivas con licencia incompatible
[ ] Los artefactos publicados tienen procedencia verificable (p. ej., SLSA, sigstore)

TU PLAN DE RESPALDO:
[ ] Identificado el destino del fork si aguas arriba enmudece
[ ] Declarada la capacidad interna de parcheo (qué ingeniero, qué código)
[ ] Candidatos de reemplazo listados, con el esfuerzo de sustitución estimado

Dos reglas operativas. Primera: el artículo 13, apartado 6, exige que las vulnerabilidades que detectes en un componente FOSS se notifiquen al proyecto aguas arriba y que cualquier corrección que produzcas se comparta de vuelta, en formato legible por máquina cuando proceda. El elemento que comprueba el cuestionario no es el compromiso del proyecto contigo, sino tu propio compromiso de hacer circular vulnerabilidades y parches en sentido inverso. Segunda: un proyecto aguas arriba en silencio no extingue tu deber. Si el proyecto se queda inactivo, tu plan de respaldo (fork, parcheo interno, reemplazo) forma parte del registro de diligencia, no es un problema para el futuro.

Para los proyectos sostenidos por una fundación o entidad jurídica que actúe como custodio de código abierto, el patrón de diligencia cambia otra vez. Ese caso está en la siguiente sección.

Custodio de OSS frente a proveedor comercial

Una clase pequeña pero importante de upstream está dirigida por un custodio de software de código abierto: una entidad jurídica, normalmente una fundación, cuyo objetivo principal es sostener proyectos concretos de código abierto destinados a un uso comercial. La Linux Foundation, la Eclipse Foundation y la Apache Software Foundation son ejemplos típicos. Los custodios entran en el artículo 24, no en el artículo 13. El conjunto de deberes es más estrecho (una política de ciberseguridad documentada, un deber de cooperación con las autoridades de vigilancia del mercado, aplicación parcial de la notificación de incidentes del artículo 14), y el custodio no es el fabricante de ningún producto comercial aguas abajo.

Para la frontera entre fabricante y custodio, consulta custodios de código abierto.

La consecuencia para ti, como integrador aguas abajo, es que la forma del cuestionario es distinta.

Lo que sigues haciendo: comprobaciones de salud del proyecto, ingesta de SBOM, monitorización de CVE, tu propio plan de fork y parche de respaldo. Lo que dejas de esperar: SLA contractuales de notificación de vulnerabilidades, niveles de soporte de pago, cláusulas de auditoría. El registro de diligencia para un componente sostenido por un custodio es más fino por el lado del proveedor y más grueso por el lado de tus propios controles que para un proveedor comercial, y esa es la forma jurídicamente correcta.

Diligencia de componentes que son servicios en la nube

Cuando el "componente" dentro de tu producto es una API o un servicio gestionado (un SaaS de autenticación, un broker de mensajería gestionado, una función serverless, una base de datos en la nube), el patrón de pruebas vuelve a ser distinto. No hay DoC, no hay SBOM, no hay código fuente que envíes. Hay un contrato, una cartera de atestaciones de seguridad y un modelo de responsabilidad compartida.

DILIGENCIA DE COMPONENTES EN LA NUBE

ATESTACIONES DE SEGURIDAD:
[ ] Informe SOC 2 Type II (vigente)
[ ] Certificado ISO/IEC 27001 (vigente, verificación de alcance)
[ ] ISO/IEC 27017 (controles específicos de nube) cuando proceda
[ ] ISO/IEC 27018 (PII en nube pública) cuando entren datos personales

EVIDENCIA OPERATIVA:
[ ] Status page con histórico de incidentes y post-mortems
[ ] RTO/RPO publicados y fecha de la última prueba de DR
[ ] Lista de subprocesadores y proceso de notificación de cambios
[ ] Contrato de tratamiento de datos con residencia UE, cuando proceda

RESPONSABILIDAD COMPARTIDA:
[ ] Ámbito de responsabilidad del proveedor documentado
[ ] Ámbito de tu responsabilidad reconocido (config, identidad, secretos, red)
[ ] Acceso a logs y registro de auditoría dentro de tu ámbito

ADYACENTE AL CRA:
[ ] Vía de divulgación de vulnerabilidades para la propia API
[ ] Reloj de notificación de brechas en el contrato (horas, no "sin demora")
[ ] Ventana de aviso de discontinuación del servicio (típicamente 12 meses)

El CRA no regula al proveedor de la nube de forma directa cuando este no comercializa un producto con elementos digitales. Tu deber bajo el artículo 13, apartado 5, es probar que la dependencia de la nube no compromete la ciberseguridad de tu producto. El entregable es la cartera de atestaciones más una declaración escrita de responsabilidad compartida, no un cuestionario con forma CRA.

Diligencia de proveedores solo de hardware y ODM

Cuando tu fabricante por contrato (ODM, EMS, ensamblador estilo OEM) entrega placas físicas y el firmware es tuyo, el proveedor aporta el sustrato de hardware pero no el envoltorio de seguridad. El CRA pone el envoltorio de seguridad sobre ti, la entidad que flashea y firma el firmware que va en la placa.

El cuestionario aquí pesa menos en preguntas de software y más en confianza de hardware e integridad de la cadena de suministro.

DILIGENCIA SOLO DE HARDWARE / ODM

CONFIANZA DEL HARDWARE:
[ ] BOM con identificación de componentes a nivel criptográfico
[ ] Controles anticomponentes falsificados (auditoría de aprovisionamiento)
[ ] Origen del elemento seguro y método de preprovisionamiento
[ ] Proceso de inyección de claves en fábrica y rastro de auditoría

INTEGRIDAD DEL ENSAMBLAJE:
[ ] Sistema de calidad ISO 9001 implantado
[ ] Evidencia de manipulación aplicada durante ensamblaje y envío
[ ] Trazabilidad de lote/serie desde fábrica hasta muelle de recepción

ENTREGA DEL FIRMWARE:
[ ] Quién firma el firmware: tú, el ODM o ambos
[ ] Estado de aprovisionamiento en el primer arranque (valores de fábrica, traspaso de propiedad)
[ ] Cadena de bootloader y arranque seguro, quién posee cada eslabón

POSTVENTA:
[ ] Ventana de aviso de EOL para la plataforma de hardware
[ ] Compromiso de last-time-buy y su duración
[ ] Disponibilidad de piezas de repuesto durante el periodo de soporte comprometido

Un error operativo común: firmar un periodo de soporte de varios años con un ODM cuya ventana de EOL de hardware es de 18 meses. El reloj del periodo de soporte del CRA empieza a correr cuando introduces el producto en el mercado de la UE; si el silicio subyacente entra en EOL dentro de esa ventana, la obligación de soporte no se transfiere a la tolerancia de tu cliente.

Firmware COTS que modificas

Si tomas un producto comercial estándar, modificas el firmware y comercializas el resultado en la UE, el artículo 22 te trata como fabricante del producto modificado para la parte afectada por la modificación sustancial, o para el producto entero si la modificación toca el envoltorio de ciberseguridad.

"A los efectos del presente Reglamento, se considerará fabricante a una persona física o jurídica, distinta del fabricante, el importador o el distribuidor, que lleve a cabo una modificación sustancial de un producto con elementos digitales y comercialice dicho producto."

La consecuencia para la diligencia es grande: la DoC y la evaluación de la conformidad del fabricante original ya no cubren el producto tal como tú lo comercializas. Heredas el conjunto de deberes del fabricante para la parte afectada o para el conjunto. El proveedor original deja de ser relevante para el expediente CRA; tu propio equipo de ingeniería se convierte en el responsable.

El paso de diligencia aquí no es, por tanto, un cuestionario al vendedor original. Es una evaluación interna del impacto de la modificación. Documenta el alcance de la modificación, decide si es sustancial y trata el conjunto como trabajo dentro del alcance del fabricante si la modificación toca la autenticación, el cifrado, la superficie de red o el mecanismo de actualización. Un registro limpio de qué modificación se aplicó a qué lote de unidades es el artefacto que una autoridad de vigilancia del mercado pedirá primero.

El cuestionario

Usa este cuestionario como punto de partida para proveedores comerciales de software y hardware. Las secciones anteriores cubren las variantes para FOSS, custodios de OSS, APIs en la nube, ODM solo de hardware y firmware COTS modificado.

Sección 1: información de la empresa

CUESTIONARIO DE DILIGENCIA DEBIDA DE PROVEEDORES
Sección 1: información de la empresa

1.1 Datos de la empresa
    Nombre de la empresa: _________________________
    Dirección legal: ______________________________
    País de constitución: _________________________
    Contacto principal: ___________________________
    Contacto de seguridad: ________________________

1.2 Información del negocio
    Años en el negocio: ___________________________
    Número de empleados: __________________________
    Facturación anual (rango): ____________________

1.3 Representación en la UE (si no establecido en la UE)
    Nombre y dirección del representante autorizado UE: __
    (Para el detalle completo de la cascada de RA y el
    enrutamiento al importador cuando no hay establecimiento
    en la UE, consulta la guía del clúster del importador:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certificaciones (adjuntar copias)
    [ ] ISO 9001 (Gestión de la calidad)
    [ ] ISO 27001 (Seguridad de la información)
    [ ] ISO 27701 (Privacidad)
    [ ] SOC 2
    [ ] Otro: _________________________________

Sección 2: cumplimiento del producto

Sección 2: cumplimiento del producto

2.1 Identificación del producto
    Nombre/modelo del producto: ___________________
    Versión/revisión: ____________________________
    Categoría del producto: ______________________

2.2 Clasificación CRA
    [ ] Por defecto
    [ ] Importante clase I (anexo III, parte I)
    [ ] Importante clase II (anexo III, parte II)
    [ ] Crítico (anexo IV)
    [ ] Aún no clasificado

2.3 Evaluación de la conformidad
    [ ] Módulo A (Autoevaluación)
    [ ] Módulo B+C (Examen UE de tipo)
    [ ] Módulo H (Aseguramiento de la calidad total)
    [ ] Aún no completada

    Si Módulo B, C o H:
    Nombre del organismo notificado: ______________
    Número de certificado: ________________________
    Fecha del certificado: ________________________

2.4 Declaración UE de conformidad
    [ ] DoC disponible (adjuntar copia)
    [ ] DoC aún no emitida
    Fecha de la DoC: ____________________________

2.5 Marcado CE
    [ ] Marcado CE aplicado
    [ ] Marcado CE aún no aplicado
    Si aplicado, ubicación en el producto: ________

2.6 Documentación técnica
    [ ] Expediente técnico disponible bajo solicitud
    [ ] SBOM disponible (formato: _________________)
    [ ] Documentación de evaluación de riesgos disponible
    [ ] Instrucciones de usuario/seguridad disponibles

Sección 3: prácticas de seguridad

Sección 3: prácticas de seguridad

3.1 Desarrollo seguro
    ¿Sigues un ciclo de vida de desarrollo seguro?
    [ ] Sí. Describe: ____________________________
    [ ] No

    ¿Realizas pruebas de seguridad?
    [ ] Análisis estático (SAST)
    [ ] Análisis dinámico (DAST)
    [ ] Pruebas de penetración
    [ ] Fuzzing
    [ ] Otro: _________________________________

    ¿Tienes un estándar de codificación segura?
    [ ] Sí. Cuál: ______________________________
    [ ] No

3.2 Gestión de componentes
    ¿Cómo gestionas los componentes de terceros?
    [ ] SBOM mantenido
    [ ] Herramienta de seguimiento de dependencias (nombre: _________)
    [ ] Seguimiento manual
    [ ] Sin seguimiento sistemático

    ¿Cómo monitorizas vulnerabilidades en dependencias?
    [ ] Escaneo automatizado (herramienta: _______________)
    [ ] Monitorización manual de CVE
    [ ] Confianza en notificaciones del proveedor
    [ ] Sin monitorización sistemática

3.3 Arquitectura de seguridad
    Describe las funciones de seguridad clave del producto:
    _____________________________________________

    ¿Qué estándares criptográficos se usan?
    _____________________________________________

    ¿Cómo se implementa la autenticación?
    _____________________________________________

    ¿Cómo se protegen los datos en reposo y en tránsito?
    _____________________________________________

Sección 4: gestión de vulnerabilidades

Sección 4: gestión de vulnerabilidades

4.1 Divulgación de vulnerabilidades
    ¿Tienes una política de divulgación coordinada de vulnerabilidades?
    [ ] Sí. URL: ______________________________
    [ ] No

    ¿Tienes un archivo security.txt?
    [ ] Sí. URL: ______________________________
    [ ] No

    ¿Cuál es el método de contacto de seguridad?
    [ ] Correo: _______________________________
    [ ] Formulario web: _______________________
    [ ] Plataforma de bug bounty: _____________
    [ ] Otro: _________________________________

4.2 Compromisos de respuesta
    ¿Cuál es tu plazo de acuse de recibo?
    [ ] En 24 horas
    [ ] En 72 horas
    [ ] En 7 días
    [ ] Sin compromiso

    ¿Cuál es tu plazo típico de parche para:
    Vulnerabilidades críticas: __________________
    Vulnerabilidades altas: _____________________
    Vulnerabilidades medias: ____________________

4.3 Notificación a ENISA
    ¿Estás preparado para la notificación a ENISA (septiembre de 2026)?
    [ ] Sí, proceso establecido
    [ ] En curso
    [ ] No
    [ ] No aplica (no fabricante)

4.4 Histórico de vulnerabilidades
    ¿Cuántas vulnerabilidades de seguridad se notificaron
    en este producto en los últimos 24 meses? __________

    ¿Cómo se resolvieron?
    [ ] Todas parcheadas dentro de los plazos indicados
    [ ] Con retrasos (explicar): ________________
    [ ] Algunas sin parchear (explicar): ________

Sección 5: actualizaciones y soporte

Sección 5: actualizaciones y soporte

5.1 Periodo de soporte
    ¿Cuál es el periodo de soporte comprometido desde la
    comercialización?
    [ ] 5 años (mínimo CRA)
    [ ] 7 años
    [ ] 10 años
    [ ] Otro: _________________________________
    [ ] No definido

    ¿Cuándo se comercializó este producto por primera vez en la UE?
    Fecha: _____________________________________

    ¿Cuándo termina el periodo de soporte?
    Fecha: _____________________________________

5.2 Mecanismo de actualización
    ¿Cómo se entregan las actualizaciones de seguridad?
    [ ] Actualizaciones automáticas (OTA)
    [ ] Descarga manual desde portal
    [ ] Soporte físico
    [ ] Otro: _________________________________

    ¿Las actualizaciones de seguridad están separadas de las de funcionalidad?
    [ ] Sí
    [ ] No, agrupadas juntas

    ¿Pueden los usuarios diferir u omitir actualizaciones?
    [ ] Sí
    [ ] No, obligatorias
    [ ] Configurable

5.3 Verificación de actualizaciones
    ¿Las actualizaciones están firmadas?
    [ ] Sí. Método: ___________________________
    [ ] No

    ¿Pueden los usuarios verificar la autenticidad de las actualizaciones?
    [ ] Sí. Cómo: _____________________________
    [ ] No

5.4 Planificación de fin de soporte
    ¿Tienes un proceso de EOL documentado?
    [ ] Sí
    [ ] No

    ¿Cómo se notificará el EOL a los clientes?
    _____________________________________________

    ¿Qué sucede cuando termina el periodo de soporte?
    [ ] El producto sigue funcionando
    [ ] El producto pierde funcionalidad
    [ ] El producto exige migración

Sección 6: requisitos de documentación

Sección 6: requisitos de documentación

6.1 Documentación disponible
    Marca toda la documentación que puedes proporcionar:

    [ ] Declaración UE de conformidad
    [ ] Expediente técnico (o extractos relevantes)
    [ ] Software Bill of Materials (SBOM)
        Formato: [ ] CycloneDX [ ] SPDX [ ] Otro
    [ ] Resumen de evaluación de riesgos
    [ ] Documento de arquitectura de seguridad
    [ ] Instrucciones de usuario (relevantes para seguridad)
    [ ] Política de divulgación de vulnerabilidades
    [ ] Términos de soporte/mantenimiento

6.2 Entrega de documentación
    ¿Cómo se entregará la documentación?
    [ ] Bajo solicitud (tiempo de respuesta: ____________)
    [ ] Vía portal seguro
    [ ] Junto con el producto
    [ ] Otro: _________________________________

6.3 Detalles del SBOM (si está disponible)
    El SBOM cubre:
    [ ] Solo dependencias directas
    [ ] Dependencias transitivas incluidas
    [ ] Componentes de hardware (si aplica)

    Frecuencia de actualización del SBOM:
    [ ] Por release
    [ ] Bajo solicitud
    [ ] Sin actualización sistemática

Sección 7: compromisos contractuales

Sección 7: compromisos contractuales

7.1 Garantía de cumplimiento
    ¿Garantizarás el cumplimiento del CRA en el contrato?
    [ ] Sí
    [ ] No
    [ ] Negociable

7.2 Retención de documentación
    ¿Retendrás la documentación técnica durante 10 años?
    [ ] Sí
    [ ] No
    [ ] Periodo más corto: ____________________

7.3 Obligaciones de notificación
    ¿Nos notificarás de:
    [ ] Vulnerabilidades de seguridad en el producto
    [ ] Cambios en el estado de conformidad
    [ ] Decisiones de fin de soporte
    [ ] Cambios materiales en la arquitectura de seguridad

7.4 Derechos de auditoría
    ¿Permitirás auditorías de cumplimiento?
    [ ] Sí, sin restricciones
    [ ] Sí, con aviso
    [ ] No

7.5 Indemnización
    ¿Indemnizarás por incumplimiento del CRA?
    [ ] Sí
    [ ] No
    [ ] Negociable

Sección 8: atestación

Sección 8: atestación

Declaro que la información facilitada en este cuestionario
es exacta y completa según mi leal saber y entender.

Entiendo que [Tu empresa] se basa en esta información
a efectos de cumplimiento del CRA y que las declaraciones
materialmente falsas pueden conllevar la terminación del contrato.

Cumplimentado por: _________________________________
Cargo: ___________________________________________
Fecha: ____________________________________________
Firma: ___________________________________________

Alertas (señales precontractuales)

Estas alertas son señales para detectar durante la revisión del cuestionario y la negociación del contrato, antes de firmar cualquier orden de compra. Para el espejo del lado del importador, aplicado al introducir en la UE el producto de un fabricante no establecido en la UE, consulta qué rechazar y por qué en la página del clúster del importador.

Alertas críticas (descartar la relación)

Alertas serias (requieren mitigación negociada)

Alertas amarillas (monitorizar durante la relación)

Proceso de verificación y monitorización

Verificación inicial

1. Recogida de documentos

   • Solicitar copia de la DoC
   • Solicitar SBOM (o confirmación de disponibilidad)
   • Solicitar información de contacto de seguridad
   • Solicitar compromiso de periodo de soporte

2. Revisión documental

   • Verificar que la DoC está firmada y completa
   • Comprobar que la identificación del producto coincide
   • Verificar las declaraciones de marcado CE
   • Revisar el formato y la completitud del SBOM

3. Comprobaciones puntuales de cumplimiento

   • Verificar que existe security.txt (si es accesible por web)
   • Comprobar que la política CVD está publicada
   • Probar que el contacto de seguridad responde
   • Verificar las declaraciones de periodo de soporte en la documentación

Monitorización continua

PROGRAMA DE MONITORIZACIÓN DE PROVEEDORES

Mensual:
[ ] Comprobar avisos de seguridad publicados
[ ] Verificar que el contacto de seguridad sigue operativo
[ ] Revisar cualquier divulgación de vulnerabilidad

Trimestral:
[ ] Solicitar SBOM actualizado (si hay releases significativos)
[ ] Verificar que la política CVD sigue accesible
[ ] Comprobar nuevas certificaciones o caducidades

Anual:
[ ] Refresco completo del cuestionario
[ ] Revisar el estado del periodo de soporte
[ ] Verificar que la documentación sigue disponible
[ ] Revisión de estabilidad del negocio

Por disparador:
[ ] Incidente de seguridad mayor → revisión inmediata
[ ] Cambio de propiedad → reevaluación completa
[ ] Discontinuación del producto → planificación EOL
[ ] Renovación de contrato → reverificación de cumplimiento

Cuando un proveedor no responde

El fallo operativo más común en la diligencia de proveedores no es una respuesta fallida al cuestionario, es la ausencia de cualquier respuesta. El proveedor ignora la solicitud, da largas durante meses o envía un "cumplimos con toda la normativa aplicable" de una línea. No hay sanción legal contra el proveedor (no tiene un deber CRA de contestar tu cuestionario), así que el flujo de escalado tiene que ser comercial y procedimental.

ESCALADO POR FALTA DE RESPUESTA DEL PROVEEDOR

SEMANA 1: cuestionario inicial enviado.
        Ventana razonable de respuesta: 15 días hábiles
        para Nivel 1, 30 días hábiles para Nivel 2,
        45 para Nivel 3-4.

SEMANA 3: primer recordatorio al contacto de seguridad
        nombrado y al contacto comercial principal.
        Con copia al responsable de compras.

SEMANA 5: escalado al account executive del proveedor y
        a tu director de compras. Fecha límite cerrada.

SEMANA 7: si sigue sin haber respuesta sustantiva:
        a) Documentar la falta de respuesta en el expediente del proveedor
        b) Marcar el componente como "cumplimiento no verificado"
        c) Iniciar la evaluación de proveedor de reemplazo
        d) Notificar a los responsables de producto que dependen del componente

SEMANA 9: punto de decisión.
        Respuesta sustantiva recibida → pasar a revisión.
        Sin respuesta → cambiar de proveedor y
        documentar el cambio como decisión motivada por el CRA.

La falta de respuesta es, en sí misma, prueba de diligencia. Una autoridad de vigilancia del mercado que pregunte por qué discontinuaste a un proveedor aceptará mucho mejor un rastro documentado de escalado y una decisión de cambio que un vago "eran difíciles de tratar". El artefacto que conservas es el log fechado de escalado más el memorándum de decisión.

Componentes compartidos aguas arriba y vetting coordinado

Cuando varios fabricantes integran el mismo componente aguas arriba (una librería de criptografía muy usada, un SDK común de procesamiento de imágenes, un sistema operativo embebido popular), cada fabricante aguas abajo carga con su propio deber del artículo 13, apartado 5. El deber no se transfiere al par más diligente, y "todo el mundo lo usa" no es una defensa.

Hay dos patrones de coordinación que reducen el trabajo duplicado sin descargar el deber:

El registro de diligencia debe nombrar la fuente del vetting compartido de forma explícita: "informe de revisión de [grupo de trabajo], con fecha [X], revisado y aceptado el [Y], huecos rastreados en [sistema]". Un copia-pega del expediente de diligencia de un par no sustituye tu propio registro de decisión.

Tras una fusión o adquisición: relaciones de proveedor heredadas

Cuando tu empresa adquiere otra, también adquiere su lista de proveedores. Una realidad posterior común a las fusiones y adquisiciones son decenas o cientos de relaciones de proveedor sin registro alguno de diligencia con forma CRA. El trabajo no puede hacerse de la noche a la mañana, pero un triaje es realizable en un trimestre.

TRIAJE DE PROVEEDORES POST-M&A (90 DÍAS)

DÍA 1-15: inventario
[ ] Extraer la lista de proveedores del ERP / sistema de compras de la entidad adquirida
[ ] Cruzar con las BOM actuales de producto
[ ] Identificar qué proveedores alimentan productos en alcance CRA
[ ] Sacar a los proveedores fuera de alcance del triaje activo

DÍA 15-30: clasificación por niveles
[ ] Aplicar tu modelo de niveles a la lista heredada
[ ] Etiquetar a los proveedores sin registro de diligencia existente
[ ] Marcar a los proveedores cuyos productos caen en clase II importante o crítico

DÍA 30-60: cuestionarios de Nivel 1
[ ] Enviar el cuestionario a todo proveedor de Nivel 1 sin registro
[ ] Reemitir a todo proveedor de Nivel 1 cuyo registro supere los 24 meses
[ ] Capturar las respuestas de forma centralizada

DÍA 60-90: punto de decisión
[ ] Proveedores de Nivel 1 con respuestas válidas → integrados
[ ] Proveedores de Nivel 1 con alertas → plan de mitigación o reemplazo
[ ] Proveedores de Nivel 2 y 3 → programar en el ciclo anual estándar

CONTINUO:
[ ] Incorporar los proveedores heredados al programa normal de monitorización
[ ] Etiquetar el origen "adquirido vía M&A" en el registro del proveedor a efectos de auditoría

El CRA no concede un periodo de gracia por M&A; la entidad adquirente hereda la obligación de fabricante en la fecha en que cierra la adquisición, sobre los componentes presentes en el producto que se está enviando. El triaje anterior es el compromiso práctico: demostrar que hay un programa de diligencia defendible en marcha, aunque el registro completo se esté reconstruyendo.

Visibilidad de la subcontratación en cadenas de varios niveles

Tu proveedor de Nivel 1 puede a su vez subcontratar a un proveedor de Nivel 2, que integra componentes de un upstream de Nivel 3. El deber CRA es tuyo con independencia del punto de la cadena en el que se origine la vulnerabilidad. La visibilidad práctica, sin embargo, se agota rápido más allá del Nivel 1.

Tres controles concretos que compran visibilidad real en varios niveles:

• Cláusula de SBOM transitivo. El contrato exige que el SBOM del proveedor incluya las dependencias transitivas, no solo las directas. Un SBOM solo directo oculta casi toda la superficie de riesgo real.
• Lista de subprocesadores y subcontratistas. El contrato exige al proveedor que comunique y actualice la lista de subcontratistas nombrados que tocan partes relevantes para la seguridad del componente. La cláusula no te da derecho de veto, pero te da visibilidad.
• Pase de vulnerabilidades. El contrato exige al proveedor que haga circular hacia ti las vulnerabilidades detectadas en componentes integrados de forma transitiva con el mismo plazo que las vulnerabilidades en código desarrollado directamente.

Sin un SBOM transitivo, no puedes ejecutar escaneos del árbol de dependencias contra el componente, y no puedes demostrar a una autoridad de vigilancia del mercado que se evaluó el riesgo en cadenas de varios niveles. Sin lista de subprocesadores, un cambio aguas arriba de subcontratista (con su propia procedencia, sus controles y su bus-factor) te resulta invisible. Sin pase de vulnerabilidades, el silencio del proveedor de Nivel 1 sobre un problema en Nivel 2 se convierte en tu silencio sobre un incidente de seguridad.

Cláusulas del acuerdo con el proveedor

Incluye estas disposiciones en los contratos con proveedores. Cada cláusula es el anclaje contractual para uno de los resultados de diligencia anteriores.

Representación de cumplimiento:

El Proveedor declara y garantiza que el/los Producto(s)
cumplen con el Reglamento (UE) 2024/2847 (Reglamento de
Ciberresiliencia) y que el Proveedor ha completado la
evaluación de la conformidad requerida.

Entrega de documentación:

El Proveedor entregará, bajo solicitud:
(a) Copia de la Declaración UE de Conformidad
(b) Software Bill of Materials en formato [CycloneDX/SPDX],
    incluyendo dependencias transitivas
(c) Documentación técnica relevante para las obligaciones
    de cumplimiento del Comprador
Tiempo de respuesta: [5 días hábiles]

Notificación de vulnerabilidades:

El Proveedor notificará al Comprador, en [24/48] horas
desde que tenga conocimiento, cualquier vulnerabilidad
de seguridad en el/los Producto(s) o en cualquier
componente integrado de forma transitiva que:
(a) Esté siendo explotada activamente, o
(b) Tenga puntuación CVSS de 7,0 o superior, o
(c) Esté sujeta a divulgación pública

Compromiso de periodo de soporte:

El Proveedor se compromete a proporcionar actualizaciones
de seguridad para el/los Producto(s) durante un periodo
mínimo de [5/7/10] años desde la fecha de primera
comercialización en la UE.

Actualizaciones de SBOM:

El Proveedor entregará un SBOM actualizado en [10] días
hábiles desde cada release del producto que incluya
cambios en componentes de terceros directos o transitivos.

Derechos de auditoría:

El Comprador podrá auditar el cumplimiento del Proveedor
con este Acuerdo y con los requisitos CRA aplicables con
[30 días] de aviso por escrito, no más de una vez al año
salvo que lo desencadene una preocupación de cumplimiento.

Comunicación de subcontratistas:

El Proveedor mantendrá y entregará, bajo solicitud, una
lista de subcontratistas que contribuyen a o tienen acceso
a componentes relevantes para la seguridad del/de los
Producto(s). El Proveedor notificará al Comprador cualquier
cambio material en esa lista en [30] días.

Errores comunes

Confiar en la autoatestación

Problema: aceptar garantías verbales del proveedor sin documentación.

Solución: obtén siempre prueba escrita. Sin copia de la DoC, no hay compra. Un cuestionario firmado es el suelo, no el techo.

Evaluación puntual

Problema: diligencia debida solo al firmar el contrato.

Solución: implanta el programa de monitorización anterior. El estado de cumplimiento cambia; los cuestionarios caducan.

Ignorar los proveedores de Nivel 3-4

Problema: evaluar solo a los proveedores "principales" e ignorar a los pequeños.

Solución: incluso los componentes menores introducen vulnerabilidades (la lección de log4j). Escala la evaluación; no saltes de nivel.

Sin respaldo contractual

Problema: confiar en la buena voluntad del proveedor sin términos contractuales.

Solución: pon por escrito las obligaciones de cumplimiento. Las cláusulas anteriores son el suelo.

Esperar a diciembre de 2027

Problema: comenzar las evaluaciones de proveedores justo antes de la fecha de aplicación del CRA.

Solución: empieza ya. Las respuestas de los proveedores tardan. Los proveedores no conformes necesitan meses para remediar o ser reemplazados.

Lista de comprobación de diligencia debida de proveedores

LISTA DE COMPROBACIÓN DE DILIGENCIA DEBIDA DE PROVEEDORES

PRE-CONTRATACIÓN:
[ ] Nivel del proveedor determinado (1/2/3/4)
[ ] Tipo de proveedor determinado (comercial, FOSS, custodio OSS,
    nube, solo hardware, COTS modificado)
[ ] Variante de cuestionario adecuada seleccionada
[ ] Revisor interno asignado

EVALUACIÓN INICIAL:
[ ] Cuestionario enviado
[ ] Cuestionario recibido y revisado
[ ] Alertas identificadas y abordadas
[ ] Documentación recogida:
    [ ] Declaración UE de conformidad (o motivo de no aplicación)
    [ ] SBOM con dependencias transitivas (o disponibilidad confirmada)
    [ ] Política CVD
    [ ] Compromiso de periodo de soporte
[ ] Comprobaciones puntuales completadas:
    [ ] security.txt verificado
    [ ] Contacto de seguridad probado
    [ ] Marcado CE verificado

NEGOCIACIÓN DEL CONTRATO:
[ ] Cláusulas de cumplimiento incluidas
[ ] Disposiciones de documentación acordadas
[ ] Términos de notificación de vulnerabilidades fijados (horas, no "sin demora")
[ ] Compromiso de periodo de soporte asegurado
[ ] Derechos de auditoría incluidos
[ ] Programa de actualización del SBOM acordado
[ ] Cláusula de comunicación de subcontratistas incluida

POST-CONTRATO:
[ ] Programa de monitorización establecido
[ ] Primera entrega de documentación confirmada
[ ] Contactos registrados en el sistema de gestión de proveedores
[ ] Fechas de revisión en calendario

CONTINUO:
[ ] Comprobaciones mensuales completadas
[ ] Revisiones trimestrales completadas
[ ] Reevaluación anual completada
[ ] Eventos disparadores gestionados (incidente, cambio de propiedad, EOL)

Guías relacionadas

• Cómo generar un SBOM conforme con el CRA: herramientas, formatos e integración CI/CD
• La guía del fabricante CRA
• Lista de comprobación del distribuidor CRA

Este artículo tiene fines exclusivamente informativos y no constituye asesoramiento jurídico. Para orientación específica de cumplimiento, consulta con asesores legales cualificados.