Gestión de proveedores SOC 2: requisitos de riesgo de terceros
SOC 2 requiere que gestione el riesgo de terceros. Esta guía cubre la evaluación de proveedores, el monitoreo continuo, los requisitos contractuales y cómo manejar las organizaciones de sub-servicios en su informe SOC 2.
GRCTrail Team
Su informe SOC 2 es tan fuerte como su proveedor más débil. Toda empresa SaaS depende de terceros — proveedores de infraestructura en la nube, procesadores de pagos, servicios de autenticación, herramientas de monitoreo, plataformas de RRHH. SOC 2 requiere explícitamente que identifique, evalúe y monitoree estas relaciones porque una falla de seguridad de un proveedor puede convertirse en su falla de seguridad.
Esto no es teórico. Cuando una empresa SaaS sufre una brecha a través de un proveedor comprometido, la credibilidad de su informe SOC 2 está en juego. Los auditores lo saben, por eso la gestión de riesgos de terceros es una de las áreas de control más exhaustivamente probadas en un compromiso SOC 2. Si no puede demostrar que gestiona el riesgo de proveedores de manera sistemática, tendrá hallazgos en su informe.
Esta guía cubre los requisitos de SOC 2 para la gestión de proveedores, cómo construir un programa que satisfaga a los auditores y los errores específicos que hacen tropezar a las empresas SaaS.
SOC 2 y las organizaciones de sub-servicios
SOC 2 utiliza terminología precisa. Lo que usted llama “proveedores” o “terceros,” el AICPA llama “organizaciones de sub-servicios” — específicamente, entidades que proporcionan servicios que forman parte de su sistema y son relevantes para el alcance de su informe SOC 2.
No todo proveedor es una organización de sub-servicio. Su proveedor de café de oficina no influye en su alcance SOC 2. Pero AWS, donde ejecuta su entorno de producción, sí es una organización de sub-servicio. Stripe, que procesa los pagos de sus clientes, es una organización de sub-servicio. Okta, que maneja su autenticación, es una organización de sub-servicio.
La distinción importa porque SOC 2 requiere que aborde las organizaciones de sub-servicios en la descripción de su sistema, y tiene dos métodos para hacerlo.
El método inclusivo
Qué significa: Los controles de la organización de sub-servicio se incluyen en el alcance de su informe SOC 2. Su auditor examina tanto sus controles como los controles del proveedor como parte de un solo compromiso.
En la práctica: Esto es raro y complejo. Requiere la cooperación total del proveedor, el acceso de su auditor a los sistemas del proveedor y una coordinación significativa. La mayoría de las empresas SaaS nunca usan el método inclusivo porque proveedores importantes como AWS y Stripe no van a conceder a su auditor acceso directo a su infraestructura.
El método de exclusión (carve-out)
Qué significa: Los controles de la organización de sub-servicio se excluyen del alcance de su informe SOC 2, pero el informe reconoce la dependencia y hace referencia al propio informe SOC 2 del proveedor. Usted confía en la atestación SOC 2 independiente del proveedor para cubrir sus controles.
En la práctica: Este es el enfoque estándar para empresas SaaS. Identifica a AWS como una organización de sub-servicio, la excluye de su alcance y hace referencia al propio informe SOC 2 Type II de AWS como evidencia de que sus controles son adecuados. La descripción de su sistema establece explícitamente qué controles son su responsabilidad y cuáles son del proveedor.
La descripción de su sistema debe identificar claramente todas las organizaciones de sub-servicios e indicar qué método está utilizando para cada una. Los auditores verificarán que esta sección sea precisa y completa.
Common Criteria relevantes
La gestión de proveedores abarca varias áreas de los Common Criteria de SOC 2. Comprender qué criterios se aplican le ayuda a construir un programa que se mapee directamente a lo que prueban los auditores.
CC2.3 — Comunicación con partes externas. Su organización debe comunicarse con partes externas — incluyendo proveedores — sobre asuntos que afectan el funcionamiento de los controles internos. Esto incluye requisitos de seguridad, expectativas de notificación de incidentes y cambios que afectan la prestación del servicio.
CC3.1 a CC3.4 — Evaluación de riesgos. Su proceso de evaluación de riesgos debe considerar los riesgos derivados de las relaciones con terceros. El riesgo de proveedores no está separado del riesgo organizacional — es un componente del mismo. Su registro de riesgos debe incluir riesgos relacionados con proveedores y sus planes de tratamiento de riesgos deben abordarlos.
CC9.2 — Mitigación de riesgos. Este criterio aborda específicamente el riesgo de proveedores y socios comerciales. Debe evaluar y gestionar los riesgos asociados con los proveedores que brindan servicios que son parte de su sistema. Esto incluye evaluación continua, no solo debida diligencia inicial.
Juntos, estos criterios crean un mandato claro: identifique a sus proveedores, evalúe su riesgo, comunique sus expectativas y monitoréelos a lo largo del tiempo.
Construcción de un programa de gestión de proveedores
Un programa de gestión de proveedores que cumpla con SOC 2 tiene cuatro fases: inventario, debida diligencia, alineación contractual y monitoreo continuo. Cada fase produce evidencia que los auditores examinarán.
Paso 1: Inventario de proveedores
No puede gestionar lo que no ha identificado. Comience con un inventario completo de cada proveedor que interactúe con sus sistemas o datos.
Cómo construirlo: Trabaje con ingeniería, TI, finanzas y líderes de departamento para catalogar cada herramienta, servicio y plataforma que su organización utiliza. Los registros financieros (facturas, suscripciones) son la fuente más confiable — revelan proveedores que los equipos individuales adoptaron sin adquisición centralizada.
Clasifique por nivel de riesgo. No todos los proveedores conllevan el mismo riesgo. Asigne niveles de riesgo según el acceso a datos, la criticidad del sistema y el impacto comercial:
- Crítico: Proveedores que alojan su infraestructura de producción, procesan datos de clientes o causarían una interrupción significativa del negocio si no estuvieran disponibles (AWS, GCP, su proveedor de base de datos principal)
- Alto: Proveedores que acceden a datos sensibles o proporcionan servicios críticos de seguridad (proveedores de identidad, herramientas de monitoreo, procesadores de pagos)
- Medio: Proveedores que acceden a datos internos pero no a datos de clientes (plataformas de RRHH, herramientas de comunicación interna, software de gestión de proyectos)
- Bajo: Proveedores sin acceso a datos e interacción mínima con el sistema (suministros de oficina, herramientas de diseño sin integración de datos)
Categorías comunes de proveedores SaaS para inventariar:
- Infraestructura en la nube: AWS, GCP, Azure
- Gestión de identidad y acceso: Okta, Auth0, Google Workspace
- Control de código fuente y CI/CD: GitHub, GitLab, CircleCI
- Monitoreo y registro: Datadog, PagerDuty, Splunk
- Comunicación: Slack, Microsoft Teams
- Procesamiento de datos de clientes: Stripe, Segment, Twilio
- RRHH y operaciones de personas: Rippling, Gusto, BambooHR
- Herramientas de seguridad: CrowdStrike, SentinelOne, Snyk
La TI en las sombras (shadow IT) es la mayor brecha en la mayoría de los inventarios de proveedores. Los equipos de ingeniería habilitan herramientas SaaS con una tarjeta de crédito y nunca informan a seguridad. La conciliación financiera detecta estas, pero también debe ejecutar escaneos de descubrimiento periódicos de logs de SSO, extensiones de navegador y concesiones de aplicaciones OAuth para encontrar herramientas no autorizadas.
Paso 2: Debida diligencia de proveedores
Una vez que haya inventariado sus proveedores, necesita evaluar la postura de seguridad de cada uno. La profundidad de la debida diligencia debe corresponder al nivel de riesgo del proveedor.
Para proveedores de riesgo crítico y alto:
- Solicite su informe SOC 2 Type II. Este es el estándar de oro. Un informe SOC 2 Type II vigente significa que un auditor independiente ha evaluado los controles del proveedor durante un período de tiempo. Type II se prefiere sobre Type I porque demuestra eficacia operativa sostenida, no solo diseño en un momento específico.
- Revise el informe a fondo. No solo confirme que existe. Lea la opinión del auditor, verifique si hay salvedades o excepciones, revise las descripciones de controles y — de manera crítica — lea los Controles Complementarios de la Entidad Usuaria (CUECs). Los CUECs son controles que el proveedor espera que usted implemente. Si AWS dice que el cifrado es responsabilidad del cliente, eso es un CUEC, y su auditor verificará si usted lo ha implementado.
- Evalúe cuestionarios de seguridad. Para proveedores sin informes SOC 2, utilice cuestionarios estandarizados como SIG (Standard Information Gathering), CAIQ (Consensus Assessments Initiative Questionnaire) o su propio cuestionario personalizado que cubra cifrado, controles de acceso, respuesta a incidentes y manejo de datos.
- Revise sub-encargados. Los proveedores de sus proveedores también importan. Verifique si el proveedor divulga sus sub-encargados y cómo gestiona el riesgo de sub-encargados. Esto es especialmente relevante si también está sujeto al RGPD, que tiene requisitos explícitos sobre sub-encargados.
- Evalúe la continuidad del negocio. Comprenda las capacidades de recuperación ante desastres del proveedor, sus compromisos de SLA y su historial de tiempo de actividad. Un proveedor crítico sin DR adecuado pone en riesgo su disponibilidad.
Para proveedores de riesgo medio:
- Solicite un informe SOC 2 o certificado ISO 27001
- Envíe un cuestionario de seguridad
- Revise su página pública de seguridad y su política de privacidad
Para proveedores de riesgo bajo:
- Confirme las prácticas básicas de seguridad (HTTPS, autenticación)
- Documente la justificación de aceptación de riesgo para una debida diligencia reducida
Documente cada evaluación. Los auditores necesitan ver que usted realizó debida diligencia para cada proveedor en el alcance, y la profundidad de la evaluación debe corresponder a la clasificación de riesgo.
Paso 3: Requisitos contractuales
La debida diligencia evalúa la postura de seguridad actual de un proveedor. Los contratos aplican obligaciones continuas. Sus acuerdos con proveedores deben incluir disposiciones específicas de seguridad y cumplimiento.
Requisitos de seguridad. Los contratos con proveedores de riesgo crítico y alto deben especificar expectativas de seguridad: estándares de cifrado, requisitos de control de acceso, obligaciones de gestión de vulnerabilidades y cumplimiento con marcos relevantes.
Acuerdos de Tratamiento de Datos. Si el proveedor procesa datos personales — especialmente si tiene clientes en la UE — necesita un Acuerdo de Tratamiento de Datos (DPA). Esto es tanto una buena práctica de SOC 2 como un requisito del RGPD. Los DPA deben especificar los fines del tratamiento de datos, las medidas de seguridad, las restricciones de sub-encargados y las obligaciones de eliminación de datos.
Derecho de auditoría. Incluya disposiciones contractuales que le otorguen el derecho de auditar las prácticas de seguridad del proveedor o solicitar evidencia de cumplimiento. Para proveedores grandes (AWS, Google), su informe SOC 2 cumple este propósito. Para proveedores más pequeños, puede necesitar la capacidad de realizar evaluaciones directas.
Notificación de incidentes. Requiera que los proveedores le notifiquen sobre incidentes de seguridad dentro de un plazo definido — 24 a 72 horas es estándar para proveedores críticos. Especifique qué constituye un incidente reportable y el método de notificación.
Manejo y eliminación de datos. Defina cómo el proveedor almacena, procesa y finalmente elimina sus datos. Incluya límites de retención y requiera confirmación de la eliminación de datos al terminar el contrato. Esto es particularmente importante para proveedores que procesan datos de clientes.
Paso 4: Monitoreo continuo
La debida diligencia inicial no es suficiente. SOC 2 requiere monitoreo continuo de sus relaciones con proveedores, y los auditores verificarán si realmente realizó actividades de monitoreo durante el período de observación.
Revisión anual de informes SOC 2. Para proveedores de riesgo crítico y alto con informes SOC 2, revise el informe actualizado anualmente cuando se publique. Verifique nuevas excepciones, cambios en el alcance o CUECs modificados. Documente la revisión con el nombre del revisor, la fecha y los hallazgos.
Rastreo de incidentes de seguridad de proveedores. Monitoree las divulgaciones públicas de brechas o incidentes de seguridad de proveedores. Suscríbase a los boletines de seguridad y páginas de estado de los proveedores. Cuando un proveedor tenga un incidente, documente su evaluación del impacto en sus sistemas y datos.
Monitoreo de cambios materiales. Esté atento a adquisiciones de proveedores, cambios de liderazgo, adiciones de sub-encargados y cambios significativos en el servicio. Cualquiera de estos puede afectar el perfil de riesgo del proveedor y puede requerir una reevaluación.
Reevaluación periódica. Reevalúe los proveedores según su nivel de riesgo:
- Crítico: Revisión exhaustiva anual con informe SOC 2 actualizado, revisión de contrato y verificación de sub-encargados
- Alto: Revisión anual del informe SOC 2 y actualización del cuestionario
- Medio: Revisión bienal o activada por cambios materiales
- Bajo: Revisión solo cuando se active por cambios o incidentes
Lo que prueban los auditores
Durante un compromiso SOC 2, su auditor examinará la gestión de proveedores en varias dimensiones. Saber lo que prueban le ayuda a prepararse.
Completitud del inventario de proveedores. Los auditores compararán su inventario de proveedores contra otras fuentes de evidencia — registros financieros, configuraciones del sistema, logs de SSO — para verificar que ha identificado todos los proveedores relevantes. Omitir un proveedor crítico es un hallazgo significativo.
Evidencia de debida diligencia. Para proveedores críticos, los auditores esperan ver evaluaciones documentadas: revisiones de informes SOC 2 con notas, cuestionarios de seguridad completados y justificaciones de clasificación de riesgo. Un proveedor clasificado como crítico sin registro de debida diligencia es una falla de control.
Revisiones de informes SOC 2. Los auditores verificarán que usted realmente leyó los informes SOC 2 de los proveedores — no solo los recopiló. Preguntarán quién revisó el informe, cuándo, cuáles fueron las conclusiones y si se evaluaron los CUECs. Almacenar un PDF que nunca abrió no satisface el requisito.
Acuerdos contractuales. Los auditores muestrearán contratos de proveedores y verificarán las disposiciones de seguridad, DPAs y cláusulas de notificación de incidentes. Esto es especialmente minucioso para proveedores que procesan datos de clientes.
Actividades de monitoreo. Para informes Type II, los auditores necesitan evidencia de monitoreo continuo durante todo el período de observación. Una revisión anual que ocurrió en el mes uno sin seguimiento durante los once meses restantes puede ser insuficiente dependiendo del nivel de riesgo del proveedor y los compromisos de su política.
Errores comunes
Las empresas SaaS tropiezan consistentemente en las mismas áreas de gestión de proveedores. Conocer estos errores le ayuda a evitarlos.
No rastrear todos los proveedores. La TI en las sombras es el mayor infractor. Los equipos de ingeniería adoptan herramientas SaaS, las conectan vía OAuth y nunca involucran a seguridad. Estas herramientas pueden acceder a código fuente, datos de clientes o comunicaciones internas — y son invisibles para su programa de gestión de proveedores. Las auditorías regulares de concesiones OAuth y las revisiones de logs de SSO detectan la mayoría de estos.
Aceptar SOC 2 Type I cuando Type II está disponible. Un informe Type I es una instantánea en el tiempo — le dice que los controles estaban diseñados correctamente en una fecha única. Un informe Type II demuestra que esos controles operaron eficazmente durante meses. Si un proveedor tiene un Type II disponible, siempre solicítelo. Conformarse con Type I cuando existe Type II señala a los auditores que su proceso de debida diligencia no es exhaustivo.
No revisar los Controles Complementarios de la Entidad Usuaria. Los CUECs son los controles que un proveedor espera que usted implemente de su lado. El informe SOC 2 de AWS, por ejemplo, enumera CUECs sobre gestión de claves de cifrado, seguridad de red y controles de acceso. Si usted depende de AWS pero no ha implementado sus CUECs, hay una brecha en su entorno de control que los auditores identificarán.
Proveedores faltantes añadidos a mitad del período de auditoría. Si incorpora un nuevo proveedor crítico durante su período de observación, ese proveedor necesita pasar por su proceso de debida diligencia y aparecer en su inventario. Los auditores observan todo el período de observación, no solo una instantánea al final.
Sin proceso para la desvinculación de proveedores. Cuando deja de usar un proveedor, necesita revocar su acceso, confirmar la eliminación de datos y actualizar su inventario de proveedores. Los proveedores con acceso persistente a sus sistemas después de la terminación del contrato son un riesgo de seguridad y un hallazgo de auditoría.
Tratar la gestión de proveedores como un proyecto anual. La gestión de proveedores es continua. Si todo su programa consiste en una carrera de revisión una vez al año antes de la temporada de auditoría, tendrá brechas. Los cambios materiales de proveedores, la incorporación de nuevos proveedores y el monitoreo de incidentes deben ocurrir en tiempo real durante todo el año. Vincular la gestión de proveedores a su programa de monitoreo continuo hace que esto sea sostenible.
Cómo ayuda GRCTrail
GRCTrail ofrece a los equipos SaaS un programa estructurado y auditable de gestión de proveedores que satisface los requisitos de SOC 2 sin hojas de cálculo dispersas.
- Registro de proveedores centralizado con clasificación de riesgo, para que cada proveedor esté inventariado, categorizado y rastreable en un solo lugar
- Recopilación y seguimiento de revisión de informes SOC 2 que registra quién revisó el informe de cada proveedor, cuándo y qué encontró — proporcionando a los auditores la pista de evidencia que necesitan
- Recordatorios automatizados para revisiones anuales activados por el nivel de riesgo del proveedor, para que las revisiones de proveedores críticos nunca se pasen de la fecha límite
- Gestión de contratos y DPA vinculada a cada registro de proveedor, facilitando la verificación de que las disposiciones contractuales están implementadas para cada relación en el alcance
- Monitoreo de cambios de sub-encargados que le alerta cuando los proveedores actualizan sus listas de sub-encargados, para que pueda reevaluar el riesgo antes de que su auditor pregunte al respecto
Guías relacionadas
Artículos relacionados
El proceso de auditoría SOC 2: cronograma, pasos y qué esperar
Un recorrido paso a paso por el proceso de auditoría SOC 2, desde la selección del auditor hasta la recepción de su informe. Cubre cronogramas, preparación y lo que evalúan los auditores.
Controles Common Criteria (CC) de SOC 2 explicados
Un desglose detallado de las nueve categorías de Common Criteria de SOC 2 (CC1-CC9), qué requiere cada una y cómo las empresas SaaS deben implementar controles para cada categoría.
Lista de verificación de cumplimiento SOC 2 para empresas SaaS
Una lista de verificación completa de cumplimiento SOC 2 que cubre cada paso desde el alcance hasta la finalización de la auditoría. Diseñada para equipos SaaS que preparan su primer o próximo informe SOC 2.