script> noscript>

Brecha de Datos en ServiceNow Junio 2026: Qué Exige el RGPD

Ilustración editorial sobre brecha de datos de ServiceNow y obligaciones de notificación bajo el RGPD

En junio de 2026, una brecha de datos en ServiceNow sacudió a miles de empresas en todo el mundo, incluidas muchas que operan en España. Una vulnerabilidad crítica en una API de la plataforma permitió que actores no autenticados accedieran a tablas con datos sensibles de clientes: nombres de empleados, tickets de soporte IT, bases de conocimiento internas y registros de acceso. Lo más grave no fue solo el fallo técnico, sino lo que ocurrió después: la compañía aplicó el parche el 5 de junio pero no informó a sus clientes hasta el 9 de junio.

Cuatro días. Cuatro días en los que miles de empresas afectadas no sabían que sus datos habían quedado expuestos. Cuatro días que, según el Reglamento General de Protección de Datos (RGPD), pueden suponer una infracción grave con sanciones de hasta 10 millones de euros o el 2% de la facturación global anual. ¿Sabe tu empresa qué hacer cuando un proveedor sufre una brecha de datos personales? ¿Tienes los protocolos listos para actuar en las primeras 72 horas?

Qué ocurrió exactamente con la brecha de datos de ServiceNow en junio de 2026

La vulnerabilidad técnica detrás del incidente

ServiceNow es una de las plataformas de gestión empresarial más utilizadas en el mundo, con miles de clientes en Europa, incluyendo grandes corporaciones, aseguradoras, entidades financieras y administraciones públicas. En junio de 2026, se descubrió que un endpoint de la API REST de la plataforma estaba configurado sin requerir autenticación: el recurso /api/now/related_list_edit/create podía ser consultado por cualquier actor externo sin presentar credenciales válidas.

La vulnerabilidad, técnicamente clasificada como un Broken Access Control (control de acceso roto), permitía enviar consultas a las tablas de instancias de clientes y recibir datos directamente. El fallo radicaba en que el Scripted REST Resource tenía el parámetro requires_authentication configurado en false. Según los investigadores que analizaron el incidente, bastaba con conocer la estructura del endpoint para extraer información de las instancias de clientes sin ninguna barrera de seguridad.

Puedes consultar el análisis técnico completo publicado por BleepingComputer.

El cronograma del incidente y el retraso en la comunicación

El 22 de abril de 2026, un investigador de seguridad envió un informe confidencial de bug bounty describiendo el problema. ServiceNow tardó 44 días en aplicar el parche, finalmente publicado el 5 de junio de 2026. Sin embargo, no emitió un aviso público hasta el 9 de junio, y ese aviso solo era visible para usuarios con acceso al portal de soporte de clientes. Las empresas que no revisaron activamente ese portal durante esos cuatro días no sabían que sus datos habían podido ser comprometidos.

Como confirmó TechCrunch, ServiceNow abrió casos de soporte con los clientes afectados, indicando que quienes no hubieran recibido uno no estaban entre los perjudicados. Sin embargo, la opacidad del proceso de comunicación generó una ola de críticas en la industria de la ciberseguridad.

Por qué falló la notificación RGPD: el problema del plazo de las 72 horas

El RGPD es muy claro en su artículo 33: cuando se produce una brecha de seguridad de datos personales que suponga un riesgo para los derechos y libertades de las personas físicas, el responsable del tratamiento debe notificarla a la autoridad supervisora competente —la AEPD en España— sin dilación indebida y, si es posible, en un plazo máximo de 72 horas desde que tenga constancia de ella.

El caso ServiceNow pone de manifiesto un problema que afecta directamente a las empresas que usan servicios en la nube: ¿cuándo empieza a contar el plazo de 72 horas?

  • Si la empresa es responsable del tratamiento: el plazo empieza cuando tiene constancia del incidente, es decir, desde que ServiceNow les informó o debería haberles informado. Si la compañía parchó el sistema el 5 de junio pero no notificó a los clientes hasta el 9, las empresas afectadas tendrían que haber evaluado su notificación a la AEPD antes del 12 de junio.
  • Si ServiceNow actúa como encargado del tratamiento: según el artículo 33.2 del RGPD, el encargado debe notificar al responsable sin dilación indebida después de tener constancia de la brecha. El retraso de cuatro días entre la aplicación del parche y la comunicación a clientes puede considerarse un incumplimiento de esta obligación contractual y legal.

La gestión opaca de la comunicación es exactamente el tipo de comportamiento que la AEPD y otras autoridades europeas han sancionado en resoluciones anteriores. Una empresa española que use ServiceNow y procese datos de empleados o clientes a través de la plataforma era, en ese intervalo, técnicamente expuesta sin saberlo.

Qué dice el RGPD sobre las brechas de seguridad de datos personales

Las obligaciones de notificación de brechas de datos están reguladas en los artículos 33 y 34 del RGPD. Conocerlos es imprescindible para cualquier empresa que trate datos personales en España o en la Unión Europea.

Artículo 33: Notificación a la autoridad de control

El responsable del tratamiento debe notificar la brecha a la AEPD en un máximo de 72 horas. La notificación debe incluir: la naturaleza de la brecha y categorías de datos afectados, el número aproximado de personas afectadas, los datos de contacto del Delegado de Protección de Datos (DPO), las posibles consecuencias del incidente y las medidas adoptadas o propuestas para remediarlo.

Si la notificación se realiza después de las 72 horas, debe ir acompañada de una explicación razonada del retraso. La AEPD dispone de un sistema de notificación electrónica de brechas accesible a través de su sede online.

Artículo 34: Comunicación a los interesados

Cuando la brecha pueda entrañar un alto riesgo para los derechos y libertades de las personas —por ejemplo, si se expusieron datos bancarios, médicos o credenciales de acceso— el responsable debe comunicarlo directamente a los afectados sin dilación indebida. Esta obligación es adicional a la notificación a la AEPD y tiene como objetivo que las personas puedan tomar medidas para protegerse.

Sanciones por incumplimiento

El incumplimiento del artículo 33 puede conllevar sanciones de hasta 10 millones de euros o el 2% del volumen de negocio anual global. Si la infracción se vincula además a una vulneración de los principios del tratamiento (artículo 5) o a una falta de responsabilidad proactiva (artículo 24), la sanción puede escalar hasta 20 millones de euros o el 4% de la facturación global.

Cómo proteger tu empresa ante brechas de datos de proveedores en la nube

El caso ServiceNow no es excepcional. Miles de empresas españolas dependen de plataformas SaaS para gestionar datos de empleados, clientes y operaciones. Cuando esas plataformas sufren una brecha de datos, la empresa responsable del tratamiento sigue siendo igualmente responsable ante el RGPD. Estas son las medidas esenciales que toda empresa debe implementar.

1. Revisar y actualizar los contratos con encargados del tratamiento

El artículo 28 del RGPD exige que los contratos con proveedores cloud incluyan cláusulas específicas sobre notificación de brechas. Si tu contrato con un proveedor SaaS no especifica que deben notificarte «sin dilación indebida» en caso de incidente de seguridad, estás en una posición de vulnerabilidad legal.

2. Establecer un protocolo interno de respuesta a incidentes

Cuando recibes una notificación de brecha de un proveedor, el reloj de las 72 horas empieza a correr. Tu empresa necesita saber exactamente qué pasos dar: evaluar el riesgo para los afectados, notificar a la AEPD si procede y, si el riesgo es alto, comunicarlo a las personas afectadas.

3. Mantener un registro de actividades de tratamiento actualizado

Saber exactamente qué datos procesa cada proveedor externo, con qué finalidad y bajo qué base legal es fundamental para poder evaluar rápidamente el impacto de una brecha. Un registro desactualizado puede convertir horas críticas en días de confusión.

4. Contar con un Delegado de Protección de Datos (DPO)

Las organizaciones que procesan datos a gran escala deben designar un DPO que actúe como punto de contacto con la AEPD y coordine la respuesta ante incidentes. En muchos casos, externalizar esta figura es la solución más eficiente para pymes y empresas medianas.

Si no tienes estos procesos implementados, desde DataIbérica podemos ayudarte a establecerlos. Consulta nuestros servicios de protección de datos y descubre cómo adaptar tu empresa a las exigencias del RGPD.

Preguntas frecuentes sobre brechas de datos y obligaciones RGPD

¿Qué debo hacer si mi proveedor cloud sufre una brecha de datos?

Evalúa inmediatamente qué datos de carácter personal fueron afectados y si suponen un riesgo para los derechos de las personas. Si existe ese riesgo, debes notificar a la AEPD en un máximo de 72 horas desde que tienes conocimiento del incidente. Si el riesgo es alto, también debes comunicarlo directamente a los afectados.

¿Es ServiceNow responsable ante el RGPD por esta brecha?

ServiceNow actúa generalmente como encargado del tratamiento para sus clientes empresariales. Bajo el artículo 33.2 del RGPD, el encargado tiene obligación de notificar al responsable sin dilación indebida tras conocer un incidente. Si ese plazo no se respetó, ServiceNow podría ser objeto de investigación por las autoridades supervisoras europeas, incluida la AEPD.

¿Mi empresa puede ser sancionada si la brecha la causó un proveedor externo?

Sí. Si no has verificado que tu contrato con el proveedor cumple el artículo 28 del RGPD, o si no notificas a la AEPD en el plazo de 72 horas cuando procede, puedes ser sancionado como responsable del tratamiento aunque el origen técnico del incidente sea externo.

¿Cuándo hay que notificar la brecha directamente a los afectados?

Cuando la brecha suponga un alto riesgo para los derechos y libertades de las personas afectadas: por ejemplo, si se expusieron datos bancarios, credenciales de acceso, datos de salud o cualquier dato que pueda derivar en suplantación de identidad o fraude. La comunicación debe realizarse sin dilación indebida según el artículo 34 del RGPD.

¿Qué información debe contener la notificación a la AEPD?

Debe incluir: la naturaleza de la brecha y tipo de datos comprometidos, el número aproximado de personas afectadas, los datos de contacto del DPO o responsable, las posibles consecuencias y las medidas adoptadas. La notificación se realiza a través de la sede electrónica de la AEPD. Si no tienes toda la información en 72 horas, puedes hacer una notificación inicial y completarla progresivamente.

Conclusión: el RGPD no espera a que tu proveedor te avise

La brecha de datos de ServiceNow de junio de 2026 es un caso de manual: una vulnerabilidad técnica real, una comunicación tardía y opaca, y miles de empresas que durante cuatro días no sabían que sus datos habían podido estar comprometidos. El cumplimiento del RGPD no es solo responsabilidad de los grandes proveedores tecnológicos —es tu responsabilidad como empresa que trata datos de personas.

Conocer tus obligaciones, tener un protocolo de respuesta a incidentes documentado y contar con contratos de encargado del tratamiento bien redactados marca la diferencia entre una gestión impecable y una multa de seis cifras. Si necesitas revisar el cumplimiento de tu empresa, contacta con DataIbérica y solicita una consulta gratuita con nuestro equipo.

Ahora ya puedes cumplir con todas las normativas de forma sencilla y económica

Más artículos
Llamar ahora WhatsApp
jQuery(window).on('load', function() { setTimeout(function() { jQuery('.elementor-accordion-item').each(function() { jQuery(this).removeClass('elementor-active'); jQuery(this).find('.elementor-tab-content').hide(); }); }, 500); });