GDPR Article 4: The Key Definitions Product and Engineering Teams Need

Short answer: GDPR Article 4 is the definitions article of the regulation. Its 26 numbered terms, including personal data, processing, pseudonymisation, controller, consent and personal data breach, decide whether GDPR applies to a feature and which obligations follow. The definitions are broader than most product teams expect, so read them before you design.

Related guides:

• Data controller vs data processor: differences explained
• GDPR special category data
• Your guide to the 6 lawful bases for data processing under GDPR

Key takeaways

• Personal data covers anything relating to an identified or identifiable person, including online identifiers such as device IDs, cookie IDs and often IP addresses.
• Processing means almost any operation on personal data, including reading a log or deleting a record.
• Pseudonymised data is still personal data for anyone who can re-identify it. Only truly anonymised data falls outside GDPR.
• Consent must be freely given, specific, informed and unambiguous. Pre-ticked boxes do not qualify.
• Genetic, biometric and health data have their own definitions, which feed into the stricter rules in Article 9.

---

What is GDPR Article 4?

Article 4 is the glossary of the General Data Protection Regulation. Some of its 26 definitions mostly matter to regulators. Others shape everyday decisions: what you log, how you hash identifiers, how you word a signup form and how you classify an incident. The full text is on EUR-Lex. The table summarizes the terms product teams meet most often.

Article 4 term	Plain-English meaning	SaaS or HealthTech example
(1) Personal data	Any information relating to an identified or identifiable living person	User email, device ID, patient record number
(4) Profiling	Automated evaluation of personal aspects to analyze or predict	Churn scoring, risk scoring for care management
(5) Pseudonymisation	Data unlinkable to a person without separately kept information	Patient names replaced with tokens, key in a vault
(7) Controller	Decides why and how personal data is processed	A clinic using your scheduling app
(8) Processor	Processes personal data on the controller's behalf	Your SaaS platform processing the clinic's patient data
(11) Consent	Freely given, specific, informed, unambiguous agreement	An unticked opt-in box for marketing emails
(12) Personal data breach	A security breach affecting personal data	An exposed storage bucket with user exports
(15) Data concerning health	Data about physical or mental health, including care received	Symptoms logged in a telehealth app

What counts as personal data and processing?

Personal data is any information relating to an identified or identifiable natural person, and processing is almost anything you do with it. Article 4(1) says a person is identifiable if they can be identified directly or indirectly, for example by a name, an identification number, location data, an online identifier or factors specific to their identity.

The word "identifiable" does the heavy lifting. A user ID, a device fingerprint, a GPS trail or a combination of job title, employer and city can single someone out. Recital 26 says to consider all means reasonably likely to be used to identify a person.

Processing (Article 4(2)) covers collection, storage, retrieval, use, disclosure, combination, erasure and more. Reading a production log that contains emails is processing. So is deleting it.

Restriction of processing (Article 4(3)) means marking stored personal data to limit its future processing, which supports the Article 18 right.

Profiling (Article 4(4)) is automated processing that evaluates personal aspects, in particular to analyze or predict things like work performance, health, preferences, behavior or location.

What it means for your product:

• Treat user IDs, device IDs, cookie IDs and location data as personal data in your data inventory.
• Build a "restricted" state into your data model so you can stop using a record without deleting it.
• Flag scoring and prediction features as profiling, and check whether Article 22 applies.

Pseudonymisation vs anonymisation: what is the difference?

Pseudonymised data is still personal data under GDPR, while anonymised data is not. Article 4(5) defines pseudonymisation as processing personal data so it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected by technical and organisational measures.

The link still exists. If the token table, the key or a matching dataset could reconnect the data to a person, it is pseudonymised, not anonymous. Recital 26 confirms that pseudonymised data which could be attributed to a person using additional information is information on an identifiable person, and that GDPR does not apply to anonymous information. Identifiability is judged by the means reasonably likely to be used, so a recipient with no realistic way to re-identify a dataset may be in a different position from the organization that holds the key. Treat that as a question for legal review, and assume GDPR applies to any pseudonymised data your organization can re-link.

	Pseudonymised data	Anonymised data
Can be re-linked to a person	Yes, with the additional information	No, by any means reasonably likely to be used
Does GDPR apply?	Yes, though pseudonymisation is recognized as a safeguard	No
Typical HealthTech example	Study dataset with patient tokens, key held by the clinic	Aggregated counts with small cells suppressed

What it means for your product: Pseudonymisation is a strong safeguard, but you still need a lawful basis, retention limits and breach handling. Before calling a dataset "anonymous", test whether it could realistically be re-identified.

Who are the controller, processor, recipient and third party?

The controller decides why and how personal data is processed, the processor acts on its behalf, a recipient receives disclosed data and a third party is anyone outside those roles. Most B2B SaaS companies are processors for customer data and controllers for their own billing and marketing data, as the related guide above explains. Two less familiar definitions matter for data flows:

• Recipient (Article 4(9)): a person or body to which personal data is disclosed, whether or not it is a third party. Your subprocessors are recipients. Public authorities receiving data in a specific legal inquiry are not.
• Third party (Article 4(10)): anyone other than the data subject, the controller, the processor and people authorized to process the data under the direct authority of the controller or processor.

What it means for your product: List recipients by category in your privacy notice and in your GDPR Article 30 records of processing.

How does GDPR define consent and a personal data breach?

Consent is a freely given, specific, informed and unambiguous indication of a person's wishes, by a statement or clear affirmative action. A personal data breach is a security breach leading to the destruction, loss, alteration, unauthorised disclosure of or access to personal data.

Consent, Article 4(11)

1. Freely given: do not bundle it with the terms of service for processing the service does not need.
2. Specific: separate choices for separate purposes, such as product emails versus marketing emails.
3. Informed: say who you are and what you will do before they agree.
4. Unambiguous, by statement or clear affirmative action: silence, pre-ticked boxes and inactivity do not count (Recital 32).

Consent is only one of six lawful bases, and often not the right one for core product features.

Personal data breach, Article 4(12)

The definition is broader than "hacked". Accidental deletion with no backup, ransomware that encrypts patient records and an email sent to the wrong customer can all qualify.

What it means for your product: Ask "was personal data affected?" for every security incident, then follow our GDPR breach notification guide.

How does Article 4 define genetic, biometric and health data?

Article 4 defines these terms so that Article 9 can apply stricter rules to them:

• Genetic data (Article 4(13)): personal data on inherited or acquired genetic characteristics that gives unique information about a person's physiology or health, in particular from analyzing a biological sample.
• Biometric data (Article 4(14)): personal data resulting from specific technical processing of physical, physiological or behavioral characteristics that allows or confirms unique identification, such as facial images or fingerprint data. A profile photo alone is not automatically biometric data. A face template used for verification is.
• Data concerning health (Article 4(15)): personal data about a person's physical or mental health, including the provision of health care services, that reveals information about their health status. An appointment booked with an oncology clinic can reveal health status even without a diagnosis field.

HealthTech teams should assume most clinical, wellness and care fields fall into these categories. The special category data guide above covers the processing conditions.

What do main establishment and cross-border processing mean?

Main establishment decides which EU supervisory authority leads on your cross-border processing.

• Main establishment (Article 4(16)): for a controller with establishments in several Member States, generally the place of its central administration in the EU, unless decisions about purposes and means are taken and implemented at another EU establishment. Processors have a parallel rule.
• Enterprise and group of undertakings (Articles 4(18) and 4(19)): any person or entity engaged in economic activity, and a controlling undertaking with those it controls.
• Cross-border processing (Article 4(23)): processing across establishments in more than one Member State, or at a single establishment that substantially affects, or is likely to affect, people in several Member States.

What it means for your product: Where you place EU decision-making affects which regulator leads. Non-EU companies without an EU establishment generally cannot use this one-stop-shop and may need an EU representative.

What are the most common misreadings of GDPR definitions?

Most mistakes come from reading "personal data" too narrowly. Watch for these:

• "Hashed emails are anonymous." Anyone who hashes the same address can match it, and it still singles out a person across systems. Treat it as pseudonymised personal data.
• "B2B contact data is not personal data." A work email such as jane.doe@hospital.example identifies a person. Your CRM is full of personal data.
• "IP addresses are just network data." IP addresses can be personal data, especially when you or another party can link them to a user. Recital 30 names IP addresses and cookie identifiers as online identifiers.
• "Aggregated means anonymous." Small cohorts and rare conditions can still identify people.

How SecureSlate helps

SecureSlate helps SMB and HealthTech teams turn GDPR definitions into working controls: GDPR policies, control mapping across GDPR, HIPAA, SOC 2 and ISO 27001, vendor risk tracking for processors and subprocessors, a risk register for privacy risks, and evidence kept in one place so you are ready when customers or auditors ask.

Start your free SecureSlate trial

FAQ

Is pseudonymised data covered by GDPR?

Yes, for any organization that holds or can reasonably obtain the additional information needed to re-identify it. In that situation it remains personal data. Only anonymised data falls outside the regulation.

Are IP addresses personal data under GDPR?

They can be. Recital 30 lists IP addresses among online identifiers, and they are personal data where they can reasonably be linked to an individual. Treat them as personal data by default.

Does Article 4 define health data for HealthTech apps?

Yes. Article 4(15) covers personal data about physical or mental health, including health care services, that reveals health status. Wellness and appointment data can fall within it, and Article 9 sets the conditions for processing it.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.