SOC 2 para startups: cuándo lo necesitas y cómo abordarlo

Por Kike Gandia · Co-Fundador y CEO, OSCP

SOC 2 es, con diferencia, el requisito de seguridad que más frecuentemente frena un contrato enterprise para una startup SaaS. No es una ley ni una obligación regulatoria: es un estándar de auditoría que tus clientes grandes exigen como prueba de que gestionas sus datos con criterio. Esta guía explica cuándo empezar, qué tipo de informe pedirte, y qué esperar del proceso real.

Type I vs Type II: la diferencia que decide el plazo

Un informe SOC 2 Type I evalúa si tus controles están bien diseñados en un momento puntual: se puede conseguir en semanas. Un Type II evalúa si esos controles funcionaron de forma efectiva durante un periodo de observación, normalmente de 3 a 12 meses. La mayoría de clientes enterprise maduros acaban pidiendo Type II, pero Type I es un punto de partida válido mientras se acumula el histórico necesario para el Type II.

Cuándo tu startup lo necesita de verdad

La señal más clara es cuando un prospecto o cliente enterprise incluye SOC 2 como requisito en su cuestionario de seguridad (vendor security questionnaire) o directamente lo exige como cláusula contractual. Perseguir la certificación antes de tener esa demanda real suele ser un gasto prematuro; startups en fase muy temprana (pre-Serie A) rara vez lo necesitan todavía.

Qué implica el proceso en la práctica

Selección de los Trust Services Criteria aplicables (seguridad es obligatorio; disponibilidad, confidencialidad, integridad de procesamiento y privacidad son opcionales según tu producto), implementación de controles (gestión de accesos, monitorización, gestión de cambios, respuesta a incidentes), periodo de observación para Type II, y auditoría por un contable público certificado (CPA) habilitado para emitir informes SOC 2.

Coste y tiempo realistas

Para una startup con pocos empleados y stack cloud estándar, un Type I suele conseguirse en 2-3 meses con un coste de consultoría más auditoría entre 15.000 y 40.000 €. Un Type II añade el periodo de observación (3-12 meses) antes de poder emitir el informe. Plataformas de automatización de cumplimiento pueden reducir el tiempo de preparación, pero no eliminan el periodo de observación exigido por el estándar.

Type I y Type II lado a lado

Puesto en una tabla, la elección deja de ser una duda técnica y pasa a ser una decisión de calendario comercial:

	Type I	Type II
Qué evalúa	El diseño de los controles en una fecha concreta	Que los controles funcionaron durante un periodo
Ventana temporal	Un día	Normalmente de 3 a 12 meses
Qué evidencia pide el auditor	Configuraciones, políticas y permisos tal como estaban ese día	Muestras repartidas a lo largo del periodo: altas y bajas reales, tickets de cambio, revisiones de acceso
Para qué sirve comercialmente	Desbloquear a un cliente que necesita ver movimiento; ganar tiempo	Cerrar compras enterprise maduras; respuesta estándar en cuestionarios
Riesgo principal	Que el cliente diga "esto no me vale, necesito Type II"	Que un control falle en mitad del periodo y aparezca como excepción

La consecuencia operativa del Type II es la que más sorprende: durante el periodo de observación hay que ejecutar los controles de verdad y dejar rastro. Si la revisión trimestral de accesos está documentada pero nadie la hizo en el segundo trimestre, eso no se arregla después: aparece como excepción en el informe.

Qué enseñar mientras no tienes el informe

Entre que un cliente lo pide y que el informe existe pasan meses, y el contrato no espera. Lo que suele funcionar, por orden de credibilidad: una carta de compromiso con la fecha de inicio del periodo de observación y la firma del auditor contratado; un informe de pentest reciente con los hallazgos críticos ya remediados; y la documentación de los controles que ya están operando (gestión de accesos, gestión de cambios, respuesta a incidentes). Un detalle que conviene conocer de antemano: cuando ya tienes un Type II, entre la fecha de fin del periodo cubierto y el momento en que un cliente te lo pide se abre un hueco temporal. Ese hueco se cubre con una carta puente (bridge letter), que emite tu propia dirección —no el auditor— declarando que no ha habido cambios materiales en los controles desde el cierre del informe. Es una práctica estándar y la mayoría de compradores la acepta, pero solo cubre unos pocos meses: no sustituye al siguiente informe.

FAQ

¿SOC 2 es obligatorio por ley?

No. Es un estándar voluntario de auditoría (AICPA) que tus clientes exigen contractualmente, no una obligación regulatoria como el RGPD o NIS2.

¿Puedo enseñar un pentest en vez de SOC 2?

Un pentest reciente suele ayudar y a veces basta para clientes menos exigentes, pero la mayoría de compradores enterprise maduros piden específicamente el informe SOC 2, no un sustituto.

¿Qué pasa si pierdo la certificación en la auditoría de seguimiento?

SOC 2 no es una certificación permanente: cada informe cubre un periodo concreto. Hay que repetir el ciclo de auditoría periódicamente (normalmente cada 12 meses) para mantener informes vigentes.

Nuestro proveedor cloud ya tiene SOC 2. ¿Nos sirve?

No para responder por ti, pero sí es una pieza del proceso. El informe SOC 2 de tu proveedor cubre su infraestructura, no tu aplicación ni cómo gestionas los accesos, y tu auditor te pedirá evidencia de que revisas ese informe como parte de la gestión de proveedores — incluido leer la sección de controles complementarios de la entidad usuaria, que es donde el proveedor enumera lo que espera que hagas tú. Ignorar esa sección es uno de los motivos más frecuentes de excepción en el primer Type II.

¿Podemos enseñar el informe SOC 2 a cualquiera?

No. Un informe SOC 2 es de uso restringido: se comparte con clientes, prospectos y sus auditores bajo acuerdo de confidencialidad, no se publica en la web. Lo que sí puede publicarse es la mención de que se dispone del informe y ponerlo a disposición bajo NDA. Conviene tener preparado ese flujo (quién lo envía, con qué NDA) antes de que lo pida el primer prospecto, porque en la práctica lo piden en mitad de una negociación.

¿Qué le vamos a tener que dar al auditor durante el periodo?

Acceso de lectura o capturas de tus sistemas de identidad, repositorio de código, gestor de tickets y consola cloud, más los registros de personal necesarios para probar altas, bajas y formación. El auditor no necesita acceso administrativo ni a los datos de tus clientes; trabaja con muestras. La carga real no es el acceso, es la recolección: si la evidencia no se va guardando a lo largo del periodo, reconstruirla al final es el punto donde se dispara el coste.

¿Qué pasa si el informe sale con excepciones?

Un informe con excepciones sigue siendo un informe válido y se puede compartir; no es un suspenso. El auditor describe la excepción y la dirección añade su respuesta explicando qué se corrigió. La mayoría de compradores lo acepta si la excepción es acotada y hay remediación documentada. Lo que sí levanta banderas es una opinión con salvedades sobre un control central como la gestión de accesos.