El perímetro del proveedor es donde comienza la mayoría de las brechas
El acceso de proveedores externos a los datos ya no es una categoría de riesgo secundaria. Según el Global Third-Party Breach Report 2025 de SecurityScorecard, el 35,5 % de todas las brechas en 2024 estuvieron relacionadas con terceros, y esa cifra probablemente es conservadora, dado que los compromisos que ocurren varios niveles por debajo en el ecosistema de un proveedor suelen clasificarse mal o no reportarse. El Data Breach Investigations Report más reciente de Verizon sitúa esa proporción en el 30 %, el doble que el año anterior. La tendencia es clara.
El impacto financiero coincide con la frecuencia. El informe Cost of a Data Breach 2024 de IBM sitúa el coste medio de una brecha por terceros por encima de los 5,08 millones de dólares. En Alemania específicamente, el coste medio de una brecha alcanzó los 4,9 millones de euros en 2024, lo que la coloca entre los cinco países con mayor coste a nivel mundial. Gartner atribuye ese sobrecoste a la complejidad añadida de gestionar incidentes que abarcan múltiples entidades, jurisdicciones legales y entornos de datos.
La exposición a brechas en la cadena de suministro también se ha vuelto estructuralmente concentrada. Quince empresas representan ahora el 62 % del mercado tecnológico global. La mitad de todas las empresas trabaja con más de 100 proveedores, frente al 38 % en 2023. Por cada relación directa con un proveedor, las organizaciones suelen tener una exposición indirecta a casi 14 veces más partes en niveles cuarto y quinto. Cuando una sola plataforma de transferencia de archivos gestionada o una herramienta SaaS se ve comprometida, el radio de impacto no queda limitado por tu propio perímetro.
Lo que los incidentes recientes revelan sobre las brechas sistémicas
La brecha de MOVEit de junio de 2023 es el ejemplo más claro y reciente de riesgo concentrado en la cadena de suministro. Tres vulnerabilidades de inyección SQL en la plataforma MOVEit Transfer de Progress Software expusieron datos de cerca de 1.700 organizaciones y casi 100 millones de personas. El grupo de ransomware Cl0p explotó los fallos para acceder al proveedor de nóminas Zellis, que a su vez expuso datos de British Airways, la BBC y otros. Ninguna organización afectada había introducido la vulnerabilidad; todas la heredaron a través de una dependencia compartida.
La campaña de Snowflake de 2024 siguió un vector diferente. Un grupo identificado como UNC5537 utilizó credenciales obtenidas mediante malware infostealer para acceder a cuentas de Snowflake en más de 160 empresas, la mayoría de las cuales no tenía configurada la autenticación multifactor. AT&T, Ticketmaster y Santander estuvieron entre los afectados. La campaña convirtió a las plataformas en la nube en el segundo vector de ataque de terceros más común en 2024, e ilustra cómo las configuraciones de acceso permisivas dentro de una plataforma de proveedor se convierten en tu problema incluso cuando la infraestructura propia del proveedor no está comprometida.
Incidentes más recientes confirman que el patrón se acelera. La brecha de Samsung Alemania de marzo de 2025 expuso cerca de 270.000 registros de clientes a través del proveedor externo Spectos. En junio de 2025, el proveedor de aprovisionamiento Chain IQ Group AG sufrió un ataque de ransomware que expuso más de 130.000 registros de empleados de clientes como UBS y Pictet. Marks and Spencer perdió 300 millones de libras cuando las credenciales comprometidas de un contratista de TCS expusieron 9,4 millones de registros de clientes, causando seis semanas de interrupción operativa. En cada caso, los controles propios de la organización principal resultaron irrelevantes: la exposición llegó a través de un tercero de confianza.
El acceso de proveedores no es un detalle de configuración. Es una decisión arquitectónica con consecuencias regulatorias y financieras que se acumulan en cada parte de tu cadena de suministro.
Qué exigen realmente el RGPD y NIS2
El artículo 28 del RGPD es inequívoco respecto a los encargados del tratamiento externos: un responsable solo puede utilizar encargados que ofrezcan garantías suficientes para aplicar medidas técnicas y organizativas apropiadas, y el encargado no puede subcontratar a otro encargado sin autorización previa y por escrito del responsable. Esa cadena de responsabilidad no termina en tu proveedor directo; se extiende a cada subencargado que este contrate.
En la práctica, esto significa que tus Acuerdos de Tratamiento de Datos deben enumerar los subencargados, especificar las categorías de datos a los que cada uno puede acceder e incluir derechos de auditoría. Cuando un proveedor no puede demostrar esos controles, el responsable sigue siendo liable por el tratamiento resultante. Las autoridades de supervisión de toda la UE han tratado sistemáticamente la supervisión inadecuada de proveedores como un fallo del responsable, no del proveedor.
NIS2 extiende una lógica similar a la continuidad operativa. Las entidades en el ámbito de aplicación deben abordar la seguridad de la cadena de suministro como parte de sus obligaciones de gestión de riesgos, lo que incluye evaluar las prácticas de seguridad de los proveedores directos y, cuando sea pertinente, de los proveedores de esos proveedores. Los datos de SecurityScorecard de 2024 que mostraban que el 98 % de las 100 principales empresas europeas había sufrido brechas de terceros en el año anterior se publicaron precisamente en el contexto del plazo de DORA, lo que subraya que los reguladores están siguiendo de cerca este ámbito. Entre las 100 principales instituciones financieras europeas, el 96 % se vio afectada por al menos una brecha de terceros en el último año, frente al 78 % del año anterior.
Un marco de auditoría práctico para el acceso de proveedores a los datos
Antes de poder limitar el acceso de proveedores externos a los datos, necesitas un inventario preciso. La mayoría de las organizaciones subestima sus relaciones con proveedores porque la contratación de SaaS ocurre fuera de la gobernanza de TI y los subencargados raramente se rastrean más allá del primer nivel. Empieza por ahí.
- Mapea cada flujo de datos hacia un proveedor o subencargado. Incluye herramientas SaaS, proveedores de servicios gestionados, plataformas de nóminas, servicios de transferencia de archivos y cualquier sistema con acceso API a datos de producción. Documenta qué categorías de datos personales puede alcanzar cada uno, en qué condiciones y quién autorizó el acceso.
- Clasifica a los proveedores por sensibilidad de datos y posibilidad de sustitución. Un proveedor con acceso a registros de RRHH o datos financieros requiere controles más estrictos y revisiones más frecuentes que uno que procesa analíticas anonimizadas. La posibilidad de sustitución importa porque determina el margen de negociación que tienes en los contratos.
- Revisa los Acuerdos de Tratamiento de Datos conforme a los requisitos del artículo 28. Verifica que las cláusulas de subencargados sean específicas, que los derechos de auditoría sean ejecutables y que los plazos de notificación de brechas cumplan el requisito de 72 horas del RGPD. Si tu acuerdo se firmó hace tres años, casi con certeza necesita actualización.
- Aplica el principio de mínimo privilegio en la capa técnica. Las cuentas de proveedores solo deben acceder a los datos necesarios para el servicio contratado. La segmentación de red, los tokens de API con alcance restringido y las credenciales con tiempo limitado reducen el radio de impacto cuando un proveedor se ve comprometido. La campaña de Snowflake tuvo éxito en gran medida porque las credenciales tenían privilegios excesivos y la autenticación multifactor estaba ausente.
- Realiza evaluaciones de riesgo de proveedores de forma periódica, no solo en la incorporación. La postura de seguridad cambia. Un proveedor que superó una revisión al firmar el contrato puede haber incorporado un subencargado, cambiado de infraestructura en la nube o sufrido un incidente no revelado desde entonces. Una reevaluación anual es el mínimo; trimestral para proveedores críticos es defendible bajo NIS2.
- Pon a prueba tu respuesta a incidentes para escenarios con terceros. Un ejercicio de simulación que asuma que la brecha se origina dentro de tu perímetro no preparará a tu equipo para la carga de coordinación de un evento al estilo MOVEit. Simula escenarios en los que un proveedor crítico te notifica un compromiso y debes evaluar la exposición, notificar a los interesados afectados y contactar con tu autoridad de supervisión en 72 horas.
Cómo la arquitectura de infraestructura reduce la superficie de riesgo del proveedor
La arquitectura de la nube para la gestión de riesgos de proveedores importa tanto como los procesos. Cuando tus cargas de trabajo se ejecutan en infraestructura sujeta a jurisdicción extranjera, cada relación con un proveedor o subencargado hereda esa complejidad jurisdiccional. La sentencia Schrems II invalidó el marco Privacy Shield precisamente porque la legislación de vigilancia de EE. UU. creaba una incompatibilidad estructural con el RGPD, independientemente de lo que dijera el acuerdo de tratamiento de datos de cualquier proveedor individual.
Operar sobre infraestructura europea soberana elimina esa capa de incertidumbre. DIVERSITY opera su propia infraestructura carrier-neutral íntegramente dentro de Europa, bajo legislación europea, con operaciones certificadas según ISO 27001. Eso significa que la capa de nube en sí no es un subencargado con subencargados opacos propios; es un componente definido y auditable dentro de tu cadena de tratamiento de datos. Para los sectores regulados que navegan por DORA, NIS2 o las expectativas supervisoras sectoriales, esa claridad arquitectónica no es una afirmación de marketing: es evidencia que puedes presentar ante un auditor.
La segmentación de red y los controles de acceso implementados en la capa de infraestructura son más duraderos que los configurados dentro de un entorno SaaS de responsabilidad compartida. Cuando controlas la red, puedes garantizar que la cuenta de servicio de un proveedor no pueda acceder a datos fuera de su segmento designado, independientemente de los permisos que la propia plataforma del proveedor permitiría. Eso supone una reducción significativa del radio de impacto, y es el tipo de control que los derechos de auditoría del artículo 28 deben verificar.
Reducir la exposición es una disciplina operativa continua
El 41,4 % de los ataques de ransomware que ahora se originan a través de terceros no es una anomalía temporal. Los atacantes siguen el camino de menor resistencia y, para la mayoría de las empresas europeas, ese camino pasa actualmente por el ecosistema de proveedores. Cerrarlo requiere un esfuerzo constante entre las funciones legal, de aprovisionamiento, de TI y de seguridad.
Las organizaciones que demostrarán un progreso significativo bajo el RGPD y NIS2 son las que tratan la auditoría del acceso de proveedores en la nube como una disciplina operativa recurrente, no como una casilla que marcar antes de firmar un contrato. Eso implica mantener el inventario de proveedores actualizado, aplicar controles técnicos que no dependan de la autoatestación del proveedor y elegir socios de infraestructura cuya propia postura de cumplimiento no añada riesgo jurisdiccional a un panorama ya complejo.
