Artico Consultores · Análisis de caso · Mayo 2026
El caso Zara:
cuando el riesgo no está en tu empresa,
sino en la que ya no trabaja para ti
En abril de 2026, ShinyHunters robó 140 GB de datos de clientes de Zara sin tocar ni un solo servidor de Inditex. Lo hicieron a través de un proveedor tecnológico con el que Inditex ya no trabajaba. La brecha técnica está en Anodot. La pregunta legal está en otra parte: ¿por qué ese proveedor seguía teniendo los datos?
La filtración de datos de Zara que se ha confirmado esta semana no es la historia que están contando la mayoría de los medios. No es la historia de un gigante empresarial hackeado. Es la historia de un ataque que explotó exactamente el punto donde las empresas tienen más descuido — y donde el RGPD tiene las obligaciones más claras: la gestión de los datos que manejan los proveedores una vez que dejan de ser proveedores.
Inditex tiene ingresos de 38.600 millones de euros, emplea a 160.000 personas y opera en más de 90 países. No es el tipo de empresa que deja su ciberseguridad al azar. Y sin embargo, 197.400 clientes tienen hoy sus datos personales en el portal de filtraciones de un grupo criminal en la dark web. La razón no está en sus propios sistemas — está en la cadena.
140 GB
Volumen de datos robados y publicados en la dark web por ShinyHunters2
€38,6MM
Facturación de Inditex en 2025 — la empresa española afectada con más impacto global3
1. Lo que pasó, con precisión:
la cronología verificada
La mayoría de las coberturas mezclan dos momentos distintos del incidente. Conviene separar los hechos con precisión, porque la cronología es relevante para entender tanto la naturaleza del ataque como la respuesta de Inditex.
Principios de abril 2026
ShinyHunters compromete Anodot y roba los datos
El grupo obtiene tokens de autenticación de Anodot — plataforma de analítica big data usada por Inditex y decenas de multinacionales — y los usa para acceder a instancias de BigQuery. Durante semanas copian el archivo de 140 GB sin ser detectados. La inteligencia artificial de detección de Anodot bloquea eventualmente el intento, pero el robo ya está consumado.
17 de abril 2026
ShinyHunters publica el aviso en su portal de la dark web
El grupo lista a Zara (zara.com) en su sitio de filtraciones en Tor con un mensaje directo: "Your BigQuery instances data was compromised thanks to Anodot.com". Fijan el 21 de abril como plazo límite para que Inditex contacte y negocie — modelo "pay or leak" estándar del grupo.
17-21 de abril 2026
Inditex confirma el incidente y notifica a autoridades
La compañía emite comunicado oficial reconociendo acceso no autorizado a bases de datos alojadas en un "antiguo proveedor tecnológico". Notifica a las autoridades competentes de protección de datos. No nombra al proveedor ni atribuye el ataque a ShinyHunters públicamente.
21 de abril 2026 — plazo vence
Inditex no paga — ShinyHunters publica los datos
Sin acuerdo. ShinyHunters hace público el archivo de 140 GB en su portal. Inditex ha tomado la decisión correcta al no pagar — pagar nunca garantiza que los datos se borren y financia futuros ataques — pero el daño ya es irreversible para los 197.400 afectados.
8-9 de mayo 2026
Have I Been Pwned confirma el alcance: 197.376 afectados
2. La anatomía del ataque:
cómo se roba sin entrar en el edificio
Entender cómo funcionó técnicamente este ataque es esencial para que los directivos y CTO entiendan el riesgo real que representa. No hace falta ser especialista en ciberseguridad — la lógica es simple y la lección es directamente aplicable a cualquier organización que use plataformas SaaS o servicios analíticos en la nube.
Cómo funciona un ataque de cadena de suministro analítico
La técnica que ShinyHunters usó contra Zara, Vimeo y Rockstar Games — y que ya han documentado contra decenas de empresas
Paso 1 — Comprometer el proveedor
Los atacantes obtienen acceso a Anodot, la plataforma de analítica big data. No necesitan hackear a Inditex directamente: solo necesitan las credenciales o tokens de la plataforma intermedia que Inditex usa para sus análisis de datos.
Paso 2 — Usar tokens legítimos
Con los tokens de autenticación de Anodot, acceden a las instancias de BigQuery (Google Cloud) donde Inditex almacena sus datos analíticos. Para el sistema de BigQuery, la petición parece completamente legítima — viene con las credenciales correctas.
Paso 3 — Copiar durante semanas
No roban todo a la vez. Durante semanas extraen datos gradualmente para evitar alertas de volumen. 140 GB en varias sesiones. El movimiento lateral hacia otros entornos SaaS conectados es parte estándar de la técnica.
Paso 4 — Extorsión "pay or leak"
Una vez tienen los datos, contactan a la víctima con plazo de días: o pagan o publican. No es ransomware — no cifran nada, no paralizan operaciones. Es extorsión pura de datos. El daño es la publicación, no el bloqueo.
ShinyHunters — mensaje en su portal dark web · Abril 2026
"Your BigQuery instances data was compromised thanks to Anodot.com. The company failed to reach an agreement with us despite our incredible patience, all the chances."
El detalle que hace especialmente importante esta técnica es la escala. ShinyHunters ha declarado a medios especializados que usaron los tokens de Anodot para acceder a datos de docenas de empresas simultáneamente. Una sola brecha en una plataforma analítica intermedia se convierte en un punto de entrada a la infraestructura de múltiples clientes de esa plataforma. El atacante no necesita hackear a cada empresa — hackea el intermediario y obtiene acceso a todos.
3. Lo que se robó —
y el riesgo real que nadie está explicando bien
Inditex ha comunicado con consistencia que los atacantes no accedieron a nombres, teléfonos, direcciones, contraseñas ni datos de pago. Eso es cierto. Y genera en el lector casual la impresión de que el incidente es relativamente menor. No lo es. La combinación de datos que sí se robó crea un vector de ataque secundario mucho más peligroso que cualquier contraseña filtrada.
Direcciones de email
Expuesto
197.400 emails únicos confirmados. Canal de contacto directo para campañas de phishing.
Historial de compras (SKU, fechas)
Expuesto
Qué productos compró, cuándo, en qué mercado. Permite personalizar ataques con precisión quirúrgica.
Tickets de soporte y devoluciones
Expuesto
Contenido de conversaciones con atención al cliente. Referencias exactas de incidencias reales.
Identificadores de pedidos
Expuesto
Números de pedido reales que dan credibilidad a comunicaciones fraudulentas.
Ubicación geográfica / mercado
Expuesto
País y mercado de origen de los tickets. Permite segmentar y personalizar los ataques por idioma y contexto.
Nombre completo
No expuesto
Inditex confirma que no estaba en las bases de datos comprometidas.
Contraseñas / credenciales
No expuesto
No estaban almacenadas en las bases analíticas comprometidas.
Datos de pago / tarjeta bancaria
No expuesto
No estaban en las bases de datos de Anodot. Procesados por sistemas separados.
⚠️ El phishing contextual: más peligroso que una contraseña filtrada. Con los datos expuestos, un atacante puede construir el email perfecto: "Estimado cliente, hemos detectado un problema con tu devolución del artículo [SKU real] del pedido #[número real] realizado el [fecha real]. Por favor, verifica tu método de pago." No hay nombre, pero hay exactamente la información suficiente para que el destinatario crea que el email es auténtico. Esta es la amenaza real de esta filtración. No la tarjeta de crédito — el engaño posterior que la tarjeta de crédito facilita. Analizamos en detalle cómo funciona la suplantación de identidad con IA en nuestro artículo sobre deepfakes corporativos.
4. La pregunta que Inditex
no ha respondido
Inditex se ha referido sistemáticamente al proveedor afectado como "un antiguo proveedor tecnológico". No han nombrado a Anodot públicamente. Desde el punto de vista de la comunicación de crisis, es una decisión comprensible — limita la exposición y evita señalar directamente a un tercero antes de que los hechos estén totalmente establecidos.
Pero hay una pregunta de fondo que esa formulación no puede eludir: si Anodot es un antiguo proveedor — es decir, una empresa con la que Inditex ya no tiene relación comercial activa — ¿por qué seguía teniendo 140 GB de datos de clientes de Inditex?
Art. 28
RGPD — La obligación que convierte la pregunta en cuestión legal
Art. 28.1 RGPD — Elección del encargado
Cuando un responsable del tratamiento externaliza operaciones a un encargado, debe elegir uno que ofrezca "garantías suficientes" y verificarlo. Eso incluye garantías sobre la seguridad de los datos — y sobre su destrucción cuando la relación termina.
Art. 28.3.g RGPD — La obligación que más importa aquí
El
contrato con el encargado debe incluir la obligación de "suprimir o devolver todos los datos personales una vez finalizada la prestación de los servicios de tratamiento". Si Anodot era un proveedor antiguo y seguía teniendo datos, algo falló aquí.
Art. 5.1.e RGPD — Limitación del plazo de conservación
Los datos no deben conservarse más tiempo del necesario para los fines para los que fueron recogidos. Si la relación comercial con Anodot había terminado, la finalidad del tratamiento por ese encargado también había terminado.
Responsabilidad del responsable — no se externaliza
El RGPD establece que el responsable del tratamiento (Inditex) sigue siendo responsable de lo que hace con los datos su encargado. Como analizamos en nuestro artículo sobre
la relación entre el Compliance Officer y el DPO, la supervisión continua de los encargados del tratamiento es una de las grietas de gobernanza más frecuentes en las organizaciones. Que Anodot haya sido atacado no exime a Inditex de responder si no verificó que los datos habían sido efectivamente eliminados al terminar la relación.
Esta pregunta tiene dos respuestas posibles, y ninguna de las dos es perfectamente cómoda. La primera: la relación con Anodot terminó pero Inditex no verificó que los datos fueran eliminados conforme al artículo 28.3.g. La segunda: Anodot sigue siendo o era hasta hace muy poco un proveedor activo, y el término "antiguo" en el comunicado es más impreciso de lo que parece. Cualquiera de las dos merece análisis y documentación.
⚡ Lo que la AEPD puede investigar: cuando un encargado del tratamiento sufre una brecha que afecta a datos del responsable, la AEPD puede investigar si el responsable había verificado las garantías del encargado, si existía un contrato art. 28 completo, si ese contrato incluía la obligación de eliminar datos al terminar la relación y si Inditex había auditado el cumplimiento de esa obligación. El hecho de que Inditex haya notificado rápido es positivo — pero no cierra esa investigación.
5. La gestión de Inditex:
lo que han hecho bien y lo que queda abierto
Un análisis equilibrado obliga a reconocer lo que Inditex ha hecho correctamente en este incidente — porque hay aspectos de su respuesta que están por encima de la media del sector — y señalar también los aspectos que no han quedado completamente resueltos.
La respuesta de Inditex — balance objetivo
Lo que han hecho correctamente y lo que todavía queda sin responder a 11 de mayo de 2026
Han notificado a las autoridades — correcto
La notificación a la
AEPD y otras autoridades de protección de datos se produjo rápidamente. Cumplimiento del plazo de 72 horas del art. 33 RGPD — una de las obligaciones más incumplidas en incidentes de este tipo.
Han notificado a los afectados — correcto
Los clientes afectados recibieron comunicación directa. No todos lo hacen. Esta notificación es obligatoria bajo el art. 34 RGPD cuando la brecha supone riesgo elevado para los interesados.
No han pagado el rescate — correcto
La decisión de no negociar con ShinyHunters es la correcta. Pagar no garantiza la destrucción de los datos, financia futuros ataques y puede generar problemas legales adicionales. Inditex absorbió el daño reputacional antes de ceder a la extorsión.
No han nombrado a Anodot — pregunta abierta
Tres semanas después de la divulgación pública del nombre por parte de ShinyHunters y de la cobertura en medios internacionales, Inditex sigue sin confirmar ni desmentir públicamente el nombre del proveedor afectado. Los afectados tienen derecho a saber.
No han atribuido el ataque — pregunta abierta
Inditex no ha atribuido públicamente el ataque a ShinyHunters aunque el grupo se ha declarado responsable, ha publicado los datos y los medios especializados lo han documentado. Puede ser jurídicamente prudente, pero genera opacidad.
La pregunta del proveedor "antiguo" — sin responder
Sigue sin explicarse por qué un proveedor con el que ya no se trabaja tenía datos vigentes de clientes. La respuesta a esta pregunta determinará en buena medida la valoración regulatoria del incidente.
6. Las obligaciones RGPD
que entran en juego — cuadro completo
72h
El plazo que Inditex parece haber cumplido — y que la mayoría de empresas no cumple
El artículo 33 del RGPD obliga a notificar una brecha de seguridad a la autoridad de control (AEPD en España) en un plazo máximo de 72 horas desde que el responsable tenga conocimiento de ella. Los procedimientos sancionadores por brechas crecieron un 157% en 2025 según la Memoria AEPD. El cumplimiento del plazo es atenuante significativo en la valoración regulatoria.
El incidente de Zara activa una cadena de obligaciones bajo el RGPD que van más allá de la notificación inicial. Entenderlas es relevante tanto para evaluar la posición de Inditex como para que cualquier empresa con estructura similar analice su propia exposición.
RGPD
Obligaciones activadas por la brecha Zara — análisis artículo por artículo
Art. 33 — Notificación a la AEPD
Obligación de notificar en 72 horas desde que se tenga conocimiento de la brecha. Inditex ha cumplido. Mitigante importante en la valoración regulatoria posterior.
Art. 34 — Comunicación a los afectados
Si la brecha supone riesgo elevado para los derechos de las personas — que en este caso sí supone dado el potencial de phishing —, hay obligación de comunicarlo a los interesados. Inditex ha notificado a los afectados.
Art. 28.3 — Contrato con encargado del tratamiento
El contrato con Anodot debía incluir obligaciones de seguridad y eliminación de datos al finalizar la relación. ¿Lo incluía? ¿Se verificó su cumplimiento? Estas preguntas son las que la AEPD puede plantear en una investigación.
Art. 32 — Medidas técnicas de seguridad
El responsable debe implementar medidas técnicas adecuadas al riesgo. Parte de esa responsabilidad incluye verificar que los encargados del tratamiento también las implementan. ¿Auditoría de seguridad a Anodot? ¿Con qué periodicidad?
Art. 5.2 — Principio de responsabilidad proactiva
Inditex deberá demostrar no solo que cumplió, sino que tiene documentado que cumplió. EIPDs actualizadas, registro de actividades, contratos art. 28 completos, auditorías de encargados. Todo debe existir y ser demostrable.
Art. 83 — Régimen sancionador
Las infracciones de los artículos 5, 25, 28 y 32 pueden ser sancionadas con hasta 20 millones de euros o el 4% de la facturación global. Para Inditex, el 4% de 38.600 millones es 1.544 millones de euros — aunque las sanciones reales nunca alcanzan ese máximo teórico.
7. La lección para su empresa:
lo que debe revisar esta semana
El caso Zara no es una anomalía. Es el patrón de ataque dominante de los próximos años. Los atacantes han aprendido que la mejor forma de comprometer a una empresa grande es no atacarla directamente — es atacar a quien tiene acceso a sus datos con menor nivel de protección. Plataformas de analítica, proveedores de email marketing, servicios de monitorización, integraciones SaaS. Todos ellos tienen tokens con acceso a infraestructura crítica. Todos ellos son el vector real del riesgo.
Lo que debe revisar hoy si tiene proveedores con acceso a datos · Artico Consultores · Mayo 2026
!
Inventario de proveedores con acceso a datos personales: ¿sabe exactamente qué empresas tienen acceso a los datos de sus clientes, empleados o usuarios? ¿Cuáles tienen tokens activos con acceso a sus entornos cloud? Si no tiene ese inventario actualizado, este es el punto de partida de cualquier proceso de adecuación al RGPD.
RGPD art. 30
!
Proveedores con los que ya no trabaja: esta es la lección más directa del caso Zara. Cuando termina una relación con un proveedor tecnológico que gestionaba datos de sus clientes, ¿verifica formalmente que han eliminado esos datos? ¿Tiene esa confirmación por escrito? Si no, el dato sigue en su riesgo aunque el proveedor no esté en su factura.
RGPD art. 28.3.g
!
Tokens de autenticación con alcance excesivo: las plataformas analíticas, de monitorización y de marketing suelen pedir tokens con permisos amplios para funcionar correctamente. La gestión inadecuada de credenciales y tokens de acceso es uno de los vectores de riesgo más subestimados — como señalamos en nuestro análisis sobre hábitos de seguridad digital en empresas. Aplique el principio de mínimo privilegio: el token de un proveedor de analítica solo debería tener acceso de lectura sobre los datos estrictamente necesarios para su función. Revise y restrinja.
RGPD art. 32
!
Contratos art. 28 completos y actualizados: el contrato de encargado del tratamiento debe incluir obligaciones de seguridad, el derecho de auditoría de su empresa sobre el encargado, y la obligación de eliminar los datos cuando termine la relación. Si sus contratos no incluyen eso, son incompletos bajo el RGPD. Un DPO externo certificado puede revisar y completar esa documentación.
RGPD art. 28.3
!
Protocolo de respuesta ante brechas documentado: si mañana descubriera que un proveedor suyo ha sido comprometido, ¿sabe exactamente qué hacer? ¿Quién llama a quién? ¿Quién notifica a la AEPD? ¿En qué plazo? Sin ese protocolo por escrito, el plazo de 72 horas del art. 33 es imposible de cumplir.
RGPD art. 33
✓
EIPD para nuevos proveedores con acceso analítico: cuando una plataforma de analítica, marketing o monitorización tiene acceso a datos personales de clientes a escala, la Evaluación de Impacto en la Protección de Datos (EIPD) es preceptiva. Realizarla antes de contratar al proveedor — no después de que ocurra el incidente. Profundizamos en las obligaciones de EIPD en nuestro artículo sobre videovigilancia inteligente y RGPD.
RGPD art. 35
Conclusión: el riesgo no está
donde crees que está
El caso Zara confirma lo que los especialistas en ciberseguridad llevan años señalando: las organizaciones mejor protegidas no son atacadas directamente. Son atacadas a través de la confianza que han depositado en terceros. Esa confianza tiene un nombre legal: encargado del tratamiento. Y el RGPD la regula con precisión en el artículo 28 exactamente porque los legisladores europeos entendieron que la privacidad de los datos no puede limitarse a la infraestructura propia.
Inditex es la empresa española de mayor facturación del mundo. Tiene recursos para contratar a los mejores equipos de ciberseguridad. Y aun así, 197.400 clientes tienen hoy sus datos en la dark web porque un proveedor — activo o no — no había eliminado los datos que debería haber eliminado, o no había protegido adecuadamente los tokens de acceso que le permitían gestionarlos.
La pregunta que todo director, CTO y responsable de compliance debe hacerse hoy no es "¿está mi empresa bien protegida?" La pregunta es "¿están bien protegidos todos los que tienen acceso a mis datos?" Son preguntas distintas. Y la segunda, con frecuencia, no tiene respuesta documentada.
A
Artico Consultores
Consultoría especializada en Protección de Datos · DPOs certificados AEPD/ENAC · Zaragoza · portalartico.es
¿Tiene auditados todos los proveedores
que acceden a datos de sus clientes?
En Artico auditamos su cadena de proveedores tecnológicos, revisamos los contratos de encargado del tratamiento y verificamos que los datos están donde deben estar — y no donde ya no deberían. DPOs certificados AEPD/ENAC · 25 años en Aragón
1Have I Been Pwned, Troy Hunt — análisis del dataset publicado por ShinyHunters. Confirmado el 8 de mayo de 2026: 197.376 direcciones de email únicas, junto con SKU de producto, identificadores de pedido y mercado de origen del ticket de soporte. Citado en BleepingComputer, SecurityAffairs y Security Boulevard (9-11 mayo 2026).
2ShinyHunters, portal de filtraciones en Tor — publicación del 21 de abril de 2026, tras vencimiento del plazo de extorsión. RedPacket Security confirma: "subsequently published a terabyte of data allegedly including 95M support ticket records" además del archivo de 140 GB de BigQuery.
3Inditex, resultados fiscales 2025: ingresos de €38.600 millones, 160.000 empleados, presencia en más de 90 países. Citado en el análisis de SecurityAffairs (9 mayo 2026) y BleepingComputer como contexto del alcance del incidente.
4CyberInsider, "Inditex confirms third-party breach as hackers threaten Zara data leak", 17 de abril de 2026. Comunicado oficial de Inditex citado íntegramente: "Inditex ha aplicado de inmediato sus protocolos de seguridad y ha comenzado a notificar a las autoridades competentes este acceso no autorizado, que se deriva de un incidente de seguridad que afectó a un antiguo proveedor tecnológico."
5Moncloa.com / Security Boulevard, análisis técnico del vector Anodot-BigQuery, mayo 2026. ShinyHunters declaró a BleepingComputer haber usado los tokens de Anodot contra "docenas de compañías" simultáneamente. La misma técnica se usó contra Vimeo (119.000 usuarios afectados) y Rockstar Games en el mismo período.
6RGPD arts. 28, 33, 34, 32, 35 y 83. AEPD, Memoria de actuación 2025: los procedimientos sancionadores por brechas de datos crecieron un 157% en 2025 (de 30 a 77), generando casi 20 millones de euros en sanciones — el 40% del total anual.
Escríbenos por WhatsApp