10110010011101001011001101101110101018200.devFrom Enterprise.Systems
Start free

Independent developers & freelancers

Security obligations that already apply to you

If you are a freelancer or an independent developer handling client data, you do not get to opt out of security regulation by being small. Processor obligations under the GDPR, deployer obligations under the EU AI Act, and your clients’ contractual security requirements all attach to you directly — today, at your current size. Here is what already applies, named regulation by regulation, and what is currently exposed on your own account.

What already applies to you

GDPR: you are a data processor — personally

When a client hands you personal data — a user database, a production system, an export — you are acting as a data processor (and sometimes a controller) under the GDPR. That status does not require a company: it attaches to “a natural or legal person”. It obliges you to process under a contract, to implement appropriate security measures for the data you hold, and to notify your client without undue delay if it is breached — and it exposes you to compensation claims and administrative fines.

Basis: GDPR Article 4 (definitions), Article 28 (processing under contract), Article 32 (security of processing), Article 33 (breach notification), Articles 82–83 (liability and administrative fines of up to €20 million or 4% of annual worldwide turnover, whichever is higher).

EU AI Act: deploying AI for clients carries obligations

If your client work includes putting AI systems into production — an assistant in a client’s product, an AI agent automating a workflow — the EU AI Act imposes obligations on deployers: those who use AI systems under their own authority in a professional context. Which obligations apply depends on the system’s risk category, but “I only integrated it” is exactly the role the deployer category covers.

Basis: EU AI Act Article 26 (obligations of deployers of high-risk AI systems), Article 4 (AI literacy), Article 99 (penalties).

Your enterprise clients must collect security evidence from you

Companies operating under SOC 2, ISO 27001, or GDPR Article 28 run vendor-management programs their auditors actually check — and those programs do not distinguish between a 500-person vendor and a one-person vendor. That is why the security questionnaire arrives before the contract does. Freelancers who can answer with evidence close faster than freelancers who improvise.

Basis: contractual — data processing agreements and vendor security requirements your clients are obliged to impose on anyone they hand data to, including individuals.

A breached client project is a real business risk

A security incident in a client project can mean direct liability under your contract’s indemnification clause, can mean processor liability under GDPR Article 82 where personal data is involved, and can mean losing the client and the reference that came with it. For a business of one, the reputational asset is the business. This is risk, not certainty — but it is the ordinary chain of consequences when a forgotten credential turns into an incident.

Basis: GDPR Article 82 (right to compensation); your own service contracts.

What is currently exposed on your account

Every obligation above implies the same first question: what has access to the place where your client work lives? For most independent developers that place is a personal GitHub account — and it has been accumulating access for years. All of the following is machine-readable from GitHub’s own API:

Installed GitHub Apps

Deployment bots, CI tools, AI assistants — each holding the permission grant you approved once. Some hold write or admin over everything you own; some belong to projects that ended long ago.

Deploy keys

Unattended SSH credentials on servers. A read-write key on a repository that only needed read is a code-injection path if that server is ever compromised.

Collaborators

People added during collaborations that have since ended, still holding write access — including on repositories that are public.

Public repositories

Which of your repositories are public, and who can push to them, is an inventory question most developers cannot answer from memory.

AI vendor keys that outlive projects

The OpenAI, Anthropic, Mistral, or Cursor account behind your side projects accumulates API keys and seats long after the project ends. 8200.dev’s AI Governance view flags stale and org-wide keys, keys that outlived a role change, and seats nobody uses — from the vendors’ own admin APIs, read-only.

See it, then decide

Connect your personal GitHub account read-only and get the inventory: every installed app and its grants, every deploy key and whether it is read-only, every collaborator, every public repository — with the findings ranked by severity. The free tier shows your top 3 findings in full. No law requires you to run a scan; the obligations above apply either way. What a scan changes is whether you can answer the questions they imply.

Read-only scopes. Never your source code. No credit card.

This page is general information about regulations that commonly apply to independent developers and freelancers; it is not legal advice. How each regulation applies to your specific situation depends on facts specific to you — for that, consult a lawyer.