Use heyGRC alongside your code reviewer
heyGRC is a compliance reviewer, not a code reviewer. It reads each pull request against the frameworks your company selected (ISO 27001, SOC 2, GDPR, and dozens more) plus your company context, and when a change touches a control it posts the control ID, the reasoning, and a check status.
That means it is designed to run next to whatever reviews your code today: Cursor Bugbot, CodeRabbit, GitHub Copilot code review, a security scanner, human reviewers. Same pull request, different question. heyGRC makes no claim about what those tools flag or miss; it simply answers a different question.
How the two reviews coexist on a PR
- Each app posts its own review and its own check. heyGRC posts one consolidated review per pass (inline findings batched into a single review), plus a neutral Checks status.
- Neither tool needs to know the other exists. There is no integration to configure and no ordering requirement.
- Findings route differently: code findings are fixed in the diff; compliance findings sometimes reach past it (a policy to update, evidence to capture). Treat heyGRC's findings as their own small queue.
Keeping the combined volume low
Set heyGRC's cadence in the console (per org, or override per repo); see Set up with your agent, step 4:
| Mode | Behavior |
|---|---|
auto | Reviews every PR when it is opened, reopened, or pushed to. |
auto_once | Reviews on open / reopen only, not on every commit. |
mention_only | Silent until someone comments /heygrc on the PR. |
Teams that already run a code-review bot usually start with auto_once or mention_only, then
tighten once the signal has earned trust.
Blocking vs informing
By default the heyGRC check is neutral: it informs and the merge decision stays with your team. To make it blocking, mark the heyGRC check as required in GitHub branch protection, exactly like any CI job.
Setup
Install from github.com/apps/heygrc, then configure frameworks and company context with one API call; the fastest path is Set up with your agent.