SOC 2 Type II para startups SaaS en 2026: alcance, controles y calendario de auditoría

Yury Pukhov CEO, YuSMP Group · ingeniería SaaS, programas de cumplimiento y preparación para procesos de compra empresariales desde 2014

TL;DR: SOC 2 Type II en un párrafo

Type I frente a Type II: qué exigen los compradores empresariales en 2026

SOC 2 tiene dos modalidades, y la diferencia importa más en 2026 de lo que importaba hace solo dos años. Un informe Type I es una atestación en un momento concreto: en la fecha en que el auditor lo revisó, sus controles estaban diseñados adecuadamente. Un informe Type II atestigua que esos controles además funcionaron de forma eficaz durante una ventana definida, normalmente de seis o doce meses.

En 2026, el manual de compras de casi todas las Fortune 1000 y de la mayoría de los compradores SaaS de Serie C+ dice más o menos esto:

• Por debajo de $25k de ACV: un Type I más un cuestionario de seguridad suele ser aceptable.
• $25k–$250k de ACV: el mínimo es un Type II con una ventana de al menos seis meses. Con un Type I le responderán «vuelva cuando tenga el Type II».
• Por encima de $250k de ACV o con cualquier comprador regulado (servicios financieros, sanidad, Administración federal): un Type II que cubra los doce meses anteriores, cada vez más a menudo acompañado de ISO 27001, y un informe de pruebas de penetración de una empresa reconocida.

En 2026 el Type I tiene un único uso honesto: servir de puente. Puede obtener un Type I en 4–6 semanas una vez terminada la preparación, entregárselo a un comprador para desbloquear el contrato y obtener el Type II al final de la siguiente ventana de observación. Gaste el presupuesto del Type I solo si tiene un comprador concreto esperándolo. Si no, sáltelo y vaya directamente a un Type II de seis meses: la renovación del segundo año caerá en un calendario más limpio y evitará pagar dos veces los honorarios del auditor. Si los controles de base aún no están construidos, ese trabajo de preparación es el punto de partida de nuestros equipos de desarrollo de software empresarial y de cloud & DevOps: arquitectura preparada para SOC 2, SDLC seguro y refuerzo de IAM antes de que se abra la ventana de observación.

Para los fundadores que venden sobre todo en la Unión Europea, SOC 2 suele combinarse con ISO 27001 y un enfoque de privacidad basado en el RGPD, o sustituirse por ellos. Explicamos la mecánica del lado europeo en nuestro artículo El RGPD para fundadores de EE. UU. que venden en la UE, y los complementos específicos de IA en Cumplimiento del Reglamento de IA de la UE.

Trust Services Criteria: cuáles elegir

El alcance de SOC 2 se define mediante los cinco Trust Services Criteria (TSC), establecidos por el AICPA. Solo uno es obligatorio; los otros cuatro son opcionales y cada uno añade un coste de auditoría real. La elección correcta depende de lo que prometan sus contratos.

El stack pragmático para una startup SaaS B2B de Serie A/B en 2026 es Security + Availability + Confidentiality. Cubre las preguntas de los cuestionarios a las que realmente se enfrenta, transmite un compromiso de SLA y mantiene los honorarios de auditoría en la franja de $20k–$35k. Añada Processing Integrity solo si un regulador o uno de sus tres principales compradores lo pide expresamente. Omita Privacy el primer año: el RGPD y la CCPA tienen más peso en los procesos de compra en 2026, y los controles se solapan mucho.

Alcance: sistemas incluidos y exclusiones de subproveedores

La definición del alcance es donde la mayoría de los programas SOC 2 pierden tiempo. El alcance es el sistema de producción que presta el servicio a los clientes: no su web de marketing, ni su Notion interno de RR. HH., ni su clúster de pruebas internas. Decida qué queda dentro del alcance preguntándose: «¿Este sistema procesa o almacena datos de clientes, o forma parte del circuito de producción que lo hace?». Si la respuesta es sí, está dentro. Si es no, fuera.

En una startup SaaS típica, los sistemas incluidos en el alcance son:

• La cuenta de producción de AWS / GCP / Azure que aloja la aplicación, incluidos todos los recursos de cómputo, almacenamiento, bases de datos, colas y gestores de secretos.
• El sistema de control de código fuente que contiene la base de código de producción (GitHub, GitLab, Bitbucket) y sus protecciones de ramas.
• El pipeline de CI/CD que despliega en producción (GitHub Actions, CircleCI, Buildkite, Argo).
• El proveedor de identidad que usan los empleados para acceder a producción (Okta, Google Workspace, Microsoft Entra ID).
• El stack de monitorización y registros (CloudWatch, Datadog, Grafana, Splunk, Wiz, Sentry).
• El sistema de tickets y gestión de cambios (Linear, Jira, GitHub Issues), porque es ahí donde se generan las evidencias de las aprobaciones.
• La solución MDM que gestiona los portátiles de los empleados con acceso a credenciales de producción (Jamf, Kandji, Intune).

Fuera del alcance: el WordPress de marketing, el CRM de ventas, el portal de soporte (salvo que procese datos de clientes) y los entornos sandbox de preproducción que no contienen datos de clientes ni comparten credenciales con producción.

Organizaciones subproveedoras: el método de exclusión (carve-out)

Casi todas las startups SaaS funcionan sobre terceros: AWS para cómputo, Stripe para pagos, Auth0 para identidad, Twilio para mensajería, Datadog para monitorización. El método de exclusión (carve-out) le dice al auditor: «Estos proveedores tienen sus propios informes SOC 2 / ISO 27001. Confíe en ellos y no vuelva a auditarlos a través de mí».

Es la respuesta correcta en el 99 % de los casos. La mecánica:

1. Enumere las organizaciones subproveedoras en la descripción del sistema SOC 2.
2. Recopile cada año sus informes SOC 2 Type II / ISO 27001 vigentes (AWS Artifact, portal de confianza de Stripe, centro de confianza de Auth0, etc.).
3. Implante los controles complementarios de la entidad usuaria (CUEC) que le indique el informe de cada proveedor. Son las cosas que debe hacer usted, porque ellos no pueden. Ejemplos: activar MFA en la cuenta raíz de AWS, no guardar nunca la clave de la cuenta raíz en el código, rotar las claves restringidas de Stripe cada 90 días, configurar la protección contra fuerza bruta de Auth0, cifrar los buckets S3 gestionados por el cliente con SSE-KMS.
4. Conserve evidencias de que cada CUEC se aplica. La plataforma de automatización del cumplimiento automatiza la mayor parte de esta recopilación.

Familias de controles con ejemplos concretos

Los Common Criteria se dividen en nueve familias (de CC1 a CC9). A la mayoría de los equipos de ingeniería les afectan cinco de ellas en el trabajo diario. A continuación verá cómo es cada una en una startup SaaS de 2026: no el lenguaje de las políticas, sino la mecánica real.

Gestión de accesos

• SSO en todas partes. Okta o Google Workspace como fuente única de identidad. Aprovisionamiento SCIM donde el SaaS lo admita. Nada de cuentas de servicio compartidas que inicien sesión con contraseña.
• MFA obligatoria en todos los sistemas próximos a producción. Llaves físicas (YubiKey, Titan) para los administradores; TOTP como mínimo para todos los demás. En 2026, una MFA solo por SMS es una deficiencia (finding).
• RBAC con mínimo privilegio. Grupos de AWS IAM, no políticas en línea. Equipos de GitHub, no colaboradores individuales. Revisiones de acceso anuales registradas en el sistema de tickets; trimestrales para los roles con acceso a producción.
• Bajas en un día hábil. Lista de comprobación documentada que cubra Okta, AWS, GitHub, Slack, Notion, Linear, Datadog, Sentry y cualquier otro tenant. La mayoría de las auditorías fallidas empiezan aquí.

Gestión de cambios

• Todo cambio en producción pasa por una pull request. Sin commits directos a main; ramas protegidas.
• Al menos un revisor independiente. Aprobación obligatoria de la PR antes del merge; CODEOWNERS para las rutas sensibles.
• Puerta de pruebas automatizada. El CI debe pasar en la PR antes del merge. Los fallos de las pruebas no pueden saltarse sin una excepción documentada.
• Despliegues en producción trazables hasta una PR y un ticket. Los registros de despliegue enlazan al SHA de Git; los mensajes de commit hacen referencia a los ID de Linear/Jira.
• Procedimiento de cambio de emergencia documentado y poco utilizado. Los auditores comprueban que la «emergencia» no sea su modo habitual de trabajo.

Monitorización y detección

• Registros centralizados. CloudWatch + Datadog o Splunk; registros conservados 365+ días; el propio acceso a los registros queda registrado.
• Alertas ante eventos de seguridad. Picos de inicios de sesión fallidos, cambios en políticas de IAM, cambios en claves de KMS, cambios en grupos de seguridad, uso de la cuenta raíz.
• Cobertura CSPM / CNAPP. Wiz, Orca, Lacework o Prowler ejecutándose de forma continua sobre la cuenta cloud. Hallazgos clasificados dentro de un SLA documentado.
• Detección en endpoints. CrowdStrike, SentinelOne o Jamf Protect en todos los portátiles con acceso a producción.
• Gestión de vulnerabilidades. Dependabot / Renovate más Snyk o GitHub Advanced Security; lo que se pone a prueba es el control del SLA para las críticas (normalmente 30 días), no la elección del escáner.

Respuesta a incidentes

• Plan de respuesta a incidentes por escrito con escala de gravedad, rotación de guardias, plantilla de comunicación y umbrales de notificación a clientes.
• Al menos un ejercicio de simulación (tabletop) al año con acta archivada.
• Post-mortem de cada incidente visible para el cliente con acciones de seguimiento hasta su cierre.
• Circuito forense y de notificación de violaciones de seguridad documentado: aunque nunca lo haya usado, el auditor preguntará por él.

Gestión de proveedores

• Inventario de proveedores. Una lista viva de todos los subencargados y SaaS que tocan datos de clientes. Las plataformas de cumplimiento la mantienen por usted si están conectadas.
• Nivel de riesgo por proveedor (bajo/medio/alto) según la sensibilidad de los datos y la profundidad de la integración.
• Informe SOC 2 / ISO 27001 recopilado anualmente para los proveedores de nivel medio o superior.
• DPA / BAA firmados donde sea necesario. Si vende al sector sanitario, además necesita BAA de nivel HIPAA.

Comparativa de plataformas de automatización del cumplimiento

Se puede llevar un programa SOC 2 con hojas de cálculo. Nosotros lo hicimos en 2018. En 2026 nadie debería hacerlo: el coste de una plataforma de automatización del cumplimiento se recupera con unas 80 horas de recopilación de evidencias ahorradas a lo largo de una ventana de observación.

Las cuatro plataformas que realmente compiten en 2026:

Lo que las cuatro hacen bien: extraer de forma continua evidencias de AWS / GCP / Azure / GitHub / Okta / Jamf / Datadog / Linear y similares; asignar esas evidencias a las pruebas de controles; señalar desviaciones cuando un control falla; ofrecer plantillas de políticas; proporcionar un portal para el auditor en el momento de la auditoría.

Lo que ninguna hace: redactar su SDLC seguro, modelar amenazas, corregir hallazgos, ejecutar de verdad las bajas, dirigir el ejercicio de simulación. Prevea un responsable a tiempo parcial dentro de ingeniería (normalmente el CTO, el head of platform o un ingeniero DevOps sénior) que impulse el programa. Externalizar el papel de responsable en el proveedor de la plataforma es el motivo más habitual por el que una primera auditoría falla o se retrasa.

Ventana de observación: ¿3, 6 o 12 meses?

El mínimo que aceptará cualquier auditor de prestigio es de tres meses, y varias firmas Big Four no bajan de seis. Los valores por defecto que recomendamos:

• Tres meses: solo si un comprador empresarial concreto lo ha aceptado por escrito. Es frágil y casi garantiza que necesitará un segundo encargo inmediato.
• Seis meses: el primer Type II estándar. Lo bastante largo para que los auditores muestreen evidencias de forma convincente y lo bastante corto para que no aparezca el cansancio con el programa.
• Doce meses: el valor por defecto a partir del segundo año, porque coincide con el periodo de validez del informe y con el ciclo de renovación que esperan los compradores.

Secuencia práctica para una startup sin experiencia previa en cumplimiento: 8–12 semanas de preparación, después un Type I (opcional) para desbloquear a los compradores inmediatos y, a continuación, una ventana de observación de 6 meses para el Type II. Tiempo total desde «decidimos hacer SOC 2» hasta «tenemos el informe Type II»: 9–12 meses.

Hoja de ruta de cumplimiento: 5 pasos desde el arranque hasta el informe

Todos los proveedores de plataformas de cumplimiento publican alguna versión de esta hoja de ruta porque funciona: la diferencia entre una primera auditoría fluida y una que se atasca depende casi por completo de la secuencia, no del esfuerzo. Esta es la versión que aplicamos con los equipos de ingeniería:

1. Análisis de brechas y alcance mínimo viable. Compare los controles actuales con los Trust Services Criteria que haya elegido (véase más arriba), enumere todos los sistemas incluidos en el alcance y las exclusiones de subproveedores, y califique cada control como cumplido / parcialmente cumplido / ausente. Es un ejercicio de 1–2 semanas, que normalmente se realiza dentro del catálogo de controles predefinido de la plataforma de cumplimiento.
2. Corrección. Cierre las brechas detectadas en el paso 1: active MFA en todas partes, configure SSO/SCIM, redacte las políticas que falten (respuesta a incidentes, control de accesos, gestión de proveedores), arregle el proceso de bajas. Calcule 4–8 semanas; aquí se consume la mayor parte de los 0.3–0.6 FTE de tiempo de ingeniería.
3. Recopilación de evidencias y ventana de observación. Una vez activos los controles, la plataforma de cumplimiento empieza a extraer evidencias de forma continua (véase la comparativa de plataformas más abajo). La ventana de observación (3, 6 o 12 meses; véase la siguiente sección) comienza el día en que los controles funcionan de forma demostrable, no el día en que decide hacer SOC 2.
4. Selección del auditor y trabajo de campo. Elija el nivel de firma CPA que acepten sus compradores (véase la tabla de costes más abajo), comparta el portal del auditor de la plataforma de cumplimiento y cuente con 2–4 semanas de muestreo y solicitudes de evidencias una vez cerrada la ventana.
5. Emisión del informe y primer ciclo de renovación. El informe Type II es válido durante doce meses desde su emisión. Inicie de inmediato la siguiente ventana de observación (véase «Cumplimiento continuo» más abajo) en lugar de tratar el informe como una meta final.

Selección del auditor y coste

Solo una firma CPA con licencia puede emitir un informe SOC 2. En 2026 el mercado se divide en tres niveles:

Elija el nivel más pequeño que acepten sus compradores. En 2026 todavía no hemos visto a ningún comprador rechazar un informe de Schellman, A-LIGN o Insight Assurance. Sí hemos visto rechazar informes de auditores de los que nadie había oído hablar: compruebe que la firma tiene una lista pública de clientes y al menos 100 informes SOC 2 emitidos.

Costes ocultos más allá de los honorarios del auditor: una prueba de penetración de una empresa reconocida (Cobalt, NetSPI, Bishop Fox: $8k–$25k), la plataforma de cumplimiento ($12k–$30k/año), el tiempo de ingeniería (0.3–0.6 FTE durante la ventana) y la corrección de hallazgos durante la auditoría (normalmente 40–80 horas de ingeniería). Coste total realista del primer año para una startup SaaS de Serie A/B: $50k–$120k.

Hallazgos de auditoría habituales que conviene evitar

En los encargos SOC 2 que hemos observado, cuatro hallazgos aparecen en aproximadamente el 70 % de los informes del primer año. Todos se pueden prevenir con disciplina, no con ingeniería.

1. Empleado dado de baja que sigue activo en al menos un sistema. La baja cubrió Okta y AWS, pero no el tenant independiente de Datadog creado hace dos años, ni el equipo de Postman, ni la organización de Sentry. Solución: mantenga una lista de comprobación de desaprovisionamiento que enumere cada tenant por su nombre; revísela cada mes; haga que RR. HH. dé el visto bueno cuando un empleado se marcha.
2. Cambio en producción sin ticket asociado. Un hotfix salió como commit directo, o se ejecutó una migración manual de la base de datos sin PR. Solución: imponga ramas protegidas; exija que cada registro de despliegue haga referencia a una PR; disponga de un procedimiento de emergencia documentado (y poco utilizado).
3. Recuperación ante desastres sin probar. El runbook existe, pero nadie ha restaurado realmente desde una copia de seguridad durante la ventana de observación. Solución: programe un simulacro trimestral de restauración desde copia de seguridad y archive el acta, aunque el simulacro dure 30 minutos.
4. Revisión de proveedores omitida. Se incorporó un nuevo subencargado a mitad de la ventana sin evaluación de riesgos ni informe SOC 2 recopilado. Solución: condicione cada decisión de «Añadir integración» a un formulario de alta de proveedor de 15 minutos en su plataforma de cumplimiento.

Cumplimiento continuo después del informe

El día en que se emite el informe Type II empieza la siguiente ventana de observación. No hay pausa. Las evidencias pierden vigencia de inmediato; los controles se desvían a medida que el equipo de ingeniería lanza funcionalidades; se añaden proveedores nuevos; hay personas que se van y otras que llegan. Tres hábitos mantienen el programa en buena forma:

1. Revisión mensual de desviaciones. 30 minutos en la plataforma de cumplimiento revisando las comprobaciones que fallan. Casi siempre son cosas triviales: un restablecimiento de MFA que se revirtió, un usuario de Datadog fuera del SSO, un informe SOC 2 caducado de un subencargado.
2. Miniauditoría interna trimestral. Elija cinco controles al azar, póngase en el lugar del auditor y recopile las evidencias. Si no puede, cierre la brecha antes de que la encuentre el auditor de verdad.
3. Revisión anual del programa. Redefina el alcance a medida que cambia el producto: nuevos TSC, nuevas organizaciones subproveedoras, nuevas líneas de negocio.

SOC 2 también se solapa con marcos afines que quizá necesite: ISO 27001 (más habitual en Europa), HIPAA (sanidad en EE. UU.; consulte nuestra lista de comprobación para el desarrollo de software HIPAA), el RGPD (residencia de datos y derechos en la UE; consulte El RGPD para fundadores de EE. UU.) y las nuevas obligaciones del Reglamento de IA de la UE para el SaaS con IA (consulte Cumplimiento del Reglamento de IA de la UE). Aproximadamente el 70 % de los controles se solapan, así que, una vez que SOC 2 está en buena forma, añadir un segundo marco es un trabajo incremental, no duplicado.

Preguntas frecuentes

¿Siguen aceptando los compradores empresariales un SOC 2 Type I en 2026?

Rara vez, y solo como solución provisional. En 2026 los equipos de compras del mid-market y empresariales consideran el Type I una prueba de que usted tiene la intención de cumplir, no de que cumple. Un Type I abre la conversación del cuestionario de seguridad; un Type II desbloquea el contrato. Si su comprador está regulado (servicios financieros, sanidad, sector público), cuente con que rechace directamente el Type I y pida un Type II que cubra al menos los seis meses anteriores.

¿Qué Trust Services Criteria debe elegir una startup SaaS?

Security (los Common Criteria) es obligatorio en todos los encargos SOC 2. Para un SaaS multi-tenant típico, añada Availability si vende un SLA de disponibilidad, y Confidentiality si procesa datos empresariales de clientes bajo NDA. Añada Processing Integrity solo cuando las garantías de exactitud sean centrales para el producto (cálculos fintech, nóminas, facturación). Privacy rara vez compensa en el primer encargo: el RGPD o la CCPA suelen aportar más a los compradores, y Privacy añade un 30–50 % al coste de la auditoría.

¿Cuánto debe durar la ventana de observación de SOC 2 Type II?

El mínimo que aceptan los auditores es de tres meses, y casi todas las firmas Big Four rechazan cualquier periodo inferior a seis. El valor por defecto pragmático para un primer Type II es de seis meses. Amplíelo a doce solo si un comprador empresarial estratégico lo exige expresamente o si tiene previsto saltarse el Type I e ir directamente al Type II por el calendario de renovación.

¿Cuánto cuesta realmente SOC 2 Type II en 2026?

Para una startup SaaS de Serie A/B, cuente con $15,000–$25,000 de honorarios del auditor en una boutique CPA de prestigio, $25,000–$40,000 en una firma nacional y $40,000–$60,000+ en una Big Four. Sume $12,000–$30,000/año por una plataforma de automatización del cumplimiento (Vanta, Drata, Secureframe, Sprinto), más 0.3–0.6 FTE de tiempo de ingeniería y de operaciones de seguridad durante la ventana de observación. Total del primer año: $50,000–$120,000.

¿Sustituyen realmente Vanta, Drata o Secureframe a un ingeniero de seguridad?

No. Sustituyen a la hoja de cálculo con la que se siguen las evidencias y al consultor que copia y pega plantillas de políticas. Las plataformas recopilan de forma continua evidencias de AWS, GCP, Azure, GitHub, Okta, Jamf y fuentes similares, las asignan a las pruebas de controles y señalan las desviaciones. No redactan su SDLC seguro, no modelan amenazas ni corrigen hallazgos. Prevea un responsable a tiempo parcial dentro de ingeniería durante el primer año: normalmente el CTO o un ingeniero DevOps sénior.

¿Se pueden excluir (carve-out) organizaciones subproveedoras como AWS, Stripe y Auth0?

Sí, y casi siempre conviene hacerlo. El método de exclusión (carve-out) saca del alcance los controles de la organización subproveedora y remite al auditor a sus propios informes SOC 2 / ISO 27001. Los controles complementarios de la entidad usuaria (CUEC) que publican AWS, Stripe y Auth0 sí se le siguen aplicando a usted: debe implantarlos (por ejemplo, activar MFA en la cuenta raíz de AWS o rotar las claves restringidas de Stripe) y disponer de evidencias que el auditor pueda muestrear.

¿Cuáles son los hallazgos más habituales en una auditoría SOC 2 Type II?

Cuatro aparecen de forma sistemática en las auditorías del primer año: (1) empleados dados de baja que siguen activos en al menos un sistema porque el proceso de baja no cubrió todos los tenants SaaS, (2) cambios en producción desplegados sin el ticket correspondiente ni la aprobación de la PR, (3) una prueba de recuperación ante desastres o de restauración de copias de seguridad que se programó pero nunca se ejecutó, (4) revisiones de proveedores omitidas o cuestionarios de seguridad ausentes para los subencargados. Los cuatro se pueden prevenir con disciplina y una revisión mensual de 30 minutos.

¿Qué ocurre después del informe? ¿SOC 2 es algo puntual?

No. Los informes SOC 2 Type II son válidos durante doce meses desde la fecha de emisión, y los compradores empresariales esperan una renovación anual sin interrupciones. El problema del «cumplimiento continuo» es que las evidencias pierden vigencia, los controles se desvían a medida que el equipo de ingeniería lanza funcionalidades y la siguiente ventana de observación empieza justo el día en que termina el periodo cubierto por el informe anterior. Trate SOC 2 como un ciclo anual, con miniauditorías internas trimestrales y una plataforma de automatización del cumplimiento vigilando las desviaciones.

Última actualización: 27 de septiembre de 2026. Los honorarios de los auditores, los precios de las plataformas y las normas de compra reflejan tarifas y observaciones de campo vigentes en el T3 de 2026.