"Compliance bot for GitHub" is a search people type when they want something that sits on their repositories and flags compliance issues without them opening a separate GRC console. The results are a mess of shapes that share the word "compliance" and almost nothing else: bots that post status comments, tools that download GitHub's own compliance *reports*, evidence collectors that ask whether branch protection is on, and chat apps that have nothing to do with code review. This guide names the shape that answers the real intent: a bot that reads each pull request against the frameworks you selected and cites a control at the diff.
It is deliberately not the same page as the flagship guide on compliance checks in pull requests. That guide answers what a compliance *check* is (the concept: advisory status, control citation, branch-protection choice). This one answers what a compliance *bot* product is (the installable thing, the event loop, the permissions, and what it is not).
Four things people mean by "compliance bot" (only one is the product)
First: a chat or ticket bot that answers policy questions in Slack. Useful for people, not for pull requests. Second: a reporting connector that exports GitHub audit or compliance reports for an auditor. That is evidence export, not a reading of a change. Third: an evidence collector or GRC platform that checks whether required repository settings (branch protection, required reviews, signed commits) are configured. That is process evidence for the programme layer. Fourth: a GitHub App that, on each pull request event, reviews the diff against named framework controls and posts a review and an optional check status. Only the fourth is a framework-mapped compliance bot for pull requests.
If your search results are full of the first three, you are not wrong about the need. The category noun for the fourth is still new: compliance review for pull requests. A bot is just how that review is delivered on GitHub.
What the bot does on a real pull request
On install, the bot attaches to the repositories you choose. When a pull request opens, updates, or is reopened (depending on the run mode you configure), it reads the change, compares it to the frameworks your organisation selected, and if a control is implicated it posts a review comment that names the clause (for example SOC 2 CC6.1 on a widened IAM role, or GDPR Art. 5(1)(c) on a log that captures a full identity record). It can also post a GitHub Check with a neutral status so the finding is visible without blocking the merge by default.
The useful default for a compliance bot is advisory: surface the control, leave the merge decision to your branch-protection policy. A bot that hard-blocks every finding trains people to mute it. A bot that never appears in the review thread is ignored. Neutral status plus a clear citation is the design that keeps the signal without becoming theater.
What it is not (so you do not buy the wrong thing)
It is not your auditor, your SOC 2 opinion, or a certificate. It is not a GRC platform that collects evidence across identity, HR, and cloud for the whole observation window. It is not a secret scanner, SAST tool, or dependency advisor, though those tools often share the same pull request thread and should keep running. It is not a replacement for Bugbot, CodeRabbit, or any code-quality reviewer: those ask whether the code is correct and safe; the compliance bot asks whether the change moved a control you will be assessed on.
If you need programme-level evidence automation, buy or keep a GRC platform. If you need vulnerability findings, keep your security scanners. The compliance bot's job is the third question on the same pull request: does this diff touch a control, and which one.
How heygrc implements that shape
heygrc is a GitHub App that does compliance review for pull requests: install on the repos you care about, select frameworks, and it posts control-cited findings at the diff. Public repositories are free; private repositories start with a free monthly allowance and a short unlimited trial when you claim the install in the console. It never blocks merges by default. You can require the check in branch protection yourself if your policy needs gating.
See a live example on the public demo repository, where prepared pull requests show real reviews against SOC 2, ISO 27001, and GDPR controls on clean synthetic code. For the concept of the check itself, read the flagship guide. For setup, read the agent-oriented install walkthrough.