Los ingenieros que se enfrentan por primera vez a SOC 2 suelen imaginarlo como una auditoría gigante de código. En realidad, no suele ser así. SOC 2 es una atestación frente a los Criterios de Servicios de Confianza, y la mayoría de esos criterios se refieren a políticas, procesos y evidencia de que los controles operaron durante un período. Solo una parte se decide por lo que hace tu código, y saber qué parte hace que todo el proceso sea menos misterioso.
Los criterios que afectan al código
Los criterios orientados al código se agrupan en la familia CC6 de criterios comunes para acceso lógico: CC6.1 (restringir el acceso a lo que necesita un rol), CC6.6 (proteger contra amenazas desde fuera del límite del sistema), CC6.7 (proteger los datos en tránsito y su movimiento), además de CC7.2 para el monitoreo y CC8.1 para la gestión de cambios. Si puedes razonar sobre quién puede acceder a qué, cómo se protegen los datos en tránsito y qué se registra, estás cubriendo la mayor parte de la superficie de SOC 2 relacionada con el código.
Es importante destacar que gran parte de lo que parece relacionado con SOC 2 en ingeniería (la existencia de revisiones de código, aprobaciones de cambios, revisiones de acceso) es evidencia de que un proceso operó, recopilada fuera del código. El código en sí habla principalmente de la familia CC6.
Las excepciones que se convierten en hallazgos
Un auditor muestreará estos controles durante un período y emitirá una opinión. Una sola solicitud de extracción que amplíe un rol de IAM a un comodín o elimine un mínimo de TLS puede generar una excepción en ese período: el control puede no haber operado como se describió para ese cambio. Si se detecta en la PR, es una corrección de una línea. Si se detecta en la auditoría, es una remediación con un rastro en papel.
Esa asimetría es el argumento principal para verificar la superficie CC6 en el diff en lugar de descubrir excepciones meses después.