Every practice that matters in engineering eventually gets a name. This one is compliance review for pull requests: reading each change against the compliance frameworks your company must meet, and naming the specific control it touches, at the diff, before it merges. heygrc is our entrant in that category, but the category is bigger than any product, and it deserves its own argument.
Categories split, and code review is splitting now
Practices do not converge into one tool that does everything; they diverge into specialists. Code review already split once: correctness review (does this change work) and security review (is this change safe) are different questions, answered by different reviewers with different knowledge, on the same pull request. Nobody expects a linter to find an injection, and nobody expects a security scanner to catch an off-by-one.
Compliance is the third split. Whether a change moves a control you are audited on is not a correctness question and not a security question: a change can be correct, safe, and still widen an access path that SOC 2 CC6.1 cares about, or trim a log that ISO 27001:2022 A.8.15 expects to exist. Different question, different knowledge, same diff. When a question is asked often enough on its own terms, it becomes a category.
Why the category exists now and not five years ago
Two curves crossed. The first: AI assistance is increasing the amount of code teams produce, and human review attention per change has not scaled with it. Teams shipping with agents merge more changes, faster, with less human reading per line than the practice was built around.
The second: the compliance surface of the same codebases is growing. More companies pursue SOC 2 and ISO 27001 earlier; the GDPR has been joined by DORA, NIS 2, and the EU AI Act; and the obligations increasingly live in code, in retention bounds, access paths, logs, and model behavior. More changes, less human reading, more obligations per change: the compliance reading needs automation at the diff if it is going to happen consistently.
What the category is, and what it is not
A compliance reviewer for pull requests reads the change against the frameworks your company selected and grounds each finding in the specific control it touches, at a grain you can verify or dispute. It runs where code review already happens, and it informs rather than gates: findings are review comments and a check status, not a blocked merge.
It is not a GRC platform (it does not run your compliance program or collect your evidence), it is not an audit (it is the leading indicator on the same obligations the audit measures), and it is not a certification (a review is a reading, not a badge). Those tools keep their jobs. This category exists for the one job none of them does: the compliance question, asked of every diff, while the change is still cheap to fix.