# Informar a los clientes tras un incidente

> Informar a los clientes tras una brecha de datos: cuándo se aplica el art. 34 del RGPD, cómo llegar a cada grupo y por qué los avisos no llevan enlaces de acceso.

Fuente: https://phpsos.de/es/blog/kunden-nach-vorfall-informieren/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** quien debe o quiere informar a los clientes tras una brecha de datos decide primero con el delegado de protección de datos y el abogado si existe una obligación según el art. 34 del RGPD, y aclara si los clientes empresariales son ellos mismos los responsables. Después vienen los grupos de clientes, los canales seguros, un servicio de atención al cliente preparado y un mensaje final. Los avisos no contienen enlaces de acceso, para que no sirvan de plantilla para el phishing. Esta página es información general y no constituye asesoramiento jurídico.

## El correo que todos temen

El servidor está limpio, la vulnerabilidad cerrada, la informática forense tiene los primeros resultados. Ahora hay sobre la mesa una pregunta que a muchos directivos les gustaría evitar: ¿tenemos que decírselo a nuestros clientes? Y, si es así, ¿cómo hacerlo sin causar más daño que el propio incidente?

La situación en torno a PHP2Shell ha planteado de nuevo esta pregunta a muchas empresas, incluso sin intrusión. Los sitios web estuvieron desconectados de forma preventiva, los clientes preguntaban y, según la experiencia, los estafadores aprovechan estas situaciones para enviar mensajes falsos. Cómo se estructura en general la comunicación de crisis, en qué orden y con qué contenidos, lo describe [Comunicación de crisis tras un ataque](https://phpsos.de/es/compliance/krisenkommunikation/). Este artículo va un paso más allá: la decisión, los grupos de clientes y la aplicación práctica.

## Informar a los clientes tras una brecha de datos: ¿obligación o decisión?

El art. 34 del RGPD exige comunicar sin dilación indebida a los afectados cuando una violación de la seguridad de los datos personales entrañe probablemente un alto riesgo para sus derechos y libertades. La comunicación describe la naturaleza de la violación en un lenguaje claro y sencillo e incluye como mínimo un punto de contacto, las probables consecuencias y las medidas adoptadas o previstas.

El art. 34, apdo. 3, enumera excepciones: si los datos son ininteligibles para personas no autorizadas, por ejemplo mediante cifrado; si medidas posteriores eliminan probablemente el alto riesgo; o si la comunicación supusiera un esfuerzo desproporcionado, en cuyo caso se sustituye por una comunicación pública. Si se da alguna de estas excepciones es una valoración jurídica del caso concreto. Corresponde al delegado de protección de datos y al abogado, igual que la notificación a la autoridad de control; véase [Obligación de notificación del RGPD: 72 horas tras el incidente](https://phpsos.de/es/compliance/dsgvo-meldepflicht-72-stunden/).

Incluso sin obligación puede ser razonable informar. Los clientes que se enteran del incidente por otra vía pierden la confianza más rápido que los que lo oyen de usted.

Queda la cuestión del momento. Quien informa demasiado pronto quizá tenga que corregir sus afirmaciones. Quien espera demasiado corre el riesgo de que mientras tanto los clientes sufran daños, por ejemplo por phishing con direcciones filtradas. Un término medio acreditado: comunicar pronto lo que está establecido y lo que los propios clientes pueden hacer, y anunciar expresamente que seguirá más información. «Sin dilación indebida» en el sentido del art. 34 no significa esperar al final de la investigación.

## A qué clientes se llega y cómo

No todos los clientes necesitan el mismo mensaje. Distinga al menos tres grupos:

| Grupo de clientes | Su rol | Qué significa para la información |
|---|---|---|
| Clientes particulares con cuenta o pedido | normalmente responsable | valorar la comunicación según el art. 34, lenguaje comprensible, recomendaciones concretas |
| Clientes empresariales cuyos datos usa usted para fines propios | normalmente responsable | información objetiva a interlocutores designados, valoración para sus propias obligaciones |
| Clientes empresariales para los que trata datos por encargo | encargado del tratamiento | información sin dilación indebida según el art. 33, apdo. 2, apoyo en sus notificaciones |

El tercer grupo suele pasarse por alto. Si usted opera, por ejemplo, tiendas o portales para clientes, estos suelen ser ellos mismos responsables y deben cumplir sus propias obligaciones de notificación. Para ello necesitan su información de forma rápida y completa.

## Elegir canales sin favorecer el phishing

El canal más seguro es el que los clientes ya conocen. Han dado buen resultado:

- **Correo electrónico desde la dirección de remitente habitual**, sin enlaces de acceso ni archivos adjuntos, con la indicación de abrir uno mismo el sitio web.
- **Aviso tras el inicio de sesión** en la cuenta de cliente, en cuanto el sistema vuelva a funcionar con seguridad.
- **Aviso en el sitio web**, como complemento público o, donde lo prevea el art. 34, apdo. 3, como comunicación pública.
- **Carta** para clientes sin dirección de correo actual o con datos especialmente sensibles.
- **Teléfono y atención al cliente** como punto de contacto para consultas, con un número que los clientes ya conozcan de su sitio web o de la factura.

> **Importante:**
> Indique expresamente en cada comunicación que nunca pedirá por correo ni por teléfono contraseñas, códigos o datos de pago. Tras incidentes conocidos, los estafadores envían con gusto mensajes que parecen suyos.

## De la decisión al mensaje final

Así puede ser el procedimiento en la práctica:

1. **Fijar los hechos:** qué está probado, qué es probable, qué se desconoce. Solo lo probado sale al exterior.
2. **Obtener la valoración jurídica:** obligación según el art. 34, rol frente a los clientes empresariales, coordinación con la notificación a la autoridad.
3. **Definir los grupos de clientes y los canales**, extraer la lista de distribución del propio sistema, no de una copia posiblemente manipulada.
4. **Preparar la atención al cliente:** preguntas y respuestas internas, un discurso claro, derivación de los casos difíciles a un servicio designado.
5. **Formular recomendaciones para los clientes:** por ejemplo cambiar la contraseña si los datos de acceso pudieran estar afectados y estar atentos a mensajes sospechosos.
6. **Enviar y documentar:** a quién se informó, cuándo y por qué canal.
7. **Dar seguimiento:** comunicar los nuevos hallazgos y enviar un mensaje final cuando termine la investigación.

Quien ha fijado internamente las vías de contacto de antemano ahorra mucho tiempo; véase [Contactos de emergencia: ¿a quién hay que avisar y cuándo?](https://phpsos.de/es/blog/notfallkontakte-liste/). Los pasos técnicos que deberían preceder a la información los resume la [lista de comprobación tras un hackeo](https://phpsos.de/es/ratgeber/checkliste-nach-dem-hack/).

## ¿Cómo ayuda PHP SOS en concreto?

- Entregamos los hechos técnicos del incidente preparados de modo que el delegado de protección de datos y el abogado puedan valorar las obligaciones.
- Revisamos sus comunicaciones a los clientes en cuanto a corrección técnica y a que no den pistas a los atacantes.
- Nos aseguramos de que las listas de distribución y las cuentas de cliente procedan de un sistema limpio antes de que usted envíe.
- Mediante la [respuesta a incidentes](https://phpsos.de/es/leistungen/incident-response/) entregamos los hallazgos para los mensajes posteriores y finales al ritmo acordado.

**Conclusión:** una buena información a los clientes está revisada jurídicamente, separada por grupos, enviada por canales seguros y se lleva hasta el final. Esta página es información general y no constituye asesoramiento jurídico; la decisión en el caso concreto la toma usted con el delegado de protección de datos y el abogado.


## Preguntas frecuentes

**¿Cuándo debo informar a los clientes tras una brecha de datos?**  
Según el art. 34 del RGPD, cuando sea probable que la violación entrañe un alto riesgo para los derechos y libertades de los afectados. Hay excepciones, por ejemplo si los datos están cifrados de forma eficaz. La valoración la hace usted con el delegado de protección de datos y el abogado; esta página no constituye asesoramiento jurídico.

**¿Qué ocurre si trato datos por encargo de mis clientes empresariales?**  
Entonces sus clientes suelen ser ellos mismos los responsables. Según el art. 33, apdo. 2, del RGPD, el encargado del tratamiento informa al responsable sin dilación indebida tras tener conocimiento de una violación de la seguridad de los datos. La notificación a la autoridad y a los afectados sigue siendo asunto de su cliente.

**¿Puedo informar a los clientes aunque no exista obligación?**  
Sí. Una información voluntaria puede ser razonable, por ejemplo si el sitio web estuvo fuera de línea de forma preventiva por PHP2Shell o si los clientes hacen preguntas. Es importante mencionar solo hechos comprobados y no dar un falso aviso de que todo está en orden.

**¿Cómo evito que los estafadores imiten mi comunicación?**  
Prescinda en el aviso de enlaces de acceso y de archivos adjuntos, remita a su sitio web conocido e indique expresamente por qué vías no pedirá nunca contraseñas ni datos de pago.

## Fuentes

- [RGPD, art. 34](https://dsgvo-gesetz.de/art-34-dsgvo/)
- [RGPD, art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI (Oficina Federal alemana para la Seguridad de la Información)](https://www.bsi.bund.de/)