La brecha de seguridad en PEUSA comunicada el 7 de septiembre de 2026 vuelve a poner sobre la mesa uno de los riesgos más importantes para cualquier empresa: la seguridad de los proveedores externos.
Hidroelèctrica del Valira, S.L., informó de que el 2 de septiembre tuvo conocimiento de un incidente que afectó a uno de los servicios web de un proveedor externo que presta servicios a la compañía y actúa también como encargado del tratamiento de datos personales. Según la información disponible, una vulnerabilidad permitió que un tercero malicioso accediera durante varias horas del 1 de septiembre a determinados datos personales de clientes.
La empresa reaccionó suspendiendo temporalmente el servicio afectado, activando su póliza de ciberriesgos, reforzando la protección y monitorización de las conexiones entrantes y notificando el incidente tanto a la Agencia Española de Protección de Datos como a la Policía Nacional.
Para una pyme, el caso deja una enseñanza muy clara:
tu ciberseguridad no depende únicamente de tus propios servidores, equipos o firewall. También depende de los proveedores que acceden, procesan o almacenan tus datos.
¿Qué ocurrió en la brecha de seguridad en PEUSA?
La propia compañía explica que el incidente no se produjo directamente en sus sistemas principales, sino en un servicio web de un proveedor externo.
Ese proveedor actuaba como encargado del tratamiento de determinados datos personales.
Según la investigación inicial:
- existía una vulnerabilidad en el servicio web;
- un tercero malicioso consiguió acceder;
- el acceso se produjo durante varias horas;
- hubo acceso no autorizado y exfiltración de información.
Este último punto es importante.
No estamos hablando únicamente de:
“alguien entró en un sistema”.
La compañía confirma que determinados datos personales fueron exfiltrados.
¿Qué datos quedaron expuestos?
Según la comunicación oficial, el incidente afectó a diferentes categorías de información personal:
- nombre y apellidos;
- DNI o NIF;
- dirección postal;
- correo electrónico;
- teléfono;
- IBAN;
- dirección de facturación;
- datos del punto de suministro;
- información de consumo.
PEUSA también indicó que:
no se vieron afectadas categorías especiales de datos ni contraseñas de acceso.
Por tanto, el incidente no implica automáticamente compromiso de credenciales.
Sin embargo, la combinación de:
identidad + contacto + IBAN + información contractual
puede tener valor para ataques posteriores.
La brecha no termina cuando se cierra la vulnerabilidad
Uno de los errores más frecuentes es pensar que un incidente termina cuando:
“el agujero ya está corregido”.
No necesariamente.
Cuando existe exfiltración de datos, aparece una segunda fase de riesgo.
Los datos pueden utilizarse posteriormente para:
- phishing;
- smishing;
- vishing;
- suplantación;
- ingeniería social;
- fraude.
La propia compañía advierte expresamente sobre el riesgo de comunicaciones fraudulentas, llamadas, mensajes e intentos de suplantación.
Un atacante con contexto es mucho más convincente
Imagine recibir un correo que simplemente dice:
“Actualice sus datos bancarios.”
Puede resultar sospechoso.
Pero ahora imagine:
“Hemos detectado una incidencia en su suministro. Para verificar su contrato asociado al punto X necesitamos confirmar los últimos datos de facturación.”
Si el atacante conoce:
- nombre;
- dirección;
- correo;
- suministro;
- IBAN;
el mensaje puede resultar mucho más creíble.
Por eso una fuga de datos puede seguir generando riesgo semanas o meses después.
Brecha de seguridad en PEUSA: el problema del proveedor externo
El aspecto más importante del caso no es solo la vulnerabilidad.
Es que se encontraba en un tercero.
Este tipo de incidente se conoce normalmente como riesgo de:
cadena de suministro
o:
third-party risk.
Una empresa moderna depende continuamente de proveedores.
Por ejemplo:
- software de gestión;
- ERP;
- Microsoft 365;
- hosting;
- páginas web;
- soporte IT;
- copias;
- CRM;
- nóminas;
- desarrollo;
- plataformas cloud.
Cada proveedor puede convertirse en una extensión de nuestra superficie de ataque.
Externalizar un servicio no externaliza el riesgo
Desde el punto de vista operativo podemos decir:
“eso lo gestiona el proveedor”.
Pero desde el punto de vista de seguridad y protección de datos, la situación es más compleja.
Si ese tercero procesa información de nuestros clientes:
también forma parte de nuestro ecosistema de riesgo.
Eso significa que una empresa debería conocer:
- qué datos procesa;
- dónde están;
- quién puede acceder;
- cómo se autentican;
- cómo se actualiza el servicio;
- cómo se detectan incidentes;
- cuánto tiempo se conservan logs.
No basta con firmar un contrato con un proveedor
Un contrato es necesario.
Pero no sustituye:
- MFA;
- parcheado;
- cifrado;
- monitorización;
- copias;
- control de accesos;
- respuesta a incidentes.
La seguridad real no se demuestra únicamente con documentación.
También requiere controles técnicos.
Un servicio web público es una superficie de ataque
El incidente afectó a un servicio web publicado.
Eso implica una característica fundamental:
estaba accesible desde Internet.
Y todo servicio publicado en Internet debería considerarse parte del perímetro de seguridad.
Un portal web puede tener:
- fallos de software;
- librerías vulnerables;
- credenciales débiles;
- configuraciones erróneas;
- APIs inseguras.
Por tanto, también necesita mantenimiento.
Una web no es “solo una página”
Muchas empresas todavía diferencian mentalmente:
“la informática”
y:
“la página web”.
Pero una aplicación web puede conectarse a:
- bases de datos;
- APIs;
- servicios de terceros;
- datos de clientes.
Por tanto, una vulnerabilidad web puede terminar afectando información crítica.
Gestión de vulnerabilidades en servicios publicados
Un servicio accesible desde Internet debería revisarse periódicamente.
Entre otras medidas:
- versiones;
- CMS;
- plugins;
- frameworks;
- dependencias;
- certificados;
- configuraciones;
- logs.
Además, cuando aparece una vulnerabilidad crítica, el tiempo de reacción es importante.
Brecha de seguridad en PEUSA y detección
PEUSA explica que, tras detectar el incidente, reforzó la protección y monitorización de las conexiones entrantes a los servicios web publicados.
Este punto es especialmente relevante.
La seguridad no consiste solamente en prevenir.
También necesitamos detectar.
Porque ningún sistema puede garantizar:
riesgo cero.
La cuestión es:
¿cuánto tardamos en saber que algo está ocurriendo?
Tiempo de detección frente a tiempo de exposición
Podemos imaginar dos escenarios.
Escenario A
Un atacante entra.
Nadie revisa nada.
Permanece semanas.
Escenario B
Un atacante entra.
Se detecta actividad anómala.
El equipo actúa en horas.
El impacto potencial cambia completamente.
Por eso la monitorización es una parte fundamental de la seguridad.
Suspender temporalmente un servicio puede ser una buena decisión
PEUSA decidió suspender temporalmente el servicio web afectado.
Esto puede parecer drástico.
Pero en determinadas situaciones:
disponibilidad temporal
puede ser menos importante que:
seguir exponiendo datos.
En respuesta a incidentes hay momentos en los que debemos elegir entre:
mantener el servicio
o:
contener el ataque.
La seguridad puede exigir detener temporalmente una plataforma.
Contener primero, investigar después
En muchos incidentes la secuencia correcta puede ser:
detectar
↓
contener
↓
preservar evidencias
↓
investigar
↓
corregir
↓
restaurar
Si intentamos arreglar precipitadamente sin preservar información, podemos destruir evidencias útiles.
La póliza de ciberriesgos también fue activada
La compañía informó de la activación de su póliza de ciberriesgos.
Esto demuestra que la ciberseguridad no es únicamente una cuestión técnica.
También tiene dimensión:
- legal;
- económica;
- operativa;
- reputacional.
Una póliza puede ayudar a gestionar determinadas consecuencias.
Pero no sustituye las medidas preventivas.
Un seguro ciber no sustituye a la seguridad
Podemos compararlo con un seguro de automóvil.
Tener seguro no significa:
dejar de mantener los frenos.
Del mismo modo, una póliza ciber no debería sustituir:
- actualizaciones;
- backups;
- MFA;
- monitorización;
- respuesta.
Es una capa adicional de gestión del riesgo.
Notificación a la AEPD
La compañía notificó el incidente a la Agencia Española de Protección de Datos.
Cuando una brecha de datos personales puede suponer riesgo para los derechos y libertades de las personas, el RGPD contempla la notificación a la autoridad de control.
Por eso una empresa necesita saber:
qué datos se han visto afectados
y:
qué riesgo genera la exposición.
No basta con conocer qué servidor falló.
Notificación a la Policía Nacional
PEUSA también presentó denuncia ante la Policía Nacional.
Esto evidencia nuevamente que un incidente puede tener varias dimensiones simultáneas:
técnica
legal
regulatoria
penal
Por eso una respuesta profesional requiere coordinación.
Brecha de seguridad en PEUSA: no se conoce uso fraudulento en este momento
La compañía señala que, en el momento de publicar su comunicación, no tenía constancia de un uso fraudulento de los datos relacionado con el incidente.
Este matiz es importante.
No debemos afirmar que:
“ya se están utilizando los datos para fraude.”
Lo confirmado es:
hubo acceso no autorizado y exfiltración.
El uso posterior todavía es un riesgo potencial.
Tampoco sabemos todos los detalles técnicos
La comunicación oficial confirma que existía una vulnerabilidad.
Pero no publica:
- CVE;
- producto concreto;
- versión;
- método exacto de explotación.
Por tanto, sería incorrecto inventar:
“el atacante utilizó esta vulnerabilidad concreta”.
La información disponible no lo permite.
¿Por qué un proveedor puede no publicar el CVE?
Existen varias razones.
La investigación puede estar abierta.
Puede tratarse de:
- una configuración;
- una vulnerabilidad privada;
- software propio;
- un fallo todavía no divulgado.
También puede evitarse publicar detalles que faciliten nuevos ataques.
Por eso debemos trabajar únicamente con lo confirmado.
Qué puede aprender una empresa de la brecha de seguridad en PEUSA
El caso deja varias enseñanzas.
1. Tus proveedores forman parte de tu superficie de ataque
Aunque el servidor no sea tuyo.
2. Las aplicaciones web necesitan mantenimiento
No son activos estáticos.
3. Los datos exfiltrados pueden alimentar futuros fraudes
El riesgo continúa después del incidente.
4. La monitorización importa
Cuanto antes detectamos, antes podemos contener.
5. Hay que conservar evidencias
Sin logs, investigar resulta mucho más complicado.
¿Qué proveedores tienen datos de tu empresa?
Una pyme debería poder responder.
Por ejemplo:
| Proveedor | Servicio | Datos |
|---|---|---|
| Microsoft 365 | correo | comunicaciones |
| ERP | gestión | clientes y facturación |
| asesoría | laboral/fiscal | empleados y empresa |
| hosting | web | formularios y bases de datos |
| backup | copias | información corporativa |
Si no sabemos qué información posee cada proveedor:
no podemos evaluar correctamente el riesgo.
Clasificar proveedores por criticidad
No todos son iguales.
Podemos diferenciar:
Bajo riesgo
Proveedor sin acceso a datos sensibles.
Medio riesgo
Proveedor con acceso limitado.
Alto riesgo
Proveedor que almacena:
- clientes;
- documentación;
- datos financieros;
- credenciales;
- copias.
Cuanto mayor sea el riesgo:
más controles necesitamos.
Preguntas de seguridad para un proveedor
Antes de contratar determinados servicios, conviene preguntar:
¿Utilizan MFA?
¿Cifran información?
¿Cómo gestionan vulnerabilidades?
¿Realizan backups?
¿Tienen logs?
¿Cómo notifican un incidente?
¿Subcontratan servicios?
Estas preguntas pueden revelar mucho sobre el nivel de madurez del proveedor.
El proveedor del proveedor también cuenta
Una empresa puede contratar:
Proveedor A
pero ese proveedor puede utilizar:
Proveedor B
para hosting.
Y:
Proveedor C
para copias.
Eso crea una cadena.
Por tanto, el riesgo de terceros también puede incluir:
cuartos proveedores.
Esta complejidad es habitual en servicios cloud.
Brecha de seguridad en PEUSA y phishing posterior
Los datos expuestos pueden utilizarse para construir mensajes mucho más personalizados.
Imagine un atacante que conoce:
- nombre;
- teléfono;
- correo;
- dirección;
- suministro.
Puede realizar:
smishing
por SMS.
vishing
mediante llamada.
phishing
por email.
Cuanto más contexto tiene:
más creíble puede resultar.
Un IBAN no permite vaciar automáticamente una cuenta
También conviene evitar alarmismo.
Conocer un IBAN no significa automáticamente:
poder retirar dinero libremente.
Pero puede utilizarse como información de contexto para:
- suplantación;
- fraude;
- ingeniería social.
Por tanto, sigue siendo información sensible desde el punto de vista operativo.
Cambios bancarios: siempre mediante doble verificación
En empresas recomendamos una medida muy sencilla.
Ante un correo que diga:
“hemos cambiado nuestro IBAN”
no debemos modificarlo automáticamente.
Hay que verificarlo mediante:
un segundo canal independiente.
Por ejemplo:
llamada a un teléfono conocido previamente.
No al número incluido en el mismo correo.
El caso también afecta al BEC
Los ataques de Business Email Compromise pueden aprovechar información real para construir fraudes.
Por ejemplo:
nombre de proveedor + factura + IBAN + contacto
puede utilizarse para crear comunicaciones convincentes.
Por eso los procedimientos internos son tan importantes como el antivirus.
SIEM para centralizar eventos
Cuando una empresa tiene:
- servidores;
- firewall;
- Microsoft 365;
- endpoints;
- NAS;
cada elemento genera registros.
Un SIEM Wazuh para empresas puede ayudar a centralizar esa información.
Así podemos investigar con mayor contexto.
¿Qué habría que buscar ante una vulnerabilidad web?
Dependiendo del incidente:
- conexiones entrantes;
- errores;
- autenticaciones;
- ejecución de procesos;
- transferencias;
- cambios.
Pero para poder buscar:
primero necesitamos tener los logs.
Los logs son especialmente importantes después de descubrir una vulnerabilidad
Supongamos que hoy sabemos que un servicio era vulnerable.
La siguiente pregunta es:
¿desde cuándo?
Y después:
¿alguien lo explotó antes de corregirlo?
Sin histórico:
la investigación puede terminar rápidamente.
Hasta 400 días de histórico
En nuestros servicios podemos conservar hasta 400 días de logs de las fuentes integradas.
Esto puede permitir búsquedas retrospectivas.
Por ejemplo:
“¿Esta IP apareció anteriormente?”
“¿Hubo accesos parecidos hace tres meses?”
“¿Cuándo comenzó realmente la actividad?”
Eso puede ser clave en una investigación.
Brecha de seguridad en PEUSA y SOC
Un SIEM puede generar señales.
Pero alguien debe interpretarlas.
Una conexión desde Internet puede ser:
normal
o:
anómala.
La diferencia depende del contexto.
Nuestro SOC analiza:
- origen;
- destino;
- comportamiento;
- frecuencia;
- eventos relacionados.
Así se puede decidir si corresponde actuar.
Herramienta y analista cumplen funciones diferentes
Podemos resumirlo:
Firewall registra.
Endpoint detecta.
SIEM centraliza y correlaciona.
SOC analiza.
Cada capa aporta algo diferente.
Endpoint / EDR sigue siendo importante
Aunque el incidente comience en una aplicación web, una intrusión puede terminar afectando servidores o equipos.
Un Endpoint / EDR puede proporcionar señales relacionadas con:
- procesos;
- archivos;
- ejecución;
- persistencia.
Puede consultar nuestras soluciones de Endpoint y firewall para empresas.
Firewall y servicios publicados
Los servicios web expuestos deberían encontrarse detrás de controles adecuados.
Dependiendo del entorno:
- firewall;
- WAF;
- filtrado;
- restricción de origen;
- monitorización.
Sin embargo:
un firewall no corrige una vulnerabilidad dentro de una aplicación.
Por eso necesitamos también:
parcheado.
Seguridad por capas
El caso PEUSA muestra perfectamente la necesidad de varias capas.
Aplicación actualizada
Firewall
MFA
Endpoint
Monitorización
SIEM
SOC
Backup
plan de respuesta
Una única herramienta no puede cubrir todos los escenarios.
¿Qué debería hacer una empresa después de conocer un incidente en un proveedor?
Primero:
confirmar si utiliza ese proveedor.
Después:
qué datos tiene.
Luego:
qué información puede haberse visto afectada.
A continuación:
- cambiar credenciales si procede;
- revisar actividad;
- advertir a usuarios;
- reforzar controles.
No todas las brechas requieren las mismas acciones.
No cambiar contraseñas indiscriminadamente si no se han afectado
En este caso PEUSA ha confirmado que las contraseñas no se encuentran entre los datos afectados.
Por tanto, no debemos afirmar que:
todos los clientes deban cambiar inmediatamente sus contraseñas por este incidente.
Sí conviene estar alerta frente a intentos de suplantación.
Pero las medidas deben basarse en el alcance real.
Ciberseguridad para empresas: el proveedor también debe estar dentro del modelo
En GHM Soluciones Informáticas trabajamos la ciberseguridad para empresas desde una visión más amplia que instalar herramientas.
Revisamos aspectos como:
- infraestructura;
- Microsoft 365;
- firewall;
- Endpoint / EDR;
- acceso remoto;
- logs;
- SIEM;
- proveedores;
- copias.
Porque el riesgo real aparece en las conexiones entre todos ellos.
Una pyme también necesita gestionar terceros
No hace falta ser una energética para sufrir una brecha de proveedor.
Una asesoría depende de:
- software laboral;
- almacenamiento;
- correo.
Un despacho jurídico:
- gestión documental;
- cloud.
Una administración de fincas:
- aplicaciones;
- banca;
- Microsoft 365.
Una ingeniería:
- hosting;
- colaboración;
- NAS.
Todas tienen terceros.
Conclusión: la brecha de seguridad en PEUSA demuestra que el perímetro ya incluye a los proveedores
La brecha de seguridad en PEUSA comenzó en un servicio web gestionado por un proveedor externo.
Una vulnerabilidad permitió que un tercero accediera durante varias horas a información personal de clientes el 1 de septiembre de 2026. PEUSA tuvo conocimiento del incidente el día 2 y lo comunicó públicamente el 7 de septiembre.
Los datos afectados incluyen información de identidad, contacto, facturación, IBAN y datos del suministro. No se vieron afectadas contraseñas ni categorías especiales de datos.
La empresa reaccionó mediante:
- suspensión del servicio afectado;
- activación de su póliza de ciberriesgos;
- refuerzo de monitorización;
- notificación a la AEPD;
- denuncia ante Policía Nacional.
Más allá del caso concreto, la enseñanza para cualquier organización es sencilla:
la ciberseguridad de una empresa incluye también a todos los proveedores que procesan sus datos.
Por eso deberíamos conocer:
quién tiene nuestros datos
qué sistemas utiliza
qué controles aplica
y:
cómo sabremos que algo ha ocurrido si su seguridad falla.
En GHM Soluciones Informáticas trabajamos con firewall administrado, Endpoint / EDR, Microsoft 365, SIEM Wazuh y análisis SOC, además de mantener hasta 400 días de histórico de logs en las fuentes integradas.
Porque cuando aparece una vulnerabilidad no basta con preguntar:
“¿ya está corregida?”
También necesitamos poder responder:
“¿podemos comprobar si alguien la explotó antes?”
Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre la brecha de seguridad en PEUSA
¿Cuándo ocurrió el incidente de PEUSA?
El acceso no autorizado se produjo durante varias horas del 1 de septiembre de 2026. La compañía tuvo conocimiento del incidente el día 2 y publicó la comunicación el 7 de septiembre.
¿Dónde se produjo la brecha?
En un servicio web de un proveedor externo que prestaba servicios a Hidroelèctrica del Valira y actuaba como encargado del tratamiento de datos personales.
¿Cómo ocurrió?
PEUSA indica que una vulnerabilidad permitió a un tercero malicioso acceder a determinados datos. La compañía no ha publicado en su comunicación el CVE ni el producto concreto afectado.
¿Hubo exfiltración de datos?
Sí. La comunicación de la empresa hace referencia expresamente al acceso no autorizado y a la exfiltración de los datos afectados.
¿Qué información quedó expuesta?
Nombre, apellidos, DNI/NIF, dirección postal, correo electrónico, teléfono, IBAN, datos de facturación, punto de suministro y consumo.
¿Se filtraron contraseñas?
No. PEUSA afirma que las contraseñas de acceso no se vieron afectadas.
¿Se afectaron datos especialmente protegidos?
La compañía indica que no se vieron afectadas categorías especiales de datos.
¿Se están utilizando ya los datos para cometer fraude?
PEUSA declaró que, en el momento de su comunicación, no tenía constancia de usos fraudulentos relacionados con el incidente.
¿Qué hizo la empresa tras detectar la brecha?
Suspendió temporalmente el servicio afectado, activó su póliza de ciberriesgos, reforzó protección y monitorización, notificó a la AEPD y presentó denuncia ante Policía Nacional.
¿Qué riesgos tienen ahora los clientes?
Principalmente potenciales intentos de phishing, smishing, vishing, suplantación y otras formas de ingeniería social utilizando los datos conocidos.
¿Debe un cliente cambiar sus contraseñas por este incidente?
La empresa indica que las contraseñas no estuvieron afectadas. Por tanto, el riesgo confirmado se centra en los datos personales exfiltrados y en posibles intentos posteriores de fraude.
¿Qué es un proveedor externo en ciberseguridad?
Es una organización que presta un servicio y que puede tener acceso, almacenar o procesar información de otra empresa.
¿Por qué un proveedor supone riesgo?
Porque una vulnerabilidad o brecha en sus sistemas puede afectar indirectamente a los datos y operaciones de sus clientes.
¿Cómo puede una empresa reducir el riesgo de proveedores?
Mediante evaluación previa, MFA, contratos adecuados, control de accesos, cifrado, monitorización, backups y procedimientos de comunicación de incidentes.
¿Qué aporta SIEM Wazuh?
Centraliza registros de diferentes sistemas y facilita búsquedas, correlación e investigación.
¿Qué aporta un SOC?
Analiza el contexto de los eventos para distinguir actividad legítima de situaciones sospechosas o que requieren actuación.
¿Por qué conservar 400 días de logs?
Porque una vulnerabilidad puede descubrirse meses después y puede ser necesario investigar retrospectivamente si ya existió actividad asociada.
¿Cuál es la principal enseñanza de este incidente?
Que la seguridad de tus datos depende también de la seguridad de los proveedores que los procesan.
