Riesgo cibernético de terceros: cómo evaluar y controlar la exposición de tus proveedores
Una empresa puede fortalecer sus controles internos y continuar expuesta a través de sus proveedores.
Servicios de nube, aplicaciones SaaS, soporte técnico, telecomunicaciones, nómina, respaldo y mantenimiento de infraestructura necesitan conectarse con sistemas, procesar información o participar en procesos esenciales. En algunos casos, los proveedores reciben accesos privilegiados que les permiten administrar componentes críticos.

Estas relaciones aportan capacidades que sería difícil desarrollar internamente, pero también crean dependencias y rutas de acceso que deben conocerse y controlarse.
El riesgo no se limita a que un proveedor sufra un ciberataque. También puede originarse en permisos excesivos, cuentas que permanecen activas después de un proyecto, integraciones mal configuradas, fallas de disponibilidad o subcontratistas que operan fuera de la visibilidad del cliente.
Por eso, gestionar el riesgo cibernético de terceros no consiste únicamente en aplicar un cuestionario antes de firmar un contrato. Requiere entender qué puede hacer cada proveedor dentro del entorno, qué consecuencias tendría una falla y qué controles deben mantenerse durante toda la relación.
Qué es el riesgo cibernético de terceros
El riesgo cibernético de terceros es la posibilidad de que una relación externa afecte la confidencialidad, integridad o disponibilidad de los sistemas, la información y las operaciones de una organización.
El origen puede encontrarse en un proveedor de tecnología, consultor, contratista, socio, integrador o empresa encargada de administrar algún componente de la infraestructura.
Un incidente puede llegar a la organización de distintas maneras. Un atacante podría comprometer la cuenta remota de un proveedor y utilizarla como punto de entrada. Una plataforma externa podría exponer información debido a una configuración incorrecta. Una actualización de software comprometida podría distribuir código malicioso. También es posible que una interrupción en el proveedor detenga un proceso crítico, aunque los sistemas internos de la empresa no hayan sido atacados.
La organización no controla directamente toda la tecnología ni todos los procesos del tercero. Sin embargo, sí puede decidir qué acceso entrega, qué información comparte, qué evidencia solicita y qué medidas aplicará si las condiciones de la relación cambian.
La criticidad del proveedor no depende del tamaño del contrato
Clasificar a los proveedores por gasto, reconocimiento de marca o duración del contrato produce una visión incompleta.
Un proveedor pequeño puede conservar acceso administrativo a un servidor esencial. Una consultoría temporal puede recibir información confidencial. Una aplicación de uso limitado puede integrarse con el directorio corporativo y obtener permisos sobre identidades, archivos o correo electrónico.
En cambio, un contrato costoso puede representar un riesgo técnico reducido cuando el proveedor no accede a datos sensibles, no se conecta con la infraestructura y puede reemplazarse sin interrumpir la operación.
La clasificación debe basarse en la relación real con la empresa.
Para determinar la criticidad conviene revisar cuatro dimensiones:
Dimensión | Pregunta principal | Indicadores de mayor riesgo |
Acceso | ¿A qué sistemas y funciones puede entrar el proveedor? | Acceso remoto, privilegios administrativos, cuentas persistentes o conexión con producción |
Información | ¿Qué datos recibe, almacena o procesa? | Información personal, financiera, confidencial, regulada o propiedad intelectual |
Dependencia | ¿Qué ocurriría si su servicio deja de estar disponible? | Interrupción de procesos críticos, ausencia de alternativas o recuperación prolongada |
Propagación | ¿Hasta dónde podría extenderse un compromiso? | Integraciones amplias, agentes instalados, relaciones de confianza o administración centralizada |
Esta clasificación permite aplicar controles proporcionales. Un servicio sin acceso a información o sistemas no necesita la misma evaluación que un proveedor que administra respaldos, identidades o infraestructura crítica.
El objetivo no es someter a todos a un proceso idéntico, sino concentrar la revisión más profunda en las relaciones que pueden generar mayor impacto.
El primer reto es saber qué proveedores existen
Las relaciones con terceros suelen estar distribuidas entre Compras, TI, Seguridad, Finanzas, Recursos Humanos y distintas áreas de negocio. La contratación directa de aplicaciones en la nube también puede incorporar servicios sin pasar por los procesos tradicionales de adquisición.
Esto hace que el inventario contractual no siempre coincida con el inventario tecnológico.
El CIS Critical Security Control 15 recomienda mantener un inventario de proveedores, clasificarlos y asignar un contacto interno responsable para cada relación.
Para que ese inventario sea útil en ciberseguridad, debería indicar:
Qué servicio presta el proveedor.
Quién es el responsable interno.
Qué sistemas, datos y procesos están involucrados.
Qué cuentas, integraciones o conexiones utiliza.
Cuál es su nivel de criticidad.
Cuándo se evaluó por última vez.
Qué subcontratistas relevantes participan.
Cuándo se revisará o terminará la relación.
Esta información no suele encontrarse completa en una sola área. Compras conoce los contratos, TI las integraciones, Seguridad los accesos y el área usuaria la importancia operativa. Construir una visión confiable requiere conectar esas fuentes.
Qué evaluar antes de contratar un proveedor
La evaluación debe comenzar por comprender cómo funcionará el servicio dentro de la organización.
Antes de enviar un cuestionario, es necesario saber qué información recibirá el proveedor, desde dónde se conectará, cómo autenticará a sus usuarios, qué permisos necesitará y qué componentes instalará o administrará.
Sin este contexto, una empresa puede solicitar mucha documentación y aun así omitir el punto de mayor exposición.
Gobierno y responsabilidades
El proveedor debe tener responsables definidos para seguridad, continuidad y respuesta a incidentes. También debe poder explicar cómo administra riesgos, excepciones, cambios relevantes y participación de subcontratistas.
Certificaciones y auditorías independientes pueden aportar evidencia sobre su madurez general. No obstante, no demuestran por sí solas que el servicio contratado esté configurado correctamente para un cliente particular.
La evaluación debe conectar la evidencia institucional del proveedor con la arquitectura específica de la relación.
Identidades y accesos
Es necesario revisar cómo se crean, protegen, supervisan y eliminan las cuentas utilizadas para prestar el servicio.
Los accesos deberían ser individuales y atribuibles. También deben contar con mecanismos adecuados de autenticación, privilegio mínimo y separación de funciones. Cuando el proveedor necesita permisos administrativos, la organización debe saber quién puede utilizarlos, bajo qué condiciones y cómo se revocarán durante una emergencia.
Las cuentas genéricas o compartidas dificultan investigar actividades y asignar responsabilidades. Los permisos permanentes también amplían el periodo durante el cual una credencial comprometida puede aprovecharse.
Protección de la información
La empresa necesita identificar qué datos recibirá el tercero, dónde serán procesados, cuánto tiempo se conservarán y quién podrá consultarlos.
La revisión debe abarcar no solo el entorno principal, sino también respaldos, registros, ambientes de prueba, archivos exportados y copias utilizadas por subcontratistas.
La clasificación interna de la información debe determinar el nivel de protección requerido. No toda información necesita las mismas medidas, pero los datos sensibles no deberían compartirse sin una justificación y controles claros.
Vulnerabilidades y cambios tecnológicos
El proveedor debería explicar cómo identifica vulnerabilidades, establece prioridades, implementa actualizaciones y comunica riesgos que puedan afectar al cliente.
Cuando existe software instalado dentro de la infraestructura, deben definirse las responsabilidades de actualización. La ambigüedad sobre quién debe corregir una vulnerabilidad suele provocar que el hallazgo permanezca abierto.
También es importante conocer cómo se evalúan cambios relevantes antes de introducirlos en el servicio.
Continuidad y recuperación
La disponibilidad del proveedor puede ser tan importante como su seguridad.
Una interrupción externa puede afectar facturación, producción, comunicaciones o atención a clientes sin comprometer directamente la infraestructura interna. Por ello, deben revisarse sus capacidades de respaldo, redundancia, recuperación y comunicación de crisis.
Para los servicios críticos, las promesas de disponibilidad deben contrastarse con evidencia de pruebas y con las dependencias reales del servicio.
Respuesta a incidentes
Antes de contratar, debe quedar claro cómo informará el proveedor un incidente que afecte datos, sistemas o disponibilidad.
La organización necesita conocer los canales de contacto, los responsables de escalamiento y el tipo de información que podrá recibir durante la investigación. También debe establecerse cómo se preservará evidencia y qué apoyo proporcionará el proveedor para contener y recuperar.
Negociar estas condiciones durante un incidente aumenta el tiempo de respuesta y puede limitar la información disponible.
La exposición puede extenderse hacia los subcontratistas
El proveedor contratado puede depender de centros de datos, plataformas de nube, desarrolladores, servicios de autenticación y otras organizaciones para entregar su solución.
Estas dependencias adicionales suelen denominarse cuartos terceros.
La empresa no siempre podrá evaluar individualmente a toda la cadena. Aun así, debería conocer qué subcontratistas participan cuando procesan información sensible o soportan funciones esenciales.
Un proveedor crítico tendría que explicar qué actividades subcontrata, qué información comparte, cómo evalúa a esas organizaciones y cómo notificará cambios relevantes.
También conviene conocer qué ocurriría si uno de esos servicios externos deja de estar disponible. Una arquitectura puede parecer redundante desde la perspectiva del proveedor y continuar dependiendo de una sola plataforma en un nivel inferior.
La falta de relación contractual directa no elimina el impacto potencial para el cliente.
El contrato debe convertir expectativas en obligaciones verificables
La evaluación muestra cómo opera el proveedor en un momento determinado. El contrato define qué deberá mantener durante la relación.
Las condiciones dependerán del servicio, la industria, el tipo de información y las obligaciones aplicables. Los contratos de mayor riesgo deberían establecer con claridad:
Controles mínimos de seguridad.
Uso y conservación permitidos de la información.
Restricciones y notificación sobre subcontratistas.
Administración y revisión de accesos.
Plazos para notificar incidentes.
Cooperación durante investigaciones.
Requisitos de continuidad y recuperación.
Corrección de vulnerabilidades relevantes.
Entrega de evidencia cuando sea necesaria.
Devolución o eliminación de información.
Revocación de accesos al finalizar el servicio.
La redacción debe ser revisada por las áreas legales correspondientes. Desde la perspectiva técnica, lo importante es evitar compromisos ambiguos.
Una obligación como “mantener medidas de seguridad adecuadas” deja demasiado margen de interpretación. Es preferible establecer responsabilidades, resultados y evidencia que puedan verificarse.
Un proveedor evaluado sigue necesitando acceso limitado
Superar la evaluación no justifica recibir acceso ilimitado.
La relación debe diseñarse con el principio de privilegio mínimo: permitir solo las acciones, sistemas y periodos necesarios para cumplir el servicio.
CISA recomienda que terceros y proveedores de servicios administrados tengan acceso únicamente a los dispositivos y servidores relacionados con sus responsabilidades. También señala la importancia de aplicar separación de funciones y formalizar requisitos de seguridad. Estas recomendaciones aparecen en su guía de prevención y respuesta frente a ransomware.
En la práctica, el acceso debería:
Utilizar cuentas individuales.
Exigir autenticación multifactor.
Restringirse a sistemas y funciones específicas.
Activarse bajo demanda cuando sea viable.
Generar registros de actividad.
Revisarse periódicamente.
Revocarse cuando deje de ser necesario.
Las medidas deben considerar también tokens, certificados, llaves API y agentes instalados. El acceso de un tercero no siempre ocurre mediante una cuenta de usuario visible.
La organización debe conservar la capacidad de suspender la conexión sin depender del propio proveedor.
El monitoreo debe seguir el nivel de riesgo
Una evaluación inicial puede perder vigencia.
El proveedor puede modificar su infraestructura, incorporar subcontratistas, ampliar el servicio o recibir acceso a información adicional. También puede ser adquirido por otra organización o cambiar las plataformas utilizadas para atender al cliente.
Por ello, la frecuencia de revisión debe depender de la criticidad de la relación.
No siempre es necesario repetir el proceso completo. La supervisión puede concentrarse en los aspectos que cambiaron y en las condiciones de mayor impacto.
Algunos eventos que deberían provocar una reevaluación son:
Renovación o ampliación del contrato.
Nuevas integraciones o privilegios.
Procesamiento de información adicional.
Cambio de subcontratistas críticos.
Modificación importante de la arquitectura.
Incidente de seguridad.
Deterioro de los niveles de servicio.
Adquisición o reestructuración del proveedor.
El monitoreo debe confirmar si la exposición sigue siendo la que la organización decidió aceptar. Repetir anualmente el mismo cuestionario, sin revisar accesos ni cambios técnicos, aporta poco valor.
Cómo responder cuando el proveedor reporta un incidente
Cuando un tercero informa un incidente, la organización debe determinar si existe una conexión con sus sistemas y operaciones.
La primera revisión debe identificar el servicio afectado, el momento aproximado del compromiso, las cuentas o integraciones involucradas y las acciones de contención ejecutadas por el proveedor.
Después, los equipos internos necesitan validar su propio entorno. Esto puede incluir registros de autenticación, accesos remotos, actividad administrativa, cambios de configuración y movimientos de información relacionados con el tercero.
La empresa no debería asumir que el análisis del proveedor cubre completamente el impacto sobre el cliente. Cada organización conoce mejor sus activos, dependencias y registros internos.
Las decisiones principales serán:
Mantener, limitar o suspender la conexión.
Revocar o rotar credenciales.
Aplicar controles temporales.
Activar alternativas de continuidad.
Preservar evidencia.
Coordinar comunicaciones y obligaciones.
Establecer condiciones para restablecer el servicio.
Suspender de inmediato toda conexión puede reducir exposición, pero también interrumpir procesos esenciales. La contención debe equilibrar seguridad y continuidad con información suficiente para tomar una decisión controlada.
Los proveedores críticos deberían estar contemplados previamente en los planes de respuesta a incidentes.
La salida también debe gestionarse como un proceso de seguridad
El vencimiento del contrato no elimina automáticamente el acceso.
Cuentas, sesiones, tokens, certificados, VPN, llaves API, agentes, dispositivos, respaldos y archivos pueden permanecer activos después de terminar la relación. La documentación y responsabilidades operativas también pueden quedar sin transferir.
El proceso de salida debe confirmar que:
Las cuentas y conexiones fueron revocadas.
Los secretos y certificados dejaron de ser válidos.
Los activos fueron recuperados.
La información fue devuelta o eliminada.
Las integraciones y agentes fueron retirados.
La documentación necesaria fue transferida.
Las responsabilidades operativas fueron reasignadas.
La continuidad del servicio quedó asegurada.
La verificación debe ser técnica. Una confirmación administrativa del proveedor no demuestra necesariamente que todas las rutas fueron cerradas.
También puede ser necesario cambiar credenciales que el tercero conocía, aunque ya no tuviera una cuenta propia.
Errores que dejan abierta la exposición
Algunas prácticas generan una apariencia de control sin reducir suficientemente el riesgo.
Evaluar al proveedor solo por su reputación
El reconocimiento de la marca no sustituye el análisis de los accesos, datos y dependencias de la relación específica.
Utilizar el mismo cuestionario para todos
Un proceso genérico puede exigir evidencia innecesaria a proveedores de bajo riesgo y omitir aspectos críticos en servicios con acceso privilegiado.
Confiar únicamente en certificaciones
Las certificaciones aportan contexto sobre la organización, pero no validan por sí mismas la configuración del servicio contratado.
Dar acceso permanente por comodidad
Los privilegios persistentes facilitan el soporte, pero amplían la oportunidad de abuso o compromiso.
Revisar solo antes de contratar
Los cambios en el servicio pueden transformar el riesgo original. Una evaluación que nunca se actualiza deja de representar la relación.
No preparar la terminación
Los accesos olvidados después de un proyecto o contrato se convierten en rutas sin un propietario activo que las supervise.
Integrar a los proveedores en el gobierno de ciberseguridad
El NIST Cybersecurity Framework 2.0 incorporó la gestión del riesgo de la cadena de suministro dentro de la función Govern.
La guía rápida de NIST para Cybersecurity Supply Chain Risk Management propone utilizar el marco para establecer una capacidad interna y comunicar requisitos a los proveedores. NIST SP 800-161 Rev. 1 amplía las prácticas para identificar, evaluar y mitigar riesgos relacionados con productos y servicios.
Este enfoque reconoce que el riesgo de terceros no pertenece exclusivamente a Seguridad o Compras.
El área de negocio determina la importancia del servicio. TI conoce la arquitectura. Seguridad revisa controles y accesos. Compras administra la relación comercial. Legal establece obligaciones. Dirección participa cuando la exposición puede producir un impacto material.
El gobierno debe conectar esas responsabilidades y definir:
Quién aprueba la incorporación del proveedor.
Qué evaluación corresponde a cada nivel de riesgo.
Quién supervisa la relación.
Qué cambios requieren una nueva revisión.
Quién puede aceptar una excepción.
Cómo se escalan los incidentes.
Quién autoriza la terminación de accesos.
Cuando estas decisiones no tienen propietario, el riesgo permanece abierto por omisión.
Cómo ayuda Ceico a gestionar el riesgo de terceros
Ceico ayuda a las organizaciones a comprender cómo los proveedores y sus integraciones se relacionan con la infraestructura, las identidades y los procesos críticos.
El acompañamiento puede incluir la identificación de conexiones externas, la clasificación técnica de proveedores, la revisión de accesos privilegiados, la evaluación de vulnerabilidades y la aplicación de controles de segmentación y privilegio mínimo.
También puede apoyar en la definición de criterios técnicos, el monitoreo de infraestructura, la preparación de procedimientos de contención y la verificación de accesos durante el proceso de salida.
El objetivo no es eliminar las relaciones externas. Las empresas necesitan proveedores especializados para operar, innovar y crecer.
La meta es que cada dependencia sea visible, tenga controles proporcionales y pueda gestionarse tanto durante la operación normal como ante un incidente.
Delegar el servicio no elimina sus consecuencias
Contratar a un proveedor transfiere parte de la operación, pero no todas las consecuencias de una falla.
Si el tercero expone información, interrumpe un proceso o permite acceso al entorno, la empresa todavía puede enfrentar afectaciones operativas, financieras, contractuales y reputacionales.
Por eso, administrar el riesgo cibernético de terceros significa controlar la relación, no intentar garantizar que ningún proveedor sufrirá un incidente.
Una organización madura sabe quién se conecta, qué puede hacer, qué información recibe, de quién depende y cómo se cerrará su acceso cuando deje de ser necesario.
Esa visibilidad permite aprovechar capacidades externas sin convertir la confianza en un punto ciego.






