GDPR glossary
for engineering teams.
GDPR defines 26 terms. This page focuses on the ones that most often change system design, workflow ownership, vendor posture, and audit evidence. The legal source remains the Regulation itself; this is the engineering-facing read.
This is a curated working glossary, not an exhaustive legal mirror.
The graph tells us GDPR defines 26 terms. For landing-page work, the useful move is not to publish 26 almost-identical term stubs. It is to surface the definitions that most often alter architecture, contracts, permissions, data flows, and user-facing workflows.
Selected terms
- 01
Personal data
Any information relating to an identified or identifiable natural person.
Why Engineers Should CareThis is the trigger term. If a system handles information that can identify someone directly or indirectly, GDPR design questions start immediately.
Implementation ConsequenceClassification needs to extend beyond obvious profile fields into logs, support notes, identifiers, telemetry, analytics events, and derived data.
- 02
Processing
Any operation performed on personal data, whether automated or not, such as collection, storage, use, disclosure, combination, or deletion.
Why Engineers Should CareGDPR attaches to more than databases. Collection, transformation, export, enrichment, inference, backup, and deletion are all processing events.
Implementation ConsequenceData-flow mapping must cover the full lifecycle of data through queues, jobs, warehouses, support tools, and vendors.
- 03
Controller
The person or organisation that determines the purposes and means of processing personal data.
Why Engineers Should CareController posture drives who owns lawful basis, transparency, rights handling, retention choices, and many accountability duties.
Implementation ConsequenceThe team needs explicit ownership over why data is collected and which product or workflow decisions change that purpose.
- 04
Processor
The person or organisation that processes personal data on behalf of a controller.
Why Engineers Should CareMany SaaS vendors operate as processors for customer data, which changes the contract surface, instruction handling, and escalation expectations.
Implementation ConsequenceEngineering and vendor workflows need to support controller instructions, Article 28 terms, security evidence, and breach escalation paths.
- 05
Recipient
A person, authority, agency, or other body to which personal data is disclosed, whether or not that party is a third party.
Why Engineers Should CareRecipient logic shapes disclosures, vendor lists, support tooling visibility, and transfer analysis.
Implementation ConsequenceTeams need a reliable way to know where personal data is sent across internal systems, processors, subprocessors, and customer-facing integrations.
- 06
Third party
A person or body other than the data subject, controller, processor, or people authorised to process data under their direct authority.
Why Engineers Should CareThis term decides when a disclosure crosses a governance boundary instead of staying within the operational boundary of the controller or processor.
Implementation ConsequenceAccess models and vendor reviews must distinguish internal authorised access from disclosures to external parties.
- 07
Consent
A freely given, specific, informed, and unambiguous indication of the data subject’s wishes by which they signify agreement to processing.
Why Engineers Should CareWhen a product relies on consent, the bar is operational, not rhetorical: the team must prove how consent was captured, scoped, withdrawn, and honoured.
Implementation ConsequenceConsent states need versioning, timestamps, purpose scoping, and withdrawal logic that actually stops the downstream processing they authorised.
- 08
Special categories of personal data
Sensitive categories such as data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data used for identification, health data, or data concerning sex life or sexual orientation.
Why Engineers Should CareThis is one of the fastest ways the compliance burden escalates. Security, access, DPIA posture, and legal basis analysis change quickly once these categories are involved.
Implementation ConsequenceData models, classifiers, permissions, and workflow routing should flag these categories early instead of treating them like ordinary profile fields.
- 09
Personal data breach
A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
Why Engineers Should CareGDPR breach posture is about more than intrusion. Availability failures, misrouting, accidental disclosure, and integrity failures all count.
Implementation ConsequenceIncident workflows need classification logic, escalation, recipient tracking, and time-aware evidence to support 72-hour response duties.
- 10
Profiling
Automated processing of personal data used to evaluate personal aspects of a natural person, especially to analyse or predict behaviour, preferences, health, reliability, location, or movements.
Why Engineers Should CareAnalytics, recommender systems, risk scoring, fraud models, and AI systems can cross into profiling long before teams label them that way.
Implementation ConsequenceProduct owners need visibility into inference pipelines, feature use, model outputs, and user-impact decisions that may trigger transparency or objection duties.
- 11
Pseudonymisation
Processing personal data so it can no longer be attributed to a specific person without additional information kept separately and protected.
Why Engineers Should CareTeams often overclaim on anonymisation when they really mean pseudonymisation. GDPR treats that difference seriously.
Implementation ConsequenceKey stores, lookup tables, re-identification boundaries, and access controls around reversal data need to be clearly separated and auditable.
- 12
Biometric data
Personal data resulting from specific technical processing of physical, physiological, or behavioural characteristics that allow or confirm the unique identification of a person.
Why Engineers Should CareFace, voice, fingerprint, gait, and similar signals raise both sensitive-data and model-governance questions quickly.
Implementation ConsequenceBiometric pipelines should be explicitly classified, access-limited, and reviewed for whether the identification use case changes the legal basis and security posture.
- 13
Representative
A natural or legal person established in the EU designated in writing to act on behalf of a controller or processor under Article 27.
Why Engineers Should CareNon-EU companies often discover this term late, after territorial scope has already pulled them into the Regulation.
Implementation ConsequenceGo-to-market and compliance workflows need to surface Article 27 edge cases before enterprise procurement or supervisory contact makes them urgent.
- 14
Restriction of processing
The marking of stored personal data with the aim of limiting how it is processed in the future.
Why Engineers Should CareRestriction is often missed because teams can export and delete, but cannot reliably hold a record in a constrained state across systems.
Implementation ConsequenceApplications need durable status controls that pause downstream use, sync that state across replicas and vendors, and preserve evidence of when the restriction took effect.
Then route into scope and implementation.
Use the terms to route into the real work.
The glossary is the shared vocabulary layer. From there, move into applicability, engineering checklists, and the RuleMesh product surfaces that execute the obligations.