The measures around personal data, decided in code.
Security of processing, Art. 32, is the GDPR's security duty: implement technical and organisational measures that give a level of security appropriate to the risk the processing carries. It names example measures: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of the systems, the ability to restore data in a timely manner after an incident, and regularly testing that the measures work. It does not prescribe a specific technology, and what is appropriate scales with the risk, but a store of personal data that quietly lost one of its measures is exactly the situation the article is written for. Those measures are provisioned and removed in code and config, which makes them pull-request decisions like any other.
The shapes the same control failure takes.
In a pull request, Art. 32 risk often appears as an ordinary change that removes or weakens one of the measures a store of personal data was relying on. The recurring shapes:
A store of personal data opens up
An access grant widens: a principal becomes a wildcard, a dashboard loses its auth, a role gets read on everything, so unauthorised access to stored personal data gets easier.
Pseudonymisation is bypassed
A pipeline or new integration starts flowing raw identifiers where pseudonymised ones used to flow, so an analysis or a tool now holds directly identifying data it did not need.
A copy loses the primary store's measures
A new export, replica, or mirror of personal data lands without the protections the main store has (encryption, scoped access), so the newest copy is the least protected one.
Availability measures are traded away
Redundancy or failover for a personal-data store is removed to save cost or simplify, leaving the data reachable only through a single component an incident can take out.
Timely restoration stops being proven
A scheduled restore drill or a recovery objective for a personal-data store is dropped, so whether access could be restored in time after an incident is assumed rather than tested.
An export bucket's read grant opened to any principal.
The data team wants to query a nightly export of the users table (names, emails, billing addresses, plan) without filing a ticket with engineering every time. A change edits the bucket policy so its read statement applies to any principal. The intent is fewer tickets and faster queries, but the policy statement's grant on a full copy of the users table now names every principal instead of the data-team role.
resource "aws_s3_bucket_policy" "user_exports" { bucket = aws_s3_bucket.user_exports.id policy = jsonencode({ Statement = [{ Effect = "Allow"- Principal = { AWS = aws_iam_role.data_team.arn }+ Principal = "*" Action = "s3:GetObject" Resource = "${aws_s3_bucket.user_exports.arn}/*" }] })}This rewrites the bucket's read grant from one named role to any principal. Unauthorised access to stored personal data is a risk Art. 32(2) names directly, and this is the kind of change a review weighs against it: unless another control (such as a Block Public Access setting on the bucket) is known to stop it, the export copy is now readable far beyond the data team. Scope the grant to the role that actually needs the export, or issue short-lived credentials, rather than widening it to every principal.
The measures are assessed before the incident, not after.
A data-protection review of security looks at the measures themselves: whether stores of personal data are encrypted where that is the appropriate measure, who and what can reach them, whether they can be restored in time after an incident, and whether any of it is actually tested. When a personal-data incident happens, this is a key article the security measures get assessed against, and the story behind the change is rarely exotic: a policy widened for convenience, an encryption setting dropped in a cleanup, a pipeline switched to raw identifiers. Each of those is an ordinary pull request, which is where a review can catch it.
A review, not your security program.
heygrc flags changes that weaken or remove a measure a store of personal data was relying on and cites the article so the choice is made in the pull request. It does not run your infrastructure, set your risk level, or decide whether a given measure is appropriate for your processing. It catches the moment the safeguard gets narrower, at the diff.