Cláusulas contractuales para ciberseguridad y responsabilidad: formulaciones modelo para contratos de adquisición de TI

En muchas adquisiciones de TI la seguridad se “pide” pero no se “negocia” correctamente. Precisamente ahí surgen las zonas grises más costosas: ¿quién informa cuándo ante un incidente de seguridad? ¿quién asume qué costes de forense, RESTauración y obligaciones de notificación? ¿qué estándares mínimos aplican en el funcionamiento y cómo se hacen verificables? Este artículo ofrece una estructura práctica para cláusulas contractuales sobre ciberseguridad y responsabilidad en contratos de adquisición de TI, incluyendo textos modelo, priorización y perspectiva de auditoría.

Importante de entrada: los textos modelo no sustituyen el asesoramiento jurídico. El objetivo es que la dirección de TI, compras y Compliance entren a la negociación con un vocabulario común —y que las expectativas técnicas (p. ej. ventana de parches, logging, cifrado, gestión de subcontratistas) se plasmen como obligaciones verificables en el contrato. Porque sin verificabilidad la ciberseguridad en el contrato de adquisición queda como una promesa sin palanca.

Por qué las cláusulas de ciberseguridad en el contrato de adquisición determinan la operación y la responsabilidad

En la práctica la seguridad rara vez falla por falta de herramientas y sí por falta de obligaciones. El contrato de adquisición es el lugar en el que convertir el “Best Effort” en obligaciones concretas de entrega —incluyendo plazos, escalado, reglas de costes y mecanismos de verificación.

Para la operación son decisivos en particular cuatro puntos:

• Medibilidad: las obligaciones de seguridad deben ser verificables (p. ej. «corregir vulnerabilidades críticas en X días» en lugar de «estado de la técnica»).
• Claridad de responsabilidades: la lógica RACI (Responsible, Accountable, Consulted, Informed) debe traducirse a obligaciones contractuales; de lo contrario las responsabilidades durante un incidente quedan poco claras.
• Lógica de costes y responsabilidad: sin una definición de quién asume los costes y de las reglas de responsabilidad, al final suele pagar el contratante —incluso por fallos del proveedor.
• Capacidad de salida: las dependencias relevantes para la seguridad (accesos, claves, formatos de datos, logs) deben ser controlables también en el cambio de proveedor.

Lógica de adquisición: cómo priorizar cláusulas según el perfil de riesgo

No todos los contratos requieren el mismo alcance de cláusulas. En la práctica resulta útil escalonar según criticidad de los datos, grado de integración y dependencia operativa. A modo de referencia:

• Nivel 1 (bajo): sin flujo de datos personales, sin procesos críticos de producción, baja densidad de integración.
• Nivel 2 (medio): datos personales o datos operativos internos, interfaces relevantes (API), influencia sobre la disponibilidad.
• Nivel 3 (alto/crítico): procesos de negocio críticos, derechos extensos (accesos de administrador), relevancia regulatoria (p. ej. NIS2, entorno DORA), fuerte dependencia del proveedor.

Cuanto mayor sea el nivel, más debería exigir contractualmente los siguientes elementos: controles de seguridad concretos, obligaciones en incidentes, derechos de auditoría e información, control de subcontratistas, reglas de salida y una lógica de responsabilidad que no haga que las fallas de seguridad sean prácticamente «neutras en coste».

Estructura básica: bloques para cláusulas contractuales de ciberseguridad y responsabilidad

En los contratos de adquisición de TI (SaaS, Managed Services, mantenimiento on‑prem, proyectos/servicios por obra) aparecen repetidamente los mismos bloques núcleo. Si estructura estos bloques de manera consistente, ganará capacidad de negociación y reducirá las lagunas:

• Definiciones (incidente de seguridad, datos personales, vulnerabilidad crítica, subcontratista).
• Estándares mínimos de seguridad (obligaciones ISMS, control de accesos, cifrado, logging).
• Gestión de vulnerabilidades y parches (plazos, excepciones, medidas compensatorias).
• Respuesta ante incidentes & obligaciones de notificación (ventanas temporales, canales de comunicación, forense, cooperación).
• Auditoría, evidencias, informes (derechos, frecuencias, alcance, costes).
• Subcontratistas & seguridad de la cadena de suministro (aprobación, flow‑down, derechos de control).
• Responsabilidad e indemnización (límite (cap), excepciones, incumplimientos de seguridad, protección de datos).
• Salida & devolución de datos (formatos, eliminación, claves, entrega).

Definiciones que evitan disputas posteriores (y facilitan las auditorías)

Muchos conflictos surgen porque los términos no están definidos. Tres definiciones debería usted fijar con claridad en contratos relacionados con seguridad casi siempre:

1) „Incidente de seguridad“ (incidente)

Formulación tipo:

„Sicherheitsvorfall“ ist jedes Ereignis, das (i) die Vertraulichkeit, Integrität oder Verfügbarkeit der vom Auftragnehmer erbrachten Leistungen oder der verarbeiteten Daten beeinträchtigt oder beeinträchtigen kann, einschließlich bestätigter oder vermuteter unbefugter Zugriffe, Malware-Infektionen, Datenabflüsse, Verlust von Authentifizierungsdaten, sowie erheblicher Ausfälle infolge von Angriffen.

Por qué es importante: „sospechado“ y „podría afectar“ evitan que se notifique solo después de 48 horas de certeza forense.

2) „Vulnerabilidad crítica“

Conviene un enfoque objetivo aquí, sin atarse a una sola escala. Ejemplo:

„Kritische Schwachstelle“ ist eine Schwachstelle mit hohem Ausnutzungsrisiko, insbesondere wenn (i) eine Ausnutzung öffentlich bekannt ist oder aktiv erfolgt, oder (ii) privilegierte Rechte, Remote-Code-Ausführung oder Zugriff auf sensible Daten ermöglicht. Bewertungen können auf branchenüblichen Verfahren (z. B. CVSS) basieren; maßgeblich ist das tatsächliche Risiko im jeweiligen Einsatzkontext.

3) „Subcontratista“ und „proveedor tercero“

Sin una delimitación precisa, los subcontratistas en la nube, los socios de soporte o los proveedores de hosting quedan fuera de la cadena de responsabilidad.

Requisitos mínimos de seguridad: del „estado de la técnica“ a la obligación verificable

„estado de la técnica“ es relevante como término jurídico, pero operativamente demasiado vago. Para el funcionamiento de TI y la auditoría es necesario contar con controles concretos. Un buen contrato combina ambas cosas: obligación general y medidas mínimas verificables.

Cláusula modelo: Security‑Baseline

Der Auftragnehmer betreibt ein angemessenes Informationssicherheits-Managementsystem (ISMS) und gewährleistet während der Vertragslaufzeit mindestens folgende Maßnahmen: (a) rollenbasierte Zugriffskontrolle nach Need-to-know/Least-Privilege, (b) Mehrfaktor-Authentifizierung (MFA) für administrative Zugänge und Remote-Zugriffe, (c) Verschlüsselung der Datenübertragung mit aktuellen TLS-Konfigurationen, (d) Verschlüsselung sensibler Daten im Ruhezustand, (e) Protokollierung sicherheitsrelevanter Ereignisse sowie Schutz der Log-Integrität, (f) Trennung von Produktions-, Test- und Entwicklungsumgebungen, (g) regelmäßige Sicherheitsaudits und Schwachstellenbewertungen.

Viabilidad: para muchos proveedores esto ya es estándar. La diferencia es que usted lo define como pRESTación contractual con obligación de aportar pruebas.

Operacionalizar contractualmente la gestión de vulnerabilidades y parches

La gestión de parches es uno de los puntos de conflicto más frecuentes: el proveedor parchea “en algún momento”, el equipo de operaciones necesita ventanas de mantenimiento concretas y cumplimiento exige evidencias. Aquí son determinantes tiempos claros, excepciones y medidas compensatorias.

Cláusula modelo: Plazos, ventanas de mantenimiento, medidas compensatorias

El contratista evalúa las vulnerabilidades conocidas de inmediato y adopta las medidas adecuadas. Para vulnerabilidades críticas, el contratista proporciona una solución eficaz (parche, cambio de configuración o medida técnica equivalente) dentro de los 7 días naturales siguientes a su detección; para vulnerabilidades altas, dentro de los 30 días naturales. Si no es posible aplicar una solución dentro del plazo, el contratista informará por escrito al cliente sobre (i) la causa, (ii) el calendario previsto, (iii) medidas compensatorias concretas (p. ej. desactivación de funciones afectadas, RESTricciones de acceso adicionales, reglas WAF/firewall) y (iv) el riesgo residual.

Perspectiva de auditoría: Las medidas compensatorias son la clave para que la “excepción” no suponga una pérdida de control. Proporcionan tratamiento de riesgo documentado.

Respuesta ante incidentes: Plazos de notificación, canales de comunicación, colaboración

Cuando la situación es grave, las horas cuentan. Un contrato sin un camino de notificación claro genera caos: ticket de soporte en lugar de línea de incidentes, interlocutores poco claros, declaraciones contradictorias ante protección de datos y dirección.

Cláusula modelo: Plazo de notificación, contenido mínimo, interlocutores

El contratista informará al cliente de forma inmediata, como máximo en un plazo de 24 horas desde la toma de conocimiento de un incidente de seguridad. La notificación inicial contendrá al menos: (a) descripción del incidente y sistemas/servicios afectados, (b) impacto estimado sobre datos, disponibilidad e integridad, (c) estado de las medidas de contención, (d) medidas recomendadas para el cliente, (e) vías de contacto con una persona de contacto para incidentes disponible 24/7. Se realizarán actualizaciones adicionales al menos cada 24 horas hasta la estabilización.

Cláusula modelo: Forense, preservación de pruebas, acceso a registros

El contratista apoya la investigación del incidente de seguridad proporcionando los registros relevantes, información del sistema y artefactos, en la medida en que estén técnica y legalmente disponibles. Los registros se conservan con protección contra manipulaciones y se almacenan durante al menos 180 días, salvo que se acuerde otra cosa. El contratista respeta los requisitos de confidencialidad y protección de datos y coordina las medidas de preservación de pruebas con el contratante.

Importante: La conservación de logs suele ser el factor silencioso decisivo. Sin una retención adecuada, los análisis de causa raíz y las evidencias frente a auditores son prácticamente inviables.

Derechos de auditoría y evidencias: cómo diseñarlos para que los proveedores no bloqueen

Muchos proveedores no aceptan una „auditoría ilimitada“. El objetivo es, por tanto, un modelo de auditoría escalonado: primero evidencias estandarizadas, después inspecciones dirigidas cuando exista un motivo. De este modo obtiene control sin someter al proveedor a inspecciones continuas.

Cláusula modelo: cascada de evidencias

El contratista facilitará al contratante, a solicitud, evidencias adecuadas sobre la seguridad de la información (p. ej., informes de auditoría, políticas, resúmenes de resultados de pruebas de penetración, certificados, en la medida en que existan). Si las evidencias no son suficientes para una valoración ajustada al riesgo o existe un motivo concreto (p. ej., incidente de seguridad, cambio significativo, sospecha fundamentada), el contratante tendrá el derecho a una inspección razonable, previamente anunciada. Las inspecciones se realizarán durante el horario laboral habitual, preservando la confidencialidad y sin causar una interferencia indebida en las operaciones del contratista.

Nota de gobernanza: Defina internamente quién autoriza el „motivo concreto“ (p. ej., CISO/ISB y Compliance) y cómo se presupuestan los costes de las inspecciones.

Subcontratistas, hosting, soporte: traducir la seguridad de la cadena de suministro a la lógica contractual

La mayoría de los riesgos de seguridad en las soluciones empresariales digitales modernas surgen a lo largo de la cadena de suministro: operación en la nube, soporte externalizado, proveedores especializados. La idea central es el „flow-down“: los subcontratistas deben asumir, como mínimo, las mismas obligaciones que impone al proveedor principal.

Cláusula modelo: aprobación y flow-down

El uso de subcontratistas que accedan a datos o a sistemas productivos, o que pRESTen partes esenciales del servicio, requerirá la aprobación previa por escrito del contratante. El contratista garantizará que los subcontratistas asuman contractualmene obligaciones al menos equivalentes en materia de seguridad de la información, confidencialidad, protección de datos, notificación de incidentes, apoyo a auditorías y eliminación/salida. El contratista seguirá siendo responsable de los actos y omisiones de los subcontratistas.

Consecuencia práctica: Sin esta cláusula el proveedor puede trasladar obligaciones a terceros, mientras usted no dispone de derechos de intervención directa.

Responsabilidad: trampas típicas y líneas de negociación prácticas

Las cláusulas de responsabilidad son el punto en el que los requisitos de seguridad se vuelven „serios“ o bien permanecen sin consecuencias económicas. En los contratos de adquisición de TI son habituales los topes máximos de responsabilidad (Caps). El problema surge cuando las violaciones de seguridad quedan sujetas al mismo tope que errores de servicio menores.

Qué debería separar en la práctica

• Fallas de rendimiento “normales” (p. ej. disponibilidad según SLA, errores) vs. violaciones de seguridad (p. ej. configuraciones gravemente negligentes, notificación tardía de incidentes, falta de parcheo de vulnerabilidades críticas).
• Daños directos (recuperación, pRESTaciones de sustitución) vs. daños consecuenciales (interrupción del negocio, penalizaciones contractuales de terceros). Muchos proveedores excluyen los daños consecuenciales; en ese caso debe negociar partidas de costes concretas y excepciones.
• Protección de datos / normativa (p. ej. notificaciones, comunicación con autoridades) – a menudo es recomendable una indemnización por reclamaciones de terceros cuando la causa reside en el proveedor.

Cláusula modelo: lógica de responsabilidad con excepciones de seguridad

La responsabilidad queda limitada en su cuantía a [X] % de la remuneración pagada en los últimos 12 meses / [importe]. Quedan excluidos del límite de responsabilidad los daños que (i) hayan sido causados por dolo o negligencia grave, (ii) resulten de la vulneración de obligaciones de confidencialidad o protección de datos, (iii) resulten de la vulneración de obligaciones esenciales de seguridad de la información conforme a este contrato, en particular en caso de no notificación en el plazo de un incidente de seguridad o por la no subsanación culpable de vulnerabilidades críticas a pesar de plazos contractuales.

Aviso para responsables de decisión: la ‚excepción de seguridad‘ es negociable. Si el proveedor no la acepta, es una señal clara de que el riesgo se está trasladando a su lado. Entonces debería ajustar en consecuencia el precio, los controles o las opciones de salida.

Costes en un incidente: forense, recuperación, notificación – ¿quién paga qué?

En auditorías y tras incidentes hay una cuestión central: ¿están las consecuencias económicas reguladas contractualmente o las partes discuten en plena crisis? Es aconsejable separar los costes según la causa.

Cláusula modelo: asunción de costes según responsabilidad

Los costes necesarios para contener, aclarar y remediar un incidente de seguridad (p. ej., forense, recuperación, proveedores externos de respuesta a incidentes) serán asumidos por la parte causante, en la medida en que el incidente haya sido causado culpablemente dentro de su ámbito de responsabilidad. El contratista apoyará al cliente en el cumplimiento de las obligaciones legales de información y notificación y facilitará para ello la información necesaria de forma oportuna.

En la práctica: con ello evita que cada hora de servicio de respuesta a incidentes (IR) se convierta en objeto de negociación mientras los sistemas aún están comprometidos.

Protección de datos (AVV) y ciberseguridad: vincular claramente, no mezclar

Muchas organizaciones incorporan obligaciones de seguridad en el encargo de tratamiento (AVV). Eso puede funcionar, pero a menudo resulta poco práctico: el AVV cubre datos personales, no todos los datos operativos y comerciales. Es preferible: línea base de seguridad en el contrato principal, obligaciones específicas de protección de datos en el AVV, con definiciones de incidente idénticas y plazos coordinados.

Importante para la realidad operativa: un incidente de seguridad puede tener consecuencias existenciales incluso sin datos personales (p. ej., ransomware). Eso debe cubrirlo el contrato principal.

Salida, portabilidad de datos y claves: „Salir de forma segura“ es parte de la seguridad

Las cláusulas de salida suelen considerarse un tema de compra, pero son críticas para la seguridad: ¿quién controla los accesos después de la finalización del contrato? ¿Cómo se revocan claves y tokens? ¿En qué formato recibe usted datos y registros (Logs) para cumplir obligaciones de conservación y trazabilidad?

Cláusula modelo: devolución de datos y eliminación

Tras la finalización del contrato, el contratista pondrá a disposición del cliente, en el plazo de 30 días, todos los datos proporcionados por el cliente o procesados por encargo en un formato común y legible por máquina. A continuación, el contratista eliminará las copias de los datos, salvo que existan obligaciones legales de conservación, y confirmará la eliminación de forma adecuada. Los accesos, claves, tokens y permisos del contratista serán revocados o invalidados de inmediato.

Complemento para niveles altos de riesgo: plan de entrega (Runbook), responsables, exportación de prueba antes del Go‑Live, y opcionalmente modelos de „Escrow“ (depósito) para artefactos críticos en software empresarial a medida o en modelos de operación cercanos a on‑prem.

Clasificación regulatoria: NIS2, DORA y riesgo de terceros (sin debate legal)

Aunque no todas las empresas estén directamente sujetas a NIS2 o DORA, los requisitos operan como una expectativa en la cadena de suministro. En la contratación eso significa: capacidad de demostración, comunicación de incidentes, control de subcontratistas y continuidad del negocio ya no son „nice‑to‑have“.

Operativamente, para la redacción contractual esto implica:

• Las pruebas y el reporting deben poder planificarse (anual/semestral, y por incidente cuando proceda).
• La gestión de cambios ante modificaciones significativas (p. ej., cambio de infraestructura, nuevos subcontratistas) requiere obligaciones de notificación.
• La resiliencia (copias de seguridad, arranque de recuperación, objetivos RTO/RPO) debe vincularse a los SLAs.

Lista de comprobación para aprovisionamiento: lo que debe aclararse antes de la firma

Esta lista de verificación está deliberadamente formulada „apta para contrato“ – puede incorporarse a un RFP, una lista de Due‑Diligence o como anexo contractual:

• Alcance: ¿Qué datos, sistemas, interfaces (API), accesos de administrador, ubicaciones de operación están incluidos?
• Base de seguridad: MFA para administradores, TLS, cifrado en reposo, registro/retención, separación de entornos.
• Reglas de parches: Plazos para vulnerabilidades críticas/altas, ventanas de mantenimiento, medidas compensatorias.
• Reglas de incidentes: notificación inicial en 24 h, contacto 24/7, contenidos mínimos, ritmo de actualizaciones, colaboración en forense.
• Auditoría & pruebas: cadena de evidencias, auditoría por causa, confidencialidad, regla de costos.
• Subcontratistas: consentimiento, Flow‑down, la responsabilidad sigue siendo del proveedor principal.
• Responsabilidad: límite (cap) sí/no, excepciones por negligencia grave, protección de datos, incumplimiento de obligaciones esenciales de seguridad.
• Costes en incidente: asumidos según la causa, apoyo para obligaciones.
• Salida: exportación de datos, eliminación, revocación de accesos/claves, plan de entrega.

Lógica práctica de implementación: cláusulas como anexo con „Security Schedule“

Un método probado es un anexo contractual propio („Security Schedule“). Ventajas: los cambios pueden versionarse, verificarse y escalarse por nivel de riesgo, sin tener que reinventar el contrato principal cada vez.

Para la gobernanza interna esto funciona bien si define una lógica de aprobación sencilla: compras se responsabiliza de las condiciones comerciales, IT‑Security/ISB se responsabiliza de la baseline y de las obligaciones ante incidentes, operaciones se responsabiliza de SLA/Runbooks/Monitoring, y protección de datos se responsabiliza de la vinculación con AVV.

Conclusión: Las buenas cláusulas de ciberseguridad son documentos operativos, no solo texto jurídico

Cláusulas contractuales eficaces sobre ciberseguridad y responsabilidad hacen las expectativas verificables, establecen obligaciones de notificación y de colaboración, y reparten las consecuencias económicas de modo que el trabajo de seguridad deje de ser opcional. Para la dirección de TI y el cumplimiento importa menos la formulación perfecta que la aplicabilidad consistente en el día a día: plazos claros, interlocutores definidos, capacidades de auditoría, control de subcontratistas y un mecanismo de salida fiable. Si ordena estos elementos por niveles de riesgo y los adjunta al contrato como «Security Schedule», gana capacidad de gobernanza —especialmente cuando bajo presión de tiempo realmente importa.

En este tema también son relevantes los contratos de adquisición de TI y la limitación de responsabilidad en contratos de TI. El artículo sitúa estos aspectos de forma comprensible y muestra qué es importante en la operación diaria.