# Comunicación de crisis tras un ataque

> Comunicación de crisis tras un ciberataque: a quién informar y cuándo, qué debe incluir un aviso a los clientes y qué afirmaciones conviene evitar.

Fuente: https://phpsos.de/es/compliance/krisenkommunikation/  
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:** una buena comunicación de crisis tras un ciberataque es rápida, honesta y coherente. Informe primero internamente, después a los afectados y a los socios, y diga solo lo que está confirmado, separado con claridad de lo que aún se está investigando. Las obligaciones de comunicación, por ejemplo según el art. 34 del RGPD, deben acordarse con el delegado de protección de datos y el asesoramiento jurídico; esta página no es asesoramiento jurídico.

## Por qué la comunicación forma parte del tratamiento del incidente

Un ataque a un servidor web es, al principio, un problema técnico. Pero muy pronto se convierte también en una cuestión de confianza: los clientes notan un sitio web inaccesible, los socios reciben correos llamativos, los empleados preguntan. Quien entonces calla o responde de forma contradictoria pierde más confianza que por el propio incidente.

La situación actual en torno a PHP2Shell lo hace tangible. Muchas empresas han desconectado sus sitios web de la red como medida preventiva o los han sometido a un mantenimiento urgente. Eso no significa automáticamente que las hayan hackeado. Justo esa distinción debería poder explicarla hacia el exterior con claridad y calma.

## Comunicación de crisis tras un ciberataque: el orden correcto

Un orden contrastado evita que grupos importantes se enteren por la prensa o por terceros:

1. **Equipo de crisis interno:** dirección, área técnica, protección de datos y, en su caso, asesoramiento jurídico y aseguradora. Aquí se decide qué se dice.
2. **Empleados:** breve información interna, con la petición de derivar las consultas al punto designado y con indicaciones de precaución ante correos sospechosos.
3. **Autoridades, donde sea necesario:** por ejemplo la autoridad de protección de datos según el art. 33 del RGPD, el BSI (Oficina Federal Alemana de Seguridad de la Información) si existe obligación NIS2, la policía en caso de denuncia. El orden lo acuerda con su asesoramiento jurídico.
4. **Clientes y socios afectados:** directamente y, si es posible, antes de una declaración pública.
5. **Público:** aviso en el sitio web y, en su caso, comunicado de prensa.

Según el art. 34 del RGPD, los afectados deben ser informados sin dilación indebida cuando es probable que una violación de la protección de datos entrañe para ellos un alto riesgo. Los fundamentos se explican en [Obligación de notificación del RGPD: 72 horas](https://phpsos.de/es/compliance/dsgvo-meldepflicht-72-stunden/).

## Qué debe incluir un aviso

Un buen aviso es breve y responde a las preguntas que se plantean los afectados. Esta estructura ha dado buen resultado:

| Apartado | Contenido |
|---|---|
| ¿Qué ha pasado? | Descripción objetiva en palabras sencillas, con el periodo |
| ¿Qué sabemos y qué no? | Hechos confirmados separados de la investigación en curso |
| ¿Quién está afectado? | Grupos de personas o de datos, en la medida en que se sepa |
| ¿Qué hemos hecho? | Medidas inmediatas, intervención de especialistas y autoridades |
| ¿Qué debería hacer usted? | Recomendaciones concretas, como cambiar la contraseña o estar atento al phishing |
| ¿Cómo puede contactarnos? | Punto de contacto fijo para consultas |

Anuncie cuándo volverá a informar y cumpla esa promesa. También un «todavía sin novedades» a la hora anunciada genera confianza.

> **Consejo:**
> Prepare plantillas para la información interna, el aviso a los clientes y el aviso en el sitio web antes de que ocurra algo. En una emergencia solo habrá que insertar los hechos.

## Lo que es mejor evitar

Algunas formulaciones y comportamientos perjudican con regularidad:

- **Falsa tranquilidad precipitada:** «No se han sustraído datos» solo es admisible si está demostrado. Un parche instalado no demuestra que antes no haya pasado nada.
- **Quitar importancia:** expresiones como «pequeño incidente técnico» resultan poco honestas si más tarde se sabe más.
- **Culpar a otros:** las alusiones al proveedor de hosting, a proveedores de servicios o a fabricantes no ayudan a los afectados y pueden tener consecuencias jurídicas.
- **Detalles técnicos útiles para los atacantes:** las vulnerabilidades concretas de sus sistemas no pertenecen a los comunicados públicos.
- **Garantías:** afirmaciones como «completamente seguro» o «inhackeable» no se pueden sostener.

## Sitio web, buscadores y oleada de phishing

Tras un ataque a un sitio web suelen sumarse dos fenómenos. Primero, Google puede mostrar una advertencia si se ha encontrado código malicioso; cómo hacer que se retire tras la limpieza se explica en [Eliminar la advertencia de Google](https://phpsos.de/es/ratgeber/google-warnung-entfernen/). Segundo, los estafadores aprovechan los incidentes conocidos para enviar correos falsos en nombre de la empresa afectada. Advierta de ello de forma activa a sus clientes e indique por qué vías se comunica usted realmente.

Si desconecta el sitio web de la red como medida preventiva, basta una página estática sencilla con un breve aviso y una vía de contacto que no dependa del servidor afectado.

Cuando el incidente se ha cerrado, merece la pena una comunicación final a todos a quienes informó antes: qué ha resultado de la investigación, qué medidas se han aplicado de forma duradera y a quién se puede seguir acudiendo. Muchas empresas omiten este paso porque la presión disminuye. Justo él demuestra, sin embargo, que se tomó en serio el incidente. Haga además una valoración interna de lo que fue bien y lo que no en la comunicación, y adapte en consecuencia las plantillas y las responsabilidades de su plan de emergencia.

## ¿Cómo ayuda PHP SOS en concreto?

- Entregamos los hechos técnicos de forma comprensible y separamos con claridad lo demostrado, lo probable y lo desconocido.
- Revisamos los borradores de sus avisos en cuanto a su exactitud técnica y a detalles que podrían ayudar a los atacantes.
- Ponemos a disposición con rapidez una página de mantenimiento estática, que funciona con independencia del sistema afectado.
- Mediante la [respuesta a incidentes](https://phpsos.de/es/leistungen/incident-response/) mantenemos la técnica al ritmo de su comunicación, para que puedan cumplirse las promesas sobre el estado de la información.


## Preguntas frecuentes

**¿Debemos hacer público un ataque mientras no esté todo claro?**  
Depende de la situación, de las obligaciones y de los afectados. A menudo es mejor un aviso breve y objetivo con lo que se sabe que guardar silencio, porque si no los clientes y socios se enteran por otras fuentes. Acuerde el momento con el asesoramiento jurídico y la aseguradora.

**¿Qué no debería figurar en ningún caso en un aviso a los clientes?**  
Suposiciones que parezcan hechos, acusaciones contra terceros, detalles técnicos que ayuden a los atacantes y promesas que no pueda cumplir con seguridad. Fórmulas como completamente descartado solo deberían usarse si están demostradas.

**¿Quién debería hablar hacia el exterior?**  
Una persona designada, normalmente de la dirección o de la comunicación corporativa, apoyada por el área técnica y el asesoramiento jurídico. Todos los demás remiten a ese punto. Así las declaraciones se mantienen coherentes.

**¿Tenemos que desconectar nuestro sitio web y explicarlo?**  
Si desconecta el sitio web de la red como medida preventiva, ayuda un aviso breve, por ejemplo en una página de mantenimiento estática. No tiene por qué ser técnico. Desconectar preventivamente no significa automáticamente que un ataque haya tenido éxito.

## Fuentes

- [RGPD, art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI (Oficina Federal Alemana de Seguridad de la Información)](https://www.bsi.bund.de/)
- [Ayuda de Google Search Console](https://support.google.com/webmasters/)
