Basta de caos en la gestión de riesgo de terceros con ServiceNow
September 11, 2026
En mayo de 2026, la Superintendencia de Bancos de Panamá emitió la Circular SBP-DR-2026-0038, instruyendo a los bancos del país a adoptar los "Principios para la gestión sólida del riesgo de terceros" que el Comité de Supervisión Bancaria de Basilea había publicado apenas cinco meses antes, en diciembre de 2025. Casi al mismo tiempo, en abril de 2026, la Comisión para el Mercado Financiero de Chile puso en consulta una actualización de su normativa bancaria sobre externalización de servicios, con un cambio de enfoque explícito: pasar de vigilar funciones tercerizadas de forma puntual a exigir un modelo integral de gestión del riesgo de terceros, con reporte periódico y estandarizado de proveedores, servicios e incidentes.
Dos reguladores, dos países, el mismo mensaje: la gestión de riesgo de terceros dejó de ser un ejercicio anual de cumplimiento y se convirtió en una función continua que la alta dirección debe poder demostrar en cualquier momento, con evidencia concreta y no solo con una política escrita. El problema es que buena parte de los equipos de riesgo en la región todavía gestionan esa función con una hoja de cálculo, un correo electrónico y un cuestionario que se actualiza una vez al año, sin importar lo que haya cambiado con el proveedor en el tiempo transcurrido.
Este artículo revisa por qué el modelo tradicional de gestión de proveedores ya no alcanza, qué están exigiendo en concreto los reguladores de la región y cómo un enfoque basado en flujos de trabajo dentro de la suite de Gestión de Riesgo Integrado de ServiceNow cierra esa brecha, sin pedirle a un equipo de riesgo que duplique su personal para lograrlo.
Ningún equipo de riesgo eligió tener un punto ciego en la gestión de proveedores. Ese punto ciego creció contrato por contrato: una herramienta que un equipo de marketing contrató sin pasar por una revisión de seguridad, una integración en la nube que el equipo de desarrollo conectó para acelerar un lanzamiento, un proveedor de servicios gestionados que se incorporó para cubrir una vacante durante un congelamiento de contrataciones. Ninguna de esas decisiones parecía riesgosa por separado. Juntas, construyeron un entorno donde decenas o cientos de terceros tienen hoy algún nivel de acceso a sistemas, datos o procesos que llegan directamente al cliente, sin que ningún equipo tenga la lista completa de quiénes son todos ellos.
La exposición se agrava más adelante en la cadena. Un proveedor que pasó una revisión de seguridad rigurosa puede depender, a su vez, de subcontratistas, proveedores de nube o librerías de software que nadie del lado comprador evaluó jamás. Esa exposición heredada, conocida como riesgo de cuarto nivel, casi nunca aparece en un cuestionario de ingreso estándar, porque ese cuestionario solo pregunta sobre el proveedor que lo responde, no sobre todos los que dependen de él.
Cuatro brechas se repiten una y otra vez en los programas de riesgo de terceros que no se han modernizado:
El costo de una relación con proveedores mal gestionada casi nunca aparece como un evento dramático aislado. Aparece como una acumulación lenta de exposición que eventualmente se manifiesta de una forma difícil de rastrear hasta su origen. La participación de terceros ya está implicada en una porción significativa de las brechas de datos confirmadas a nivel global, y la investigación sobre el panorama de amenazas de 2026 señala el uso excesivo de datos en aplicaciones SaaS, el acceso sobreprivilegiado a APIs y el abuso en la cadena de suministro de software a través de dependencias de código abierto como categorías que impulsan esa tendencia, además del riesgo ya conocido de que un proveedor de servicios gestionados o un socio en la nube sea comprometido directamente.
El impacto de negocio no se limita al incidente en sí. Una falla de un proveedor puede activar obligaciones de notificación a clientes, penalidades contractuales, escrutinio regulatorio, ciclos de venta que se alargan mientras los clientes propios hacen sus propias revisiones de seguridad y, cada vez más, preguntas directas de la junta directiva sobre por qué esa exposición no se detectó antes. Nada de esto es hipotético para las instituciones financieras en particular: dos tercios reportan sentir presión para fortalecer sus programas de riesgo de terceros, y señalan a auditores y reguladores, no solo al apetito de riesgo interno, como el principal motor de esa presión, una presión que ya resulta familiar para los bancos que cargan con el costo de mantener sistemas legados.
Imagina el patrón que suele repetirse: un procesador de pagos renueva su contrato sin problemas, su cuestionario anual vuelve limpio, y seis meses después divulga una brecha que expuso datos de una parte de sus propios clientes, incluidos algunos registros de tu organización. El proveedor no hizo nada distinto entre la revisión y la brecha; la revisión simplemente no podía ver seis meses hacia adelante. Un programa construido sobre monitoreo continuo, en lugar de una sola fotografía anual, está diseñado precisamente para detectar ese tipo de deterioro, no solo las respuestas iniciales de un formulario.
Las expectativas regulatorias sobre gestión de riesgo de terceros convergieron con fuerza en los últimos años, y lo hicieron alrededor del mismo principio: la supervisión tiene que ser continua, evidenciable y proporcional al riesgo real de cada proveedor, no una política que se desempolva una vez al año. Los Principios para la gestión sólida del riesgo de terceros del Comité de Basilea, publicados en diciembre de 2025, cubren gobernanza, evaluación de riesgos, debida diligencia, contratación, monitoreo continuo, terminación de contratos y riesgo de concentración. La adopción casi inmediata de esos principios por parte de la Superintendencia de Bancos de Panamá, apenas cinco meses después de su publicación, confirma qué tan rápido se está trasladando ese estándar a la supervisión bancaria de la región.
Chile avanza en la misma dirección desde otro ángulo: la propuesta de abril de 2026 de la CMF sobre el Capítulo 20-7 de su normativa bancaria crea un nuevo archivo de reporte estandarizado, "I28, Servicios Externalizados", pensado específicamente para que los bancos reporten de forma periódica sus proveedores, los servicios que prestan y los incidentes asociados. Ese es exactamente el tipo de evidencia que una hoja de cálculo compartida no puede producir a demanda, mucho menos en un portafolio de proveedores lo bastante grande como para que nadie recuerde de memoria los detalles de cada uno.
El riesgo de concentración agrega otra capa a la exigencia: cuando muchas instituciones del mismo mercado dependen de los mismos proveedores de nube o de tecnología, la falla de un solo proveedor puede propagarse a todo un sector. Por eso los reguladores ahora esperan que las entidades mapeen qué proveedores comparten dependencias adicionales entre sí, y no que simplemente los sigan uno por uno como si fueran independientes, el mismo tipo de exigencia de evidencia que ya se refleja en cómo las agencias gubernamentales de la región están modernizando sus propios procesos de supervisión.
Una parte creciente de la lista de proveedores que un equipo de riesgo debería estar rastreando no existía como categoría hace cinco años. Cada herramienta SaaS que agregó una función de IA generativa, cada proveedor de IA independiente que un área de negocio contrató directamente y cada equipo interno que experimenta con un modelo de terceros crearon un tipo nuevo de dependencia: una donde el proveedor no solo procesa datos, sino que toma decisiones o genera contenido que un proceso de negocio puede usar sin que una persona revise cada resultado.
Los cuestionarios de proveedores tradicionales preguntan sobre manejo de datos, cifrado e historial de brechas, y esas preguntas siguen siendo válidas. Casi nunca preguntan con qué se entrenó el modelo de IA de un proveedor, si ese modelo retiene las entradas para seguir entrenándose, o qué pasa cuando su salida alimenta directamente una decisión que afecta a un cliente. Un programa de riesgo de terceros que no actualizó sus preguntas de ingreso para cubrir esos puntos tiene un punto ciego dentro de su propio punto ciego, y ese punto ciego crece cada vez que un área de negocio adopta una nueva herramienta con IA sin pasar antes por compras o seguridad.
Esto no requiere un programa de riesgo de IA separado, montado encima del que ya existe. Requiere agregar criterios específicos de IA al mismo proceso de clasificación y evaluación descrito antes: si el proveedor usa datos de clientes para entrenar sus modelos, si existe supervisión humana para decisiones con consecuencias reales y si el contrato especifica qué pasa con los datos si el proveedor cambia de motor de IA. Incorporar esas preguntas al flujo de trabajo de riesgo de terceros que ya existe, en lugar de tratar a los proveedores de IA como una categoría aparte para gestionar más adelante, evita que el programa se fragmente justo cuando más necesita mantenerse unificado.
Cerrar la brecha entre lo que exige el regulador y lo que ocurre día a día no requiere reinventar la gestión de riesgos. Requiere que sucedan seis cosas de forma consistente, para cada proveedor, sin depender de que alguien se acuerde de hacerlas:
Parte de la razón por la que la gestión de riesgo de terceros se estanca entre hojas de cálculo es que ningún equipo la tiene realmente bajo su responsabilidad. Compras es dueño del contrato y quiere que el proveedor quede firmado rápido. Seguridad es dueño de la evaluación de riesgo y necesita tiempo para hacerla bien. Legal es dueño del lenguaje de responsabilidad y revisa según su propio calendario. El área de negocio que pidió al proveedor en primer lugar es dueña de la relación día a día y suele tener la menor visibilidad de lo que encontraron los otros tres equipos. Cuando algo sale mal, los cuatro pueden decir, con razón, que la falla no fue solo suya, y cada uno tendría parte de razón.
Un sistema basado en flujos de trabajo no resuelve por sí solo ese problema de propiedad, pero obliga a responder la pregunta que las hojas de cálculo permiten evitar: quién es el dueño responsable del nivel de riesgo de este proveedor específico, hoy mismo. Asignar esa responsabilidad en el momento en que se clasifica al proveedor, en lugar de dejarla implícita, es lo que convierte un "todos somos un poco responsables" en "esta persona es responsable, y esto es lo que debe rendir cuentas". La mayoría de los programas que fallan no carecen de proceso; carecen de un nombre concreto asignado al registro de riesgo de cada proveedor.
Un punto de partida práctico es un RACI simple: seguridad suele ser responsable de la metodología de evaluación y del puntaje de riesgo, el área de negocio es responsable del desempeño diario del proveedor y de escalar problemas operativos, compras y legal siguen siendo responsables de los términos contractuales y comerciales, y un dueño de riesgo designado, no un comité, firma si el riesgo residual de un proveedor es aceptable o no. Nada de esto requiere contratar personal nuevo. Requiere que el flujo de trabajo haga visible esa asignación y la vuelva imposible de saltarse.
La aplicación de Gestión de Riesgo de Terceros de ServiceNow vive dentro de su suite más amplia de Gestión de Riesgo Integrado (IRM), sobre la misma Now Platform que ya soporta ITSM, la CMDB y buena parte de los flujos operativos que muchas organizaciones ya tienen en marcha. Esa ubicación importa más de lo que parece a primera vista: los datos de riesgo de proveedores dejan de vivir en un silo aparte y pasan a estar junto a la misma información de configuración que ya describe qué servicios de negocio, aplicaciones y bases de datos existen en la organización.
Como los registros de proveedores viven junto a la CMDB, un equipo de riesgo puede ver exactamente qué servicios de negocio y elementos de configuración dependen de un proveedor determinado, así que un hallazgo queda automáticamente vinculado a lo que realmente pone en riesgo, en lugar de ser solo un nombre en una hoja de cálculo con una columna de estado al lado. Las evaluaciones digitales y estructuradas reemplazan el formulario enviado por correo, y las respuestas alimentan directamente el perfil de riesgo, la clasificación y el puntaje del proveedor, sin que nadie tenga que volver a digitar datos de un documento a un rastreador.
Las integraciones de monitoreo continuo incorporan señales externas (calificaciones de seguridad, estado de certificaciones, brechas divulgadas) para que el perfil de riesgo de un proveedor pueda cambiar entre ciclos formales de revisión, no solo durante ellos. Esa es la diferencia entre enterarte de que una certificación venció la semana en que ocurrió y enterarte durante la auditoría del año siguiente, después de meses de exposición sin gestionar.
Now Assist para Gestión de Riesgo de Terceros, la capa de IA generativa de ServiceNow para este módulo, lee las respuestas de las evaluaciones completadas y recomienda hallazgos con un resumen ya justificado, para que un revisor lo confirme antes de que se convierta en un hallazgo registrado formalmente. Eso convierte el paso de "leer el cuestionario y decidir si importa" de una tarde entera de trabajo manual en un paso de revisar y aprobar, sin eliminar el criterio humano que una decisión de riesgo genuina sigue requiriendo.
Cada hallazgo confirmado lleva un dueño, un objetivo de nivel de servicio y un flujo de remediación que corre sobre el mismo motor de flujos de trabajo que ya impulsa la gestión de incidentes y cambios en muchos clientes de ServiceNow, así que la escalación no depende de que alguien recuerde dar seguimiento dos semanas después. Los reportes se consolidan en tableros de IRM construidos alrededor del riesgo inherente, el riesgo residual después de la remediación y las revisiones atrasadas, exactamente el tipo de vista que un auditor o un comité de riesgo de la junta directiva pide ver, y no una exportación cruda de cada fila de una hoja de cálculo.
Esa misma ubicación en la plataforma también cierra una brecha que está aguas arriba de la gestión de riesgo: el ingreso de compras y contratos. Cuando una solicitud de nuevo proveedor pasa por la misma Now Platform que aloja el módulo de riesgo de proveedores, esa solicitud puede disparar automáticamente una clasificación de riesgo y una ruta de evaluación antes de firmar el contrato, en lugar de que seguridad descubra al proveedor después de que ya tiene acceso a producción. Ese único cambio, mover la revisión de riesgo antes en el proceso en lugar de agregarla como un paso posterior, suele ser lo que separa a un programa que detecta problemas antes del ingreso de uno que solo los detecta en la siguiente revisión anual.
Un programa de riesgo de terceros puede verse ocupado sin reducir realmente la exposición, así que vale la pena rastrear un pequeño conjunto de métricas que muestren si el cambio de las hojas de cálculo a un sistema basado en flujos de trabajo está dando resultado. El tiempo para completar una evaluación de proveedor es una: si la revisión de un proveedor crítico sigue tomando seis semanas porque los revisores persiguen respuestas por correo, la herramienta no cambió el cuello de botella real. El porcentaje de proveedores atrasados en su reevaluación es otra, y debería acercarse a cero específicamente en el nivel de mayor riesgo, porque ahí un atraso representa la mayor exposición.
El tiempo promedio para remediar un hallazgo confirmado importa tanto como la rapidez con la que se detectó, porque un hallazgo que queda abierto durante meses protege muy poco más que uno que nunca se señaló. Por último, la proporción de proveedores con una clasificación de riesgo documentada y vigente frente al total de proveedores es una medida simple pero honesta de cobertura: un programa con flujos de trabajo perfectamente automatizados para cuarenta proveedores, mientras otros doscientos siguen sin rastrear, no cerró realmente la brecha, solo hizo más rápida una parte de ella.
Los equipos que obtienen más valor de este cambio no intentan incorporar a todos sus proveedores al nuevo proceso desde el primer día. Un enfoque por fases protege tanto la implementación como la credibilidad del programa frente al resto de la organización:
El riesgo de terceros no se va a simplificar por sí solo. La huella de proveedores sigue creciendo, el ciclo anual de cuestionarios se sigue quedando atrás, y los reguladores en toda la región, desde Panamá hasta Chile, siguen pidiendo evidencia que una hoja de cálculo no puede producir a demanda. Lo que realmente cambia el resultado es tratar el riesgo de terceros de la misma forma en que ServiceNow ya trata cualquier otro flujo operativo: clasificado por riesgo, monitoreado de forma continua y enrutado a un dueño con una fecha límite, sobre la misma plataforma que ya corre el resto de la operación.
Si tu equipo todavía rastrea proveedores entre tres hojas de cálculo y una bandeja de entrada, vale la pena revisarlo antes del próximo ciclo de auditoría regulatoria, no después.
Conversa con GB Advisors sobre Gestión de Riesgo de Terceros con ServiceNow
