Imagen2: images/en-wordpress-responder-no-basta-sin-contingencia-previa-2.webp
Schema_json: {"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://mantenwp.com/en-wordpress-responder-no-basta-sin-contingencia-previa/#article","headline":"En WordPress, responder no basta sin contingencia previa","description":"Cuando la web deja de vender... Respuesta a incidentes y contingencia para aislar el fallo, proteger datos y recuperar el servicio.","datePublished":"2026-07-22T09:15:00+00:00","dateModified":"2026-07-22T09:15:00+00:00","author":{"@type":"Person","name":"Josu Barrios","url":"https://mantenwp.com/author/josu-barrios/"},"publisher":{"@type":"Organization","name":"Mantenimiento WordPress","logo":{"@type":"ImageObject","url":"https://mantenwp.com/images/logo.png","width":200,"height":60}},"image":{"@type":"ImageObject","url":"https://mantenwp.com/images/en-wordpress-responder-no-basta-sin-contingencia-previa.jpg","width":1200,"height":630},"url":"https://mantenwp.com/en-wordpress-responder-no-basta-sin-contingencia-previa/","mainEntityOfPage":"https://mantenwp.com/en-wordpress-responder-no-basta-sin-contingencia-previa/","inLanguage":"es","keywords":"respuesta a incidentes y contingencia, WordPress, hackeo, ransomware, plan de contingencia, continuidad de negocio, RGPD, copias de seguridad, recuperación del servicio"},{"@type":"BreadcrumbList","@id":"https://mantenwp.com/en-wordpress-responder-no-basta-sin-contingencia-previa/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://mantenwp.com/"},{"@type":"ListItem","position":2,"name":"Seguridad","item":"https://mantenwp.com/category/seguridad/"},{"@type":"ListItem","position":3,"name":"En WordPress, responder no basta sin contingencia previa","item":"https://mantenwp.com/en-wordpress-responder-no-basta-sin-contingencia-previa/"}]}]}
Ante un hackeo, ransomware o caída crítica en WordPress, los primeros 60 minutos determinan el impacto: aislar el sitio, preservar evidencias, comprobar las copias y avisar a las personas responsables evita agravar la pérdida de datos, ventas o confianza.
La respuesta a incidentes y contingencia permite detectar, contener y resolver un ataque o fallo, mantener la actividad cuando el servicio no opera y fijar responsables, copias verificadas, comunicación, requisitos RGPD y recuperación probada.
Qué hacer en la primera hora tras un hackeo
La primera hora debe servir para contener el incidente, preservar datos y evitar que el problema siga creciendo.
Aísla la web sin destruir pruebas
Aísla WordPress con modo mantenimiento, una regla del Web Application Firewall o un bloqueo temporal desde el hosting. Haz capturas y guarda registros del servidor, correos de alerta, archivos sospechosos y lista de usuarios; anota hora, síntoma, detector y cada cambio aplicado. No borres malware, usuarios ni registros antes de copiar evidencias: si el atacante sigue conectado, corta primero el acceso público y pide apoyo técnico urgente.
Escala según el daño real
Escala a dirección, mantenimiento WordPress y hosting cuando el problema afecte pagos, formularios, áreas privadas o campañas activas. Si el proveedor puede revisar registros, pide conservar logs de acceso, PHP y correo durante al menos 7 a 30 días, según su política. INCIBE-CERT ofrece pautas para organizaciones españolas; para entidades públicas, el organismo de referencia es CCN-CERT.
Una web caída no siempre es un ciberataque, pero un ataque tratado como una simple caída puede destruir pruebas y alargar la recuperación.
Antes de un incidente, verifica contactos, accesos de emergencia, copias de seguridad verificadas, inventario de proveedores y el tiempo objetivo de recuperación de cada servicio crítico. Durante un hackeo en WordPress, registra la alerta, aísla el entorno, conserva evidencias, clasifica la severidad, decide si se activa el canal alternativo y comunica cada decisión con hora y responsable. Después, valida formularios, pagos, usuarios, registros y monitorización antes de declarar la recuperación del servicio; documenta la causa raíz, las cuentas rotadas, el RTO y RPO alcanzados, las tareas pendientes y la fecha del siguiente simulacro.
Esta lista convierte el plan de contingencia en una rutina repetible y auditable.
Incidente, contingencia y continuidad: qué activa cada plan
La respuesta técnica controla la causa, la contingencia mantiene funciones esenciales de forma temporal y la continuidad de negocio protege la actividad global antes, durante y después de una crisis.
| Plan | Cuándo se activa | Responsable | Cierre medible |
|---|
| Respuesta a incidentes | Malware, acceso extraño o fallo grave | Responsable técnico | Causa eliminada y servicio validado |
| Contingencia | Se supera el RTO o falla un proceso crítico | Dirección | Canal principal recuperado |
| Continuidad de negocio | Impacto en varios servicios o equipos | Dirección y coordinación | Operación estable y revisión cerrada |
Umbrales que activan la contingencia
Activa la contingencia si el pago o las reservas están parados más de 30 minutos, si más del 20 % de usuarios no puede acceder o si no puede confirmarse una copia recuperable antes de vencer el RTO. Puede consistir en tomar pedidos por teléfono, habilitar un formulario externo, pausar campañas o mostrar una página de estado mientras se repara el servicio.
Roles que evitan esperas peligrosas
Flujo de decisión para una web WordPress crítica
Alerta
→
Aislar y registrar
→
Medir RTO y alcance
→
Activar contingencia
→
Recuperar y validar
Técnico: ejecuta. Dirección: autoriza contingencia. DPO o legal: valora la brecha. Comunicación: informa con un mensaje único.
Una matriz RACI evita que la gestión de incidentes dependa de decisiones improvisadas. El responsable técnico suele ser quien ejecuta el aislamiento, recopila evidencias y coordina la recuperación del servicio; seguridad valida la erradicación y el alcance; dirección autoriza gastos, paradas y el plan de contingencia; legal y el DPO evalúan obligaciones contractuales y de protección de datos. Comunicación prepara mensajes aprobados; RR. HH. interviene si hay credenciales de empleados comprometidas, y el hosting, la pasarela de pago o la agencia WordPress aportan registros y soporte. También conviene designar un suplente para cada función y dejar por escrito quién tiene autoridad para activar cada medida.
Recupera WordPress sin volver a abrir la puerta
La recuperación segura exige probar la copia fuera del entorno afectado, corregir la causa y cambiar todos los accesos expuestos antes de publicar.
Comprueba la copia antes de restaurarla
Restaura primero en un dominio de pruebas y comprueba acceso, formularios, emails, pedidos, medios e integraciones. Compara la fecha de la copia con la hora estimada del compromiso: una copia creada después del ataque puede conservar malware. Revisa también usuarios administradores, claves API, tareas programadas, redirecciones, archivos modificados y credenciales de correo, SFTP, base de datos y pasarela de pago.
🛒
Producto recomendado
Un disco externo puede ayudar a conservar una copia cifrada fuera del servidor cuando se combina con almacenamiento remoto y pruebas de restauración. No sustituye las copias automatizadas ni la revisión periódica.
- Permite guardar una copia desconectada del hosting tras cada revisión mensual
- Facilita trasladar archivos y base de datos para una restauración de prueba local
- Reduce el riesgo de perder todas las copias si el servidor sufre ransomware
Ver en Amazon →
Caso: ransomware en una tienda online
Ante una extensión vulnerable que cifra archivos y bloquea el checkout, el equipo debe aislar la web, mantener atención por teléfono, conservar logs, restaurar en pruebas una copia anterior y rotar credenciales. Pagar un rescate no garantiza recuperar datos ni eliminar el acceso del atacante; identifica el punto de entrada, limpia persistencias y vigila los registros posteriores.
Comunica, mide y cierra el incidente con pruebas
La comunicación debe basarse en hechos confirmados y salir de una fuente coordinada: técnico para alcance, dirección para contingencia, legal o DPO para RGPD y comunicación para clientes.
Si una brecha de datos personales entraña riesgo para las personas, el RGPD puede exigir notificarla a la Agencia Española de Protección de Datos en un máximo de 72 horas. Mide detección, escalado, MTTR, RTO, RPO y simulacros superados para comprobar que el plan funciona.
Plantilla mínima para cada incidente
- Identificación: fecha, hora, detector, servicio WordPress afectado y nivel de severidad.
- Evidencias: capturas, URLs, logs, usuarios, correos y copias preservadas.
- Decisiones: quién aisló, quién activó contingencia, canal alternativo y hora de cada decisión.
- Recuperación: copia elegida, vulnerabilidad corregida, credenciales rotadas y pruebas superadas.
- Cierre: impacto real, comunicación enviada, obligaciones RGPD y tareas con fecha.
Revisa el plan después de cada prueba
Haz un simulacro entre una y dos veces al año y repítelo tras cambiar de hosting, pasarela de pago o sistema de copias. ISO 22301 orienta ejercicios de continuidad e ISO/IEC 27001 ayuda a ordenar controles y riesgos.
Un plan completo puede ser excesivo para una web personal sin ingresos, datos sensibles ni servicios críticos. Aun así, mantén actualizaciones, copias verificadas y un procedimiento básico de recuperación. Si hay señales de compromiso activo, este contenido no sustituye la intervención de un especialista forense o de seguridad.
El flujo de comunicación debe comenzar con un aviso interno al responsable técnico y a dirección, indicando servicio afectado, hora de detección, severidad, medidas aplicadas y próxima actualización prevista. Si intervienen proveedores, solicita por un canal trazable la preservación de registros, la confirmación de sus actuaciones y un contacto de escalado disponible fuera de horario. Los clientes solo deben recibir información confirmada, con el impacto conocido, el canal alternativo y la frecuencia de nuevas comunicaciones.
Cuando exista una brecha de datos personales, el responsable del tratamiento, con apoyo del DPO o legal, debe documentar la evaluación del riesgo, valorar la notificación a la autoridad de control y, si el riesgo es alto, informar a las personas afectadas sin dilación indebida.
Preguntas frecuentes
¿Qué es la respuesta a incidentes?
Es el proceso para detectar, contener, investigar, eliminar y recuperar un servicio tras un ataque o fallo grave. En WordPress incluye revisar archivos, base de datos, usuarios, plugins, temas y registros.
¿Cuándo activo un plan de contingencia?
Actívalo cuando el servicio no pueda recuperarse dentro del RTO, afecte pagos o reservas, o deje sin acceso a una parte relevante de usuarios.
¿Restaurar una copia elimina el malware?
No siempre: la copia puede contener código malicioso o el atacante puede conservar una contraseña, clave API o puerta trasera fuera de ella.
¿Cuándo debo avisar a la AEPD?
Debes valorar la notificación cuando una brecha afecta datos personales y genera riesgo; si procede, el plazo máximo es de 72 horas desde que conoces la brecha.
Deja decidido quién actúa antes de la caída
Un buen plan asigna nombres, teléfonos y autoridad para aislar, activar contingencia y comunicar; define hoy el RTO y RPO de cada web crítica.
Prueba una restauración real antes de confiar en las copias. La seguridad WordPress consiste en saber qué hacer en los primeros minutos, sostener el negocio y volver sin dejar la misma puerta abierta.
