GDPR, reviewed in the pull request.
GDPR is a regulation, not a control catalog, so there is no clause that says line 40 is non-compliant. But several of its duties are decided entirely in code: what personal data you collect, how long you keep it, whether erasure reaches every copy, and where it flows. Those are the decisions a pull request makes, often without anyone noticing the article behind them.
The breach usually starts as an ordinary feature.
Most GDPR exposure does not arrive as a malicious change. It arrives as a helpful one: a new analytics event that happens to log an email, a table that grows without a retention rule, a debugging payload that carries more than it should. A linter cannot see it, because nothing is technically broken. heygrc reads the change against the articles your processing has to satisfy and names the duty the diff just touched, while it is still a review comment and not a regulator's question.
The GDPR duties a review can actually catch.
Each row is a real article reference and the kind of change that trips it. heygrc cites the article on the finding, not a vague privacy note.
- Art. 5(1)(c)data minimisation
A new field, log line, or analytics event starts capturing personal data the feature does not actually need, or a payload widens to carry more than the purpose requires.
- Art. 5(1)(e)storage limitation
A retention bound is removed or extended, a deletion job is disabled, or a new personal-data table ships with no expiry at all.
- Art. 6lawful basis
A processing path runs before the consent or lawful-basis check, or a consent gate is bypassed for a code path that handles personal data.
- Art. 17right to erasure
A new store of personal data is added that the delete-my-account path does not reach, leaving a copy that erasure cannot remove.
- Art. 25data protection by design and default
A default flips toward more exposure: a profile set public by default, an opt-out where the law expects opt-in, telemetry on out of the box.
- Art. 32security of processing
Personal data is written to logs in the clear, an encryption-at-rest setting is dropped, or access to a personal-data store widens.
- Art. 44international transfers
A new third-country processor or region is wired in for personal data without the transfer safeguards the chapter requires.
Per-duty deep dives:
A debug log that breaks Art. 5(1)(c).
A pull request adds a log line to debug a checkout issue. It logs the whole request, which includes the customer email and address: more personal data than the purpose needs, now sitting in a log store with its own retention.
export async function onCheckout(req: CheckoutRequest) {
+ logger.info("checkout received", { body: req }) const order = await createOrder(req)
return order
}This logs the full request body, which carries the customer email and address, into application logs. Art. 5(1)(c) (data minimisation) expects personal data to be limited to what the purpose needs, and Art. 32 covers how it is then secured. Log an order id and the fields you actually need to debug, not the whole personal-data payload.
A review, not legal advice.
heygrc flags changes that touch a GDPR duty and cites the article so the fix happens in the pull request. It is not a Data Protection Officer, does not render a legal determination, and does not replace your privacy counsel or your records of processing. It catches the change early so a privacy question is answered in code review instead of after an incident. heygrc is in early access.