Data Privacy
In a Nutshell
Data privacy is about handling people's personal information responsibly and lawfully — collecting only what you need, using it only for stated purposes, protecting it, and honoring individuals' rights over their own data. Where encryption and access control are about security (keeping data safe from attackers), privacy is about governance (what data you collect, why, how long you keep it, and who you share it with). Regulations like GDPR and CCPA turn these principles into legal obligations with serious penalties. For system designers, privacy isn't a legal afterthought — it shapes data models, retention policies, logging, and architecture from the start ("privacy by design").
How It Actually Works
PII and Sensitive Data
The core object of privacy is PII (Personally Identifiable Information) — anything that identifies a person:
| Category | Examples |
|---|---|
| Direct identifiers | Name, email, phone, SSN, passport |
| Quasi-identifiers | Birth date, ZIP code, gender (combine to re-identify) |
| Sensitive PII | Health, biometrics, race, religion, sexual orientation, financial |
| Online identifiers | IP address, device ID, cookies, location |
Sensitive PII gets stricter protection. Quasi-identifiers matter because combinations can re-identify someone even without direct identifiers.
The Core Privacy Principles
| Principle | Meaning |
|---|---|
| Data minimization | Collect only what you actually need |
| Purpose limitation | Use data only for the purpose it was collected for |
| Storage limitation | Keep data only as long as necessary; then delete |
| Consent | Get clear, informed permission before collecting/processing |
| Transparency | Tell people what you collect and why |
| Individual rights | Let people access, correct, delete, and export their data |
| Accountability | Be able to demonstrate compliance |
Key Regulations
| Regulation | Scope | Notable Rights/Rules |
|---|---|---|
| GDPR (EU) | Anyone processing EU residents' data | Access, erasure ("right to be forgotten"), portability, consent, breach notification (72h); fines up to 4% of global revenue |
| CCPA/CPRA (California) | California residents | Know, delete, opt out of sale |
| HIPAA (US) | Health data | Strict PHI protection |
| PCI DSS | Card data | Cardholder data security standards |
These apply based on whose data you handle, not just where you are — a US company with EU users must comply with GDPR.
Techniques for Protecting Privacy
Beyond encryption, privacy-preserving techniques reduce the risk and identifiability of data:
| Technique | What It Does | Reversible? |
|---|---|---|
| Anonymization | Remove identifiers so data can't be traced to a person | No (if done right) |
| Pseudonymization | Replace identifiers with a token/key | Yes (with the mapping) |
| Tokenization | Swap sensitive values for non-sensitive tokens | Yes (via a secure vault) |
| Data masking | Hide parts of data (****-****-****-1234) |
Depends |
| Aggregation | Report only group-level stats, not individuals | No |
| Differential privacy | Add statistical noise so individuals can't be isolated | No |
Pseudonymization (GDPR-favored) keeps data useful while reducing risk: store PII separately, reference it by token, so most systems never touch raw identifiers.
Privacy by Design
Privacy must be built into architecture, not bolted on:
- Minimize collection at the source (don't log full PII "just in case").
- Separate PII from other data (a dedicated, tightly-controlled PII store).
- Encrypt sensitive fields; restrict access via least privilege.
- Design for deletion: know where every copy of a user's data lives so
you can actually honor "delete my account" (including backups, logs,
caches, analytics, third parties).
- Set retention/TTL policies so data auto-expires.
- Anonymize/pseudonymize data used for analytics and ML.The hardest engineering challenge is usually the right to erasure — actually deleting all copies of a person's data scattered across databases, backups, logs, caches, search indexes, and third-party processors.
Seeing It in Action
Scenario: Designing a system to be GDPR-compliant from the start.
Data minimization:
- Signup asks only for what's needed (email). Don't collect birthdate,
phone, or address unless a feature genuinely requires it.
- Logs/analytics avoid raw PII (log a user token, not the email).
Architecture (privacy by design):
┌─ PII Vault (tightly controlled) ─┐ maps user_7f3a → {email, name}
│ - encrypted, least-privilege │
│ - separate store + separate keys │
└──────────────────────────────────┘
Everything else references users by the token "user_7f3a":
orders, events, analytics, ML features → NO raw PII.
→ A breach of the analytics DB exposes tokens, not identities.
Consent & transparency:
- Explicit, granular consent (marketing emails: opt-in, unticked).
- Clear privacy notice: what's collected, why, how long, who it's shared with.
- Record consent (what, when, version) for accountability.
Retention:
- TTL policies: inactive-account data purged after N months.
- Logs rotated and expired; no indefinite PII retention.
Honoring individual rights:
- Access/export: assemble all of a user's data on request (portability).
- Erasure ("delete my account"): a documented process that removes the
PII-vault entry AND scrubs/anonymizes references across databases,
caches, search indexes, backups (per policy), and notifies third-party
processors to delete too. Deleting the vault entry alone de-identifies
the tokenized data everywhere at once — the key design win.
Breach readiness:
- Detection + a 72-hour notification process (GDPR requirement).Why privacy-by-design pays off: the single most powerful decision here is isolating raw PII into a separate, guarded vault and referencing users by token everywhere else. This makes almost every privacy obligation dramatically easier: analytics and ML never touch identities (minimization), a breach of most systems exposes only meaningless tokens (protection), and — crucially — honoring "delete my account" can be as simple as deleting the one vault entry, which instantly de-identifies all the tokenized data scattered across the system, instead of hunting down and scrubbing personal data from dozens of tables, logs, and indexes. Retrofitting privacy onto a system that sprayed raw PII everywhere is painful, error-prone, and often incomplete; building the boundary in from day one turns compliance from a scramble into a property of the architecture. Privacy, like security, is far cheaper designed-in than bolted-on.
Interview Questions
Q: What's the difference between data privacy and data security? Hint: Security is protecting data from unauthorized access/attackers (encryption, access control, hardening). Privacy is responsible governance of personal data — what you collect, why, how long you keep it, who you share it with, and honoring individuals' rights. You can be secure but not private (safely storing data you shouldn't have collected). Privacy requires security plus governance, consent, minimization, and rights.
Q: What are the core data-privacy principles (e.g., under GDPR)? Hint: Data minimization (collect only what's needed), purpose limitation (use only for the stated purpose), storage limitation (keep only as long as necessary), consent (informed permission), transparency (disclose what/why), individual rights (access, correct, delete, export/portability), and accountability (demonstrate compliance). Together they shift the default from "collect everything" to "collect deliberately and delete promptly."
Q: Compare anonymization, pseudonymization, and tokenization. Hint: Anonymization irreversibly strips identifiers so data can't be traced to a person (not reversible if done right). Pseudonymization replaces identifiers with a token but keeps a separate mapping (reversible with the key) — GDPR-favored, keeps data useful while reducing risk. Tokenization swaps sensitive values for tokens redeemable via a secure vault. Anonymized data falls outside many privacy rules; pseudonymized data doesn't (still personal).
Q: Why is the "right to erasure" hard to implement, and how does architecture help? Hint: A user's data is scattered across many databases, caches, search indexes, logs, backups, analytics, and third-party processors — deleting all copies reliably is genuinely hard. Architecture helps by isolating raw PII in one guarded vault and referencing users by token elsewhere: deleting the vault entry de-identifies all tokenized data at once, turning erasure from a system-wide hunt into a single controlled deletion (plus policy for backups/third parties).
Q: What does "privacy by design" mean in practice? Hint: Building privacy into architecture from the start rather than bolting it on: minimize collection at the source, separate and encrypt PII, apply least-privilege access, set retention/TTL so data auto-expires, design for deletion (know where every copy lives), and anonymize/pseudonymize data for analytics/ML. It makes compliance a property of the system instead of a costly retrofit.
References
- GDPR official text & summary — the EU regulation explained
- OWASP: Privacy Risks — top privacy risks for developers
- NIST Privacy Framework — a structured approach to privacy
Dive Deeper
- Privacy by Design (Ann Cavoukian) — the seven foundational principles
- Differential privacy explained (Apple/Google approaches) — protecting aggregate data
- Data anonymization pitfalls (re-identification research) — why anonymization is harder than it looks