We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Data Governance Compliance
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Data Governance Compliance
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
On May 25, 2018, the General Data Protection Regulation (GDPR) went into effect. Overnight, every company that processes data of EU residents, regardless of where the company is based, became subject to fines of up to 4% of global annual revenue or 20 million euros, whichever is higher.
This isn't a European-only concern. If your SaaS product has a single user in Germany, GDPR applies to you. If your mobile app is available in the EU App Store, GDPR applies. If your website is accessible from France and collects cookies, GDPR applies.
The regulation has teeth. Amazon was fined 746 million euros by Luxembourg's CNPD for targeted advertising practices. Meta was fined 1.2 billion euros by Ireland's DPC for transferring EU user data to the US without adequate safeguards. WhatsApp was fined 225 million euros for failing to be transparent about data sharing with Facebook. These aren't warnings. They're business-threatening penalties.
For engineers, GDPR isn't just legal text to hand off to lawyers. It imposes specific technical requirements: the right to erasure (you must be able to delete all of a user's data across every system), the right to portability (you must be able to export it in a machine-readable format), data breach notification (you must detect and report breaches within 72 hours), and privacy by design (you must build privacy into your architecture from the start, not bolt it on after launch).
| Principle | What It Means | Engineering Implication |
|---|---|---|
| Lawfulness, fairness, transparency | Have a legal basis for processing; be transparent about what you do | Consent management system, clear privacy policy, no dark patterns in cookie banners |
| Purpose limitation | Collect data for specific, stated purposes only | Don't repurpose marketing data for AI training without new consent |
| Data minimization | Collect only what's necessary | Don't collect DOB if you only need age verification (just store "over 18: yes/no") |
| Accuracy | Keep data accurate and up to date | Allow users to edit their data; validate inputs; handle name changes |
| Storage limitation | Don't keep data longer than needed | Automated retention policies with TTLs; data deletion workflows |
| Integrity and confidentiality | Protect data with appropriate security | Encryption at rest + in transit, access controls, pseudonymization |
| Accountability | Be able to demonstrate compliance | Audit logs, data processing records, Data Protection Impact Assessments (DPIAs) |
The accountability principle is the one most engineers miss. It's not enough to be compliant. You must be able to prove it. When a regulator asks "show me evidence that encryption has been enabled on all databases for the past 12 months," you need timestamped audit logs, not a verbal assurance.