sota.io
2026-04-05·7 min read·sota.io team

GDPR Article 25 Privacy by Design — A Developer's Guide to Compliance Through EU-Native Infrastructure in 2026

Most developers know GDPR as the regulation that requires a cookie banner and a privacy policy. That reading is not wrong — but it is incomplete. Article 25 of the GDPR imposes obligations that go much deeper: it requires that data protection be built into your systems from the start, not retrofitted at deployment or added as a legal checkbox. For developers building on cloud infrastructure in 2026, this creates a concrete technical requirement — and most popular PaaS platforms fail it at the infrastructure level before you write a single line of application code.

This guide explains what GDPR Article 25 actually demands, what it means for the infrastructure you choose, and how EU-native hosting combined with formal verification techniques gives you a demonstrably compliant baseline.

What GDPR Article 25 Actually Says

Article 25 of the General Data Protection Regulation consists of two obligations:

Article 25(1) — Data Protection by Design: The controller shall implement technical and organisational measures designed to implement the data-protection principles (Article 5) in an effective manner, and to integrate the necessary safeguards into the processing.

Article 25(2) — Data Protection by Default: The controller shall implement appropriate technical and organisational measures to ensure that, by default, only personal data which are necessary for each specific purpose of the processing are processed.

The key phrase is by design — meaning these protections must be integrated at the design stage, not added afterwards. The European Data Protection Board (EDPB) published Guidelines 4/2019 on Art. 25 clarifying that compliance requires a risk-based approach, with documentation showing the technical choices made and why they satisfy the data minimisation, storage limitation, and integrity/confidentiality principles of Article 5.

In 2026, Data Protection Authorities (DPAs) across the EU — notably the BfDI (Germany), CNIL (France), and DPA (Ireland) — have shifted enforcement focus from cookie violations to infrastructure-level compliance. Art. 25 is a priority target because it is the foundational obligation: if your infrastructure design fails it, downstream compliance measures are built on sand.

Why Most Cloud Platforms Fail Article 25 at the Infrastructure Level

Here is the problem that most developers never encounter in documentation but discover during DPA audits:

The CLOUD Act transfers personal data to US jurisdiction. The Clarifying Lawful Overseas Use of Data Act (2018) allows US law enforcement and intelligence agencies to compel US companies to produce data stored anywhere in the world — including EU-region instances on AWS, GCP, or Azure — without a European court order and without notifying the data subject.

This creates a direct tension with GDPR Article 25(1). If you are building a system that must protect personal data by design, and your infrastructure provider is legally required to hand that data to US agencies on demand, you have a design-level privacy failure. The Schrems II ruling (CJEU, July 2020) confirmed this: data stored on US-owned infrastructure in EU regions does not automatically comply with GDPR transfer rules.

Railway, Render, and Vercel are incorporated in the United States. EU-region servers do not change their legal jurisdiction. For Art. 25 compliance, the infrastructure layer must be outside US legal reach — not just physically located in Europe.

Choosing a US-headquartered PaaS and then trying to achieve Art. 25 compliance through application-layer measures is like trying to build a secure house on a foundation that has a legally mandated back door.

What "Privacy by Design" Requires in Practice

The EDPB Guidelines 4/2019 translate Art. 25 into seven design principles that must be demonstrable, not just asserted:

  1. Proactive, not reactive — privacy protection is anticipated before processing begins
  2. Privacy as the default — no action required by the data subject to protect their privacy
  3. Privacy embedded into design — integrated into system design, not added as an add-on
  4. Full functionality — privacy and security are complementary, not in conflict
  5. End-to-end security — all data is secure throughout its lifecycle
  6. Visibility and transparency — systems operate as stated, independently verifiable
  7. Respect for user privacy — user-centric design that keeps data subject rights actionable

Principle 6 — visibility and transparency — is where formal methods enter the picture. Art. 25 compliance requires documentation that your technical choices satisfy the principles. For complex systems, informal documentation ("our system is secure because we use TLS and hashed passwords") is increasingly rejected by DPAs during audits. The expectation is that high-risk systems provide auditable evidence of design-level protections.

The Infrastructure Tier: Why EU-Native Hosting Is a Prerequisite

Before you write application-level Art. 25 controls, your infrastructure needs to satisfy three baseline requirements:

1. No US legal jurisdiction. The processor must be incorporated and operating under EU law (or a country with an adequacy decision). German, Dutch, and French cloud providers qualify. US companies with EU subsidiaries do not automatically qualify — the parent company's CLOUD Act obligations persist.

2. Physical data residency in the EU. Data must stay within the EU/EEA for Art. 25 and Art. 44-46 (transfer rules). "EU region" on a US platform does not satisfy this when the legal entity can be compelled to export data.

3. Documented technical and organisational measures (TOMs). The processor must provide documentation you can include in your Records of Processing Activities (RoPA) under Art. 30.

sota.io is incorporated in Germany, runs on German infrastructure, and is not subject to the US CLOUD Act. Every deployment — from a personal project to a production API — runs on infrastructure outside US legal jurisdiction. This satisfies the infrastructure tier of Art. 25 compliance before you configure anything in your application.

The Application Tier: Formal Verification as Auditable Evidence

For systems processing sensitive personal data under GDPR (health data, financial data, HR data under Art. 9 special categories), informal "we tested it" documentation is increasingly insufficient. DPAs expect technical evidence proportionate to the risk.

This is where the EU's formal verification research tradition provides a direct compliance tool:

Frama-C (CEA/INRIA, France) — static analysis and formal proof for C code. For applications with C components handling personal data, Frama-C can generate machine-checkable proofs of memory safety, absence of buffer overflows, and invariant preservation. These proofs constitute Art. 25 evidence: you are not claiming your system is secure, you are proving it has specific verified properties.

TLA+ (Leslie Lamport, Microsoft Research) — temporal logic for distributed system correctness. For systems where personal data flows between microservices, databases, and message queues, TLA+ specifications prove that access control invariants hold across all possible system states. Amazon uses TLA+ for exactly this kind of distributed correctness — the same technique is applicable to GDPR access control proofs.

Dafny (Microsoft Research, now open-source) — verification-aware programming where functions carry formal pre/post-conditions. A Dafny-verified data processing component ships with machine-checkable proof that it cannot, by construction, access data outside its specified scope. This is Privacy by Design in the strongest possible sense.

Viper (ETH Zurich, Switzerland) — the intermediate verification language underlying Prusti (Rust), Gobra (Go), and Nagini (Python). For teams building in modern languages, Viper-based tools provide permission-based heap reasoning — proving that data ownership is correctly transferred and that no component can access memory it should not.

None of these require you to become a formal methods researcher. At minimum, using EU-hosted formal verification tooling to check critical data handling components and documenting the results as part of your DPIA (Data Protection Impact Assessment) strengthens your Art. 25 position substantially over untested code.

The DPIA Connection: When Art. 25 Requires Art. 35

GDPR Art. 35 requires a Data Protection Impact Assessment (DPIA) when processing is "likely to result in a high risk." The EDPB identifies three triggers that almost always require a DPIA:

Art. 25 and Art. 35 interact: your DPIA must demonstrate that Art. 25's "by design" requirements are met. The technical controls documented in the DPIA — infrastructure choices, access control architecture, data minimisation measures — need to be verifiable, not just asserted.

If you are building an AI system that processes personal data, Art. 35 almost certainly applies. And if the AI system is "high-risk" under the EU AI Act (Annex III — HR, credit scoring, medical), you have overlapping obligations: EU AI Act Art. 9 (risk management system) and GDPR Art. 25 (privacy by design) converge on the same requirement: documented, verifiable evidence that your system's design protects the rights of individuals.

EU-native infrastructure and formal verification tooling address both simultaneously.

Practical Checklist: GDPR Art. 25 Compliance for Developers

Infrastructure tier (prerequisite):

Application tier (design measures):

Documentation tier (DPA audit readiness):

2026 Enforcement Context: Why This Matters Now

The EDPB's 2025 Coordinated Enforcement Action focused on "data subjects' rights" — but the 2026 work programme shifts focus to Art. 25 technical implementation. German, French, and Irish DPAs have all signalled infrastructure-level audits as a priority.

Three enforcement trends to watch:

  1. Data transfers to the US. Post-Schrems II, DPAs are scrutinising whether EU-region servers on US platforms constitute unlawful transfers. Austrian and French DPAs have already ruled against Google Analytics implementations on exactly this basis — the principle extends directly to any US-owned PaaS.

  2. AI systems processing personal data. As EU AI Act high-risk obligations take effect from August 2026, regulators will check whether Art. 25 DPIAs cover AI-specific risks (algorithmic discrimination, unintended data retention from training).

  3. SME enforcement. The 2024 GDPR enforcement statistics show a significant rise in fines against SMEs and startups — the "we are too small to be targeted" assumption no longer holds.

Conclusion: Privacy by Design Starts at the Infrastructure Layer

GDPR Article 25 is not a checkbox — it is a design discipline. It requires that privacy protection be embedded in your infrastructure, your application architecture, and your development process from the beginning.

For the infrastructure layer, that means hosting with a provider outside US legal jurisdiction — not just physically in Europe, but legally outside CLOUD Act reach. For the application layer, it means documented technical controls, proportionate to the sensitivity of the data processed. For high-risk systems, that increasingly means formal verification: machine-checkable proofs that your data handling properties hold by construction, not just by convention.

sota.io provides the infrastructure tier: EU-incorporated, German-hosted, not subject to US surveillance law, with managed PostgreSQL and deployment documentation you can reference in your RoPA and DPIA. The formal methods tooling for the application tier — Frama-C, TLA+, Dafny, Viper, and 150+ other tools — can all be deployed on the same EU-sovereign infrastructure.

Privacy by design is a technical obligation. It deserves a technical solution.

Deploy to EU-sovereign infrastructure — free tier, no credit card required.

Related reading: