Gestión de riesgos de terceros: cláusulas contractuales e intervalos de auditoría para proveedores de servicios

La gestión de riesgos de terceros (Third-Party-Risk-Management) se decide en muchas organizaciones no en un documento estratégico, sino en el día a día: cuando un proveedor de servicios gestionados necesita accesos de administrador, cuando un proveedor SaaS procesa datos personales o cuando un servicio de mantenimiento interviene por acceso remoto durante la noche. En estas situaciones surgen riesgos que solo pueden resolverse técnicamente de forma parcial. El RESTo se controla mediante contratos, reglas operativas claras e intervalos de auditoría fiables.

Este artículo muestra cómo diseñar los contratos con proveedores para que realmente ayuden en la operación, y cómo planificar los intervalos de verificación basados en el riesgo sin sobrecargar a su equipo de auditoría y seguridad. El foco está en cláusulas concretas, la lógica de gobernanza, la evidencia para los auditores y en quién debe entregar qué y cuándo: TI, Compliance, Compras y el proveedor.

Por qué los contratos y los intervalos de verificación pertenecen juntos en la gestión de riesgos de terceros

Un malentendido frecuente: los contratos regulan “jurídicamente”, las auditorías regulan “técnicamente”. En la práctica ambos son indivisibles. Una obligación contractual sin un mecanismo de verificación se convierte en una cláusula que solo queda en papel. Un requisito de auditoría sin base contractual acaba en discusiones sobre «no exigible» o «no razonable».

Para los responsables de TI es importante: muchas medidas de seguridad en terceros no son directamente ejecutables porque usted no dirige ni los sistemas ni el personal. Sin embargo, puede fijar contractualemente requisitos sobre procesos (p. ej., gestión de parches y de vulnerabilidades), sobre evidencias (p. ej., informes de auditoría), sobre plazos de notificación (p. ej., notificación de incidentes) y sobre vías de acceso (p. ej., Jump-Host, MFA). Los intervalos de verificación son entonces el ritmo en el que controla si esos requisitos siguen vigentes y se aplican en la práctica, sobre todo después de cambios organizativos, migraciones de plataforma o sustituciones de subcontratistas.

Aclarar el alcance: ¿qué tipo de proveedores necesitan qué profundidad?

Antes de definir cláusulas e intervalos debe quedar claro el alcance. No todo proveedor es un “proveedor crítico”. Al mismo tiempo, una clasificación genérica «crítico/no crítico» rara vez basta. En la práctica ayudan tres ejes que deberá documentar en el registro de proveedores (Vendor Inventory):

• Relación con los datos: ¿Se procesan datos personales, secretos comerciales confidenciales o datos de autenticación? (En el caso de datos personales: con frecuencia tratamiento por encargo según el RGPD, abreviado AVV.)
• Acceso al sistema: ¿Tiene el proveedor acceso a la red o a sistemas, privilegios de administrador, acceso a identidades o a mecanismos de copia de seguridad/recuperación?
• Dependencia operativa: ¿Qué impacto tiene una interrupción en procesos críticos, producción, facturación, niveles de servicio o cumplimiento?

De estos ejes se deriva un escalonado basado en riesgo, p. ej. Tier 1 (crítico), Tier 2 (importante), Tier 3 (estándar). Esto no es un ejercicio académico: el tiering determina qué cláusulas son obligatorias, el nivel de pruebas requerido y la frecuencia de las comprobaciones.

Cláusulas contractuales que realmente gobiernan los riesgos operativos

Las siguientes áreas de cláusulas son especialmente efectivas en el Third-Party-Risk-Management porque conectan directamente con realidades operativas: accesos, cambios, incidentes, evidencias, subcontratistas y plan de salida. No toda cláusula encaja con cualquier proveedor; lo decisivo es la combinación de la clase de riesgo y el modelo de prestación (SaaS, servicio gestionado, contrato de obra, soporte/mantenimiento, hosting, reventa en la nube).

1) Requisitos de seguridad como mínimos medibles

En lugar de “seguridad adecuada” deberían describirse estándares mínimos concretos y verificables. No se trata de la implementación completa de ISO o NIST, sino de requisitos base fiables que usted pueda controlar.

• Identity & Access: MFA para accesos privilegiados, principio de menor privilegio, recertificación periódica de cuentas, desprovisionamiento inmediato ante cambios de personal.
• Cifrado: cifrado en tránsito (TLS), cifrado de datos en reposo, gestión de claves (quién gestiona las claves, cómo se rotan).
• Vulnerability & Patch: ventanas de parche definidas, priorización de vulnerabilidades críticas, manejo de componentes no parcheables (mitigación, controles compensatorios).
• Logging & Monitoring: registro de acciones relevantes para la seguridad, períodos de retención, acceso a los logs en caso de incidente.

Importa una formulación que no termine en “Best Effort”, sino que incluya responsabilidades y plazos. Al mismo tiempo los requisitos deben ajustarse al servicio: en SaaS rara vez obtiene detalles del sistema, pero puede exigir evidencias y controles garantizados.

2) Derechos de auditoría y evidencias: lo que puede exigir de forma realista

El derecho de auditoría es un instrumento central, pero con frecuencia resulta o demasiado blando (“previa coordinación”) o demasiado rígido (“acceso presencial en cualquier momento”), de modo que en la práctica es inutilizable. Un enfoque práctico combina:

• Derecho a evidencias: suministro periódico de pruebas de auditoría y cumplimiento (p. ej. certificado ISO 27001 con Statement of Applicability, informe SOC-2 Tipo II, resumen de pruebas de penetración, evidencias de pruebas BCM).
• Derecho de auditoría (escalonado): auditoría remota como estándar, auditoría presencial ante triggers definidos (incidente crítico, cambio material, incumplimientos repetidos de SLA, sospecha de violación contractual).
• Reglas de alcance y confidencialidad: para que el proveedor no pueda rechazar de forma general y usted obtenga, aun así, una visión verificable (p. ej. acceso a descripciones de procesos relevantes, no al código fuente).

Desde la perspectiva de la auditoría no basta con que teóricamente “tenga derecho a auditar”; el contrato debe describir qué evidencias se entregan cuándo y cómo se tratan las desviaciones (plan de remediación, plazos, seguimiento).

3) Notificación de incidentes y brechas con plazos y contenidos claros

En incidentes de seguridad el tiempo es la variable decisiva. Por eso las cláusulas contractuales no solo deben fijar plazos de notificación, sino también contenidos y vías de comunicación.

• Definiciones: ¿qué es un “Security Incident”, qué es una “Breach” (p. ej. violación de confidencialidad, pérdida de integridad, interrupción por ataque)?
• Canal de notificación: punto de contacto accesible 24/7, matriz de escalación, obligación de confirmar la recepción.
• Lógica de plazos: «Notificación inicial» dentro de las horas definidas, actualizaciones de seguimiento a intervalos fijos, informe de cierre.
• Requisitos de contenido: sistemas afectados/categorías de datos, periodo, indicadores, medidas inmediatas, próximos pasos previstos, posibles impactos en su entorno.

Para configuraciones relevantes para el RGPD (encargado del tratamiento) es especialmente importante que el proveedor le informe de manera que usted pueda cumplir sus propias obligaciones de notificación y comunicación. Una cláusula demasiado vaga genera, en caso grave, lagunas de documentación.

4) Hacer controlables a los subcontratistas (subprocesadores) y los cambios de ubicación

Muchos riesgos no se originan en el proveedor principal, sino en la cadena: centro de datos, socio de soporte, call center, incident responder, subcontratistas en la nube. Por ello los contratos deberían regular:

• Obligación de transparencia: lista de subcontratistas, proporción del servicio y relación con datos/accesos.
• Derecho de aprobación o de oposición: previo a cambios, especialmente en el tratamiento de datos, accesos de administrador o traslado de ubicación.
• Flow-down: obligación de transmitir a los subcontratistas sus requisitos mínimos (efecto de repercusión contractual).
• Geografía y residencia de datos: dónde se permite procesar datos, incluidos sitios de copia de seguridad y países de soporte remoto.

Sin estas cláusulas los intervalos de auditoría resultan ineficaces, porque al auditar siempre se le «sorprende»: otro operador, otro país, otra cadena.

5) Gestión de cambios: cambios que debe conocer obligatoriamente de antemano

Los riesgos técnicos aumentan de forma abrupta con los cambios: migración de plataforma, cambio de IAM, modificaciones en el logging, nuevas herramientas de administración, nuevos segmentos de red. A menudo falta en los contratos la obligación de información previa. Son aconsejables:

• Notificación de cambio material: obligación de notificar cambios significativos en controles de seguridad, modelo operativo, subcontratistas o ubicaciones de datos.
• Obligaciones de colaboración: p. ej. ventanas de prueba, procesos de aceptación, obligación de plan de retorno (rollback).
• Compromisos de compatibilidad: para interfaces (APIs), procedimientos de autenticación, protocolos, listas blancas de IP.

Para la dirección de TI esto es especialmente relevante, porque los cambios del proveedor suelen romper sus propios procesos operativos: integración SSO, reglas de firewall, integración SIEM o exportaciones de backup.

6) SLA, SLO y créditos de servicio: no solo disponibilidad, sino capacidad de recuperación

Muchos SLA se centran en la disponibilidad, pero no en la capacidad de recuperación. Para el perfil de riesgo son con frecuencia más importantes:

• RTO/RPO: Recovery Time Objective (tiempo de recuperación) y Recovery Point Objective (pérdida máxima de datos) — por servicio, no de manera general.
• Obligaciones de backup y RESTore: intervalos de prueba para RESTauración, evidencias de recuperaciones exitosas.
• Ventanas de mantenimiento & capacidad: paradas planificables, mecánica de escalado ante picos de carga.
• Metodología de medición: quién mide, desde dónde, qué excepciones aplican (p. ej. mantenimiento planificado solo tras anuncio previo).

Los créditos de servicio no son un instrumento de seguridad, pero establecen un incentivo económico. Para servicios críticos deberían combinarse con derechos de remediación y de escalado (p. ej. obligación de análisis de causa raíz ante incumplimientos repetidos).

7) Devolución de datos, eliminación y estrategia de salida (incl. operación de transición)

La fase de salida es el punto más frecuente para brechas de cumplimiento y seguridad: exportaciones de datos incompletas, cuentas residuales, confirmaciones de eliminación poco claras, falta de apoyo en el cambio de proveedor. Los contratos deben regular:

• Portabilidad: formatos de exportación, frecuencia, exportación por API/lotes, metadatos y registros.
• Eliminación y comprobante: plazos de eliminación, tratamiento de copias de seguridad, confirmación de eliminación como evidencia.
• Servicios de transición: horas de soporte definidas/tarifas diarias, acceso a personal especializado, entrega de documentación.
• Desmantelamiento de cuentas y claves: desactivación de accesos, rotación de secrets/keys tras la finalización del contrato.

Sin cláusulas de salida, corre el riesgo de permanecer vinculado más tiempo del previsto o de cambiar con un riesgo innecesario.

Establecer intervalos de revisión basados en riesgo: cadencia, disparadores y esfuerzo

Los intervalos de revisión no son un fin en sí mismos. Deben, con un esfuerzo razonable, responder a dos preguntas: ¿Ha cambiado el riesgo? ¿Siguen funcionando los controles acordados? Una revisión anual aislada suele ser demasiado burda; una revisión completa trimestral por lo general no es asumible. Ha demostrado su validez un modelo por capas:

Capa 1: controles continuos „ligeros“ (operativos)

Estos controles están próximos a la operación y entregan señales tempranas. Ejemplos:

• Informes SLA/SLO (mensuales) y análisis de incidentes
• Notificaciones de cambios (Material Change) y su impacto en el riesgo
• Avisos de seguridad del proveedor y tiempos de respuesta
• Conciliación de accesos activos/cuentas de soporte (p. ej. trimestral)

Aquí pesa menos la profundidad que la regularidad. El objetivo es identificar disparadores de forma temprana.

Capa 2: revisión periódica de evidencias (con cadencia de cumplimiento)

Se trata de los comprobantes que debe recoger y evaluar periódicamente. Intervalos típicos según clase de riesgo:

• Tier 1 (crítico): revisión basada en evidencias cada seis meses, revisión profunda anual
• Tier 2 (importante): revisión basada en evidencias anual
• Tier 3 (estándar): cada 24 meses o al producirse un disparador

Los intervalos son valores iniciales. Lo decisivo es que pueda justificarlos: criticidad de los datos, derechos de acceso, dependencias, historial de incidentes, frecuencia de cambios.

Capa 3: revisiones profundas (Audit / Onsite / revisiones técnicas)

Las revisiones profundas deben planificarse de forma puntual, pero con desencadenantes claros. Disparadores típicos:

• incidente grave o incidentes de seguridad repetidos
• cambio sustancial en el servicio (cambio de plataforma, IAM, subcontratistas, residencia de datos)
• evolución anómala en SLA/indicadores de calidad
• nuevos requerimientos regulatorios o nuevos tipos de datos
• ampliación del alcance (más sistemas, más accesos, más datos)

Esto reduce el esfuerzo sin operar a ciegas.

Concepto de revisión en concreto: qué evidencias debe solicitar a cada proveedor

Un Third-Party-Risk-Management verificable necesita paquetes de evidencia estandarizados. Importante: „solicitarlo todo“ no funciona; o no recibe nada o recibe documentos no estructurados. Son mejores paquetes escalonados:

Evidencia básica (para casi todos los proveedores relevantes)

• descripción actual del servicio y del alcance (qué se entrega exactamente, dónde están los límites del sistema)
• puntos de contacto, escalamiento, disponibilidad 24/7 (cuando proceda)
• lista de subcontratistas con su alcance
• Anexos de protección de datos y seguridad, incl. TOMs (Medidas técnicas y organizativas; en breve: las TOMs son medidas de protección descritas de forma concreta)
• Resumen BCM/DR (Business Continuity Management / Disaster Recovery), incl. evidencias de pruebas si es crítico

Evidencia ampliada (Tier 1/2 o en caso de acceso a datos o con privilegios de administrador)

• Certificado ISO 27001 o paquete de evidencia ISMS equivalente (ISMS = sistema de gestión de seguridad de la información)
• SOC-2 Tipo II o informe de auditoría comparable, incl. respuesta de la dirección
• Resumen de pruebas de penetración, incl. estado de remediación de hallazgos críticos
• Evidencias de procesos para gestión de parches, vulnerabilidades e incidentes
• Pruebas de controles de acceso (recertificación, política de MFA, registro de eventos)

Evidencia técnica de integración (si opera interfaces)

• Descripción de API/interfaz, procedimientos de autenticación (p. ej. OAuth, mTLS), tiempos de validez de tokens
• Proceso de rangos IP/allowlist, rotación de claves, gestión de secretos
• Capacidad de entrega de logs (p. ej. Syslog, exportación por API, integración SIEM) y retención

Para los auditores cuenta: debe poder demostrar que no solo recopila las evidencias, sino que las evalúa y deriva acciones.

Gobernanza: roles, responsabilidades y lógica de decisiones

La gestión de riesgos de terceros rara vez falla por falta de voluntad, sino por responsabilidades. Una gobernanza práctica separa cuatro roles, que no tienen que ser necesariamente cuatro equipos:

• Service Owner (funcional/IT): es responsable del valor, el alcance y las interfaces operativas; evalúa el impacto de los cambios.
• Risk/Compliance Owner: define requisitos mínimos, estándares de evidencia, frecuencias de auditoría; documenta decisiones de riesgo.
• IT-Security (operativo): evalúa controles técnicos, integra logs/incidentes, acompaña auditorías y remediación.
• Compras/Legal: negocia cláusulas, asegura el cumplimiento de estándares, gestiona plazos contractuales y renovaciones.

Es importante un mecanismo de decisión claro para excepciones (Exceptions): si el proveedor no acepta una cláusula, necesita una aceptación de riesgo documentada o una compensación (p. ej. acceso más RESTrictivo, controles de monitorización adicionales, plazo contractual más corto).

Plantilla RACI mínima (como punto de partida)

Tarea: Clasificación de riesgo del proveedor        R: Compliance/Risk  A: Dirección de TI  C: Service Owner, IT-Security  I: Compras/Legal
Tarea: Cláusulas mínimas por clase de riesgo        R: Compliance/Risk  A: Dirección de TI  C: Legal, IT-Security           I: Service Owner
Tarea: Requisitos técnicos de integración           R: IT-Security      A: Service Owner C: Compliance/Risk           I: Compras/Legal
Tarea: Recopilar y evaluar evidencias                 R: Compliance/Risk  A: Dirección de TI  C: IT-Security, Service Owner I: Compras/Legal
Tarea: Seguimiento de remediación                    R: Service Owner    A: Dirección de TI  C: IT-Security, Compliance    I: Compras/Legal

La plantilla es deliberadamente compacta. Amplíela con artefactos concretos (p. ej. „Evidence-Paket Tier 1“, „Incident-Runbook“, „Exit-Checkliste“), para que en la auditoría quede claro qué significa „completado“.

Perspectiva de auditoría: lo que los auditores suelen querer ver

Independientemente de normas concretas (p. ej. ISO 27001, auditoría interna, requisitos regulatorios por sector), las expectativas son similares:

• Completitud: ¿Dispone de un registro de proveedores actualizado, incluyendo clasificación de riesgo y referencia a datos/accesos?
• Trazabilidad: ¿Puede justificar por qué un proveedor es Tier 1/2/3 y por qué se eligió ese intervalo de revisión?
• Eficacia: ¿Existen evidencias de que los controles se han implementado (evidencias, reuniones, tickets de remediación, escaladas)?
• Respuesta ante desviaciones: ¿Qué ocurre ante hallazgos? ¿Hay plazos, responsables, reexaminación?
• Salida y continuidad: ¿Existe un plan si el proveedor falla o debe ser reemplazado?

Un hallazgo frecuente en auditorías no es la „cláusula ausente“, sino la „falta de evidencia del control continuo“: documentos presentes, pero sin evaluación, sin decisiones, sin seguimiento.

Planificar costes y esfuerzo de forma realista: dónde surge la complejidad

La gestión de riesgos de terceros requiere tiempo porque es trabajo de interfaces. Bloques típicos de esfuerzo:

• Clasificación inicial: flujos de datos, accesos, dependencias de procesos – a menudo distribuidos entre varios equipos.
• Negociación: los proveedores no aceptan cláusulas estándar o solo con coste adicional; especialmente con grandes proveedores SaaS las modificaciones son limitadas.
• Gestión de evidencias: recopilar, evaluar, archivar, controlar plazos.
• Integración técnica: SSO, registro de eventos, acceso a la red, secretos, accesos de emergencia.

Gestión pragmática: estandarice tanto como sea posible (conjunto de cláusulas por Tier, paquete de evidencias por Tier, lista de verificación de revisión), pero deje espacio para excepciones. Un número reducido de proveedores Tier-1 gestionados de forma ordenada es mejor que un proceso formalmente perfecto que no se aplica en la operación.

Listas de verificación: de uso inmediato para revisión de contratos y planificación de auditorías

Lista de verificación A: cláusulas contractuales para proveedores Tier-1 (forma abreviada)

• Base de seguridad (IAM/MFA, cifrado, registro de eventos, gestión de parches/vulnerabilidades, proceso de incidentes) definida y verificable
• Notificación de incidentes/violaciones: plazos, contenidos, canal 24/7, ritmo de actualizaciones
• Derechos de auditoría: obligación de suministro de evidencias + derecho de auditoría escalonado incl. desencadenantes
• Subcontratistas: transparencia + aprobación/objeción + aplicación en cascada (flow-down)
• Notificación de cambios materiales, incl. cambios de seguridad y de ubicación
• BCM/DR: RTO/RPO, evidencias de pruebas, escalada en caso de incumplimiento
• Salida: exportación de datos, eliminación incluida la gestión de backups, apoyo en la transición
• Modelo de acceso: acceso remoto solo por vías definidas, registro, limitado en el tiempo

Lista de verificación B: establecer intervalos de revisión (lógica de decisión)

• ¿Qué categorías de datos? (personales/confidenciales/cercanos a la autenticación)
• ¿Qué derechos de acceso? (sin acceso/estándar/privilegiado)
• ¿Cuál es el impacto de una falla? (RTO/RPO, criticidad del proceso)
• ¿Frecuencia de cambios del proveedor? (estable vs. despliegues/ajustes frecuentes)
• Historial de incidentes/hallazgos? (ninguno vs. recurrente)
• Regulación/sector? (obligaciones adicionales, densidad de evidencias)

Si tres o más puntos son „altos“, típicamente es plausible clasificar como Tier 1 con al menos una revisión profunda anual. Si solo un punto es „alto“, puede bastar Tier 2, siempre que lo compense (por ejemplo, acceso más RESTrictivo, evidencias de monitorización adicionales).

Peligros típicos – y cómo evitarlos

• „Certificado“ sin revisar el alcance: ISO 27001 o SOC 2 solo dicen algo sobre el alcance auditado. Verifique si su servicio está dentro del alcance.
• Derecho de auditoría sin desencadenantes: „Podemos auditar“ no sirve cuando las auditorías in situ son prácticamente imposibles. Defina desencadenantes y alternativas remotas.
• AVV separado de las operaciones: Los anexos de protección de datos se leen a menudo sin el equipo de operaciones de TI. Resultado: las TOMs prometen registro o eliminación que no se implementan operativamente.
• Exit olvidado: Si la exportación/el borrado no se regulan por adelantado, el cambio resulta costoso y arriesgado.
• Intervalos de revisión como cita en el calendario: Sin paquetes de evidencia claros y criterios de evaluación, las revisiones se convierten en mera acumulación de documentación.

Conclusión: la capacidad de control surge de cláusulas y cadencia

La gestión de riesgos de terceros resulta eficaz cuando los contratos accionan las palancas adecuadas y los intervalos de revisión traducen esas palancas en un ritmo de control fiable. No es decisivo el número de cláusulas, sino su adecuación al riesgo: accesos, datos, dependencia y velocidad de cambio. Combine requisitos mínimos verificables, derechos escalonados de auditoría y de evidencia, obligaciones claras de notificación de incidentes, cadenas de subcontratistas controlables y una estrategia de salida sólida. Establezca intervalos de revisión en capas: controles ligeros y continuos; revisiones periódicas de evidencia; auditorías en profundidad cuando se activen desencadenantes.

Así se crea un modelo que funciona en operación, que puede explicarse en auditoría y que hace que las decisiones sean rastreables —incluidas excepciones documentadas cuando un proveedor no cumple con todo.

Para este tema también son importantes el riesgo del proveedor y la gestión de proveedores. El artículo sitúa estos aspectos de forma comprensible y muestra qué es relevante en la práctica cotidiana.