European Union — Scope & Applicability

Article 3 GDPR defines when the regulation applies, using two distinct grounds: the establishment clause (Art. 3(1)) and the targeting clause (Art. 3(2)). These rules determine GDPR applicability for both EU-established and non-EU controllers and processors, creating one of the most expansive extraterritorial data-protection regimes in force.

## Article 3(1): Establishment clause

The GDPR applies to "the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not." This clause turns on the existence of an EU establishment, not the location of the processing itself. A US parent company processing EU-resident data on US servers is subject to GDPR if the processing occurs "in the context of" its French subsidiary's activities, even if the subsidiary never touches the data. The CJEU has interpreted "establishment" broadly in the data-protection context — a single representative office or branch with real economic activity suffices, and the processing need only be "inextricably linked" to the establishment's activities.

The regulation covers both controllers (entities determining purposes and means of processing, Art. 4(7)) and processors (entities processing on behalf of a controller, Art. 4(8)). If either the controller or the processor has an EU establishment in connection with the processing, Art. 3(1) applies. EU establishments of non-EU parent organizations trigger full GDPR compliance for the parent's processing activities when conducted in the context of the EU establishment.

## Article 3(2): Targeting clause (extraterritorial reach)

The GDPR applies to processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:

(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or

(b) the monitoring of their behaviour as far as their behaviour takes place within the Union.

This is the cross-border reach provision. A controller with no EU presence falls within GDPR scope if it targets EU residents through either offering or monitoring.

"Offering of goods or services" requires an intention to offer to EU data subjects. Recital 23 clarifies that "mere accessibility" of a website, email address, or use of a language common in the controller's home country is insufficient. Evidence of intent includes: use of a language or currency used in one or more EU Member States with the possibility of ordering in that language, mention of EU customers or users, or payment in EU currencies. The offering need not be paid; free services (ad-supported platforms, apps) trigger Art. 3(2)(a) if directed at EU users.

"Monitoring of behaviour" covers tracking individuals on the internet, including profiling to analyze or predict personal preferences, behaviors, and attitudes (Recital 24). Behavioral advertising, location tracking, and analytics involving EU-resident data when the individual is physically in the Union at the time of data collection all constitute monitoring. The behaviour must take place within the Union — tracking an EU citizen while traveling outside the EU does not trigger Art. 3(2)(b).

## Article 3(3): Representative requirement

Where Art. 3(2) applies, the controller or processor must designate in writing a representative in the Union (Art. 27(1)). The representative must be established in one of the Member States where the data subjects whose data are processed are located. Small exceptions apply (public authorities, occasional processing that does not include large-scale special-category data and is unlikely to result in risk to rights and freedoms). The representative acts as the point of contact for supervisory authorities and data subjects on all GDPR compliance matters.

## Practical consequence

A non-EU SaaS provider with no EU office but offering services to EU-resident customers (even if only 5% of its user base) must comply with the entirety of GDPR — lawful bases (Art. 6), data-subject rights (Arts. 12–23), breach notification (Arts. 33–34), DPO appointment if thresholds met (Art. 37), records of processing activities (Art. 30), and full enforcement exposure including Art. 83 administrative fines up to €20 million or 4% of global annual turnover, whichever is higher. The extended territorial scope, confirmed in CJEU Schrems II (Case C-311/18) and reflected in enforcement actions by the EDPB and national supervisory authorities, means GDPR obligations attach based on target market, not corporate domicile.

Cross-border businesses evaluating GDPR applicability start with Art. 3. If either prong applies, full compliance is mandatory, and the one-stop-shop mechanism under Art. 56 (lead supervisory authority for cross-border processing) governs enforcement coordination among EU data protection authorities.

Source: Regulation (EU) 2016/679 (GDPR), Articles 3, 4(7)–(8), 27

Article 2 GDPR defines the material scope of the regulation — which types of processing operations fall within GDPR and which are expressly excluded. While Article 3 determines when GDPR applies geographically (establishment and targeting), Article 2 determines what processing it governs and what is carved out by law. Together, these provisions form the threshold applicability analysis every controller and processor must perform.

## Article 2(1): Positive scope — automated and structured manual processing

The GDPR applies to "the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system."

Automated processing covers any use of IT systems — databases, cloud platforms, email servers, CRM systems, cookies, mobile apps, algorithmic decision-making. The threshold is low: if a computer touches the personal data at any stage, Art. 2(1) applies. Recital 15 confirms that manual files organized by criteria relating to individuals (searchable employee files sorted alphabetically, patient records indexed by name or ID number) also fall within scope when structured as a filing system, ensuring consistent treatment regardless of processing method.

Filing system is defined in Art. 4(6) as "any structured set of personal data which are accessible according to specific criteria, whether centralized, decentralized or dispersed on a functional or geographical basis." A paper-based HR file cabinet indexed by employee surname, or a document management system tagged by customer ID, both qualify. Unstructured or ad-hoc collections — miscellaneous notes in a drawer, un-indexed emails — may fall outside if not organized to permit retrieval by individual-related criteria, though the line is often thin in practice.

## Article 2(2): Statutory exclusions — four categories outside GDPR scope

The GDPR does not apply to processing of personal data:

(a) "in the course of an activity which falls outside the scope of Union law" — This clarifies jurisdictional boundaries rather than creating a substantive exemption. The phrase is not particularly helpful on its face. In practice, it has very limited impact: almost any commercial or administrative activity involving data flows across borders or affecting the internal market falls within Union competence. Activities genuinely outside Union law are rare (certain purely domestic matters with no cross-border dimension, activities of international organizations governed by their own immunities). The provision confirms the EU does not overstep its constitutional limits but does not create a broad carve-out.

(b) "by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU" — This exempts Member State processing in the context of the Common Foreign and Security Policy (CFSP), which remains an intergovernmental competence under the Treaties. National foreign-policy and defense activities under CFSP are outside GDPR scope; ordinary public-administration processing by Member State authorities (tax, health, education, public registries) remains fully within GDPR.

(c) "by a natural person in the course of a purely personal or household activity" — The household exemption removes individual, non-professional data processing from GDPR obligations. Recital 18 elaborates: "This Regulation does not apply to the processing of personal data by a natural person in the course of a purely personal or household activity and thus with no connection to a professional or commercial activity. Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities."

The CJEU has interpreted this exemption narrowly. In Lindqvist (C-101/01), the Court held that publishing personal data (including health data) about colleagues on a publicly accessible website could not be considered a purely household activity, because the data were "made accessible to an indefinite number of people" on the internet. The exemption applies only to activities "carried out in the course of private or family life of individuals," and the regulation refers to "purely personal or household" activity — not merely activity with some personal element.

In Ryneš (C-212/13), the CJEU ruled that operating a home video surveillance camera that captured even a partial view of a public space (street, neighboring property) fell outside the household exemption, because the processing was "directed outwards from the private setting" and thus not purely domestic. The household exception must be narrowly construed to preserve the regulation's fundamental-rights protection (Recital 4, Art. 1(2)).

Consequence for practitioners: A natural person maintaining a private contacts list, sending family photos to relatives via email, or posting to a small closed social-media group limited to close friends may qualify. An individual running a side business from home, maintaining a blog read by the public, operating a publicly accessible Ring doorbell that captures the sidewalk, or reselling products via a personal e-commerce account does not qualify — the processing has a professional, commercial, or outward-facing dimension that takes it beyond "purely" household use. Legal entities (companies, NGOs, foundations, even informal associations) cannot invoke the household exemption at all; it applies only to natural persons acting in a genuinely private capacity.

(d) "by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security" — Processing by police, prosecutors, criminal courts, prison authorities, and national-security agencies for law-enforcement purposes is excluded from GDPR and instead governed by Directive (EU) 2016/680 (the Law Enforcement Directive), which establishes a parallel data-protection framework tailored to the constraints of criminal justice. This carve-out is purpose-specific: a police department processing employee payroll or handling civilian complaints about officer conduct remains subject to GDPR; only processing for criminal-law-enforcement objectives is excluded. Similarly, administrative agencies (tax authorities, labor inspectorates, competition authorities) that process data for regulatory enforcement but not criminal prosecution remain within GDPR scope.

## Article 2(3)–(4): Regulation of EU institutions and e-Commerce Directive

Article 2(3) notes that processing by EU institutions, bodies, offices, and agencies was at the time of GDPR adoption governed by Regulation (EC) No 45/2001, which has since been replaced by Regulation (EU) 2018/1725 aligning the institutional data-protection regime with GDPR principles.

Article 2(4) confirms that GDPR is "without prejudice" to Directive 2000/31/EC (the e-Commerce Directive), preserving its liability safe harbors for intermediary service providers under Articles 12–15 (mere conduit, caching, hosting). A hosting provider is not liable for user-uploaded content solely by virtue of storing it, even if that content includes personal data, provided it meets the conditions of the e-Commerce Directive; this is compatible with — and unaffected by — the GDPR's controller/processor obligations.

## Practical takeaway

An applicability analysis begins with two questions: (1) Does Article 3 apply (establishment or targeting)? If yes, (2) does Article 2(2) exclude the processing? If both answers favor applicability, all GDPR obligations attach — lawful bases (Art. 6), transparency (Arts. 12–14), data-subject rights (Arts. 15–22), security (Art. 32), breach notification (Arts. 33–34), records of processing (Art. 30), and DPIA when thresholds met (Art. 35). There is no partial compliance. The exclusions are statutory and narrow; when in doubt, GDPR applies.

Source: Regulation (EU) 2016/679 (GDPR), Articles 2, 4(6), Recitals 15, 18 Source: CJEU, Bodil Lindqvist, Case C-101/01, Judgment of 6 November 2003 Source: CJEU, Ryneš, Case C-212/13, Judgment of 11 December 2014

Article 4(7) and (8) GDPR define the two core roles in the data-protection framework: the controller and the processor. These are functional concepts that allocate responsibility according to who actually makes decisions about processing, not what a contract labels the parties. The distinction is foundational — it determines which obligations attach, whether a data processing agreement (Art. 28) is mandatory, whether a DPO appointment is required (Art. 37), and the entity's exposure to administrative fines under Art. 83. The CJEU and EDPB have interpreted both concepts broadly, particularly joint controllership, to ensure effective protection for data subjects.

## Article 4(7): Controller — determines purposes and means

A controller is "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 test has two prongs: why (purpose) and how (means). An entity that decides both is a controller.

Purposes — the objective or outcome for which personal data are processed. A marketing agency that decides to build a customer profile database for targeted advertising determines the purpose (profiling for marketing), even if a client later accesses the profiles. An employer that collects employee time-clock data to calculate wages and comply with labor law determines the purpose (payroll and legal compliance).

Means — the method and mechanics of processing. The EDPB distinguishes essential means (which data to collect, how long to retain it, who has access, whether to use profiling algorithms) from non-essential means (choice of server vendor, specific database software, backup schedules). A controller determines essential means. A processor may choose non-essential means within the controller's instructions, but the moment a processor decides which categories of data to collect, which data subjects to target, or how long to retain data, it crosses into controllership (Guidelines 07/2020, paras. 36–40).

The definition applies to any legal form: natural persons, companies, public authorities, NGOs, trade associations. In practice, it is usually the organization as such, not an individual employee or board member, that acts as controller (EDPB Guidelines 07/2020, para. 20). Importantly, a controller need not have access to the personal data itself to be classified as a controller — the CJEU confirmed in Wirtschaftsakademie Schleswig-Holstein (Case C-210/16, judgment of 5 June 2018) that the administrator of a Facebook fan page was a joint controller with Facebook even though the administrator received only anonymized statistical insights, never the underlying personal data of page visitors (paras. 35–39). The administrator influenced the data collection by defining parameters for the fan page and benefited from the processing, satisfying the functional test.

## Article 4(8): Processor — processes on behalf of the controller

A processor is "a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller." Two conditions must be met: (1) the processor is a separate entity from the controller, and (2) it processes only according to the controller's instructions (Art. 28(3)(a)).

The processor has no independent purpose for the processing — it acts as a service provider executing the controller's decisions. Classic examples: a cloud-hosting provider storing customer data that the controller uploads; a payroll bureau calculating wages based on employee hours the controller provides; an email service provider sending marketing campaigns the controller drafts.

The EDPB recognizes that processors retain some margin of discretion in how to implement instructions — choosing technical infrastructure, selecting sub-processors (subject to controller authorization under Art. 28(2)), determining internal access controls. This operational discretion does not make the processor a controller, provided it does not determine the essential means or the purpose (Guidelines 07/2020, paras. 76–78). But if the processor decides to retain data longer than instructed, or to process it for its own analytics, it becomes a controller for that additional processing and violates Art. 28(10) (which prohibits a processor from engaging another processor without the controller's authorization).

A processor that exceeds its instructions — for example, a marketing platform that uses client customer data to train its own recommendation engine — ceases to be a mere processor for that use and assumes controller liability, including exposure to Art. 83(5) fines up to €20 million or 4% of global annual turnover.

## Joint controllers under Article 26

Where two or more entities jointly determine the purposes and means of processing, they are joint controllers under Art. 26 GDPR. Joint controllership arises when participation in the decision-making is inextricably linked — the processing would not be possible without both parties' involvement. The CJEU has construed this broadly.

In Wirtschaftsakademie, the Court held that operating a Facebook fan page to promote educational services made Wirtschaftsakademie a joint controller with Facebook for the processing of visitor data via Facebook Insights, because (1) by creating the fan page, Wirtschaftsakademie enabled Facebook to collect data, and (2) Wirtschaftsakademie defined parameters (age, location, interests) for the analytics and benefited from the insights (para. 35). The joint participation need not be equal in scope or technical capability; it is sufficient that each entity contributes to the determination of purposes or means (para. 43: "joint responsibility does not necessarily imply equal responsibility").

In Fashion ID (Case C-40/17, judgment of 29 July 2019), the CJEU found that embedding a Facebook "Like" button on a website made the website operator a joint controller with Facebook for the collection and transmission of visitor data to Facebook, because the operator "made it possible" for Facebook to collect the data and received commercial benefit (increased visibility on the social network). Critically, the joint controllership was limited in scope to the initial data collection and disclosure; Fashion ID was not a controller for Facebook's subsequent processing (advertising targeting, profile building) over which it had no influence (paras. 70–74).

Article 26(1) requires joint controllers to determine their respective responsibilities in a transparent arrangement, the essence of which must be made available to data subjects (Art. 26(2)). The arrangement should allocate specific tasks: who handles data-subject rights requests (Art. 15–22), who conducts the DPIA (Art. 35), who notifies breaches (Art. 33), who appoints the DPO (Art. 37). Even if one controller is designated as the primary point of contact, data subjects may exercise their rights against each joint controller (Art. 26(3)), and each controller remains liable for compliance with the GDPR.

## Law-designated controllers

The second sentence of Art. 4(7) provides that "where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law." When a statute imposes a duty to collect and process data — for example, national law requiring employers to report employee wages to a tax authority, or a public-health regulation mandating hospitals to report infectious diseases — the law effectively designates the controller. This does not displace the functional test; the designated entity must actually possess the ability to determine purposes and means. Member State law may also designate multiple entities as joint controllers or allocate specific responsibilities among them (EDPB Guidelines 07/2020, paras. 44–49).

## Practical consequence: the Art. 28 contract requirement

When a controller engages a processor, Art. 28(3) mandates a contract or other legal act in writing (including electronic form) that specifies:

• Subject-matter, duration, nature, and purpose of the processing
• Type of personal data and categories of data subjects
• Obligations and rights of the controller
• That the processor processes only on documented instructions (Art. 28(3)(a))
• Ensures confidentiality of persons authorized to process (Art. 28(3)(b))
• Implements appropriate technical and organizational measures (Art. 32)
• Obtains prior specific or general authorization before engaging a sub-processor (Art. 28(2))
• Assists the controller in responding to data-subject rights (Art. 28(3)(e))
• Assists the controller in ensuring security, breach notification, and DPIA compliance (Art. 28(3)(f)–(h))
• Deletes or returns all personal data at the end of the provision of services (Art. 28(3)(g))
• Makes available to the controller all information necessary to demonstrate compliance and allows audits (Art. 28(3)(h))

The EDPB has emphasized that Art. 28(3) contracts must not merely restate the regulation's text but specify concrete implementation: how breach notifications will be communicated, which audit rights the controller reserves, naming any pre-approved sub-processors, defining the technical security baseline (Guidelines 07/2020, para. 126). Failure to have a compliant Art. 28 contract is itself an infringement, exposable to Art. 83(4)(a) fines (up to €10 million or 2% of global annual turnover).

If the relationship is actually joint controllership, Art. 28 does not apply; instead, the parties must comply with Art. 26 (arrangement, essence made available to data subjects, allocation of responsibilities). Misclassifying a joint-controller relationship as controller–processor is a compliance risk: data subjects may be deprived of transparency about who controls their data, and neither party may be implementing the required Art. 26 arrangement. The EDPB and national supervisory authorities assess the substance of the relationship, not the contract label (Guidelines 07/2020, para. 13: "functional concepts").

A practitioner evaluating a vendor or partner relationship must ask: Does the vendor determine why this data is processed, or only how to execute my instructions? Does the vendor process for its own purposes (analytics, model training, cross-client benchmarking)? If yes, the vendor is a controller (or joint controller), and an Art. 28 processor agreement is insufficient — the relationship requires either separate controller arrangements or an Art. 26 joint-controller arrangement with transparent allocation of responsibilities.

Source: Regulation (EU) 2016/679 (GDPR), Articles 4(7)–(8), 26, 28 Source: EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR, adopted 7 July 2021 Source: CJEU, Wirtschaftsakademie Schleswig-Holstein, Case C-210/16, Judgment of 5 June 2018

Article 4(1) GDPR defines personal data as "any information relating to an identified or identifiable natural person ('data subject')." This definition is the gateway to GDPR applicability: if information does not qualify as personal data, the regulation does not apply. The threshold is deliberately broad and functional — the CJEU has repeatedly held that the EU legislature intended to assign a "wide scope" to the concept, encompassing "all kinds of information, not only objective but also subjective, in the form of opinions and assessments," provided the information "relates" to the data subject.

The definition has four cumulative elements: (1) any information, (2) relating to, (3) an identified or identifiable, (4) natural person. Each component has been interpreted expansively in case law.

## "Any information" — all formats, objective and subjective

The phrase "any information" reflects the regulation's technology-neutral and media-neutral design. Personal data includes text, numbers, images, audio, video, biometric templates, location coordinates, and any other perceivable or machine-readable form. It covers both objective facts (a person's date of birth, postal address, transaction history) and subjective assessments (performance reviews, credit scores, opinions expressed by or about an individual).

In EDPS v. SRB (Case C-413/23 P, judgment of 4 September 2025), the CJEU confirmed that personal opinions or views qualify as personal data even when pseudonymized, because "as an expression of a person's thinking, [they] are necessarily closely linked to that person." The Court emphasized that determining whether information "relates to" an individual does not require a separate analysis of "purpose or effect" when the content itself is inherently personal — for example, written comments authored by an identified stakeholder in a consultation process.

Similarly, in Ministerstvo zdravotnictví (Case C-710/23, judgment of 3 April 2025), the CJEU held that disclosing the name, signature, and contact details of a natural person acting as a company director constitutes processing of personal data, even though the sole purpose of the disclosure was to identify the legal person (the company). The fact that the data are disclosed in a professional or representative capacity does not remove them from the scope of Art. 4(1); the information still "relates to" the natural person. Recital 14 GDPR confirms that the regulation "does not cover the processing of personal data which concerns legal persons," but when contact details or names of natural persons are embedded in records about a legal entity, those elements are personal data of the individuals.

## "Relating to" — content, purpose, or effect test

Information "relates to" a natural person if it is linked to that person by reason of its content (the information is about the individual), its purpose (the information is used to evaluate, treat, or influence the individual), or its effect (the information impacts the individual's rights, interests, or circumstances). This three-prong test, developed under the predecessor Data Protection Directive 95/46/EC and carried forward into the GDPR, ensures that indirect linkages are captured.

A dataset that does not explicitly name an individual can still "relate to" that individual if it is used to make decisions about them or if combining it with other information would identify them. For example, anonymized transaction logs used to build a profile that is then applied to assess creditworthiness "relate to" the individuals profiled, even if the logs themselves do not contain names.

## "Identified or identifiable natural person" — the identifiability standard

An individual is identified when their identity is directly apparent from the information (name, national ID number, photograph with face clearly visible). An individual is identifiable when they can be singled out, directly or indirectly, through additional information or context.

Article 4(1) provides a non-exhaustive list of identifiers: "a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person." Online identifiers — cookies, device fingerprints, IP addresses, RFID tags, social-media handles — are explicitly recognized as capable of rendering a person identifiable, especially when combined with server logs, user-account data, or third-party datasets.

Recital 26 GDPR elaborates the identifiability test: "To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly." The assessment is objective and forward-looking: account must be taken of all objective factors, "such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments."

The CJEU applied this standard in Breyer (Case C-582/14, judgment of 19 October 2016), holding that dynamic IP addresses stored by a website operator constitute personal data if the operator has the legal means to obtain additional information (subscriber identity from the internet service provider) allowing identification, even if the operator does not hold that additional information itself and even if obtaining it requires a court order. The Court reasoned that because the legal framework permits the website operator to request identification data from the ISP under certain circumstances (such as a cyberattack investigation), the combination of the IP address (in the operator's possession) and the subscriber identity (held by the ISP) makes the visitor identifiable within the meaning of Art. 4(1).

Importantly, Recital 26 states that if identification is "prohibited by law or would require a disproportionate effort in terms of time, cost and man-power," the risk of identification should be considered insignificant and the person not identifiable. This is a high bar in practice — the CJEU in Breyer emphasized that the existence of a legal prohibition or practical difficulty does not eliminate identifiability if another party (such as an ISP or a data broker) holds the key and the controller has a lawful route to obtain it.

## Pseudonymized data remains personal data (for controllers who can re-identify)

Article 4(5) GDPR defines pseudonymization 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."

Pseudonymization is a data-protection technique, not an exit from GDPR scope. Recital 26 confirms: "Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person." If the controller (or a processor acting on its behalf) retains the ability to re-link pseudonymized records to identified individuals using a key, lookup table, or algorithm, the pseudonymized data remain personal data for that controller.

In EDPS v. SRB (C-413/23 P), the CJEU clarified that pseudonymized data "must not be regarded as constituting, in all cases and for every person, personal data" — the status depends on whether the recipient of the pseudonymized data has the means reasonably likely to be used to re-identify individuals. If effective pseudonymization prevents a third-party recipient from identifying data subjects, and the recipient has no access to the re-identification key and no other reasonable means to identify individuals, the data may not be personal data for that recipient (though they remain personal data for the controller that holds the key). The Court emphasized that identifiability is assessed from the perspective of the entity processing the data and depends on the means available to that entity and to any third parties with whom it might collaborate.

The EDPB Guidelines 01/2025 on Pseudonymisation (adopted 17 January 2025) confirm this principle and add implementation detail: even if pseudonymized data are not personal data for a downstream recipient, the controller that pseudonymized the data must still comply with transparency obligations (informing data subjects of the disclosure under Art. 13 or 14 GDPR) and must assess whether the recipient's re-identification risk is genuinely negligible.

## Anonymous data — outside GDPR scope if truly irreversible

Recital 26 states that the GDPR "does not … concern the processing of … anonymous information, that is information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." Anonymization is the process of irreversibly severing the link between a dataset and any individual. If properly achieved, anonymized data fall outside GDPR scope entirely.

The threshold is strict. The EDPB (successor to the Article 29 Working Party) has long held that anonymization must withstand all reasonable re-identification attacks, including singling out, linkability, and inference. If a motivated adversary (whether the controller, a recipient, or a third party with access to auxiliary data) can use means reasonably likely to be employed to re-identify individuals, the data are not anonymous but pseudonymous or still directly identifiable, and GDPR applies. Technological advances — machine learning, linkage attacks on supposedly anonymized datasets, growing availability of auxiliary data — have made robust anonymization increasingly difficult in practice.

## Only natural persons — legal persons excluded, but contact details of representatives are in scope

Article 4(1) refers to an "identified or identifiable natural person." The GDPR does not apply to information solely about legal persons (companies, foundations, public authorities as juridical entities). Recital 14 confirms: "This Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person."

However, when a legal person's contact details include the name, email address, telephone number, or signature of a natural person (such as a director, authorized representative, or sole proprietor), that element is personal data of the natural person. In Ministerstvo zdravotnictví (C-710/23), the CJEU held that disclosing the name and contact details of a natural person representing a company in a public register qualifies as processing personal data of that individual, even though the purpose is to identify the legal person. In practice, business-contact databases, corporate registries, and commercial directories that list natural-person representatives are processing personal data and must comply with GDPR.

## Practical consequence — the Art. 4(1) gateway

If information qualifies as personal data, all GDPR obligations apply: the controller must identify a lawful basis under Art. 6 (or Art. 9 for special-category data), comply with transparency requirements (Arts. 12–14), honor data-subject rights (Arts. 15–22), implement security measures (Art. 32), notify breaches when thresholds are met (Arts. 33–34), maintain records of processing (Art. 30), and conduct a data protection impact assessment (Art. 35) if the processing is high-risk. There is no partial or light-touch compliance for "low-risk" personal data; the definitional test is binary.

Conversely, if information is genuinely anonymous — such that no person (including the controller, any processor, and any reasonably foreseeable third party) can identify individuals using means reasonably likely to be employed — GDPR does not apply, and the controller is free to process, share, and retain the data without GDPR constraint (subject to sector-specific rules, competition law, and other legal frameworks).

A practitioner evaluating a new processing operation must begin with Art. 4(1): Does this dataset, cookie, log file, or algorithm input relate to identified or identifiable natural persons? If the answer is yes (or cannot confidently be ruled out), GDPR compliance is mandatory. The CJEU's consistent message is that the concept of personal data is broad by legislative intent, and doubts should be resolved in favor of applicability to ensure the fundamental right to data protection under Article 8 of the Charter of Fundamental Rights is effectively safeguarded.

Source: Regulation (EU) 2016/679 (GDPR), Article 4(1), (5); Recitals 14, 26 Source: CJEU, Patrick Breyer v. Bundesrepublik Deutschland, Case C-582/14, Judgment of 19 October 2016 Source: CJEU, EDPS v. Single Resolution Board, Case C-413/23 P, Judgment of 4 September 2025 Source: CJEU, Ministerstvo zdravotnictví, Case C-710/23, Judgment of 3 April 2025 Source: EDPB Guidelines 01/2025 on Pseudonymisation, adopted 17 January 2025

Article 27 GDPR imposes a mandatory obligation on controllers and processors not established in the Union but subject to GDPR under Article 3(2) (the targeting clause — offering goods or services to, or monitoring behaviour of, EU data subjects) to designate in writing a representative in the Union (Art. 27(1)). This requirement creates an EU-based point of contact for supervisory authorities and data subjects, enabling effective enforcement of GDPR obligations against entities beyond EU borders. The representative functions as a liaison, not a substitute for the foreign controller or processor, which remains fully liable for GDPR compliance.

## Trigger: Article 3(2) extraterritorial scope

The representative obligation applies only when Article 3(2) triggers GDPR applicability. A non-EU controller or processor must appoint a representative if it offers goods or services to EU data subjects (Art. 3(2)(a)) or monitors their behaviour within the Union (Art. 3(2)(b)), and it has no establishment in the Union for purposes of Article 3(1). If Article 3(1) already applies because the entity has an EU establishment in the context of which the processing occurs, Article 27 does not apply — the entity is treated as EU-established for that processing.

The EDPB Guidelines 3/2018 on territorial scope (adopted 12 November 2019) clarify that both controllers and processors falling under Article 3(2) must appoint representatives. A non-EU processor engaged by a non-EU controller to process EU data subject data in connection with offering or monitoring under Article 3(2) must itself appoint a representative, even if the processor has no direct relationship with the data subjects.

## Article 27(2): Statutory exceptions

Article 27(2) carves out two narrow exceptions. The representative requirement does not apply to:

(a) Occasional processing that meets all of the following cumulative conditions:

• Processing is occasional (not regular, repeated, or continuous);
• Does not include, on a large scale, processing of special categories of data under Article 9(1) (racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for unique identification, health data, or data concerning sex life or sexual orientation) or personal data relating to criminal convictions and offences under Article 10; and
• Is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope, and purposes of the processing.

The EDPB interprets "occasional" in line with its guidance on the Article 30 records-of-processing exemption: processing that is not carried out regularly, that happens outside the regular course of business, and whose occurrence and timing cannot reasonably be predicted. The Guidelines note that for most commercial controllers and processors offering services to EU data subjects, the processing will not qualify as occasional — a SaaS provider, e-commerce site, or analytics platform processes EU data subject data continuously or regularly, not occasionally. The large-scale threshold and the risk assessment further narrow the exception. In practice, the occasional-processing exemption applies to rare, ad-hoc processing scenarios, not to ongoing business operations.

(b) Public authorities and bodies exercising official authority under Article 3(3) are exempt. The provision originally included this exemption in Art. 27(2)(b) prior to the May 2018 effective date; it reflects the fact that public-authority processing for governmental functions typically falls outside Article 3(2) targeting logic or is subject to separate international-law frameworks.

The representative requirement does not apply to entities with an EU establishment, even a small one, if that establishment's activities are connected to the processing under Article 3(1). A US company with a French sales subsidiary must analyze whether the processing occurs "in the context of the activities" of that French entity — if yes, Article 3(1) applies and no representative is required under Article 27 (though the French subsidiary's presence may itself serve as the compliance anchor).

## Article 27(3): Location of the representative

The representative must be established in one of the Member States where the data subjects whose personal data are processed in relation to the offering of goods or services or the monitoring of behaviour are located (Art. 27(3)). If a non-EU controller offers services to data subjects in multiple Member States, the EDPB Guidelines recommend locating the representative in the Member State where the largest number of affected data subjects are located, while ensuring that data subjects in other Member States retain easy access to the representative (Guidelines 3/2018, para. 119). The representative may be a natural person or a legal entity; it may be a law firm, consultancy, private company, or a dedicated representative service provider. One representative may serve multiple non-EU controllers or processors, provided the mandate is clearly defined for each.

## Article 27(4): Role and mandate of the representative

The representative is mandated by the controller or processor to be addressed in addition to or instead of the controller or the processor by supervisory authorities and data subjects on all issues related to processing, for the purposes of ensuring compliance with this Regulation (Art. 27(4)). The mandate must be in writing (Art. 27(1)). The representative's core functions include:

• Contact point for supervisory authorities and data subjects on compliance matters (Art. 27(4));
• Maintaining records of processing activities (ROPA) under Article 30 on behalf of the controller or processor, making them available to supervisory authorities on request (Art. 30(4), Art. 31(2));
• Cooperating with supervisory authorities in the performance of their tasks (Art. 31);
• Facilitating communications regarding data-subject rights requests (Arts. 12–22), though the ultimate responsibility for responding remains with the controller or processor.

The EDPB Guidelines emphasize that the representative acts on instructions from the controller or processor and has no independent decision-making authority regarding processing. This distinguishes the representative from a Data Protection Officer (DPO), who must act independently and may not receive instructions regarding the exercise of DPO tasks (Art. 38(3)). The EDPB has confirmed that the same entity cannot simultaneously serve as both DPO and representative for the same controller or processor, because the DPO's independence requirement conflicts with the representative's instruction-following mandate (Guidelines 3/2018, para. 122).

Similarly, an EU-based processor should not act as the Article 27 representative for a non-EU controller for which it processes data, due to the potential conflict of interest between its processing role and its representative liaison function (Guidelines 3/2018, para. 121).

## Article 27(5): Preservation of direct liability

Article 27(5) states that the designation of a representative shall be without prejudice to legal actions which could be initiated against the controller or the processor themselves. The representative does not insulate the non-EU entity from enforcement. Supervisory authorities retain the power to pursue the controller or processor directly, and data subjects may bring legal actions under Article 79 against the controller or processor in addition to or instead of the representative. The representative serves an administrative facilitation function, not a liability shield.

The question of representative liability for the controller's or processor's GDPR violations has been contested. Recital 80 states that the representative "should be subject to enforcement proceedings in the event of non-compliance by the controller or processor," but the operative articles (Arts. 27, 83) do not specify representative liability for client violations. In Rondon v LexisNexis Risk Solutions UK Ltd [2021] EWHC 1442 (QB), the UK High Court held that the representative has "a bespoke, limited but important role which supports and is ancillary but not alternative to extra-jurisdictional enforcement" and is not liable for the controller's substantive GDPR breaches — only for the representative's own failure to perform its duties under Article 27(4) and related provisions. The EDPB Guidelines 3/2018 acknowledge that supervisory authorities "may initiate an enforcement action against the representative" (para. 125) but do not assert full vicarious liability for client violations. Spain's national implementing law (Organic Law 3/2018, Article 30) imposes joint liability on the representative with the controller or processor, creating a stricter regime that may diverge from the Recital 80 / Art. 27(5) balance.

Representatives who fail to fulfill their own obligations — refusing to cooperate with a supervisory authority, failing to maintain Article 30 records, or ignoring data-subject communications — may face Art. 83(4)(a) administrative fines (up to €10 million or 2% of global annual turnover). The non-EU controller or processor remains subject to the full fine scale under Art. 83(5) (up to €20 million or 4% of global turnover) for substantive violations (unlawful processing under Art. 6, breach of data-subject rights under Arts. 12–22, inadequate security under Art. 32, failure to notify breaches under Art. 33, non-compliance with cross-border transfer rules under Chapter V).

## Transparency obligation: disclosing representative identity

Controllers and processors subject to Article 27 must disclose the identity and contact details of the representative to data subjects as part of their transparency obligations under Articles 13(1)(a) and 14(1)(a). When collecting personal data directly from the data subject (Art. 13) or from other sources (Art. 14), the controller must provide the name and contact details of the controller and, where applicable, the controller's representative. The EDPB has confirmed that a non-EU controller falling under Article 3(2) that fails to inform data subjects of its representative's identity is in breach of its transparency obligations under the GDPR (EDPB statement, 16 November 2018, para. 118 of Guidelines 3/2018). The representative's contact information should appear in the entity's privacy notice or privacy policy, accessible at the point of data collection.

## Enforcement practice: fines for non-designation

Supervisory authorities have begun enforcing Article 27. On 12 May 2020, the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) fined locatefamily.com €525,000 for failure to appoint an EU representative, with an additional penalty payment of €20,000 per two-week period until compliance. The decision underscored that non-EU entities offering services to EU data subjects must designate a representative or face substantial penalties (Art. 83(4)(a) allows fines up to €10 million or 2% of total worldwide annual turnover for violations of Arts. 8, 11, 25–39, and 42–43, which includes Art. 27).

On 10 May 2023, the Austrian Data Protection Authority (Datenschutzbehörde) issued a decision against Clearview AI, finding violations of Articles 5, 6, 9, and 27 GDPR. Among other infringements, Clearview AI had failed to appoint an Article 27 representative despite being subject to Article 3(2). The authority ordered Clearview AI to designate a representative in the Union and to erase the complainant's data. The decision illustrates that Article 27 non-compliance is treated as a standalone violation and is often cited alongside substantive processing violations in multi-ground enforcement actions.

## Practical consequence: compliance checklist

A non-EU controller or processor evaluating Article 27 obligations should:

1. Determine Article 3 applicability: Does Article 3(2) apply (offering or monitoring)? If Article 3(1) applies due to an EU establishment, Article 27 does not.
2. Assess the exceptions: Does the occasional-processing exception under Art. 27(2)(a) apply? The burden is on the controller or processor to document why the exception is met. For regular commercial offerings to EU data subjects, the exception typically does not apply.
3. Designate a representative in writing (Art. 27(1)) in a Member State where a significant proportion of affected data subjects are located (Art. 27(3)).
4. Draft a clear written mandate specifying the representative's tasks, authority limits, contact protocols, and obligations to maintain Article 30 ROPA records and cooperate with supervisory authorities.
5. Disclose the representative in the privacy notice / privacy policy under Art. 13(1)(a) or Art. 14(1)(a), naming the representative and providing contact details.
6. Maintain ROPA (Art. 30) and ensure the representative has a current copy to provide to supervisory authorities on request.
7. Avoid conflicts: Do not appoint the same entity as both DPO and representative; do not appoint an EU processor that processes data on your behalf as your representative.

Non-EU entities that designate a representative are not thereby brought into the Article 56 one-stop-shop mechanism for cross-border processing. The one-stop-shop applies to controllers or processors with an establishment in more than one Member State (Art. 56(1)); a representative under Article 27 does not constitute an establishment for one-stop-shop purposes. Therefore, non-EU entities subject to Article 3(2) must cooperate with all supervisory authorities in Member States where affected data subjects are located, and breach notifications under Article 33 must be made to each relevant supervisory authority, not a single lead authority (EDPB Guidelines 9/2022 on breach notification, para. 73).

The Article 27 requirement reflects the GDPR's commitment to effective enforcement against entities beyond EU jurisdiction. The representative ensures that supervisory authorities and data subjects have a local point of contact and that GDPR compliance can be monitored and enforced even when the controller or processor operates from a third country. Failure to appoint a representative exposes the entity to administrative fines, enforcement orders, and reputational risk, as recent supervisory-authority decisions demonstrate.

Source: Regulation (EU) 2016/679 (GDPR), Articles 3, 4(17), 13, 14, 27, 30, 31, 83, Recital 80 Source: EDPB Guidelines 3/2018 on the territorial scope of the GDPR (Article 3), adopted 12 November 2019

Article 9 GDPR establishes the most stringent data-protection regime in the regulation: a general prohibition on processing nine enumerated categories of special-category personal data (often called "sensitive data"), followed by a narrow list of ten exceptions that lift the prohibition when specific conditions are met. These categories are singled out because processing them carries heightened risks of discrimination, stigma, and interference with fundamental rights. Processing special-category data requires both an Article 6(1) lawful basis (consent, contract, legal obligation, vital interests, public task, or legitimate interests) and an Article 9(2) exception — a two-layer compliance structure confirmed by the CJEU in Krankenversicherung Nordrhein (Case C-667/21, judgment of 21 December 2023, para. 90). Controllers evaluating whether data fall within Article 9 must apply the CJEU's expansive interpretation: special-category data include not only information that directly reveals a protected characteristic but also data liable indirectly to reveal such characteristics through inference, comparison, or deduction.

## Article 9(1): The prohibition — nine special categories

Article 9(1) states: "Processing of 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 data concerning a natural person's sex life or sexual orientation shall be prohibited."

The nine special categories are:

1. Racial or ethnic origin — data revealing an individual's race, ethnicity, or descent. This includes explicit identifiers (self-declared ethnicity in a form) and data from which ethnicity can be inferred (nationality, country of birth, language, surname patterns, photographs processed with facial-recognition algorithms calibrated to ethnicity, or membership in ethnic-minority organizations).

1. Political opinions — data revealing an individual's political beliefs, party affiliation, voting intentions, or participation in political activities. Membership in a political party, donations to political campaigns, attendance at political rallies, and publicly expressed political views all fall within this category. Recital 56 clarifies that processing of personal data for direct-marketing purposes may be regarded as carried out for a legitimate interest (Art. 6(1)(f)), but when the marketing involves profiling based on political opinions, it triggers the Art. 9(1) prohibition and requires an Art. 9(2) exception.

1. Religious or philosophical beliefs — data revealing religious faith, atheism, agnosticism, or adherence to a philosophical worldview (such as pacifism, veganism framed as an ethical belief system, or secular humanism). Membership in a religious congregation, dietary restrictions linked to religion (kosher, halal), religious clothing or symbols visible in photographs, and participation in worship or religious events are all within scope.

1. Trade union membership — data revealing membership in or affiliation with a labor union or workers' representative body. Employee lists that identify union members, dues deductions on payroll records, and participation in collective-bargaining activities are covered.

1. Genetic data — 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." Genetic data include DNA sequences, genomic test results (ancestry tests, genetic predisposition screenings, whole-genome sequencing), and family medical histories that reveal inherited genetic traits. Recital 34 emphasizes that genetic data "should not include information about the mere assignment of a number to the data subject," ensuring the definition captures substantive genetic information, not administrative identifiers.

1. Biometric data for the purpose of uniquely identifying a natural person — Article 4(14) defines biometric data 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 data" (fingerprints). The key limitation: biometric data qualify as special-category data under Art. 9(1) only when processed for the purpose of unique identification. A gym that scans members' fingerprints to control access is processing special-category biometric data; a photograph in an HR file used solely for visual recognition by colleagues, without algorithmic or technical processing for identification, is not special-category data under Art. 9, though it remains personal data under Art. 4(1). Recital 51 notes that photographs "should be considered to be biometric data only when they are processed through a specific technical means allowing the unique identification or authentication of a natural person." Facial recognition, iris scanning, voiceprint analysis, and gait-recognition algorithms all produce biometric data for unique identification when deployed for that purpose.

1. Data concerning health — 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." Health data encompass medical diagnoses, test results, prescriptions, hospital admission records, disability status, mental-health treatment history, genetic predisposition to disease, insurance claims for medical services, sick-leave records, and wellness-app data that track symptoms or vital signs (heart rate, blood pressure, glucose levels). The CJEU has clarified that the definition is functional and broad: in Lindenapotheke (Case C-21/23, judgment of 4 October 2024), the Court held that the sale of non-prescription, pharmacy-only medicinal products online — where the controller processes the buyer's name, address, and the specific product ordered — constitutes processing of health data, because the product's therapeutic uses allow "a link to be established between … a medicinal product, the therapeutic uses thereof and an identified or identifiable natural person" (para. 47). The Court emphasized that health data can be revealed "by means of an intellectual operation involving collation or deduction," not only through direct medical records.

1. Data concerning a natural person's sex life — data revealing sexual activity, sexual practices, sexual history, or related intimate behaviors. This includes sexual-health records (STI testing, contraceptive prescriptions), relationship history when linked to sexual conduct, and online activity indicating sexual interests or behavior.

1. Data concerning a natural person's sexual orientation — data revealing whether an individual is heterosexual, homosexual, bisexual, asexual, or another orientation. Membership in LGBTQ+ organizations, participation in Pride events, self-identification of sexual orientation, and data from which orientation can be inferred (such as the name and gender of a spouse or partner) all fall within this category.

## "Revealing" includes indirect inference — the CJEU's expansive interpretation

The CJEU has held that Article 9(1) applies not only to data that explicitly state a special category but also to data liable indirectly to reveal a protected characteristic. In OT v Vyriausioji tarnybinės etikos komisija (Case C-184/20, judgment of 1 August 2022), the Court ruled that publishing the name of an individual's spouse, cohabitee, or partner as part of a public-interest declaration constitutes processing of special-category data concerning sexual orientation under Art. 9(1). The Lithuanian court had found that it was possible to deduce information about sexual orientation from the partner's name (through gender inference), and the CJEU held this was sufficient to trigger the prohibition, regardless of whether the controller intended to reveal sexual orientation or whether the inference was accurate (para. 71–72). The Court emphasized that the concept of data "revealing" special categories must be interpreted broadly, encompassing data that "are liable indirectly to reveal sensitive information concerning a natural person, such as … their … sexual orientation … by means of an intellectual operation involving comparison or deduction" (para. 72).

In Meta Platforms v Bundeskartellamt (Case C-252/21, judgment of 4 July 2023), the CJEU confirmed this expansive reading, stating that "the concept of 'personal data revealing' … special categories … must be understood as covering not only data which, by their nature, directly reveal such information, but also data which, by reason of their combination with other data or because of the particular context in which they were collected or disclosed, make it possible, by means of deduction or inference, to reveal such information" (para. 89). The Court noted that behavioral tracking across websites and apps — through cookies, plug-ins, and data aggregation — can reveal special-category data even when no single data point explicitly names a protected characteristic. In that case, the CJEU held that even though Maximilian Schrems had publicly disclosed his sexual orientation in a panel discussion, Meta could not rely on the Article 9(2)(e) exception ("data manifestly made public by the data subject") to process additional special-category data obtained from external sources (websites visited, third-party plugins, offline tracking) and aggregate it for targeted advertising, because the public disclosure was limited to the specific statement made in the specific forum, not a blanket waiver for all processing (para. 101–107).

The practical consequence: controllers must assess whether data, when combined with other information available to the controller or to third parties, or when processed in a particular context, are liable to reveal a special category. A name, photograph, delivery address for a pharmacy order, website visit logged by a tracking pixel, or social-media "like" may trigger Art. 9(1) if the processing involves inference about a protected characteristic. The CJEU's test is objective and forward-looking: if the data are capable of revealing the information through deduction, the prohibition applies, even if the controller does not intend to make the inference and even if the inference might be inaccurate.

## Article 9(2): The ten exceptions that lift the prohibition

Processing special-category data is lawful only if one of the ten exceptions in Article 9(2) applies and the processing satisfies an Article 6(1) lawful basis. The Art. 9(2) exceptions are:

(a) Explicit consent — "the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition … may not be lifted by the data subject." Recital 51 clarifies that explicit consent requires an express statement or a clear affirmative action; pre-ticked boxes, silence, and inactivity do not qualify. The EDPB Guidelines 05/2020 on consent (adopted 4 May 2020) specify that explicit consent "requires a very clear and specific statement of consent" — written declaration, signed form, oral declaration recorded and logged, or an electronic form with a typed confirmation such as "I consent to processing my health data for X." Standard cookie-banner checkboxes do not meet the explicit-consent threshold for special-category data. Recital 33 permits "broad consent" in scientific research when the purpose cannot be fully specified at the time of collection, but this flexibility is strictly limited and does not displace the requirement that consent be informed, freely given, and revocable.

(b) Employment, social security, and social protection — processing is necessary for the controller or the data subject to carry out obligations and exercise specific rights in the field of employment, social security, and social protection law, insofar as it is authorized by Union or Member State law or a collective agreement providing appropriate safeguards. Examples: processing employee health data to comply with occupational health and safety regulations, managing sick leave under national labor law, or administering statutory health-insurance contributions. The exception requires a legal basis in Union or Member State law; it does not permit arbitrary employer access to health records outside the scope of legal obligations.

(c) Vital interests — processing is necessary to protect the vital interests of the data subject or another natural person where the data subject is physically or legally incapable of giving consent. This exception is narrow and applies in emergencies: a hospital treating an unconscious patient and processing their blood-type or allergy data; a first responder accessing medical-alert information from a wearable device when the wearer is unable to communicate. If the data subject can give consent, this exception does not apply.

(d) Not-for-profit bodies — processing is carried out in the course of the legitimate activities of a foundation, association, or any other not-for-profit body with a political, philosophical, religious or trade union aim, provided the processing relates solely to members or former members (or persons in regular contact with the body in connection with its purposes) and the data are not disclosed outside that body without the data subjects' consent. This exception permits a political party to maintain a member database including political opinions, a church to process congregant religious affiliation, or a trade union to track membership. Recital 56 confirms that the exception is limited to activities "with appropriate safeguards" and does not extend to processing for purposes unrelated to the organization's core mission.

(e) Data manifestly made public by the data subject — processing relates to personal data manifestly made public by the data subject. The threshold is high: the data subject must have taken an active, intentional step to make the data public (posting on a public social-media profile, speaking at a public event, publishing an article). The CJEU in Meta Platforms held that publicly disclosing sexual orientation in one context (a panel discussion) does not constitute a blanket waiver for controllers to aggregate additional special-category data from other sources and process them for unrelated purposes (para. 105–107). The exception is narrow and context-specific.

(f) Legal claims or judicial acts — processing is necessary for the establishment, exercise, or defense of legal claims or whenever courts are acting in their judicial capacity. This permits lawyers, courts, and litigants to process special-category data in litigation (medical records in a personal-injury case, political affiliation in a discrimination claim, genetic data in a paternity dispute).

(g) Substantial public interest — processing is necessary for reasons of substantial public interest, on the basis of Union or Member State law which is proportionate to the aim pursued, respects the essence of the right to data protection, and provides for suitable and specific measures to safeguard fundamental rights and interests of the data subject. This exception requires a legislative basis — the controller cannot unilaterally declare a substantial public interest. Examples: processing genetic data for public-health genomic surveillance programs authorized by statute, or anti-money-laundering processors handling politically exposed-person (PEP) data under AML directives. National implementing laws often enumerate specific public-interest grounds in schedules or annexes (as in the UK DPA 2018 Schedule 1 Part 2).

(h) Health or social care — processing is necessary for preventive or occupational medicine, assessment of working capacity, medical diagnosis, provision of health or social care or treatment, or management of health or social care systems and services, on the basis of Union or Member State law or a contract with a health professional, and subject to the conditions in Article 9(3): processing must be by or under the responsibility of a professional subject to the obligation of professional secrecy (physician, nurse, pharmacist) or another person also subject to equivalent secrecy obligations under Union or Member State law. The CJEU in Krankenversicherung Nordrhein held that a medical service provider (MDK) processing health data of its own employees to assess their working capacity could rely on Art. 9(2)(h) and Art. 9(3), provided the processing was conducted by or under the responsibility of a professional bound by secrecy (para. 60–62).

(i) Public health — processing is necessary for reasons of public interest in the area of public health, such as protecting against serious cross-border threats to health or ensuring high standards of quality and safety of health care and medicinal products or medical devices, on the basis of Union or Member State law which provides suitable and specific measures to safeguard rights, in particular professional secrecy. This exception underpins COVID-19 contact-tracing systems, infectious-disease reporting mandates, and national health surveillance registries authorized by statute.

(j) Archiving, research, and statistics — processing is necessary for archiving purposes in the public interest, scientific or historical research purposes, or statistical purposes in accordance with Article 89(1) based on Union or Member State law which is proportionate, respects the essence of the right to data protection, and provides for suitable and specific measures to safeguard fundamental rights and interests. Article 89(1) requires technical and organizational measures to ensure data minimization (pseudonymization where possible) and mandates that research data not be used for decisions affecting individuals unless a further lawful basis exists. Many Member States have enacted research-specific implementing laws that authorize broad scientific-research processing under this exception.

## Article 9(4): Member State discretion to maintain or introduce further conditions

Article 9(4) permits Member States to "maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data or data concerning health." Several Member States have exercised this power: France requires hébergeur de données de santé (HDS) certification for hosting health data; Germany's BDSG adds employment-context restrictions on biometric data; Italy's Garante has issued binding rules on biometric attendance systems. Controllers processing these three categories must check national law in each Member State where they operate.

## Two-layer requirement: Article 6 lawful basis + Article 9 exception

Recital 51 states: "In addition to the specific requirements for such processing, the general principles and other rules of this Regulation should apply, in particular as regards the conditions for lawful processing." The CJEU confirmed in Krankenversicherung Nordrhein (para. 90) that Article 9(2) does not itself provide a lawful basis for processing — it lifts the prohibition, but the controller must also satisfy one of the six Article 6(1) lawful bases. A controller processing health data must identify:

• Layer 1: An Article 6(1) lawful basis — consent (Art. 6(1)(a)), contract (Art. 6(1)(b)), legal obligation (Art. 6(1)(c)), vital interests (Art. 6(1)(d)), public task (Art. 6(1)(e)), or legitimate interests (Art. 6(1)(f)).
• Layer 2: An Article 9(2) exception that lifts the Art. 9(1) prohibition.

Both must apply. The EDPB has clarified that legitimate interests (Art. 6(1)(f)) is rarely appropriate for special-category data processing, because the heightened sensitivity and the narrow Art. 9(2) exceptions generally preclude the controller's business interests from outweighing data subjects' fundamental rights. Common pairings in practice: Art. 6(1)(a) (consent) + Art. 9(2)(a) (explicit consent); Art. 6(1)(c) (legal obligation) + Art. 9(2)(b) (employment law) or Art. 9(2)(i) (public health statute); Art. 6(1)(e) (public task) + Art. 9(2)(g) (substantial public interest authorized by law).

## Heightened obligations triggered by special-category data

Processing special-category data engages additional GDPR requirements:

• Data Protection Impact Assessment (DPIA): Article 35(3)(b) mandates a DPIA when processing includes "processing on a large scale of special categories of data pursuant to Article 9(1)." The EDPB Guidelines 4/2019 on Art. 35 (adopted 29 January 2020) clarify that "large scale" considers the number of data subjects, volume of data, duration, and geographical extent; even medium-scale processing of special-category data often triggers a DPIA due to inherent high risk.

• Records of processing activities (ROPA): Article 30(5) removes the small-enterprise exemption (fewer than 250 employees) when processing includes special categories of data under Art. 9(1) or criminal-conviction data under Art. 10. Any controller processing special-category data must maintain ROPA regardless of size.

• Administrative fines: Violations of Article 9 fall under the higher fine tier in Article 83(5), exposing controllers and processors to fines up to €20 million or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher. This contrasts with Art. 83(4) (up to €10 million or 2% of turnover) for violations of controller/processor obligations under Arts. 25–39.

• Transparency: Controllers must inform data subjects which special categories are processed and which Art. 9(2) exception applies, as part of the Art. 13 or Art. 14 transparency obligations.

## Practical takeaway

A controller evaluating a processing operation must ask: (1) Does the data directly reveal, or is it liable indirectly to reveal, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic characteristics, biometric identification, health status, sex life, or sexual orientation? (2) If yes, which Article 9(2) exception applies? (3) Which Article 6(1) lawful basis applies? If the controller cannot answer all three affirmatively with documented justification, the processing violates Article 9(1) and exposes the controller to Art. 83(5) fines, enforcement action by supervisory authorities under Art. 58, and private claims for compensation under Art. 82. The CJEU's case law — particularly OT and Meta Platforms — imposes an objective, forward-looking risk assessment: if data could reveal a special category through inference, controllers must treat them as special-category data, implement appropriate safeguards, conduct a DPIA, and document the legal basis. The prohibition is the default; the exceptions are narrow and must be construed strictly to preserve the fundamental right to data protection under Article 8 of the Charter of Fundamental Rights.

Source: Regulation (EU) 2016/679 (GDPR), Article 9, Article 4(13)–(15), Article 35(3)(b), Article 83(5), Recitals 33, 34, 51, 56 Source: CJEU, OT v Vyriausioji tarnybinės etikos komisija, Case C-184/20, Judgment of 1 August 2022 Source: CJEU, Meta Platforms v Bundeskartellamt, Case C-252/21, Judgment of 4 July 2023 Source: CJEU, Krankenversicherung Nordrhein, Case C-667/21, Judgment of 21 December 2023