Security Obligations That Already Apply to You as an Independent Developer

There is a persistent belief among independent developers that security and privacy regulation is something that happens to companies — that obligations begin when you incorporate, hire a DPO, or sign an enterprise contract. It is not true, and it has not been true for years. If you are a freelancer or an indie developer handling client data, several obligations already apply to you today, personally, at your current size. This article walks through what they are, names the regulations they come from, and ends with the practical question that matters: what, concretely, is exposed on your accounts right now?

One thing this article will not do is tell you that any law requires you to buy a security tool. None does. What the law does require is that you know what you are doing with the data you process and secure it appropriately — and the honest starting point for that is knowing what access exists on the accounts where your client work lives.

Under GDPR, a freelancer processing client data is a processor — with direct obligations

If a client in the EU (or a client whose users are in the EU) hands you personal data — a user database to migrate, a production system to debug, an export to analyze — you are almost always acting as a data processor under the GDPR, and in some engagements (when you decide what to collect and why) as a controller. Neither status requires a company. The GDPR's definitions in Article 4 attach to "a natural or legal person" — a person with a laptop qualifies.

That status carries direct, personal obligations:

• Article 28 requires that your processing for a client be governed by a contract — the data processing agreement your enterprise clients keep sending you is not bureaucratic theater; it is a legal requirement on both of you, and it binds you to specific security commitments.
• Article 32 requires you to implement "appropriate technical and organisational measures" to secure the personal data you process — appropriate to the risk, which includes controlling who and what can access it.
• Article 33 requires a processor to notify the controller "without undue delay" after becoming aware of a personal data breach — which presupposes you are in a position to become aware of one.
• Article 82 gives data subjects the right to compensation from processors for damage caused by processing that infringes the regulation, and Article 83 backs the whole framework with administrative fines that can reach, for the most serious infringements, up to twenty million euros or four percent of annual worldwide turnover, whichever is higher.

Nobody is suggesting a supervisory authority's first move against a freelancer is the statutory maximum. The point is simpler: the obligations are real, they attach to you directly, and "I am just one person" is not a recognized exemption anywhere in the regulation's text.

The EU AI Act adds obligations for deployers of AI systems

If your client work now includes wiring AI into products — an assistant in a client's app, an AI agent automating a workflow, a model making decisions that affect people — the EU AI Act is relevant to you. The Act does not only regulate the companies that train models; it imposes obligations on deployers — those who use AI systems under their own authority in a professional context.

Article 26 sets out deployer obligations for high-risk AI systems, including using systems in accordance with their instructions, ensuring appropriate human oversight, and monitoring operation. Article 4 requires providers and deployers alike to ensure a sufficient level of AI literacy in the people operating these systems on their behalf. And Article 99 backs the framework with administrative fines for non-compliance. Which obligations apply to a given engagement depends on what the system does and the risk category it falls into — but "I only integrated it, I didn't build it" is precisely the role the deployer category was written for.

There is a practical irony here that we see constantly in AI agent governance: independent developers are the heaviest adopters of AI coding agents and automation bots — and the least likely to have an inventory of what those agents can reach. If an AI agent can push to every repository you own, that is a fact about your security posture whether or not any regulator ever asks about it.

Your enterprise clients are already regulated — and their obligations flow down to you

Even if you never touch EU personal data and never deploy an AI system, there is a third source of security obligations that applies to nearly every freelancer working with businesses of any size: contracts. Enterprise clients operate under SOC 2 reports, ISO 27001 certifications, GDPR Article 28 processor requirements, and vendor-management programs that their auditors actually check. Those programs do not distinguish between a 500-person vendor and a one-person vendor. A vendor is a vendor.

This is why the security questionnaire keeps arriving before the contract does. Your client is required — by their framework, their auditor, or their own customers — to collect security evidence from the people they hand data to. Including you. The freelancers who can answer credibly ("here is what has access to my development environment, here is how I control it, here is evidence") close those deals faster than the ones who improvise. We wrote about the org-side version of this dynamic in what auditors require for AI governance in 2026; the vendor-side version lands on your desk as a questionnaire.

What a breach actually costs an independent developer

Risk framing, because that is the honest framing: a security incident in a client project can mean direct financial liability under your contract's indemnification clause, can mean processor liability under GDPR Article 82 if personal data was involved, and — most concretely for a freelancer — can mean the end of the client relationship and the reference that came with it. For a consultancy of one, the reputational asset is the business. None of this is hypothetical exotica; it is the ordinary chain of consequences when a compromised credential or an over-permissioned integration turns into a client-data incident.

So what is actually exposed on your account right now?

Here is the uncomfortable, specific version of the question. Your client work almost certainly lives on a personal GitHub account. That account has accumulated, over years of projects:

• Installed GitHub Apps — deployment bots, CI tools, AI assistants — each holding a permission grant you approved once and probably never reviewed. Some of them hold write or admin over everything you own. Some belong to projects that ended in 2024.
• Deploy keys — unattended SSH credentials sitting on servers, some with write access to the repository they were meant only to read. If that server is compromised, a read-write deploy key is a code-injection path into your client's product.
• Collaborators — people you added during a collaboration that has since ended, still holding write access, including on repositories that are public.
• Repository exposure — which of your repositories are public, and what is in them, is itself an inventory question most developers cannot answer from memory.

Every one of these is machine-readable through GitHub's own API, which means every one of them is checkable — not by trusting your memory, but by enumerating what actually holds access today. That inventory is exactly what 8200.dev's GitHub connector now produces for personal accounts, not just organizations: connect your own GitHub login, and the scan lists the installed apps and their permission grants, the deploy keys and whether each one is read-only, the collaborators per repository, and the findings that fall out of that graph — the forgotten bot with admin, the write-capable deploy key, the stale app nobody has touched in a year.

The free personal tier runs the full scan and shows you the most severe findings; the paid personal tier — priced like a code-completion subscription, not like enterprise software — unlocks the complete list with continuous monitoring and alerts. And if you grow into an agency with an organization account, the same scan, the same rules, and the same evidence trail scale up with you — that is the organization side of the product, and it is the same connector.

The obligations above apply to you whether or not you ever run a scan. What the scan changes is whether you can answer the questions those obligations imply — what has access, why, and what you did about the access nobody could justify. Start with the free tier, see what has quietly accumulated on your account, and decide from there — the pricing is public, self-serve, and starts at zero.

*This article is general information about regulations that commonly apply to independent developers; it is not legal advice, and how each regulation applies to your specific situation depends on facts a scanner cannot know. For that, talk to a lawyer.*