Gestión de Proveedores en ISO 27001: Requisitos de Riesgo de Terceros

Tu ISMS es tan fuerte como tu proveedor más débil. Toda empresa SaaS depende de una red de relaciones con terceros — proveedores de infraestructura en la nube que alojan tu entorno de producción, proveedores de identidad que gestionan la autenticación, procesadores de pagos que manejan datos financieros, herramientas de monitoreo que ingieren tu telemetría y docenas de otros servicios de los que tu aplicación depende para funcionar. ISO 27001 reconoce esta realidad y requiere que identifiques, evalúes y gestiones sistemáticamente los riesgos de seguridad de la información introducidos por estas relaciones.

Esto no es una preocupación teórica. Cuando un proveedor sufre una brecha, su fallo se convierte en tu exposición. Los datos de clientes procesados por un subprocesador comprometido siguen siendo tu responsabilidad. Una interrupción del proveedor de identidad que bloquea a tus usuarios fuera de tu plataforma sigue siendo tu fallo de disponibilidad. Una dependencia con una puerta trasera inyectada en tu pipeline de compilación sigue siendo tu incidente de seguridad. Los controles A.5.19 a A.5.23 del Annex A de ISO 27001 existen precisamente porque las relaciones con proveedores son una de las fuentes de riesgo de seguridad de la información más significativas y persistentes.

Esta guía cubre los requisitos de ISO 27001 para la gestión de proveedores, explica cada control relevante del Annex A, recorre los procesos prácticos de debida diligencia, alineación contractual y monitoreo continuo, y aborda los desafíos específicos de la cadena de suministro que enfrentan las empresas SaaS.

Controles de Gestión de Proveedores en ISO 27001 Explicados

La revisión de 2022 de ISO 27001 agrupa los controles de gestión de proveedores bajo la sección A.5, dentro de la categoría de controles organizacionales. Cinco controles crean un marco integral para gestionar el riesgo de terceros.

A.5.19 — Seguridad de la Información en las Relaciones con Proveedores

Este es el control fundamental. Requiere que establezcas y documentes una política y procedimientos para gestionar los riesgos de seguridad de la información asociados con el uso de productos y servicios de proveedores. La política debe abordar:

• Los tipos de proveedores y los tipos de acceso que tienen a tu información y sistemas
• Los requisitos mínimos de seguridad de la información para cada tipo de relación con proveedores
• Procesos para evaluar las capacidades de seguridad de la información del proveedor antes de establecer una relación
• Los criterios para seleccionar y aprobar proveedores
• Responsabilidades para gestionar las relaciones con proveedores durante todo su ciclo de vida

Este control establece que la gestión de proveedores no es ad hoc — es un proceso definido, repetible y gobernado por una política documentada. Tu política de seguridad de la información para proveedores debe ser parte de tu marco de políticas del ISMS más amplio.

A.5.20 — Abordando la Seguridad de la Información en los Acuerdos con Proveedores

Una vez que hayas seleccionado un proveedor, este control requiere que establezcas y acuerdes los requisitos de seguridad de la información relevantes con cada proveedor que pueda acceder, procesar, almacenar, comunicar o proporcionar componentes de infraestructura de TI para tu información. En términos prácticos, esto significa que tus contratos deben incluir:

• Definición clara de la información y los servicios a los que el proveedor accederá o proporcionará
• Requisitos de seguridad de la información específicos para la relación (estándares de cifrado, controles de acceso, derechos de auditoría)
• Obligaciones de notificación de incidentes (qué tan rápido el proveedor debe informarte de incidentes de seguridad que afecten tus datos)
• La obligación del proveedor de cumplir con tus requisitos de seguridad de la información o estándares equivalentes
• Tu derecho a auditar el cumplimiento del proveedor con los requisitos acordados
• Requisitos para la gestión del proveedor de sus propios subproveedores (tu riesgo de cuarta parte)
• Devolución o destrucción de tu información al finalizar la relación
• Obligaciones de confidencialidad y no divulgación

Estos requisitos se implementan típicamente a través de una combinación del acuerdo maestro de servicios, un acuerdo de procesamiento de datos (consulta nuestra guía de DPA para GDPR para requisitos cuando están involucrados datos personales) y anexos o adendas de seguridad de la información.

A.5.21 — Gestión de la Seguridad de la Información en la Cadena de Suministro de TIC

Este control aborda específicamente los riesgos de la cadena de suministro en productos y servicios de tecnologías de la información y las comunicaciones (TIC). Para las empresas SaaS, esto es directamente relevante porque tu cadena de suministro de software incluye bibliotecas de código abierto, componentes comerciales, servicios en la nube e integraciones SaaS a SaaS.

El control requiere que:

• Definas e implementes procesos para gestionar los riesgos de seguridad de la cadena de suministro de TIC
• Requieras que los proveedores propaguen prácticas de seguridad apropiadas a lo largo de la cadena de suministro
• Incluyas los riesgos de la cadena de suministro de TIC en tu proceso de evaluación de riesgos
• Monitorees las amenazas de la cadena de suministro (dependencias comprometidas, actualizaciones maliciosas, brechas de proveedores)

En el contexto SaaS, este control impulsa prácticas como el análisis de composición de software, el escaneo de vulnerabilidades de dependencias, programas de cuestionarios de seguridad de proveedores y el monitoreo de subprocesadores.

A.5.22 — Monitoreo, Revisión y Gestión del Cambio de Servicios de Proveedores

La gestión de proveedores no es una actividad puntual. Este control requiere monitoreo continuo y revisión periódica de los servicios de proveedores y cualquier cambio en la entrega del servicio del proveedor. Específicamente, debes:

• Monitorear el rendimiento y la seguridad del servicio del proveedor de manera continua
• Revisar el cumplimiento del proveedor con los requisitos de seguridad de la información acordados
• Gestionar los cambios en los servicios del proveedor (incluyendo cambios en los subproveedores del proveedor, plataformas tecnológicas o postura de seguridad)
• Evaluar si los cambios en el servicio del proveedor afectan tu perfil de riesgo de seguridad de la información

Para las empresas SaaS, esto se traduce en la revisión regular de los informes SOC 2 del proveedor, el monitoreo de avisos de seguridad del proveedor, el seguimiento de cambios en las listas de subprocesadores del proveedor y la reevaluación del riesgo del proveedor cuando ocurren cambios significativos.

A.5.23 — Seguridad de la Información para el Uso de Servicios en la Nube

Este es un nuevo control introducido en la revisión de 2022, que refleja el papel central de los servicios en la nube en los sistemas de información modernos. Requiere que establezcas procesos para la adquisición, uso, gestión y salida de servicios en la nube, con atención específica a:

• Definir requisitos de seguridad de la información para servicios en la nube basados en tus necesidades de seguridad
• Establecer criterios de selección de servicios en la nube que incluyan capacidades de seguridad
• Definir roles y responsabilidades entre tu organización y el proveedor de servicios en la nube (el modelo de responsabilidad compartida)
• Gestionar los controles de seguridad que son tu responsabilidad bajo el modelo de responsabilidad compartida
• Establecer estrategias de salida para servicios en la nube, incluyendo recuperación de datos y verificación de eliminación

Este control reconoce que los servicios en la nube presentan desafíos únicos de gestión de proveedores — estás compartiendo la responsabilidad de la seguridad con el proveedor, y el límite de esa responsabilidad compartida varía según el modelo de servicio (IaaS, PaaS, SaaS).

Para un mapeo completo de todos los controles del Annex A, consulta nuestra guía de controles del Annex A de ISO 27001.

Clasificación y Estratificación de Proveedores

No todos los proveedores conllevan el mismo riesgo. Un proveedor de infraestructura en la nube que aloja tu base de datos de producción es fundamentalmente diferente de una herramienta de diseño utilizada por tu equipo de marketing. ISO 27001 requiere que tu esfuerzo de gestión de proveedores sea proporcional al riesgo que cada proveedor introduce. La clasificación y la estratificación hacen esto práctico.

Construyendo un Inventario de Proveedores

Antes de poder clasificar proveedores, necesitas un inventario completo. Esto es más difícil de lo que parece porque las empresas SaaS típicamente adoptan herramientas rápidamente y a veces sin supervisión centralizada de adquisiciones.

Métodos de descubrimiento:

• Registros financieros — Facturas, estados de tarjetas de crédito y plataformas de gestión de suscripciones revelan cada herramienta y servicio por el que la organización paga. Esta es la fuente más confiable.
• Registros de SSO y proveedor de identidad — Tu proveedor de identidad (Okta, Google Workspace, Azure AD) muestra a qué aplicaciones SaaS acceden los empleados. Las aplicaciones no integradas con SSO son una brecha que vale la pena investigar.
• Análisis de tráfico de red — Los registros DNS y de proxy revelan los servicios externos con los que tus sistemas se comunican, incluyendo aquellos que pueden no estar formalmente adquiridos.
• Encuestas por departamento — Pregunta a cada equipo qué herramientas y servicios utilizan. Esto captura herramientas de nivel gratuito y TI en la sombra que no aparecen en los registros financieros.
• Revisión de arquitectura de ingeniería — Revisa tus diagramas de infraestructura, manifiestos de dependencias (package.json, requirements.txt, Gemfile) y configuraciones de despliegue para identificar todos los servicios externos de los que depende tu aplicación.

Marco de Estratificación

Asigna cada proveedor a un nivel basándote en el riesgo que introduce. Un modelo de tres niveles equilibra el rigor con la practicidad:

Nivel	Criterios	Nivel de Debida Diligencia	Frecuencia de Revisión	Ejemplos
Nivel 1 — Crítico	Procesa o almacena datos de clientes, aloja infraestructura de producción, proporciona servicios críticos de seguridad o causaría una interrupción significativa del negocio si no está disponible	Debida diligencia completa: cuestionario de seguridad, revisión de informe SOC 2/ISO 27001, resultados de pruebas de penetración, requisitos contractuales de seguridad	Anualmente (mínimo), más revisiones activadas por eventos	AWS/GCP/Azure, proveedor principal de base de datos, proveedor de identidad, procesador de pagos
Nivel 2 — Significativo	Accede a datos internos sensibles, se integra con sistemas de producción o proporciona servicios comerciales importantes	Debida diligencia estándar: cuestionario de seguridad, revisión de certificaciones, requisitos contractuales de seguridad	Anualmente	Plataformas de CI/CD, herramientas de monitoreo, plataformas de comunicación con integraciones de datos, sistemas de RRHH
Nivel 3 — Bajo	Sin acceso a datos sensibles, sin integración con sistemas de producción, impacto limitado en el negocio	Debida diligencia básica: verificación de estado de certificación, revisión de política de privacidad	Cada 2 años	Herramientas de diseño, gestión de proyectos (sin datos sensibles), suministros de oficina, análisis de marketing

Factores de clasificación a evaluar:

• Acceso a datos: ¿A qué tipos de datos accede el proveedor? ¿Datos de clientes, datos de empleados, datos financieros, propiedad intelectual?
• Procesamiento de datos: ¿El proveedor almacena tus datos, los procesa o simplemente los transita?
• Integración de sistemas: ¿El proveedor está integrado con tu entorno de producción? ¿Puede un compromiso del proveedor alcanzar tus sistemas?
• Criticidad del negocio: ¿Qué sucede si este proveedor deja de estar disponible? ¿Minutos de inactividad o inconveniencia?
• Exposición regulatoria: ¿El acceso del proveedor a datos personales crea obligaciones bajo GDPR u otras regulaciones de privacidad?
• Sustituibilidad: ¿Qué tan rápido podrías cambiar a una alternativa? Los altos costos de cambio aumentan el riesgo de dependencia del proveedor.

Proceso de Debida Diligencia de Proveedores

La debida diligencia es el proceso de evaluar la postura de seguridad de la información de un proveedor antes de establecer una relación y periódicamente después. La profundidad de la debida diligencia debe ser proporcional a la clasificación de nivel del proveedor.

Evaluación Previa al Compromiso

Paso 1: Recopilar documentación de seguridad del proveedor.

Solicita lo siguiente según el nivel del proveedor:

Para proveedores de Nivel 1:

• Certificado ISO 27001 (verifica que el alcance cubra los servicios que utilizarás, verifica el certificado con el organismo de certificación)
• Informe SOC 2 Tipo II (lee el informe completo, no solo la opinión — busca excepciones, opiniones calificadas y controles complementarios de la entidad usuaria)
• Resumen o informe ejecutivo de pruebas de penetración (busca hallazgos críticos y altos y si fueron remediados)
• Cuestionario de seguridad completado (SIG, CAIQ o tu cuestionario personalizado)
• Documentación de continuidad del negocio y recuperación ante desastres
• Documentación de privacidad y procesamiento de datos (DPA, lista de subprocesadores, diagramas de flujo de datos)
• Certificados de seguros (responsabilidad cibernética, indemnización profesional)

Para proveedores de Nivel 2:

• Certificado ISO 27001 o informe SOC 2
• Cuestionario de seguridad completado (versión abreviada aceptable)
• Política de privacidad y términos de procesamiento de datos
• Procedimientos de notificación de incidentes

Para proveedores de Nivel 3:

• Revisión de página pública de seguridad o centro de confianza
• Revisión de política de privacidad
• Cuestionario básico (5-10 preguntas cubriendo cifrado, control de acceso, respuesta a incidentes)

Paso 2: Evaluar la documentación.

No solo marques casillas. Analiza la documentación críticamente:

• Alcance del informe SOC 2: ¿El alcance del informe cubre los servicios específicos que estás utilizando? Una empresa puede tener un informe SOC 2 para un producto pero no para el producto que estás adquiriendo.
• Excepciones y calificaciones: Los informes SOC 2 pueden contener excepciones — instancias donde un control no operó efectivamente. Léelos cuidadosamente y evalúa si afectan tu riesgo.
• Validez del certificado ISO 27001: Verifica la fecha de expiración del certificado y veríficalo con el organismo de certificación emisor. Algunas organizaciones continúan presentando certificados expirados.
• Hallazgos de pruebas de penetración: Enfócate en hallazgos relevantes para los servicios que utilizas. Los hallazgos críticos o altos que permanecen abiertos son indicadores de riesgo significativos.
• Lista de subprocesadores: Identifica los propios terceros del proveedor que pueden acceder a tus datos. Tu riesgo de cuarta parte es parte de tu riesgo de terceros.

Paso 3: Evaluar el riesgo residual.

Después de revisar la documentación, determina si algún riesgo residual requiere controles adicionales, aceptación de riesgo o son factores descalificantes. Documenta tu evaluación de riesgo para cada proveedor de Nivel 1 y Nivel 2 e incorpórala en tu evaluación de riesgos general.

Diseño del Cuestionario de Seguridad

Si utilizas un cuestionario de seguridad personalizado (en lugar de o además de marcos estándar como SIG o CAIQ), enfócate en preguntas que produzcan respuestas accionables:

Gestión de identidad y acceso:

• ¿Cómo controla el proveedor el acceso a tus datos? ¿Qué mecanismos de autenticación se utilizan?
• ¿El proveedor aplica MFA para todo acceso a sistemas que procesan tus datos?
• ¿Cómo se revisan y revocan los derechos de acceso para empleados terminados?

Protección de datos:

• ¿Cómo se cifran tus datos en reposo y en tránsito? ¿Qué estándares de cifrado y longitudes de clave se utilizan?
• ¿Dónde se almacenan tus datos geográficamente? ¿El proveedor utiliza subprocesadores en jurisdicciones fuera de tu lista aprobada?
• ¿Cuál es la política de retención de datos del proveedor? ¿Cómo se eliminan tus datos al finalizar el contrato?

Gestión de incidentes:

• ¿Cuál es el plazo de notificación de incidentes del proveedor? (Busca compromisos específicos — “prontamente” no es un plazo)
• ¿El proveedor realiza revisiones posteriores a incidentes y comparte hallazgos relevantes con los clientes afectados?
• ¿El proveedor ha experimentado algún incidente de seguridad en los últimos 24 meses?

Continuidad del negocio:

• ¿Cuáles son los objetivos de tiempo de recuperación y punto de recuperación del proveedor?
• ¿El proveedor prueba sus procedimientos de recuperación ante desastres? ¿Con qué frecuencia?
• ¿Cuál es el historial de tiempo de actividad del proveedor y su SLA?

Madurez del programa de seguridad:

• ¿El proveedor cuenta con certificación ISO 27001 o atestación SOC 2?
• ¿El proveedor realiza pruebas de penetración regularmente? ¿Por quién?
• ¿El proveedor tiene un programa de divulgación de vulnerabilidades?

Requisitos Contractuales de Seguridad

El control A.5.20 requiere que los requisitos de seguridad de la información se acuerden formalmente en los contratos con proveedores. Estos requisitos protegen a tu organización legal y operativamente cuando las relaciones con proveedores no salen según lo planeado.

Cláusulas Contractuales Esenciales

Términos de procesamiento de datos. Define exactamente qué datos accederá el proveedor, cómo puede procesarlos, dónde puede almacenarlos y por cuánto tiempo. Si se involucran datos personales, se requiere un Acuerdo de Procesamiento de Datos formal bajo GDPR (consulta nuestra guía de DPA para GDPR).

Requisitos de seguridad. Especifica los controles mínimos de seguridad que el proveedor debe mantener:

• Estándares de cifrado (TLS 1.2+ en tránsito, AES-256 en reposo)
• Requisitos de control de acceso (MFA, acceso basado en roles, gestión de acceso privilegiado)
• Obligaciones de registro y monitoreo
• Expectativas de gestión de vulnerabilidades (SLAs de parcheo, frecuencia de pruebas de penetración)
• Requisitos de verificación de antecedentes para personal con acceso a tus datos

Notificación de incidentes. Requiere que el proveedor te notifique de incidentes de seguridad que afecten tus datos dentro de un plazo definido. Para proveedores que procesan datos personales sujetos a GDPR, esto debe ser lo suficientemente rápido para permitirte cumplir con tu propia obligación de notificación de 72 horas. Un estándar común es requerir notificación dentro de 24-48 horas. Incluye requisitos para el contenido de la notificación: qué sucedió, qué datos fueron afectados, qué está haciendo el proveedor al respecto y la información de contacto de su equipo de incidentes.

Derechos de auditoría. Reserva el derecho de auditar el cumplimiento del proveedor con los requisitos de seguridad acordados, ya sea directamente o a través de un tercero independiente. Para proveedores de Nivel 1, esta cláusula es innegociable. En la práctica, la mayoría de las empresas SaaS ejercen los derechos de auditoría a través de revisiones de informes SOC 2 en lugar de auditorías presenciales, pero tener el derecho contractual te permite realizar una auditoría directa si el informe SOC 2 genera preocupaciones.

Gestión de subprocesadores. Requiere que el proveedor te notifique antes de contratar nuevos subprocesadores que accederán a tus datos. Define tu derecho a objetar los cambios de subprocesadores. Esto es particularmente importante bajo GDPR, donde necesitas mantener una imagen precisa de todas las entidades que procesan datos personales en tu nombre.

Devolución y destrucción de datos. Al finalizar el contrato, el proveedor debe devolver todos tus datos en un formato utilizable y certificar que todas las copias han sido destruidas de manera segura. Define el plazo para la devolución y destrucción (30 días es común) y el método de certificación de destrucción (atestación escrita de un funcionario autorizado, certificado de destrucción).

Obligaciones de cumplimiento. Requiere que el proveedor mantenga las certificaciones relevantes (ISO 27001, SOC 2) durante la vigencia del acuerdo y que te notifique si su certificación caduca o si reciben opiniones de auditoría calificadas.

Responsabilidad e indemnización. Define la responsabilidad del proveedor en caso de una brecha de seguridad causada por su incumplimiento de los requisitos de seguridad acordados. Incluye indemnización por multas regulatorias, costos de notificación y reclamaciones de clientes resultantes de brechas del proveedor.

Evaluación de Proveedores en la Nube y el Modelo de Responsabilidad Compartida

El control A.5.23 aborda específicamente los servicios en la nube, reconociendo que las relaciones con proveedores de la nube son fundamentalmente diferentes de las relaciones tradicionales con proveedores debido al modelo de responsabilidad compartida.

Entendiendo la Responsabilidad Compartida

En un entorno en la nube, la seguridad se divide entre el proveedor de la nube y el cliente. La división exacta depende del modelo de servicio:

Infraestructura como Servicio (IaaS) — AWS EC2, GCP Compute Engine, Azure VMs:

• Responsabilidad del proveedor: Seguridad física, hipervisor, infraestructura de red, infraestructura de almacenamiento
• Tu responsabilidad: Parcheo del sistema operativo, seguridad de la aplicación, cifrado de datos, gestión de acceso, configuración de red, registro, monitoreo

Plataforma como Servicio (PaaS) — AWS RDS, Google App Engine, Azure App Service:

• Responsabilidad del proveedor: Todo en IaaS más sistema operativo, entorno de ejecución y middleware
• Tu responsabilidad: Código de aplicación, datos, gestión de acceso, cifrado a nivel de aplicación, monitoreo

Software como Servicio (SaaS) — Salesforce, Slack, Datadog:

• Responsabilidad del proveedor: Casi todo — infraestructura, plataforma, aplicación, seguridad física
• Tu responsabilidad: Clasificación de datos, gestión de acceso (aprovisionamiento/desaprovisionamiento de usuarios, aplicación de MFA), configuraciones, seguridad de integraciones

Evaluando Proveedores en la Nube

Para proveedores de IaaS y PaaS (tus proveedores de Nivel 1), la evaluación se enfoca en:

Certificaciones y atestaciones. Los principales proveedores de la nube mantienen portafolios de certificaciones integrales. Verifica que los servicios y regiones específicos que utilizas estén dentro del alcance de sus certificaciones. El certificado ISO 27001 de AWS, por ejemplo, cubre servicios específicos listados en el alcance — verifica que tus servicios estén incluidos.

Documentación de responsabilidad compartida. Revisa la documentación del modelo de responsabilidad compartida del proveedor para entender exactamente qué aseguran ellos y qué debes asegurar tú. Mapea esto contra tus requisitos de control para asegurar que no existan brechas.

Controles Complementarios de la Entidad Usuaria (CUECs) / Controles Complementarios de la Organización de Subservicios (CSOCs). Los informes SOC 2 de proveedores de la nube listan los controles que esperan que implementes de tu lado. Si confías en AWS pero no has implementado sus CUECs sobre gestión de claves de cifrado, seguridad de red y controles de acceso, existe una brecha en tu entorno de control que tu auditor identificará.

Residencia y soberanía de datos. Verifica que el proveedor pueda cumplir con tus requisitos de residencia de datos. Si te has comprometido a almacenar datos de clientes de la UE en la UE, confirma que las regiones y servicios específicos de la nube que utilizas cumplen. Ten en cuenta la replicación de datos, las ubicaciones de almacenamiento de respaldos y el acceso de soporte que puede cruzar fronteras geográficas.

Estrategia de salida. El control A.5.23 requiere planificación de salida. Evalúa la viabilidad de migrar fuera del proveedor de la nube: formatos de exportación de datos, compatibilidad de API, términos contractuales para la recuperación de datos y el plazo para la eliminación de datos posterior a la terminación. La dependencia del proveedor es un riesgo que debe gestionarse.

Monitoreo y Revisión Continuos

El control A.5.22 requiere monitoreo continuo — la gestión de proveedores no termina después de firmar el contrato. Tu programa de monitoreo debe rastrear la postura de seguridad del proveedor, el rendimiento del servicio y los cambios que afectan tu perfil de riesgo.

Actividades de Monitoreo Continuo

Seguimiento de certificaciones e informes. Rastrea las fechas de expiración del certificado ISO 27001 y el período de observación del informe SOC 2 de cada proveedor. Solicita informes actualizados antes de que expiren. Un proveedor cuyo informe SOC 2 expiró hace seis meses y que no ha producido uno nuevo es un indicador de riesgo que requiere investigación.

Monitoreo de avisos de seguridad. Monitorea los avisos de seguridad del proveedor, las notificaciones de brechas y las divulgaciones de vulnerabilidades. Muchos proveedores publican avisos de seguridad a través de listas de correo electrónico, páginas de estado o portales de confianza. Suscríbete a estos canales para todos los proveedores de Nivel 1 y Nivel 2.

Notificaciones de cambio de subprocesadores. Rastrea los cambios en las listas de subprocesadores del proveedor. Bajo GDPR, los procesadores deben informarte de nuevos subprocesadores antes de contratarlos. Bajo ISO 27001, los cambios en los subprocesadores pueden afectar tu perfil de riesgo y requerir reevaluación.

Seguimiento de rendimiento y disponibilidad. Monitorea el tiempo de actividad, los tiempos de respuesta y el cumplimiento del SLA del proveedor. La degradación persistente del rendimiento puede indicar problemas subyacentes de seguridad u operacionales.

Noticias e inteligencia de amenazas. Monitorea fuentes de noticias de seguridad y feeds de inteligencia de amenazas para informes de brechas, vulnerabilidades u otros eventos de seguridad que afecten a tus proveedores. Puedes enterarte de un compromiso del proveedor a través de informes públicos antes de que el proveedor te notifique formalmente.

Proceso de Revisión Periódica

Revisión anual de proveedores (Nivel 1). Realiza una revisión anual integral de cada proveedor de Nivel 1:

• Solicita y revisa el informe actualizado SOC 2 Tipo II o los resultados de la auditoría de vigilancia ISO 27001
• Revisa cualquier incidente de seguridad que el proveedor haya reportado durante el año
• Reevalúa la clasificación de riesgo del proveedor basándote en cualquier cambio en la relación
• Revisa los términos contractuales para su adecuación (requisitos de seguridad, plazos de notificación, derechos de auditoría)
• Verifica que tus controles complementarios sigan siendo efectivos
• Actualiza tu registro de riesgos con cualquier cambio en los riesgos relacionados con proveedores

Revisión anual de proveedores (Nivel 2). Realiza una revisión más ligera de los proveedores de Nivel 2:

• Verifica el estado de certificación
• Revisa cualquier incidente reportado
• Confirma que las actividades de procesamiento de datos no han cambiado materialmente
• Actualiza la clasificación de riesgo si es necesario

Revisión bienal de proveedores (Nivel 3). Revisa los proveedores de Nivel 3 cada dos años:

• Verifica que el proveedor sigue siendo apropiado para el servicio proporcionado
• Comprueba si ha habido eventos de seguridad significativos
• Confirma que la relación no se ha expandido en alcance (lo que podría justificar una reclasificación)

Manejo de Cambios de Riesgo del Proveedor

Cuando el monitoreo revela un cambio en el riesgo del proveedor, necesitas un proceso de respuesta definido:

El proveedor reporta un incidente de seguridad. Activa tus propios procedimientos de gestión de incidentes. Evalúa si tus datos fueron afectados. Determina si el incidente del proveedor activa tus propias obligaciones de notificación. Solicita un informe posterior al incidente del proveedor y evalúa si tu evaluación de riesgos y controles necesitan actualización.

Caducidad de certificación del proveedor. Un certificado ISO 27001 caducado o un informe SOC 2 vencido es un indicador de riesgo significativo. Contacta al proveedor para entender por qué. Solicita evidencia alternativa de su postura de seguridad (prueba de penetración reciente, actualización de cuestionario de seguridad). Escala internamente y considera si se necesitan controles compensatorios mientras persiste la brecha de certificación.

Cambio de subprocesador del proveedor. Evalúa al nuevo subprocesador contra tus requisitos de seguridad. Evalúa si el cambio introduce nuevos riesgos (nueva jurisdicción, nuevo acceso a datos, postura de seguridad diferente). Ejerce tu derecho a objetar si el cambio es inaceptable.

Adquisición o cambio material del negocio del proveedor. Cuando un proveedor es adquirido, su postura de seguridad puede cambiar. Reevalúa la relación, revisa los términos y certificaciones actualizados y determina si la entidad adquirente cumple con tus requisitos.

Manejo de Incidentes del Proveedor

Cuando un proveedor experimenta un incidente de seguridad que puede afectar a tu organización, tu respuesta debe coordinarse con la respuesta del proveedor.

Recepción de notificación de incidente del proveedor. Cuando recibes una notificación de incidente de un proveedor:

1. Registra la notificación con marca de tiempo, fuente y contenido
2. Evalúa el impacto potencial en tus datos y sistemas
3. Determina si se deben activar tus propios procedimientos de respuesta a incidentes
4. Identifica si el incidente del proveedor activa tus obligaciones de notificación a clientes o reguladores
5. Solicita actualizaciones regulares del proveedor sobre el progreso de la investigación y la remediación

Tus responsabilidades durante un incidente del proveedor:

• Implementa las mitigaciones recomendadas (rotación de credenciales, restricción de acceso, monitoreo mejorado)
• Evalúa el radio de impacto dentro de tu propio entorno
• Preserva registros y evidencia relevantes de tus sistemas que puedan ayudar en la investigación
• Coordina las comunicaciones con clientes si los datos de clientes pueden estar afectados
• Rastrea el progreso de remediación del proveedor y verifica que las vulnerabilidades sean abordadas

Revisión posterior al incidente del proveedor. Después de que el incidente del proveedor se resuelva:

• Solicita un informe detallado posterior al incidente del proveedor
• Evalúa si la respuesta del proveedor fue adecuada
• Reevalúa la clasificación de riesgo del proveedor
• Determina si se necesitan cambios contractuales (requisitos de notificación más estrictos, obligaciones de seguridad adicionales)
• Actualiza tu registro de riesgos y controles basándote en las lecciones aprendidas

Desvinculación del Proveedor y Devolución/Destrucción de Datos

El final de una relación con un proveedor es un período de alto riesgo que muchas organizaciones manejan deficientemente. ISO 27001 requiere que gestiones las salidas de proveedores con el mismo rigor que la incorporación de proveedores.

Proceso de Desvinculación

Paso 1: Inventario y devolución de datos. Antes de terminar la relación:

• Identifica todos los datos en poder del proveedor (datos de producción, respaldos, registros, datos de prueba)
• Solicita la exportación de todos los datos en un formato utilizable y portátil
• Verifica la completitud de los datos devueltos
• Transfiere los datos a tus sistemas o a un proveedor de reemplazo

Paso 2: Revocación de acceso. Inmediatamente al finalizar:

• Revoca el acceso del proveedor a tus sistemas (claves API, cuentas de servicio, acceso VPN, claves SSH)
• Revoca el acceso de tu equipo a los sistemas del proveedor (para prevenir el uso continuado accidental)
• Elimina al proveedor de tus integraciones de SSO/proveedor de identidad
• Actualiza las reglas de firewall y configuraciones de red para bloquear la conectividad del proveedor

Paso 3: Verificación de destrucción de datos.

• Solicita certificación escrita del proveedor de que todas las copias de tus datos han sido destruidas de manera segura
• La certificación debe especificar el método de destrucción, fecha y los conjuntos de datos destruidos
• Para proveedores que procesan datos personales bajo GDPR, la verificación de destrucción de datos es un requisito legal
• Establece un recordatorio de seguimiento para confirmar la destrucción dentro del plazo acordado contractualmente (típicamente 30-90 días)

Paso 4: Actualización de documentación.

• Actualiza tu inventario de proveedores para reflejar la relación terminada
• Actualiza tu registro de riesgos para eliminar o modificar los riesgos relacionados con el proveedor
• Archiva la documentación de seguridad, el contrato y la correspondencia del proveedor para tus registros
• Si el proveedor era un subprocesador listado en tu documentación de procesamiento de datos orientada al cliente, actualiza esos registros

Consideraciones de la Cadena de Suministro SaaS

Las empresas SaaS enfrentan riesgos de cadena de suministro que son distintos de la gestión tradicional de proveedores empresariales. Tu programa ISO 27001 debe tenerlos en cuenta.

Riesgo de Dependencias de Código Abierto

Tu aplicación probablemente depende de cientos o miles de bibliotecas de código abierto. Cada una es parte de tu cadena de suministro y cada una conlleva riesgo.

Análisis de composición de software (SCA). Implementa escaneo automatizado de tus manifiestos de dependencias para identificar vulnerabilidades conocidas, problemas de cumplimiento de licencias y paquetes desactualizados. El SCA debe integrarse en tu pipeline de CI/CD para que las dependencias vulnerables se detecten antes del despliegue.

Fijación de dependencias y verificación de integridad. Fija las versiones de dependencias y verifica la integridad del paquete usando sumas de verificación o firmas. Esto previene ataques donde un actor malicioso publica una versión comprometida de un paquete popular.

Monitoreo de ataques a la cadena de suministro. Suscríbete a avisos de seguridad para tus dependencias críticas. Monitorea informes de paquetes comprometidos, ataques de typosquatting y compromisos de cuentas de mantenedores.

Integraciones SaaS a SaaS

Las arquitecturas SaaS modernas frecuentemente involucran integraciones extensas entre servicios SaaS. Cada integración crea un flujo de datos que debe evaluarse como una relación con un proveedor.

Gestión de tokens OAuth. Las integraciones SaaS típicamente usan tokens OAuth para autenticación. Estos tokens otorgan acceso a tus datos y deben gestionarse como credenciales: inventariados, con alcance mínimo, revisados regularmente y revocados cuando ya no son necesarios.

Mapeo de flujos de datos. Para cada integración SaaS a SaaS, documenta qué datos fluyen entre los servicios, en qué dirección, con qué propósito y qué hace el servicio receptor con ellos. Este mapeo apoya tanto tu cumplimiento de ISO 27001 como tus registros de procesamiento de datos de GDPR.

Revisiones de acceso de integraciones. Revisa periódicamente todas las integraciones SaaS activas. Identifica integraciones que ya no son necesarias, integraciones con permisos excesivos e integraciones conectadas por exempleados cuyas cuentas han sido desaprovisionadas pero cuyas integraciones persisten.

Seguridad de API en las Relaciones con Proveedores

Las APIs son el tejido conectivo de las cadenas de suministro SaaS. Las APIs de proveedores introducen riesgos que deben gestionarse:

Autenticación y autorización de API. Asegura que las integraciones de API de proveedores usen autenticación fuerte (claves API, OAuth, TLS mutuo). Revisa la documentación de seguridad de API del proveedor para limitación de velocidad, validación de entrada y prácticas de control de acceso.

Versionado y deprecación de API. Monitorea los anuncios de versiones de API del proveedor. Las APIs deprecadas pueden recibir menor atención de seguridad. Planifica migraciones a versiones de API soportadas dentro del plazo de deprecación del proveedor.

Minimización de datos en llamadas API. Solicita solo los datos que necesitas de las APIs del proveedor. Las consultas API excesivamente amplias recuperan y transmiten datos innecesariamente, aumentando el impacto de una potencial interceptación o brecha del proveedor.

Construyendo un Programa de Gestión de Proveedores Conforme a ISO 27001: Paso a Paso

Para las empresas SaaS que construyen su programa de gestión de proveedores como parte de la implementación de ISO 27001, aquí hay una hoja de ruta práctica:

Mes 1: Fundamento

• Redacta y aprueba tu política de seguridad de la información para proveedores (A.5.19)
• Define tu marco de estratificación de proveedores
• Comienza el inventario de proveedores analizando registros financieros y registros de SSO

Mes 2: Inventario y Clasificación

• Completa el inventario de proveedores en todos los departamentos
• Clasifica cada proveedor en el nivel apropiado
• Prioriza los proveedores de Nivel 1 para debida diligencia inmediata

Meses 3-4: Debida Diligencia de Nivel 1

• Solicita documentación de seguridad de todos los proveedores de Nivel 1
• Evalúa informes SOC 2, certificados ISO 27001 y respuestas a cuestionarios
• Identifica brechas contractuales e inicia renegociación para cláusulas de seguridad faltantes
• Documenta evaluaciones de riesgo para cada proveedor de Nivel 1

Mes 5: Debida Diligencia de Nivel 2 y Alineación Contractual

• Completa las evaluaciones de proveedores de Nivel 2
• Asegura que todos los contratos de Nivel 1 y Nivel 2 incluyan las cláusulas de seguridad requeridas (A.5.20)
• Ejecuta DPAs donde el procesamiento de datos personales lo requiera

Mes 6: Lanzamiento del Programa de Monitoreo

• Establece seguimiento de certificaciones e informes para todos los proveedores de Nivel 1 y Nivel 2
• Suscríbete a canales de avisos de seguridad para proveedores críticos
• Configura recordatorios de calendario para ciclos de revisión anuales
• Documenta tus procedimientos de monitoreo

Continuo: Operar y Mejorar

• Realiza revisiones anuales de proveedores según tu calendario de estratificación
• Procesa las notificaciones de incidentes de proveedores a través de tus procedimientos de gestión de incidentes
• Gestiona la incorporación y desvinculación de proveedores usando tus procesos definidos
• Reporta el estado de riesgo de proveedores en las revisiones de gestión
• Actualiza tu programa de gestión de proveedores basándote en lecciones aprendidas y hallazgos de auditoría

Este programa debe alinearse con tu lista de verificación de certificación ISO 27001 general y conectarse con tus procesos de evaluación de riesgos y mejora continua.

Errores Comunes en la Gestión de Proveedores de ISO 27001

Sin inventario de proveedores. No puedes gestionar lo que no has identificado. Las organizaciones que omiten el paso del inventario y gestionan solo los proveedores que se les ocurren tendrán brechas. La TI en la sombra — herramientas adoptadas por equipos individuales sin adquisición centralizada — es la fuente más común de riesgo de proveedores no gestionados.

Tratar a todos los proveedores por igual. Aplicar el mismo rigor de debida diligencia a tu proveedor de suministros de oficina que a tu proveedor de infraestructura en la nube desperdicia recursos en proveedores de bajo riesgo mientras potencialmente se subinvierte en los críticos. La estratificación hace que tu programa sea proporcional y sostenible.

Aceptar la autoatestación como debida diligencia. Que un proveedor te diga que es seguro no es evidencia de que lo sea. Requiere evidencia independiente: certificados ISO 27001 emitidos por organismos de certificación acreditados, informes SOC 2 de firmas de auditoría calificadas, informes de pruebas de penetración de evaluadores reputados. Los cuestionarios de seguridad autocompletados complementan pero no reemplazan la atestación independiente.

Contratos sin cláusulas de seguridad. Si tu contrato con un proveedor crítico no incluye requisitos de seguridad, obligaciones de notificación de incidentes y derechos de auditoría, no tienes base contractual para responsabilizarlos cuando algo sale mal. Incluir cláusulas de seguridad retroactivamente en contratos existentes es difícil — inclúyelas desde el principio.

Debida diligencia única sin monitoreo continuo. Un proveedor que pasó tu evaluación hace dos años puede no cumplir tus requisitos hoy. Las personas cambian, las arquitecturas cambian, la propiedad cambia. El monitoreo continuo (A.5.22) no es opcional — es un requisito de control separado y explícito.

Ignorar el modelo de responsabilidad compartida. Las empresas SaaS que asumen que su proveedor de la nube maneja toda la seguridad están creando brechas críticas. Tu proveedor de la nube asegura su infraestructura. Tú debes asegurar tu configuración, tu gestión de acceso, tus datos y tus aplicaciones. No implementar tus controles complementarios es un hallazgo en tu auditoría ISO 27001 y una vulnerabilidad real de seguridad.

Sin proceso de desvinculación. Proveedores con acceso persistente después de la terminación del contrato son un riesgo de seguridad. Datos que no se confirma que fueron destruidos después de que termina una relación son un riesgo de cumplimiento. Define y ejecuta un proceso de desvinculación para cada relación con proveedores que termine.

No monitorear integraciones SaaS a SaaS. Los tokens OAuth e integraciones API creadas entre servicios SaaS son relaciones con proveedores que muchas organizaciones no logran inventariar y gestionar. Una integración no utilizada con permisos amplios es una superficie de ataque esperando ser explotada.

Cómo Ayuda GRCTrail

GRCTrail proporciona a las empresas SaaS un programa estructurado de gestión de proveedores que satisface los controles A.5.19-A.5.23 del Annex A de ISO 27001 mientras hace que la supervisión continua de proveedores sea manejable a escala.

• Registro centralizado de proveedores con estratificación que inventaría cada vendedor, los clasifica por nivel de riesgo, rastrea su documentación de seguridad (certificados ISO 27001, informes SOC 2, respuestas a cuestionarios) y te alerta cuando las certificaciones o informes se acercan a su vencimiento
• Automatización del flujo de trabajo de debida diligencia que guía a tu equipo a través del proceso de evaluación para cada nivel de proveedor, rastrea la recopilación de documentos y registra las decisiones de evaluación de riesgos en un formato auditable que tu organismo de certificación puede revisar
• Paneles de monitoreo continuo con recordatorios automatizados para revisiones anuales, seguimiento de cambios de subprocesadores e integración con tu registro de riesgos para que los cambios de riesgo de proveedores fluyan directamente a la revisión de gestión de tu ISMS

Comienza con GRCTrail

Guías Relacionadas

• ¿Qué es ISO 27001? Una Guía Completa para Empresas SaaS
• Evaluación de Riesgos ISO 27001: Marco y Proceso
• Controles del Annex A de ISO 27001: Guía Completa
• Lista de Verificación de Certificación ISO 27001
• Gestión de Proveedores SOC 2: Requisitos de Riesgo de Terceros
• Acuerdos de Procesamiento de Datos GDPR: Una Guía Completa
• Políticas de ISO 27001: Lo Que Necesitas Documentar