GDPR by Design: Engineering Patterns for SMB Software (Not Legal Advice)

On 10 March 2025 the German Federal Data Protection Commissioner fined Vodafone Germany a combined €45 million for two things most Mittelstand engineering teams also get wrong (opens in new tab): processor agreements with no working audit process (€15M), and weak portal authentication that combined with hotline access enabled eSIM fraud (€30M). The paperwork existed. The engineering did not. This post is not legal advice — it is the set of patterns we actually ship, eight years after Art. 25 told us to do "data protection by design and by default."

The numbers are not getting better

DLA Piper's January 2026 survey put 2025 GDPR fines at roughly €1.2 billion across Europe (opens in new tab), bringing the cumulative total since May 2018 to €7.1 billion. The headline is dominated by big tech — Ireland alone accounts for over half of all fines ever issued (opens in new tab) — which is why many Mittelstand founders shrug it off. The more useful indicator is breach notifications: an average of 443 per day in 2025, a 22% jump (opens in new tab) over 2024. Each one starts a 72-hour clock.

Germany fined €45.9M in 2025, concentrated on employee data and processor supervision — areas where SMBs are structurally exposed (opens in new tab). The CJEU's Deutsche Wohnen ruling (C-807/21) (opens in new tab) removed the "rogue manager" defence: organisational negligence is enough, and fines benchmark against group-wide turnover.

Art. 25, reframed as five engineering requirements

Article 25 GDPR (opens in new tab) is too abstract to write a ticket against. As a build spec, five obligations fall out: residency (point at where every byte lives), consent (show what each subject agreed to and when), deletion (every store has a tested erasure path), attribution (every access tied to an authenticated principal in auditor-readable logs), and vendor transparency (every sub-processor known, contracted, swappable).

Residency is a deployment topology problem, not a checkbox

The most common residency bug we see: an EU-only stack on Hetzner Falkenstein with a frontend that loads US-hosted fonts, ships analytics to a US endpoint, and calls OpenAI's default API (US-routed unless you pin EU residency). The core DB is in Germany; personal data still leaves the EU several times per page load. Since Schrems II and the 2023 EU-US Data Privacy Framework, transfers are legal again for DPF-certified recipients — but the General Court only just dismissed the first direct challenge in Latombe v. Commission on 3 September 2025 (opens in new tab), and NOYB has signalled "Schrems III." A framework that one CJEU ruling can invalidate is one your architecture should fall back from without a six-month migration.

Patterns that age well: pin every data path to EU regions explicitly and fail loudly when a binding is missing — for Cloudflare that means Regional Services EU (opens in new tab), Customer Metadata Boundary EU, Geo Key Manager EU/Germany, and D1 with jurisdiction: "eu" (opens in new tab) set at creation. Know the escape hatches: jurisdiction-constrained D1 covers data at rest, not where compute runs. Treat third-party APIs as residency decisions — an LLM call without an EU residency agreement is a transatlantic transfer of whatever you send. For Postgres-heavy stacks, Hetzner or Scaleway with EU-only S3-compatible storage remains the simplest defensible baseline.

Consent is a state machine, not a cookie banner

What matters under GDPR is that for every record, you can produce — months or years later — the legal basis you processed it under, and if that basis was consent, prove what the subject saw, when, and for which purposes. We model consent as an append-only log: a consent_events table keyed by subject with purpose, granted | withdrawn, timestamp, version_of_notice_shown, and source. Current state is a view. The EDPB's Opinion 28/2024 on AI models (opens in new tab) clarified that legitimate interest can be a lawful basis for AI features, but only after a documented three-step test — if you cannot write that test down per feature, you need consent.

Implications: feature flags gate on consent state, not user ID, enforced at module edge; withdrawal is a synchronous deletion trigger for anything you only had consent for (Article 17 restores the pre-consent state); notice versions are content-hashed and stored so you can serve back the exact text a subject saw; consent state replicates to every system and fails closed when stale.

The deletion cascade no one has tested

A typical SaaS soft-deletes a users row and calls it done. Meanwhile: audit logs hold the email in old_values, Stripe still has the customer, the ESP has them on a marketing segment, last Tuesday's backups have everything, the warehouse links session IDs to user ID, the LLM cache has support transcripts, and the error tracker has months of stack traces with their user object.

We treat deletion as a dependency graph. For each store we declare: whether it holds personal data directly or by linkage; the rule (hard delete, anonymise, or retain under a different basis like HGB §257); the responsible service; how we verify. We run an end-to-end deletion test in CI — a synthetic user with a random token embedded in name, email, messages, uploads. After deletion, a scanner greps every store for the token; any hit fails the build. The February 2025 Hanover Regional Court ruling (opens in new tab) leaned heavily on whether the defendant had "transparency architecture and documentation" — if a DPA demands proof of erasure and you cannot produce a machine-readable record, you are arguing from a losing position.

Access logs an auditor can actually read

Most SMB products have logs; few have logs a supervisory authority would accept as evidence. Our baseline schema for a personal-data access event: timestamp (UTC ISO-8601); actor as an authenticated principal (never "admin" as a shared identity); action (read/write/export/delete/impersonate, both sides logged); resource as a stable record ID; purpose or justification; and a request_id. Retention 12–24 months on its own schedule, append-only storage with restricted writes, shipped to a second EU-jurisdiction destination with object-lock, and a periodic hash-chain check.

Employee data access is the trap. German enforcement consistently targets employee-data violations (opens in new tab), and the OLG Stuttgart ruling in February 2025 (opens in new tab) held that staff effectively controlling processing purposes can trigger GDPR liability. If your staff can pull up any customer record without a justification prompt, you have audit theatre.

The vendor and sub-processor problem is now an LLM problem

Art. 28 GDPR (opens in new tab) requires a written processor contract for every party processing personal data on your behalf, and requires you to "allow for and contribute to audits." Vodafone was an Art. 28(1) failure — contracts existed, oversight did not.

A workable process: a sub-processor registry in version control (vendor, purpose, data category, residency, DPA reference, DPF status, sub-processor URL, review date, owner — reviewed quarterly via PR); a new-vendor gate where CI diffs outbound egress against the registry; LLM vendors as the hard case — prompts in support, sales or HR are personal data, and the options from most to least defensible are self-hosted open-weights on EU infra, EU-region API with residency commitment and no-training opt-out, US API with DPF and SCCs (the indefensible choice is not knowing which one you made); and annual evidence collection (SOC 2, ISO 27001, DPIAs, breach notifications) filed where the DPO can find them in under ten minutes. The hidden sub-processors matter most — keep the direct vendor list small enough that their sub-processor lists can actually be read.

What "by design" actually looks like in a Mittelstand codebase

The shorthand we give new clients: if an auditor walked in tomorrow, could your senior engineer — not your lawyer, not your DPO — answer these five questions in under fifteen minutes? (1) Show me every place personal data lives, and the jurisdiction of each. (2) Show me, for this test user, what purposes they consented to and when. (3) Delete this test user and prove every store holding their data was hit. (4) Show me who accessed this test user's record in the last 90 days and why. (5) Show me every third party that has seen this test user's data.

If those answers live in code, in version-controlled config, and in logs — you have privacy by design. If they live in a binder, you have privacy by paperwork. The BDSG amendments of 2024 (opens in new tab) and German case law on organisational negligence both push the same way: documentation that reflects reality, and reality shaped by the documentation. Art. 25 is a tax on every shortcut, and the tax compounds. Pay it in the architecture, or pay it in the fine letter.

Further reading

• DLA Piper GDPR Fines and Data Breach Survey, January 2026 (opens in new tab) — the authoritative annual snapshot of fines and breach notifications.
• CMS GDPR Enforcement Tracker (opens in new tab) and Enforcement Tracker Report 2025 (opens in new tab) — case-level data we consult for every DPIA.
• EDPB Opinion 28/2024 on AI models and personal data (opens in new tab) — the three-step test any AI feature has to survive.
• Cloudflare Data Localization Suite documentation (opens in new tab) and the D1 jurisdiction changelog (opens in new tab) — current state of residency primitives on Cloudflare.
• EuroCloud: German Courts on GDPR Fines Through 2025 (opens in new tab) — the Deutsche Wohnen, Hanover, and Stuttgart rulings that shape how Mittelstand defendants are treated.
• Vodafone Germany €45M fine summary, EDPB national news (opens in new tab) — the 2025 case that put processor oversight back on every engineering team's backlog.