SOC 2 para startups: qué es, Type I vs Type II y cómo un equipo ágil se prepara para la auditoría

Qué es SOC 2 en realidad (y qué no es)

SOC 2 es un informe de atestación definido por la AICPA (American Institute of Certified Public Accountants), producido bajo la norma de atestación SSAE 18 (AT-C 105 y AT-C 205). La sigla proviene de System and Organization Controls. A diferencia de una certificación como la ISO/IEC 27001 —en la que un organismo certificador emite un certificado estandarizado—, el SOC 2 es un documento descriptivo: el auditor evalúa los controles de tu empresa de servicios contra los Trust Services Criteria y emite una opinión. Por eso el cliente no recibe un 'sello' para el sitio; recibe (en general bajo NDA) un informe que puede llegar a decenas de páginas, con la descripción del sistema, la tabla de controles y las pruebas realizadas.

Es útil separar la familia SOC. El SOC 1 trata de controles relevantes para los estados financieros de los clientes (ICFR) y es una auditoría del mundo contable. El SOC 2 trata de controles operacionales de seguridad y afines, y es lo que pide el mercado de software y fintech. Existe además el SOC 3, que es una versión resumida y pública del SOC 2, útil para publicar en el sitio sin exponer los detalles del informe completo. Para una startup que vende SaaS, el objetivo casi siempre es el SOC 2; el SOC 3 es un derivado opcional.

Quién lo emite es una parte esencial. SOC 2 solo puede ser firmado por un CPA licenciado o por una firma de CPA registrada, no por una consultoría de seguridad, ni por la propia Decripte o por cualquier socio que prepare a la empresa. Esto es por diseño: la atestación exige independencia del auditor. El rol de un socio de preparación es distinto y legítimo: implementar controles, cerrar brechas, organizar evidencia y conducir un readiness assessment antes de que el auditor entre. Confundir ambos roles es un error común: la empresa que 'audita' y 'prepara' al mismo tiempo compromete la independencia que le da valor al informe.

Vale decir qué no significa el informe. Un SOC 2 limpio (opinión sin salvedades) atesta que, en el alcance definido y en el período evaluado, tus controles fueron diseñados de forma adecuada y —en el Type II— operaron con efectividad. No es garantía de que nunca tendrás un incidente, ni cubre sistemas fuera del alcance. Leer la sección de alcance y la opinión del auditor es tan importante como comprobar si el informe existe.

Los 5 Trust Services Criteria: qué entra en tu alcance

Los Trust Services Criteria (TSC) son las cinco categorías de la AICPA contra las cuales el auditor evalúa tus controles. La primera, Security, es obligatoria en todo SOC 2 y también se denomina Common Criteria (CC1 a CC9). Cubre la base: entorno de control y gobernanza, comunicación, evaluación de riesgo, actividades de monitoreo, controles lógicos y físicos de acceso, operaciones de sistema, gestión de cambios y mitigación de riesgo. En la práctica, es donde residen MFA, gestión de accesos, logging, respuesta a incidentes, gestión de vulnerabilidades y cambios. Los otros cuatro criterios se agregan al alcance según la promesa que tu empresa le hace al cliente: agregar un criterio significa más controles a diseñar y más evidencia a producir, así que la decisión es estratégica, no automática.

Availability (disponibilidad) cubre si el sistema está disponible para operación y uso conforme a lo comprometido. Entra cuando vendes un SLA de uptime o cuando la continuidad es parte central del valor: aquí aparecen el monitoreo de capacidad, los backups, la recuperación ante desastres y las pruebas del plan de continuidad. Confidentiality (confidencialidad) trata de la protección de información designada como confidencial —cifrado, controles de acceso a datos sensibles, retención y descarte—. Es el criterio más comúnmente agregado por SaaS B2B porque cubre el dato del cliente que no es necesariamente dato personal (contratos, código, datos de negocio).

Processing Integrity (integridad de procesamiento) verifica si el procesamiento del sistema es completo, válido, preciso, oportuno y autorizado. Tiene sentido para empresas cuyo núcleo es procesar transacciones o calcular resultados —fintechs de pago, nómina, conciliación, antifraude— donde el cliente necesita confiar en que lo que entra se procesa correctamente. Privacy (privacidad) trata de la recolección, uso, retención, divulgación y descarte de información personal de acuerdo con el aviso de privacidad de la entidad y con los criterios de la AICPA. Atención a una confusión frecuente: Privacy trata datos personales de individuos; Confidentiality trata información confidencial en general. Muchas startups que ya tratan la LGPD se benefician de incluir Privacy, pero eso amplía el alcance y la evidencia exigida.

La regla práctica de alcance para una startup ágil: comienza con Security (que es obligatorio) y agrega solo los criterios que de hecho prometes contractualmente o que destraban el pipeline actual. Confidentiality suele ser el primer añadido natural para SaaS; Availability entra cuando hay SLA; Processing Integrity y Privacy entran cuando el modelo de negocio los vuelve materiales. Cada criterio extra agrega controles y meses de evidencia: un alcance deliberado es lo que mantiene el proyecto viable para un equipo pequeño.

Type I vs Type II: fotografía contra película

La distinción más consecuente del SOC 2 es entre los dos tipos de informe, y determina el cronograma, el costo y el peso del documento en la mesa de negociación. El SOC 2 Type I evalúa, en una fecha específica (as of date), si los controles están diseñados e implementados de forma adecuada para atender los criterios elegidos. Es una fotografía: el auditor verifica que el control existe y está bien diseñado en ese punto. Por eso es más rápido de obtener: tan pronto como los controles están implementados, puedes hacer un Type I en semanas.

El SOC 2 Type II evalúa el diseño y la efectividad operacional de los controles a lo largo de un período de observación, típicamente de 3, 6 o 12 meses. Es una película: el auditor no pregunta solo '¿el control existe?', sino '¿operó de forma consistente durante toda la ventana?'. Para ello realiza pruebas de muestreo a lo largo del período —por ejemplo, selecciona un subconjunto de cambios de código del trimestre y verifica si cada uno pasó por la aprobación exigida, o muestrea nuevos colaboradores y comprueba si el aprovisionamiento de acceso siguió la política—. Un control que falló en parte del período, o cuya evidencia no existe para toda la ventana, genera una excepción (exception) descrita en el informe.

En la decisión de secuenciamiento, el patrón más común para una startup es usar el Type I como puente. Implementas los controles, emites un Type I para tener algo concreto que mostrar rápido mientras cierras deals que aceptan un informe inicial, y simultáneamente entras en el período de observación del Type II. Esto evita esperar meses sin ningún artefacto. Los clientes en EE. UU. suelen aceptar un Type I de un proveedor joven como medida transitoria, pero la expectativa casi universal es que el próximo ciclo entregue un Type II, y de ahí en adelante la renovación del Type II se vuelve anual y continua, con períodos que se empalman para no dejar lagunas (gaps de cobertura) entre informes.

El punto que los founders subestiman: el período de observación del Type II no se acelera con dinero. Puedes contratar al mejor auditor y la mejor plataforma, pero si el alcance pide tres meses de operación, son tres meses de evidencia que deben acumularse de verdad. Por eso el reloj del Type II debe empezar a correr temprano —tan pronto como los controles estén operando— para que el informe esté listo cuando el pipeline lo exija.

Evidencia, el readiness assessment y el rol del auditor

El corazón operacional de un SOC 2 es la evidencia. Cada control declarado en la descripción del sistema necesita prueba de que existe y —en el Type II— de que operó durante todo el período. La evidencia es el registro concreto: la configuración que fuerza MFA, el log de revisión trimestral de accesos con fecha y responsable, el ticket de offboarding que muestra que el acceso de un ex colaborador fue revocado dentro del SLA interno, el pull request con aprobación obligatoria antes del merge, el informe de pentest y el registro del retest, la alerta de monitoreo y el ticket de tratamiento. La lección central: diseña los controles para generar evidencia automáticamente. Un control que depende de que alguien recuerde tomar una captura mensual va a fallar en el muestreo del Type II.

Antes de que el auditor entre, el paso de mayor retorno es el readiness assessment (evaluación de preparación), también llamado gap assessment. Aquí un socio de preparación mapea tus controles actuales contra los criterios del alcance, identifica brechas, ayuda a implementar lo que falta y valida que la evidencia se esté recopilando del modo en que el auditor querrá verla. Ese trabajo es independiente de la auditoría: es exactamente lo que hace Decripte dentro de la Seguridad Normativa —estructurar controles y conformidad, conducir el pentest que el alcance de Security frecuentemente exige, y organizar la evidencia para que llegues al auditor sin sorpresas—. El plan gratuito de Gestión de Amenazas ayuda a establecer la visibilidad inicial —monitoreo e identificación de exposiciones— que alimenta varios controles del Common Criteria.

El rol del auditor (CPA) es deliberadamente separado. Revisa la descripción del sistema escrita por ti, prueba el diseño de los controles (Type I) y, en el Type II, ejecuta pruebas de operación sobre muestras del período. Al final emite la opinión: sin salvedades (unqualified) cuando los controles atienden los criterios; con salvedad (qualified) cuando hay excepciones relevantes; y variaciones más graves en casos extremos. La independencia exige que quien prepara a la empresa no sea quien firma el informe: mantener esos roles en organizaciones distintas es lo que preserva la credibilidad del SOC 2 ante el cliente.

Vale calibrar la expectativa sobre las herramientas. Las plataformas de automatización de conformidad se integran con tus sistemas de nube, RR. HH. y código para recopilar evidencia continuamente y mapearla a los criterios. Reducen el trabajo manual, pero no sustituyen el diseño correcto de los controles ni el juicio de alcance: automatizar un control mal diseñado solo produce evidencia consistente de algo incorrecto. La combinación eficiente para una startup es: plataforma para la recolección continua, socio de preparación para el diseño y la corrección, y CPA independiente para la atestación.

Cómo una startup ágil se prepara y obtiene el SOC 2

El secuenciamiento sensato comienza por la decisión de alcance, no por la elección del auditor. Define el sistema (qué productos, entornos y equipos entran), los criterios (Security más lo que prometes) y el tipo de informe que el pipeline exige. Esa definición es la palanca que más afecta el plazo y el costo: un alcance demasiado amplio multiplica controles y evidencia; un alcance ágil y defendible entrega valor comercial más rápido. Para la mayoría de las startups B2B el punto de partida es Security más Confidentiality, con Type I como puente y Type II en secuencia.

En seguida viene la base de controles y políticas, que se superpone fuertemente a lo que ya exigiría cualquier cliente enterprise: MFA en accesos de producción y administración, cifrado en tránsito y en reposo, gestión de identidad con privilegio mínimo, logging y monitoreo centralizados, gestión de vulnerabilidades, backups probados, plan de respuesta a incidentes, gestión de cambios con aprobación, gestión de proveedores y un ciclo de desarrollo seguro. Frameworks como el NIST Cybersecurity Framework 2.0 y los CIS Critical Security Controls sirven de mapa para no olvidar categorías, y quien apunta a SOC 2 e ISO 27001 al mismo tiempo aprovecha que buena parte de los controles es común a ambos.

Con los controles implementados, inicia la recolección de evidencia y el período de observación del Type II lo antes posible: el reloj solo corre después de que los controles están operando. Conduce un readiness assessment para cerrar brechas antes de la auditoría, haz el pentest y corrige los hallazgos por severidad, y solo entonces contrata al CPA independiente para la atestación. Tratar la secuencia en ese orden evita el error más caro: llamar al auditor demasiado pronto, cosechar excepciones evitables y tener que rehacer el ciclo.

Sobre hacerlo interno versus tercerizar: para una startup antes de la madurez de un equipo de seguridad dedicado, el modelo eficiente combina un responsable interno (el primer hire de seguridad o el propio CTO al inicio) con socios externos para lo que exige especialización e independencia —readiness, pentest y soporte a la auditoría— y un CPA separado para firmar. Es exactamente ese arreglo el que sostiene Decripte: visibilidad continua de amenazas en el plan gratuito de Gestión de Amenazas, y Seguridad Normativa para conformidad, controles, pentest y monitoreo, de modo que llegues al auditor con las brechas cerradas y la evidencia organizada, sin inflar headcount y con el cronograma de seguridad acompañando al de ventas.

Checklist práctico

1. 1

   1. Define el alcance antes que nada

   Delimita el sistema evaluado (productos, entornos, equipos), elige los Trust Services Criteria (Security es obligatorio; agrega Confidentiality, Availability, Processing Integrity o Privacy solo según lo que le prometes al cliente) y decide Type I, Type II o Type I como puente hacia el Type II. Un alcance ágil es la mayor palanca de plazo y costo.

2. 2

   2. Implementa los controles del Common Criteria

   Cubre la base de Security (CC1 a CC9): MFA en producción y administración, cifrado en tránsito y en reposo, gestión de identidad con privilegio mínimo, logging y monitoreo, gestión de vulnerabilidades y cambios, backups probados y respuesta a incidentes. Usa NIST CSF 2.0 y CIS Controls como mapa de cobertura.

3. 3

   3. Formaliza las políticas y diseña controles que generen evidencia

   Escribe políticas reales de seguridad, control de acceso, cambios, respuesta a incidentes, proveedores y desarrollo seguro. Diseña cada control para producir prueba automática —logs, tickets, aprobaciones de pull request, registros fechados de revisión de acceso— porque el Type II evalúa la operación consistente, no la intención.

4. 4

   4. Inicia la recolección de evidencia y el período de observación temprano

   Tan pronto como los controles operan, comienza a acumular evidencia y pon en marcha el reloj del período de observación del Type II (3, 6 o 12 meses). Una plataforma de automatización de conformidad ayuda a recopilar y mapear evidencia continuamente, pero no sustituye el diseño correcto de los controles.

5. 5

   5. Haz un readiness assessment y cierra las brechas

   Antes del auditor, conduce una evaluación de preparación (gap assessment) contra los criterios del alcance con un socio de preparación, corrige las brechas y valida que la evidencia esté en el formato que el auditor va a muestrear. Este paso evita excepciones evitables en el informe.

6. 6

   6. Realiza el pentest y corrige por severidad

   El criterio Security frecuentemente exige una prueba de penetración. Contrata un pentest independiente alineado a OWASP, prioriza la corrección por severidad y solicita el retest. Guarda el informe y la evidencia de remediación como parte del paquete de controles.

7. 7

   7. Contrata al CPA independiente para la atestación

   Selecciona una firma de CPA licenciada por la AICPA —separada de quien preparó a la empresa, para preservar la independencia—. El auditor revisa la descripción del sistema, prueba el diseño (Type I) y la operación (Type II) y emite la opinión. Planifica la renovación anual del Type II con períodos que se empalman para no dejar gaps de cobertura.

Preguntas frecuentes