Three baselines
- Minimize: don't collect fields you won't use; collecting them makes you responsible for them;
- Encrypt sensitive data: IDs, tokens, health info should not sit in plaintext;
- Support erasure: when a user asks to be deleted, really delete (backups and logs too).
Design for it
- Tag fields public / internal / sensitive, with separate access for sensitive;
- Never log full request bodies; mask phones and passwords;
- Before sharing with third parties, define purpose and scope.
Two pitfalls
- Incomplete anonymization: dropping names can still identify people via other fields;
- Backups forgotten: deleting from the main DB but not backups means you didn't delete.
Real-world cases: three common privacy oversights
- Plain phone numbers in logs: logging whole request bodies for convenience scatters personal data across the logging stack. Mask or hash phone numbers, ID numbers and tokens.
- "Collect it now, useful later": gathering far more fields than the current purpose increases exposure and violates data minimisation. Before adding a field, ask what breaks without it.
- No deletion path: after account closure data lingers in backups, the warehouse and third parties. Deletion must cover the whole chain and leave verifiable records.
FAQ
Is anonymisation the same as pseudonymisation? No — pseudonymised data can still be re-linked, while anonymised data cannot identify a person, and faces stricter rules. How long should logs be kept? By purpose; 7–30 days usually suffices for troubleshooting, and longer retention needs a rationale plus aggregation. Is a consent banner always required? It depends on jurisdiction and purpose: strictly necessary cookies usually need no consent, while analytics and advertising do. Is encryption enough for compliance? Only one control; you still need minimisation, access control, retention limits and deletion.
Data classification and a flow inventory
The most effective compliance tool is a data register with at least four columns: field, classification, storage location and retention.
- Classify: public, internal, sensitive and highly sensitive, each with its own encryption, masking and access requirements;
- Govern per field: review individual fields rather than whole tables, avoiding vague "this table is internal so it does not matter" reasoning;
- Track flows: record which systems data passes through from collection to deletion (logs, warehouse, third-party SDKs) — any hop can leak;
- Access and audit: log every access to highly sensitive fields and disallow bulk export by default;
- Review quarterly: reconcile the register with reality and delete fields and copies with no purpose — data left lying around is risk that will not remove itself.
Beyond compliance, this lowers incident cost: when something happens you can answer immediately which data was affected and how many people are involved.
Everyday checks for developers
- Check sample data before committing: test fixtures and screenshots often contain real user data. Use synthetic data and mask before sharing.
- Be careful with third-party scripts: analytics and tracking send data outward — document what they collect so you do not silently widen your data flows.
- Default to tight access: internal tools should start with the minimum visible scope and grant on request, rather than being company-wide with an honour system.
- Log and cap exports: bulk export is high risk — record who, what range and when, and cap the volume per operation.
- Make deletion verifiable: after deletion, confirm the data is unreadable everywhere, including caches and search indexes, not just absent from primary storage.
None of these is complex, but they must become habits: privacy incidents come from many harmless-looking omissions rather than one dramatic mistake.