En resumen: un plan de emergencia informática para servidores web establece de antemano quién decide en la emergencia, a quién se puede contactar, qué sistemas pueden verse afectados y qué pasos siguen y en qué orden. Quien quiera crear un plan de emergencia informática no necesita un manual grueso, sino pocas páginas actualizadas a las que también se pueda acceder sin informática en funcionamiento. La situación en torno a PHP2Shell es una buena ocasión para hacerlo ahora.
Por qué un plan de emergencia ahorra tiempo y daños
En la emergencia, las primeras horas suelen perderse buscando: ¿quién tiene acceso al proveedor de hosting? ¿Dónde están las copias de seguridad? ¿Quién decide si la tienda se desconecta? ¿A quién hay que informar? Un plan de emergencia responde a estas preguntas de antemano y con calma.
PHP2Shell ha mostrado lo corto que puede ser el tiempo. El 20/10/2026, php.net anunció los parches; el 21/10 a las 16:00 hora alemana se publicaron, y el BSI recomendó actualizar de inmediato o desconectar temporalmente. Las empresas con un plan sabían a quién llamar y qué servidores revisar. Otras tuvieron que averiguar primero dónde funciona PHP.
Crear un plan de emergencia informática: los componentes
Un plan útil en la práctica para servidores web comprende estas partes:
1. Roles y decisiones. ¿Quién dirige en la emergencia, quién sustituye, quién puede desconectar sistemas, quién habla hacia el exterior? Anote nombres y suplencias.
2. Lista de contactos. Interlocutores internos, proveedor de hosting, agencia, proveedor de servicios informáticos, delegado de protección de datos, asesoramiento jurídico, ciberseguro con número de póliza, autoridad de control de protección de datos competente, el Punto Central de Contacto contra la Cibercriminalidad (ZAC) de su estado federado. Esta lista debe estar disponible impresa.
3. Inventario de sistemas. Cada sitio web, tienda y portal con servidor, proveedor de hosting, modo de funcionamiento, versión de PHP, aplicación, responsable y tipo de datos tratados.
4. Reglas de decisión. ¿En qué condiciones desconectamos un sistema de la red? ¿Quién puede decidirlo? ¿Qué rige por la noche y en fin de semana?
5. Procedimientos. Secuencias breves de pasos para casos típicos: vulnerabilidad crítica conocida, sospecha de intrusión, sitio web desfigurado, fuga de datos, extorsión.
6. Vías de notificación. ¿Quién examina una obligación de notificar según el art. 33 del RGPD, si es posible en un plazo de 72 horas desde que se tiene conocimiento? ¿Quién notifica al BSI en caso de obligación NIS2? ¿Quién informa a la aseguradora?
7. Recuperación. ¿Dónde están las copias de seguridad, quién puede restaurarlas, cuánto tarda y cuándo se probó por última vez?
Ejemplo: procedimiento «vulnerabilidad crítica de PHP»
Así puede ser un procedimiento como el que hizo falta con PHP2Shell:
| Paso | Quién | Resultado |
|---|---|---|
| Valorar el aviso (php.net, BSI) | Responsables de TI | sistemas afectados según el inventario |
| Instalar la actualización, reiniciar todos los workers | Administrador o proveedor de servicios | Prueba con estado de paquetes y hora de los procesos |
| Donde no sea posible actualizar: medidas provisionales o desconexión de la red | Decide la dirección | decisión documentada |
| Conservar registros, comprobar rastros | Administrador o análisis forense | Hallazgo o ausencia de hallazgo |
| Si hay hallazgo: iniciar el procedimiento de incidente | Dirección de emergencia | comprobar vías de notificación |
Lo importante es: un parche cierra la vulnerabilidad, pero no elimina el software malicioso introducido antes. Por eso la búsqueda de rastros debe formar parte fija del procedimiento.
Establezca durante cuánto tiempo se conservan los registros del servidor web y dónde se guardan fuera del servidor. En el caso de PHP2Shell, la prensa especializada recomendó conservar los registros desde el 20/10/2026. Quien solo conserva los registros unos pocos días no puede aplicar recomendaciones así.
Prevención que hace efectivo el plan
Un plan vale lo que valen sus requisitos previos. Compruebe si hay copias de seguridad según la regla 3-2-1 y si están probadas; véase Copias de seguridad según la regla 3-2-1. Aclare por escrito con el proveedor de hosting y la agencia quién asume qué ante vulnerabilidades críticas. Tenga las credenciales para emergencias guardadas de forma segura pero accesible, por ejemplo en una caja fuerte de contraseñas protegida con acceso de emergencia.
Prepare además plantillas de texto: información interna, aviso a los clientes, aviso en una página de mantenimiento estática. Encontrará indicaciones en Comunicación de crisis tras un ataque.
Practicar y mantener actualizado
Un plan que nunca se ha practicado casi siempre contiene lagunas. Simule una vez al año un escenario, por ejemplo «vulnerabilidad crítica de PHP un viernes por la tarde», y anote dónde falla. Para empezar basta una prueba sencilla: ¿puede una segunda persona, sin la ayuda de la primera, contactar con el proveedor de hosting, restaurar una copia de seguridad y poner el sitio web en modo de mantenimiento? Si no, falta algo en el plan, casi siempre un acceso, un número de teléfono o una descripción. Justo esas lagunas son las que deben hacer visibles los ejercicios antes de que la cosa se ponga seria. Actualice el plan tras cada ejercicio y cada cambio sustancial. Como marco metodológico son adecuados el IT-Grundschutz del BSI y el estándar BSI 200-4 sobre gestión de la continuidad de la actividad.
El plan no resuelve de forma definitiva las cuestiones jurídicas, por ejemplo sobre las obligaciones de notificación. Se encarga de que las personas adecuadas intervengan a tiempo. Esta página es información general y no constituye asesoramiento jurídico.
¿Cómo ayuda PHP SOS en concreto?
- Elaboramos con usted el inventario de sistemas de sus servidores web, incluido el modo de funcionamiento y la versión de PHP.
- Redactamos los procedimientos técnicos para escenarios típicos y los coordinamos con el proveedor de hosting y la agencia.
- Realizamos un ejercicio e incorporamos las conclusiones al plan.
- En la emergencia asumimos la parte técnica mediante la respuesta a incidentes, si lo desea respaldada por un contrato de mantenimiento de seguridad.
Preguntas frecuentes
¿Cómo de extenso debe ser un plan de emergencia informática?
Tan breve como sea posible y tan detallado como sea necesario. Para servidores web suelen bastar pocas páginas con contactos, lista de sistemas, reglas de decisión y procedimientos. Más importante que la extensión es que esté actualizado y que se encuentre en la emergencia.
¿Dónde guardo el plan de emergencia?
En al menos un lugar al que también se pueda acceder sin informática en funcionamiento, por ejemplo impreso o en un dispositivo separado. Un plan que solo está en el servidor afectado o en la red bloqueada de la empresa no ayuda en la emergencia.
¿Con qué frecuencia debe revisarse el plan?
Como mínimo una vez al año y tras cada cambio sustancial, por ejemplo un cambio de proveedor de hosting o un software nuevo. Es útil un breve ejercicio en el que se simule un escenario.
¿Hay plantillas del BSI?
El BSI (Oficina Federal Alemana de Seguridad de la Información) trata la gestión de emergencias en el marco del IT-Grundschutz (protección básica de TI) y en el estándar BSI 200-4 sobre gestión de la continuidad de la actividad. Sirven como marco; para servidores web merece la pena una versión breve y práctica.