SLA de parcheado en contratos SaaS de ciberseguridad: qué exigir y cómo leer la letra pequeña

Después de leer esta guía sabrás qué cláusulas concretas buscar (y cuáles negociar) antes de firmar un contrato SaaS de seguridad: tiempos de respuesta ante CVEs críticos, obligación de notificación, ventanas de mantenimiento y quién asume la responsabilidad si el parche llega tarde.

El punto de partida es un hecho incómodo: Cisco acaba de parchear cinco vulnerabilidades en Secure Workload con puntuaciones de 10, 10, 9.9, 9.6 y 7.5, y parte de los clientes en modalidad SaaS también tuvieron que actuar. “El proveedor lo gestiona” no es sinónimo de “yo no tengo que hacer nada”. La siguiente vez que aparezca algo así, el contrato que hayas firmado decidirá cuánto control tienes sobre la situación.

---

1. Entiende el modelo de responsabilidad compartida del contrato actual

Antes de exigir nada, necesitas saber qué cubre el proveedor hoy. Localiza en el contrato vigente:

1. La definición de “servicio gestionado”: ¿incluye explícitamente el parcheado del sistema operativo subyacente, los contenedores y el software de aplicación, o solo la disponibilidad del servicio?
2. El ámbito del SLA de disponibilidad: un 99,9 % de uptime no dice nada sobre cuánto tarda el proveedor en parchear un CVE de severidad crítica.
3. Las exclusiones de responsabilidad: muchos contratos eximen al proveedor de daños derivados de vulnerabilidades conocidas si el cliente no aplicó una configuración recomendada.

El mapa real de quién parchea qué en SaaS de seguridad es el mejor sitio para entender dónde suelen estar los agujeros antes de revisar tu contrato específico.

---

2. Las cláusulas que debes buscar (o pedir que se añadan)

2.1 Tiempo máximo de respuesta ante CVEs por severidad

Un contrato riguroso fija plazos distintos según la puntuación CVSS:

• Crítico (CVSS ≥ 9.0): parche o mitigación documentada en 24-72 horas desde la publicación del CVE.
• Alto (CVSS 7.0-8.9): 7 días naturales.
• Medio (CVSS 4.0-6.9): 30 días.
• Bajo (CVSS < 4.0): próximo ciclo de mantenimiento programado.

Si el contrato usa términos vagos como “a la mayor brevedad posible” o “en tiempo razonable”, eso no es un SLA: es una promesa sin consecuencias.

2.2 Obligación de notificación al cliente

El proveedor debe comprometerse a notificarte de forma proactiva cuando se publique un CVE que afecte al servicio. El contrato debe especificar:

• Canal: correo a un alias de seguridad designado, no solo un aviso en el portal de soporte que nadie monitoriza.
• Plazo: idealmente en las 4-8 horas siguientes a la publicación oficial del CVE o al advisory del fabricante.
• Contenido mínimo del aviso: CVE ID, puntuación CVSS, componentes afectados, si el cliente debe tomar alguna acción y en qué plazo.

Este último punto es clave: como muestra el caso de Cisco Secure Workload, hay CVEs de SaaS donde el cliente sí tiene que actuar aunque el proveedor gestione la infraestructura.

2.3 Ventanas de mantenimiento y parches de emergencia

Distingue dos regímenes en el contrato:

• Mantenimiento programado: ventanas acordadas con antelación (mínimo 48-72 horas de aviso) en horario de bajo impacto.
• Parches de emergencia: procedimiento acelerado para CVEs críticos que permite saltarse la ventana programada, con aviso mínimo de 2-4 horas y compromiso de comunicación del impacto esperado.

Un contrato que solo prevé mantenimiento programado deja al proveedor sin margen legal para reaccionar rápido ante una vulnerabilidad de puntuación 10.

2.4 Penalizaciones y créditos de servicio

Las cláusulas de SLA sin consecuencias son papel mojado. Exige:

• Créditos de servicio automáticos si el proveedor supera el tiempo máximo de respuesta ante un CVE crítico. El baremo habitual es un porcentaje de la cuota mensual por cada hora o día de incumplimiento.
• Derecho de terminación sin penalización si el incumplimiento supera un umbral (por ejemplo, dos CVEs críticos sin parchear en el plazo pactado en un período de 12 meses).

Sin este derecho de salida, dependes de la buena voluntad del proveedor para renegociar.

2.5 Evidencia de parcheado

El proveedor debe poder demostrarte que el parche se aplicó. Pide:

• Acceso a informes de cumplimiento (SOC 2 Tipo II, ISO 27001 o equivalente) con frecuencia al menos anual.
• Notificación de cierre por CVE: confirmación escrita de que el fallo quedó remediado, con fecha y versión del componente parcheado.
• En instalaciones híbridas o on-premise, acceso a los registros de actualización del agente o componente que gestiona el proveedor.

---

3. Cómo auditar estas cláusulas antes de firmar

1. Pide el contrato estándar y los anexos técnicos por separado. Los SLA de parcheado suelen estar en un documento adjunto (“Service Description”, “Security Addendum”) que el comercial no te enseña por defecto.
2. Busca las definiciones. Antes de valorar un plazo, comprueba cómo define el contrato “CVE crítico”: ¿usa CVSS del NVD, del propio fabricante o un criterio propio? Un proveedor puede redefinir “crítico” para que nada llegue a ese umbral.
3. Contrasta con su historial público. Consulta la base de datos del NVD (nvd.nist.gov) o el advisory history del fabricante: ¿cuánto tardó en publicar el parche en los últimos tres CVEs relevantes de su producto? La brecha entre su historial real y lo que promete en el contrato es el dato más honesto que tienes.
4. Pregunta por el proceso de escalado. Si el proveedor no tiene un proceso escrito de gestión de vulnerabilidades (o no te lo quiere enseñar), ese es un dato de due diligence tan importante como el precio.
5. Incluye a legal desde el principio. La misma metodología de revisión que aplica para auditar la seguridad de un proveedor de IA antes de desplegarlo sirve aquí: checklist técnico primero, revisión jurídica después.

---

Errores más comunes al firmar contratos SaaS de seguridad

• Confundir SLA de disponibilidad con SLA de parcheado. Son compromisos distintos. Un servicio puede estar al 99,9 % de uptime y llevar semanas sin parchear un fallo crítico.
• Aceptar notificaciones solo por el portal de soporte. Si nadie de tu equipo tiene una alerta activa en ese canal, el aviso llega, pero nadie lo lee.
• No pedir el anexo de seguridad. El contrato principal rara vez detalla los plazos de parcheado; están en los documentos adjuntos que hay que pedir explícitamente.
• Ignorar la cláusula de terminación. Sin derecho de salida vinculado a incumplimientos de SLA de seguridad, la penalización económica es el único recurso, y en muchos casos no cubre el coste real del incidente.
• Olvidar las instalaciones mixtas. Si tienes agentes on-premise gestionados por el proveedor (como ocurre con parte de los despliegues afectados por el caso Cisco), los SLA del contrato SaaS pueden no cubrir esos componentes. Revisa el alcance exacto de cada cláusula.

La misma disciplina que aplicas para revisar qué garantiza realmente el contrato de un producto “seguro por diseño” vale aquí: la promesa de marketing y el texto del contrato son dos documentos distintos. Lee el segundo.

Qué es: guía de cláusulas SLA de parcheado para contratos SaaS de ciberseguridad
Palancas clave: tiempo de respuesta por severidad CVSS · notificación proactiva · penalizaciones · evidencia de remediación
Caso de referencia: CVEs críticos en Cisco Secure Workload (CVSS 10/10/9.9/9.6/7.5)
Fuentes: contexto editorial de El Comando · NVD (nvd.nist.gov) como referencia de plazos
Estado: guía de referencia, sin verificación manual de la redacción