En este capítulo
Ecosistema contractual tecnológico
Las organizaciones contratan licencias de software, servicios SaaS, infraestructura cloud, soporte y actividades de seguridad. Cada relación distribuye funciones de manera distinta. Un servicio que parece secundario puede resultar crítico si concentra autenticación, datos o conectividad. Antes de negociar cláusulas conviene describir qué depende del proveedor, qué información utiliza y qué interrupciones podrían afectar la operación. Los contratos marco y anexos deben estar alineados; una cláusula general de disponibilidad puede ser insuficiente para un proceso que necesita recuperarse en un plazo corto. El contrato no reemplaza el análisis técnico de las dependencias.
Conceptos de este apartado
- Licencias, servicios y outsourcing
- SaaS, PaaS e IaaS
- Managed services y MSSP
- Integradores y subcontratistas
- Contratos marco, órdenes y anexos
- Identificación de dependencias críticas
Due diligence de seguridad
La diligencia debida o due diligence busca comprender si un proveedor puede cumplir requisitos proporcionales al riesgo. Los cuestionarios son un punto de partida, pero una afirmación de «seguridad certificada» debería concretarse: alcance, estándar, vigencia y servicios cubiertos. También importan informes de auditoría, historial de incidentes, subcontratistas y controles específicos. Una pequeña herramienta que procesa información muy sensible puede requerir mayor revisión que un servicio más grande con datos públicos. La evaluación documenta hallazgos y limitaciones, y define medidas de seguimiento. Recibir un PDF de certificación no equivale a examinar todo el ecosistema operativo.
Conceptos de este apartado
- Cuestionarios y evidencias
- Certificaciones e informes de auditoría
- Revisión de arquitectura y controles
- Historial de incidentes
- Subprocesadores y cuarta parte
- Evaluación basada en criticidad
Cláusulas de seguridad y privacidad
Las cláusulas de seguridad establecen obligaciones sobre accesos, cifrado, vulnerabilidades, incidentes, conservación de evidencia y cooperación. Deben indicar quién realiza qué acción y en qué circunstancias, evitando fórmulas imposibles de verificar. Los acuerdos de tratamiento de datos, cuando corresponden, se suman a las obligaciones de seguridad. Una notificación contractual de incidentes puede necesitar plazos diferentes a los exigidos por leyes sectoriales; ambas capas deben coordinarse. Es útil prever acceso a información técnica suficiente para investigar sin comprometer secretos o derechos de otras partes. La calidad del contrato depende de su operatividad, no de la cantidad de términos técnicos incluidos.
Conceptos de este apartado
- Obligaciones mínimas de seguridad
- Control de acceso y cifrado
- Gestión de vulnerabilidades
- Notificación de incidentes
- Cooperación y preservación de evidencia
- Protección de datos y DPA
SLA, continuidad y responsabilidad
Un acuerdo de nivel de servicio o SLA define indicadores como disponibilidad y tiempos de respuesta, pero no implica por sí mismo que exista continuidad de negocio. Los objetivos RTO y RPO expresan, respectivamente, el tiempo deseado de recuperación y la pérdida de datos temporalmente tolerable. Una cláusula de responsabilidad debe examinar riesgos reales, seguros y posibles limitaciones legales. La dependencia de un proveedor introduce escenarios de fallo que pueden exceder una compensación económica prevista en el contrato. Por eso, negociación y arquitectura deben coordinarse: ninguna indemnización recupera automáticamente un servicio crítico durante una crisis.
Conceptos de este apartado
- Disponibilidad y niveles de servicio
- RTO/RPO contractuales
- Backups y recuperación
- Limitaciones de responsabilidad
- Indemnidades y seguros
- Fuerza mayor y eventos cibernéticos
Auditoría, monitorización y cambio
La supervisión de proveedores continúa después de firmar. Informes periódicos, indicadores, cambios de arquitectura y auditorías pueden revelar desviaciones. Un proveedor que subcontrata nuevas funciones o modifica la región de procesamiento puede alterar el riesgo y las obligaciones de datos. Los contratos deberían establecer comunicaciones de cambios materiales y posibilidades razonables de revisión. Cuando un control falla, se necesita un plan de remediación con plazos y verificación de cierre. La evaluación debe evitar exigir evidencias imposibles o innecesarias; la materialidad y criticidad del servicio orientan la profundidad de cada comprobación.
Conceptos de este apartado
- Derechos de auditoría
- Informes de terceros
- Planes de remediación
- Cambios materiales en servicio
- Notificación de subcontratistas
- Reevaluación periódica
Terminación y exit strategy
Salir de un servicio tecnológico suele ser más complejo que contratarlo. Un plan de salida debe prever exportación de datos, formatos interoperables, asistencia de transición, borrado verificable y conservación legítima de evidencia. La migración puede interrumpir servicios si se subestiman configuraciones, dependencias o tiempos de transferencia. El bloqueo por proveedor, o lock-in, no siempre es ilegítimo, pero debe reconocerse y gestionarse. La continuidad durante la transición es tan importante como el resultado final. Un contrato responsable define qué ocurre con las cuentas, claves, logs y documentación después de terminar la relación.
Conceptos de este apartado
- Portabilidad y devolución de datos
- Borrado seguro
- Transición a nuevo proveedor
- Asistencia de salida
- Custodia de evidencia y logs
- Riesgo de lock-in y continuidad durante la migración
Un caso para comprenderlo
Una empresa contrata un software de expediente electrónico sin prever cómo recuperar información al terminar el servicio. Cuando el proveedor modifica precios descubre dificultades de exportación y dependencia técnica. Una diligencia debida previa y cláusulas de salida habrían permitido valorar interoperabilidad, conservación, borrado y continuidad de manera más realista.
Cómo aplicar estos conceptos
El punto de partida es describir el sistema o situación con precisión, distinguir hechos de suposiciones y seleccionar qué información permitiría comprobar una conclusión. A partir de ahí se identifican riesgos, controles, responsabilidades y evidencias posibles. La utilidad de estos conocimientos aumenta cuando se relacionan con otras áreas de la ciberseguridad y del Derecho informático.
Fuentes y lecturas de referencia
Para aplicar estos marcos a un caso concreto deben comprobarse la versión vigente, el ámbito de aplicación y las condiciones del supuesto.