Evaluar proveedores: lo declarado frente a lo observado

Casi todos los programas de riesgo de terceros se construyen sobre una única fuente: lo que el proveedor contesta en un cuestionario. Es una fuente legítima y necesaria, pero tiene una propiedad que conviene no olvidar: mide la percepción que el proveedor tiene de sí mismo, filtrada por quien rellenó el formulario y por el momento en que lo hizo.

La otra mitad de la evaluación es lo observable: aquello que puedes comprobar por tu cuenta, sin depender de su colaboración, y que además no caduca cada doce meses. Un programa que sólo tiene la primera mitad no está evaluando riesgo, está archivando declaraciones.

Qué sirve de lo declarado, y cómo hacerlo servir más

El cuestionario no es inútil. Es la única forma de conocer decisiones internas que no dejan huella externa: cómo gestionan los accesos privilegiados, si tienen plan de continuidad probado, qué subcontratan. El problema no es el instrumento, es cómo se usa.

Tres cambios lo mejoran bastante:

Pregunta por la evidencia, no por el estado. «¿Tienen gestión de vulnerabilidades?» se contesta que sí siempre. «Indiquen la fecha del último informe de análisis de vulnerabilidades y el porcentaje de activos cubiertos» obliga a mirar un dato real, y una respuesta evasiva es en sí misma informativa.

Pide el alcance de las certificaciones, no la certificación. Un ISO 27001 es un documento de dos páginas con un anexo de alcance. El anexo es lo que importa. Es frecuente que el certificado cubra la sede corporativa y no la plataforma que te va a prestar el servicio.

Fija la fecha de corte de cada respuesta. Un cuestionario sin fecha de referencia mezcla datos de tres años distintos. La pregunta debería ser siempre «a fecha de hoy» o «en los últimos doce meses», y la respuesta debería decir cuál.

Qué se puede observar sin pedir permiso

Hay un conjunto de señales que cualquiera puede recoger desde fuera y que tienen dos virtudes: no dependen del proveedor y se pueden actualizar de forma continua.

• Superficie expuesta. Qué dominios y subdominios publica, qué servicios responden, qué tecnologías se identifican en las respuestas. Un panel de administración accesible desde internet dice más sobre la madurez operativa que veinte respuestas de cuestionario.
• Higiene de TLS y de correo. Certificados caducados o mal configurados, ausencia de SPF, DKIM o DMARC, cabeceras de seguridad ausentes. Son señales débiles individualmente, pero muy consistentes en conjunto: los equipos que descuidan esto suelen descuidar más cosas.
• Historial público de incidentes y de divulgación. Si tienen política de divulgación coordinada publicada, si responden a los reportes, cómo comunicaron el último incidente. Un proveedor que publica postmortems honestos es una señal mucho mejor que uno sin historial visible.
• Ritmo de parcheo observable. Cuando una vulnerabilidad afecta a una tecnología que se identifica en su superficie, ¿cuánto tarda en desaparecer la versión vulnerable? Es un indicador de proceso real, no declarado.
• Estructura de subcontratación. Dónde alojan, qué CDN usan, qué proveedores de identidad. La concentración importa: si tú y tu proveedor dependéis del mismo tercero, tu diversificación es ficticia.

Ninguna de estas señales prueba por sí sola que un proveedor sea inseguro. Su valor está en el contraste: cuando lo declarado y lo observado no coinciden, tienes una pregunta concreta que hacer, y las preguntas concretas son las que producen conversaciones útiles.

El contraste es el producto, no cada fuente por separado

Un ejemplo de cómo se ve esto en la práctica. El cuestionario dice que se aplican parches críticos en un plazo de quince días. La observación externa muestra una versión de servidor web con una vulnerabilidad publicada hace tres meses, todavía presente.

Hay tres explicaciones posibles y todas son informativas: el banner miente y la versión real está parcheada —lo que revela que no tienen ocultación de banners ni lo consideran relevante—; el activo no está en su inventario —lo que revela un problema de cobertura mayor que el parche en sí—; o el compromiso de quince días no se cumple. Cualquiera de las tres merece constar en el expediente.

Ese es el trabajo real de la evaluación: no puntuar, sino localizar las discrepancias y documentar qué se hizo con cada una.

Segmentar por criticidad, porque no todos merecen lo mismo

Aplicar el mismo proceso a los ciento ochenta proveedores del registro garantiza que se haga mal en todos. La criticidad debería determinar la profundidad, y debería derivarse de tres preguntas:

1. ¿Qué función soporta? Si soporta una función esencial —y bajo DORA esa clasificación ya la tienes hecha—, el proveedor hereda esa criticidad.
2. ¿A qué datos accede? Distingue entre quien procesa datos personales o confidenciales y quien no los ve nunca.
3. ¿Cómo de reversible es? Un proveedor sustituible en dos semanas y otro que exigiría dieciocho meses de migración no son el mismo riesgo aunque hagan lo mismo.

Con eso salen tres o cuatro niveles. En el nivel alto cabe la evaluación completa, la revisión contractual y la vigilancia continua. En el bajo, basta con un registro actualizado y una comprobación externa automática. El error es no distinguir.

Lo que el regulador espera que puedas demostrar

Tanto NIS2 como DORA convirtieron esto en obligación explícita. El artículo 21.3 de la NIS2 pide tener en cuenta las vulnerabilidades específicas de cada proveedor directo y la calidad de sus prácticas y procedimientos de desarrollo seguro. DORA va más lejos: el artículo 28.4 exige evaluación previa a la firma del contrato, y el 28.3 un registro de información actualizado y un reporte anual a la autoridad.

En ambos casos, la evidencia que se pide es la misma: por cada proveedor, la fecha de la evaluación, quién la hizo, qué se revisó y qué se decidió. Una carpeta con cuestionarios rellenados no responde a ninguna de esas cuatro preguntas.

Lo mínimo viable

Si tienes que empezar de cero y con poco tiempo, este es el orden que más rendimiento da: registro completo de proveedores con la función que soportan; clasificación en tres niveles de criticidad; para el nivel alto, cuestionario con evidencias y una comprobación externa de superficie; para todos, la fecha de la última revisión visible. Con eso ya puedes responder a un auditor, y a partir de ahí se refina.

La parte que no escala a mano es mantener lo observado al día y enlazado con lo declarado, proveedor a proveedor. Es exactamente la brecha que cubre el módulo de riesgo de terceros de Violet Security, aunque el criterio de criticidad —cuál importa y por qué— tiene que ponerlo tu organización.