Eight years after the GDPR came into force I see the same gaps in almost every project: incomplete records of processing activities, partial DPAs, deletion concepts only on paper, US sub-processors without standard contractual clauses. Anyone in 2026 still thinking "we handled GDPR back in 2018" risks fines of up to 4% of annual turnover at the next supervisory authority audit. This article tackles the most common myths and shows what a GDPR-compliant software architecture looks like in 2026.
The GDPR in a nutshell
The General Data Protection Regulation (Regulation EU 2016/679) applies to anyone processing personal data — even the smallest sole proprietor with a newsletter list. It defines duties (Art. 30 records of processing, Art. 28 data processing, Art. 35 DPIA), data subject rights (Art. 15 access, Art. 17 erasure, Art. 20 portability) and breach notification duties (Art. 33, 72-hour deadline).
Fines reach EUR 20 million or 4% of global group turnover — whichever is higher. In practice it's rarely the maximum fines that hurt; it's the reputational damage and remediation costs after an incident.
The five most common GDPR gaps in 2026
1. The record of processing (RoPA) is outdated or incomplete
The RoPA is a living document, not a one-off effort. When a tool changes, a new processing is added, or a service provider is swapped, the RoPA has to be updated. Reality: many RoPAs are from 2018 and have never been touched. Supervisory authorities check this in spot checks.
2. DPAs missing or outdated
Every external service provider processing personal data on your behalf needs a Data Processing Agreement — hosting, email, cloud storage, AI providers, analytics. Many providers offer templates these days, but you still have to check: if the provider isn't in the EU, are the Standard Contractual Clauses (SCC) in place? Is there a Transfer Impact Assessment (TIA)?
3. US cloud services without third-country framework
Schrems II (CJEU 2020) and Schrems III (pending) make using US cloud services a compliance risk. I recommend EU hosting wherever possible: Scaleway Paris for backend and AI models, Supabase EU region for database, IONOS Germany for frontend. If you must use AWS, Google Cloud or Microsoft Azure, you need SCCs, TIA and data minimisation.
4. Deletion concept exists only on paper
Retention periods per data category are documented in 80% of audits — but not technically enforced. Deletion doesn't happen by itself, a cron job has to do it. In Schwankl Software installations a daily job anonymises or deletes expired data and documents the result in an audit log.
5. No efficient access procedure
When a user asks for access under Art. 15, you must respond within one month. Anyone who has to manually click through five databases will miss the deadline. Solution: an admin workflow that aggregates all data for an email address, exports it, and delivers it in a standardised format at the push of a button.
Example: deletion concept as code
A deletion concept belongs in a table, not in a PDF. Here's what that looks like in Postgres:
CREATE TABLE retention_policies (
table_name TEXT PRIMARY KEY,
retention_days INTEGER NOT NULL,
legal_basis TEXT NOT NULL,
last_review TIMESTAMPTZ DEFAULT NOW()
);
INSERT INTO retention_policies VALUES
('contact_messages', 90, 'Art. 6 (1) lit. f — outreach', NOW()),
('newsletter_logs', 365, 'Art. 6 (1) lit. a — consent', NOW()),
('auth_audit_log', 730, 'Art. 6 (1) lit. f — security', NOW()),
('invoices', 3653, 'German HGB § 257 — 10y retention', NOW());
A cron job runs daily, reads the policy, and deletes or anonymises expired entries. The result is documented in a `retention_runs` audit log — provable to the supervisory authority.
EU hosting by default
For every new architecture I ask first: does this really have to run in the US? For 95% of cases the answer is no. My standard stack:
- Frontend: Next.js on IONOS VPS Germany (Docker)
- Backend: FastAPI on the same VPS
- Database: Supabase EU (Frankfurt or London)
- AI inference: Scaleway Paris (Mistral, Pixtral)
- Email: IONOS SMTP Germany
- Monitoring: self-hosted (Prometheus + Grafana on the same VPS)
That gives me a complete stack without US third-country transfers. Standard contractual clauses, TIA and Schrems risks fall away — for typical SaaS projects a significant compliance advantage and a sales argument for mid-market clients.
What I do concretely
In a GDPR audit for your project I systematically check: is there an up-to-date RoPA? Are all DPAs in place and current? What third-country transfers exist and how are they protected? How is deletion handled and is it technically enforced? Does the access procedure work? Is there a breach reporting procedure?
On the implementation side I deliver EU hosting by default, DPA templates, a privacy policy generator per service, automatic deletion via cron, a GDPR access workflow, and a logging concept that takes data minimisation seriously (no PII in plain-text logs).
More at /compliance/dsgvo.
