GDPR for engineers: what to do before May

On 25 May 2018 the General Data Protection Regulation becomes enforceable, and the penalties are large enough that nobody is ignoring it. It is tempting to file GDPR under “legal”, but that is a mistake: most of what GDPR requires is engineering work, because it is about how your systems collect, store, expose, and delete personal data. If you build the software, a chunk of compliance is your job. Here is a pragmatic, non-lawyer’s guide to what that actually means for the code — with the standard caveat that this is engineering perspective, not legal advice.

Start with a data inventory

You cannot protect, expose, or delete personal data you cannot find, so the foundational task is a data inventory: know what personal data you hold, where it lives, why you have it, and how long you keep it. “Personal data” under GDPR is broad — names, emails, IP addresses, device IDs, anything that can identify a person — and it hides in more places than you think:

• Your obvious model columns (users.email, users.name).
• Logs (request logs full of IPs, error trackers capturing parameters).
• Third-party services you have sent data to (analytics, email providers, support tools).
• Backups, caches, search indexes, and that CSV export someone made in 2016.

Map all of it. This audit is unglamorous and genuinely revealing — most teams discover personal data in places they had forgotten, and you cannot comply with anything else until you know the territory.

Data minimisation: the cheapest compliance

The single most effective principle is also the simplest: do not collect or keep what you do not need. Data you never collected cannot be breached, cannot be requested, and does not need deleting. So before building any compliance machinery, delete the liabilities:

• Stop collecting fields you do not actually use.
• Set retention policies and enforce them — purge old records, truncate logs after a sensible window, expire data you only needed temporarily.
• Anonymise or pseudonymise where you can — if analytics needs patterns, not identities, strip the identities.

Every field you do not hold is a field you do not have to protect, expose on request, or erase. Minimisation turns a large compliance surface into a small one for free.

Consent and lawful basis

GDPR requires a lawful basis for processing personal data, and where that basis is consent, the consent must be freely given, specific, and informed — which kills some patterns engineers built without thinking:

• No pre-ticked boxes. Consent must be an active opt-in, not a checkbox you ticked for them.
• Granular, not bundled. “Accept everything to use the site” is not valid consent for, say, marketing emails; separate purposes need separate consent.
• Withdrawable. It must be as easy to withdraw consent as to give it, and you must record when and how consent was given — so model consent as data (timestamped records), not a single boolean you overwrite.

Practically, this means a consent model in your database with an audit trail, and UI that asks honestly rather than dark-patterns its way to a yes.

The data subject rights: access and erasure

Two rights have direct, concrete engineering consequences, and you need to be able to satisfy them on request:

• Right of access (data portability). A person can ask for all the personal data you hold about them, in a usable format. You need a way to gather everything about one user across all your models and services and export it — which the data inventory makes possible. Build this as a real feature (an export job), not a frantic manual SQL session each time a request arrives.
• Right to erasure (“right to be forgotten”). A person can ask you to delete their personal data, and you must be able to do it — across your database, your logs, your backups (within reason), and your third-party processors. This is harder than it sounds: a naive user.destroy may violate foreign keys, orphan records, or break financial records you are legally required to keep. The pattern is usually to anonymise rather than hard-delete where you must retain the record (an order must survive for tax law, but can have its personal fields scrubbed), and to propagate the deletion to every service you forwarded the data to.

Design both as deliberate operations on your data model, tested, so that when a request comes you run a known process rather than improvising.

Privacy and security by design

GDPR expects privacy to be built in, not bolted on, and several engineering practices follow:

• Encrypt personal data in transit (TLS everywhere) and sensitive data at rest.
• Limit access — least-privilege on who and what can read personal data, including internal tools and staff.
• Breach notification. GDPR requires notifying authorities of a breach within 72 hours, which means you need the monitoring and logging to detect a breach in the first place — another reason the observability work matters.
• Vet your processors. Every third party you send personal data to is your responsibility; you need agreements with them and to know they are compliant too.

Verdict

GDPR is not a legal formality you can hand off — it is a set of requirements that live in your data model, your retention policies, your consent flows, and your ability to export and erase a person’s data on demand. The work, in order: inventory the personal data you hold (you have more, in more places, than you think); minimise ruthlessly, because the cheapest data to protect is the data you never kept; model consent honestly with an audit trail; and build access and erasure as real, tested features — anonymising where you must legally retain records. Treat privacy and security as design constraints, not afterthoughts. Done properly, GDPR is less a burden than a forcing function for the data hygiene you should have had anyway — and the May deadline is simply when “should” became “must”.