How to Discuss GDPR Compliance in English

Learn the English vocabulary and phrasing for discussing GDPR compliance with engineers, legal, and stakeholders, from data subject requests to lawful basis.

“Is this GDPR compliant?” is rarely a yes-or-no question an engineer can answer alone, and this guide covers the vocabulary that lets a technical team have a precise, useful conversation with legal instead of guessing at what compliance actually requires.

Key Vocabulary

Lawful basis — the specific legal justification, such as consent or legitimate interest, that permits processing a particular piece of personal data, required to be identified explicitly for every category of data collected. “We can’t just collect this field because it’s useful — we need a lawful basis for it first. If it’s not covered by our existing consent flow, legal needs to confirm whether legitimate interest actually applies here.”

Data subject request (DSR) — a request from an individual to access, correct, delete, or export their personal data, which the system needs to be able to fulfill within a legally required timeframe, usually a month. “This deletion needs to cascade through every system that stores this user’s data, not just the primary database — if we get a data subject request for erasure, we’re legally required to actually remove it everywhere, not just where it’s convenient.”

Data minimization — the principle of only collecting personal data that’s actually necessary for a specific, stated purpose, rather than collecting broadly in case it’s useful later. “I’d push back on adding this field to the signup form — we don’t have an actual use for it yet, and collecting it without a defined purpose is exactly the kind of thing data minimization is meant to prevent.”

Data processing agreement (DPA) — a contract between a data controller and a third-party processor specifying how personal data will be handled, required before sending user data to any external vendor or service. “We can’t send this data to the new analytics vendor yet — legal confirmed we need a signed data processing agreement in place first, since they’d be processing personal data on our behalf.”

Retention period — the defined length of time personal data is kept before being deleted or anonymized, which needs to be justified by an actual business or legal need rather than kept indefinitely by default. “Right now we’re keeping these logs forever, which isn’t defensible under GDPR — we need an actual retention period, tied to a stated reason, and a process that actually deletes data once that period ends.”

Common Phrases

  • “What’s the lawful basis for collecting this specific field?”
  • “Can our system actually fulfill a data subject request within the required timeframe?”
  • “Is this data minimization, or are we collecting more than we currently need?”
  • “Do we have a data processing agreement with this vendor before we send them user data?”
  • “What’s the retention period on this data, and is it actually being enforced?”

Example Sentences

Raising a concern in a design review: “Before we add this field to the onboarding flow, I want to confirm the lawful basis with legal — collecting it under our current consent language might not cover this use case, and I’d rather check now than after it’s already shipped.”

Explaining a technical requirement to a non-technical stakeholder: “A data subject request for erasure isn’t just deleting the row in our main database — this user’s data also lives in our analytics pipeline and our email vendor’s system, and we’re legally required to remove it from all three within thirty days.”

Pushing back on scope creep: “I’d rather not collect this data speculatively, in case it’s useful for a future feature — data minimization means we should only be collecting what we have a defined purpose for right now, not building a backlog of personal data we might use later.”

Professional Tips

  • Ask about lawful basis explicitly, and early, whenever a feature introduces new personal data collection — retrofitting a lawful basis after data is already being collected is a much harder conversation with legal than having it upfront.
  • Build systems with data subject request fulfillment in mind from the start — a system where user data is scattered across many stores with no clear way to locate and delete it all becomes a serious operational problem when a real request arrives.
  • Apply data minimization as a default engineering habit, not just a compliance checkbox — asking “do we actually need this field” before adding it prevents a much harder cleanup conversation later.
  • Confirm a data processing agreement is in place before sending user data to any new third-party vendor — this is a legal, not just technical, gate, and skipping it is a common and serious compliance gap.
  • Define and enforce a retention period for every category of personal data stored — indefinite retention with no stated justification is one of the more common findings in a GDPR audit.

Practice Exercise

  1. Explain what lawful basis means and why it needs to be identified before collecting new data.
  2. Describe what a system needs to support in order to fulfill a data subject request.
  3. Write a sentence explaining the difference between data minimization and simply collecting less data by accident.