Cuando pensamos en una brecha de seguridad, es habitual imaginar ataques sofisticados: un ransomware, explotación de una vulnerabilidad Zero-Day, una intrusión en los sistemas o un ataque de denegación de servicio. Sin embargo, no siempre hace falta nada de eso.
El incidente sufrido por Revolut a mediados de septiembre de 2026 es un ejemplo de ello. En este caso concreto alguien contactó con la compañía haciéndose pasar por una agencia gubernamental personal de Revolut no verificó que esa solicitud fuese legítima y respondió como si se tratase de un requerimiento oficial. Ante esto, quedaron expuestos datos personales de clientes de Revolut a un tercero no autorizado (quien se hizo pasar por una agencia gubernamental) y consecuentemente el resultado fue una brecha de seguridad.
Según la información conocida del incidente, los hechos fueron los siguientes. Los atacantes utilizaron el dominio legítimo de una agencia gubernamental para solicitar información sobre determinados clientes de Revolut.
Lo característico de este incidente está en que no se trataba simplemente de un correo imitando y/o suplantando a una autoridad, sino que la comunicación procedía de un dominio real, haciendo que la petición resultara auténtica.
Los atacantes buscaban obtener información que posteriormente pudiera servir para realizar nuevas solicitudes fraudulentas. Una vez detectado el ataque, es cierto que Revolut actuó adoptando medidas para contenerlo, entre ellas bloquear la dirección utilizada por los atacantes y comunicar el incidente a las autoridades correspondientes.
Cuando el phishing no intenta engañar al cliente.
El Instituto Nacional de Ciberseguridad (INCIBE) encuadra este tipo de situaciones en ataques de suplantación de identidad en el ámbito empresarial, relacionados con técnicas de phishing.
La mecánica habitual es sencilla: el atacante suplanta a una persona o entidad en la que la víctima confía para conseguir que una comunicación fraudulenta parezca legítima y, como consecuencia, obtener información de interés.
Sin embargo, el caso de Revolut tiene una peculiaridad ya que, en cierto modo, de dos víctimas dentro de una misma cadena de engaño. Por un lado, la agencia gubernamental cuya identidad fue utilizada fraudulentamente. Y, por otro, Revolut, que confió en esa identidad y terminó facilitando información de sus propios clientes.
Es precisamente aquí en donde está una de las principales lecciones del incidente:
- La seguridad no termina en el perímetro tecnológico, implica a la dirección.
Cuando una empresa gestiona datos de terceros, el riesgo no está únicamente en sus servidores, aplicaciones, redes o sistemas de autenticación. También está en las decisiones que toman las personas.
En muchas organizaciones, uno de los puntos más vulnerables puede ser la confianza depositada en quien realiza una solicitud y, sobre todo, el procedimiento utilizado para determinar si esa petición es realmente legítima.
- Amenaza, vulnerabilidad e incidente: tres conceptos dentro de una misma cadena.
Conviene diferenciar tres conceptos que a menudo mezclamos: amenaza, vulnerabilidad e incidente.
En este caso, la amenaza era la solicitud fraudulenta enviada por los atacantes, la vulnerabilidad no estaba necesariamente en un sistema informático, sino en la ausencia o en el incumplimiento de un procedimiento que obligara a verificar la petición por un canal independiente antes de facilitar información de clientes. Como resultado, el envío de la información genera la existencia de un incidente.
Una amenaza no tiene por qué provocar daños por sí sola si no encuentra una vulnerabilidad que permita explotarla, y, en este caso demuestra que incluso las herramientas técnicas de seguridad tienen límites, un filtro antiphishing tradicional puede no detectar el engaño y la cuestión pasa a ser organizativa y procedimental.
- Sin hackeo también puede existir una brecha.
Que no haya una intrusión directa en los sistemas no significa que no exista una brecha de seguridad.
Desde la perspectiva de la protección de datos, el RGPD define en su artículo 4.12 la violación de la seguridad de los datos personales como aquella que provoque, entre otros efectos, la comunicación o el acceso no autorizados a datos personales.
Además, la obligación de proteger los datos no se limita a instalar herramientas de seguridad, el artículo 5.2 del RGPD establece el principio de responsabilidad proactiva, mientras que el artículo 32 exige adoptar medidas técnicas y organizativas adecuadas para garantizar un nivel de seguridad acorde con los riesgos. En un caso como este, el problema está más relacionado con un fallo de procedimiento de Dirección.
- Un dominio legítimo no convierte una solicitud en legítima.
Esta es probablemente uno de los principales aprendizajes que cualquier organización debería extraer del caso, de forma que, un correo aparentemente tenga un dominio real solo permite acreditar el origen técnico de la comunicación, no demostrando por sí mismo que la persona que realiza la petición tenga autoridad para solicitar información ni que exista una base jurídica que obligue a entregarlos. Es decir, autenticar al remitente no es lo mismo que validar la solicitud.
Aunque todavía no conozcamos todos los detalles sobre cómo los atacantes consiguieron utilizar el dominio legítimo, existen algunas comprobaciones básicas que deberían formar parte de cualquier procedimiento interno cuando se recibe un requerimiento de una autoridad:
- ¿Quién está solicitando los datos?
- ¿Tiene realmente competencia para solicitarlos?
- ¿Cuál es el fundamento jurídico de la petición?
- ¿Qué información concreta se está solicitando?
- ¿Es necesario entregar todos esos datos?
- ¿Existe un canal independiente para verificar la solicitud?
E incluso cuando una solicitud sea legítima, no significa que pueda entregarse todo el expediente del cliente, sino que deberá facilitarse únicamente la información necesaria para cumplir con la finalidad correspondiente, cumpliendo con el principio de minimización de datos del artículo 5.1.c del RGPD.
Otra cuestión a destacar que merece una especial atención del análisis de este caso concreto es la tipología de información afectada. Los documentos de identidad, fotografías o imágenes del rostro, datos de contacto, información bancaria, IBAN o historial de transacciones pueden proporcionar a un atacante una cantidad considerable de información para intentar suplantar la identidad de una persona o realizar nuevos fraudes.
Por eso, una brecha de estas características no termina cuando se bloquea al atacante, hay que analizar el riesgo para las personas afectadas y determinar qué obligaciones de comunicación se activan.
Entre ellas se encuentran:
- Notificación a la autoridad de control: debe realizarse sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que la organización tiene conocimiento de la violación, conforme al artículo 33 del RGPD.
- Comunicación a las personas afectadas: cuando la violación pueda entrañar un alto riesgo para los derechos y libertades de las personas, el artículo 34 del RGPD contempla la obligación de comunicarla a los afectados sin dilación indebida.
Por tanto, gestionar una brecha no consiste únicamente en averiguar qué ha ocurrido. También implica tomar decisiones rápidas sobre a quién informar, qué información comunicar y en qué plazo.
En el caso de una entidad financiera como Revolut, el análisis no termina necesariamente en el RGPD, ya que, como otras entidades, en función del sector al que pertenecen, deben cumplir con otras obligaciones complementarias al RGPD.
En el sector financiero en el que nos situamos con Revolut, entra en aplicación el Reglamento (UE) 2022/2554, conocido como DORA (Digital Operational Resilience Act), el cual establece un marco específico para la resiliencia operativa digital del sector financiero y es aplicable desde el 17 de enero de 2025.
DORA incluye dentro de su ámbito a diferentes tipos de entidades financieras, entre ellas las entidades de crédito y las entidades de dinero electrónico, entre otras categorías contempladas en su artículo 2.
Esto significa que un incidente originado mediante ingeniería social no queda automáticamente fuera del ámbito de la resiliencia operativa digital por el simple hecho de que no haya existido una intrusión informática.
Entre otras cuestiones, DORA establece obligaciones relacionadas con:
- La gestión del riesgo TIC, incluyendo cuestiones de gobernanza, organización, identificación de riesgos y establecimiento de controles.
- La gestión y notificación de incidentes relacionados con las TIC, con criterios específicos para determinar cuándo un incidente puede considerarse grave y con obligaciones de comunicación propias.
- La gestión del riesgo asociado a terceros proveedores de servicios TIC, cuando estos intervengan en el proceso.
En términos prácticos, esto significa que la gestión de una brecha de seguridad en una entidad financiera ya no puede analizarse únicamente desde la perspectiva del RGPD, sino que habrá de tenerse en cuenta las obligaciones de resiliencia operativa y gestión de incidentes que correspondan al sector financiero pero todas complementarias.
Hay una lección especialmente relevante detrás de todo esto: la ciberseguridad no puede delegarse por completo en el departamento de sistemas. Es decir, ante una brecha de seguridad no solo se debe actuar ante un problema técnico, sino que acompaña y es una decisión de dirección. Preguntas aparentemente sencillas como «¿a quién entregamos estos datos?» o «¿qué protocolo seguimos ante una solicitud oficial?» tienen consecuencias legales, económicas y estratégicas. Por eso, deben formar parte de la gobernanza de la organización.
Ante un incidente de este tipo, algunas de las primeras preguntas que debería plantearse la dirección son:
- ¿Qué sabemos con certeza y qué son todavía hipótesis?
- ¿Qué personas pueden haberse visto afectadas?
- ¿A quién tenemos que informar?
- ¿Qué autoridades o reguladores deben ser notificados?
- ¿Qué debemos comunicar a los afectados?
- ¿Qué opciones tenemos y qué consecuencias tiene cada una?
Un error sería tomar estas decisiones cuando el incidente ya ha ocurrido, la organización debería contar previamente con un procedimiento conocido por los trabajadores, con responsables definidos y con un protocolo claro de verificación de solicitudes de información previa entrega de información.
En este punto, cabe preguntarse qué aplicaría a cada organización. Pues bien, el caso de Revolut permite extraer algunas medidas prácticas que pueden aplicarse en empresas de prácticamente cualquier sector.
- Verifica por un canal independiente. No respondas automáticamente al remitente.
- Exige el fundamento jurídico y centraliza los requerimientos a través de un Delegado de Protección de Datos).
- Detección y alerta interna inmediata.
- Evidencia y evalúa.
- Contención en las primeras 24 horas.
- Notificación conforme a los plazos legales que apliquen.
- Entrega mínima e imprescindible.
- Simulacros periódicos.
El caso Revolut no fue un ataque a sus sistemas, sino un fallo procedimental a través de una solicitud fraudulenta enviada desde un dominio legítimo que fue tratada como auténtica lo que acabó provocando una comunicación de datos de clientes. A efectos del RGPD, eso constituye una violación de la seguridad de los datos personales con independencia de que haya existido o no una intrusión técnica.
Además, Revolut está sujeto a un marco regulatorio más amplio debido a su actividad bancaria y de criptoactivos quedando dentro del ámbito de DORA, que refuerza los controles sobre las solicitudes externas de información y la gestión y notificación de incidentes.
La lección es sencilla: un dominio legítimo no implica que una petición sea legítima. Antes de entregar cualquier dato, hay que verificar quién lo solicita, con qué base y qué información es realmente necesaria. La seguridad también depende de estos controles y de que la organización los respalde.
Si te interesa conocer más información sobre violaciones de seguridad puedes leer otras entradas de nuestro blog pinchando aquí y aquí.
