Web hackeada: qué obligaciones legales tienes y en qué orden

Si acabas de descubrir que te han atacado la web, para un segundo antes de borrar nada. El instinto es restaurar la copia de seguridad, respirar aliviado y seguir trabajando. Ese es exactamente el movimiento que te deja sin pruebas, sin saber por dónde entraron y, si había datos de clientes por medio, en mala posición si mañana tienes que explicárselo a la Agencia Española de Protección de Datos. En este artículo tienes qué te obliga la ley en un caso así y, sobre todo, en qué orden hay que hacer cada cosa.

Un aviso honesto por delante: esto es una guía operativa escrita desde el lado técnico, no asesoramiento jurídico. Cuando hay datos sensibles, muchos afectados o un contrato con penalizaciones de por medio, la decisión final la debe revisar un abogado. Lo que sí puedes hacer tú, y hoy, es no estropear el terreno.

Primero contener, pero sin destruir las pruebas

Hay dos cosas que hay que hacer casi a la vez y que parecen contradictorias: frenar el daño y conservar el escenario. El equilibrio práctico es este.

Esto sí, ahora mismo:

Congela una copia íntegra antes de tocar nada. Si tienes SSH: tar -czf ~/evidencia-AAAAMMDD.tar.gz public_html y mysqldump -u USUARIO -p BASE_DATOS > ~/evidencia-AAAAMMDD.sql. Si solo tienes panel, comprime public_html desde el gestor de archivos y exporta la base de datos completa desde phpMyAdmin. Descárgatelo todo a tu ordenador y no lo toques más.
Salva los registros de acceso antes de que roten. En cPanel los tienes en Métricas → Accesos sin procesar; en Plesk, en Registros. Muchos hostings compartidos solo guardan unos días, así que este paso caduca.
Si la web está sirviendo phishing, descargas maliciosas o redirecciones a terceros, córtala ya. Ahí el daño ya no es solo tuyo y esperar te añade problemas.

Esto todavía no:

No restaures la copia de seguridad encima.
No borres los archivos raros que has encontrado: son la prueba de por dónde entraron y de cuándo.
No lances un plugin de seguridad en modo «reparar y eliminar»: te limpia y, de paso, te borra la única pista que tenías.
No reinstales WordPress por encima ni cambies la versión de PHP «por probar».

Cuando tengas el paquete de evidencias descargado, calcula su huella para poder demostrar después que no lo has modificado. En Windows: certutil -hashfile evidencia-AAAAMMDD.tar.gz SHA256. En Linux o macOS: sha256sum evidencia-AAAAMMDD.tar.gz. Apunta ese valor en un documento con la fecha y la hora, y ya tienes algo que sostener frente a un cliente, un seguro o un inspector.

Cómo saber si ha habido acceso a datos personales y no solo cambio de portada

Esta es la pregunta que decide todo lo que viene después. Que te cambien la portada por una pantalla negra con un mensaje es un problema de integridad y de imagen, pero puede que ningún dato personal haya salido de ahí. Que alguien haya podido leer tu tabla de pedidos es otra cosa completamente distinta.

Estos son los sitios concretos donde mirar en un WordPress:

Usuarios. La tabla wp_users tiene correos y contraseñas cifradas. Si entraron con un administrador, se los llevaron.
Pedidos. En WooCommerce, los datos de facturación y envío viven en wp_postmeta (claves que empiezan por _billing_ y _shipping_) o en las tablas propias de pedidos si tienes el almacenamiento nuevo activado.
Formularios que guardan copia. Contact Form 7 con Flamingo, WPForms, Gravity Forms o Forminator archivan cada envío en la base de datos. Mucha gente no sabe que lleva ahí tres años de mensajes con teléfonos y direcciones.
Reservas, citas, cursos y listas de correo. Cualquier plugin de este tipo es, en la práctica, un fichero de clientes.

Y en los registros de acceso, busca estas señales:

Peticiones POST a /wp-login.php con respuesta 302 desde una IP que no reconoces (login correcto).
Accesos con respuesta 200 a /wp-admin/export.php. Esa es la exportación nativa de WordPress: si aparece, alguien se llevó contenido en un fichero.
Ficheros .php servidos desde /wp-content/uploads/. Ahí nunca debería ejecutarse código.
Respuestas con un tamaño en bytes anormalmente grande: suele indicar volcados de base de datos o descargas masivas.
Ficheros con nombres tipo adminer.php, db.php o dump.sql en la raíz.

Sé honesto contigo mismo con el resultado. Si los registros ya se han rotado y no puedes descartar el acceso, la respuesta correcta no es «entonces no ha pasado nada»: es asumir el peor escenario razonable y decirlo con esas palabras cuando notifiques. La AEPD entiende mucho mejor un «no puedo descartarlo por falta de registros» que un optimismo que luego se cae.

El reloj de las 72 horas: cuándo arranca en un ataque a WordPress

El plazo no empieza cuando te atacaron, ni cuando te enteraste de que algo iba raro. Empieza cuando tienes conocimiento con un grado razonable de certeza de que ha habido una brecha de datos personales. En un ataque a WordPress, eso suele ser el momento en el que confirmas que hubo acceso a la base de datos o al panel de administración, no el momento en que viste la portada cambiada.

Ojo con la tentación de estirar ese punto de partida. La norma exige investigar sin demora indebida: no puedes retrasar la confirmación a conveniencia y luego decir que el reloj arrancó el viernes. Un margen razonable para el diagnóstico inicial es de horas, no de semanas.

Y si llegas justo, se puede notificar por fases: una notificación inicial con lo que sabes y una ampliación posterior cuando tengas el alcance cerrado. Es mejor que llegar tarde. El procedimiento completo, campo por campo, lo tienes en la guía sobre cómo notificar una brecha a la AEPD dentro del plazo de 72 horas.

Hay una segunda obligación que se olvida a menudo: si la brecha entraña un riesgo alto para los derechos de los afectados, además de notificar a la Agencia hay que comunicárselo a ellos, en lenguaje claro y sin rodeos. Cuándo se cruza ese umbral y cómo se redacta ese aviso lo desarrollamos en el artículo sobre cuándo hay que comunicar la brecha a los afectados.

Denuncia a Policía o Guardia Civil: cuándo aporta algo y cuándo no

Denunciar y notificar son cosas distintas y no se sustituyen. La denuncia es un procedimiento penal; la notificación a la AEPD es una obligación administrativa. Puedes tener que hacer las dos, una o ninguna.

La denuncia aporta cuando: hay perjuicio económico (fraude, cargos, transferencias desviadas), hay extorsión o secuestro de datos, ha habido suplantación de tu empresa frente a clientes, necesitas el atestado para tu seguro o vas a reclamar a un tercero por vía civil.

La denuncia aporta poco cuando: es un cambio de portada en una web pequeña, sin datos comprometidos, sin autoría identificable y sin perjuicio cuantificable. Se admitirá, pero lo más probable es que acabe archivada. Decirte lo contrario sería venderte humo.

Si vas, ve preparado: cronología con horas, direcciones IP sospechosas, capturas de pantalla, el paquete de evidencias en un soporte con su huella SHA-256 y los datos de contacto de tu hosting. Puedes presentarla en cualquier comisaría de la Policía Nacional o cuartel de la Guardia Civil. Para orientación previa gratuita, el INCIBE atiende en el 017.

Qué documentar desde la hora cero

Abre un documento y no lo cierres hasta que esto termine. Debe contener:

Cronología con hora y zona horaria de cada hallazgo y cada acción tuya. «17:40 CEST: cambio contraseña de cPanel» vale oro dentro de tres semanas.
Inventario de lo afectado: qué webs, qué bases de datos, qué buzones de correo, qué cuentas.
Quién tenía acceso antes del incidente: usuarios de WordPress, cuentas FTP, accesos de la agencia, del diseñador y del becario que estuvo en verano.
La huella de la copia forense y dónde la guardas.
Capturas de pantalla con el reloj del sistema visible.
Los correos con el hosting, tal cual, sin reescribir.

Además, tengas que notificar o no, el RGPD te obliga a llevar un registro interno de incidentes de seguridad. Es un documento sencillo, pero tiene que existir antes de que alguien te lo pida. Encaja dentro del bloque de obligaciones de protección de datos y ciberseguridad que afectan a una pyme española.

Obligaciones frente a clientes con contrato y frente a tu seguro

Si tratas datos por cuenta de otra empresa (llevas su web, su CRM o su tienda), tú eres encargado del tratamiento y estás obligado a avisar al responsable sin dilación indebida. No dentro de 72 horas: en cuanto lo sepas, porque su plazo depende de tu aviso.

Y en sentido inverso: si tu web la lleva una agencia, es el momento de releer qué firmaste. La mayoría de contratos de mantenimiento no dicen quién limpia, quién paga ni en cuánto tiempo avisa. Las cláusulas que deberían estar ahí las repasamos en el artículo sobre las cláusulas de seguridad que casi nunca aparecen en un contrato de mantenimiento web.

Con el seguro, dos cosas: los plazos de comunicación de un ciberriesgo suelen ser muy cortos y algunas pólizas exigen que no manipules los sistemas antes del peritaje. Lee la póliza antes de limpiar, no después. Si limpias primero, puedes quedarte sin cobertura por haber destruido lo que el perito tenía que ver.

El error de restaurar la copia y no investigar la causa

Es el final infeliz más repetido. Restauras, la web vuelve, y a los diez días está igual. Por tres motivos que se dan casi siempre juntos:

La copia es posterior a la intrusión y ya lleva dentro la puerta trasera.
La vía de entrada (un plugin sin actualizar, una contraseña reutilizada, un acceso FTP filtrado) sigue abierta.
Al restaurar has borrado lo único que te habría dicho cuál de las dos anteriores era.

El orden que funciona es siempre el mismo: congelar, analizar, limpiar, cerrar la vía de entrada y verificar desde fuera. Restaurar es una herramienta dentro del paso «limpiar», no un atajo que se salta los demás.

Cuándo puedes con esto tú solo y cuándo no

Te lo digo claro, porque no todo requiere pagar a nadie. Puedes hacerlo tú si tienes una web escaparate sin formularios que guarden datos, sin tienda, con una copia de seguridad anterior al incidente que te conste limpia, y sabes razonablemente por dónde entraron (por ejemplo, un plugin que llevaba dos años sin actualizar).

Busca ayuda si hay tienda con pedidos, datos de salud o financieros, varias webs en el mismo servidor, sospecha de acceso al correo del dominio, extorsión de por medio, o si vas a tener que sostener por escrito ante la AEPD o ante un cliente qué pasó exactamente. En ese caso ya no estás limpiando una web: estás construyendo una versión de los hechos que tiene que aguantar preguntas.

Si el reloj ya ha empezado a correr y necesitas que alguien tome el mando de las primeras horas sin romper las pruebas, aquí puedes ver cómo trabajamos una respuesta a incidentes desde el minuto uno: contención, evidencias con cadena de custodia, alcance real de los datos afectados y el informe que después vas a necesitar enseñar.

Seguir leyendo en esta sección

Ver todo en Brechas y obligaciones tras un incidente → · Mapa completo del sitio