How to catch compliance in code review.
Practical, developer-register guides on doing compliance at the diff: what each framework actually checks in your repo, how to catch the common issues in review, and how to wire it into the pipeline you already run.
- Primer
Compliance as code: a practical primer
What it means to treat compliance like the rest of your engineering: defined, checked on every change, and grounded in a specific control rather than a quarterly document.
- Explainer
What SOC 2 actually checks in your repo
Most of SOC 2 is process and evidence. The part that lives in your codebase clusters in the CC6 logical-access family, and it is smaller and more concrete than people expect.
- Walkthrough
Catching a GDPR retention bug in code review
A walkthrough of the most common GDPR issue that ships through a normal pull request: personal data that outlives its purpose, and how to catch it at the diff.
- Playbook
Shift-left compliance for a small team
If you are a handful of engineers heading into your first audit, you do not need a GRC department. You need a few habits that keep compliance from becoming a quarterly emergency.
- How-to
Make compliance a required check, on your terms
A compliance review is most useful when it lives in the same place as your other checks. Here is how to think about blocking versus advisory, without turning your pipeline into a bottleneck.
- Walkthrough
Setting up heygrc: install, configure as code, review
Onboarding is one click plus a single API call your coding agent can make. Here is the whole flow, what each step does, and why heygrc never blocks a merge on its own.
- Explainer
Compliance checks in pull requests: what they are and how to add one
A compliance check on a pull request is not the green tick that says your tests passed. It reads the change against the frameworks you are audited on and names the control it touches. Here is what that looks like, and how to add one without turning your pipeline into a bottleneck.
- Map
Compliance automation tools for engineering teams
Most compliance-automation roundups list one category: platforms that manage the program and collect the evidence. Engineering teams touch a second layer too, the pull request where controls actually move. Here is a neutral map of both.
- Field guide
Compliance checks for AI-generated code
An AI agent can write code that is correct, safe, and appropriately licensed, and still move a control you are audited on. Bug, vulnerability, and license scanners are not built to read that. Here is what a compliance check for AI-generated code actually reads, with a worked example.
- How-to
Run heygrc alongside Cursor Bugbot
Bugbot reviews your pull requests for likely bugs and code quality. heygrc reads the same diff for the compliance control it touches. How to set up the pair, keep the comment volume sane, and decide what blocks a merge.
- How-to
Run heygrc alongside CodeRabbit
CodeRabbit reviews pull requests for bugs, quality, and best practices, and summarizes what changed. heygrc adds the missing citation: the compliance control a change touches. How to run both without doubling the noise.
- Field guide
EU AI Act for developers: Article 50 is live, high-risk is later
As of 2 August 2026, Article 50 transparency duties apply. The Digital Omnibus (Regulation (EU) 2026/1744) deferred most high-risk Chapter III duties to December 2027 and August 2028. What that calendar means in a pull request, with a worked disclosure-removal example.
- Explainer
DORA compliance for developers: what lands in a pull request
DORA is operational resilience law for EU financial entities, and for designated critical ICT third-party providers under direct oversight. Most of it is governance and testing. The slice that erodes in code is small, concrete, and easy to ship through a normal review. Which articles matter in a diff, a worked third-party example, and what a code review can actually catch.
- Explainer
NIS 2 software requirements: what lands in a pull request
NIS 2 sets cybersecurity risk-management duties for EU essential and important entities, and most coverage treats it as policy and process. One measure, secure development and vulnerability handling under Art. 21(2)(e), is decided by what actually ships. Which changes trip it, a worked example distinct from the framework hub, and what a review can and cannot catch.
- Playbook
How to pass SOC 2 as a startup
SOC 2 has no pass/fail board and no certificate. An auditor writes an opinion after checking whether your controls are designed well and, for a Type II report, whether they actually operated over a window of months. Type I versus Type II, what to scope, the realistic timeline, and where a pull-request check fits.
- Explainer
What a compliance bot for GitHub actually does
Search for a "compliance bot for GitHub" and you get chat bots, score dashboards, and evidence collectors. None of those is a framework-mapped reading of the pull request. Here is the product shape that is, how it installs, and how it differs from a compliance check in the abstract.
- Explainer
GDPR code review checks: which duties show up in a pull request
Most "GDPR code review" search results are cookie scanners or generic secure-coding essays. This is the PR-level map: Art. 5(1)(c) and (e), Art. 17, Art. 25, Art. 32, and Art. 44 as they appear in a diff, with a worked example that is not a retention bug.
- Explainer
SOC 2 change management in pull requests (CC8.1)
SOC 2 in pull requests is often reduced to "turn on branch protection." CC8.1 is also about whether a change actually went through the approvals and process you described. What a skipped approval looks like in a diff, and how that ties to a Type II observation window.
- Field guide
Cyber Resilience Act for developers: what can move in a pull request
CRA is product cybersecurity law for products with digital elements: SBOM, vulnerability handling, secure-by-design. Reporting obligations begin 11 September 2026; main obligations 11 December 2027. What a code review can actually catch, and what it cannot.