Yes. A repository is a storage system like any other, and GDPR attaches to personal data by what it is rather than where it sits. What makes repos and CI pipelines distinctive is not the legal analysis, which is ordinary, but the practical one: these are the places personal data arrives without anyone deciding to put it there, and git history is designed to make deletion difficult.
This article covers how personal data ends up in a codebase, why deleting it is not a revert, what CI retention does that you did not configure, how this differs from a logging problem, and what to actually do about it.
The Places Personal Data Ends Up In A Codebase
Nobody commits a customer database. Personal data reaches repositories by smaller routes, and every one of them looks harmless at the moment it happens.
Test fixtures and seed data are the largest source, because the fastest way to build a realistic fixture is to copy a real record. Bug reports carry screenshots with a real user's name, email and sometimes their session content. Debug output pasted into an issue thread contains a real payload. A .env file with a support mailbox, an on-call phone number or an API key tied to a named account gets committed once and never noticed. Analytics or migration scripts embed a sample of live rows so somebody could check the output.
CI adds its own layer. Build logs capture environment variables and request payloads. Test artefacts include the screenshots the browser tests took, which include whatever the seeded user was called. Failed-job output is verbose by design, and verbose output is exactly the output that contains data.
Deletion Is Not A Revert, And That Is The Hard Part
Everywhere else in your stack, deleting personal data means running a delete. In git, a commit that removes a file leaves the file in history, reachable by hash, present in every clone and every fork, and mirrored into whatever backup or archive service you have connected.
Removing it properly means rewriting history — filtering the object out, force-pushing, invalidating every existing clone, and coordinating with everyone who has one. On a shared repository that is disruptive enough that teams routinely decide not to. That decision is understandable and it is also a decision to retain personal data indefinitely, which is a storage limitation problem under Article 5(1)(e) whether or not anyone frames it that way.
Two consequences follow. First, prevention is worth far more here than remediation, because remediation is genuinely expensive. Second, if you receive an erasure request and the data is in git history, you need an honest answer about what you can and cannot remove rather than a confident one. That is the same discipline that applies to deleting personal data from backups, where the practical constraint is similar and the accepted approaches — putting data beyond use, or maintaining a suppression record — are worth borrowing.
CI Retention Is A Setting Somebody Else Chose
Build logs and artefacts have a retention period. On most managed CI platforms that period is a default nobody on your team selected, it is measured in weeks or months, and it applies to output that may contain personal data.
Treat it as a retention decision, because it is one. Find the current setting, decide what it should be, and write the decision down with a reason. Where artefacts contain screenshots or payloads, a shorter period is almost always defensible and rarely costs anything, since nobody investigates a build from four months ago.
The other half is access. Repository and pipeline access is usually granted broadly — every engineer, often every contractor, sometimes every employee with an SSO account. If the pipeline output contains personal data, that access list is the recipient list for it, and it is generally much wider than the access list for the production database holding the same information.
This Is A Place Problem, Not A Logging Problem
There is a neighbouring question that answers differently and it is worth keeping apart. Whether the entries your application writes are personal data, how long you keep them and what lawful basis covers them is a question about logging as a practice, and it has its own answer. So does the narrower question of whether a given identifier in a log line counts as personal data.
What this article covers is different: personal data ending up in places built to hold code rather than data. The controls are different too. Log retention is a configuration decision on a system you designed to receive data. Repository hygiene is a prevention problem on systems that were never meant to receive it — secret scanning and pre-commit hooks, synthetic rather than copied fixtures, redaction in bug templates, artefact retention limits, and a rule about what may be pasted into an issue.
The nearest neighbour is test data generally. Whether you may use production data in a test environment is the question one step upstream, and if the answer there is disciplined, most of this problem never reaches your repository.
What This Costs When It Goes Wrong
The realistic failure is not a regulator reading your commit history. It is a repository access incident where the exposure assessment has to include everything in history rather than everything currently checked out, and those are very different numbers.
That assessment is what determines whether Article 33 notification to a supervisory authority is required within 72 hours and whether Article 34 communication to affected individuals follows. It is hard to run quickly if nobody knows what is in the history, which is the argument for keeping an eye on it before you need to.
It also determines what your insurer will and will not do. Whether cyber insurance is worth carrying for a SaaS turns partly on the forensic and notification costs of exactly this kind of incident, which are the costs cover genuinely addresses.
Common Mistakes With Repos And CI Output
Building fixtures by copying production rows. It is the fastest way to a realistic test and it puts real people into a system with no retention policy and very wide access. Generated or synthetic fixtures cost an afternoon once and remove the problem permanently.
Treating a deleted file as deleted data. A commit that removes a file leaves it in history, in every clone and every fork. If the data genuinely needs to go, it needs history rewriting, and if it does not, say so honestly rather than reporting a deletion that did not happen.
Leaving CI artefact retention on the platform default. Someone else picked that number and they did not know your build logs contain payloads. It is a retention decision about personal data and it should be made deliberately and recorded.
Pasting real payloads into issues and pull requests. Issue threads are searchable, exportable, often visible to contractors, and retained for the life of the project. A redacted example demonstrates the bug just as well.
Assuming a private repository is a security control that resolves the question. Private controls who can reach it, not what is in it or how long it stays. The access list for a private repo is usually wider than the access list for production, which is the opposite of what most people assume.
FAQ
Is source code itself personal data?
Generally no — code is not information relating to an identifiable person. But authorship metadata is: commit messages carry names and email addresses, and blame history links individuals to specific changes. That is employee personal data with an indefinite retention period, which is worth knowing even though it is rarely the pressing problem.
Do I have to rewrite git history if someone requests erasure?
Not automatically. The right to erasure is not absolute, and you may weigh technical feasibility, though inconvenience alone is a weak argument. What matters is that you assess it properly, document the reasoning, tell the person plainly what you have and have not removed, and stop the data being used. An unexplained refusal is the failure mode.
Does GDPR apply to a private repository nobody outside the company can see?
Yes. The regulation applies to processing, not to publication. A private repository holding personal data is processing that data, needs a lawful basis, a retention position and appropriate security. Being private is one of the security measures, not an exemption from the rest.
Do our CI and repository providers need a DPA?
If they host repositories or run pipelines containing personal data, they are processing it on your behalf and Article 28 applies. Most major providers publish one and it needs accepting rather than assuming. They also belong on your subprocessor list, which is where they are most often missing.
Closing Thought
The pattern here is that engineering systems accumulate personal data in exactly the places where nobody has authority to delete it. A product manager can decide a customer table's retention period. Nobody owns the retention period of a four-year-old test fixture, and everyone who could rewrite the history has a good reason not to. That is why this problem grows quietly rather than dramatically, and why the only cheap intervention is upstream — stop the data getting in, because getting it out is genuinely hard and will stay that way.
Practically, that means secret scanning, synthetic fixtures and an artefact retention setting somebody chose on purpose. ComplyDog covers the customer-facing half — a compliance portal on your own domain with your DPA, subprocessor list, data subject request handling and security page — which is what a buyer reviews when they ask how you handle their data. It does not scan your repositories, rewrite git history or set your CI retention, and no compliance tool can; that part belongs to whoever owns the pipeline.
