Compliance belongs in the pull request.
We call the practice compliance review for pull requests: reading each change against the frameworks your company must meet, at the diff, not months later in an audit. These essays are the arguments behind that category. Short, opinionated, and written for the people who actually change the system: engineers and security engineers.
- 00
Compliance review for pull requests.
Code review is splitting into lenses: correctness, security, and now compliance. This essay names the third lens as a category and explains why it exists now.
- 01
Catch it at the PR, not the audit.
A compliance gap is cheapest to fix at the moment it is written, and most expensive the day an auditor finds it.
- 02
Compliance is a CI check, not a quarterly fire drill.
Treating compliance as an event you survive twice a year is why it feels like a fire drill. Treat it as a check that runs on every change and it gets boring, which is the goal.
- 03
Your linter is framework-blind.
Linters and scanners catch defects and vulnerability classes. A change can be flawless code and still break a compliance obligation, because the obligation is not a property of the code, it is a property of the framework.
- 04
Controls live in diffs, not Word docs.
A control written in a policy document is an intention. The control is only real where the running system enforces it, and the running system changes one diff at a time.
- 05
The audit is a lagging indicator.
An audit tells you what was true months ago. If that is the only signal you have, you are steering a system by looking in the rear-view mirror.