What a Data Subject Is: GDPR Definition, Rights, and Examples

If you have read a privacy policy or skimmed the text of the General Data Protection Regulation (GDPR), you have seen the term everywhere: a data subject is mentioned hundreds of times in the regulation, yet the law never stops to explain it in plain language. Understanding what a data subject is matters for any business that collects emails, runs analytics, or processes orders, because every legal duty in the GDPR is owed to these individuals. This guide explains the definition, who qualifies, the rights involved, and what your business needs to do about them. It is educational content rather than legal advice, so consult a qualified attorney for guidance specific to your situation.

What a Data Subject Is Under the GDPR

A data subject is an identified or identifiable living individual whose personal data is processed by an organization. The definition comes from Article 4(1) of the GDPR, which defines personal data as "any information relating to an identified or identifiable natural person ('data subject')."

Two elements of that definition do most of the work:

• Natural person: A data subject must be a human being. Companies, charities, and government bodies are "legal persons" and are not data subjects, even though information about them may be commercially sensitive.
• Identified or identifiable: The person does not need to be named. If someone can be singled out directly or indirectly through an identifier such as an email address, an IP address, a device ID, a location trace, or a combination of factors, they are identifiable and therefore a data subject.

The second point catches many businesses off guard. A visitor to your website whose behavior you track with an analytics cookie is a data subject, even if you never learn their name. Recital 30 of the GDPR explicitly lists online identifiers, including IP addresses and cookie identifiers, as data that can make a person identifiable. If you are unsure where the line sits, the related guide on what counts as personal data under GDPR breaks it down in detail.

One more boundary is worth knowing: Recital 27 states that the GDPR does not apply to deceased persons. Protection ends at death under EU law, although individual member states can, and some do, legislate their own rules for the data of the deceased.

Who Qualifies as a Data Subject: Everyday Examples

Almost everyone your business interacts with is a data subject in some context. Concrete examples make the definition easier to apply:

• Customers who create an account, place an order, or contact support.
• Website visitors tracked by analytics tools, advertising pixels, or session recording software.
• Newsletter subscribers whose email addresses sit in your marketing platform.
• Employees and job applicants whose HR files, CVs, and payroll records you hold.
• Business contacts such as a named procurement manager at a client company. The company is not a data subject, but the individual is.
• Children using your app or website. They are data subjects with extra protections: Article 8 of the GDPR requires parental consent for information society services offered to children under 16, though member states can lower this to 13.

Notice what is missing from the qualifying criteria: citizenship and residency. GDPR protection attaches to people who are in the EU when the processing occurs, per Article 3. An American tourist browsing your site from Berlin is protected. Conversely, an EU citizen living permanently in Texas generally is not, unless an EU establishment is doing the processing.

For a business outside Europe, this means the question is never "do we have European customers on file?" It is "do we offer goods or services to people in the EU, or monitor their behavior?" If the answer is yes, the individuals involved are data subjects and the GDPR applies to you regardless of where your servers or headquarters sit.

A Data Subject Is Not a Controller or Processor: Key Differences

The GDPR builds its entire structure on three roles, and confusing them is one of the most common compliance mistakes. The data subject holds rights. The other two roles carry obligations.

Role	Who it is	Core position under GDPR
Data subject	The living individual the data describes	Holds rights (access, erasure, objection, and more)
Data controller	The organization that decides why and how data is processed	Owes duties directly to data subjects (Articles 12 to 22, 24)
Data processor	A vendor processing data on the controller's instructions	Owes duties mainly to the controller (Article 28)

A practical example: an e-commerce store selling to EU customers is the controller of its customer data. Its email marketing platform and payment provider are processors. The shopper whose name, address, and order history flow through all three systems is the data subject.

The distinction matters because data subjects exercise their rights against the controller, not the processor. If a customer emails your email marketing vendor asking for deletion, the vendor's job under Article 28(3)(e) is to assist you, the controller, in fulfilling that request. The legal responsibility to respond remains yours.

One person can occupy different roles in different relationships. A freelance consultant is a controller for their own client list and simultaneously a data subject in the records of their accountant, their bank, and every online service they use.

The Rights Every Data Subject Can Exercise

Chapter 3 of the GDPR (Articles 12 to 23) grants data subjects eight enforceable rights. Any business acting as a controller must be able to honor each one:

1. Right to be informed (Articles 13 and 14): People must be told what data you collect, why, on what legal basis, who receives it, and how long you keep it. Your privacy policy is the primary vehicle for this.
2. Right of access (Article 15): A data subject can request a copy of their personal data and supporting details about the processing. This is commonly called a subject access request, and the mechanics are covered in the guide to handling a subject access request under GDPR.
3. Right to rectification (Article 16): Inaccurate or incomplete data must be corrected without undue delay.
4. Right to erasure (Article 17): Also known as the right to be forgotten. Deletion is required in defined circumstances, such as when the data is no longer needed or consent is withdrawn, though it is not absolute.
5. Right to restriction of processing (Article 18): The data subject can require you to pause processing while, for example, an accuracy dispute is resolved.
6. Right to data portability (Article 20): Data provided by the individual and processed by automated means under consent or contract must be supplied in a structured, commonly used, machine-readable format.
7. Right to object (Article 21): An absolute right to stop direct marketing, and a qualified right to object to processing based on legitimate interests.
8. Rights around automated decision-making (Article 22): Individuals can refuse to be subject to decisions with legal or similarly significant effects made solely by automated means, including profiling, subject to exceptions.

These rights are backed by real enforcement. Supervisory authorities such as the ICO in the UK, CNIL in France, and the DPC in Ireland can fine controllers up to 20 million EUR or 4% of global annual turnover under Article 83 for infringing data subject rights. For a deeper walkthrough of each right with practical response tips, see the companion article on GDPR data subject rights.

How to Handle a Data Subject Request

When a data subject exercises a right, GDPR sets strict procedural rules. Article 12 governs the process, and getting it wrong is itself a violation. A workable process looks like this:

1. Recognize the request. Requests do not need magic words or a specific form. "Send me everything you have on me" in a support chat is a valid subject access request. Train anyone who faces customers to spot and escalate these.
2. Verify identity proportionately. You may request additional information to confirm identity under Article 12(6), but only what is reasonably needed. Demanding a passport scan to unsubscribe someone from a newsletter is excessive.
3. Meet the one-month deadline. Article 12(3) gives you one month from receipt, extendable by two further months for complex or numerous requests. If you extend, you must tell the data subject why within the first month.
4. Respond free of charge. The first response must be free. Article 12(5) allows a reasonable fee or refusal only for manifestly unfounded or excessive requests, and you carry the burden of proving that.
5. Cover your processors. Instruct every vendor holding the person's data, such as your CRM, analytics, and email tools, to action deletions or corrections as well.
6. Document everything. Record the request, the verification steps, the response, and the date. Article 5(2) makes you accountable for demonstrating compliance.

Two edge cases deserve attention. First, third-party data: when fulfilling an access request, you must not disclose personal data of other individuals mixed into the same records, so redact accordingly. Second, backups: erasure obligations extend to backup systems, though regulators accept phased deletion where backups are overwritten on a defined cycle, provided the data is not restored to live systems.

Data Subjects Under Other Privacy Laws

The GDPR coined the term, but the concept of a protected individual appears in privacy laws worldwide under different names, sometimes with different boundaries:

• CCPA/CPRA (California): Uses the term "consumer," defined in Section 1798.140 as a California resident. Unlike the GDPR, protection follows residency rather than physical presence. Rights include knowing, deleting, correcting, and opting out of the sale or sharing of personal information, with fines of up to $2,500 per unintentional and $7,500 per intentional violation under Section 1798.155.
• UK GDPR and Data Protection Act 2018: Retains the term data subject with a definition mirroring the EU regulation, enforced by the ICO.
• LGPD (Brazil): Uses "titular," meaning the natural person to whom the personal data refers. The rights catalogue in Article 18 of the LGPD closely tracks the GDPR.
• PIPEDA (Canada): Refers simply to "individuals" and grants access and correction rights.
• POPIA (South Africa): Also uses "data subject," and notably extends the definition to include legal persons such as companies, a significant departure from the GDPR.

If you serve an international audience, you cannot assume one definition fits all. A practical approach is to identify the strictest regime that applies to your user base, usually the GDPR, build your processes to that standard, and then layer on jurisdiction-specific mechanics such as the CCPA's "Do Not Sell or Share My Personal Information" link.

What Data Subjects Mean for Your Privacy Policy

Every data subject right begins with the right to be informed, which makes your privacy policy the front door of compliance. Articles 13 and 14 of the GDPR prescribe exactly what data subjects must be told, and a policy missing these elements is non-compliant on its face:

• Your identity and contact details, plus your data protection officer's contact details if you have one.
• The purposes of processing and the legal basis for each purpose under Article 6.
• The recipients or categories of recipients of the data, including processors and third countries.
• Retention periods, or the criteria used to determine them.
• A description of each data subject right and how to exercise it, including the right to withdraw consent and the right to lodge a complaint with a supervisory authority.

Keeping this accurate over time is the hard part, because every new analytics tool, advertising pixel, or embedded widget changes what you collect and who receives it. Writing the document itself does not require a law firm for most small and medium businesses: a privacy policy generator can produce a policy covering GDPR and CCPA disclosure requirements based on your actual practices. Platforms like TermsBox pair this with a website scanner that detects the cookies and third-party services running on your site, so the disclosures reflect what your site really does rather than what you remember configuring.

Make the policy easy to find. Link it from your footer on every page, at account signup, at checkout, and anywhere else you collect personal data. Article 12(1) requires the information to be concise, transparent, intelligible, and in clear and plain language, so resist the urge to bury the disclosures in legalese.

Common Misconceptions About Data Subjects

A few persistent myths cause real compliance failures, so they are worth correcting directly:

• "We only have anonymous analytics, so we have no data subjects." True anonymization is rare. If you or your analytics vendor can single out a returning visitor via a cookie ID or IP address, that visitor is identifiable and is a data subject. Only irreversibly anonymized data falls outside the GDPR under Recital 26.
• "B2B data is exempt." There is no B2B exemption in the GDPR. The named individuals at your business customers, such as [email protected], are data subjects. Only truly generic addresses like [email protected] escape, and even then, caution is warranted.
• "Data subjects must pay or justify their requests." Neither is true. Requests are free by default, and a data subject never has to give a reason for exercising a right.
• "Small businesses are exempt." The GDPR has no revenue or headcount threshold for its core obligations. The limited small-business concession, in Article 30(5), only relaxes record-keeping for organizations with fewer than 250 employees, and even that falls away for regular or risky processing.
• "If we delete the account, we are done." Erasure covers all copies: CRM entries, email marketing lists, support tickets, logs, and processor systems. Deleting the login while retaining the marketing profile does not fulfill an Article 17 request.

Frequently Asked Questions

Is an employee a data subject?

Yes. Employees are data subjects because their employer processes their personal data, including names, salaries, performance reviews, and health records. GDPR obligations apply to employee data just as they apply to customer data, and employees can exercise all data subject rights against their employer.

Can a company be a data subject?

No. Under Article 4(1) of the GDPR, a data subject must be a natural person, meaning a living human being. Companies, charities, and public bodies are legal persons and have no data subject rights, although data about their individual employees or directors is still personal data.

What is the difference between a data subject and a data controller?

A data subject is the individual the personal data describes, while a data controller is the organization that decides why and how that data is processed. The controller owes legal duties under GDPR Articles 12 to 22, and the data subject holds the corresponding rights.

How long do I have to respond to a data subject request?

Article 12(3) of the GDPR requires you to respond within one month of receiving the request. You can extend this by two further months for complex or numerous requests, but you must inform the data subject of the extension and the reasons within the first month.

Are deceased people data subjects under GDPR?

No. Recital 27 of the GDPR states that the regulation does not apply to the personal data of deceased persons. However, individual EU member states may provide their own rules, and countries such as France and Denmark have enacted protections for deceased persons' data.

Do data subjects have to be EU citizens for GDPR to apply?

No. GDPR protection is based on location and context, not citizenship. Article 3 applies the regulation to anyone in the EU whose data is processed by an organization offering them goods or services or monitoring their behavior, regardless of their nationality or residency status.