Live 20 practitioner certifications live · First lesson free on every course Back to main site →

Definitions worth memorising: personal data, processing, controller, processor, pseudonymisation, third country, transfer

The definitions in Article 4 GDPR do more work than a reader expects. This lesson walks the eight definitions a practitioner uses every week, with the practitioner distinction each carries.

Free preview 8 min read Verified

Article 4 GDPR lists 26 definitions. A working practitioner reaches for maybe eight of them every week. Memorising these eight, in their operational meaning, saves you from the most common misreadings.

Personal data (Art 4(1))

Any information relating to an identified or identifiable natural person. Two elements: (a) it must be information about a natural person (not a legal person, not a machine), and (b) that person must be identified or identifiable. Identifiability is a wide test: identifiable directly (name, government ID) or indirectly (device fingerprint, cookie, browsing pattern, IP address, wallet address). CJEU IAB Europe (C-604/22) [L4-C1] confirmed that pseudonymous identifiers are personal data where re-identification is reasonably likely.

Processing (Art 4(2))

Any operation performed on personal data, whether or not by automated means, including collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure, alignment, restriction, erasure, or destruction. The word "processing" catches almost everything you can do to data. Storing a customer email in your CRM is processing. Reading it a year later is processing. Deleting it is processing.

Controller (Art 4(7))

The natural or legal person which, alone or jointly with others, determines the purposes and means of the processing. Determination is factual, not contractual. Whoever decides why the processing is happening and, at the essential level, how, is the controller. EDPB Guidelines 07/2020 is the operational reading.

Processor (Art 4(8))

A natural or legal person which processes personal data on behalf of the controller. A processor does not determine purposes; it acts on the controller\'s documented instructions. Most Indian IT services engagements make the Indian IT firm a processor of the EU client controller.

Pseudonymisation (Art 4(5))

The processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures. Pseudonymised data remains personal data (Recital 26); it is not anonymous. Practical use: pseudonymisation is a security measure and a transfer-risk mitigation, not an escape from GDPR.

Third country (implied through Chapter V)

A country outside the EEA (EU plus Iceland, Norway, Liechtenstein). India is a third country under GDPR. Transfers from EU to India require compliance with Chapter V (adequacy, or Article 46 mechanism, or Article 49 derogation).

Cross-border transfer (Chapter V)

The Regulation does not define "transfer" explicitly, but EDPB Guidelines 05/2021 on the interplay between the territorial scope and international transfers offer the three-cumulative-criterion test: (i) the exporter is a controller or processor subject to GDPR for the given processing; (ii) the exporter transmits or otherwise makes the personal data available to the importer; (iii) the importer is in a third country or is an international organisation. All three must be present for a Chapter V transfer analysis to apply. Note: an Indian entity accessing EU personal data from India (rather than the data being moved to India) can still trigger a Chapter V analysis if the exporter is EU-based and the importer (you) is in a third country.

Data subject (Art 4(1))

The identified or identifiable natural person to whom the personal data relates. In DPDP the equivalent term is Data Principal (Section 2). The rights held by a data subject under GDPR Chapter III largely map to the rights held by a Data Principal under DPDP Section 11-14, with the DPDP Section 13 nomination right having no direct GDPR counterpart.

The "Data Principal" definition in DPDP is slightly narrower than "data subject" in GDPR in that DPDP applies only to Data Principals within the territory of India, whereas GDPR applies to data subjects in the Union irrespective of nationality. An EU national in Chennai on a work assignment is a DPDP Data Principal for that period; an Indian national on holiday in Berlin is a GDPR data subject for that period; and a Bengaluru-resident EU passport holder is both simultaneously for the same processing.

Recipient (Art 4(9))

A natural or legal person to whom the personal data are disclosed, whether a third party or not. Includes processors, joint controllers, and any other party you disclose to. The Article 30 ROPA obligation requires you to list categories of recipients per processing activity. Recipients also matter for Article 13/14 transparency (you must inform the data subject of the categories of recipients) and for Article 19 (if you erase or rectify data at a data subject's request, you must communicate the change to each recipient unless the effort is disproportionate).

Special categories (Art 9)

Not in Article 4 but critical enough to memorise here. Article 9 lists nine special categories: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data processed to uniquely identify a natural person, health data, sex life, and sexual orientation. Processing of special categories is prohibited unless a Article 9(2) exception applies (explicit consent, employment law, vital interests, and eight others). DPDP does not carve out special categories the same way; instead it uses the concept of Data Principals whose data warrants stronger protection through the SDF-notification and Rule 12 mechanism. Practitioner action: run an Article 9 inventory across your ROPA and mark every processing activity that touches a special category; the Art 9(2) basis is the second lawful basis you must maintain alongside your Article 6 basis.

Why definitions matter

Almost every misreading of GDPR by a first-time practitioner starts with a definition confusion. Treating pseudonymous data as anonymous. Treating a controller-processor as a joint controller. Missing that Article 3(2) makes "third country" the wrong lens (because a non-EU processor is directly caught, not just receiving a transfer). Memorise Article 4 the way a securities lawyer memorises the SEBI Act definitions.

Anonymisation versus pseudonymisation: the 2026 EDPB draft position

On 7 July 2026 the EDPB adopted Draft Guidelines 02/2026 on Anonymisation and released them for public consultation, updating the 2014 WP29 Opinion 05/2014 that had been the operating standard for over a decade. The 2026 draft frames anonymisation around three cumulative tests derived from the 2014 Opinion but retuned for the AI era:

  1. Singling-out test: Can any individual record be isolated as belonging to one unique person from within the dataset?
  2. Linkability test: Can records relating to the same person be joined across the dataset or with an external dataset?
  3. Inference test: Can values of attributes for a person be inferred with meaningful probability from the dataset?

All three must be defeated for a dataset to be anonymous under the draft's reading. The draft also acknowledges "means reasonably likely to be used" as a proportionality anchor (aligning with Recital 26) and adds a "contextual controls" dimension where legal, organisational, and technical safeguards can reduce the practical re-identifiability of a dataset. For an Indian practitioner running an EU-facing analytics pipeline, the operational takeaway is: anonymisation claims for GDPR purposes must survive the singling-out plus linkability plus inference tests in the practical setting of your release; pseudonymisation is a lower bar and always leaves the data as personal data under GDPR. Alongside Draft Guidelines 02/2026 sits EDPB Guidelines 01/2025 on Pseudonymisation, adopted 16 January 2025 for consultation, which sets the operational rubric for when pseudonymisation counts as an appropriate safeguard.

Data Principal versus data subject: the DPDP alignment

The DPDP Act uses "Data Principal" where GDPR uses "data subject". The definitions are similar in effect but different in the rights bundle they carry. The DPDP Data Principal has the right to nomination (Section 13) that lets them nominate another individual to exercise their rights in the event of their death or incapacity; GDPR has no equivalent nomination right. GDPR's Article 22 automated-decision-making right has no direct DPDP counterpart, although Rule 12 for Significant Data Fiduciaries pulls a similar norm in through the algorithmic-fairness audit. For a dual-regime programme, treat the union of the two rights bundles as your operating floor: run a Data Principal Request procedure that also serves as a Data Subject Request procedure, cover nomination and Article 22 both.

GDPR definitions — the ones that matter in daily work
TermCore idea
Personal data Term Any info about an identified or identifiable natural person
Processing Term Any operation on personal data — collection to destruction
Controller Term Determines purposes + means — DPDP's Data Fiduciary analogue
Processor Term Processes on controller's behalf — DPDP's Data Processor analogue
Pseudonymisation Term Reversible with separate key — still personal data
Third country Term Outside EU/EEA — adequacy or SCCs required
Transfer Term Any way data leaves the EU/EEA — incl. remote access
Every claim in this lesson is cited. Yellow markers like [L1-C1] are clickable. Click any to see the verbatim text of the Section, Rule or judgment we're relying on. Learn how we verify content ›

Preview in progress 8 more modules waiting behind enrolment

Enjoying the preview? Here's what enrolment unlocks.

  • All 8 paid modules (30 lessons)
  • Complete citation register — every claim linked to the primary source
  • Final exam: 40 questions, unlimited retakes
  • Verifiable certificate with public verify URL and LinkedIn share
  • Lifetime access plus every future update
Inclusive of 18% GST. Certificate on pass. LinkedIn-shareable. Lifetime access. Course updates included.
Citations
CJEU Judgment, IAB Europe C-604/22 (IAB Europe (C-604/22, 7 March 2024)) L4-C1
CJEU judgment of 7 March 2024 in Case C-604/22 (IAB Europe v Belgian Data Protection Authority). Held that the Transparency and Consent Framework (TCF) Consent String, even in pseudonymous form, constitutes personal data where identifiability is reasonably likely. IAB Europe is a joint controller with adtech participants for the processing associated with the TCF signal, insofar as it influences purposes and means. Reshapes adtech: operators can no longer treat TCF strings as anonymous. Practical impact for Indian adtech vendors serving EU users: TCF integration alone does not launder legal-basis analysis.
Free preview
Reading Module 1. Enrol to unlock the rest of the course.
Module 1: Foundations: why GDPR reaches you as an Indian practitioner
Module 2: Lawful basis and consent
  • The six Article 6 lawful bases and why consent is overused
  • Legitimate interests: the three-part test (Guidelines 1/2024)
  • Article 7 consent standards and Guidelines 05/2020
  • Article 9 special categories and the ten Art 9(2) gateways
Module 3: Data subject rights end-to-end
  • The rights inventory and the one-month response clock
  • Article 15 access requests: the practitioner playbook
  • Article 17 erasure: six triggers, ten exceptions
  • Articles 20, 21, 22: portability, objection, automated decisions
Module 4: Controller vs processor, contracts, subprocessing
  • Determining the role: factually, not contractually
  • Article 28 processor contract: the eight mandatory clauses
  • Joint controllership under Article 26 and the transparency obligation
  • Article 30 records of processing: what an Indian processor's ROPA must show
Module 5: DPO office, DPIA, records of processing
  • Article 37 DPO trigger: when a DPO must be appointed
  • Articles 38-39: DPO independence, resources, tasks
  • Article 35 DPIA: when and how
  • One DPO office serving GDPR and DPDP in parallel
Module 6: Breach notification and the triple clock
  • Article 33: when the 72-hour clock actually starts
  • Article 34 data-subject notification: the high-risk test
  • The triple clock: CERT-In 6h, DPDP 72h, GDPR 72h
  • Worked scenario: ransomware at an Indian SaaS with EU customers
Module 7: Cross-border transfers: SCCs, adequacy, DPF, Transfer Impact Assessment
  • Chapter V architecture: adequacy, Article 46, Article 49 derogations
  • Commission SCCs 2021/914: four modules walkthrough
  • Schrems II TIA obligation: the practitioner working reference
  • EU-US Data Privacy Framework: read as fragile additional layer
  • DPDP Section 16 + Rule 15: the negative-list mirror
Module 8: Adjacent EU instruments + enforcement pattern + capstone
  • DSA, DMA, Data Act, AI Act, NIS2: what reaches an Indian entity
  • Top-15 GDPR fines 2018-2026: practitioner lessons
  • Reading the 2024-2026 enforcement pattern
  • AI Act plus GDPR for Indian AI providers: DPIA plus FRIA overlap
  • Capstone: dual-regime compliance programme for an Indian IT services firm
Module 9: Final Exam and Certificate