Qué mirar en un contrato de mantenimiento web antes de firmarlo (SLA, backups, tiempos de respuesta)

Un contrato de mantenimiento web que dice "copias de seguridad periódicas" y "soporte prioritario ante incidencias" no te protege de nada. Esas dos frases no obligan a nadie a nada concreto: no dicen cada cuánto se hace la copia, dónde se guarda, ni cuánto tarda el proveedor en responder si tu web cae un domingo a las 3 de la mañana. Y sin cifras, un SLA (Service Level Agreement) no es un compromiso, es una declaración de buenas intenciones.

Hemos revisado decenas de contratos de mantenimiento de clientes que llegaban a Kodia después de un problema serio —web caída tres días, backup que resultó no existir, dominio registrado a nombre de una agencia que ya no cogía el teléfono. En casi todos los casos, el contrato original tenía huecos que un cliente sin experiencia técnica no podía detectar al firmarlo. Aquí está lo que sí hay que exigir por escrito.

1. Tiempo de respuesta: en horas, no en adverbios

"Lo antes posible" no es un tiempo de respuesta, es una forma de no comprometerse. Un SLA serio especifica números distintos según la gravedad del incidente, porque no es lo mismo que falle un formulario de contacto que una caída total del sitio en horario de venta.

Una estructura razonable para una pyme distingue al menos tres niveles de severidad:

// Ejemplo de cláusula de tiempos de respuesta
Severidad 1 (web caída, checkout roto): respuesta < 2h, resolución < 8h
Severidad 2 (función parcial rota, error visible): respuesta < 8h, resolución < 48h
Severidad 3 (cambios menores, consultas): respuesta < 24h laborables

Si el contrato no distingue severidades, un fallo crítico y una duda sobre cómo cambiar un texto entran en la misma cola. Pregunta también si el tiempo de respuesta cuenta desde que abres el ticket o desde que alguien lo lee — con horarios de oficina de 9 a 18h, un aviso enviado un viernes a las 19h puede "responderse en 2 horas" el lunes a las 11h sin incumplir nada.

2. Backups: frecuencia, retención y prueba de restauración

"Hacemos copias de seguridad" es la frase más repetida y menos útil de cualquier contrato de mantenimiento. Un backup que nunca se ha restaurado no es un backup, es un archivo que probablemente funciona. En la práctica, una parte relevante de los backups automáticos fallan silenciosamente en algún punto —credenciales caducadas, cuota de almacenamiento llena, un cron que dejó de ejecutarse hace meses— y nadie se entera hasta que hace falta restaurar.

El contrato debe especificar tres cosas por separado:

• →Frecuencia real: ¿diaria, semanal? ¿Incluye base de datos y archivos, o solo uno de los dos?
• →Retención: cuántas copias históricas se guardan y durante cuánto tiempo (si solo hay una copia y se sobrescribe cada noche, un problema detectado tarde ya no tiene vuelta atrás).
• →Ubicación: ¿la copia vive en el mismo servidor que el sitio? Si el servidor cae o lo hackean, una copia local no sirve de nada.

Y la cláusula que casi nadie pide pero es la que realmente importa: derecho a solicitar una prueba de restauración al menos una vez al año, en un entorno de pruebas, con confirmación por escrito de que funcionó. Un proveedor serio no tiene problema en aceptar esto porque ya lo hace internamente.

3. ¿De quién es tu web si el proveedor desaparece?

Esta es la cláusula que más disgustos evita y la que menos se pregunta al firmar. Muchas agencias registran el dominio, el hosting y hasta las cuentas de correo corporativo a su propio nombre "por comodidad de gestión". Funciona bien mientras la relación es buena. Deja de funcionar el día que la agencia cierra, sube precios de forma unilateral, o simplemente deja de responder al teléfono.

Antes de firmar, verifica y exige por escrito:

4. Qué significa exactamente "actualizaciones de seguridad"

En WordPress, "actualizaciones de seguridad" puede significar tres cosas muy distintas según quién redacte el contrato, y el precio suele variar mucho según cuál sea:

Solo el core

Actualizar WordPress en sí mismo. Es lo más barato de mantener y lo menos relevante: la mayoría de vulnerabilidades explotadas en sitios WordPress vienen de plugins desactualizados, no del core.

Core + plugins + tema

Esto sí cubre el riesgo real, pero implica más trabajo: cada actualización de un plugin puede romper algo, así que un mantenimiento serio incluye probar en un entorno de staging antes de aplicar en producción, no actualizar directamente en el sitio en vivo.

Monitorización activa de vulnerabilidades

El nivel más completo: el proveedor recibe alertas cuando se publica un CVE para alguno de los plugins instalados y actúa antes de que sea explotado, no en el ciclo mensual habitual.

Pide que el contrato especifique cuál de los tres niveles está pagando, con nombre y apellido. "Mantenimiento y seguridad" sin más detalle normalmente significa el nivel más barato de los tres.

5. Penalizaciones si no se cumple el SLA

Un SLA sin penalización es una recomendación, no un contrato. Si el proveedor incumple el tiempo de respuesta acordado de forma repetida, debe haber una consecuencia económica real —un descuento proporcional en la cuota mensual, por ejemplo—, no solo una disculpa por email.

Tampoco hace falta redactar cláusulas agresivas. Basta con algo tan simple como: "por cada hora de retraso sobre el tiempo de respuesta acordado en incidencias de severidad 1, se aplicará un descuento del X% en la cuota mensual del mes en curso". Sirve sobre todo como incentivo: obliga al proveedor a dimensionar bien su capacidad antes de aceptar el contrato.