Una web hackeada tiene una habilidad bastante irritante: obligar a decidirlo todo cuando menos tiempo hay para pensar. Quién puede detener el checkout, dónde está la copia, quién habla con el hosting y quién autoriza volver a vender. Si esas respuestas viven en la cabeza de una sola persona, el problema ya viene con suplemento.
Este plan de recuperación de WordPress para 2027 sirve para dejar esas decisiones preparadas antes del incidente y ensayarlas sin tocar producción. Incluye una ficha copiable, responsabilidades, condiciones de reapertura y un ejercicio ficticio para descubrir huecos. No sustituye la investigación técnica ni certifica que una web esté limpia.
¿El incidente está ocurriendo ahora? Empieza por la evaluación de recuperación de WordPress hackeado. Un plan preparado ayuda; rellenar una plantilla mientras los visitantes siguen expuestos no debe retrasar la contención.
Qué debe resolver el plan, antes de hablar de herramientas
Separa tres resultados: recuperar el control, recuperar el servicio y recuperar la continuidad del negocio. Entrar al administrador resuelve una parte del primero. Ver la portada resuelve una parte del segundo. Ninguna de esas dos cosas demuestra que los pedidos, formularios o permisos estén bien.
Escribe qué necesita tu negocio para funcionar de forma segura: recibir solicitudes, permitir acceso de clientes, publicar información o vender. Prioriza esos recorridos y las personas que dependen de ellos. Una web corporativa sin tienda también puede perder contactos, documentos privados o correos de recuperación.
Después fija quién puede aceptar una interrupción y qué necesita saber para hacerlo. Evita prometer una recuperación en un número de horas todavía no probado. El plan debe permitir elegir un siguiente paso con información incompleta, dejando visible esa incertidumbre.
La ficha de recuperación que puedes copiar
Guarda una copia accesible aunque WordPress y el correo habitual no funcionen. Sustituye cada marcador por una referencia interna. Aquí van ubicaciones y responsables; las contraseñas pertenecen al gestor de secretos aprobado.
PLAN WP-2027 | versión y fecha de revisión:
Dominio y entorno de producción:
Responsable del incidente / sustituto:
Canal independiente y contacto del hosting:
Persona autorizada a contener / aprobar gastos:
Recorridos de negocio que debemos proteger:
Ubicación protegida de copias y registros:
Última restauración ensayada / resultado / límites:
Pérdida de datos tolerable propuesta / aprobada por:
Tiempo objetivo propuesto / prueba que lo respalda:
Responsable de conciliación de datos recientes:
Criterios de reapertura / quién los revisa:
Alternativa segura si falla la reapertura:
Próxima revisión / tareas pendientes / responsables:Una casilla vacía es una tarea, no una invitación a inventar el dato. Si nadie sabe cuándo se ensayó la restauración, escribe «sin prueba disponible». Si el hosting conserva registros durante un plazo concreto, anota la respuesta y su fecha, sin atribuirle una garantía distinta.
Añade la ubicación del inventario de proveedores: DNS, CDN, alojamiento, correo, copias, repositorio y pasarela cuando exista. La ficha enlaza esos documentos; no necesita convertirse en una enciclopedia con datos que caducarán sin que nadie los revise.
Cuatro responsabilidades que deben tener nombre
En una empresa pequeña, una persona puede llevar varios papeles. Lo que no conviene es que todos crean que la decisión pertenece a otro. Para cada función escribe titular, sustituto y forma de localizarlo fuera del correo de la web.
| Función | Decisión | Registro mínimo |
|---|---|---|
| Coordinación | Alcance, prioridades y escalado | Incidente, responsables y próxima revisión |
| Técnica y hosting | Contención, conservación y recuperación | Cambio, motivo, alcance y alternativa segura |
| Negocio | Conciliación y aceptación de recorridos | Datos pendientes, pruebas y aprobación |
| Comunicación | Mensajes aprobados y destinatarios | Hechos confirmados, hora y siguiente actualización |
Una aprobación comercial no convierte una duda técnica en una comprobación superada. Si dos funciones discrepan, registra el punto concreto y escala. Para posibles problemas con datos de clientes o pagos, activa los responsables y procedimientos correspondientes; este documento no determina obligaciones de comunicación.
Preparar acceso sin fabricar otra puerta trasera
Comprueba que el propietario puede demostrar titularidad al hosting y recuperar sus canales de control. El plan debe indicar qué procedimiento seguir si el correo de administrador también está comprometido. Mandar otro enlace de recuperación al mismo buzón no arregla esa dependencia.
Define acceso individual y limitado para quien intervenga, cómo se autoriza y cuándo se revoca. No dejes una cuenta administrativa compartida «por si acaso», ni contraseñas en la plantilla. La guía de recuperación segura del administrador bloqueado desarrolla ese recorrido técnico.
Ensaya la localización del contacto y la documentación con el propietario. Ver un nombre en el inventario no demuestra que responda, que conserve acceso o que su autorización siga vigente. El simulacro debe sacar esas dependencias a la luz con tiempo para resolverlas.
Copias: define qué recuperarías y qué perderías
Una copia tiene fecha, contenido, ubicación y estado de prueba. «Tenemos backup» deja demasiadas preguntas abiertas. Identifica si incluye archivos y base de datos, quién puede obtenerla y dónde podría restaurarse sin sobrescribir la única evidencia del incidente.
El objetivo de pérdida de datos tolerable se suele expresar como RPO; el tiempo objetivo para recuperar el servicio, como RTO. Son objetivos del negocio, no resultados por escribir las siglas. Si la prueba no alcanza lo previsto, registra la diferencia y decide qué inversión o cambio hace falta.
Para una tienda, compara la fecha de la copia con pedidos, pagos y movimientos posteriores. Para una web de captación, hazlo con formularios y CRM. Conserva las fuentes antes de decidir una restauración: la recuperación desde una copia sin reintroducir la intrusión necesita evaluar código, acceso y datos, además de disponibilidad.
Una referencia visual para ordenar decisiones
La idea útil es asociar cada incidencia con responsable y estado. Puedes hacerlo en un documento sencillo: «contenido», «pendiente de verificar» y «aprobado para reabrir» deben significar cosas distintas. Una barra de progreso bonita no sustituye la prueba que falta.
Simulacro original: el hosting propone restaurar ayer
El siguiente caso es ficticio. Es un ejercicio de mesa diseñado para esta plantilla, sin ejecutar un hackeo, restauración, compra ni cobro. No describe un cliente ni mide tiempos de recuperación. Usa seis tarjetas, por orden, y pide al equipo que escriba su decisión antes de leer la siguiente.
Escenario: una tienda WordPress recibe un aviso de redirección. El hosting ofrece una copia del día anterior; el administrador no puede entrar y existen pagos posteriores a esa copia. La pregunta no es quién encuentra antes el botón de restaurar, sino qué debe quedar resuelto para autorizar una intervención.
- Aviso sin alcance confirmado. Coordinación registra síntoma, hora y fuente; técnica propone contención adecuada al riesgo. Falta determinar alcance. No se marca «limpio» porque desaparezca una redirección.
- Copia disponible. Técnica identifica fecha, componentes y ubicación protegida. Pide conservar el estado actual y los registros antes de sobrescribir. La disponibilidad de la copia no demuestra que sea un punto de recuperación fiable.
- Correo de recuperación dudoso. El propietario activa el canal alternativo con el proveedor. Se documenta quién valida titularidad. Recuperar una sesión de WordPress no cierra todavía la cadena de acceso.
- Pagos posteriores. Negocio identifica la ventana de conciliación y su responsable. No repite cobros ni fuerza estados. La recuperación de datos recientes queda como condición explícita, enlazada a su expediente protegido.
- La web vuelve a cargar. Técnica entrega las comprobaciones y sus límites; negocio verifica los recorridos acordados. Cualquier prueba incompleta mantiene su estado. Nadie convierte una portada visible en permiso automático para vender.
- Reaparece el síntoma. Se aplica la alternativa de contención aprobada y se conserva lo observado. El plan no devuelve tráfico a una raíz infectada como supuesto rollback. Coordinación reabre el incidente y asigna la siguiente investigación.
Al terminar, revisa qué decisiones dependían de alguien ausente o de un dato inexistente. Esos son los resultados del ejercicio: tareas concretas con responsable. Si queréis medir duración, hacedlo en vuestro simulacro real y anotad condiciones; este ejemplo no aporta una duración observada.
Del simulacro a tres tareas que sí se pueden cerrar
En el escenario anterior, «mejorar las copias» sería una conclusión demasiado cómoda. Convierte cada hueco en una tarea con una salida comprobable. Estas tres siguen siendo propuestas del ejercicio ficticio, no trabajos realizados en una tienda.
- REC-01: contacto alternativo. El propietario debe localizar el procedimiento de acreditación con el hosting y comprobar quién puede utilizarlo. Cierre propuesto: referencia del procedimiento, titular y sustituto confirmados, sin copiar documentos de identidad al plan.
- REC-02: restauración aislada. Técnica debe proponer un entorno sin exposición pública ni envíos, cobros o sincronizaciones accidentales. Cierre propuesto: restauración ensayada, componentes identificados, resultado registrado y límites documentados. Tener una fecha reservada para probarlo todavía no cierra la tarea.
- REC-03: datos posteriores. Negocio debe identificar las fuentes de pagos y pedidos de la ventana pendiente. Cierre propuesto: responsable, fuentes autorizadas, criterios de conciliación y prueba acordada. Una cifra total de ventas no sustituye la relación entre cada pago y su operación.
Prioriza según el bloqueo que elimina cada tarea y quién depende de ella. Si REC-01 impide obtener la copia, no tiene sentido declarar listo el plan porque REC-03 tenga un documento precioso. El resultado útil es saber qué puede ejecutarse y qué sigue condicionado.
Condiciones de reapertura que se puedan revisar
Prepara una lista con cuatro estados: superado, fallido, incompleto y no aplicable con motivo. Cada requisito necesita responsable, evidencia y fecha. La aprobación debe referirse a una versión recuperada concreta y a los recorridos probados, no a «la web» de forma indefinida.
Incluye control de cuentas, tratamiento del punto de entrada, procedencia del código, revisión de datos y comprobación del síntoma original. Añade las funciones de negocio afectadas y qué ocurrirá si vuelve el problema. La guía para demostrar el cierre de una recuperación debe consultarse para desarrollar la matriz técnica; valida su alcance con quien intervenga.
El regreso a producción y el cierre del incidente son decisiones distintas. Puede quedar trabajo de seguimiento autorizado, con plazo y responsable. Los bloqueos de seguridad o la incertidumbre sobre pedidos cobrados necesitan resolución explícita antes de dar por recuperado ese recorrido.
Qué pedir al proveedor de recuperación
Solicita un alcance inicial por escrito: sistemas incluidos, conservación, acceso necesario, entregables y condiciones para ampliar el trabajo. Diferencia respuesta inicial, diagnóstico y recuperación verificada. Son hitos diferentes y deberían aparecer separados en el presupuesto y en la conversación.
Pide también quién coordina con el hosting, cómo tratará los datos recientes y qué evidencia entregará al finalizar. Confirma exclusiones: correo, servidor, integraciones y dominios asociados pueden requerir otro especialista o autorización. Una promesa genérica de limpieza no responde a esas dependencias.
Para preparar una evaluación de rescate de una web hackeada, envía dominio, síntomas, cronología resumida, proveedor y funciones afectadas. Indica si existe una copia y su fecha; no adjuntes bases de clientes, archivos infectados ni credenciales en un formulario público. El acceso se acuerda por un canal gestionado.
Cómo mantener útil la edición de 2027
Revisa la ficha al cambiar hosting, personas, pasarela, sistema de copias o despliegue. El año identifica esta edición de planificación; no convierte una instrucción en válida para cualquier instalación. Los procedimientos concretos deben contrastarse con las versiones y proveedores realmente utilizados.
Conserva el resultado del simulacro junto al plan: hueco descubierto, acción, responsable, fecha prevista y evidencia de resolución. Repite el recorrido afectado después de corregirlo. Un documento recién fechado y nunca ensayado sigue siendo un documento sin ensayar.
Como referencias de base, consulta la documentación de WordPress sobre sitios comprometidos y su guía de copias. La ficha y el simulacro de este artículo son herramientas editoriales propias para organizar decisiones; no son una certificación de WordPress ni un informe forense.