"¿Cómo aprobamos SOC 2?" es la pregunta que la mayoría de las startups primerizas se hacen, y la respuesta honesta comienza corrigiendo la premisa. SOC 2 no es un examen con una puntuación de aprobación ni emite un certificado. Una firma de CPA independiente audita tus controles frente a los Criterios de Servicios de Confianza de AICPA y emite una opinión, un informe escrito que indica si los controles estaban diseñados adecuadamente y, en el caso del tipo de informe que casi todos los compradores exigen, si operaron de manera efectiva durante un período de observación. "Aprobar" significa que la opinión del auditor no tiene salvedades: sin excepciones lo suficientemente graves como para calificarla. Todo lo que sigue es el proceso que lleva a una startup a obtener esa opinión sin salvedades, y se trata principalmente de alcance y disciplina, no de una lista de cambios de código.
Tipo I frente a Tipo II, y por qué el Tipo II es el que importa
Un informe Tipo I verifica si tus controles están diseñados adecuadamente en una fecha específica. Responde a la pregunta: "si estos controles operaran como se describe, ¿cumplirían los criterios?", pero no dice nada sobre si realmente se mantuvieron en la práctica. Un informe Tipo II verifica los mismos controles en cuanto a su efectividad operativa durante un período de observación, comúnmente tres meses para un primer informe y de seis a doce meses para una renovación. Responde la pregunta que realmente interesa a las revisiones de seguridad de los compradores: ¿se mantuvieron el control de acceso, la gestión de cambios y la monitorización durante un período real, no solo en el papel?
La mayoría de las startups finalmente necesitan el Tipo II, porque es lo que cada vez más exigen las compras empresariales y los cuestionarios de seguridad de proveedores. El Tipo I aún tiene su papel: es más rápido de producir (no hay que esperar un período) y algunas startups lo usan como primer artefacto para demostrar avances en un acuerdo temprano con una empresa mientras el período de observación del Tipo II se ejecuta en paralelo. Ninguno de los informes es una certificación y ninguno tiene una puntuación numérica; el entregable es un informe que incluye la descripción del sistema y los controles (por parte de la dirección), la afirmación de la empresa, las pruebas y resultados del auditor para un Tipo II, y la opinión del auditor.
Define el alcance antes de construir un solo control: solo Seguridad es obligatorio
SOC 2 se organiza en torno a cinco Categorías de Servicios de Confianza: Seguridad, Disponibilidad, Confidencialidad, Integridad del Procesamiento y Privacidad. Seguridad, los Criterios Comunes (los criterios numerados CC, del CC1 al CC9), es la única categoría obligatoria; todos los informes SOC 2 la incluyen. Las otras cuatro son opcionales, y una startup que incluye las cinco por defecto suele estar construyendo y documentando controles que nadie ha solicitado.
Define el alcance en función de lo que realmente exigen las revisiones de seguridad de tus compradores, no a partir de una plantilla. Una empresa B2B SaaS suele incluir Seguridad más Disponibilidad (compromiso de tiempo de actividad) y Confidencialidad (manejas datos empresariales de clientes bajo una obligación similar a un NDA). La Integridad del Procesamiento importa principalmente si la función central de tu sistema es procesar transacciones donde la completitud y precisión de ese procesamiento es la promesa del producto, como en pagos o facturación, no solo "tenemos una base de datos". Privacidad es la categoría de AICPA para los compromisos de manejo de información personal en tu propia política de privacidad, algo distinto a GDPR u otras leyes de privacidad; la mayoría de las startups cumplen con las expectativas de los compradores en el manejo de datos personales sin necesidad de incluirla. Pregunta a tus primeros clientes empresariales qué exige su equipo de seguridad de proveedores antes de comprometerte con un alcance; es mucho más económico añadir una categoría después que haber documentado una que nadie necesitaba.
El cronograma realista
Primero viene la preparación: un análisis de brechas frente a los criterios que definiste, la redacción de las políticas que requieren los criterios (control de acceso, gestión de cambios, respuesta a incidentes, entre otras) y el cierre de las brechas de control en tus sistemas reales (implementación de MFA, activación de registros de auditoría, formalización de un paso de aprobación de cambios). Para una startup pequeña que usa una plataforma de automatización de cumplimiento para rastrear evidencia y controles, la preparación suele tomar de cuatro a ocho semanas; más tiempo si un control debe construirse en lugar de solo documentarse, como implementar un registro centralizado que no existía antes.
Para un informe Tipo II, el período de observación es el siguiente paso, y su duración no puede acortarse: los controles deben operar durante un período acordado antes de que el auditor pueda probarlos, por lo que un período de tres meses son tres meses calendario, no un lote de evidencia recopilada después de los hechos. No hay un mínimo legal universal; el período se acuerda con tu firma de CPA y se define según lo que esperan los usuarios previstos del informe. Los primeros informes suelen cubrir de tres a seis meses, y las renovaciones, de seis a doce. Durante el período, los controles en el alcance deben operar de manera consistente: una brecha puede convertirse en una excepción muestreada según las pruebas del auditor, su naturaleza, frecuencia y relevancia, no automáticamente.
El trabajo de campo de la auditoría sigue al período: el auditor revisa la evidencia, muestrea transacciones y cambios, entrevista a los responsables de los controles y redacta los hallazgos, generalmente en dos a cuatro semanas, y luego emite el informe final. En total, el primer informe Tipo II de una startup suele tardar de cinco a nueve meses desde el inicio hasta el informe en mano como referencia típica, no como requisito de AICPA. Trata con cuidado las promesas de "SOC 2 en un mes": suelen referirse a trabajo de preparación, un informe Tipo I o un período de informe excepcionalmente corto aceptado por un auditor específico, no a un Tipo II convencional de varios meses.
Qué puede romper un período de observación
El período de observación es donde la mayoría de las startups primerizas se llevan una sorpresa desagradable, porque es lo suficientemente largo como para que el trabajo de ingeniería normal pueda deshacer silenciosamente un control que la fase de preparación acababa de implementar. Una solicitud de pull request que amplía una política de IAM a un comodín por comodidad, una limpieza que elimina la línea de registro de auditoría de una acción privilegiada, una corrección urgente que omite el paso habitual de aprobación de cambios bajo presión de plazo: ninguna de estas acciones parece trabajo de cumplimiento mientras ocurren, y cada una es exactamente el tipo de cosa que puede convertirse en una excepción muestreada si se implementa dentro del período y el auditor la detecta en sus pruebas. Los detalles a nivel de control sobre qué criterios aparecen realmente en un diff, principalmente la familia CC6 de acceso lógico más CC7.2 de monitorización y CC8.1 de gestión de cambios, se encuentran en el análisis en profundidad del marco SOC 2 y en la guía complementaria sobre qué verifica SOC 2 en tu repositorio.
Esta es la capa que añade una revisión de cumplimiento a nivel de pull request durante el período: lee cada cambio frente a los criterios que definiste y nombra el que afecta, por ejemplo CC6.1 en la política de IAM ampliada, como un comentario de revisión en el momento en que se propone el cambio. Si se detecta allí, el equipo puede evaluarlo y corregirlo antes de que se implemente, generalmente mucho más económico que después de los hechos. Si no se detecta, es un cambio que el auditor podría muestrear como una excepción que tendrías que explicar, lo que podría complicar la opinión en la que has trabajado durante meses.
Qué no reemplaza esto
Una revisión de pull request es una capa de un proceso mucho más amplio, y vale la pena ser preciso sobre el resto, porque ninguna de esas partes es responsabilidad de heygrc. Elegir tu auditor, definir el alcance de tus categorías de confianza, redactar tus políticas, realizar el análisis de brechas de preparación, recopilar evidencia en toda tu pila (proveedor de identidad, configuración en la nube, incorporación y desvinculación de RRHH, gestión de proveedores) durante todo el período de observación e emitir la opinión: todo eso es el programa de cumplimiento, que generalmente se gestiona a través de una plataforma diseñada para ello (la guía sobre herramientas de automatización de cumplimiento describe esa capa) más tu auditor. heygrc está diseñado para leer las solicitudes de pull request frente a los criterios que seleccionaste y nombrar el control que afecta un cambio. No realiza tu auditoría, no reemplaza a tu auditor y no te lleva por sí solo a una opinión sin salvedades; está diseñado para ayudar al equipo a detectar cambios relevantes en las solicitudes de pull request a tiempo, durante el programa, antes de que puedan convertirse en el tipo de excepción que dificulta obtener la opinión.