GDPR is built on a precisely defined vocabulary. The terms it uses — personal data, processing, controller, processor, consent — carry specific legal meanings that differ, sometimes significantly, from how those words are used in ordinary language. Getting these definitions right is not a pedantic exercise. The definitions in Article 4 determine whether GDPR applies to a given activity, who bears the legal obligations for that activity, and what those obligations are.
This article works through the most important Article 4 definitions systematically, providing the legal text alongside the practical interpretation that determines how each term operates in real compliance programmes. It also addresses a set of adjacent concepts — special categories, data subjects, third parties, supervisory authorities — that are defined elsewhere in GDPR but are equally foundational.
Personal Data: Broader Than Most Organisations Assume
Personal data is defined in Article 4(1) as ‘any information relating to an identified or identifiable natural person (‘data subject’)’. An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person.
Three elements of this definition require particular attention. First, the ‘relating to’ standard is broad. Data relates to a person if it is about that person, has them as its focus, or can be used to evaluate, influence, or make decisions about them. A product review relates to the reviewer. A vehicle registration record relates to the registered keeper. Employee performance data relates to the employee.
Second, the identifiability test applies to the data held by any party who could reasonably be used to identify the individual — not just the party processing the data. If an organisation holds an IP address and could identify the individual by combining it with data held by an internet service provider, that IP address is personal data even if the organisation itself cannot make the identification without external assistance.
Third, the definition applies only to natural persons — living human beings. Data about deceased individuals is not personal data under GDPR (though some member states extend protection to deceased persons under national law). Data about legal entities — companies, organisations — is not personal data. However, data about individuals in a business context, such as a named employee or business contact, is personal data even if it relates primarily to their professional role.
| KEY IDEA | Organisations frequently underestimate the scope of personal data they hold. IP addresses, device identifiers, location data, cookie values, purchase histories, and combinations of non-obvious data points all constitute personal data if they can be linked to an individual. The test is identifiability, not obvious identification. |
Processing: Every Operation on Personal Data
Processing is defined in Article 4(2) as ‘any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction’.
This definition is deliberately exhaustive. Every point in the data lifecycle constitutes processing: collecting data, storing it, using it, sharing it, modifying it, deleting it. Simply holding personal data — storing it on a server without actively using it — is processing. Transferring data to a third party is processing. Analysing data for insights is processing. Running an automated algorithm across personal data is processing. The only activity that is not processing is having no interaction with personal data at all.
The practical consequence is that GDPR applies to virtually every activity that involves personal data in any form. An organisation cannot escape GDPR obligations by arguing that it is ‘just storing’ data, or that it ‘doesn’t use’ the data it holds. If personal data passes through its systems, GDPR applies.
Controller: Who Determines the Purpose and Means
The controller is defined in Article 4(7) as ‘the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data’.
The controller is the entity that decides why personal data is being processed and how. Purpose and means are the two decisive criteria. An organisation that decides to collect customer email addresses for marketing purposes is a controller for that processing. An organisation that decides to run a HR system that processes employee records is a controller for that processing. The controller bears the primary legal obligations under GDPR: it must establish a lawful basis, implement the data protection principles, respond to data subject rights, ensure security, and be able to demonstrate compliance.
The means element is qualified: determining the essential means — what data to collect, which individuals to process, how long to retain it, who to share it with — is the decisive factor. Choosing among available technical implementation options (which database vendor to use, which encryption algorithm to deploy) is not a means determination that creates controller status.
| IMPORTANT | Controller status cannot be contracted away. An organisation that determines the purpose and means of processing is a controller regardless of how it describes itself in contractual documentation. A data processing agreement cannot make a controller into a processor if the organisation’s actual conduct meets the controller definition. |
Processor: Who Acts on the Controller’s Instructions
The processor is defined in Article 4(8) as ‘a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller’. A processor acts exclusively on the controller’s documented instructions. It does not determine the purpose of the processing — that is fixed by the controller — and it may only determine the means of processing within the parameters set by the controller.
Classic processor relationships include: a payroll bureau that processes employee data on behalf of an employer; a cloud hosting provider that stores personal data on behalf of a customer organisation; a marketing analytics platform that processes customer data according to a client’s configuration; a customer support tool that handles personal data according to the deploying company’s instructions.
A processor that begins making its own decisions about the purpose or essential means of processing — that processes data for its own purposes, or in ways the controller has not authorised — becomes a controller for that additional processing and takes on full controller obligations for it. This is a common compliance risk in complex SaaS relationships where the platform uses client data for its own analytics, model training, or product improvement purposes.
Processors carry direct GDPR obligations that did not exist under the 1995 Directive. Article 28 requires controllers to use only processors that provide sufficient guarantees, implemented in a written contract (the Data Processing Agreement). Processors must implement appropriate security measures, maintain records of processing activities carried out on behalf of controllers, cooperate with supervisory authorities, notify controllers of breaches, delete or return personal data at the end of the relationship, and not engage sub-processors without the controller’s authorisation.
Joint Controllers: Shared Determination of Purpose
Joint controllers are defined in Article 26 as two or more controllers that jointly determine the purposes and means of processing. The key test is whether the processing activity in question cannot be attributed to a single controller — whether two or more parties are genuinely co-determining the purpose and means.
Joint controllership is common in digital advertising ecosystems, where a website operator and an advertising platform may jointly determine how user data is collected and used for targeting. The Court of Justice of the EU has found joint controllership in contexts where organisations that embed third-party tools — Like buttons, analytics pixels, integrated login — may jointly determine the processing with the tool provider.
Joint controllers must enter into an arrangement that determines their respective responsibilities for complying with GDPR obligations, particularly around transparency with data subjects. Both joint controllers bear accountability to the supervisory authority, but the arrangement can allocate operational responsibility between them.
Consent: Seven Conditions, All Mandatory
Consent is defined in Article 4(11) as ‘any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her’.
Each element of this definition carries operational weight. Freely given means the individual must have a genuine choice — consent is not valid if refusing it has negative consequences for the individual, or if consent is bundled with other conditions in a way that removes meaningful choice. A job applicant cannot meaningfully withhold consent from an employer’s processing of their application data — the power imbalance invalidates the consent as a lawful basis for the processing.
Specific means consent must be given separately for each distinct processing purpose. Blanket consent covering multiple unrelated processing activities is not valid GDPR consent. An organisation that processes personal data for marketing, analytics, and personalisation on the basis of consent must obtain separate consent for each purpose.
Informed means the individual must understand what they are consenting to — the identity of the controller, the purpose of the processing, and the right to withdraw consent. Pre-ticked boxes, silence, and inactivity do not constitute valid consent. A clear affirmative action is required — something the individual does deliberately to indicate agreement.
Consent must be demonstrable: Article 7(1) requires controllers to be able to demonstrate that the data subject has consented. A consent record — capturing when, how, and to what the individual consented — is not optional. And consent can be withdrawn at any time, as easily as it was given. Processing on the basis of consent must stop when consent is withdrawn, though this does not affect the lawfulness of processing that occurred before withdrawal.
| KEY IDEA | Consent is often the wrong lawful basis. It is appropriate when an organisation genuinely gives individuals a free and meaningful choice about processing that is not otherwise justified. For processing that is necessary for a contract, required by law, or conducted in the organisation’s legitimate interests, consent is not only unnecessary but counterproductive — it creates withdrawal rights that can disrupt legitimate processing. |
Pseudonymisation and Anonymisation: A Critical Distinction
Pseudonymisation is defined in Article 4(5) as ‘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 to ensure that the personal data are not attributed to an identified or identifiable natural person’.
Pseudonymised data is still personal data. GDPR applies to it. The distinction matters because pseudonymisation reduces the risk associated with processing — it is treated as a risk-reducing technical measure rather than a mechanism for removing GDPR applicability. Organisations that pseudonymise data may be able to satisfy certain security requirements more readily, but they cannot treat pseudonymised data as outside GDPR’s scope.
Anonymisation, by contrast, renders GDPR inapplicable — but only if it is genuine and irreversible. The EDPB and its predecessor the Article 29 Working Party have set a high standard: data is truly anonymous only if no reasonably likely means could re-identify the individuals. Given modern re-identification techniques and the availability of large auxiliary datasets, genuine anonymisation is technically demanding and rarely as complete as organisations assume. Many datasets described as ‘anonymised’ in practice retain re-identification risk and therefore remain personal data subject to GDPR.
Special Categories of Personal Data
Article 9 defines special categories of personal data as personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or a natural person’s sex life or sexual orientation. These categories attract heightened protection because of the particular sensitivity of the information and the discrimination, harm, or stigma that exposure could cause.
Processing special category data is prohibited under Article 9(1) unless one of the specific conditions in Article 9(2) applies. These conditions are more demanding than the standard lawful bases in Article 6. Explicit consent — a higher standard than ordinary consent — is one condition. Employment and social security law is another. Vital interests of the data subject when they cannot consent. Legitimate activities of not-for-profit bodies. Data that the subject has manifestly made public. Legal claims. Substantial public interest. Healthcare and social care purposes. Public health. Archiving, research, and statistical purposes.
For most commercial organisations, special category data triggers not only the Article 9 conditions but also a mandatory Data Protection Impact Assessment under Article 35 and heightened security requirements. The processing of health data, biometric data, or genetic data requires explicit additional justification regardless of the general lawful basis under Article 6.
Data Subject, Third Party, and Recipient
The data subject is defined in Article 4(1) as the identified or identifiable natural person to whom personal data relates. The data subject is the individual whose rights GDPR protects — the customer, employee, website visitor, or any other person about whom data is processed. Data subjects must be natural persons; organisations do not have GDPR rights.
A third party is defined in Article 4(10) as a natural or legal person, public authority, agency, or body other than the data subject, controller, processor, and persons who, under the direct authority of the controller or processor, are authorised to process personal data. In practical terms, a third party is any entity that receives or accesses personal data that is not part of the existing controller-processor relationship. Sharing personal data with a third party requires justification and, where the third party becomes a controller, triggers additional obligations.
A recipient is defined in Article 4(9) as any natural or legal person, public authority, agency, or body to which personal data is disclosed. Recipients include both processors (who receive data under a DPA and act on the controller’s instructions) and independent controllers (who receive data to process for their own purposes). The distinction matters because the obligations flowing from disclosure differ significantly depending on whether the recipient is a processor or an independent controller.
Supervisory Authority and the One-Stop-Shop
A supervisory authority (SA) is defined in Article 4(21) as an independent public authority established by a member state to be responsible for monitoring the application of GDPR. Each EU member state has at least one DPA. In countries with a federal structure (Germany, Belgium), there may be multiple DPAs with jurisdiction over different levels of government and different sectors.
The lead supervisory authority concept — the one-stop-shop mechanism — applies to controllers and processors with establishments in multiple EU member states. The lead SA is the DPA in the member state where the controller’s main establishment is located — typically where the organisation’s EU headquarters or central administration is based. For cross-border processing, the lead SA coordinates with ‘concerned’ SAs in other member states through the cooperation mechanism. For non-EU organisations with an Article 27 representative, the SA in the member state where the representative is located may take on the coordinating role in practice.
Profiling and Automated Decision-Making
Profiling is defined in Article 4(4) as any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location, or movements.
Profiling is a form of processing and requires a lawful basis like any other processing activity. Where profiling is combined with solely automated decision-making that produces legal or similarly significant effects on individuals, Article 22 applies additional restrictions. Individuals have the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects concerning them — unless specific conditions are met. This provision has significant implications for credit scoring, insurance pricing, recruitment screening, and other automated decision contexts.
Genetic and Biometric Data
Genetic data is defined in Article 4(13) as personal data relating to the inherited or acquired genetic characteristics of a natural person which give unique information about the physiology or the health of that natural person and which result, in particular, from an analysis of a biological sample from the natural person in question.
Biometric data is defined in Article 4(14) as personal data resulting from specific technical processing relating to the physical, physiological, or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic (fingerprint) data. Critically, biometric data only falls within the Article 9 special category regime when it is processed for the purpose of uniquely identifying a natural person. A standard photograph is biometric data in the general sense, but it becomes special category data under GDPR only when processed through facial recognition or similar technology for identification purposes.
Data Concerning Health
Data concerning health is defined in Article 4(15) as personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status. This definition is broad and has been interpreted expansively. It includes not only clinical records and diagnoses, but data from health monitoring devices, pharmacy purchase records, insurance claims data, absence records that reveal a health condition, and any data from which health information can be inferred. Organisations that handle data with health implications — even tangentially — should assess whether Article 9 applies.
Practical Application: Using Definitions to Map Obligations
The Article 4 definitions are not merely academic. They are the analytical tools used to map GDPR obligations onto real processing activities. When assessing a new data processing activity, the definitional questions form the first layer of analysis: Is the data personal data? Is the activity processing? What is the role of our organisation — controller, processor, or joint controller? Are special categories involved? Does it involve profiling or automated decision-making?
The answers to these questions determine which provisions of GDPR apply, what documentation is required, which rights data subjects hold, what security standards must be met, and whether a DPIA is mandatory. Getting the definitions wrong at this stage — assuming data is anonymised when it is merely pseudonymised, treating a processing relationship as processor when the organisation is actually a joint controller — creates structural compliance failures that cascade through the entire programme.
| BITLION INSIGHT | The most common definitional failure in GDPR compliance is misclassifying the controller/processor relationship in complex vendor and SaaS contexts. An organisation that assumes it is a processor because it ‘just provides infrastructure’ may in practice be making decisions about processing purposes or means that make it a controller or joint controller. Role classification should be reviewed whenever the nature of a processing relationship changes. |
The subsequent articles in Section 1 build directly on these definitional foundations. Article 1.3 applies the territorial scope definitions to determine which non-EU organisations are subject to GDPR. Article 1.4 examines the six lawful bases, each of which has specific conditions tied to the definitions of consent, legitimate interests, and contract. Articles 1.5 and 1.6 address the rights of data subjects and the obligations of controllers, processors, and joint controllers — all of which follow from the definitional framework established here.