Busca SOC 2 en pull requests y encontrarás principalmente listas de verificación de procesos: requerir revisiones, comprobaciones de estado y commits firmados. Esas configuraciones importan. Son evidencia de que existe un proceso de gestión de cambios. CC8.1 (gestión de cambios de Criterios Comunes) también se refiere a si el control operó para un cambio dado: ¿el cambio fue autorizado según lo que indica tu política, o una corrección urgente, un bot o un camino de emergencia omitió un paso requerido.
Esta guía se enfoca en el nivel de detalle de los pull requests. No vuelve a explicar Tipo I versus Tipo II (consulta /guides/how-to-pass-soc-2-as-a-startup) ni mapea toda la familia de acceso CC6 (consulta /guides/what-soc-2-actually-checks-in-your-repo). Se centra en la gestión de cambios en el momento en que se fusiona un pull request.
La protección de ramas es necesaria, pero no suficiente
Requerir una revisión de aprobación y una comprobación de CI exitosa es la línea base habitual. Los auditores verifican si ese proceso se ejecutó durante la ventana de observación. Un repositorio con protección activada aún puede generar excepciones cuando alguien fusiona con anulación de administrador, cuando una ruta de implementación omite la rama protegida o cuando una cuenta de automatización fusiona sin la aprobación humana que tu política exige.
La señal visible en el código no siempre está en el código fuente de la aplicación. A menudo está en archivos de flujo de trabajo, CODEOWNERS, scripts de implementación o un cambio de una línea en quién puede aprobar. Todos estos aún se registran como pull requests.
Ejemplo práctico: ruta de emergencia que omite la aprobación requerida
El equipo de guardia recibe una alerta. Un ingeniero abre un pull request que añade un trabajo workflow_dispatch con continue-on-error y una ruta que implementa en producción desde un fork personal usando un token de larga duración, documentado como "break-glass". Un segundo pull request el mismo día modifica CODEOWNERS para que esa ruta ya no requiera el equipo de plataforma. Ambos pull requests parecen higiene operativa. El código de la aplicación puede no cambiar en absoluto.
Lo que importa a CC8.1 es si los cambios en producción aún pasan por el proceso de cambio autorizado. Una ruta de emergencia que debilita permanentemente las aprobaciones requeridas es un cambio de control, no solo una comodidad. Durante una ventana de Tipo II, si el auditor selecciona implementaciones que usaron esa ruta sin la aprobación documentada, estarás explicando una excepción. Detectar los diffs de workflow y CODEOWNERS en el momento de la revisión es más económico que explicarlos seis meses después.
Cómo esto se relaciona con la ventana de observación (sin volver a explicar la auditoría)
En Tipo II, el auditor verifica si los controles operaron durante un período. Una sola aprobación omitida dentro de esa ventana puede convertirse en una excepción muestral, incluso si el resto del año estuvo impecable. Por eso, la higiene de gestión de cambios durante la ventana no es burocracia por sí misma, sino cómo evitas sorprender la opinión en la que has trabajado durante meses. Los detalles sobre preparación, alcance y selección del auditor se mantienen en la guía de proceso SOC 2 para startups.
Una verificación de cumplimiento en pull requests que menciona CC8.1 en una puerta de aprobación debilitada no aprueba la emergencia. Hace visible el cambio de proceso mientras el pull request aún está abierto.
Dónde encaja heygrc y el límite de honestidad
heygrc está diseñado para analizar pull requests frente a los marcos que seleccionaste, incluyendo SOC 2 cuando está habilitado, y para identificar criterios como CC8.1 cuando un cambio parece debilitar la gestión de cambios (puertas de aprobación, comprobaciones requeridas, autorización de implementación). No ejecuta tu auditoría, recopila evidencia de IdP o RRHH, ni emite una opinión.
Mantén tu revisor de calidad de código. CC8.1 se refiere a la integridad del proceso en el cambio, no a si la corrección urgente fue elegante.