GDPR and privacy for engineers

01What counts as personal data

Personal data is any information relating to an identified or identifiable living person. Names and emails are obvious. Less obvious: IP addresses, device IDs, cookie IDs, order histories, location points, voice recordings and support chat logs. If you can link it back to a person, alone or combined with other data you could reasonably get, it counts. Some categories are 'special' and need stronger justification: health, biometric data used for identification, religion, political opinions, sexual orientation, trade-union membership, racial or ethnic origin, genetic data. Pseudonymised data, such as a user ID in an analytics table, is still personal data because you can re-identify it. Only truly anonymised data, where re-identification is not reasonably possible, falls outside the law, and real anonymisation is harder than it looks.

• Controller: decides why and how data is processed (usually your client or company).
• Processor: processes data on the controller's behalf (your hosting, email or analytics vendor).
• Data subject: the person the data is about.

02The principles, translated into engineering

Article 5 lists the principles every system must follow, and each maps to concrete design choices. Lawfulness, fairness and transparency: a valid reason for each use, explained in a privacy notice. Purpose limitation: data collected for delivery is not silently reused for unrelated profiling. Data minimisation: do not collect a birth date if you only need to know the user is an adult. Accuracy: let users correct their data. Storage limitation: delete or anonymise data when its purpose ends, with automatic retention jobs. Integrity and confidentiality: encryption, access control, logging. Accountability: be able to show what you do, through documentation, records and audit trails. Article 25 adds 'data protection by design and by default': the most private option should be the default setting.

03Lawful bases and consent done right

Every processing activity needs one of six lawful bases: consent, contract, legal obligation, vital interests, public task or legitimate interests. Engineers often assume consent is always needed; it is not. Processing an order uses 'contract'. Keeping invoices uses 'legal obligation'. Fraud prevention often uses 'legitimate interests' after a balancing test. Consent is right for optional things such as marketing emails or non-essential tracking, and it must be freely given, specific, informed and unambiguous: no pre-ticked boxes, no 'by using this site you agree'. It must be as easy to withdraw as to give. For cookies and similar storage on a device, the separate ePrivacy rules require consent for anything not strictly necessary, so analytics and advertising cookies wait until the user agrees.

1-- Store consent as an auditable event, never as a single boolean
2CREATE TABLE consent_events (
3  id           BIGSERIAL PRIMARY KEY,
4  user_id      BIGINT NOT NULL REFERENCES users(id),
5  purpose      TEXT NOT NULL,          -- 'marketing_email', 'analytics'
6  granted      BOOLEAN NOT NULL,       -- true = given, false = withdrawn
7  notice_version TEXT NOT NULL,        -- which privacy text the user saw
8  source       TEXT NOT NULL,          -- 'signup_form', 'settings_page'
9  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
10);
11-- Current state = latest event per (user_id, purpose)

04Building data subject rights into the product

People have rights you must be able to honour, usually within one month (extendable by two further months for complex requests). Access: give them a copy of their data and information about how it is used. Rectification: let them fix inaccurate data. Erasure (the 'right to be forgotten'): delete data when there is no longer a valid reason to keep it, while retaining what a law requires, such as invoices. Portability: provide data they gave you in a structured, machine-readable format like JSON or CSV. Objection and restriction: stop certain processing, such as direct marketing, on request. Engineering-wise, this means a data map that knows every table, bucket, log and third party holding a user's data, plus tested export and deletion jobs. Verify the requester's identity first, so the access feature does not become a data leak.

• Self-service export and delete in account settings reduce support load.
• Deletion must reach backups, search indexes, caches and processors on a known schedule.
• Log each request and its completion for accountability.

05Security, breaches and the 72-hour clock

The GDPR requires 'appropriate technical and organisational measures' for security, judged by risk. Typical expectations: encryption in transit (TLS) and at rest, least-privilege access, multi-factor authentication for staff, audit logs on access to personal data, secure development practices and tested backups. A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, disclosure of or access to personal data, not only hacks: an email to the wrong recipient counts. The controller must notify the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people, and must inform affected people directly when the risk is high. Processors must tell the controller without undue delay. Every breach, even unreported ones, must be documented internally.

06Vendors, transfers and paperwork that matters

Each vendor that processes personal data for you, such as hosting, email delivery, analytics or error tracking, is a processor and needs a data processing agreement (Article 28). Keep a list of them; it doubles as your sub-processor list for customers. Sending personal data outside the European Economic Area requires a transfer mechanism: an adequacy decision (including the EU-US Data Privacy Framework for certified US companies), standard contractual clauses, or another Chapter V tool. Organisations must keep records of processing activities (Article 30), and high-risk processing such as large-scale monitoring or sensitive data needs a data protection impact assessment (Article 35) before launch. Engineers rarely write these documents, but they supply the facts: what is collected, where it is stored, who can access it and for how long.

07Privacy by design in the data model

Design the schema so privacy is easy. Separate identity data (name, email, phone, address) from behavioural data (orders, events), joined by an internal ID, so analytics and exports can work on the behavioural side without identity fields. Mark personal columns in code or schema comments so tooling can find them. Add retention metadata: a created date, a purpose and an expiry rule per table. Use field-level encryption for highly sensitive values, with keys managed outside the database. Keep audit tables of who accessed or changed personal data, especially from admin panels. When a user is deleted, the design should make it a few well-defined operations rather than a hunt across the codebase.

1// Retention job: anonymise inactive guest orders after the retention period
2await db.order.updateMany({
3  where: {
4    userId: null,
5    createdAt: { lt: subMonths(new Date(), RETENTION_MONTHS) },
6    anonymisedAt: null,
7  },
8  data: {
9    guestEmail: null,
10    guestPhone: null,
11    shippingAddress: null,
12    anonymisedAt: new Date(),
13  },
14});

08Logs, observability and AI tools

Logs are the most common hidden store of personal data. Request logs capture emails, tokens and IP addresses; error trackers capture form payloads; session replay tools can record everything typed. Configure scrubbing at the source: allow-list fields rather than block-list, mask query strings, and set short retention for raw logs. Treat observability vendors as processors with agreements and regions you chose. The same applies to AI services: sending support tickets or user documents to a large language model API is a transfer to a processor, so check the vendor's data processing terms, retention, training use and region, and strip identifiers when the task does not need them.

09International transfers in practice

Chapter V restricts transfers of personal data outside the EEA. The cleanest route is an adequacy decision: the EU has recognised countries such as the UK, Switzerland, Japan and South Korea, and the EU-US Data Privacy Framework covers US companies that self-certify; it survived a first court challenge at the EU General Court in 2025, though further appeals are possible. Otherwise, standard contractual clauses plus a transfer impact assessment are the usual tool. Engineering choices reduce the problem: choose EU regions for primary storage, check where support and sub-processors access data from, and avoid sending raw personal data to tools that do not need it. Keep the vendor and region list current, because customers will ask.

10Change is coming: keep an eye on reforms

Privacy law is not static. In November 2025 the European Commission proposed a 'Digital Omnibus' package that would amend parts of the GDPR and the cookie rules; at the time of writing (November 2026) the data-protection part is still being negotiated by the Parliament and Council, so the current GDPR text applies unchanged. National regulators also publish guidance that shifts practice, for example on cookie banners, pseudonymisation and legitimate interests. As an engineer, build systems that are easy to adapt: configurable retention periods, purpose-tagged consent, a central data map and feature flags around trackers. When the rules change, you then adjust settings rather than rebuild.