GitHub issues, not privacy policies, are where compliance gets decided
arXiv:2512.10618 mined 32,820 law-related issues from 13,227 GitHub repositories and found engineers negotiating data-subject rights line by line, often without legal input. The empirical picture it produces overturns the comfortable assumption that a signed privacy policy corresponds to compliant code. In open-source practice, the issue tracker is the compliance artifact, and the maintainer is the de facto privacy officer.
Why are GitHub issues a compliance artifact now?
A privacy policy declares intent. An issue thread records what was actually built, debated, deferred, or quietly dropped. That distinction matters because the legal deadlines are no longer hypothetical.
The study dataset spans April 2016 through June 2024, bracketing both the GDPR enforcement date and the CCPA rollout, which is exactly the window in which privacy law stopped being a legal-department memo and started requiring code changes. A companion commit-level study (arXiv:2505.22234) examined 37,213 commits across 12,391 repositories and found that the bulk of privacy-law-related work landed in the year each statute took effect. The shape of that activity is reactive: a spike when the deadline bites, then a tail.
This is also the structural reason an issue tracker carries more compliance signal than a policy document. A policy is written once and edited by lawyers. An issue thread accumulates over years, written by whoever happened to be assigned the ticket, and it preserves the reasoning behind edge-case decisions in a way no policy ever does. For an auditor or a successor maintainer, the threads are the record of how the code’s privacy behavior was actually reasoned into existence.
What do 32,820 law-related issues actually discuss?
The researchers manually examined a representative sample of 1,186 issues and derived a taxonomy of 24 discussion categories grouped into six clusters: features and bugs, consent-related concerns, documentation, data storing and sharing, adaptability, and general compliance.
The headline finding is what the discussion is not about. Most threads concern user consent, user-rights functionality, bugs, and cookie management rather than abstract legal principles, according to the abstract. Developers are not litigating the meaning of “legitimate interest” in public. They are arguing about whether a consent banner fires twice, whether the erasure endpoint deletes derived records, and whether a third-party cookie loader can be made conditional.
That concentration is useful and also a warning. A cluster structure built from issue text tells you where developers spend effort, not where risk concentrates. A compliance gap in a low-discussion area, such as data sharing with subprocessors or cross-border transfer, may simply mean nobody opened a ticket, not that the code is correct. Absence of discussion is not evidence of compliance; in a sample built from issues, it is mostly evidence of silence.
Which rights do developers fixate on, and which do they ignore?
Three rights dominate the dataset: the right to erasure, the right to opt-out, and the right of access. Other rights receive comparatively little attention, the authors report.
This is a predictable skew, and the predictability is itself the finding. Erasure, opt-out, and access are the rights that map onto concrete, testable software behavior: a delete endpoint, a toggle, a data-export job. Rights that are harder to reduce to a function call, such as the right to object to specific processing or restrictions on automated decision-making, generate far fewer threads. The taxonomy is, in effect, a map of which legal obligations have a clean code surface and which have been quietly deferred because they do not.
The commit study reinforces the same asymmetry from a different angle. It found scarce reference to specific data-subject rights in commit messages, per arXiv:2505.22234, suggesting that even when code changes for privacy land, they are rarely labeled by the right they implement. A maintainer searching a history for “right to object” will find almost nothing, whether or not the obligation has been honored. The linkage between law and code is, in practice, lossy and unlabeled.
How does this shift liability from legal teams to maintainers?
The financial stakes are large enough to make the maintainer-as-privacy-officer framing uncomfortable. GDPR exposure can reach €20 million or 4% of global annual revenue, CCPA penalties can run to $7,500 per intentional violation, and breach notification windows are typically 72 hours, according to a 2026 legal guide for app developers. Those numbers attach to code behavior, and code behavior is set by the people writing the diff.
The trend line for who must implement this is moving toward developers, not away from them. Organizations are shifting from deploying AI and data systems to actively governing them, with state-level frameworks in Colorado, Texas, and Utah layering new obligations that have to be expressed in code, a 2026 legal forecast notes. Each new state statute adds another set of rights, toggles, and retention rules that someone has to translate into repository behavior. The legal team reviews the policy; the maintainer implements, and is responsible for, the mechanism.
For open-source maintainers the exposure is sharper still. A volunteer who accepts a PR that reintroduces a deleted tracking cookie is now the person whose commit broke a consent guarantee, with no legal review in the loop and often no clear assignee for the resulting liability. The taxonomy study’s central practical contribution is making that migration of responsibility visible: compliance is being negotiated in the open, by people who, as the angle notes, rarely have legal training.
What should privacy tooling learn from the taxonomy?
The honest answer is restraint. The taxonomy shows that developer privacy work clusters around consent, cookies, and a small set of rights-driven workflows. Those are exactly the areas where partial automation can help: a linter that flags a new cookie set without a consent check, a test harness that asserts an erasure endpoint also clears derived tables, a PR check that detects a new subprocessor data flow.
What the taxonomy does not justify is the marketing of “full automated GDPR/CCPA code scanning.” Most of the discussion the study captured concerns runtime consent and user-rights behavior, not static-code facts that a scanner can fully validate. A tool cannot statically prove that a consent banner was shown before a tracker loaded in a real browser session, or that an export endpoint returns every copy of a user’s data across every store. Those are dynamic, integration-level properties. Vendors who claim complete coverage are claiming more than the source material supports.
The more defensible tooling bet is developer-led and grounded in the rights surface. Hook consent checks into CI. Label commits by the data-subject right they implement, which the commit study suggests almost nobody does. Treat the issue tracker as a first-class compliance signal and make erasure and access endpoints exercisable in tests. None of that closes the liability gap, but it narrows the distance between what the law demands and what the repository can demonstrate.
Where do the study’s limits leave room for skepticism?
The authors are explicit about the ceiling on their method. An issue-based analysis cannot prove source-code compliance, they caution, because it studies discussions rather than executing or verifying code. A repository with hundreds of GDPR-tagged, well-reasoned issues may still ship non-compliant behavior, and a repository with no such issues may simply lack the conversation. Issue volume measures engagement with the law, not adherence to it.
Two cautions follow for anyone using this work as a compliance benchmark. First, the dataset over-represents projects that discuss privacy in public at all. Internal enterprise code, where most liability actually lives, is invisible to this method, so the taxonomy describes open-source practice rather than industry-wide behavior. Second, the rights skew, erasure, opt-out, access, is a finding about developer attention, and it should not be read as a statement about which rights carry the most legal weight. The rights that are quiet in the data may be the ones most likely to produce a fine precisely because nobody is arguing about how to implement them.
The useful read of arXiv:2512.10618 is therefore narrow and honest: it is the best available map of where privacy-law obligations surface as concrete engineering work, drawn from the conversations that produce that work. It is not, and does not claim to be, a certificate of compliance. Teams building data-handling software should use it to prioritize, to scope audits, and to interrogate vendors who promise more than the source code can prove. The GDPR’s legal text still has the last word on what compliance means; this study simply shows who, in practice, is doing the reading.
Frequently Asked Questions
Does this issue-tracker compliance signal apply to internal, closed-source repositories?
No. The taxonomy is built only from public GitHub issues, so it describes open-source practice. Internal enterprise code, where most liability actually lives, is invisible to this method, and the sampled discussions end in June 2024, before the most recent U.S. state AI and privacy laws took effect.
How should a team evaluate a vendor that claims automated GDPR or CCPA code scanning?
Ask which of the 24 issue categories the tool can actually observe. Most scanning products look for static strings or policy presence, but the taxonomy shows the real work happens in runtime consent flows, cookie gating, and erasure or access workflows. A scanner that cannot exercise a real browser session or prove an export returns every copy is claiming coverage the study does not support.
What is the cheapest operational change teams can make after reading the taxonomy?
Label commits, issues, and pull requests by the data-subject right they implement. The companion commit study found almost no rights labeling in 37,213 commits, so maintainers cannot later grep for ‘right to object’ or ‘automated decision-making’ to confirm coverage. A consistent naming convention turns the tracker into a searchable compliance ledger.
Which rights are most likely to create liability because they are rarely discussed?
Rights that do not map to a single endpoint, such as objecting to specific processing or restricting automated decision-making. The dataset shows developers cluster around erasure, opt-out, and access because those have clear code surfaces. Newer state laws in Colorado, Texas, and Utah add algorithmic disclosure and opt-out obligations that the 2016-2024 sample barely covers, so those quiet surfaces are where an auditor or regulator is likely to find an un-ticketed gap.
