Personal Data vs Sensitive Personal Data: special categories and stricter duties

Every privacy law protects personal data, but each one draws its own line around a smaller set of sensitive data that carries stricter duties, and security teams that miss where the line falls apply the wrong controls. The EU and UK GDPR call it special category data, California's CPRA calls it sensitive personal information, and India's DPDP Act does not create a separate category at all. The lists differ, the legal tests differ and the operational consequences differ: an extra legal condition in one regime, an opt-out link in another, heavier scrutiny of volume and harm in a third. This guide compares personal data and sensitive personal data across the GDPR, the CPRA and the DPDP Act, maps what changes in controls when data crosses the line, and covers the inference risk that AI systems introduce. It is written for privacy engineers, security architects and data governance teams. The GDPR side is covered in depth in the Special Category Data Guide; this page is the cross-regime comparison. Status checked November 2026.

Key takeaways

• Sensitivity is defined by statute, not by intuition. Financial account numbers are sensitive under the CPRA but not special category data under the GDPR; trade union membership is sensitive under both.
• The GDPR adds a second legal gate. Special category data needs an Article 6 lawful basis and an Article 9 condition, and the ICO notes the two are chosen separately.
• The CPRA adds a consumer control, not a prohibition. Consumers can direct a business to limit use of sensitive personal information to what they would reasonably expect, which can require a "Limit the Use of My Sensitive Personal Information" link.
• Inference creates sensitive data. The Court of Justice held in C-184/20 that data indirectly revealing sexual orientation are special category data, so models and analytics that infer traits can move data across the line.
• Build one control tier for the union of lists. Classifying to the strictest applicable definition, then applying regime-specific legal steps on top, is simpler than running separate taxonomies.

The short answer

Personal data is the broad category. Under GDPR Article 4(1) it is any information relating to an identified or identifiable natural person; the CPRA's definition in Civil Code 1798.140(v) covers information that identifies, relates to, describes or is reasonably capable of being linked with a particular consumer or household; and the DPDP Act section 2(t) covers any data about an individual who is identifiable by or in relation to that data.

Sensitive personal data is a subset that each law singles out because misuse causes outsized harm: discrimination, physical danger, financial loss or loss of dignity. The practical difference is what the law makes you do once data is in the subset. Under the GDPR processing is prohibited unless an Article 9(2) condition applies. Under the CPRA processing is allowed, but the consumer gains a right to limit it. Under the DPDP Act there is no separate rule set, but volume and sensitivity can lead the Government to designate an organisation a Significant Data Fiduciary with extra obligations.

Definitions compared across regimes

The UK GDPR keeps the same Article 9 categories; the UK Data Protection Act 2018 adds the Schedule 1 conditions and, for many of them, an appropriate policy document. The GDPR also lets Member States add conditions or limits for genetic, biometric and health data under Article 9(4), so the EU position can vary by country.

What changes when data crosses the line

GDPR and UK GDPR: a prohibition with exceptions

Article 9(1) prohibits processing special category data unless one of the ten Article 9(2) conditions applies, from explicit consent (a) and employment and social protection law (b) through legal claims (f), substantial public interest (g), health and social care (h), public health (i) and research and statistics (j). The ICO's guidance is that you must identify an Article 6 lawful basis and an Article 9 condition, and that one does not determine the other. Consequences that follow for operations:

• DPIA triggers: the ICO lists processing special category data on a large scale, using it to decide access to a product, service, opportunity or benefit, and genetic or biometric data used for unique identification as cases where a DPIA is mandatory. See the DPIA Guide.
• Documentation: in the UK, the record of processing must name the condition relied on, and the employment and substantial public interest conditions usually need an appropriate policy document.
• Automated decisions: Article 22(4) bars decisions based solely on automated processing from using special category data unless Article 9(2)(a) or (g) applies and suitable safeguards are in place.
• Criminal data: Article 10 allows processing of criminal convictions and offences data only under official authority or where law authorises it with safeguards, so it needs its own handling path.

CPRA: a right to limit

The CPRA does not prohibit processing sensitive personal information. Under Civil Code 1798.121, a consumer may at any time direct a business to limit its use to what is necessary to provide the goods or services an average consumer would reasonably expect, plus certain listed purposes. After that direction, the business may not use or disclose the information for other purposes without later consent, and service providers and contractors with actual knowledge that the data is sensitive are bound too. A business using sensitive personal information beyond those purposes must provide a "Limit the Use of My Sensitive Personal Information" link under 1798.135, or a single combined link with the sale and sharing opt-out.

• The inference exception: 1798.121(d) excludes sensitive personal information collected or processed without the purpose of inferring characteristics about a consumer from the right to limit, though it remains personal information for every other section. Purpose therefore matters: the same field can carry different obligations depending on why you process it.
• Breach exposure: the private right of action in 1798.150 applies where certain nonencrypted and nonredacted personal information, or an email address with a password or security question and answer, is exposed through a failure of reasonable security, with statutory damages of $100 to $750 per consumer per incident or actual damages if greater. Several of those data types overlap the sensitive list, which is why account credentials need the strongest protection.
• Fines: up to $2,500 per violation and $7,500 per intentional violation or violation involving consumers known to be under 16, subject to inflation adjustment under 1798.199.95(d).
• Regulations: the CPPA's regulations on risk assessments and cybersecurity audits took effect on 1 January 2026. See the California CCPA Cybersecurity Audit and Risk Assessment Regulations Guide and the CCPA and CPRA guide.

DPDP Act: one tier, scaled by risk

The DPDP Act treats all digital personal data under one set of duties: consent or a section 7 legitimate use, reasonable security safeguards to prevent a personal data breach under section 8(5), and the rest of the fiduciary obligations. Sensitivity re-enters in two places. Section 10(1)(a) lists volume and sensitivity of the personal data processed as factors when the Government designates a Significant Data Fiduciary, and section 9 imposes specific duties for children's data. The Schedule sets penalties of up to 250 crore rupees for failing to take reasonable security safeguards. Operational detail sits in rules made under the Act, so confirm the current rules before relying on timelines. See the India DPDP Act Guide.

Control differences triggered by each tier

The legal steps above sit on top of security controls. The table shows the baseline for ordinary personal data and what changes for the sensitive tier, written so one control set satisfies all three regimes.

See the Data Classification Guide and the Pseudonymisation Techniques Guide for the techniques themselves.

Non-personal, pseudonymised and anonymised data

The other edge of the line matters as much. GDPR Recital 26 says data protection principles do not apply to anonymous information, but pseudonymised data, which under Article 4(5) can no longer be attributed to a person without additional information kept separately, is still personal data. Pseudonymising special category data reduces risk; it does not remove the Article 9 requirement. Under the CPRA, publicly available information is excluded from personal information altogether, though biometric information collected without the consumer's knowledge is not treated as publicly available. Teams that label a dataset "anonymous" because names were removed often still hold personal, and sometimes sensitive, data. See the Anonymisation and Re-identification Risk Guide.

AI and inference risk

Machine learning blurs the line because it can produce sensitive data from ordinary data. Purchase history can suggest pregnancy, location traces can suggest religious practice, and text or voice can suggest health conditions. Three legal hooks make this a live risk:

• GDPR, indirect revelation: in C-184/20 (OT, Grand Chamber, 1 August 2022) the Court of Justice held that publishing personal data that can indirectly reveal a person's sexual orientation is processing special category data. A model output or derived attribute that reveals a protected trait can bring a pipeline inside Article 9.
• GDPR, automated decisions: Article 22(4) limits solely automated decisions based on special category data, so a scoring model that uses inferred health or ethnicity faces a narrow path.
• CPRA, purpose: the 1798.121(d) exception depends on processing without the purpose of inferring characteristics. A model built to infer characteristics from sensitive inputs sits outside that exception.

Practical controls for AI pipelines:

1. Inventory model features and outputs and tag any that reveal or proxy a sensitive category.
2. Record the purpose of each training dataset, including whether it is used to infer characteristics.
3. Run a DPIA or CPRA risk assessment before training on, or producing, sensitive attributes.
4. Pseudonymise training data by default and restrict access to re-identification keys.
5. Test outputs for leakage of sensitive attributes, including through prompts to generative models.
6. Apply the sensitive-tier controls to derived data stores, not only to source systems.

Decision guidance

• Global organisations: classify to the union of the lists (GDPR special categories plus the CPRA's identifiers, credentials, geolocation, communications content and neural data), then apply regime-specific legal steps per data subject population. One taxonomy is cheaper to run than three.
• EU or UK only: treat government IDs, financial accounts and precise location as high-risk personal data even though they are not special category, because breach harm and notification exposure are high.
• US consumer-facing businesses: decide early whether any processing goes beyond the 1798.121(a) purposes. If it does not, you may avoid the limit link; if it does, design the limit control into the data platform, not only the website.
• India: do not wait for a sensitive tier that the Act does not create. Apply sensitive-tier controls to health, financial, biometric and children's data anyway, because volume and sensitivity drive Significant Data Fiduciary designation and breach penalties are severe.
• Small organisations: the simplest compliant design is not to collect sensitive data you do not need. See the Data Minimisation guide.

Implementation roadmap

1. Map: build or update the data inventory with category tags for each regime. See the Data Mapping and RoPA Guide.
2. Discover: scan structured and unstructured stores for sensitive identifiers and categories, including free-text fields, support tickets and email archives, which often hold health or immigration details.
3. Decide the legal path: for each sensitive processing activity, record the Article 9 condition or CPRA purpose and whether inference is a purpose.
4. Apply the tier: roll out encryption, access restriction and logging per the control table, piloting on one high-value store first and confirming applications still work before wider rollout.
5. Wire the rights: connect limit requests and consent withdrawal to the systems that use the data, and test end to end with sample requests.
6. Review: reassess when new models, data sources or jurisdictions are added; roll back a control change by restoring the previous access policy version if a business-critical process breaks, then fix and re-apply.

Worked scenario: one dataset, three answers

A wellness app with users in Germany, California and India collects step counts, precise location, a self-reported medical condition and a login. In Germany the medical condition is special category data, so the app needs explicit consent or another Article 9(2) condition alongside its Article 6 basis, and large-scale processing points to a mandatory DPIA. In California the medical condition (health information collected and analysed), the precise location and the account login are all sensitive personal information; if the app uses location for advertising beyond what users would reasonably expect, it needs the limit link and must flow limit requests to its advertising partners. In India none of the fields form a separate category, but every field needs consent or a legitimate use, reasonable safeguards, and, if any users are under 18, verifiable parental consent and no targeted advertising. One control tier (encrypted health and location fields, restricted access, read logging) serves all three; the legal paperwork differs.

Framework mapping

Common failure patterns

• One list for every regime: a GDPR-only taxonomy misses CPRA identifiers, credentials, location and message content, leaving them under baseline controls.
• Ignoring derived data: controls cover the source system but not the feature store or model outputs where inferred sensitive attributes live.
• Treating pseudonymised as anonymous: pseudonymised special category data is still special category data.
• Consent without the Article 9 step: collecting health data under a general consent or contract basis without the explicit consent or other Article 9 condition.
• Weak protection for genetic and health data: the 23andMe credential stuffing breach exposed genetic relationship data for millions of customers through reused passwords, and the ICO fined the company £2.31 million in June 2025.
• Limit requests that stop at the website: the preference is stored but never reaches the analytics and advertising systems or the service providers that must honour it.

Detection and measurement

• Sensitive data coverage: percentage of data stores scanned and tagged with regime-specific categories.
• Unprotected sensitive fields: count of sensitive columns or files without encryption or tokenisation, trending to zero.
• Access breadth: number of identities with read access to sensitive stores, and percentage certified in the last review cycle.
• Bulk access alerts: volume of unusual exports or queries on sensitive data, with time to triage.
• Rights fulfilment: median days to honour limit requests and consent withdrawals across all downstream systems.
• Assessment coverage: share of sensitive processing activities with a current DPIA or risk assessment.

Practitioner checklist

• Publish one sensitive data taxonomy covering GDPR Article 9, Article 10 and CPRA 1798.140(ae).
• Record the Article 9 condition and Article 6 basis separately for each special category activity.
• Decide whether any processing goes beyond the CPRA permitted purposes and, if so, implement the limit control end to end.
• Tag model features and outputs that reveal or proxy sensitive traits.
• Encrypt or tokenise sensitive fields and separate key custody.
• Restrict and certify access to sensitive stores at least quarterly.
• Log and alert on bulk reads and exports of sensitive data.
• Apply sensitive-tier controls to health, financial, biometric and children's data in India despite the single-tier Act.

Standards and references

• GDPR: Article 9 Processing of special categories of personal data
• GDPR: Article 4 Definitions
• Court of Justice of the EU: Case C-184/20 OT v Vyriausioji tarnybinės etikos komisija
• California Privacy Protection Agency: California Consumer Privacy Act statute
• California Privacy Protection Agency: CCPA updates, cybersecurity audits, risk assessments and ADMT regulations
• Ministry of Electronics and IT, India: Digital Personal Data Protection Act 2023
• ICO: What are the rules on special category data?
• GDPR: Article 22 Automated individual decision-making

Related NHI Mgmt Group resources: Special Category Data Guide · CCPA and CPRA · GDPR vs CCPA/CPRA · India DPDP Act Guide · DPIA Guide. This guide summarises the personal data and sensitive data definitions in the GDPR, CPRA and DPDP Act and is not legal advice.