# Contratos con proveedores de TI: regular con claridad las obligaciones de seguridad

> Qué debe regular en materia de seguridad un contrato con agencia, hosting o proveedor de TI: actualizaciones, reinicio, canales de aviso, logs, accesos y salida.

Fuente: https://phpsos.de/es/blog/dienstleistervertrag-sicherheit/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** un contrato con un proveedor de TI no debería mencionar la seguridad de pasada, sino regularla de forma concreta: quién actualiza qué componentes, en qué plazo y con qué prueba, cómo se informa de las vulnerabilidades críticas, quién colabora en caso de incidente, cómo se conservan los logs y se gestionan los accesos, y qué ocurre en la salida. Esta página ofrece indicaciones generales y no es asesoramiento jurídico; los contratos los revisa un abogado.

## La pregunta que ha planteado PHP2Shell: ¿quién es responsable?

El 21 de octubre de 2026, a las 16:00 hora alemana, el proyecto PHP publicó los parches. La BSI (Oficina Federal alemana de Seguridad de la Información) recomendó actualizar de inmediato o, donde no fuera posible, desconectar temporalmente de la red los servidores web. En muchas empresas, lo que empezó después no fue el trabajo, sino la búsqueda del responsable. La agencia remitió al proveedor de hosting, este al contrato, y en el contrato figuraba «mantenimiento según esfuerzo».

Estas lagunas contractuales no son un caso aislado. Muchos contratos con agencias y proveedores se firmaron cuando se trataba de construir un sitio web, no de operarlo con seguridad durante años. Una vulnerabilidad crítica en el entorno de ejecución de PHP, que no afecta ni al CMS ni al código de la aplicación, cae entonces fácilmente entre todas las sillas.

## Qué debería regular en materia de seguridad un contrato con un proveedor de TI

La visión general siguiente recoge los puntos que han resultado importantes en la práctica. No sustituye a una revisión jurídica, pero ayuda a detectar lagunas en el contrato existente.

| Punto a regular | Qué debería constar | Relación con PHP2Shell |
|---|---|---|
| Alcance de la prestación | Qué capas se atienden: sistema operativo, entorno de ejecución de PHP, servidor web, CMS, plugins, código propio | El entorno de ejecución de PHP faltaba a menudo en la enumeración |
| Plazos de actualización | Escalonados según la gravedad, con regla de excepción para emergencias | Vulnerabilidad crítica con CVSS v4.0 9,2 |
| Reinicio y prueba | Las actualizaciones solo se consideran terminadas tras reiniciar todos los procesos, con justificante por escrito | Los archivos nuevos por sí solos no cierran la vulnerabilidad |
| Información | Aviso activo ante vulnerabilidades críticas, con valoración y plan | Muchos clientes tuvieron que preguntar por su cuenta |
| Colaboración en incidentes | Apoyo en análisis, aseguramiento y restauración, persona de contacto | Búsqueda de rastros tras el parche |
| Logs | Tipo, conservación, entrega previa solicitud | La prensa especializada aconsejó asegurar los logs desde el 20 de octubre |
| Accesos | Cuentas personales, autenticación en dos factores, lista de todos los accesos | ¿Quién tenía en realidad acceso? |
| Subcontratistas | Quién más participa, información en caso de cambio | El proveedor de hosting del proveedor de hosting |
| Fin de vida del software | Aviso con antelación antes del fin del soporte, plan de migración | PHP 8.2 termina el 31 de diciembre de 2026 |
| Salida | Entrega de datos, documentación y accesos, retirada de los permisos | Cambio tras un incidente |

## Plazos y pruebas: los puntos que más cuentan

Los plazos son el núcleo. Una formulación como «sin demora» no ayuda en el peor caso. Acuerde plazos separados según la gravedad y establezca con qué se mide esa gravedad, por ejemplo con la clasificación del fabricante o de la BSI. Para situaciones extraordinarias debería regir una regla de emergencia: quién está localizable, quién decide si un sistema se desconecta temporalmente de la red y cómo se factura el esfuerzo adicional.

Igual de importante es la prueba. Con PHP2Shell, el número de versión mostrado decía a menudo poco, porque las distribuciones y los proveedores de hosting aplican las correcciones como backport. Un justificante fiable indica el estado del paquete, el momento de la instalación y el reinicio de todos los procesos de PHP. Qué datos cuentan exactamente lo describe [Cómo preguntar a su proveedor de hosting por el estado del parche](https://phpsos.de/es/ratgeber/hoster-patch-status-erfragen/). Incluya estos datos como contenido obligatorio en el contrato.

> **Consejo:**
> Pida al proveedor una matriz de tareas anexa al contrato: una fila por componente, una columna por tarea y un nombre en cada celda. Las lagunas se notan entonces enseguida, mucho antes de que llegue el próximo aviso.

## Accesos, subcontratistas y salida

Los proveedores necesitan accesos, y esos son justo una vía de ataque frecuente. Regule que cada persona reciba una cuenta propia, que la autenticación en dos factores sea obligatoria donde la técnica lo permita y que usted pueda solicitar en cualquier momento una lista actualizada de todos los accesos. Los empleados del proveedor que se hayan marchado deben eliminarse sin demora de todos los sistemas.

Si el propio proveedor trabaja con socios, por ejemplo un centro de datos o un equipo forense especializado, usted debería saberlo. Si uno de esos socios trata datos personales, se añaden obligaciones de protección de datos. Más sobre ello en el artículo [Encargo del tratamiento cuando los proveedores acceden a servidores](https://phpsos.de/es/blog/auftragsverarbeitung-serverzugriff/).

La salida es lo que más se olvida al firmar el contrato. Establezca que, al terminar el contrato, se entreguen por completo los datos, la configuración, la documentación y las credenciales, se retiren todos los accesos del proveedor y se confirme por escrito. Justo tras un incidente, un cambio ordenado resulta de otro modo difícil.

## Revisar contratos existentes: cómo proceder

No tiene que renegociar todos los contratos. Para empezar basta un procedimiento pragmático:

1. Reunir todos los contratos con agencias, proveedores de hosting y proveedores de TI que afecten a sitios web o servidores.
2. Contrastar cada contrato con la tabla de arriba y marcar los puntos abiertos.
3. Plantear por escrito al proveedor las lagunas más importantes, empezando por el alcance de la prestación, los plazos y la prueba.
4. Recoger los resultados en un acuerdo complementario y hacerlo revisar jurídicamente.
5. Incorporar la matriz de tareas al plan de emergencia.

Para la dirección, este paso es también una cuestión de diligencia. Quien regula con claridad las responsabilidades y documenta las decisiones está en mejor posición si más tarde se hacen preguntas. Los antecedentes los ofrece [Responsabilidad de la dirección ante vulnerabilidades de seguridad informática](https://phpsos.de/es/compliance/geschaeftsfuehrer-haftung/). El reparto típico de tareas en los servidores gestionados lo describe [Servidor gestionado: aclarar la responsabilidad](https://phpsos.de/es/server/managed-server/).

## ¿Cómo ayuda PHP SOS en concreto?

- Leemos desde el punto de vista técnico sus contratos y descripciones de servicios existentes y marcamos qué componentes y tareas faltan.
- Elaboramos una matriz de tareas para todos los sitios web y servidores, que puede acordar con sus proveedores.
- Formulamos los requisitos técnicos de plazos, pruebas y canales de aviso, que su abogado puede incorporar al contrato.
- Donde nadie es responsable, asumimos nosotros mismos las tareas mediante un [contrato de mantenimiento de seguridad](https://phpsos.de/es/leistungen/security-wartungsvertrag/) con un alcance claramente descrito.

**Conclusión:** un buen contrato no evita una vulnerabilidad de seguridad, pero evita que en el peor caso se pierda tiempo con la pregunta de quién es responsable. Esta página es información general y no asesoramiento jurídico.


## Preguntas frecuentes

**¿Debe un proveedor de TI aplicar actualizaciones de seguridad sin encargo?**  
Depende del contrato. Sin una regulación clara, a menudo se discute si las actualizaciones forman parte de la prestación debida. Por eso el contrato debería establecer expresamente quién actualiza qué componentes y en qué plazo. La valoración jurídica en cada caso concreto corresponde a un abogado.

**¿Necesito además un contrato de encargo del tratamiento?**  
Si el proveedor trata datos personales por encargo o puede acceder a ellos, por lo general hace falta un contrato de encargo del tratamiento conforme al art. 28 del RGPD. No sustituye al contrato de servicios, sino que lo complementa. Aclárelo con su delegado de protección de datos.

**¿Qué plazos para las actualizaciones de seguridad son habituales?**  
No existen valores fijos. Tiene sentido una escala según la gravedad, por ejemplo plazos separados para vulnerabilidades críticas, altas y restantes. Es importante que los plazos consten por escrito y que incluyan una regla de excepción para emergencias como PHP2Shell.

**¿Qué ocurre con los accesos cuando termina el contrato?**  
El contrato debería regularlo: devolución o eliminación de datos, entrega de credenciales y documentación, retirada de todos los accesos del proveedor y una confirmación al respecto.

## Fuentes

- [BSI IT-Grundschutz (protección básica de TI de la Oficina Federal alemana de Seguridad de la Información)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [php.net: versiones compatibles](https://www.php.net/supported-versions.php)