El cumplimiento como código es la idea de que una obligación de cumplimiento debe expresarse y verificarse donde realmente reside el sistema, en el repositorio y en el pipeline, en lugar de solo en un documento de política que un auditor revisa una vez al año. Toma prestado el enfoque que funcionó para las pruebas y la infraestructura: convertir algo que solía ser manual y periódico en algo definido y continuo.
Las tres cosas que realmente requiere
Primero, la obligación debe estar definida en un nivel de detalle verificable. 'Mejorar nuestra postura de seguridad' no es verificable; 'un cambio en un rol privilegiado debe registrarse, según ISO 27001:2022 A.8.15' sí lo es. Segundo, la verificación debe ejecutarse donde ocurren los cambios, en la solicitud de extracción, no en una herramienta separada que nadie usa. Tercero, cuando detecta algo, debe indicar qué control y por qué, para que el ingeniero pueda actuar sin convertirse en un experto en cumplimiento.
La mayoría de los equipos ya tienen el primer ingrediente en sus marcos de trabajo y el segundo en su CI. Lo que suele faltar es la capa de traducción que conecta un cambio de código concreto con el control específico que afecta.
Por qué el diff es la unidad adecuada
Un control no se degrada según un calendario. Se degrada en el momento en que alguien amplía un rol, elimina una configuración de cifrado o quita una línea de registro. Cada uno de esos casos es un diff. Si verificas el cumplimiento en el diff, detectas la degradación en el momento en que se introduce, mientras el autor aún tiene el contexto para corregirlo de manera económica.
Esta es la misma razón por la que las pruebas se ejecutan en cada cambio en lugar de una vez al trimestre: el costo de una regresión crece con el tiempo entre su introducción y su detección.
Dónde encaja heygrc
heygrc está diseñado para ser esa capa de traducción: para leer cada solicitud de extracción frente a los marcos que tu empresa ha seleccionado y nombrar el control específico que afecta un cambio, como un comentario de revisión con la cláusula adjunta. No está pensado para reemplazar tu marco de trabajo, tu auditor o tu criterio de ingeniería; el objetivo es hacer visible el control en el diff para que la decisión esté informada.