GDPR Complete Developer Guide: All 99 Articles Explained for Engineers (2026)
Post #455 in the sota.io EU Cyber Compliance Series
The GDPR has 99 articles. Most developer guides cover three of them.
This guide covers all of them — not as a legal reference, but as an engineering reference. For each chapter, you get the practical implications for SaaS and PaaS builders, the implementation requirements that trigger compliance obligations, and the CJEU case law that shows where regulators actually look when enforcement happens.
The sota.io EU Cyber Compliance Series has published a dedicated guide for every article group in the GDPR. This page is the hub: a structured index that maps every obligation to the post that explains it, with enforcement priority indicators so you know where to start.
Why Developers Need a Complete GDPR Reference
GDPR enforcement in 2026 has fundamentally changed the risk calculus for SaaS builders:
- EUR 7.1B in fines issued since May 2018
- Q1 2026: +340% enforcement activity vs Q1 2023
- Average fine: EUR 8.7M (up from EUR 2.3M in 2022)
- CEF 2026 focus areas: Art.12–14 Transparency, Art.5 Principles, Art.6 Lawful Bases
The practical consequence: a GDPR violation is no longer a theoretical business risk. For any SaaS with EU users, it is a P0 operational risk. Understanding which articles matter, what they require technically, and how to build infrastructure that reduces your exposure is a core engineering competency in 2026.
How to Use This Guide
Each section below maps to a GDPR chapter, with links to the dedicated developer implementation guide for each article group. The Priority column uses three levels:
| Priority | Meaning |
|---|---|
| P0 — Critical | DPAs actively enforce this in 2026. Violation is a direct fine trigger. |
| P1 — High | Required for compliant architecture. Typically checked in audits. |
| P2 — Standard | Important for topical authority and full compliance posture. |
Chapter I — General Provisions (Art.1–4)
Priority: P0 — Before any other compliance work, you must determine whether GDPR applies and to what processing.
| Articles | Topic | Key Developer Question |
|---|---|---|
| Art.1 | Subject matter and objectives | What is GDPR trying to protect? |
| Art.2 | Material scope | Which processing activities are covered? |
| Art.3 | Territorial scope | Does GDPR apply to your org even if not EU-based? |
| Art.4 | Definitions | What exactly is "personal data", "processing", "controller"? |
Art.3 is the most dangerous article for SaaS developers. The targeting criterion means GDPR applies to any service offering products or services to EU residents — regardless of where the company is incorporated or where the servers are located. US-incorporated SaaS with a German user base is fully subject to GDPR. Cloud Act exposure compounds this for US-hosted services.
Read the dedicated guide: GDPR Art.1–4 Developer Implementation Guide
Chapter II — Principles (Art.5–11)
Priority: P0 — Art.5 and Art.6 are the most commonly cited articles in 2026 enforcement actions.
| Articles | Topic | Priority |
|---|---|---|
| Art.5 | Seven processing principles | P0 |
| Art.6 | Lawful bases for processing | P0 |
| Art.7 | Conditions for consent | P0 |
| Art.8 | Children's consent | P1 |
| Art.9 | Special categories of data | P0 |
| Art.10–11 | Criminal data / processing without identification | P1 |
Art.5(2) accountability principle means you must be able to demonstrate compliance — not just be compliant. This transforms GDPR from a passive legal requirement into an active engineering obligation: logging, audit trails, documented decisions, data maps.
Art.6 lawful bases — choosing the wrong basis is the single most common violation pattern. Consent is not always the right choice. Legitimate interests requires a three-part balancing test. Contract performance has a narrower scope than most developers assume.
- GDPR Art.5: Seven Principles
- GDPR Art.6: Lawful Bases for Processing
- GDPR Art.7: Conditions for Consent
- GDPR Art.8: Children's Consent and Age Verification
- GDPR Art.9: Special Categories (Health, Biometric, Genetic)
- GDPR Art.10–11: Criminal Convictions and Processing Without Identification
Chapter III — Rights of Data Subjects (Art.12–23)
Priority: P0 for Art.12–17 (transparency and access rights are the 2026 CEF enforcement focus)
| Articles | Topic | Priority |
|---|---|---|
| Art.12–14 | Transparency obligations / Privacy notice | P0 |
| Art.15–17 | Access, rectification, erasure (right to be forgotten) | P0 |
| Art.18–20 | Restriction, notification, portability | P1 |
| Art.21–22 | Right to object / Automated decision-making | P1 |
| Art.23 | Restrictions by national law | P2 |
Implementation trap for Art.15–17: Erasure does not mean deleting one database table. It means cascade deletion across all systems — backups, analytics pipelines, third-party integrations, audit logs (where legally permissible), CDN cache layers. The technical scope of a GDPR erasure request is consistently underestimated.
Art.22 automated decision-making has direct implications for any SaaS using ML models that affect users — credit scoring, content moderation, job screening. By 2026 this article intersects directly with EU AI Act obligations.
- GDPR Art.12–14: Transparency and Privacy Notice Requirements
- GDPR Art.15–17: Right to Access, Rectification, and Erasure
- GDPR Art.18–20: Restriction, Notification, and Data Portability
- GDPR Art.21–22: Right to Object and Automated Decision-Making
Chapter IV — Controller and Processor Obligations (Art.24–43)
Priority: P1 across the board — this is the operational architecture chapter
Chapter IV is the largest and most operationally relevant chapter for SaaS builders. It defines what you must build and document to operate as a compliant data controller or processor.
| Articles | Topic | Priority |
|---|---|---|
| Art.23–24 | Restrictions / Controller responsibility + TOMs | P1 |
| Art.25 | Privacy by design and by default | P1 |
| Art.26 | Joint controllers | P1 |
| Art.27 | EU representative (for non-EU controllers) | P1 |
| Art.28 | Processor contracts (DPA requirements) | P0 |
| Art.29 | Processing under authority | P2 |
| Art.30 | Records of Processing Activities (RoPA) | P1 |
| Art.31 | Cooperation with supervisory authorities | P1 |
| Art.32 | Technical and organisational security measures | P0 |
| Art.33–34 | Breach notification (72-hour rule) | P0 |
| Art.35–36 | DPIA and prior consultation | P1 |
| Art.37–39 | DPO designation and tasks | P1 |
| Art.40–43 | Codes of conduct and certification | P2 |
Art.28 processor contracts are the most commonly overlooked P0 obligation. Every third-party tool that processes personal data on your behalf — analytics, monitoring, email, payments — requires a signed DPA with specific mandatory clauses. Using a tool without a DPA makes you the party liable for any processing violation downstream.
Art.32 security measures are not a compliance checkbox. They must be proportional to the specific risk and the state of the art. TLS, encryption at rest, key management, access controls, and audit logging are the baseline — what the EDPB and national DPAs call "minimum expectation" in 2026.
Art.33–34 breach notification requires notification to the DPA within 72 hours of becoming aware of a breach — not 72 hours after you have fully investigated it. This means you need an incident response process that can produce a preliminary notification with incomplete information.
- GDPR Art.23–24: Controller Responsibility and TOMs
- GDPR Art.25: Privacy by Design and by Default
- GDPR Art.26: Joint Controllers
- GDPR Art.27: EU Representative for Non-EU Controllers
- GDPR Art.28: Processor Contracts — DPA Requirements
- GDPR Art.29: Processing Under Authority
- GDPR Art.30: Records of Processing Activities (RoPA)
- GDPR Art.31: Cooperation with Supervisory Authorities
- GDPR Art.32: Technical and Organisational Security Measures
- GDPR Art.33–34: Breach Notification — The 72-Hour Rule
- GDPR Art.35: Data Protection Impact Assessment (DPIA)
- GDPR Art.36: Prior Consultation with Supervisory Authorities
- GDPR Art.37–39: DPO Designation, Position, and Tasks
- GDPR Art.40–43: Codes of Conduct and Certification
Chapter V — Third Country Transfers (Art.44–49)
Priority: P0 for any SaaS using US-based tools or cloud providers
Chapter V governs data flows outside the EU/EEA. Post-Schrems II, this chapter is the single largest compliance risk for SaaS builders who use US-incorporated tooling (AWS, GCP, Azure, Stripe, Twilio, SendGrid, Datadog — the list is long).
| Articles | Topic | Priority |
|---|---|---|
| Art.44 | General principle for transfers | P0 |
| Art.45 | Adequacy decisions | P1 |
| Art.46 | Standard Contractual Clauses (SCCs) | P0 |
| Art.47 | Binding Corporate Rules (BCRs) | P2 |
| Art.49 | Derogations | P1 |
The most practical solution to Chapter V compliance is architectural: use EU-only infrastructure that never routes personal data to non-EU processors. When your hosting, database, object storage, monitoring, and email delivery are all EU-incorporated and EU-hosted, Art.44 doesn't trigger for the infrastructure layer.
For every US SaaS tool that remains in your stack, you need:
- A signed SCC (the correct 2021 module for controller-to-processor)
- A Transfer Impact Assessment (TIA) documenting the legal environment in the recipient country
- Documented supplementary measures where required
GDPR Art.44–49: Third Country Transfers, SCCs, and BCRs
Chapter VI — Supervisory Authorities (Art.50–59)
Priority: P1 — Understanding supervisory authority structure helps you navigate enforcement
| Articles | Topic | Key Developer Takeaway |
|---|---|---|
| Art.50–55 | SA independence, competence, and establishment | Who your DPA is and what authority they have |
| Art.56 | Lead Supervisory Authority (One-Stop-Shop) | For SaaS with multi-EU operations, one SA leads |
| Art.57–58 | SA tasks and enforcement powers | What a DPA investigation actually looks like |
Art.56 One-Stop-Shop is the mechanism that lets SaaS companies with EU main establishment deal with a single lead DPA (e.g., Ireland's DPC for Meta, Luxembourg's CNPD for Amazon). For smaller SaaS, your lead SA is typically where your EU main establishment is — or your EU representative's country if you have no EU establishment.
- GDPR Art.50–55: Supervisory Authority Independence and Competence
- GDPR Art.56: Lead Supervisory Authority and One-Stop-Shop
- GDPR Art.57–58: SA Tasks, Powers, and Enforcement
Chapter VII — Cooperation and Consistency (Art.60–76)
Priority: P2 — Understanding EDPB governance matters for multi-jurisdictional compliance
| Articles | Topic |
|---|---|
| Art.60–65 | One-Stop-Shop cooperation, consistency mechanism, dispute resolution |
| Art.66–76 | EDPB structure, independence, and governance |
The consistency mechanism (Art.63–65) is how the EDPB issues binding decisions that override individual national SA rulings. EDPB Guidelines issued under this mechanism are de facto binding interpretation of GDPR for all developers.
- GDPR Art.60–65: Consistency Mechanism and EDPB Binding Decisions
- GDPR Art.66–76: EDPB Structure and Governance
Chapter VIII — Remedies, Liability, and Penalties (Art.77–84)
Priority: P0 — This chapter defines the financial and operational consequences of violations
| Articles | Topic | Key Numbers |
|---|---|---|
| Art.77–82 | Data subject rights to remedies and compensation | Non-material damage claims surging in 2026 |
| Art.83 | Administrative fines — Tier 1 and Tier 2 | Up to EUR 20M or 4% global turnover |
| Art.84 | Member State penalties | Additional national penalties on top of fines |
The fine structure has two tiers:
- Tier 1 (up to EUR 10M / 2% turnover): Violations of Art.8, 11, 25–39, 42–43 — primarily operational failures (no DPA with processors, missing RoPA, inadequate security measures)
- Tier 2 (up to EUR 20M / 4% turnover): Violations of Art.5–7, 9, 12–22, 44–49 — fundamental principles, lawful bases, data subject rights, transfer rules
The 11-factor fine calculation under Art.83(2) means the same violation can produce very different fine amounts. Cooperation with the supervisory authority, prior violations, and the nature of the data are the three factors with the highest weight in EDPB fine guidance.
- GDPR Art.77–82: Data Subject Remedies and Compensation
- GDPR Art.83–84: Administrative Fines and Penalties — With Fine Calculator
Chapter IX — Provisions Relating to Specific Processing (Art.85–91)
Priority: P2 — Applies to specific sectors and use cases
| Articles | Topic | Relevant If |
|---|---|---|
| Art.85–88 | Freedom of expression, employment, research, national ID | Media/journalism SaaS, HR platforms, research tools |
| Art.89 | Research, statistics, archiving in the public interest | Academic/research SaaS |
| Art.90–91 | Professional secrecy, religious organisations | Legal SaaS, denominational platforms |
- GDPR Art.85–88: Expression, Employment, National ID, and Specific Processing
- GDPR Art.89: Research, Statistics, and Archiving Safeguards
- GDPR Art.90–91: Professional Secrecy and Religious Organisations
Chapters X–XI — Delegated Acts, Final Provisions (Art.92–99)
Priority: P2 — Procedural articles that govern how the GDPR is updated and administered
The Infrastructure Shortcut: EU-Native Hosting as Compliance Strategy
A consistent pattern across all chapters in this guide: many of the most complex compliance obligations disappear or simplify dramatically when your infrastructure stack is EU-native.
Chapter V (Transfers): If data never leaves EU jurisdiction, Art.44–49 doesn't trigger for your hosting layer. No SCCs, no TIAs, no Schrems II risk.
Chapter IV Art.32 (Security): EU-incorporated providers are directly subject to GDPR themselves as processors — their security obligations align with yours by regulation, not just by contract.
Chapter VI (Supervisory Authorities): Working with an EU-incorporated PaaS means your providers are under the jurisdiction of the same DPAs you answer to — no CLOUD Act override, no Foreign Intelligence Surveillance Act exposure.
The US CLOUD Act allows US authorities to compel US-incorporated cloud providers to produce data stored anywhere in the world, including EU data centers. This is not a GDPR violation by the provider — it is a structural risk that no contractual safeguard can fully eliminate.
sota.io is an EU-native PaaS hosted in Germany: EU-incorporated, EU-hosted, and not subject to the US CLOUD Act. No Standard Contractual Clauses required for the hosting layer. Deployable in seconds via CLI, Git, or Claude Code MCP.
Implementation Priority Order for New SaaS Projects
If you are building a new SaaS or auditing an existing one, the order that provides the maximum risk reduction per hour of engineering work:
- Establish lawful basis for all processing (Art.6) — document before you build, not after
- Audit your third-party tools for Art.28 DPAs — every processor needs a signed DPA with mandatory clauses
- Implement privacy notice requirements (Art.12–14) — 2026 CEF enforcement focus
- Build a DSAR handler (Art.15–17) — access, rectification, erasure within 30 days
- Create your RoPA (Art.30) — required for all but the smallest organisations
- Implement a breach detection and notification workflow (Art.33–34) — 72-hour DPA notification window
- Evaluate your Chapter V exposure — map every US SaaS tool that touches personal data
- Conduct a DPIA for high-risk processing (Art.35) — required before starting, not after
Related EU Regulation Guides on sota.io
GDPR does not operate in isolation. In 2026, the complete EU compliance picture for SaaS builders includes:
- NIS2 Directive: Cybersecurity obligations for essential and important entities. Art.21 security measures overlap directly with GDPR Art.32.
- EU AI Act: High-risk AI systems require DPIAs (GDPR Art.35), technical documentation, and human oversight mechanisms that intersect with GDPR automated decision-making (Art.22).
- DORA (Digital Operational Resilience Act): For fintech SaaS. ICT risk management, incident reporting, and third-party risk obligations parallel the GDPR processor chain requirements.
- Cyber Resilience Act (CRA): Mandatory security-by-design and vulnerability disclosure for software products with digital elements.
Each of these is covered in the sota.io EU Cyber Compliance Series. Start with the GDPR guide for your use case, then layer the sector-specific regulations on top.