En resumen: ISO 27001 y TISAX afectan a los servidores web sobre todo a través de tres requisitos: hay que detectar y tratar las vulnerabilidades, hay que gestionar a proveedores como el alojamiento y las agencias, y los incidentes de seguridad necesitan un procedimiento regulado. Una situación como PHP2Shell es una prueba práctica para cualquier SGSI. Quien documenta de forma trazable la valoración, el parche y el reinicio tiene una buena base para la próxima auditoría. Un certificado o una etiqueta no sustituyen al parche.
Qué son ISO 27001 y TISAX, en dos párrafos
ISO/IEC 27001 describe los requisitos de un sistema de gestión de la seguridad de la información, abreviado SGSI. Se trata de un ciclo ordenado: valorar riesgos, fijar medidas, aplicarlas, comprobarlas y mejorar. La edición actual de 2022 contiene en su anexo A un catálogo de 93 medidas en cuatro temas. Cuáles se aplican lo decide la empresa sobre la base de su valoración de riesgos y lo recoge en la declaración de aplicabilidad.
TISAX es el mecanismo de auditoría e intercambio extendido en la industria del automóvil. Lo gestiona la ENX Association; la base es el catálogo de requisitos ISA, que mantiene la ENX y publica la VDA. Proveedores de auditoría independientes realizan una evaluación, cuyo alcance depende de la necesidad de protección y va de revisiones documentales a visitas in situ. Los resultados se conceden, según la ENX, como etiquetas, son válidos durante tres años y se comparten a través del portal de la ENX solo con socios seleccionados.
ISO 27001 en el servidor web: ¿qué requisitos se aplican?
Un servidor web rara vez es un capítulo propio en el SGSI. Aparece en varios puntos, y es justo ahí donde surgen lagunas. El siguiente resumen asigna de forma general los temas más importantes. No sustituye la consulta de su propia declaración de aplicabilidad.
| Tema en el SGSI | Qué significa para el servidor web | Prueba que ayuda en la auditoría |
|---|---|---|
| Inventario de activos | Cada sitio web, cada servidor y cada versión de PHP están registrados | Lista actualizada con operador, versión y responsable |
| Gestión de vulnerabilidades técnicas | Avisos como PHP2Shell se valoran y se tratan | Ticket con valoración, decisión y fecha del parche |
| Relaciones con proveedores | El proveedor de alojamiento y la agencia tienen obligaciones de seguridad claras | Contrato, reparto de tareas, confirmación por escrito del estado de parches |
| Registro y supervisión | Los registros del servidor web se conservan y se analizan | Regla de conservación, ejemplo de un análisis |
| Gestión de incidentes | Las sospechas se comunican, se valoran y se cierran | Registro de incidentes, lessons learned |
| Gestión de la configuración | La configuración de PHP y del servidor web está definida | Configuración objetivo y control de desviaciones |
En TISAX se aplican temas comparables, porque el catálogo ISA está armonizado con otros estándares importantes. Además, algunos objetivos de auditoría, como la protección de prototipos, exigen un cuidado especial en los sistemas a través de los cuales los socios intercambian datos. Pueden ser también portales basados en PHP.
PHP2Shell como prueba práctica del SGSI
El 21 de octubre de 2026, el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales. Un SGSI que funcione debería desencadenar en esta situación una cadena que luego pueda acreditarse.
- Entrada: ¿quién recibió el aviso, cuándo y dónde está registrado?
- Valoración: ¿qué sistemas están afectados? Esto presupone un inventario actualizado; véase Saber qué se ejecuta.
- Decisión: parche, medida transitoria o desconexión temporal, con motivación y el nombre de la persona que decide.
- Aplicación: estado del paquete, reinicio de todos los procesos de PHP, control. En los backports de la distribución cuenta el registro de cambios del paquete, no el número de versión mostrado; cómo acreditarlo lo muestra Comprobar correctamente la versión de PHP y el estado del parche.
- Proveedores: confirmación por escrito del proveedor de alojamiento de que se ha parcheado y reiniciado.
- Control posterior: comprobación de indicios de compromiso desde el 17 de octubre de 2026, porque un parche no deshace intrusiones anteriores.
Cómo convertir esta cadena puntual en un procedimiento permanente lo describen Gestión de vulnerabilidades para la pyme y Gestión de parches como proceso.
Puntos débiles frecuentes en la documentación
En la práctica, la prueba rara vez falla por la técnica, sino por lagunas en la cadena. Es típico un sitio web que un departamento opera con una agencia y que falta en el inventario. Igual de frecuentes son los contratos de alojamiento sin ninguna indicación sobre la rapidez con que se instalan las actualizaciones de seguridad y si se informa a los clientes.
Otro clásico: el ticket del parche está cerrado, pero nadie ha reiniciado los procesos de PHP. Formalmente el punto está resuelto, técnicamente sigue funcionando el código antiguo. Una buena prueba contiene por ello no solo «actualización instalada», sino también el reinicio y un control posterior.
También es difícil con sistemas que no pueden parchearse de inmediato, por ejemplo una aplicación en PHP 8.1. Aquí un SGSI no exige milagros, pero sí una decisión consciente: ¿qué medidas transitorias se aplican, quién ha aceptado el riesgo restante y para cuándo está previsto el cambio? Una aceptación de riesgo por escrito con fecha de caducidad es claramente mejor en la auditoría que un sistema antiguo que sigue funcionando en silencio. Igual de importantes son los registros. La prensa especializada y autores del sector aconsejaron tras PHP2Shell conservar los registros del servidor desde el 20 de octubre de 2026. Si su regla de conservación lo permite y si los registros están en el proveedor de alojamiento o en su poder, debería aclararse antes del próximo incidente, no durante él.
Si su empresa además está sujeta a NIS2, estos requisitos se intensifican. Los fundamentos figuran en NIS2 y seguridad de los servidores web. Es información general, no asesoramiento jurídico.
Un certificado o una etiqueta describe el estado de un sistema de gestión en el momento de la auditoría. No protege a ningún servidor concreto frente a una nueva vulnerabilidad. Lo decisivo es que el procedimiento funcione de verdad en caso de emergencia.
¿Cómo ayuda PHP SOS en concreto?
- Registramos sus servidores web e instalaciones de PHP de modo que encajen en el inventario de su SGSI.
- Parcheamos y documentamos con nuestro servicio de parches PHP: estado del paquete, reinicio, control, con fecha y justificantes.
- Formulamos las preguntas al proveedor de alojamiento y a las agencias y valoramos sus respuestas para su gestión de proveedores.
- Entregamos a los responsables de su SGSI los hechos técnicos. La valoración en el sistema de gestión y la auditoría siguen en manos de usted y de su entidad auditora.
Conclusión
ISO 27001 y TISAX no exigen un servidor web concreto, pero sí un tratamiento trazable del mismo. PHP2Shell muestra si el inventario, el tratamiento de vulnerabilidades y la gestión de proveedores funcionan juntos. Quien acredita con rigor la cadena de entrada, valoración, parche, reinicio y control posterior no solo tiene la auditoría, sino sobre todo el servidor bajo control.
Preguntas frecuentes
¿Forma parte el sitio web de la empresa del ámbito de aplicación de una ISO 27001?
Depende de cómo haya definido su empresa el ámbito de aplicación. Si el sitio web procesa datos de clientes, está conectado con sistemas internos o lo opera un proveedor de servicios, hay mucho a favor de incluirlo o, al menos, de recogerlo mediante la gestión de proveedores.
¿Es TISAX un certificado?
La ENX Association habla de una evaluación (assessment) realizada por proveedores de auditoría independientes, cuyos resultados se conceden como etiquetas TISAX. Según la ENX, las etiquetas son válidas durante tres años y se comparten de forma selectiva con socios a través del portal de la ENX; no son públicas.
¿Debo informar a mi auditora tras PHP2Shell?
No existe una obligación general. Pero su SGSI debería documentar cómo valoró y trató la vulnerabilidad. Esta documentación suele revisarse en la siguiente auditoría.
¿Qué versión de ISO 27001 es la actual?
La vigente es la edición ISO/IEC 27001:2022. Su anexo A ordena las medidas en cuatro temas: organizativo, de personas, físico y tecnológico.