El perímetro de seguridad de una organización ya no coincide con sus paredes ni con su red corporativa. Cada proveedor de software, cada servicio en la nube, cada subcontratista con acceso a un sistema o a un dato personal es, de facto, una extensión de esa superficie de ataque. Y la evidencia de los últimos años es contundente: los incidentes más devastadores no han entrado por la puerta principal de la víctima, sino por la puerta trasera de un proveedor de confianza. SolarWinds, Log4Shell, Kaseya y el backdoor de xz/liblzma no son anécdotas técnicas aisladas: son la demostración de que comprometer a un proveedor puede comprometer a miles de sus clientes de una sola vez, con un retorno de la inversión para el atacante muy superior al de atacar organización por organización. Este módulo cubre el ciclo de vida completo de la gestión del riesgo de terceros —desde la due diligence antes de firmar hasta el offboarding seguro al terminar la relación—, los marcos de referencia (ISO/IEC 27036, los controles 5.19 a 5.23 de ISO/IEC 27002:2022) y las obligaciones que NIS2, DORA y el RGPD imponen sobre esta materia en España y la Unión Europea.
Qué aprenderás
- Por qué el riesgo de terceros se ha convertido en una prioridad de primer nivel para cualquier programa de GRC, con datos de incidentes reales que lo demuestran.
- Los distintos tipos de terceros —proveedores TIC, servicios en la nube (SaaS/PaaS/IaaS), subcontratistas, encargados del tratamiento del RGPD— y por qué el tratamiento de riesgo no es el mismo para todos.
- El ciclo de vida completo de gestión del riesgo de proveedores en sus seis fases: due diligence, clasificación por criticidad, cláusulas contractuales, onboarding, monitorización continua y offboarding.
- Qué cláusulas de seguridad son imprescindibles en cualquier contrato con un proveedor que acceda a sistemas o datos.
- ISO/IEC 27036 y los controles 5.19 a 5.23 de ISO/IEC 27002:2022, y cómo se traducen en la práctica diaria de un equipo de seguridad.
- Los ataques a la cadena de suministro de software más relevantes de la última década —SolarWinds, Log4Shell, Kaseya, xz/liblzma— y las técnicas de mitigación (SBOM, verificación de integridad, gestión de dependencias, mínima confianza).
- Cómo NIS2 (artículo 21), DORA y el RGPD (artículo 28) regulan de forma explícita el riesgo de terceros y qué exigen a las organizaciones.
- Cómo diseñar un cuestionario de evaluación de seguridad para un proveedor SaaS que trata datos personales.
Por qué el riesgo de terceros es hoy una prioridad crítica
Durante años, la gestión de riesgos de seguridad se centró casi en exclusiva en el perímetro propio: firewalls, EDR, gestión de vulnerabilidades internas, concienciación del personal. Ese enfoque sigue siendo necesario, pero ya no es suficiente, por tres razones estructurales que se han acelerado en la última década.
La primera es la externalización masiva de funciones TIC. Ninguna organización mediana o grande aloja hoy toda su infraestructura, desarrolla todo su software desde cero o gestiona internamente todos sus procesos de negocio. Se contratan proveedores cloud para la infraestructura, SaaS para aplicaciones críticas (CRM, RRHH, facturación), subcontratistas para el desarrollo o el soporte, y encargados del tratamiento para procesar datos personales de clientes o empleados. Cada uno de esos contratos abre una vía de acceso a información o sistemas que antes solo tocaba personal propio.
La segunda es que el software moderno es, en esencia, una cadena de dependencias. Una aplicación típica no se escribe desde cero: se ensambla a partir de decenas o cientos de librerías de terceros, muchas de ellas de código abierto y mantenidas por un puñado de voluntarios sin respaldo corporativo. Un fallo o una puerta trasera introducida en una sola de esas librerías —como ocurrió con Log4j o con xz/liblzma, casos que se explican en detalle más adelante— se propaga automáticamente a todo el software que la incorpora, sin que el desarrollador final sepa siquiera que la está usando.
La tercera razón, la más relevante desde la perspectiva del atacante, es puramente económica: comprometer un proveedor tiene un retorno de la inversión muy superior a comprometer una víctima final. Si un atacante logra insertar código malicioso en la actualización de un producto ampliamente usado, o comprometer las credenciales de un proveedor de gestión remota como Kaseya, obtiene acceso simultáneo a todos los clientes de ese proveedor con un solo esfuerzo de intrusión. Es la lógica de un ataque «uno a muchos» frente al tradicional «uno a uno», y explica por qué los grupos de amenaza persistente avanzada (APT) y las bandas de ransomware han incorporado la cadena de suministro como vector de entrada preferente.
El resultado es que un programa de GRC que no incluya una gestión formal del riesgo de terceros tiene, por definición, un perímetro de seguridad incompleto: puede tener controles internos ejemplares y seguir siendo vulnerable a través de la puerta que abrió el proveedor menos vigilado.
Tipos de terceros y por qué el riesgo no es homogéneo
No todos los terceros representan el mismo tipo ni el mismo nivel de riesgo, y agruparlos bajo una única política sería un error de diseño. Conviene distinguir al menos cuatro categorías, que a menudo se solapan en un mismo proveedor:
Proveedores TIC tradicionales
Empresas que suministran hardware, software a medida, desarrollo, integración de sistemas o soporte técnico. Su riesgo depende del nivel de acceso que tengan a la red o a los sistemas de la organización: no es lo mismo un proveedor que instala impresoras que uno con acceso VPN permanente a la infraestructura de producción.
Servicios en la nube: SaaS, PaaS e IaaS
La computación en la nube introduce un matiz importante que conviene tener siempre presente: el modelo de responsabilidad compartida. En IaaS (infraestructura como servicio, por ejemplo AWS EC2 o Azure VMs), el proveedor asegura el centro de datos, la red física y la virtualización, pero el cliente es responsable del sistema operativo, las aplicaciones y los datos. En PaaS (plataforma como servicio) el proveedor añade la gestión del entorno de ejecución. En SaaS (software como servicio, por ejemplo un CRM o una herramienta de RRHH en la nube) el proveedor gestiona casi todo el stack, pero el cliente sigue siendo responsable de la configuración de seguridad, la gestión de accesos y, sobre todo, de la clasificación y protección de los datos que introduce en la aplicación. Confundir «está en la nube» con «ya no es mi responsabilidad» es uno de los errores de gobierno más caros que puede cometer una organización.
Subcontratistas y proveedores de servicios de negocio
Empresas de limpieza con acceso físico a oficinas, centros de atención al cliente externalizados, consultoras con acceso temporal a sistemas para un proyecto concreto. Su riesgo suele subestimarse porque no «parecen» tecnológicos, pero el acceso físico o las credenciales temporales mal gestionadas son un vector de intrusión clásico.
Encargados del tratamiento en el sentido del RGPD
Esta es una categoría jurídica específica y de enorme relevancia práctica. El artículo 4.8 del Reglamento (UE) 2016/679 (RGPD) define al encargado del tratamiento como la persona física o jurídica que trata datos personales por cuenta del responsable del tratamiento. Cualquier proveedor que procese datos personales de la organización —una gestoría, un proveedor de email marketing, un SaaS de RRHH, un centro de datos que aloja una base de clientes— actúa como encargado del tratamiento, y esa relación está sujeta a una obligación contractual específica y no negociable: el contrato de encargado del tratamiento del artículo 28 del RGPD, que se trata con detalle en el Módulo 10 de este curso sobre RGPD y protección de datos y que retomamos más adelante en la sección de regulación.
El ciclo de vida de gestión del riesgo de proveedores
Gestionar el riesgo de terceros no es una tarea puntual que se resuelve en la fase de contratación: es un ciclo continuo con seis fases diferenciadas. Tratarlo como un trámite de compras que termina con la firma del contrato es, de hecho, uno de los errores más comunes y más caros, como se detalla en la sección de errores de este módulo.
Fase 1: Due diligence — evaluación previa a la contratación
Antes de firmar cualquier contrato que implique acceso a datos o sistemas, la organización debe evaluar la postura de seguridad del proveedor candidato. Esta due diligence incluye, como mínimo: revisar si el proveedor cuenta con certificaciones relevantes (ISO/IEC 27001, ENS, SOC 2), solicitar evidencias de su programa de seguridad (políticas, resultados de auditorías, informes de pentest recientes), verificar su historial de incidentes públicos, y —cuando el proveedor vaya a tratar datos personales— confirmar que ofrece garantías suficientes conforme al artículo 28.1 del RGPD para cumplir los requisitos del reglamento y proteger los derechos de los interesados.
La profundidad de esta evaluación debe ser proporcional al riesgo esperado: no tiene sentido exigir el mismo nivel de evidencias a un proveedor de material de oficina que a uno que va a alojar la base de datos de clientes. Esto conecta directamente con la fase siguiente.
Fase 2: Clasificación por criticidad
Cada proveedor debe clasificarse en un nivel de criticidad en función de dos variables: el acceso que tiene a datos y sistemas, y el impacto que tendría un fallo o compromiso de ese proveedor sobre la organización. Esta clasificación determina el nivel de escrutinio, la frecuencia de revisión y las cláusulas contractuales exigibles.
| Nivel de criticidad | Criterios típicos | Ejemplos | Tratamiento exigido |
|---|---|---|---|
| Crítico | Acceso a datos personales sensibles o a gran volumen de datos; acceso privilegiado a sistemas de producción; sin alternativa viable a corto plazo (dependencia estructural); un fallo del proveedor detiene la operación de negocio. | Proveedor cloud que aloja toda la infraestructura; procesador de pagos; SaaS de RRHH con datos de toda la plantilla; proveedor TIC con acceso administrativo a la red. | Due diligence exhaustiva, auditoría previa, cláusulas contractuales completas, revisión anual con evidencias, plan de contingencia y salida documentado, comité de aprobación. |
| Alto | Acceso a datos personales no sensibles en volumen relevante o a sistemas no críticos; impacto significativo pero no paralizante ante un fallo. | Herramienta de email marketing con base de clientes; proveedor de soporte con acceso a tickets; gestoría con datos de nóminas. | Cuestionario de seguridad detallado, cláusulas contractuales estándar reforzadas, revisión periódica (12-18 meses), verificación de certificaciones. |
| Medio | Acceso limitado a información no sensible; impacto moderado y acotado a un proceso concreto. | Herramienta de gestión de proyectos sin datos personales relevantes; proveedor de formación online. | Cuestionario simplificado, cláusulas contractuales estándar, revisión cada 2-3 años o ante cambio relevante del servicio. |
| Bajo | Sin acceso a datos ni sistemas, o acceso puramente físico y puntual sin conectividad a la red corporativa. | Proveedor de material de oficina; servicio de mensajería; catering. | Cláusulas de confidencialidad básicas; sin necesidad de evaluación técnica formal. |
Fase 3: Cláusulas contractuales de seguridad
El contrato es, con frecuencia, la única palanca real que tiene la organización para exigir un comportamiento de seguridad al proveedor una vez iniciada la relación. Un contrato sin cláusulas de seguridad específicas deja a la organización sin base legal para auditar, sin plazo exigible de notificación ante un incidente y sin garantía sobre qué pasa con sus datos si la relación termina. La tabla siguiente recoge las cláusulas que ningún contrato con un proveedor de criticidad media, alta o crítica debería omitir.
| Cláusula | Qué debe garantizar | Por qué es imprescindible |
|---|---|---|
| Derecho de auditoría | La organización (o un tercero independiente en su nombre) puede auditar, con preaviso razonable, los controles de seguridad del proveedor, o exigir informes de auditoría equivalentes (SOC 2 Tipo II, certificado ISO 27001). | Sin esta cláusula, la organización depende exclusivamente de lo que el proveedor decida contarle. Es también un requisito explícito del artículo 28.3.h) del RGPD para los encargados del tratamiento. |
| Notificación de incidentes en plazo determinado | Obligación del proveedor de notificar cualquier incidente de seguridad que afecte a los datos o sistemas de la organización en un plazo concreto (por ejemplo, 24-72 horas desde su detección), no «sin demora indebida» sin más precisión. | El responsable del tratamiento tiene, a su vez, un plazo de 72 horas para notificar brechas a la AEPD (artículo 33 RGPD). Si el encargado tarda en avisar, el responsable puede incumplir su propio plazo sin margen de reacción. |
| SLA de seguridad | Compromisos medibles: tiempos de aplicación de parches críticos, disponibilidad del servicio, tiempos de respuesta y recuperación (RTO/RPO) ante incidente. | Convierte expectativas vagas («mantendremos el servicio seguro») en obligaciones exigibles y con consecuencias contractuales si se incumplen. |
| Requisitos de subcontratación (subencargados) | El proveedor no puede subcontratar el tratamiento a un tercero (un «subencargado» o «cuarta parte») sin autorización previa, general o específica, e informando de cualquier cambio. | Exigencia directa del artículo 28.2 del RGPD. Sin ella, la cadena de responsabilidad se rompe: la organización puede acabar dependiendo de un subproveedor que nunca evaluó ni conoce. |
| Cifrado de datos | Cifrado de los datos en tránsito y en reposo, con estándares y gestión de claves especificados (no solo «usamos cifrado», sino qué algoritmo y quién controla las claves). | Reduce drásticamente el impacto de una brecha en el proveedor: datos cifrados correctamente suelen quedar fuera del ámbito de notificación obligatoria si las claves no se han comprometido. |
| Devolución y borrado de datos al finalizar | Al terminar el contrato, el proveedor debe devolver o eliminar de forma verificable todos los datos y copias, según decida el cliente, salvo obligación legal de conservación. | Exigencia expresa del artículo 28.3.g) del RGPD. Sin ella, los datos personales pueden seguir «vivos» en sistemas de un proveedor con el que ya no existe relación ni supervisión. |
| Cumplimiento normativo | Compromiso expreso del proveedor de cumplir la normativa aplicable (RGPD, NIS2 si corresponde, ENS si el cliente es sujeto obligado) y de facilitar la documentación necesaria para que el cliente demuestre su propio cumplimiento. | El responsable del tratamiento y las entidades sujetas a NIS2 no pueden trasladar su responsabilidad legal al proveedor; necesitan que el proveedor colabore activamente para poder demostrar diligencia debida. |
Fase 4: Onboarding
Una vez firmado el contrato, el onboarding formaliza el alta operativa del proveedor: se provisionan los accesos estrictamente necesarios (principio de mínimo privilegio), se documenta el proveedor en el inventario o registro de terceros de la organización —un registro que, como se ve más adelante, es una obligación explícita bajo DORA para el sector financiero—, se define el propietario interno de la relación (quién es responsable de vigilar a ese proveedor) y se comunican los procedimientos de contacto ante incidente.
Fase 5: Monitorización continua
La seguridad de un proveedor no es estática: cambia con el tiempo, con nuevas amenazas, con cambios en su propia infraestructura o en su cadena de subcontratación. La monitorización continua incluye varios mecanismos complementarios:
- Cuestionarios de seguridad periódicos, con frecuencia proporcional a la criticidad del proveedor (anual para los críticos, cada 2-3 años para los de criticidad media).
- Solicitud de evidencias actualizadas: informes de pentest recientes, resultados de auditorías internas, planes de acción sobre hallazgos previos.
- Verificación de certificaciones vigentes: comprobar que el certificado ISO/IEC 27001, la certificación del Esquema Nacional de Seguridad (ENS) o el informe SOC 2 del proveedor no ha caducado ni ha sido revocado, y revisar el alcance exacto que cubre —una certificación ISO 27001 «de la empresa» no siempre cubre el servicio concreto que se está contratando.
- Security ratings: servicios de calificación continua de la postura de seguridad externa de un proveedor (basados en señales como configuración DNS, certificados TLS, exposición de puertos, presencia en brechas conocidas), que ofrecen una señal de alerta temprana entre evaluaciones formales, similar a un rating crediticio pero de ciberseguridad.
- Revisión ante cambios relevantes: fusión o adquisición del proveedor, cambio de subencargados, incidente de seguridad público, cambio sustancial en el servicio contratado.
Fase 6: Offboarding seguro
Cuando la relación termina —por decisión propia, por fin de contrato o por sustitución del proveedor—, el offboarding debe revocar de forma verificable todos los accesos concedidos (cuentas, VPN, API keys, integraciones), exigir la devolución o el borrado certificado de los datos conforme a la cláusula contractual correspondiente, y actualizar el inventario de terceros. Un proveedor «dado de baja» en la práctica de negocio pero con credenciales activas en los sistemas es una de las formas más habituales, y más silenciosas, en que una organización acumula riesgo residual sin darse cuenta.
Marcos y controles: ISO/IEC 27036 e ISO/IEC 27002:2022
ISO/IEC 27036: la norma específica de seguridad en las relaciones con proveedores
ISO/IEC 27036, Cybersecurity — Supplier relationships, es la norma de referencia dedicada en exclusiva a este ámbito, estructurada en cuatro partes:
- Parte 1 (Overview and concepts): introduce los conceptos y el marco general que desarrollan las partes siguientes; su versión vigente es de 2021.
- Parte 2 (Requirements): establece los requisitos genéricos para definir, implementar, gestionar, monitorizar, revisar y mejorar las relaciones de seguridad entre adquirente y proveedor, aplicables a cualquier relación de suministro de bienes o servicios.
- Parte 3 (Guidelines for ICT supply chain security): proporciona directrices específicas para gestionar el riesgo de seguridad en cadenas de suministro TIC físicamente dispersas y con múltiples capas de subcontratación, precisamente el escenario descrito en la sección de casos reales de software de este módulo.
- Parte 4 (Guidelines for security of cloud services): orienta tanto a proveedores como a clientes de servicios en la nube sobre la gestión del riesgo de seguridad específico de ese modelo.
Los controles de ISO/IEC 27002:2022 sobre proveedores y nube (5.19 a 5.23)
Quien haya seguido el Módulo 6 de este curso sobre los 93 controles de ISO/IEC 27002:2022 reconocerá que cinco de esos controles, dentro del tema Organizacional, están dedicados en exclusiva a este ámbito. Merece la pena repasarlos aquí con el contexto específico de la gestión de terceros:
| Control | Nombre | Qué exige en esencia |
|---|---|---|
| 5.19 | Información de seguridad en las relaciones con proveedores | Define e implementa procesos y procedimientos para gestionar los riesgos de seguridad asociados al uso de productos y servicios de proveedores. Es el control «paraguas» que da pie a los cuatro siguientes. |
| 5.20 | Tratamiento de la seguridad de la información en los acuerdos con proveedores | Establece y acuerda con cada proveedor los requisitos de seguridad de la información relevantes, en función del tipo de relación: es la base normativa de la tabla de cláusulas contractuales de este módulo. |
| 5.21 | Gestión de la seguridad de la información en la cadena de suministro TIC | Exige procesos para gestionar los riesgos de seguridad asociados a la cadena de suministro de productos y servicios TIC, incluyendo la propagación del riesgo a través de subproveedores. |
| 5.22 | Monitorización, revisión y gestión de cambios de los servicios de proveedores | Requiere revisar, monitorizar, evaluar y gestionar de forma regular los cambios en las prácticas de seguridad y en la prestación del servicio de los proveedores: es el control que sustenta la fase de monitorización continua. |
| 5.23 | Seguridad de la información para el uso de servicios en la nube | Control íntegramente nuevo en la edición 2022 (no existía en 2013). Establece procesos de adquisición, uso, gestión y salida de servicios en la nube conforme a los requisitos de seguridad de la organización, reconociendo el modelo de responsabilidad compartida descrito antes. |
El riesgo de la cadena de suministro de software: casos reales y mitigación
Ningún argumento sobre el riesgo de terceros es tan persuasivo como la evidencia empírica. Los cuatro casos siguientes, ocurridos entre 2020 y 2024, ilustran variantes distintas del mismo problema estructural: la confianza implícita que se deposita en el software de terceros y en sus procesos de actualización.
| Caso | Año | Qué ocurrió | Vector |
|---|---|---|---|
| SolarWinds / Sunburst | 2020 (descubierto en diciembre, tras una intrusión iniciada en 2019) | Atacantes vinculados a un actor estatal comprometieron el proceso de compilación de SolarWinds e insertaron una puerta trasera (Sunburst) en actualizaciones legítimas y firmadas digitalmente del software de monitorización Orion. Unos 18.000 clientes instalaron la versión troyanizada, entre ellos agencias del gobierno de EE. UU. y empresas del Fortune 500. El caso fue descubierto por FireEye al investigar una intrusión en su propia red. | Compromiso del proceso de build/actualización de un proveedor de software (ataque «upstream»). |
| Log4Shell (Log4j) | 2021 (divulgada el 9-10 de diciembre) | Vulnerabilidad crítica (CVE-2021-44228, CVSS 10.0) en Log4j, la librería de registro (logging) de Java más usada del mundo, presente como dependencia transitiva en un número prácticamente incalculable de aplicaciones empresariales. Permitía ejecución remota de código con una simple cadena de texto. El impacto fue masivo precisamente porque muy pocas organizaciones sabían que usaban Log4j: la habían heredado como dependencia de otra dependencia. | Vulnerabilidad crítica en una dependencia de código abierto ampliamente reutilizada. |
| Kaseya VSA | 2021 (2 de julio) | El grupo de ransomware REvil explotó una vulnerabilidad de inyección SQL en Kaseya VSA, software de gestión remota usado por proveedores de servicios gestionados (MSP), y distribuyó ransomware a través de él a los clientes finales de esos MSP. Alrededor de 60 MSP y más de 1.000 empresas cliente sufrieron cifrado de sistemas en una sola oleada. REvil exigió 70 millones de dólares por un descifrador universal. | Explotación de una vulnerabilidad en software de gestión remota para propagarse «aguas abajo» a clientes de proveedores de servicios. |
| Backdoor de xz / liblzma | 2024 (descubierto el 29 de marzo) | Un atacante, tras casi dos años ganándose la confianza como colaborador del proyecto de código abierto xz Utils bajo el pseudónimo «Jia Tan», obtuvo permisos de mantenedor e insertó una puerta trasera (CVE-2024-3094, CVSS 10.0) en la librería de compresión liblzma, que afectaba a OpenSSH en las principales distribuciones Linux. Fue descubierto casi por casualidad por el ingeniero Andres Freund, que investigó una ralentización de 500 ms en los inicios de sesión SSH durante pruebas de rendimiento de PostgreSQL. | Ingeniería social a largo plazo para infiltrarse como mantenedor de confianza de un proyecto de código abierto crítico. |
Estos cuatro casos, leídos juntos, dibujan un patrón: el atacante no ataca el objetivo final, ataca el eslabón de la cadena donde la confianza es mayor y la vigilancia menor —el proceso de build de un proveedor, una librería de código abierto asumida como «ya revisada por alguien», el software de gestión remota de un MSP, o la propia gobernanza de un proyecto open source. La mitigación, en consecuencia, no puede limitarse a «confiar menos»: requiere visibilidad técnica real sobre lo que se está ejecutando.
Técnicas de mitigación
- SBOM (Software Bill of Materials): un inventario formal y máquina-legible de todos los componentes, librerías y dependencias —directas y transitivas— que forman parte de una aplicación o producto, habitualmente en formato SPDX o CycloneDX. Sin un SBOM, una organización no puede responder con rapidez a la pregunta que Log4Shell hizo inevitable: «¿usamos este componente vulnerable en algún sitio?». Iniciativas como la Orden Ejecutiva 14028 de EE. UU. (2021) y las guías del NIST han impulsado su adopción como requisito de facto para proveedores de software crítico.
- Verificación de firmas e integridad: comprobar la firma digital y el hash de cualquier actualización o paquete de software antes de desplegarlo, y desconfiar de actualizaciones que se salten los canales oficiales de distribución o de verificación.
- Gestión activa de dependencias: escaneo continuo de dependencias (SCA, Software Composition Analysis) para detectar componentes con vulnerabilidades conocidas o versiones obsoletas, con un proceso definido de actualización priorizado por criticidad.
- Principio de confianza mínima (mínimo privilegio aplicado a la cadena de suministro): limitar el alcance de lo que un componente de terceros, un proveedor o una actualización automática pueden hacer una vez dentro del sistema —sandboxing, segmentación de red, revisión de permisos solicitados por cada dependencia— en lugar de asumir que, una vez pasado el control de entrada, todo lo que viene de un proveedor «de confianza» es intrínsecamente seguro.
Quien quiera profundizar en cómo se investiga técnicamente un incidente de este tipo una vez detectado —desde el análisis forense hasta la contención y la recuperación— puede consultar el curso de DFIR y respuesta a incidentes, y quien necesite entender cómo se protege el directorio activo frente a un compromiso propagado desde un proveedor con acceso privilegiado, el curso de defensa de Active Directory.
Cómo lo exige la regulación
La gestión del riesgo de terceros ha dejado de ser una buena práctica opcional para convertirse en una obligación legal explícita en varios marcos normativos que afectan a organizaciones en España y la Unión Europea.
NIS2: la seguridad de la cadena de suministro como medida obligatoria
El artículo 21.2 de la Directiva (UE) 2022/2555 (NIS2) enumera diez medidas mínimas de gestión de riesgos de ciberseguridad que las entidades esenciales e importantes deben implementar, y la letra d) dedica una de ellas, de forma expresa, a la seguridad de la cadena de suministro, incluyendo los aspectos relacionados con la seguridad de las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. El propio artículo obliga a tener en cuenta las vulnerabilidades específicas de cada proveedor directo y la calidad general de sus prácticas de ciberseguridad, incluida la seguridad de su proceso de desarrollo. Este módulo conecta directamente con el Módulo 11 de este curso sobre NIS2 y DORA, donde se detallan las diez medidas completas y el régimen sancionador.
DORA: el riesgo de terceros TIC en el sector financiero
El Reglamento (UE) 2022/2554, de Resiliencia Operativa Digital (DORA), va un paso más allá para el sector financiero: exige a las entidades financieras mantener un registro de información con una visión completa de todos los terceros que les prestan servicios TIC (artículo 28), y establece requisitos contractuales mínimos específicos según se trate de funciones esenciales o importantes, o de funciones estándar (artículo 30) —derecho de acceso, auditoría e inspección; obligaciones de asistencia en caso de incidente; y planes de salida documentados, entre otros—. DORA introduce además la figura de los proveedores críticos de TIC (CTPP), que pueden quedar sujetos a supervisión directa por los supervisores europeos cuando su papel sistémico lo justifica.
RGPD: el contrato de encargado del tratamiento (artículo 28)
Para cualquier tercero que trate datos personales por cuenta de la organización, el artículo 28 del RGPD no es una recomendación: es una obligación legal directa. Exige un contrato u otro acto jurídico vinculante que regule, entre otros extremos, el objeto y la duración del tratamiento, la naturaleza y finalidad, el tipo de datos y categorías de interesados, y las obligaciones y derechos del responsable —precisamente el contenido que se recoge en la tabla de cláusulas contractuales de este módulo—. El incumplimiento de esta obligación es una de las infracciones que la Agencia Española de Protección de Datos (AEPD) sanciona con mayor frecuencia en sus resoluciones.
Caso práctico: cuestionario de evaluación de seguridad para un proveedor SaaS
Supongamos que la organización va a contratar un SaaS de gestión de recursos humanos que tratará datos personales de toda la plantilla (nombre, DNI, datos bancarios, datos de salud en los procesos de incapacidad temporal). Por el tipo de datos y el volumen, este proveedor se clasifica como crítico según la tabla de la fase 2 del ciclo de vida. El siguiente cuestionario —pensado para enviarse antes de firmar, como parte de la due diligence, y para reutilizarse anualmente en la fase de monitorización continua— cubre los aspectos que ese nivel de criticidad exige.
CUESTIONARIO DE EVALUACIÓN DE SEGURIDAD — PROVEEDOR SAAS
Proveedor: <proveedor> Servicio evaluado: <nombre_del_servicio>
Fecha: <fecha> Clasificación de criticidad: CRÍTICO
1. GOBIERNO Y CERTIFICACIONES
¿Dispone de certificación ISO/IEC 27001 vigente? Adjunte certificado
y alcance exacto (no solo el nombre de la empresa, sino qué
servicios/centros cubre).
¿Dispone de informe SOC 2 Tipo II o equivalente de los últimos
12 meses? Adjunte informe o resumen ejecutivo.
2. UBICACIÓN Y TRANSFERENCIAS DE DATOS
¿En qué país(es) se almacenan y procesan los datos?
Si hay transferencia fuera del EEE: ¿qué garantía del capítulo V
del RGPD ampara la transferencia (adecuación, cláusulas
contractuales tipo, normas corporativas vinculantes)?
3. CIFRADO
¿Los datos se cifran en tránsito (TLS 1.2+) y en reposo?
¿Quién gestiona las claves de cifrado: el proveedor, el cliente,
o un servicio de gestión de claves (KMS) independiente?
4. CONTROL DE ACCESOS
¿Aplica autenticación multifactor (MFA) para el acceso
administrativo a la plataforma?
¿Cómo se segrega el acceso de su personal a los datos de
<proveedor>? ¿Existe registro (log) de accesos a datos personales?
5. SUBENCARGADOS (CUARTAS PARTES)
Facilite el listado completo de subencargados que participan en
la prestación del servicio (hosting, soporte, analítica, etc.).
¿Se notificará al cliente cualquier alta o baja de subencargado
con antelación suficiente para poder oponerse?
6. GESTIÓN DE INCIDENTES
Describa su procedimiento de respuesta a incidentes.
¿En qué plazo máximo notificará al cliente una brecha de
seguridad que afecte a sus datos? (Debe ser inferior a 72h para
permitir el cumplimiento del art. 33 RGPD por parte del cliente).
7. CONTINUIDAD Y RECUPERACIÓN
¿Cuáles son sus objetivos de RTO (tiempo de recuperación) y RPO
(punto de recuperación) para este servicio?
¿Con qué frecuencia se prueban las copias de seguridad y el plan
de continuidad?
8. GESTIÓN DE VULNERABILIDADES
¿Con qué frecuencia se realizan pruebas de penetración sobre la
plataforma? Adjunte fecha del último informe (resumen ejecutivo
es suficiente).
¿Cuál es su SLA interno para aplicar parches críticos tras su
publicación?
9. DERECHO DE AUDITORÍA
¿Acepta la cláusula de derecho de auditoría del cliente, o de un
tercero independiente designado por el cliente, con preaviso
razonable?
10. FORMACIÓN Y PERSONAL
¿El personal con acceso a los datos recibe formación periódica
en protección de datos y seguridad de la información?
¿Se realizan verificaciones de antecedentes (screening) al
personal con acceso a datos sensibles?
11. FIN DE LA RELACIÓN
Al finalizar el contrato: ¿devuelve los datos, los elimina de
forma verificable, o ambas opciones a elección del cliente?
¿En qué plazo se completa el borrado tras la resolución del
contrato?
12. CUMPLIMIENTO NORMATIVO
¿Actuará como encargado del tratamiento conforme al art. 28
RGPD? ¿Acepta firmar el contrato de encargado correspondiente
antes del inicio del servicio?
Un cuestionario de este tipo no sustituye al contrato: lo alimenta. Las respuestas obtenidas determinan qué cláusulas contractuales de la tabla de la fase 3 necesitan un desarrollo específico —por ejemplo, si el proveedor declara subencargados en un tercer país, la cláusula de subcontratación deberá exigir garantías adicionales de transferencia internacional— y sirven como línea base documentada para las revisiones anuales posteriores.
Errores comunes
- Evaluar solo en el momento de la contratación y nunca más. La postura de seguridad de un proveedor en el día de la firma no dice nada sobre su postura dos años después. Sin monitorización continua, la organización descubre los problemas del proveedor cuando ya son un incidente propio.
- No clasificar por criticidad y tratar a todos los proveedores por igual. Aplicar el mismo cuestionario de doce páginas al proveedor de café que al proveedor cloud que aloja la producción malgasta recursos en el primero y, con frecuencia, resulta insuficiente para el segundo.
- Firmar contratos sin cláusula de notificación de incidentes ni derecho de auditoría. Sin plazo de notificación exigible, la organización se entera de la brecha del proveedor por la prensa o por la propia AEPD. Sin derecho de auditoría, no hay forma de verificar que las promesas de seguridad del proveedor son reales y no solo comerciales.
- Ignorar la cuarta parte (los subencargados). Un proveedor puede tener un programa de seguridad ejemplar y, aun así, delegar una parte del servicio en un subcontratista que la organización nunca evaluó ni conoce. La cadena de responsabilidad es tan fuerte como su eslabón menos vigilado, y ese eslabón suele estar a dos o tres niveles de distancia del contrato original.
- Tratar «está en la nube» como sinónimo de «ya no es mi responsabilidad». El modelo de responsabilidad compartida deja siempre una parte —a menudo la configuración, los accesos y la clasificación de datos— del lado del cliente, y es precisamente ahí donde ocurren la mayoría de brechas de servicios cloud mal configurados.
- No mantener un inventario centralizado de terceros. Si nadie en la organización puede responder en cinco minutos «qué proveedores tienen acceso a nuestros datos personales y con qué nivel de criticidad», no existe gestión real del riesgo de terceros, por muchas cláusulas que tengan los contratos individuales.
Ejercicio
Elige un proveedor SaaS que uses o conozcas bien —de tu organización actual o de un caso hipotético realista— y realiza el siguiente ejercicio en cuatro pasos:
- Clasifícalo en uno de los cuatro niveles de criticidad de la tabla de la fase 2, justificando la clasificación en dos frases: qué acceso tiene y qué impacto tendría un fallo.
- Revisa (o imagina, si no tienes acceso al contrato real) si están presentes las siete cláusulas contractuales de la tabla de la fase 3. Señala cuáles faltan.
- Adapta el cuestionario de doce ítems del caso práctico a ese proveedor concreto, eliminando o añadiendo preguntas según el tipo de datos que trate.
- Identifica qué control de ISO/IEC 27002:2022 (5.19 a 5.23) respalda cada una de las cuatro decisiones anteriores.
Preguntas frecuentes
¿Es obligatorio firmar un contrato de encargado del tratamiento con cualquier proveedor que trate datos personales?
Sí, siempre que el proveedor trate datos personales por cuenta de la organización actuando como responsable del tratamiento. El artículo 28 del RGPD lo exige sin excepción, con independencia del tamaño del proveedor o del volumen de datos tratados; lo que varía es la profundidad de las garantías exigibles, no la obligación de tener el contrato.
¿Qué diferencia hay entre ISO/IEC 27036 y los controles 5.19-5.23 de ISO/IEC 27002:2022?
ISO/IEC 27036 es una norma monográfica y mucho más extensa, dedicada por completo a la seguridad en las relaciones con proveedores, con guías detalladas en sus cuatro partes. Los controles 5.19 a 5.23 de ISO/IEC 27002:2022 son la versión resumida e integrada en el catálogo general de controles de seguridad, pensada para auditarse dentro de un SGSI conforme a ISO/IEC 27001. En la práctica, muchas organizaciones usan 27002 como referencia de cumplimiento cotidiano y 27036 como guía de detalle cuando necesitan profundizar en un aspecto concreto.
¿Cómo se clasifica de forma objetiva la criticidad de un proveedor si no hay una metodología cuantitativa de por medio?
Lo habitual es combinar dos escalas simples (por ejemplo, de 1 a 4) para el «nivel de acceso a datos/sistemas» y el «impacto ante fallo del proveedor», y cruzarlas en una matriz, de forma análoga a como se hace con el riesgo probabilidad × impacto explicado en el Módulo 3 de este curso. No hace falta una fórmula sofisticada: lo importante es que el criterio sea consistente y esté documentado, para que dos evaluadores distintos lleguen a la misma clasificación ante el mismo proveedor.
¿Qué se hace si un proveedor crítico se niega a firmar las cláusulas de derecho de auditoría o de notificación de incidentes?
Es una señal de alerta que debe escalarse formalmente, no ignorarse. Las opciones son negociar una alternativa equivalente (por ejemplo, aceptar un informe SOC 2 Tipo II independiente en lugar de auditoría directa), documentar el riesgo residual y elevarlo a quien tenga autoridad para aceptar ese riesgo de forma explícita, o descartar al proveedor si su criticidad no admite ese nivel de incertidumbre. Lo que no es aceptable es firmar sin esas cláusulas y no dejar constancia de la decisión.
¿SBOM es solo relevante para fabricantes de software, o también para quien simplemente lo usa?
También para quien lo usa. Un SBOM no es únicamente una obligación que recae sobre el fabricante: es una herramienta que el cliente debe exigir y conservar de sus proveedores de software crítico, precisamente para poder responder con rapidez ante el próximo «Log4Shell» —saber en minutos si un componente vulnerable recién publicado está presente en algún sistema de la organización, en lugar de tardar semanas en averiguarlo revisando manualmente cada aplicación.
«Systems and services that we rely on in our daily lives are intertwined, so a disruption on one end can have a ripple effect across the supply chain.»
— Juhan Lepassaar, Director Ejecutivo de ENISA, en el informe ENISA Threat Landscape for Supply Chain Attacks (julio de 2021)