Most teams that take pull requests seriously already run a reviewer or two on every change. A bug checker like Cursor Bugbot or CodeRabbit reads the diff and asks whether the code is correct. A security agent reads it and asks whether the code is safe: an injection, a broken access check, a leaked secret. Both answer real questions, and a serious change deserves both.
There is a third question that code review rarely puts an owner on: does this change still hold up against the compliance frameworks your company is audited on? Not 'is it a bug' and not 'is it a vulnerability,' but 'does it touch a control in SOC 2, ISO 27001 or the GDPR, and is the evidence still true after it ships.' It is a different question from correctness and from security, and it is the one heygrc is built for. It sits alongside the other two rather than replacing either.
Correct, secure, and still a finding
The three questions are independent. A change can be a bug and not a vulnerability. It can be a vulnerability and not a compliance problem. And it can be clean, working code that still moves a control you will be audited on. That last case is the one that rarely has a reviewer in the room.
Here is the kind of change we mean. Treat it as illustrative: one line of clean code that compiles and runs, and is neither the bug nor the vulnerability in the diff.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}The branch is clean, working code: it returns a decision and nothing about it is a bug or a vulnerability. But it makes a solely automated decision about a person, denying their refund, with no path to human review. Where a decision like that produces a legal or similarly significant effect, GDPR Art. 22 gives the person the right not to be subject to it and the right to obtain human intervention. What this change really shipped is a compliance question to answer, not a defect to fix.
Why the third question has no owner
A bug checker and a security agent can be framework-blind on purpose, and that is their strength. Their rules are universal: a use-after-free is a use-after-free in every repository, an unparameterised query is an injection everywhere. Universal rules are why those tools work out of the box.
Compliance is the opposite. Whether a change is a finding depends on which frameworks you are bound to, which controls you wrote down, and what your last audit relied on. The same diff that is nothing for one company is a SOC 2 CC7.2 evidence gap for the next. That is not something a framework-blind rule can carry on its own, because the problem is not a property of the code. It is a property of your obligations, and it has to be read against them.
Stack the lenses, do not choose between them
The takeaway is not 'add another tool.' It is that a pull request is read most completely through three lenses, not one: is it correct, is it secure, does it still meet our frameworks. Keep your bug checker. Keep your security agent. They are good at their questions, and heygrc does not try to answer theirs. heygrc adds the third lens, and reports it the only way a compliance finding is worth anything, by citing the exact control it touches.
The example above is illustrative, the kind of change that raises the third question, not a specific incident. But the shape is the whole point: the changes that move your compliance posture are usually not the buggy ones or the insecure ones. They are the clean, correct-looking ones that quietly touch a control, which is a different thing to be looking for than a bug or a vulnerability.