Skip to main content
DataRidge
Category: Privacy Principles

Data Subject

Also known as: Individual (in EU/UK GDPR context)
Simply put

A data subject is the identified or identifiable living individual whose personal data is being processed. In practice, this is the person the data is about, such as a customer, employee, or website user. This term comes from European data protection law and carries a specific meaning under the EU GDPR and UK GDPR.

Formal definition

Under the EU GDPR, a data subject is the identified or identifiable natural person to whom personal data relates, where personal data means any information relating to that person and identifiability may be established directly or indirectly. The concept is defined within the GDPR's definitions and is the reference point for the rights afforded to individuals under that Regulation, including, among others, the right to be informed, the right of access, and the right to rectification. Scope notes: a data subject is generally understood to be a natural person, not a legal entity, and the term is native to the EU GDPR and mirrored in the UK GDPR; other regimes (for example the CCPA and CPRA, which use 'consumer', or HIPAA, which uses 'individual') frame the equivalent role differently, so treatment is not interchangeable across jurisdictions. This entry defines the actor only; it does not enumerate the full catalogue of data subject rights, the conditions or exemptions governing their exercise, response timelines, or the distinct obligations borne by a controller versus a processor when responding to those rights. The distinction between personal data and special category data, and between a data subject and a data controller or processor, is out of scope here.

Why it matters

The data subject is the reference point around which the entire rights framework of the EU GDPR and UK GDPR is built. Because the Regulation defines a data subject as the identified or identifiable natural person to whom personal data relates, correctly determining who qualifies as a data subject is a prerequisite for knowing whose rights apply and whose data triggers obligations. Getting this wrong at the outset, for example, by treating only direct identifiers as relevant, or by overlooking that individuals can be identifiable indirectly, can cause an organisation to underscope its compliance activities.

The concept also matters because it is jurisdictionally specific. 'Data subject' is native to the EU GDPR and mirrored in the UK GDPR, but equivalent roles are framed differently elsewhere: the CCPA and CPRA use 'consumer' and HIPAA uses 'individual'. Treating these terms as interchangeable is a common expert-level error, because the scope, definitions, and rights attached to each differ by regime. Organisations operating across borders generally need to map how each applicable framework describes the individual before assuming a single set of rights or definitions applies uniformly.

A further practical point is that the data subject is defined as a living natural person, not a legal entity. This distinction shapes which records fall within scope of the Regulation and which do not, and it underpins the individual rights the GDPR affords, including the right to be informed, the right of access, and the right to rectification. This entry identifies the actor only; the full catalogue of rights, the conditions and exemptions governing their exercise, and response timelines are addressed elsewhere.

Who it's relevant to

Data Protection Officers
DPOs need a precise understanding of who qualifies as a data subject because that determination governs the scope of the rights framework they oversee. This includes recognising that identifiability may be direct or indirect and that the term applies to living natural persons rather than legal entities under the EU GDPR and UK GDPR.
Privacy and Compliance Teams Operating Across Jurisdictions
Teams working under multiple regimes must avoid treating 'data subject' as interchangeable with equivalents such as 'consumer' under the CCPA and CPRA or 'individual' under HIPAA. Because these terms are framed differently across frameworks, mapping the correct terminology and its scope per jurisdiction is essential before assuming rights or definitions carry over.
Privacy Engineers and Data Governance Leads
Those responsible for data catalogues, lineage, and processing records benefit from applying the identifiability test, direct or indirect, when classifying whether records relate to a data subject. Correct scoping at this stage informs which data falls within the Regulation and supports demonstrable accountability, though this entry does not cover controller or processor obligations for responding to rights.
Legal Professionals Advising on Data Protection
Counsel advising on GDPR matters rely on the precise definition of a data subject as the identified or identifiable natural person to whom personal data relates. Because the concept is native to the EU GDPR and mirrored in the UK GDPR but framed differently elsewhere, advice should be scoped to the applicable regime rather than assumed to be universal.

Inside Data Subject

Identified or identifiable natural person
A data subject is the living individual to whom personal data relates. The concept centers on natural persons and generally does not extend to legal entities such as companies. Identifiability can be direct (by name or identifier) or indirect (by reference to factors that, combined, single out the person).
Origin in EU/UK GDPR framing
The term is most prominently defined and used within the EU GDPR and the UK GDPR. Other regimes address the same underlying individual using different terminology; for example, the CCPA and CPRA generally refer to a 'consumer.' The obligations attached to the individual differ by regime and should not be assumed to be equivalent.
Basis for individual rights
Being a data subject is what triggers the rights that a given regime affords, which may include access, rectification, erasure, restriction, portability, and objection under the EU/UK GDPR. The specific rights, their conditions, and available exemptions vary by jurisdiction and by processing context.
Relationship to controllers and processors
The data subject is distinct from the parties that handle their data. The controller determines purposes and means of processing and generally bears primary accountability toward the data subject, while the processor acts on the controller's documented instructions. The data subject typically exercises rights against the controller.
Scope of the personal data connected to the individual
Data relating to a data subject may include ordinary personal data and, in some cases, special category (sensitive) data, which attracts additional conditions under the EU/UK GDPR. Pseudonymized data still relates to a data subject and remains personal data; only irreversibly anonymized data generally falls outside this scope.

Common questions

Answers to the questions practitioners most commonly ask about Data Subject.

Is a data subject the same as a customer or a user account?
No. A data subject is the identified or identifiable natural person to whom personal data relates, not a commercial role or a system record. A single individual may be a data subject across many contexts, such as an employee, a website visitor, and a prospect, without holding any customer relationship or account. Conversely, a user account may correspond to more than one natural person, or to none in the case of shared or service accounts. The concept is tied to the person, not to the record or the relationship, so scoping rights and obligations to account holders alone can miss data subjects whose personal data you process without any account.
Do only living individuals in the EU count as data subjects?
The term originates in EU data protection law and, under the EU GDPR, generally concerns identified or identifiable natural persons in connection with processing that falls within that regime's territorial scope, which can extend beyond individuals physically located in the EU. Whether deceased persons or legal entities are covered is not uniform: the GDPR generally concerns natural persons and leaves the treatment of the deceased to national law, and other regimes such as the UK GDPR, the CCPA and CPRA, or HIPAA use their own defined terms, such as consumer or individual, with their own scope. Do not assume the EU definition applies unchanged in other jurisdictions; confirm the applicable instrument. This answer does not address territorial scope mechanics or cross-border transfer rules.
How should we determine whether a person is identifiable when scoping data subjects?
Identifiability is generally assessed by reference to the means reasonably likely to be used to identify the person, taking account of available data, linkable datasets, and technical context, rather than by whether a direct identifier such as a name is present. This means pseudonymized data typically still relates to a data subject because re-identification remains possible, whereas data that is genuinely anonymized to an irreversible standard generally falls outside the definition. In practice, document your identifiability assessment and revisit it when new linkable data or capabilities become available. This entry does not prescribe a specific anonymization technique or threshold.
As a processor, do we owe obligations directly to data subjects?
The allocation depends on the regime and the arrangement. Generally, the controller determines purposes and means and bears primary accountability toward data subjects, including responding to their requests, while a processor acts on documented instructions and typically assists the controller rather than fielding requests independently. Where individuals contact a processor directly, the usual approach is to route the matter to the relevant controller under the terms of the processing arrangement. Confirm role classification for each processing activity, since the same organization can be a controller for some data and a processor for others. This does not cover contractual liability terms or specific rights-handling timelines.
How do we handle a request when we cannot confirm which data subject it concerns?
Because rights attach to the person, you generally need reasonable assurance that the requester is the data subject in question before acting, to avoid disclosing personal data to the wrong individual. Verification approaches typically balance the sensitivity of the data against the burden on the requester, and some regimes recognize that a controller may be unable to identify a data subject from the data held. Where you cannot link a request to identifiable personal data using reasonable means, document that assessment and the basis for your response. This entry does not set specific verification standards, response deadlines, or exemptions, which vary by instrument and should be checked against the applicable law.
What records support demonstrating that we have correctly identified and served data subjects?
Accountability under most governance and data protection frameworks requires demonstrable evidence rather than stated intent, so maintain records that show how you determine who your data subjects are and how their rights are handled. This generally includes documented identifiability assessments, records of processing activities where required, role classifications distinguishing controller and processor activities, and logs of requests received and actions taken. These governance artifacts overlap with, but are distinct from, the security controls that protect the underlying data. This answer does not specify a mandatory record format or address whether a records of processing activities obligation applies to your organization, which depends on the applicable regime and thresholds.

Common misconceptions

A data subject can be a company or organization.
In the EU/UK GDPR sense, a data subject is a living natural person. Legal entities are generally not data subjects, though information about an individual associated with an entity (for example, a sole trader or a named contact) may still relate to a data subject.
Once data is encrypted, tokenized, or pseudonymized, the individual is no longer a data subject.
Encryption, tokenization, and pseudonymization are security or risk-reduction measures, not a change of legal status. Because the link to the individual can generally be restored, such data typically remains personal data and the person remains a data subject. Only irreversible anonymization generally removes data from scope.
The terms 'data subject' and 'consumer' are interchangeable across regimes.
'Data subject' is primarily EU/UK GDPR terminology, while the CCPA and CPRA generally use 'consumer.' The scope, definitions, and rights attached differ by regime, so the terms should not be treated as equivalent without checking the applicable law.

Best practices

Determine which regime applies before assuming a person is a 'data subject' with GDPR-style rights, since terminology and the associated rights differ across the EU/UK GDPR, the CCPA/CPRA, and other frameworks.
Map which party is the controller and which is the processor for each processing activity, so that data subject requests are routed to the accountable party and handled within the applicable conditions.
Treat pseudonymized, encrypted, and tokenized data as still relating to a data subject in your records and rights-handling processes, rather than excluding it as non-personal.
Identify where special category (sensitive) data about individuals is processed and apply the additional conditions that generally attach to it under the EU/UK GDPR.
Maintain demonstrable evidence of how data subject rights requests are received, verified, and fulfilled, since accountability generally requires evidence rather than stated intent.
Confirm the specific rights, conditions, and exemptions available in your jurisdiction for each request type rather than assuming a uniform set of rights applies everywhere.