Casi todas las empresas gestionan ya a sus proveedores de alguna forma: un proceso de compras, una plantilla de contrato, quizá un cuestionario de seguridad que se envía una vez al dar de alta al proveedor. La gestión de riesgos de terceros (TPRM, por sus siglas en inglés, third party risk management) es lo que convierte eso en una disciplina continua: saber de qué proveedores dependes, cuánto importa cada dependencia, qué hace cada uno con tus datos y tus sistemas, y qué pasa si alguno falla.
Dos normas europeas convierten ahora esa disciplina en una obligación legal para buena parte del mercado. DORA, el Reglamento de Resiliencia Operativa Digital, se aplica a las entidades financieras y es muy detallado sobre cómo deben gestionar a sus proveedores TIC. NIS2 se aplica a las entidades esenciales e importantes de muchos sectores y trata la seguridad de la cadena de suministro como una de las medidas de gestión de riesgos que toda entidad cubierta debe adoptar. Piden cosas distintas, y una empresa sujeta a una, a otra o a las dos necesita entender dónde se cruzan.
Qué es la gestión de riesgos de terceros (TPRM)
La gestión de riesgos de terceros es el proceso de identificar, evaluar, vigilar y reducir los riesgos que vienen de organizaciones ajenas a la tuya: proveedores de software y de nube, proveedores de servicios gestionados, desarrollo externalizado, procesadores de pagos, consultores con acceso a tus sistemas. El riesgo puede ser una brecha en el proveedor que expone tus datos, una caída que detiene tu servicio, un contrato que no te da derecho a auditar ni a salir, o una dependencia tan concentrada que no existe alternativa.
Un proceso de TPRM que funciona tiene una forma reconocible. Hay un inventario de proveedores, cada uno clasificado según su criticidad. Los proveedores críticos se evalúan antes de contratar y se revisan después de forma periódica. Los contratos incluyen las cláusulas de seguridad, auditoría y salida que exige el riesgo. Los cambios en el proveedor, desde un nuevo subencargado hasta un incidente de seguridad, provocan una nueva evaluación. Y existe un plan para el día en que un proveedor clave desaparezca. Un cuestionario archivado el día del alta solo cubre el primero de esos pasos.
Qué exige DORA
DORA, el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025. Su cuarto pilar, la gestión del riesgo de terceros proveedores de servicios TIC, ocupa los artículos 28 a 44, y los que obligan a toda entidad financiera son el 28, el 29 y el 30. Del artículo 31 en adelante se regula el marco de supervisión europeo de los proveedores terceros críticos de servicios TIC, que afecta a los proveedores designados por las Autoridades Europeas de Supervisión y no a las entidades financieras en sí.
Artículo 28: principios y registro de información
El artículo 28 convierte el riesgo de terceros TIC en parte integrante del marco de gestión del riesgo TIC de la entidad. La entidad debe adoptar una estrategia sobre ese riesgo, con una política sobre el uso de servicios TIC que soportan funciones esenciales o importantes, revisada periódicamente por el órgano de dirección. Antes de firmar un acuerdo debe valorar si el servicio soporta una función esencial o importante, hacer la diligencia debida sobre el proveedor, identificar conflictos de interés y comprobar que el proveedor aplica normas adecuadas de seguridad de la información. También debe tener estrategias de salida para los servicios TIC que soportan funciones esenciales o importantes, y derechos contractuales de resolución en supuestos definidos.
La obligación más concreta es el registro de información. El artículo 28.3 exige mantener y actualizar un registro de todos los acuerdos contractuales sobre servicios TIC con terceros proveedores, distinguiendo los que soportan funciones esenciales o importantes. El registro completo debe ponerse a disposición de la autoridad competente cuando lo solicite, y la entidad informa al menos una vez al año de los nuevos acuerdos. El formato no queda a criterio de cada entidad: el Reglamento de Ejecución (UE) 2024/2956 fija plantillas normalizadas, con tablas enlazadas para la entidad, los proveedores, los acuerdos contractuales, las funciones que soportan y la cadena de suministro del servicio TIC.
Artículo 29: riesgo de concentración
El artículo 29 pide a la entidad que valore el riesgo de concentración TIC antes de contratar un servicio que soporte una función esencial o importante. Las preguntas son si el proveedor es fácilmente sustituible y si la entidad acabaría con varios acuerdos con el mismo proveedor o con proveedores estrechamente vinculados. Cuando hay subcontratación, la entidad sopesa los beneficios y los riesgos de la cadena, incluido en qué países operan los subcontratistas y si su legislación permite una supervisión eficaz.
En la práctica, aquí es donde muchos registros fallan en la primera lectura del supervisor. Una entidad puede tener decenas de contratos que parecen independientes y que resultan depender de la misma región de nube o del mismo proveedor de fondo. La concentración solo se ve cuando el inventario recoge no solo al proveedor directo, sino también los servicios y los proveedores que hay debajo.
Artículo 30: qué debe decir el contrato
El artículo 30 enumera las disposiciones contractuales clave. Todo contrato de servicios TIC debe describir las funciones y servicios prestados, los lugares donde se prestan los servicios y se tratan los datos, las disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad de los datos, el derecho a acceder a los datos y recuperarlos si el proveedor quiebra o el contrato termina, la descripción de los niveles de servicio, la obligación del proveedor de prestar asistencia ante un incidente TIC, la cooperación con las autoridades competentes, los derechos de resolución con plazos mínimos de preaviso y la participación del proveedor en los programas de concienciación de la entidad cuando proceda.
Los contratos de servicios que soportan funciones esenciales o importantes van más allá: descripción completa de los niveles de servicio con objetivos de rendimiento cuantitativos y cualitativos precisos, obligaciones de preaviso y de información, planes de contingencia que el proveedor implanta y prueba, participación en las pruebas de penetración basadas en amenazas cuando se apliquen, derechos ilimitados de acceso, inspección y auditoría para la entidad y su supervisor, y estrategias de salida con un periodo de transición obligatorio. Para un proveedor SaaS que vende a bancos o aseguradoras, este artículo suele ser el primer lugar donde aparece DORA: en un contrato lleno de cambios.
Qué exige NIS2
NIS2, la Directiva (UE) 2022/2555, aborda a los proveedores desde la gestión de riesgos y no desde un registro. El artículo 21.2 enumera las medidas mínimas de gestión de riesgos de ciberseguridad que debe adoptar toda entidad esencial o importante, y la letra d) es la seguridad de la cadena de suministro, incluidos los aspectos de seguridad de las relaciones entre la entidad y sus proveedores directos o prestadores de servicios.
El artículo 21.3 añade el detalle. Al decidir qué medidas de cadena de suministro son adecuadas, las entidades deben tener en cuenta las vulnerabilidades específicas de cada proveedor directo y prestador de servicios, la calidad general de sus productos y de sus prácticas de ciberseguridad, incluidos sus procedimientos de desarrollo seguro, y los resultados de las evaluaciones coordinadas de riesgos de las cadenas de suministro críticas realizadas a escala europea según el artículo 22. Esas evaluaciones las lleva a cabo el Grupo de Cooperación NIS junto con la Comisión y ENISA, y significan que un riesgo detectado para toda una categoría de proveedores puede pasar a ser algo que cada entidad debe ponderar.
Para algunas categorías de proveedores digitales, entre ellas los proveedores de nube, de centros de datos y de servicios gestionados, el Reglamento de Ejecución (UE) 2024/2690 concreta más estas exigencias, entre ellas una política de seguridad de la cadena de suministro y una lista actualizada de proveedores directos y prestadores de servicios. En España, la ley que transpone NIS2, el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, no se había publicado en el BOE a mediados de 2026, así que la directiva es la referencia de lo que contendrán las obligaciones. La cuestión del alcance, qué empresas quedan cubiertas, se explica en NIS2 en España: qué empresas están obligadas.
DORA y NIS2, frente a frente
Leídas juntas, las dos normas persiguen el mismo resultado por caminos distintos. DORA dice a las entidades financieras exactamente qué deben registrar y qué deben incluir en los contratos. NIS2 pide a las entidades cubiertas que gestionen el riesgo de la cadena de suministro de forma proporcionada y les deja más libertad en el método.
- A quién obliga: DORA obliga a las entidades financieras y alcanza a los proveedores TIC a través de los contratos y, en el caso de los más sistémicos, mediante supervisión directa de la UE. NIS2 obliga a las entidades esenciales e importantes de los sectores de sus anexos y alcanza a sus proveedores a través de requisitos contractuales.
- Inventario de proveedores: DORA exige un registro de información con formato fijo que cubre todos los acuerdos TIC. La directiva NIS2 no fija un formato de registro, aunque hace falta un inventario para aplicar el artículo 21.3, y el Reglamento de Ejecución 2024/2690 lo espera de ciertos proveedores digitales.
- Evaluación antes de contratar: DORA exige diligencia debida y una valoración del riesgo de concentración para los servicios que soportan funciones esenciales o importantes. NIS2 exige tener en cuenta las vulnerabilidades y prácticas propias de cada proveedor.
- Contenido del contrato: DORA enumera cláusulas obligatorias en el artículo 30. NIS2 espera requisitos de seguridad en las relaciones con proveedores, pero no enumera cláusulas.
- Salida: DORA exige estrategias de salida y periodos de transición para las funciones esenciales o importantes. NIS2 cubre la continuidad dentro de las medidas generales del artículo 21.
- Incidentes en un proveedor: ambas esperan que la entidad los tenga en cuenta; DORA a través del deber contractual de asistencia del proveedor, NIS2 a través de la gestión de incidentes y de las obligaciones de notificación del artículo 23. Los plazos de esas notificaciones se explican en plazos de notificación de incidentes NIS2 y DORA.
Una empresa que es a la vez entidad financiera y entidad NIS2, o que es proveedora de clientes sujetos a cada una, acaba respondiendo a los dos juegos de preguntas. Construir el inventario una sola vez, con los campos que satisfacen la más exigente de las dos, evita llevar dos programas de proveedores que describen los mismos contratos de forma distinta.
Dónde la ISO 27001 ya cubre el terreno
Las empresas certificadas en ISO 27001 no parten de cero. El Anexo A de la ISO 27001:2022 tiene cinco controles sobre proveedores: el 5.19, seguridad de la información en las relaciones con proveedores; el 5.20, tratamiento de la seguridad de la información en los acuerdos con proveedores; el 5.21, gestión de la seguridad de la información en la cadena de suministro TIC; el 5.22, seguimiento, revisión y gestión de cambios de los servicios de proveedores; y el 5.23, seguridad de la información en el uso de servicios en la nube. Juntos cubren una política de proveedores, cláusulas de seguridad en los contratos, el riesgo de la cadena de suministro, la revisión continua y el caso concreto de la nube.
Lo que la ISO 27001 no aporta es la concreción regulatoria. No prescribe el formato del registro de DORA, su valoración del riesgo de concentración, su lista de cláusulas contractuales ni sus exigencias de estrategia de salida, y no hace referencia a las evaluaciones coordinadas de la cadena de suministro de NIS2. Lo sensato es usar los controles de la ISO como columna vertebral y añadir encima los campos y pasos propios de DORA y NIS2, en lugar de montar un proceso separado para cada norma.
Un único inventario de proveedores que sirva para las dos
El inventario es la pieza de la que depende todo lo demás. La diligencia debida, la revisión de contratos, el análisis de concentración y la evaluación periódica empiezan por saber qué proveedores existen, qué prestan y cuánto importa cada uno.
Clasificar a los proveedores por criticidad
No todos los proveedores merecen el mismo escrutinio, e intentar aplicar una diligencia debida completa al proveedor de material de oficina es la forma más rápida de que un programa de TPRM se atasque. Una clasificación útil parte de la función que soporta el proveedor. En DORA, la pregunta decisiva es si el servicio TIC soporta una función esencial o importante, es decir, una cuya interrupción perjudicaría de forma importante los resultados financieros de la entidad, la continuidad de sus servicios o su cumplimiento normativo. En NIS2 y en la ISO 27001, el equivalente es una valoración del riesgo basada en el acceso a datos, el acceso a sistemas y el impacto de una caída.
Suelen bastar tres niveles: proveedores críticos, que soportan funciones esenciales o tratan datos sensibles; proveedores importantes, con un acceso relevante pero con alternativas disponibles; y proveedores de bajo riesgo, sin acceso a sistemas ni a datos. El nivel determina después todo lo demás: la profundidad de la evaluación inicial, las cláusulas contractuales necesarias, la frecuencia de revisión y si hace falta un plan de salida.
Frecuencia de revisión y evidencias
Una evaluación de proveedor es una foto. El proveedor cambia de subencargados, traslada datos a otra región, sufre un incidente o deja caducar una certificación, y la evaluación original ya no describe la relación. Las dos normas esperan que la revisión continúe mientras dure el contrato, y DORA espera que los derechos de auditoría e inspección se ejerzan con una frecuencia basada en el riesgo.
Un ciclo de revisión defendible fija una frecuencia por nivel, por ejemplo anual para los proveedores críticos y cada dos o tres años para los importantes, más revisiones provocadas por cambios. Cada revisión debe dejar evidencia: la evaluación actualizada, los certificados o informes comprobados con sus fechas de caducidad, los hallazgos abiertos y quién se encarga de cada uno. Cuando un supervisor o un auditor pregunta por un proveedor, la respuesta es un registro fechado, no un recuerdo.
Encontrar los proveedores que nadie registró
La carencia más habitual en un inventario de proveedores no es un proveedor mal evaluado. Es el proveedor que nadie conoce: la herramienta SaaS que un equipo contrató con una tarjeta de empresa, el asistente de IA conectado a una unidad compartida, el servicio de analítica que un desarrollador añadió al producto. Ninguno pasó por compras, así que ninguno está en el registro, y algunos tratan datos de la empresa.
El descubrimiento tiene que salir de los sistemas en los que la gente inicia sesión de verdad. Los registros del inicio de sesión único y las integraciones con el proveedor de identidad muestran a qué aplicaciones se autentican los empleados, y los datos de gastos y tarjetas muestran cuáles se están pagando. Cruzar esas fuentes con el registro de forma periódica es la única manera fiable de mantener el inventario completo, y un registro incompleto es, por sí solo, un hallazgo en DORA.
Lista de comprobación de TPRM
Para una empresa que debe cumplir DORA, NIS2 o ambas, el núcleo de un programa de proveedores puede comprobarse con esta lista:
- Una estrategia de riesgo de terceros TIC y una política de proveedores por escrito, aprobadas por la dirección y revisadas de forma periódica.
- Un inventario completo de proveedores, incluidos los descubiertos a través del inicio de sesión y de los gastos, con un responsable para cada relación.
- Una clasificación por criticidad de cada proveedor y, en las entidades financieras, una marca explícita para los servicios que soportan funciones esenciales o importantes.
- Diligencia debida antes de contratar, proporcional al nivel, y una comprobación del riesgo de concentración para los servicios críticos.
- Cláusulas contractuales revisadas frente al artículo 30 de DORA cuando aplique, y frente al control 5.20 de la ISO 27001 en todos los casos.
- Un ciclo de revisión por nivel, más una nueva evaluación cuando un proveedor cambia o comunica un incidente.
- Estrategias de salida y alternativas probadas para los proveedores sin los que no podrías operar.
- En las entidades financieras, un registro de información mantenido en el formato del Reglamento de Ejecución 2024/2956 y listo para enviar.
La mayoría de las empresas comprueban que pueden marcar el primer y el quinto punto, y muy pocos de los demás. La carencia rara vez es una política que falta; es el trabajo operativo de mantener vivos un inventario y un ciclo de revisión mes tras mes. Todo esto forma parte del programa más amplio de DORA, y el pilar de terceros se describe junto a los otros cuatro en los cinco pilares de DORA.
Cómo ayuda el panel de proveedores de Qalea
La plataforma de Qalea incluye un panel de proveedores que contiene el inventario: cada proveedor con su nivel de riesgo, si pertenece a una categoría crítica, su ciclo de revisión y la evidencia de cada revisión. Los proveedores pueden descubrirse a través del inicio de sesión único de la empresa, de modo que las herramientas SaaS que nunca pasaron por compras aparecen en el inventario en lugar de quedar ocultas. El equipo de Qalea acompaña de forma guiada la realización de las revisiones, y lo que la empresa ya tiene, en otra plataforma o en hojas de cálculo, se migra en lugar de rehacerse.
El panel es el inventario y el registro de revisiones que alimenta el registro de información de DORA; no se presenta como el registro regulatorio en sí. Las entidades financieras siguen elaborando el registro en las plantillas del Reglamento de Ejecución 2024/2956, y el inventario es lo que hace fiable ese trabajo, porque el registro solo es tan completo como la lista de proveedores que hay detrás. El mismo inventario sirve para los controles de proveedores de la ISO 27001, SOC 2, la ISO 9001 y el ENS, así que un único programa de proveedores cubre todos los marcos que gestiona la empresa.
