Español

Revisión de seguridad y cumplimiento para compradores de SaaS de mercado medio

El equipo legal entregó el informe SOC 2 a IT, IT confirmó que la insignia estaba vigente, y adquisición marcó la revisión de seguridad como completada. Procedimiento estándar. El vendor era una empresa de Serie B bien financiada con una página de seguridad de aspecto razonable y una lista de logos de clientes reconocibles.

Once meses después, un exploit de día cero en el middleware de API del vendor expuso 40.000 registros de clientes. El SOC 2 había cubierto los controles de acceso del vendor, los procedimientos de gestión de cambios y el monitoreo de disponibilidad. No había cubierto el componente de terceros específico que falló. Y como el contrato contenía una cláusula de limitación de responsabilidad amplia, la recuperación legal de la empresa fue mínima.

Nadie había sido negligente. El SOC 2 era genuino. Pero una certificación que le dice que un vendor tenía buenos controles en el momento de la auditoría no le dice si esos controles cubren el riesgo específico que se materializa en el mes once.

Esta guía es la revisión de seguridad que va más allá de la insignia.

Datos clave: revisión de seguridad de SaaS en 2026

  • Aproximadamente el 67% de los vendors de SaaS B2B tienen un informe SOC 2 Tipo II vigente, según el benchmark State of Trust de Vanta 2024, pero menos del 30% incluyen los criterios de Confidencialidad o Privacidad en el alcance.
  • La revisión de seguridad de SaaS enterprise promedio toma 41 días de principio a fin (IANS Research, 2024), razón por la cual los equipos de mercado medio envían soluciones provisionales antes de que se complete la revisión.
  • Se estima que el 54% de las filtraciones de terceros en 2024 se rastrearon hasta un vendor de SaaS o en la nube en el stack del comprador (Verizon DBIR, sección de Cadena de Suministro 2024).
  • Las empresas de mercado medio (200-2.000 empleados) omiten la revisión formal de seguridad en el 38% de las compras de SaaS, generalmente porque adquisición no identificó el gasto como software (Gartner, 2024).
  • La cláusula de notificación de filtración mediana en los contratos de SaaS es de 30 días, 10 veces más larga que el estándar de 72 horas del GDPR que la mayoría de los compradores asume que aplica.

Por qué las certificaciones son puntos de partida, no de llegada

Las certificaciones de seguridad sirven un propósito importante: crean un registro documentado de que un vendor aplicó ciertos controles en un momento específico, verificado por un tercero. Eso es significativo. La explicación de AICPA sobre los informes SOC aclara exactamente qué atestigua cada tipo de informe y qué no.

Pero las certificaciones tienen limitaciones estructurales:

Son retrospectivas. Un SOC 2 Tipo II cubre un período de observación de 6-12 meses que terminó antes de que usted firmara. La postura de seguridad del vendor hoy puede ser diferente de lo que refleja el informe, debido a cambios de personal, migraciones de infraestructura o nuevas dependencias de terceros. Para una explicación en lenguaje claro de qué cubre cada uno de SOC 2, ISO 27001 y GDPR y dónde se superponen, la guía del marco de cumplimiento para compradores es el mejor punto de partida.

Cubren alcances definidos. El SOC 2 de un vendor puede cubrir su producto principal pero excluir explícitamente ciertas integraciones de terceros, socios de procesamiento de datos o componentes de infraestructura. Leer la sección de alcance de un informe SOC 2 a menudo revela sorpresas.

No le dicen qué ocurre cuando las cosas salen mal. Una certificación le habla de controles y procesos. No le dice con qué rapidez el vendor le notificará sobre una filtración, cómo es su Playbook de respuesta a incidentes o cómo ha gestionado históricamente los eventos de seguridad.

Las herramientas con IA recopilan más. Las herramientas SaaS tradicionales procesaban los datos que usted les proporcionaba. Las herramientas con IA cada vez procesan más datos inferidos (patrones, comportamientos, señales agregadas de múltiples clientes) de maneras que pueden no estar cubiertas por los marcos de certificación existentes.

La revisión de cinco capas a continuación aborda todas estas brechas.

La revisión de seguridad proporcional

La revisión de seguridad proporcional es un principio del lado del comprador: adapte la profundidad de su revisión a la sensibilidad de los datos que el vendor manejará, no al valor del contrato ni al prestigio del logo del vendor. Una herramienta de $6/licencia que ingiere PII de clientes merece una revisión más profunda que una de $60/licencia que solo ve métricas de uso agregadas, y la mayoría de las listas de revisión de mercado medio se atascan porque los equipos ejecutan el mismo cuestionario de 200 preguntas contra cada vendor independientemente de la exposición de datos. Clasifique los vendors en rutas de revisión mínima (sin datos de clientes), estándar (datos internos) y elevada (datos regulados o de clientes) antes de enviar el cuestionario.

Capa 1: certificaciones: lea el informe, no la insignia

SOC 2 Tipo II

La expectativa estándar para cualquier herramienta SaaS que maneje datos de negocio o de clientes. Confirme:

  • Período del informe. El informe debe cubrir los 6-12 meses inmediatamente anteriores a su revisión. Un SOC 2 de hace 18 meses no está vigente.
  • Criterios de servicios de confianza incluidos. SOC 2 tiene cinco criterios: Seguridad (CC), Disponibilidad (A), Integridad del procesamiento (PI), Confidencialidad (C) y Privacidad (P). La mayoría de los vendors cubren solo Seguridad y Disponibilidad. Confirme qué criterios están cubiertos y verifique que los relevantes para su caso de uso estén incluidos.
  • Alcance. Lea la sección de alcance con atención. ¿Qué sistemas, productos e infraestructura están incluidos? ¿Qué está excluido?
  • Opinión cualificada. Si el informe contiene excepciones u opiniones calificadas, comprenda de qué se trata. Una excepción menor en la gestión de cambios es diferente a una excepción en el control de acceso.

Qué preguntar:

  • ¿Puedo recibir el informe SOC 2 Tipo II completo bajo NDA?
  • ¿Qué criterios de servicios de confianza cubre su informe?
  • ¿Cuál fue el período de auditoría y cuándo está programada su próxima auditoría?
  • ¿Hay excepciones o calificaciones en el informe actual?

ISO 27001

Relevante si opera en mercados internacionales o industrias reguladas. ISO 27001 cubre un sistema de gestión de seguridad de la información (ISMS), que no es lo mismo que SOC 2 y no son intercambiables. Un vendor con ISO 27001 pero sin SOC 2 tiene un perfil diferente al de uno con SOC 2 pero sin ISO 27001.

Verifique el alcance del certificado: debe corresponder a los productos e infraestructura que está comprando.

Pruebas de penetración

Solicite la fecha y el alcance de la prueba de penetración más reciente, quién la realizó y cuáles fueron los hallazgos materiales. Los vendors que nunca han realizado una prueba de penetración o que se niegan a compartir los resultados resumidos son una señal de riesgo significativa.

Una respuesta creíble: "Realizamos pruebas de penetración anuales con [empresa externa]. La más reciente fue [fecha] y el informe resumido está disponible bajo NDA. Los hallazgos materiales han sido remediados."

Capa 2: manejo y residencia de datos

Esta capa trata sobre qué le sucede a sus datos una vez que están dentro de los sistemas del vendor.

Geografía de almacenamiento de datos

El lugar donde viven sus datos afecta sus obligaciones de cumplimiento, su exposición a solicitudes de datos de gobiernos extranjeros y sus derechos bajo regulaciones de privacidad como el GDPR.

Preguntas que debe hacer:

  • ¿Dónde están alojadas geográficamente las bases de datos de producción?
  • ¿Dónde se almacenan las copias de seguridad?
  • ¿Ofrece una opción de residencia de datos para EE.UU./UE/región específica si es requerido?
  • Si usa AWS, Azure o GCP, ¿qué regiones?

Retención y eliminación de datos

  • ¿Cuánto tiempo se conservan los datos del cliente durante un contrato activo?
  • ¿Cuánto tiempo se conservan los datos del cliente después de la cancelación del contrato?
  • ¿Cuál es el proceso de eliminación y puede proporcionar verificación de que se completó?
  • ¿Las copias de seguridad se eliminan en el mismo cronograma que los datos de producción?

Subprocesadores de terceros

Todo vendor de SaaS usa infraestructura, análisis, soporte y proveedores de IA de terceros. Cada uno de esos proveedores es un punto potencial de exposición de datos. Solicite una lista actual de subprocesadores y verifique si alguno está en jurisdicciones con preocupaciones significativas de privacidad.

Datos de entrenamiento de IA (fundamental para herramientas con IA)

Si la herramienta del vendor incluye funciones de IA, esta se convierte en la pregunta más importante sobre el manejo de datos:

  • ¿Los datos del cliente se usan para entrenar modelos de IA del vendor? (¿Modelo compartido o aislado por cliente?)
  • Si es así, ¿pueden los clientes optar por no participar?
  • ¿Los resultados de inferencia de los datos del cliente se comparten con otros clientes?
  • ¿Cuál es el acuerdo de procesamiento de datos para el manejo específico de IA?

Capa 3: modelo de control de acceso

Cómo el vendor controla el acceso a sus datos (y a su propia infraestructura) es un indicador directo de madurez en seguridad.

Controles de acceso del lado del vendor:

  • ¿Quién en el vendor tiene acceso a los datos del cliente? (Soporte, ingeniería, equipos de datos)
  • ¿Cuál es el proceso de aprobación para que los empleados del vendor accedan a datos de producción?
  • ¿El acceso se registra y audita?
  • ¿Se requiere autenticación multifactor para que los empleados del vendor accedan a los sistemas de producción?

Controles de acceso del lado del cliente:

  • ¿El producto admite control de acceso basado en roles (RBAC)?
  • ¿El SSO está disponible y está incluido en el nivel base o es un complemento?
  • ¿La autenticación multifactor es requerida, disponible u opcional para los usuarios finales?
  • ¿Qué sucede con el acceso a los datos cuando se da de baja a un usuario?

El problema del "impuesto SSO": muchos vendors de SaaS cobran un cargo adicional por SSO, que es un control de seguridad que debería ser estándar. Esta práctica está ampliamente documentada en la comunidad de seguridad. La descripción general de SSO en Wikipedia explica por qué la federación de identidad es un control de seguridad fundamental y no una función premium. Si su empresa usa un IdP (Okta, Azure AD, Google Workspace), el SSO es un requisito de seguridad significativo. Averigüe si está incluido antes de verlo en el precio del formulario de pedido. Este tipo de patrón de costo oculto es exactamente lo que el modelado de TCO para SaaS captura en la línea de costos de integración de la Categoría 3.

Capa 4: política de notificación de filtraciones

Cuando algo sale mal (y estadísticamente algo saldrá mal con cualquier vendor que use el tiempo suficiente), qué tiene derecho a saber y cuándo importa significativamente.

Preguntas que debe hacer:

  • ¿Cuál es su compromiso contractual para los plazos de notificación de filtraciones? (72 horas es el estándar del GDPR; muchos contratos ofrecen 30 días, lo que es demasiado lento)
  • ¿Qué constituye una filtración reportable según su definición frente a un incidente de seguridad?
  • ¿Ha tenido una filtración reportable en los últimos dos años? Si es así, ¿qué sucedió y cuál fue el resultado?
  • ¿Cuál es su procedimiento de respuesta a incidentes y quién es el contacto designado?
  • ¿Su seguro de responsabilidad cibernética cubre los costos de notificación al cliente?

Estándar contractual mínimo: obtenga un SLA de notificación de filtraciones por escrito. 72 horas desde el descubrimiento para cualquier cosa que involucre datos personales es el estándar que debe negociar. Esto sigue el requisito establecido en el Artículo 33 del GDPR. Si el vendor se resiste, entienda por qué.

Capa 5: historial de divulgación de vulnerabilidades

Los incidentes de seguridad pasados, cuando se manejan bien, son evidencia de madurez, no un factor que descalifica. Un vendor que nunca ha divulgado una vulnerabilidad o no ha sido atacado (improbable) o no tiene un programa de divulgación (un problema). El Marco de Ciberseguridad del NIST define la divulgación responsable y la gestión de vulnerabilidades como prácticas centrales de las funciones "Responder" y "Recuperar". Los vendors que no pueden hacer referencia a ellas probablemente no operan a ese nivel de madurez. Para herramientas con IA, estas preguntas se extienden a la inferencia de modelos y la exposición de datos de entrenamiento, que la guía de evaluación de SaaS con IA aborda en detalle.

Preguntas que debe hacer:

  • ¿Tiene un programa de bug bounty o una política de divulgación responsable?
  • ¿Ha divulgado algún CVE (Vulnerabilidades y Exposiciones Comunes) en los últimos dos años?
  • Si es así, ¿cuál fue el plazo desde el descubrimiento hasta el parche y la divulgación?
  • ¿Qué bibliotecas o componentes de terceros usa su producto y cómo rastrea las vulnerabilidades en ellos?

El cuestionario de revisión de seguridad (20 preguntas)

Envíe este cuestionario antes de la llamada de revisión de seguridad. Esto saca a la luz las brechas antes de que su tiempo se dedique a ellas.

Certificaciones

  1. ¿Tiene un informe SOC 2 Tipo II vigente? ¿Qué criterios de servicios de confianza cubre?
  2. ¿La certificación ISO 27001 aplica a los productos que estamos comprando?
  3. ¿Cuál fue la fecha de su prueba de penetración más reciente y hay un resumen disponible?

Manejo de datos 4. ¿Dónde se almacenan los datos de producción geográficamente? ¿Dónde están las copias de seguridad? 5. ¿Ofrece opciones de residencia de datos para [nuestra región]? 6. ¿Cuál es su política de retención de datos durante y después de la cancelación del contrato? 7. ¿Qué subprocesadores manejan nuestros datos y dónde están ubicados? 8. ¿Los datos del cliente se usan para entrenar sus modelos de IA? ¿Pueden los clientes optar por no participar?

Control de acceso 9. ¿Quién en su empresa puede acceder a los datos de producción de los clientes y cuál es el proceso de aprobación? 10. ¿El acceso a producción se registra y es auditable? 11. ¿El SSO/SAML está disponible y está incluido en el nivel base? 12. ¿El producto admite control de acceso basado en roles (RBAC)?

Notificación de filtraciones 13. ¿Cuál es su plazo contractual de notificación de filtraciones? 14. ¿Ha tenido una filtración reportable o un incidente de seguridad material en los últimos dos años? 15. ¿Quién es el contacto de seguridad designado en caso de un incidente?

Gestión de vulnerabilidades 16. ¿Tiene un programa de bug bounty o de divulgación responsable? 17. ¿Ha divulgado algún CVE en los últimos 24 meses? 18. ¿Cómo rastrea y parchea las vulnerabilidades de bibliotecas de terceros?

Contrato y cumplimiento 19. ¿Puedo recibir el DPA y todos los addenda de procesamiento de datos antes de firmar? 20. ¿Cuál es su limitación de responsabilidad por una filtración de seguridad que afecte los datos de nuestros clientes?

Scorecard de seguridad del vendor

Use este cuadro para resumir la revisión para un tomador de decisiones no técnico:

Dominio Puntaje (1-5) Notas
Vigencia y alcance de la certificación
Transparencia en el manejo de datos
Madurez del control de acceso
Compromiso de notificación de filtraciones
Historial de divulgación de vulnerabilidades
Manejo de datos de IA (si aplica)
General

Puntaje 4-5: proceda con la revisión estándar del contrato. Puntaje 3: proceda con requisitos específicos de remediación en el contrato. Puntaje por debajo de 3: escale al liderazgo de IT antes de proceder; evalúe si este vendor puede cumplir sus requisitos.

Cómo Rework aborda la revisión de seguridad en ambas partes de la mesa

Rework mantiene SOC 2 Tipo II (criterios de Seguridad, Disponibilidad y Confidencialidad), con opciones de residencia de datos en regiones de EE.UU. y UE y un compromiso de notificación de filtraciones de 72 horas en nuestro DPA estándar, sin necesidad de negociación para igualar el estándar del GDPR. Los datos del cliente nunca se usan para entrenar modelos de IA compartidos, los subprocesadores están listados públicamente y el SSO está incluido en todos los niveles de pago en lugar de estar bloqueado detrás de un complemento enterprise.

En el otro lado de la mesa, Rework Work Ops es lo que los equipos de IT y seguridad de mercado medio usan para ejecutar la revisión de seguridad como un proceso interfuncional. Work Ops (desde $6/usuario/mes) ofrece una cola de entrada compartida donde adquisición marca las nuevas solicitudes de SaaS, las enruta automáticamente a IT o seguridad según el nivel de sensibilidad de datos, rastrea las respuestas al cuestionario contra los plazos de firma del contrato y mantiene a legal, finanzas y el departamento solicitante en el mismo cronograma. Convierte el ciclo de revisión promedio de 41 días en un Workflow predecible en lugar de un hilo de Slack que muere después del tercer seguimiento.

Preguntas frecuentes

Preguntas frecuentes sobre revisión de seguridad y cumplimiento de SaaS

¿Qué certificaciones de seguridad debe tener todo SaaS?

Para cualquier herramienta que maneje datos de clientes o de negocio, SOC 2 Tipo II (criterios de Seguridad y Disponibilidad como mínimo) es la línea base. Añada ISO 27001 si opera en la UE o industrias reguladas, y un DPA vigente si algún dato personal fluye a través del vendor. Las certificaciones por debajo de SOC 2 Tipo II, como un SOC 2 Tipo I, un "whitepaper de seguridad" con autoatestación o una página de centro de confianza sin un informe subyacente, no son equivalentes y deben tratarse como una brecha, no como aprobación.

¿Cuándo debo exigir un cuestionario de seguridad completo?

Clasifique por sensibilidad de datos. Revisión mínima (cuestionario corto, documentos públicos del centro de confianza) para herramientas que no ven datos de clientes. Revisión estándar (SIG Lite de 30-40 preguntas) para herramientas con datos internos de negocio. Revisión elevada (SIG o CAIQ completos, más informe SOC 2 bajo NDA y revisión del DPA) para todo lo que toque PII de clientes, datos financieros, código fuente o datos regulados. Ejecutar el mismo formulario de 150 preguntas contra cada vendor es la razón por la que las listas de revisión crecen más rápido de lo que se cierran.

¿Cuánto debe tardar una revisión de seguridad de SaaS?

Para un proceso por niveles, la revisión mínima toma 2-5 días hábiles, la estándar 10-15 días hábiles, y la elevada 3-6 semanas. El benchmark de IANS 2024 de 41 días refleja procesos sin niveles donde las herramientas de bajo riesgo están en la misma cola que las de alto riesgo. Si su revisión elevada supera consistentemente las 8 semanas, el cuello de botella es casi siempre la revisión legal del DPA, no el cuestionario de seguridad en sí.

¿Puede un vendor de SaaS prescindir de SOC 2 y aun así ser seguro?

Los vendors en etapa temprana (antes de la Serie A, con menos de ~50 empleados) a veces operan de forma segura sin un SOC 2 simplemente porque el costo de la auditoría aún no cabe en su presupuesto. Para casos de uso de baja sensibilidad, un vendor creíble con ISO 27001, un resumen publicado de prueba de penetración, un DPA claro y una fecha comprometida para SOC 2 puede ser aceptable con lenguaje contractual compensatorio. Para cualquier cosa que maneje PII de clientes o datos regulados, "estamos trabajando en el SOC 2" no es sustituto: exíjalo antes del despliegue en producción e incorpórelo al contrato como un hito.

¿Cuál es la señal de alerta más grande en una revisión de seguridad?

Un vendor que no comparte su informe SOC 2 bajo NDA. La insignia en el sitio web es marketing; el informe es el artefacto. Los vendors que se desvían con "nuestro equipo legal no nos permite compartir el informe" o están tergiversando su certificación, tienen excepciones materiales que no quieren que los compradores vean, o tienen un alcance del informe que no cubre el producto que está comprando. La segunda más grande: negarse a comprometerse con una notificación de filtración en menos de 30 días.

¿Quién es responsable de la revisión de seguridad: IT, el equipo de seguridad o legal?

En el mercado medio (200-2.000 empleados), la revisión de seguridad generalmente recae en IT o en una pequeña función de seguridad, con legal a cargo de la revisión del DPA y el contrato. El modo de fallo es cuando nadie es responsable del traspaso: IT aprueba los controles, legal aprueba los términos, pero nadie verifica que el lenguaje del contrato refleje realmente lo que IT verificó. Asigne un único responsable de revisión por vendor, generalmente IT para el nivel elevado y adquisición para el estándar, y convierta a legal en revisor, no en guardián.

¿Debo revisar nuevamente a los vendors que ya aprobé?

Sí, con una cadencia por nivel de riesgo. Vendors de nivel elevado anualmente (nuevo informe SOC 2, lista actualizada de subprocesadores, actualización de prueba de penetración). Vendors de nivel estándar cada 2 años o en la renovación. Vendors de nivel mínimo solo ante un cambio material (adquisición, expansión regional, nueva función de IA). Un vendor adquirido por una empresa más grande o que se expande a una nueva región de procesamiento de datos debe activar una revisión fuera del ciclo independientemente del nivel.

Más información