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:
- Singling-out test: Can any individual record be isolated as belonging to one unique person from within the dataset?
- Linkability test: Can records relating to the same person be joined across the dataset or with an external dataset?
- 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.
| Term | Core 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 |