TPRM Gestión del Riesgo de Terceros.

La Gestión del Riesgo de Terceros (TPRM) trata a sus proveedores, subcontratistas y prestadores de servicios como una extensión de su propia superficie de ataque. La lógica es simple: si un proveedor procesa sus datos, opera su infraestructura o forma parte de su cadena de suministro, entonces sus debilidades se convierten en sus incidentes. El TPRM es la disciplina que hace que esa exposición sea visible, contractual y supervisada de forma continua, en lugar de descubierta en el momento de la brecha.

Las cuatro fases que los profesionales ejecutan realmente

El TPRM no es un cuestionario puntual. Es un ciclo de vida que abarca desde el primer contacto con un proveedor hasta el día en que se le desconecta. La mayoría de los programas maduros lo estructuran en cuatro fases:

• Diligencia debida de incorporación. Antes de firmar, se evalúa al proveedor en función del riesgo que introduce. Un proveedor SaaS que aloja datos personales y un proveedor de material de oficina no reciben el mismo escrutinio. La clasificación por criticidad es lo que evita que el programa se desborde.
• Cláusulas contractuales. El contrato es donde la garantía se vuelve exigible: obligaciones de seguridad, derechos de auditoría, plazos de notificación de brechas, divulgación de subprocesadores, ubicación de los datos y condiciones de salida. Si no está en el contrato, no podrá exigirlo después.
• Garantía continua. El riesgo no se congela en la firma. La cadencia de reevaluación, el seguimiento de certificados (ISO 27001, SOC 2), la supervisión continua de la postura de seguridad del proveedor y la revisión de las dependencias de cuarta parte mantienen el panorama actualizado.
• Desvinculación. Cuando la relación termina, se recupera o se confirma la destrucción de los datos, se revocan los accesos y se cierra la exposición residual. Es la fase que los equipos omiten con más frecuencia, y la que deja credenciales huérfanas atrás.

Por qué se convirtió en una conversación a nivel de consejo de administración

El TPRM solía residir en compras. Pasó al consejo de administración porque los fallos más sonados de la última década llegaron a través de la cadena de suministro, no por la puerta principal. El incidente de SolarWinds mostró a un atacante alcanzando a miles de organizaciones al comprometer una única actualización de software de confianza. La caída de CrowdStrike demostró que una actualización defectuosa de un único proveedor crítico podía detener las operaciones de sectores enteros a la vez. Ambos replantearon a los terceros como un riesgo sistémico, no como una casilla de verificación de compras.

La regulación lo siguió. NIS 2 convierte la seguridad de la cadena de suministro en un deber explícito para las entidades incluidas en su ámbito y responsabiliza a los órganos de dirección de los fallos. DORA va más allá para las entidades financieras, dedicando uno de sus cinco pilares al riesgo de terceros proveedores de TIC, imponiendo requisitos contractuales específicos y sometiendo a los propios proveedores críticos de TIC a supervisión. Para una empresa regulada, el TPRM ya no es una buena práctica, es una obligación documentada.

En qué se diferencia el TPRM de las disciplinas vecinas

El TPRM convive con la gestión de proveedores y la gestión de riesgos en general, pero es más estrecho y más preciso que cualquiera de ellas. La gestión de proveedores optimiza el coste, el rendimiento y la relación comercial. El TPRM se ocupa específicamente del riesgo de seguridad, resiliencia, privacidad y cumplimiento que introduce una tercera parte. También se diferencia del trabajo interno del SGSI: sus controles se detienen en su perímetro, pero su responsabilidad no. Puede externalizar la actividad, no puede externalizar el riesgo. Esa asimetría es la razón misma por la que existe la disciplina.