Why this became an engineering concern, not just a legal one
GDPR (the EU's General Data Protection Regulation), along with similar laws like California's CCPA, turned data handling practices that used to be purely a legal or policy question into something that directly shapes how systems must be built — deletion, export, and consent all need to actually work in the code, not just exist in a privacy policy document.
The right to access and export
A user has the right to request a copy of all personal data a system holds about them. In practice, this means a system needs some reasonably complete way to gather that data — which is far easier to build if personal data is tracked and centralized from the start, rather than scattered undocumented across a dozen tables and third-party services discovered only when the request arrives.
The right to be forgotten
DELETE FROM users WHERE id = ?;
DELETE FROM user_logs WHERE user_id = ?;
DELETE FROM analytics_events WHERE user_id = ?;Deleting a user's row in the main table is rarely sufficient — logs, analytics events, cached copies, and backups can all still contain their data. A real deletion process has to account for every place personal data was copied to, which is exactly why data minimization (not copying personal data around more than necessary in the first place) makes compliance meaningfully easier.
Consent has to be specific and genuinely optional
A pre-checked checkbox, or consent bundled into "agree to our terms" for something unrelated, generally doesn't satisfy GDPR's requirement for freely given, specific, informed consent. Consent for marketing emails and consent for the core service functioning have to be separable — a user should be able to decline the former without losing access to the latter.
Data minimization: collect only what you need
Beyond the legal requirement, collecting only the personal data actually necessary for the service reduces what a breach could expose, shrinks what a deletion request has to cover, and reduces the ongoing burden of keeping data accurate and secure. Every optional field a signup form collects "just in case it's useful later" is a small, compounding liability.
This is not just an EU concern. GDPR practically applies to any service with EU users, regardless of where the company itself is based, and similar laws (CCPA in California, LGPD in Brazil, and others) are spreading. Designing data handling around these principles from the start is far cheaper than retrofitting compliance into a system that was never built with it in mind.
The practical takeaway for engineers
Track what personal data you collect and where it lives, build deletion and export as real, working features rather than manual one-off processes, and default new data collection to "no" unless there's a specific, justified reason to collect it. These habits satisfy the letter of most privacy laws largely as a side effect of being genuinely good data practice.
Comments