La seguridad de su organización es tan sólida como su proveedor más débil. Puede sonar a tópico, hasta que los controles de acceso deficientes de un proveedor interrumpen sus operaciones o un regulador pregunta por qué no se validó la resiliencia de los socios críticos.

Normativas como NIS2 y DORA han convertido la gobernanza de proveedores en un asunto de nivel directivo, no porque a los reguladores les guste el papeleo, sino porque los incidentes en la cadena de suministro son ya demasiado frecuentes y dañinos para considerarlos un problema ajeno. Este artículo presenta un marco práctico y directo para ir más allá de los cuestionarios básicos a proveedores. Explica dónde comienza realmente gran parte del riesgo de terceros, cómo detectar problemas de concentración antes de que causen daños y por qué la planificación de salida no es opcional.

El riesgo comienza antes del contrato

Una parte importante del riesgo de terceros se acepta en el momento en que compras, legal y seguridad no participan en la misma conversación. Se firman demasiados acuerdos en los que seguridad interviene como una mera validación formal cuando las condiciones comerciales ya están cerradas. El resultado son contratos con derechos de auditoría débiles, cláusulas imprecisas de notificación de incidentes y sin una responsabilidad operativa clara.

La mejor gobernanza de proveedores comienza con los estándares que la organización está dispuesta a exigir durante la negociación, no después. Una regla sencilla: si un proveedor crítico rechaza una cláusula de derecho de auditoría, debe tratarse como una decisión de riesgo con un responsable y una aceptación documentada, no con indiferencia.

Pensemos en una empresa industrial que firmó un contrato plurianual con un nuevo proveedor de ERP en la nube sin incorporar requisitos de seguridad al SLA. Cuando surgieron problemas en la relación, el proveedor se negó a compartir informes de auditoría críticos. La remediación costó una cifra de seis dígitos y se prolongó durante meses. La lección no fue que el proveedor fuera difícil, sino que el contrato no le obligaba a cooperar.

Las cláusulas de derecho de auditoría, los plazos de notificación de incidentes, las obligaciones de tratamiento de datos y las condiciones de salida no son añadidos jurídicos. Son controles de seguridad expresados en lenguaje comercial. Si no están en el contrato, no existen.

La realidad de NIS2: usted responde por el fallo del proveedor

En virtud de NIS2, si un proveedor crítico se ve comprometido y su servicio deja de funcionar, el regulador exigirá responsabilidades a su organización, no solo al proveedor. La Directiva es explícita: las entidades esenciales e importantes deben gestionar los riesgos de seguridad derivados de sus proveedores y prestadores de servicios.

No se trata de una expectativa general de buena conducta. Es una obligación de cumplimiento con consecuencias de supervisión y sanción.

En una empresa energética se daba por hecho que el proveedor de mantenimiento SCADA era seguro. Una evaluación de brechas reveló que utilizaba credenciales administrativas compartidas y sin parchear para varios clientes. El problema se corrigió antes de que se convirtiera en una notificación de brecha. Ese es el nivel de validación activa que los reguladores esperan hoy. Preguntar «¿cumplen?» no basta. Es necesario ver evidencias y revisarlas de forma periódica.

Como mínimo, la mayoría de las organizaciones debería aplicar a sus proveedores críticos:

  • Un cuestionario anual de seguridad validado mediante evidencias, no solo mediante autoevaluación
  • Una cláusula de derecho de auditoría que se utilice realmente
  • Obligaciones de notificación de incidentes con plazos definidos
  • Evidencias de sus propias pruebas y de su capacidad de resiliencia

Para los proveedores de máxima criticidad, esta base es únicamente el punto de partida.

Lo que debe revelar un buen registro de terceros

Listar proveedores es solo el comienzo. El verdadero valor está en lo que el registro permite descubrir.

En una entidad bancaria no bastaba con disponer de un listado de proveedores. Se enriqueció el registro y se comprobó que el 40 % del procesamiento de pagos críticos dependía de una única región de nube en Fráncfort. Esa visibilidad permitió diseñar una estrategia de conmutación por error multirregión antes de que una caída regional afectara a los clientes. El registro no prescribió la solución, pero hizo imposible ignorar la exposición.

Un registro maduro de terceros debe mostrar:

  • Riesgo de concentración: cuántos servicios críticos dependen de un único proveedor o de una única ubicación geográfica
  • Opciones de salida débiles: relaciones de las que no existe una vía práctica para salir
  • Dependencias frágiles: proveedores que constituyen un punto único de fallo para un proceso crítico de negocio
  • Brechas en la calidad contractual: situaciones en las que las protecciones contractuales no se corresponden con la criticidad de la relación

DORA exige a las entidades financieras mantener un registro de información sobre todos los acuerdos contractuales con proveedores terceros de servicios TIC. El Reglamento concreta qué debe contener ese registro. Incluso fuera del sector financiero, el principio sigue siendo válido: si el registro no ayuda a identificar riesgos, es solo una hoja de cálculo con pasos adicionales.

La responsabilidad compartida no es una exención

Demasiadas organizaciones migran a AWS, Azure o Google Cloud y presuponen que el proveedor se ocupa de todo. El modelo de responsabilidad compartida es preciso, no ambiguo. AWS protege la nube; la organización es responsable de lo que introduce en ella: datos, configuración, accesos, monitorización y copias de seguridad.

Una empresa sufrió una fuga de datos porque asumía que su proveedor SaaS realizaba copias de seguridad de los datos de configuración. Las condiciones del proveedor indicaban expresamente que esa responsabilidad correspondía al cliente. Nadie las había leído con suficiente atención. Las suposiciones se convirtieron en exposición.

Un modelo claro de gobernanza de la nube elimina esa ambigüedad. Debe documentarse quién es responsable del registro de eventos, la recuperación, la gestión de accesos y la respuesta a incidentes. Después hay que probarlo, porque una suposición no documentada y una suposición documentada pero nunca probada son igual de peligrosas durante un incidente real.

La planificación de salida forma parte de la resiliencia

Una dependencia no está realmente gestionada si no existe una vía de salida creíble. Esto se aplica por igual a proveedores de nube, servicios gestionados, plataformas de software y consultoras especializadas.

Durante un proyecto de preparación para DORA en una aseguradora se formuló al proveedor de la plataforma central de administración de pólizas una pregunta sencilla: «Si mañana entra en quiebra, ¿cómo recuperamos nuestros datos en 48 horas?». El proveedor no tenía un proceso automatizado de exportación. Habrían sido necesarias semanas, o quizá más, para recuperar los datos en un formato utilizable. Se estableció como condición para renovar el contrato un depósito mensual de datos en custodia.

Si los contratos con proveedores críticos no incluyen una cláusula de salida con pasos prácticos —formato de datos, plazo, parte responsable y coste—, la organización no es resiliente. Está cautiva y solo descubrirá hasta qué punto cuando ya sea demasiado tarde para negociar.

La planificación de salida no implica esperar que las relaciones fracasen. Consiste en conservar la capacidad de actuar cuando eso suceda.

La incorporación de proveedores convierte los estándares en realidad

Una política de proveedores solo es útil si el proceso de incorporación la hace cumplir. Muchas organizaciones tienen políticas sólidas sobre el papel y controles de entrada débiles en la práctica. El momento en que un nuevo proveedor necesita acceso suele ser también el momento en que los estándares desaparecen silenciosamente bajo la presión comercial.

En una entidad financiera se diseñó un flujo de incorporación en el que ningún proveedor podía ser dado de alta en el sistema de gestión de identidades hasta que se hubiera revisado su informe SOC 2 Tipo II, verificado y registrado en la herramienta GRC sus datos de contacto para incidentes, y confirmado sus obligaciones de clasificación de datos. Durante el primer mes, el proceso impidió que tres proveedores de alto riesgo accedieran a la red.

Los controles prácticos sobre la provisión de accesos, la confirmación del tratamiento de datos, la revisión de evidencias y el registro de contactos para incidentes convierten una buena política en un control real. Sin ellos, la incorporación es solo un correo de bienvenida.

La proliferación de SaaS es un problema de GRC, no solo de inventario de TI

Los departamentos de marketing contratan herramientas con tarjetas corporativas sin que nadie evalúe su seguridad. Con el tiempo, el número de plataformas no gobernadas aumenta y también lo hace la exposición.

Se han dado casos en los que listas de clientes se cargaron para entrenar modelos públicos de aprendizaje automático porque nadie revisó las condiciones de uso del proveedor. Marketing no era consciente del riesgo, TI no tenía visibilidad y GRC no había sido informado. Los datos ya eran públicos cuando alguien detectó el problema.

La proliferación de SaaS genera deriva de accesos, propiedad de datos poco clara, condiciones contractuales no revisadas y exposición oculta a proveedores. Es un asunto de GRC porque los riesgos son de gobernanza —responsabilidad, tratamiento de datos, supervisión de terceros y respuesta a incidentes—, no únicamente técnicos.

Si el entorno SaaS crece más deprisa que la capacidad de supervisión, el primer paso es realizar un ejercicio de descubrimiento. No se puede gobernar lo que se desconoce.

Conclusión y siguientes pasos

El riesgo de terceros ya no es una tarea administrativa de cumplimiento. Es un componente esencial de la resiliencia operativa y, bajo NIS2 y DORA, una obligación jurídica directa para un amplio conjunto de organizaciones europeas.

Al integrar la seguridad en compras antes de la firma de los contratos, aplicar controles estrictos de incorporación, mantener un registro que revele riesgos de concentración y de salida, y conservar la supervisión del entorno de nube y SaaS, la cadena de suministro deja de ser una vulnerabilidad para convertirse en un ecosistema gestionado y resiliente.

Siguiente paso: descargue gratuitamente la Lista de verificación para auditar contratos de proveedores conforme a NIS2 y DORA. No existe barrera de registro por correo electrónico: la descarga es directa y está diseñada para utilizarse.

Para revisar primero su modelo actual de riesgo de terceros, contacte con GRCForce para una breve conversación de diagnóstico.