Lista de verificación contractual para proveedores cloud: SLAs, protección de datos y cláusulas de salida que realmente surtan efecto

Quien compra servicios en la nube no adquiere solo capacidad de cálculo o almacenamiento, sino realidad operativa: disponibilidad, tiempos de respuesta, flujos de datos, pistas de auditoría y una opción de salida. Precisamente aquí decide un contrato si su TI puede gobernar en el día a día o tendrá que improvisar después. Esta lista de verificación contractual para proveedores cloud se centra por tanto en cláusulas que puedan formularse de forma concreta, medirse y auditarse —con mirada al funcionamiento de TI, seguridad, protección de datos (DSGVO) y la cuestión de cómo salir limpiamente en caso de necesidad.

Importante: Muchos contratos estándar usan términos como „best effort“, „práctica habitual del sector“ o „medidas razonables“. Eso ayuda poco en auditorías y en incidentes, porque es difícil de demostrar. El objetivo no es regular cada eventualidad, sino definir estándares mínimos claros: ¿Qué se mide? ¿Quién informa qué, cuándo y cómo? ¿Qué datos recibe usted de vuelta? ¿Qué ocurre si no funciona?

Lista de verificación contractual para proveedores cloud en la práctica

Antes de redactar cláusulas individuales, la situación de partida debe ser inequívoca. En la práctica, los contratos cloud no fracasan tanto por una „falta de seguridad“ como por responsabilidades poco claras. El proveedor opera la plataforma; usted opera la configuración, las identidades y los datos —según el modelo (IaaS, PaaS, SaaS) con distinto grado de profundidad. Esta distribución de tareas se describe a menudo como Shared Responsibility Model: el proveedor es responsable de determinadas capas (p. ej. infraestructura física), usted de otras (p. ej. IAM, clasificación de datos, políticas de aplicaciones).

Punto de control: aclarar el objeto del contrato y las dependencias

• Lista de servicios con versiones/ediciones, regiones, ventanas de mantenimiento, funciones opcionales (p. ej. Managed Keys, WAF, DLP).
• Servicios de terceros dependientes (p. ej. CDN, Anti-DDoS, subcontratistas de ticketing). En la práctica, el „servicio cloud“ suele depender de varios subservicios.
• Matriz de responsabilidades (RACI: Responsible, Accountable, Consulted, Informed) para operación, seguridad, protección de datos, incidentes, cambios, gestión de claves.
• Tipos de datos: datos personales, especialmente protegidos, secretos empresariales, datos regulados (p. ej. datos financieros). De ello se derivan las TOMs y los requisitos de auditoría.

Si no puede incluir estos puntos en el propio contrato, debe existir al menos un anexo referenciado contractualmente (p. ej. „Service Schedule“), que solo podrá modificarse mediante un procedimiento de cambios definido.

2) SLAs en el contrato cloud: de cifras de marketing a obligaciones mensurables

Un SLA (Service Level Agreement) solo es tan bueno como su método de medición. Para dirección de TI y auditoría no importa que „99,9 %“ figure en algún sitio, sino qué se considera exactamente como fallo, cómo se mide y qué consecuencias se derivan. Preste especial atención a las exclusiones („maintenance“, „force majeure“, „customer network“, „beta features“): en estas cláusulas estándar suelen esconderse los riesgos reales.

2.1 Verfügbarkeit: Definition, Messpunkte, Wartungsfenster

• Service-Abgrenzung: Disponibilidad por servicio (p. ej. almacenamiento de objetos, servicio de base de datos, IAM) en lugar de „plataforma en su conjunto“.
• Messpunkt: Monitorización del proveedor vs. cliente. Es preferible una medición doble y un mecanismo de resolución de conflictos.
• Ausfall-Definition: p. ej. „HTTP 5xx durante X minutos“ o „la operación API falla en Y % de los intentos“. Para servicios no basados en HTTP, aplicar métricas equivalentes (p. ej. tasa de errores de autenticación, acumulación en colas).
• Wartungsfenster: Plazo de aviso, duración máxima, ventana horaria (zona horaria local), „sin mantenimiento“ durante periodos críticos (periodos de blackout).

2.2 Performance- und Support-SLAs: Latenz, Durchsatz, Reaktionszeiten

Muchos contratos se limitan a la disponibilidad y dejan la performance sin definir. Para soluciones digitales orientadas a procesos empresariales suele ser determinante el tiempo de respuesta. Sin parámetros claros, se entra en discusiones de „va más o menos“.

• Performance-SLOs (Service Level Objectives) para APIs centrales: p. ej. latencia p95/p99 en regiones y ventanas temporales definidas.
• Kapazitätszusagen: Límites, cuotas, reglas de ráfaga, comportamiento de escalado y aviso previo ante ajustes de límites.
• Support-Klassen: Clases de prioridad (P1–P4) con tiempo de respuesta, frecuencia de actualizaciones y objetivo temporal para la provisión de un workaround.
• Kommunikationskanäle: Página de estado, e-mail, ticket, teléfono, con niveles de escalación definidos e inclusión de escalación a la dirección.

2.3 Incident- und Problem-Management: Postmortems, RCA, Evidence

Para compliance y dirección no solo es relevante la resolución de la incidencia, sino la demostración: ¿cuál fue la causa (RCA: análisis de causa raíz), qué medidas se tomaron y qué implica eso para el riesgo de recurrencia?

• Meldepflicht por incidentes de seguridad y alteraciones operativas con plazos (p. ej. „notificación inicial dentro de X horas desde la detección“).
• RCA-Format: Cronología, causa, componentes afectados, impacto en clientes, medidas inmediatas, prevención, puntos abiertos.
• Log- und Forensik-Unterstützung: Qué logs se proporcionan, durante cuánto tiempo, en qué formato y con qué integridad (p. ej. almacenamiento a prueba de manipulación).
• Change-Transparenz: Cambios del proveedor que afecten a clientes, con aviso previo, opciones de rollback y clasificación de „Breaking Change“.

2.4 Konsequenzen bei Nichterfüllung: Service Credits sind nicht genug

Los Service Credits raramente compensan el perjuicio comercial. Aun así son útiles como disparador vinculante para la escalación y planes de mejora. Complétenlos con derechos operativos.

• Service Credits con cálculo claro y abono automático, no solo „a solicitud“.
• Right to Cure: Plazo para subsanar y medidas de mejora definidas.
• Sonderkündigungsrecht por incumplimientos repetidos del SLA o por incidentes graves de seguridad.

3) Protección de datos y AVV: DSGVO-konform heißt nicht automáticamente auditfähig

Si el proveedor cloud procesa datos personales para usted, normalmente necesita un acuerdo de encargado del tratamiento (AVV) conforme al art. 28 DSGVO. «Tenemos un AVV» no es suficiente a nivel operativo. Lo decisivo es si con ello puede cumplir sus obligaciones de responsabilidad: minimización de datos, limitación de la finalidad, TOMs (medidas técnicas y organizativas), políticas de eliminación y evidencias.

3.1 Roles y flujos de datos: responsable, encargado del tratamiento, responsabilidad compartida

Aclare contractualmente y en los anexos, qué parte tiene cada rol. Especialmente en SaaS existen zonas grises, por ejemplo si el proveedor persigue fines propios (p. ej. mejora del producto mediante telemetría). Eso puede cambiar la clasificación.

• Finalidades del tratamiento y categorías de datos personales.
• Grupos afectados (clientes, empleados, socios) y categorías especiales (art. 9 DSGVO), si procede.
• Telemetría/datos de diagnóstico: qué datos, opt-in/opt-out, agregación/anonimización, plazos de retención.

3.2 TOMs y nivel de seguridad: concreto en lugar de genérico

Las TOMs no tienen que nombrar cada herramienta, pero deben ser verificables. Para auditorías es útil que el proveedor entregue un catálogo de TOMs estructurado, que pueda mapearse a sus requisitos (p. ej. control de acceso, registro de eventos, cifrado, separación, disponibilidad, capacidad de recuperación).

• Cifrado: datos „at REST“ y „in transit“, estándares mínimos (p. ej. TLS), gestión de claves (KMS), opciones para claves controladas por el cliente (BYOK/HYOK – Bring/Hold Your Own Key).
• Identidades y accesos de administrador: MFA, accesos privilegiados, Break-Glass-Accounts, acceso JIT (Just-in-Time), proceso de aprobación.
• Registro (logging): qué eventos, qué retención, posibilidades de exportación a su SIEM (Security Information and Event Management).
• Gestión de vulnerabilidades: ciclos de parches, clases de criticidad, tratamiento de Zero-Days, obligaciones de comunicación.

3.3 Subcontratistas y transferencias a terceros países: puntos de control para las cadenas de suministro

La mayoría de los proveedores cloud utilizan subcontratistas (p. ej. operación de centros de datos, soporte, servicios anti-spam/abuso). Contractualmente son relevantes la transparencia, los derechos de oposición y las obligaciones de información. En las transferencias a terceros países (datos fuera de la UE/EEE) entran en juego las cláusulas contractuales tipo (SCC) y las evaluaciones de impacto de la transferencia (TIA).

• Lista actual de subcontratistas como anexo, incluyendo participación en la pRESTación y categorías de datos.
• Notificación de cambios: aviso previo ante nuevos subcontratistas, proceso de oposición, opciones alternativas.
• Localización de datos: regiones/ubicaciones obligatorias, incluidos metadatos, copias de seguridad y accesos de soporte.
• Transferencia a terceros países: normativa clara sobre cuándo se realiza, qué garantías aplican y cómo se le comunican los cambios.

3.4 Derechos de los interesados, eliminación, retención: la «última milla»

En la práctica, los problemas de protección de datos suelen surgir durante los procesos de eliminación, las copias de seguridad y las exportaciones. El contrato debe definir cómo puede imponer técnicamente la eliminación y el derecho de acceso y qué plazos se aplican.

• Plan de eliminación: plazos, ejecución técnica (incl. copias de seguridad), forma de comprobación (p. ej., protocolo de eliminación).
• Exportación de datos personales en formatos habituales (portabilidad de datos) y proceso para respuestas masivas a solicitudes de acceso.
• Retención: retención predeterminada y control por parte del cliente (Legal Hold vs. obligación de eliminación).

4) Cláusulas de salida y portabilidad de datos: limitar activamente el vendor lock-in

Las cláusulas de salida no son un tema de «peor escenario», sino parte de la gobernanza habitual. Las razones para una salida son diversas: evolución de costes, cambio de estrategia, M&A, requisitos regulatorios, situación de seguridad o, simplemente, un servicio que ya no encaja. Sin reglas de salida, un proyecto ordenado se convierte rápidamente en un incidente de riesgo.

4.1 Qué debe cubrir contractualmente un proceso de salida

• Disparadores de salida: terminación ordinaria, terminación extraordinaria, incidente grave, incumplimientos de cumplimiento, incumplimiento repetido de SLA.
• Soporte de transición: alcance de soporte definido (duración, roles, tiempos de reacción), opcionalmente de pago, pero con lógica de precios y límites máximos.
• Plan de salida como anexo: exportación de datos, operación en paralelo, corte (cutover), responsabilidades, canales de comunicación.
• Deprovisioning: apagado seguro, eliminación de derechos de acceso, tokens/keys, cuentas de servicio.

4.2 Devolución de datos: formatos, completitud, integridad

«Proporcionaremos una exportación» es demasiado impreciso. Necesita especificaciones sobre el alcance de los datos y los criterios de calidad. Especialmente en SaaS, las exportaciones a veces son solo extractos parciales en CSV sin integridad referencial (relaciones entre registros).

• Alcance: datos primarios, metadatos, configuración, registros de auditoría, modelos de permisos, parámetros de cifrado (en la medida permitida).
• Formatos: formatos abiertos y documentados; en bases de datos, p. ej., volcado más esquema; en almacenamiento de objetos, exportaciones estructuradas incluidas sumas de verificación.
• Integridad: hash/sumas de verificación, validación por muestreo, listas de exportación completas.
• Cronograma: plazos para la puesta a disposición y ventana de descarga, opciones de prórroga.

4.3 Eliminación de datos tras la salida y prueba documental

Al finalizar el contrato, muchas organizaciones desean una prueba sólida de que los datos no se conservan más tiempo. Al mismo tiempo deben considerarse las obligaciones legales de conservación (p. ej. derivadas del derecho mercantil o fiscal): con frecuencia la obligación recae en usted, no en el proveedor.

• Plazos de eliminación tras la finalización, diferenciados por datos productivos, copias de seguridad y registros (logs).
• Evidencia de la eliminación (confirmación, registro, informe de auditoría) y gestión de los residuos técnicos inevitables (p. ej. rotación de copias de seguridad).
• Derechos sobre datos derivados (p. ej. estadísticas anonimizadas) regulados de forma clara.

4.4 Control de costes en la salida: la dimensión de control oculta

Los costes de salida suelen originarse por la extracción de datos (egress), soporte adicional o operaciones paralelas a corto plazo. Al menos defina parámetros de control.

• Lógica de precios para el soporte de transición y la exportación de datos (tarifas diarias, tarifas planas, topes).
• Costes de egress: transparencia, aviso previo de cambios de precio y, si procede, contingentes.
• Fin de licencia/suscripción: fechas claras de facturación, sin renovaciones automáticas sin confirmación activa.

5) Derechos de auditoría, evidencias y capacidad de cumplimiento regulatorio

Un dilema frecuente: el proveedor entrega informes de certificación, pero no permite auditorías individuales. Esto puede ser aceptable si los informes cubren sus requisitos. Para muchas empresas es determinante que existan rutas de auditoría: qué evidencias recibe, cuán actuales son y cómo se gestionan las desviaciones.

5.1 Evidencias: qué es realista y útil

• Informes de auditoría independientes periódicos (p. ej. sobre controles ISMS) y frecuencia de actualización clara.
• Derecho de auditoría como regla escalonada: revisión de documentos y entrevistas por defecto; auditoría in situ solo por causa justificada (p. ej. incidente grave) y bajo condiciones de seguridad.
• API de evidencias/exportaciones: registros, evidencias de configuración, datos de cambios que pueda integrar en sus propios procesos GRC/auditoría.

5.2 Gestión de hallazgos: CAPA y plazos

Un hallazgo de auditoría no es automáticamente un criterio de exclusión. Lo decisivo es si existe un plan vinculante: CAPA (Acciones Correctivas y Preventivas) con prioridades, plazos e informes de progreso.

• Clasificación de severidad y plazos por clase.
• Transparencia sobre los hallazgos relevantes que afecten a sus datos o a la disponibilidad.
• Derechos de rescisión/especiales, si los hallazgos críticos no se subsanan.

6) Cláusulas de seguridad que realmente respaldan la operación

Las buenas cláusulas de seguridad no son «más texto», sino mecánica operativa clara: accesos, claves, registros, accesos de emergencia, responsabilidades. Es especialmente importante vincularlas a sus políticas internas para que auditoría y operación hablen el mismo idioma.

6.1 Acceso e identidades: asegurar contractualmente los requisitos de IAM

IAM (Gestión de Identidades y Accesos) es la palanca de control más habitual en entornos cloud. Contractualmente debería al menos asegurarse de que la plataforma ofrece las funcionalidades de seguridad necesarias y no las modifica de forma unilateral.

• MFA para accesos privilegiados, SSO (inicio de sesión único) mediante protocolos estándar (p. ej. SAML/OIDC) y modelos de roles.
• Registro de acciones administrativas y acceso a los registros (logs) con una retención definida.
• Acceso de emergencia: procedimiento Break-Glass, documentación, pruebas periódicas.

6.2 Gestión de claves: ¿quién controla las «joyas de la corona»?

Si el proveedor controla las claves, puede (según el modelo) obtener acceso en el marco del soporte o de solicitudes de autoridades. Eso no es intrínsecamente ilícito, pero debe encajar en su aceptación de riesgo. Las opciones BYOK/HYOK reducen este riesgo, pero aumentan la responsabilidad operativa (rotación, disponibilidad del KMS, recuperación).

• Opciones de claves y responsabilidades (rotación, copia de seguridad, acceso).
• Key Escrow y procesos de entrega (si están previstos) solo bajo condiciones claras.
• Solicitudes de autoridades: obligaciones de información, en la medida legalmente posible, e informes de transparencia.

6.3 Registro, monitorización e integración SIEM: sin datos no hay control

Muchos incidentes en la nube se detectan tarde porque los registros no se recopilan de forma centralizada o se conservan por poco tiempo. Contractualmente debe asegurarse de que la plataforma proporcione las fuentes de registros necesarias y que la exportación/retención no se limite de forma arbitraria.

• Fuentes mínimas de registros disponibles (acciones de administración, autenticación, accesos a datos, eventos de red – según el servicio).
• Retención y exportación a formatos comunes, acceso oportuno en caso de incidentes.
• Integridad (p. ej. almacenamiento a prueba de manipulación) para auditoría y forense.

7) Consecuencias operativas y gobernanza: roles, vías de decisión, control de costes

Un contrato cloud es también un modelo operativo. Si los roles no están claros o los presupuestos no son controlables, surgen «procesos sombra»: los equipos eluden la adquisición, los registros no se aseguran, las políticas se interpretan localmente. Eso es un problema de gobernanza, no de tecnología.

7.1 Modelo de roles y responsabilidades

• Service Owner (funcional/técnico) con mandato sobre presupuesto y priorización.
• Security/Compliance con controles mínimos y derechos de aprobación para excepciones de riesgo.
• Operaciones de TI con control de cambios, monitorización, proceso de incidentes y runbooks.
• Vendor Management con reporting de SLA, QBR (Quarterly Business Review) y lógica de escalado.

7.2 Control de costes y uso como parte del contrato

La mecánica FinOps (control de costes en entornos cloud) requiere datos y permisos: etiquetado, presupuestos, exportación de datos de uso, límites. Sin eso, el control de costes no funciona.

• Reporting de costes y exportación de los datos de uso en formatos legibles por máquina.
• Funciones de presupuesto y límites (quotas), incluidas las notificaciones.
• Cambios de precios: plazos de aviso, transparencia, derecho de rescisión en caso de cambios sustanciales.

8) Lista de verificación contractual compacta: cláusulas mínimas que puede «formular»

La lista siguiente está pensada como estructura para su revisión contractual. No sustituye asesoramiento jurídico, pero ayuda a traducir requisitos técnicos y organizativos mínimos a un lenguaje contractual claro.

8.1 SLA y operación

• Disponibilidad por servicio incl. definición «interrupción» y método de medición
• Ventanas de mantenimiento con aviso previo, duración, periodos de blackout
• Prioridades de soporte con tiempos de respuesta y de actualización
• Notificación de incidentes, RCA, formato de postmortem, canales de comunicación
• Service Credits y derechos especiales en caso de repetición

8.2 Protección de datos (AVV/DSGVO)

• Roles, finalidades, categorías de datos, reglas de telemetría
• Catálogo de TOM: cifrado, acceso, registro, parcheado/vulnerabilidades
• Lista de subcontratistas + notificación de cambios + proceso de objeción
• Ubicación de los datos incl. copias de seguridad/registros/accesos de soporte
• Concepto de borrado, derechos de los interesados, información/exportación, evidencias

8.3 Seguridad y auditoría

• IAM/SSO/MFA, registro de acciones privilegiadas, Break-Glass
• Opciones de gestión de claves (BYOK/HYOK), rotación y responsabilidad
• Exportación de logs, retención, integración con SIEM, soporte forense
• Evidencias/informes, modelo de auditoría (revisión documental/en sitio según el motivo)
• Proceso CAPA para hallazgos con plazos y escalamiento

8.4 Salida

• Triggers de salida, derechos de rescisión especiales
• Plan de salida como anexo, soporte de transición con lógica de precios
• Exportación de datos: alcance, formatos, integridad (sumas de comprobación), plazos
• Borrado de datos tras la salida incl. copias de seguridad/registros y comprobante
• Control de costes: salida de datos (egress), operación en paralelo, fechas de corte de facturación

9) Plantillas prácticas: bloques de texto y requisitos verificables

Para que los requisitos no queden en el plano abstracto, conviene formularlos como criterios verificables. Los siguientes modelos están descritos deliberadamente en términos técnico-operativos. Debe adaptarlos a su contexto de riesgo y a su situación jurídica.

9.1 Ejemplo: medición de SLA e informes (verificable)

El proveedor mide la disponibilidad del servicio por cada servicio nombrado de forma mensual. Se considera no disponibilidad:
- para servicios basados en API: una tasa de error > X% (HTTP 5xx/Timeouts) durante un período deslizante de Y minutos,
- para servicios de autenticación: autenticaciones fallidas por errores del proveedor > X% durante Y minutos.

Los datos de medición y la lógica de cálculo se proporcionan al cliente mensualmente como un informe legible por máquina.
Las ventanas de mantenimiento planificadas deben anunciarse al menos Z días naturales antes y no podrán exceder un total de N horas por mes.

9.2 Ejemplo: cambios de subcontratistas y objeción

El proveedor mantiene una lista actualizada de todos los subcontratistas que acceden o procesan datos del cliente.
Los subcontratistas nuevos o sustituidos se anuncian al menos 30 días antes de su entrada en vigor.
El cliente puede presentar una objeción por causa justificada dentro de los 14 días. En ese caso, el proveedor ofrece
(a) una alternativa razonable sin el subcontratista, o
(b) un derecho de rescisión extraordinario para los servicios afectados con una asistencia de transición adecuada.

9.3 Ejemplo: salida y exportación de datos con comprobante de integridad

Al término del contrato, el proveedor facilita un exporte completo de los datos en un plazo de 10 días hábiles,
incluyendo configuración, estructuras de permisos y registros de auditoría (en la medida en que estén técnicamente disponibles).
La exportación se realiza en formatos abiertos y documentados e incluye sumas de comprobación (p. ej., SHA-256) por archivo/objeto.
El proveedor asiste al cliente hasta 20 horas para consultas sobre la interpretación del exporte.
Los datos productivos se eliminan tras la entrega satisfactoria conforme al concepto de borrado en un plazo de 30 días,
las copias de seguridad en 90 días, salvo que existan obligaciones legales de conservación o de resolución de disputas que lo impidan.

Conclusión: Un contrato en la nube es un instrumento de gobernanza – no solo un documento de compra

Con una lógica contractual limpia no se pueden “negociar” los riesgos cloud, pero sí hacerlos manejables: SLA medibles, normas de protección de datos auditables y un exit que funcione operativamente. La piedra de toque central es siempre la misma: ¿Puede su organización demostrar las obligaciones en el funcionamiento —y puede actuar en caso de incidencia sin tener que aclarar primero cuestiones interpretativas? Si utiliza esta lista de comprobación contractual para proveedores cloud como estándar mínimo, un contrato genérico de proveedor se convierte en un marco sólido para la gobernanza, la seguridad y la continuidad del negocio.

Para este tema también son importantes el SLA en la nube y el RGPD en la nube. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en la práctica.