GDPR is often summarized as "get consent and let people delete their data," but the technical requirements underneath that summary are what engineering teams actually need to implement.
Data minimization by design
GDPR's "data protection by design and by default" principle means systems should collect and retain only the personal data necessary for the stated purpose. In practice: audit what fields you're actually storing versus what you actually use, and stop collecting fields "just in case."
The right to erasure, technically
"Right to be forgotten" requests require an actual deletion path through every system holding that person's data — including backups, logs, analytics pipelines, and any third-party processor you've shared data with. A common gap: application data gets deleted, but the same identifiers remain in log aggregation systems or data warehouses indefinitely.
Right to access and portability
You need the technical ability to export a specific individual's data in a structured, commonly-used format on request. This requires your data model to support querying "everything associated with this person" — which is hard to retrofit if personal data is scattered without clear ownership.
Encryption and pseudonymization
GDPR doesn't mandate specific encryption algorithms, but Article 32 explicitly calls out encryption and pseudonymization as appropriate technical measures. Encrypting personal data at rest and in transit, and pseudonymizing identifiers where full identification isn't necessary, both directly support compliance.
Breach notification timelines
A confirmed breach involving personal data must be reported to the relevant supervisory authority within 72 hours. This means your incident response process needs a clear, fast path to determine: was personal data involved, and how many individuals are affected — not just "was there unauthorized access."
Data processing agreements with vendors
Any third-party processor handling personal data on your behalf needs a Data Processing Agreement in place. Engineering teams often introduce new sub-processors (a new logging vendor, a new analytics tool) without looping in whoever owns this — building a lightweight approval step for "new vendor touching personal data" avoids this gap.
GDPR compliance isn't a document you write once — it's a set of technical capabilities (deletion, export, encryption, breach detection) that need to actually work when tested.