GDPR for Engineers: Data Subject Rights & Implementation

GDPR for Engineers

GDPR is a long document and the engineering consequences reduce to a manageable list. You need to know what personal data you hold and why, you need to be able to give it to the person it's about, correct it, delete it, and export it in a portable format, all within a month. You need to log processing activities, detect and report breaches within 72 hours, and build systems that collect the minimum and protect it by default.

Most of that is systems work. The lawyers determine lawful basis and draft the notices; engineering determines whether the answer to "can you delete this person's data from every system?" is yes or a shrug. A team that never asked the question ships a product where the honest answer is "we don't know," which is both a compliance failure and an operational one.

The framing that helps most: GDPR is a set of functional requirements with an unusual stakeholder. Design for them and they cost very little. Retrofit them and each one is a project.

TL;DR

Personal data is anything relating to an identifiable person — broader than "PII," and includes IPs and device IDs.
Every processing activity needs a lawful basis: consent, contract, legal obligation, vital interests, public task, or legitimate interests.
Eight data subject rights; the load-bearing ones for engineers are access, erasure, and portability.
One month to respond to a request (extendable to three for complex cases).
72 hours to notify a supervisory authority of a reportable breach — from awareness, not from resolution.
Data minimization and purpose limitation are legal requirements, not best practices.
A RoPA (record of processing activities) is mandatory; it's essentially your data inventory.
Applies based on whose data you process, not where you're incorporated.

Core Concepts

Lawful basis

Every processing activity needs one, chosen before processing and documented. It's not a formality — the basis determines which rights apply.

The practical implication for a system: you need to know, per data category, which basis applies — because a user withdrawing consent for analytics must not delete the invoices you're legally required to keep.

The eight rights

Rights 2, 4, and 6 are the ones that require real engineering. The others are largely policy, a flag, or a process — with the exception of right 5 (restriction), which needs a state where data is retained but not processed, and that's easy to get wrong if "restricted" users still appear in a batch job.

Subject access and portability

Portability (Article 20) is stricter than access: the data the user provided must be in a structured, commonly used, machine-readable format — JSON or CSV, not a PDF. Access can include derived data; portability is limited to what they gave you plus what you observed about them.

The hard part is completeness. The systems people forget: the analytics warehouse, the support tool, the email service provider, the CRM, backups, and log aggregation. See PII & Sensitive Data Handling.

Erasure

Anonymization is often the right answer instead of deletion. An order record with the customer replaced by a non-reversible identifier keeps your financial reporting intact while no longer being personal data. This is the standard approach for transactional history.

Backups are the recurring hard question. The accepted approach: define a backup retention window (30–90 days) so deleted data ages out, ensure a restore re-applies pending erasures, and document the whole thing. See Data Retention & Deletion.

Breach notification

72 hours from awareness, not from resolution — you notify with partial information and follow up. That has a direct engineering implication: you need detection and enough audit logging to answer "what was accessed, by whom, and whose data was it?" within days. A team without those logs cannot characterize a breach, and "we don't know what was taken" is the worst possible answer to a regulator.

DPIAs

A Data Protection Impact Assessment is required before processing that's likely to be high risk — large-scale monitoring, systematic profiling, special-category data at scale, automated decisions with legal effects, or new technologies applied to personal data.

For engineers it's a design document with a privacy lens: what data, why, what's the risk, what mitigations. Done at design time it's a few hours; done after building it's a rework exercise. Treat it like an ADR for a feature touching personal data.

International transfers

Moving personal data outside the EEA needs a legal mechanism: an adequacy decision (the UK, Switzerland, Japan, and — currently — the US via the Data Privacy Framework), Standard Contractual Clauses, or Binding Corporate Rules.

The engineering consequence is data residency: knowing and controlling where data physically lives, which region your cloud resources are in, and which sub-processors your vendors use. The legal landscape here has been unstable — Safe Harbor and Privacy Shield were both invalidated — so build for regional isolation rather than assuming today's mechanism persists.

Building For It

The stable subject identifier is the piece most often missing. If the analytics warehouse keys on a different ID than the application, and the support tool keys on email, then satisfying a request means a fuzzy join across three systems — which is slow, error-prone, and impossible to prove complete.

Best Practices

Build the DSAR pipeline before you need it

The first request will come, and doing it manually across eight systems takes days and misses things. An automated export and erasure path is a week of work built proactively and a crisis built reactively.

Maintain the RoPA as a living artifact

Article 30 requires a record of processing activities. Generate it from schema annotations and infrastructure code rather than maintaining a spreadsheet — a document updated once a year is wrong within a quarter and provides no operational value. See PII & Sensitive Data Handling.

Prefer contract over consent for core functionality

Consent is revocable, must be granular, and creates an obligation to stop and delete. For processing genuinely necessary to deliver the service the user signed up for, contract is the appropriate and far more robust basis.

Anonymize rather than delete transactional records

Replacing the customer reference in an order with a non-reversible identifier satisfies erasure while preserving financial and operational data. This is standard practice and usually the correct interpretation.

Include third parties in every flow

Processors — your email provider, analytics vendor, support tool, CRM — hold personal data on your behalf and are in scope for both access and erasure. Maintain the list, ensure each has a data processing agreement, and include them in the automated pipeline.

Log processing, and don't log the data

You need an audit trail of who accessed what. That trail must not itself become a second copy of the personal data — record identifiers and actions, not payloads, and apply the same retention rules to it.

Set retention at collection time

Every field gets a retention period when it's introduced, enforced by an automated job. "We'll figure out retention later" means keeping everything forever, which is both a legal exposure and a growing breach blast radius.

Do the DPIA at design time

A privacy review alongside the architecture review, for anything touching personal data at scale. It's cheap before implementation and a rework exercise afterward.

Common Mistakes

No stable identifier across systems

Treating consent as the default basis

A deletion that misses systems

Personal data in audit logs

No breach detection

Assuming it doesn't apply

FAQ

Does GDPR apply to us if we're not in the EU?

If you offer goods or services to people in the EU, or monitor their behavior, yes — Article 3 is explicitly extraterritorial. Incidental access by an EU resident to a purely domestic service is a grayer area, but any deliberate targeting (EU language options, EUR pricing, EU shipping) puts you in scope. In practice, most consumer-facing internet services should assume it applies.

How long do we have to respond to a request?

One month from receipt, extendable by two further months for complex or numerous requests — with the extension communicated to the individual within the first month. You must also verify identity before disclosing anything, and doing that badly is its own risk: releasing someone's data to an impostor is a breach.

Can we refuse an erasure request?

Yes, in specific circumstances: a legal obligation to retain (tax and accounting records are the common one), establishment or defense of legal claims, freedom of expression, and public health or archival purposes. You must respond explaining which data is retained and why. What you cannot do is refuse because deletion is technically inconvenient.

What about backups?

The generally accepted position is that immediate deletion from backups isn't required, provided you can show the data will age out on a defined schedule, that it isn't actively used, and that a restore re-applies pending erasures. Document the backup retention window. Crypto-shredding — per-user encryption keys, destroyed on erasure — makes the backup copy unreadable and is the strongest technical answer.

Do we need a Data Protection Officer?

Required if you're a public authority, if your core activities involve large-scale systematic monitoring, or if you process special-category data at scale. Many organizations appoint one voluntarily, and Germany has a lower threshold than the regulation's baseline. The engineering-relevant point is that a DPO is an independent role who must be involved in system design decisions, not consulted afterward.

What are the actual penalties?

Up to €20 million or 4% of global annual turnover, whichever is higher, for the most serious violations; up to €10 million or 2% for others. Large fines have been issued and cluster around a few patterns: inadequate lawful basis for advertising, insufficient security leading to a breach, and unlawful international transfers. Regulators have generally been more lenient with organizations that could demonstrate genuine effort and documentation — which is another argument for building the inventory and the audit trail.