The GDPR has been enforced for over seven years now: more than 2,500 fines totaling over €7 billion. That is a large enough sample to stop treating compliance as legal theory and start reading it as data. And when you sort the fine table by size, a pattern appears that should reorganize how engineering teams think about it: the biggest GDPR problems are database problems.
Look at the top of the table. Meta's €1.2 billion record fine (2023) was for where data flowed: EU user data reaching US servers. TikTok's €530 million (2025) was the same shape, EU data reachable from China. The famous UK fines were database compromises: British Airways (£20M) and Marriott (£18.4M, 339 million guest records exposed through an acquired reservation system). H&M's €35.3M was a shadow database: managers recording employees' private lives in an internal store that too many people could read. Different articles, one common denominator: the regulator's questions were answered by database topology, database access, and database records.
So this post reads GDPR from the database outward: which articles land there, what the enforcement record says they mean in practice, and the controls that hold up.
The Articles That Live in the Database
GDPR is 99 articles; a handful do most of the work in an engineering review:
| Article | Obligation | Where it lands in the database |
|---|---|---|
| Art. 32 Security | "Appropriate technical measures", naming pseudonymisation and encryption explicitly | Encryption at rest/in transit, masking, least-privilege access |
| Art. 17 Erasure | Delete on request, without undue delay | Deletion that reaches replicas, warehouses, and backups |
| Art. 30 Records | Records of processing activities | Knowing which databases and columns hold personal data |
| Art. 33 Breach | Notify the DPA within 72 hours | An audit trail that can scope an incident in hours, not weeks |
| Art. 44+ Transfers | Lawful basis for data leaving the EU | The physical location of every primary, replica, and backup |
The familiar cast (data subject, controller, processor, DPO) allocates the accountability for all of the above; if the roles are new to you, the short version is that the controller answers for everything below.
What the Enforcement Record Teaches
Lesson 1: transfers are a topology question. The two largest fines in GDPR history are not about hacking or dark patterns; they are about which country's infrastructure could reach EU personal data. After Schrems II, "transfer" includes remote access: a support engineer in a third country querying an EU database is a transfer. The compliance artifact regulators want is effectively a map: every primary, replica, analytics copy, and backup of EU personal data, with a location and a legal basis attached. Most teams cannot produce that map, and the common architectural answer is regional isolation:
Same schema everywhere, different data residency per region. It satisfies Chapter V cleanly, and it creates a new operational obligation: every schema migration must now deploy consistently to every region, because drift between the EU and US instances is how "the same application" quietly stops being the same processing.
Bytebase Batch Mode exists for exactly this: one change, deployed and tracked across all regional databases.
Lesson 2: Art. 32 is judged in hindsight, at the database. British Airways and Marriott were fined not for being attacked but for what the attackers found when they reached the data layer: broad access from compromised credentials, insufficient monitoring, personal data readable in bulk. "Appropriate technical measures" is graded after the breach, which means the standard is effectively: would this control have contained the blast radius? Named-and-explicit in the article text: pseudonymisation and encryption. In database terms that is encryption at rest and in transit as table stakes, masking or tokenization for the human access path, and statement-level least privilege so one credential cannot SELECT * the customer table.
Lesson 3: shadow data is a standing violation. H&M's fine came from data that officially didn't exist: notes on employees' health and beliefs accumulated in an internal system with wide access. Every organization has a version of this: the ops dashboard fed by a full production copy, the staging environment restored from prod last year, the analyst's export sitting in a warehouse. Art. 30's records of processing are only as accurate as your data discovery, so classification (which columns, in which databases, hold personal and special-category data) is the control everything else keys off.
Lesson 4: don't plan around annulment. Amazon's €746M fine, the second-largest ever, was annulled on procedural grounds in March 2026, seven years after the underlying conduct, even as the court left the violation findings standing. The legal war of attrition is survivable for a trillion-dollar company; for everyone else the practical reading is unchanged: build the controls.
The Database Work
Condensing the lessons into the working checklist:
- Draw the transfer map before legal asks. Inventory where every copy of EU personal data physically sits, including read replicas, DR sites, log pipelines, and that S3 backup bucket in
us-east-1. This single artifact feeds Art. 30 records, Chapter V analysis, and incident response. - Classify columns, then let controls follow. Masking, access reviews, and erasure jobs all need to know where the personal data is. Do the discovery pass once, keep it maintained in a catalog, and treat new-column review as the enforcement point so classification never goes stale.
- Least privilege at the statement level. The BA/Marriott lesson: standing broad access is what turns a phished credential into a reportable breach. Scope humans to the tables their role needs, mask what they don't need in cleartext, time-box elevated access, and route the rare production write through an approval.
- Erasure that reaches every copy. An Art. 17 request completed on the primary but surviving in the warehouse is not completed. Where immutable stores (backups, append-only logs) make deletion impractical, encrypt per user and erase the key, and write that mechanism into your policy so the DPA sees a design, not an excuse.
- Rehearse the 72-hour clock. Art. 33 gives you 72 hours from awareness to notification, and the notification must scope the breach: whose data, which categories, how much. That is a query against your audit trail. If reconstructing a week of access to a customer table takes longer than an afternoon, you will miss the window; this is the same "logging enabled vs. audit evidence" gap we found in our own SOC 2 audit.
Where Bytebase Fits
Bytebase covers the human-to-database slice of the list: data classification feeding dynamic masking in the SQL Editor, statement-level access control with just-in-time grants, approval workflows for production changes, batch deployment across regional databases, and an exportable audit log for the 72-hour scramble. Encryption at rest, network topology, and your application's own connection are outside its scope; those live in the infrastructure layer, and a GDPR posture needs both.
Closing Thoughts
Seven years of enforcement have made GDPR unusually legible: the record fines are about where data sits, the classic fines are about who could reach it, and the embarrassing ones are about data nobody admitted keeping. All three are answered in the database layer, long before a lawyer gets involved. Build the transfer map, classify the columns, scope the access, and rehearse the clock; the paperwork then describes something real.