TL;DR (para los dopamináticos)
- Tu superficie de exposición incluye a tus proveedores. Puedes tener tus sistemas impecables y seguir siendo vulnerable por el acceso remoto de un tercero.
- TPRM y VRM no son sinónimos, aunque el mercado los use así. VRM es un subconjunto de TPRM, y ambos son distintos de la seguridad de la cadena de suministro (SCRM). Confundirlos deja fuera precisamente a los terceros más peligrosos: los que no pasan por compras, incluido el shadow IT y el shadow AI.
- La metodología ya está escrita. ISO/IEC 27001:2022 (controles A.5.19 a A.5.23), la serie ISO/IEC 27036 y NIST (CSF 2.0 y SP 800-161r1) definen qué hay que hacer. Este artículo lo traduce a siete fases ejecutables.
- Clasifica primero, pregunta después. Un cuestionario único para todos los proveedores es el error más común y el que más esfuerzo desperdicia.
- Ya te aplica. NIS2 (artículo 21.2.d) obliga a gestionar el riesgo de tus proveedores directos, y las empresas obligadas lo trasladan a sus proveedores. En el sector financiero, DORA lo lleva mucho más lejos.
- Al final tienes una herramienta gratuita para montar el cuestionario y descargarlo en PDF rellenable.
Si tienes un poco más de tiempo, lo vemos con detalle. 👇
El problema de fondo
La ciberseguridad de una empresa no termina en sus propios sistemas. Cada vez dependemos más de terceros con acceso a nuestros datos, nuestros sistemas, nuestras aplicaciones o nuestra operativa.
El patrón se repite con frecuencia: una organización invierte en firewall, MFA, formación y copias de seguridad, y el incidente entra por la VPN del proveedor que mantiene el ERP, por el software de un fabricante comprometido en origen o por el SaaS donde se aloja el CRM con todos los datos de clientes. La campaña contra instancias de Salesforce iniciada a través de tokens filtrados en GitHub es un ejemplo reciente de lo segundo.
Los casos con nombre propio lo confirman. En España, Mango notificó en octubre de 2025 la exposición de datos de contacto de clientes a través de un proveedor externo de marketing, e Iberia confirmó en noviembre un acceso no autorizado a un repositorio gestionado por un proveedor tecnológico. Fuera de España, SolarWinds, Kaseya y MOVEit siguen siendo los casos de referencia. En ninguno hicieron falta miles de intrusiones: bastó comprometer a un proveedor y dejar que la relación de confianza hiciera el resto.
Según el informe de amenazas de ENISA de 2025, el 62 % de las brechas notificadas en Europa durante el último año involucraron a terceros, ya fueran proveedores o servicios cloud.
La conclusión práctica es que esto afecta a cualquier organización que tenga un proveedor con una contraseña de sus sistemas, con independencia de su tamaño.
Primero, definiciones: TPRM, VRM y SCRM
Vas a ver estos tres acrónimos por todas partes, usados indistintamente. No significan lo mismo.
Conviene aclarar antes una cosa: TPRM y VRM son términos de mercado, no de norma. Ninguna ISO los define. Las normas hablan de supplier relationships y de supply chain. Aun así, la distinción es útil en la práctica.
Proveedores contratados: hay contrato, hay factura, hay palanca comercial. Suele vivir en el departamento de compras.
El subconjunto más pequeño de los tresToda relación externa, tenga contrato o no: partners, integradores, distribuidores, asesorías, filiales, becarios de una universidad, una administración con la que intercambias datos.
Incluye al consultor que entra por TeamViewer y no factura porque va dentro del mantenimiento del ERPEl producto o servicio en sí: componentes, librerías, firmware, dependencias de software, procedencia, y los proveedores de tus proveedores (fourth parties).
Incluye la librería open source sin mantenimiento que va dentro del software que te vendió tu proveedorLa relación es de círculos concéntricos: VRM ⊂ TPRM ⊂ Gestión de riesgos corporativa (ERM), con SCRM actuando de forma transversal a los tres.
La distinción determina el criterio de inclusión en el inventario. Si el programa se construye únicamente desde compras, la lista sale de las facturas, y los terceros que más riesgo introducen en una pyme no están ahí. El criterio útil no es «¿le pagamos?», sino «¿puede acceder, degradar o exponer algo nuestro?».
Qué dicen las normas (y qué ya te exigen)
ISO/IEC 27001:2022 — Anexo A, los cinco controles de proveedores
Es el punto de anclaje más reconocible en el mercado español y lo que te van a pedir tus clientes.
| Control | Título | Qué exige en la práctica |
|---|---|---|
| A.5.19 | Seguridad de la información en las relaciones con proveedores | Un proceso definido para gestionar el riesgo de los proveedores, en lugar de improvisar caso por caso. |
| A.5.20 | Tratamiento de la seguridad de la información en los acuerdos con proveedores | Lo que se pacte debe estar en el contrato. Un requisito que no figura en el contrato no es exigible. |
| A.5.21 | Gestión de la seguridad de la información en la cadena de suministro TIC | Mirar más allá del proveedor directo: qué compone lo que te vende y de quién depende él. |
| A.5.22 | Seguimiento, revisión y gestión de cambios de los servicios de proveedores | Revisar durante la relación y detectar cambios relevantes: subcontratas nuevas, cambio de ubicación de los datos, operaciones societarias. |
| A.5.23 | Seguridad de la información para el uso de servicios en la nube | El cloud tiene sus propias reglas: responsabilidad compartida, contratos de adhesión y un proceso de salida que rara vez se define. |
Sobre A.5.23 hay un matiz que suele pasarse por alto. En la nube el contrato no se negocia: se firma como está. La única palanca real es elegir bien antes de firmar y tener resuelto cómo salir. Por eso el proceso de adquisición y el de terminación pesan tanto como el cuestionario.
ISO/IEC 27036 — el desarrollo completo
Cuando A.5.19–A.5.23 se quedan cortos, la serie ISO/IEC 27036 es el desarrollo específico:
- 27036-1:2021 — visión general y conceptos.
- 27036-2:2022 — requisitos. Define el ciclo de vida completo de la relación: planificación, selección, acuerdo, operación y terminación.
- 27036-3:2023 — cadena de suministro de hardware, software y servicios.
- 27036-4:2016 — servicios en la nube.
La aportación más valiosa de la parte 2 es tratar la relación con el proveedor como un ciclo de vida y no como un trámite de alta. Esa idea estructura todo lo que viene después.
NIST — aplicable aunque no vayas a certificar
CSF 2.0 (2024) introdujo la categoría GV.SC — Cybersecurity Supply Chain Risk Management dentro de la función Govern. Con diez subcategorías, es la más extensa de todo el marco. Situarla en gobierno, y no en identificación o protección, indica el nivel al que NIST entiende que se toman estas decisiones: dirección, no técnica.
SP 800-161r1 (2022, con errata de noviembre de 2024) es la guía de referencia de C-SCRM. Exhaustiva y densa, pensada para organizaciones con programa formal.
SP 1326 (julio de 2026) es la incorporación más práctica: una guía rápida de due diligence de proveedores TIC que baja SP 800-161r1 a algo ejecutable, estructurada en cinco componentes: propiedad y control extranjero (FOCI), procedencia, resiliencia, prácticas ciberseguras fundamentales y niveles de la cadena de suministro.
GV.SC-10: los planes deben contemplar qué ocurre cuando la relación termina. Revocación de accesos, devolución o destrucción de datos, retirada de integraciones y cierre de cuentas. Tiene su propia fase al final de este artículo, y por una razón.
La parte regulatoria
NIS2 (Directiva UE 2022/2555), artículo 21.2.d. La seguridad de la cadena de suministro es una de las diez medidas mínimas obligatorias. El artículo 21.3 concreta que hay que tener en cuenta las vulnerabilidades específicas de cada proveedor directo y la calidad de sus prácticas de seguridad, todo ello bajo principio de proporcionalidad al tamaño y al riesgo.
El efecto cascada. Es lo que de verdad alcanza a la pyme. Si no eres entidad esencial o importante pero le vendes a una que sí lo es, el cuestionario te va a llegar, y con plazo.
En España la transposición sigue pendiente. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad se aprobó en Consejo de Ministros en enero de 2025 y a día de hoy no se ha publicado en el BOE. La Comisión Europea ya remitió dictamen motivado por el retraso. Esperar a la ley para empezar tiene poco sentido, porque los clientes no esperan. Lo tienes desarrollado en NIS2 en España 2026: qué te obliga ya.
DORA (Reglamento UE 2022/2554), aplicable desde enero de 2025 al sector financiero, es hoy el marco más exigente: due diligence previa obligatoria (art. 28), registro de información de todos los acuerdos TIC, evaluación de riesgo de concentración (art. 29) y cláusulas contractuales mínimas tasadas (art. 30). Su artículo 28.1.a resume el fondo del asunto: la entidad es plenamente responsable en todo momento del cumplimiento, aunque el servicio esté externalizado.
La metodología: siete fases
A continuación, la traducción de todo lo anterior a un proceso que cabe en una pyme sin equipo de seguridad dedicado. Pincha en cualquiera para ir al detalle:
La fase más tediosa y la que condiciona el resto. Sin inventario no hay programa.
Cruza contabilidad, sistemas y equiposEvaluar a todos por igual es inviable y contraproducente. Tres niveles, cinco criterios.
Documenta el criterio, no solo el resultadoOcho dominios mínimos, cada uno con su anclaje normativo. Y dos criterios que separan una evaluación seria de un trámite.
Pregunta por compromisos, no por intencionesLo que no está en el contrato no es exigible. Siete cláusulas mínimas para un proveedor crítico.
Control A.5.20El cuestionario devuelto es el punto de partida del análisis, no su cierre.
Cuatro salidas, y una decisión formalEl riesgo de un proveedor cambia sin previo aviso. Lo mínimo sostenible son tres elementos.
Calendario y disparadoresLas cuentas de proveedores antiguos que siguen activas son de los hallazgos más frecuentes de cualquier revisión de accesos.
GV.SC-10 existe por una razónFase 1 — Inventario de terceros
Sin inventario no hay programa. Es la fase más tediosa y también la que condiciona el resto.
Conviene cruzar al menos tres fuentes, porque ninguna es completa por sí sola:
- Contabilidad. Proveedores con factura recurrente.
- Sistemas. Quién tiene cuenta, VPN, acceso remoto, integración por API o aplicación conectada al tenant de Microsoft 365 o Google Workspace. Aquí aparece el shadow IT.
- Los equipos. Preguntar a cada responsable de área con quién trabaja de fuera. Suelen aparecer terceros que no figuran en ninguna de las dos listas anteriores.
Para cada tercero hacen falta cuatro datos mínimos: qué servicio presta, a qué accede, qué datos trata y quién es el responsable interno de la relación. Este último campo determina si el programa se sostiene o no: un proveedor sin dueño interno es un cuestionario que nadie perseguirá.
Te dejo la hoja de cálculo ya montada, con las columnas de esta fase y las de la siguiente en el orden del método, listas desplegables, la clasificación coloreada y un contador automático por nivel. Formato Excel, sin macros y sin dejar tus datos en ningún sitio.
Descargar la plantilla de inventario de terceros (.xlsx, 24 KB)
Fase 2 — Clasificación por criticidad (tiering)
Evaluar a todos por igual es inviable y contraproducente: consume tiempo, deteriora la relación con el proveedor y diluye la atención sobre los que realmente importan.
Cinco criterios de clasificación:
- Acceso. ¿Tiene acceso a sistemas internos? ¿Es privilegiado? ¿Permanente o puntual?
- Datos. ¿Trata datos personales, categorías especiales, información confidencial o propiedad intelectual? ¿Los almacena o solo los consulta?
- Criticidad operativa. Si mañana desaparece, ¿cuánto tiempo aguanta la operación? ¿Existe alternativa?
- Interconexión. ¿Hay integración técnica permanente (API, VPN, SSO, federación de identidad)?
- Concentración y sustituibilidad. ¿Cuántos procesos críticos dependen del mismo proveedor? ¿Cuánto costaría migrar?
Con eso, tres niveles:
| Nivel | Perfil típico | Profundidad de evaluación | Frecuencia |
|---|---|---|---|
| Crítico | Acceso privilegiado, datos sensibles, servicio sin alternativa rápida | Cuestionario extenso, evidencias, revisión de certificaciones, cláusulas contractuales reforzadas y derecho de auditoría | Anual |
| Relevante | Acceso limitado o datos no sensibles, servicio sustituible con esfuerzo | Cuestionario medio y certificaciones si las hay | Cada 2 años o ante cambio relevante |
| Bajo | Sin acceso a sistemas ni datos (material de oficina, catering, suministros) | Comprobación mínima documentada | Solo si cambia el alcance |
Documenta el criterio de clasificación, no únicamente el resultado. El día que un cliente, un auditor o un regulador pregunte por qué un proveedor está clasificado como bajo, la respuesta tiene que ser un criterio escrito.
Fase 3 — Evaluación (due diligence)
Los dominios mínimos del cuestionario, con su anclaje normativo:
| Dominio | Qué preguntas | Anclaje |
|---|---|---|
| Gobierno y organización | ¿Hay responsable de seguridad? ¿Políticas aprobadas? ¿Formación periódica al personal? | ISO 27001 A.5.1, A.6.3 |
| Protección de la información | Cómo clasifica, cifra, segrega y elimina los datos. Dónde están físicamente. | A.5.12, A.8.10, A.8.24 |
| Control de accesos | MFA, gestión de cuentas privilegiadas, altas y bajas, accesos de sus propios terceros. | A.5.15–A.5.18, A.8.2, A.8.5 |
| Gestión de vulnerabilidades | Cómo identifica y corrige. Plazos comprometidos por severidad. Pentest periódico. | A.8.8 |
| Respuesta ante incidentes | Procedimiento, capacidad de detección y plazo de notificación al cliente. | A.5.24–A.5.28 |
| Continuidad y recuperación | Copias, RTO/RPO comprometidos y si prueban la restauración. | A.5.29, A.5.30, A.8.13 |
| Subcontratación | Quiénes son sus terceros, si avisa antes de cambiarlos, si les traslada tus requisitos. | A.5.21 |
| Cumplimiento y certificaciones | ISO 27001, ENS, SOC 2, sectoriales. Con alcance. | A.5.31, A.5.35, A.5.36 |
Dos criterios separan una evaluación seria de un trámite.
El primero es preguntar por compromisos y no por intenciones. «¿Gestionan vulnerabilidades?» se responde siempre que sí y no aporta información. «¿En qué plazo corrigen una vulnerabilidad crítica y cómo lo miden?» produce una respuesta utilizable, comparable y contractualizable.
El segundo es pedir evidencias solo a los críticos, y solo aquellas que se vayan a revisar: un certificado, una política, un informe de pentest sin datos sensibles, el resultado de una prueba de restauración. Solicitar treinta documentos que nadie va a abrir vacía el proceso de contenido y desgasta la credibilidad ante el proveedor.
Que un proveedor «tenga la ISO 27001» no dice nada por sí solo. Hay que mirar tres cosas: el alcance (¿cubre el servicio que te presta, o solo su sede y no el centro de datos?), la entidad certificadora (¿acreditada por ENAC o equivalente?) y la fecha de validez.
En SOC 2, un Type I acredita que los controles estaban diseñados en un momento concreto; el Type II verifica que funcionaron durante un periodo. No son equivalentes.
Existen además cuestionarios estándar que evitan partir de cero: el SIG de Shared Assessments y el CAIQ de Cloud Security Alliance para servicios cloud. Adaptarlos al contexto propio suele ser más eficiente que redactar uno desde el principio.
Esta fase la puedes resolver ahora mismo
He publicado ACBSEC · Basic VRM Form: eliges el nivel de criticidad del proveedor, marcas a qué accede y la herramienta arma el cuestionario con los ocho dominios de esta tabla, más los bloques de nube, datos personales, inteligencia artificial, desarrollo y seguridad física cuando aplican.
Cada pregunta lleva impreso el control del que sale en ISO 27001, NIST CSF 2.0, ENS, TISAX, RGPD, el Reglamento de IA e ISO 42001. Al final descargas un PDF con campos rellenables para que el proveedor responda sin imprimir nada.
Montar mi cuestionario →Fase 4 — Contrato (A.5.20)
Lo que no está en el contrato no es exigible. Cláusulas mínimas para un proveedor crítico:
- Requisitos de seguridad concretos y medibles, evitando fórmulas del tipo «aplicará medidas adecuadas».
- Notificación de incidentes con plazo explícito (24, 48 o 72 horas) y canal definido.
- Autorización previa o notificación de subcontratación.
- Derecho de auditoría o, en su defecto, entrega periódica de evidencias.
- Ubicación de los datos y condiciones de transferencia internacional.
- Encargado de tratamiento (art. 28 RGPD) cuando haya datos personales.
- Devolución y destrucción certificada de datos a la finalización, con formato y plazo.
La última es la que menos se firma y la que más problemas evita.
Fase 5 — Tratamiento de los resultados
El cuestionario devuelto es el punto de partida del análisis, no su cierre. Con las respuestas en la mano deberían producirse cuatro salidas:
- Riesgos identificados, valorados por probabilidad e impacto sobre tu negocio, no sobre el del proveedor.
- Brechas de control: qué debería existir según su nivel de criticidad y no existe.
- Plan de acción con responsable y fecha, acordado con el proveedor.
- Decisión formal y trazable: aceptar, aceptar con condiciones, exigir mitigación antes de contratar o rechazar.
Un riesgo aceptado a sabiendas y por escrito por quien tiene autoridad para hacerlo es una decisión de negocio legítima; un riesgo aceptado por omisión es negligencia.
Fase 6 — Monitorización y reevaluación
El riesgo de un proveedor cambia sin previo aviso: operaciones societarias, cambio de proveedor cloud, una brecha, ampliación del servicio prestado, traslado del soporte a otro país.
Lo mínimo sostenible incluye tres elementos:
- Reevaluación periódica según el nivel de clasificación (tabla de la fase 2).
- Disparadores de reevaluación fuera de calendario: incidente de seguridad público, cambio de control societario, ampliación de alcance del servicio, cambio de subcontratistas.
- Vigilancia ligera mediante alertas de noticias sobre los proveedores críticos. Coste cero y, en ocasiones, información antes de que llegue por el canal oficial.
Fase 7 — Salida
GV.SC-10 existe por una razón. Cuando termina la relación:
- Revocar todos los accesos, incluidos los técnicos: claves API, certificados, cuentas de servicio.
- Recuperar los datos en formato utilizable y exigir certificado de destrucción.
- Desmontar integraciones y eliminar reglas de firewall y VPN.
- Documentar el cierre.
Las cuentas de proveedores antiguos que siguen activas están, en mi experiencia, entre los hallazgos más frecuentes de cualquier revisión de accesos, y entre los más sencillos de aprovechar por un atacante.
Errores más habituales
Un cuestionario único para todos
Cien preguntas al proveedor de agua embotellada y ninguna al que administra el servidor.
El cuestionario como trámite
Se envía, se archiva y nadie lo revisa. Si no va a analizarse la respuesta, el envío solo consume tiempo propio y ajeno para generar un papel.
Evaluar solo en el alta
El proveedor aprobado hace tres años puede no parecerse al de hoy.
Confundir certificado con garantía
Ver el logo de ISO 27001 y no comprobar el alcance.
Ignorar la cuarta parte
El proveedor cumple, pero su subcontratista tiene tus datos. El riesgo se hereda, y la responsabilidad frente a tu cliente también.
Cómo empezar sin coste
Si partes de cero, no intentes montar el programa completo:
- Lista tus terceros en una hoja de cálculo, cruzando las tres fuentes de la fase 1. Tienes la plantilla en Excel preparada para eso.
- Marca los que tienen acceso a sistemas o datos. Suelen ser bastantes menos de los esperados.
- De esos, señala los cinco más críticos y empieza únicamente por ellos.
- Revisa quién tiene accesos activos y no debería tenerlos. Es gratuito, se resuelve en una tarde y es la medida con mejor retorno de la lista.
- Envía un cuestionario corto a esos cinco. Diez o quince preguntas bien elegidas rinden más que cien mal enviadas.
Cuando ese circuito funcione, amplíalo. Un programa de veinte proveedores que se mantiene aporta mucho más que uno de doscientos abandonado al segundo mes.
Una evaluación de proveedores no tiene por qué ser complicada
La dificultad rara vez está en saber qué preguntar, sino en gestionar el proceso: preparar el cuestionario, enviarlo, perseguir respuestas, revisar evidencias, analizar resultados y mantener un registro que sirva cuando alguien pregunte.
Esa carga administrativa es la que hace que la mayoría de programas de evaluación de proveedores se abandonen en la tercera ronda.
Por eso he creado ACBSEC · Basic VRM Form, una herramienta básica de formularios de VRM que podrás pasarle a tus proveedores.
¿Quieres empezar a evaluar la seguridad de tus proveedores?
Clasificas al proveedor, marcas qué le aplica y te llevas el cuestionario en PDF rellenable, con el mapeo a ISO 27001, NIST CSF 2.0, ENS, TISAX, RGPD, Reglamento de IA e ISO 42001. Todo se genera en tu navegador: no se envía nada a ningún servidor.
Accede a la herramienta gratis →¿Te ha llegado el cuestionario de seguridad de un cliente y no sabes por dónde empezar a responderlo? Escríbeme y lo vemos juntos, sin compromiso.
NormasISO/IEC 27036-1:2021, visión general y conceptos · ISO/IEC 27036-3:2023, cadena de suministro de hardware, software y servicios · ISO/IEC 27001:2022 Anexo A, controles de proveedores (A.5.19–A.5.23) · A.5.20, seguridad en los acuerdos con proveedores · A.5.23, servicios en la nube
NISTCSF 2.0, categoría GV.SC · SP 800-161r1, C-SCRM Practices · SP 1326, guía rápida de due diligence (julio de 2026) · SP 1305, guía rápida del CSF 2.0 para C-SCRM
RegulaciónNIS2, artículo 21(2)(d) y cláusulas con proveedores · Estado de la transposición de NIS2 en España · Reglamento (UE) 2022/2554 (DORA) en el BOE · CNMV, preguntas frecuentes sobre DORA
Casos e incidentes citadosCampaña contra instancias de Salesforce originada en GitHub · Mango, brecha en proveedor externo · Iberia, incidente en proveedor tecnológico
Sobre TPRM y VRMThird-Party Risk Management vs Vendor Risk Management (UpGuard) · Diferencias entre VRM y TPRM (Vanta)
Última revisión de este contenido: agosto de 2026. La correspondencia entre controles de distintos marcos es una referencia de trabajo, no una equivalencia oficial: el alcance concreto lo fija cada norma en su texto.