How to Discuss GDPR Compliance in English

“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.

Navigating Nuances: Supporting Non-Native Speakers

Discussing GDPR compliance effectively requires precision – not just in the technical details of data protection regulations, but also in the language we use. For developers who are building their professional English skills, the subtleties of legal and regulatory terminology can be particularly challenging. It’s easy to fall into overly formal or jargon-heavy language that obscures understanding rather than clarifies it. The goal isn’t simply to state facts; it’s to build consensus and ensure everyone involved – from engineers to legal counsel – is on the same page regarding data handling practices. A key element of this is proactively addressing potential misunderstandings, particularly concerning phrases like “lawful basis” or “data subject rights.”

Let’s consider a scenario: During a code review, Sarah, a senior engineer, comments on a pull request submitted by David, a junior developer. David had implemented a new feature that involved collecting user email addresses for marketing purposes. Sarah’s comment reads: “This data collection needs to be fully compliant with GDPR. We absolutely must ensure we have documented consent and a legitimate interest.” While technically accurate, this phrasing could come across as overly prescriptive or even slightly intimidating to David, who is still developing his English skills. A more approachable alternative might be: “David, regarding the email address collection – let’s confirm we’ve clearly outlined how users can opt-out and that we have a solid justification for collecting this data based on our marketing strategy. Could you add a brief explanation of the ‘lawful basis’ we’re relying on?” This approach uses more accessible vocabulary (“justification,” “opt-out”) and frames the discussion as a collaborative effort to ensure best practices.

Another common situation is crafting PR descriptions for new features. Imagine you’re documenting an update to your user profile system, which now includes processing location data. A typical description might be: “The updated system adheres to all relevant GDPR stipulations regarding the handling of Personally Identifiable Information (PII).” Again, while technically correct, this could feel dense and inaccessible. Instead, try something like: “This release incorporates enhanced controls for managing user location data, ensuring we comply with GDPR’s requirements around data minimization and transparency. We’ve implemented a clear process for obtaining consent when collecting location information and provide users with options to update or delete their data.” This version focuses on the impact of the change – user control and data minimization – making it more immediately understandable.

Finally, remember that active listening is just as important as using precise language. When communicating with colleagues who may have varying levels of English proficiency, take time to check for understanding. Asking clarifying questions like “Could you explain what you mean by ‘data subject rights’ in this context?” or “Can you walk me through how this aligns with the GDPR principles?” demonstrates respect and fosters a more productive dialogue. It’s about building bridges of communication, not just delivering information.