Compliance as code is the idea that a compliance obligation should be expressed and checked where the system actually lives, in the repository and the pipeline, rather than only in a policy document that an auditor samples once a year. It borrows the move that worked for testing and infrastructure: take something that used to be manual and periodic, and make it defined and continuous.
The three things it actually requires
First, the obligation has to be named at a grain you can check. "Improve our security posture" is not checkable; "a privileged role change must be logged, per ISO 27001:2022 A.8.15" is. Second, the check has to run where changes happen, on the pull request, not in a separate tool nobody opens. Third, when it flags something, it has to say which control and why, so the engineer can act without becoming a compliance expert.
Most teams already have the first ingredient buried in their frameworks and the second in their CI. What is usually missing is the translation layer that connects a concrete code change to the specific control it touches.
Why the diff is the right unit
A control does not degrade on a schedule. It degrades the moment someone widens a role, drops an encryption setting, or removes a log line. Each of those is a diff. If you check compliance at the diff, you catch the degradation at the moment it is introduced, while the author still has the context to fix it cheaply.
This is the same reason tests run on every change rather than once a quarter: the cost of a regression grows with the time between when it was introduced and when it was found.
Where heygrc fits
heygrc is built to be that translation layer: to read each pull request against the frameworks your company selected and name the specific control a change touches, as a review comment with the clause attached. It is not meant to replace your framework, your auditor, or your engineering judgment; the goal is to make the control visible at the diff so the decision is informed. heygrc is in early access.