Sensitive personal information is personal data that receives additional protection because of what it reveals or how it can be used. Health information, genetic data and identifying biometrics are common examples. The legal definition depends on the applicable law: GDPR special categories and CCPA sensitive personal information are different lists.
For website teams, the question extends beyond a customer database. Form answers, page addresses, search terms and advertising events can disclose sensitive information too. This guide explains the definitions and a practical way to review those flows. Legal references were reviewed on 19 September 2026.
Personal information versus sensitive personal information
Personal information can identify, relate to or be linked to a person, depending on the applicable definition. Sensitive information is a subset that attracts additional rules. A business can also classify information as confidential for security reasons without that information belonging to a statutory sensitive category.
An email address normally identifies a contact. Attach it to a medical diagnosis and the record also reveals health information. Conversely, a payment card number needs strong protection but is not automatically a GDPR special category.
Classification should consider the complete record, its context and the purpose of processing. The label on a database column is insufficient.
What counts under GDPR?
Article 9 of the EU GDPR covers data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs and trade union membership. It also covers genetic data, biometric data processed to uniquely identify someone, health data, and data about sex life or sexual orientation.
Processing generally requires both an Article 6 lawful basis and an applicable Article 9 condition. Explicit consent is one condition; others address matters such as employment obligations, legal claims and healthcare, with their own requirements. Legitimate interests alone does not satisfy Article 9.
Criminal convictions and offences are addressed separately by Article 10. Financial information and government identifiers are not automatically Article 9 data, although other safeguards and national rules can apply. A photograph is not automatically identifying biometric data simply because a face is visible. GDPR, Articles 4, 6, 9 and 10
The practical decision is therefore more specific than “get consent for sensitive data”. Identify the exact processing, the lawful basis and the additional condition, then check that its requirements are met.
What counts under CCPA and CPRA?
The CPRA amended the CCPA. California's current statutory definition includes:
- Social Security, driving licence, state identification card and passport numbers.
- Account login or financial account, debit card or credit card numbers combined with credentials that permit account access.
- Precise geolocation.
- Racial or ethnic origin, citizenship or immigration status, religious or philosophical beliefs, and union membership.
- Mail, email and text contents, unless the business is the intended recipient.
- Genetic data and neural data as defined in the statute.
- Biometrics processed to uniquely identify a consumer.
- Personal information collected and analysed concerning health, sex life or sexual orientation.
The definition has specific qualifications, including its statutory publicly available exclusion. It does not make all children's data sensitive solely because of age; separate protections can still apply. California Civil Code §1798.140(ae)
When is a “Limit the Use” option needed?
The CCPA right to limit applies to certain uses and disclosures beyond permitted purposes. Collecting sensitive information does not automatically require every business to display a limit link. Assess the purposes, the statutory exception for processing without the purpose of inferring characteristics, and the implementing regulations.
Where the right applies, the business must provide the required notice and method and make the limitation effective in its processing. This is distinct from opting out of sale or sharing. California Civil Code §1798.121
See our CCPA versus CPRA guide for the wider rights framework.
Examples: how the same data can be treated differently
These are illustrative classification questions, not findings about any particular company.
| Data or activity | What to check |
|---|---|
| A booking form containing a diagnosis | Health data can fall within GDPR special categories and California's sensitive definition. Check the purpose and applicable rules before sending it to another system. |
| A fingerprint template used to identify a customer | The identifying purpose matters to both GDPR and CCPA biometric classifications. |
| A bank account number with access credentials | California expressly covers the relevant combination. It is not automatically an Article 9 category under GDPR. |
| Precise coordinates attached to a device identifier | California expressly includes precise geolocation. Under GDPR, location can also reveal a special category through its context. |
| A mailing list identifying trade union members | An ordinary contact field becomes part of a record revealing union membership. |
| A preference for a website language | This alone does not automatically establish racial or ethnic origin. Assess any additional inference the business makes. |
A useful inventory records the applicable legal category alongside the business's security classification. Avoid a single “sensitive: yes/no” field with no explanation of which law it refers to.
Other US states: consent is not a universal permission
State definitions and obligations differ. Connecticut, for example, requires consent for covered processing of sensitive data and includes categories such as certain children's data, precise geolocation and consumer health data. Its current guidance also reflects expanded categories and applicability rules. Do not copy California's definition into every state's assessment. Connecticut Attorney General's CTDPA guidance
Maryland takes a different approach. Subject to the law's scope and exceptions, a controller may collect, process or share sensitive data only when strictly necessary to provide or maintain a specific product or service requested by the consumer. Selling sensitive data is prohibited. Obtaining consent does not turn that prohibition into permission. Maryland Attorney General's MODPA guidance
Separate health-data laws can apply outside traditional healthcare settings. Washington's My Health My Data Act addresses consumer health information beyond HIPAA's coverage and has its own collection, sharing and sale requirements. Washington Attorney General's health-data guidance
Use the US state privacy law tracker to identify the laws to examine before choosing controls.
Where website tracking can expose sensitive information
A website may disclose sensitive information without deliberately configuring a field called “health” or “religion”. Review these potential routes:
- URLs and page titles: a confirmation page can include a diagnosis, treatment or identifiable booking reference.
- Forms and site search: automatic event collection or session recording can capture answers and search terms.
- Advertising events: an event name or product identifier can reveal the nature of a sensitive service when tied to a person or device.
- Customer matching: a hashed email can still enable a recipient to match the event to a person.
- Server logs and forwarded events: moving collection to a server does not remove the information or its disclosure to another recipient.
These are review scenarios, not a rule that every page visit necessarily reveals sensitive data. Examine the payload, identifiability, destination and intended use together. Our server-side tracking guide explains the relevant data flows.
A cookie banner cannot by itself resolve unlawful collection or a prohibited sale. First remove unnecessary sensitive fields and destinations; then implement the legally appropriate permissions and restrictions for the processing that remains.
A practical sensitive-data review checklist
- Map the data. Include forms, CRM fields, URLs, event names, browser requests, server requests and logs.
- Classify each purpose. Record the applicable statutory category, affected people, jurisdiction and reason for the classification.
- Check permission and restrictions. Identify the lawful basis, additional condition, consent or limitation obligation, and any prohibition.
- Minimise collection. Remove fields and transfers that are unnecessary. Prefer an allowlist of permitted event fields over sending an entire form or page address.
- Assess recipients. Check actual use, contracts, onward disclosures and retention. A vendor's product label does not settle its legal role.
- Apply safeguards. Restrict access, protect data in transit and storage, set retention limits and document deletion procedures.
- Assess risk. Determine whether a GDPR DPIA or a state data protection assessment is required for the proposed processing. The relevant legal triggers matter.
- Verify with synthetic data. Inspect requests before and after choices, including server destinations, and repeat the check when the implementation changes.
For a consent and tracking implementation review, see our cookie consent implementation service. Resolve the permitted processing with the responsible privacy team before configuring tags around it.
FAQ
Is an email address sensitive personal information?
An email address is generally personal information, but it is not automatically a sensitive category. Its content or connection to other information can reveal health, religion or another protected characteristic. Assess the complete record and applicable law.
Is financial information special category data under GDPR?
Financial information is not automatically an Article 9 special category. It still needs appropriate protection under GDPR and other applicable rules. A transaction record can also reveal a special category through its context.
Does all sensitive data require explicit consent?
No. GDPR provides several Article 9 conditions, with explicit consent being one. US states use different combinations of consent, limitation rights, necessity restrictions and prohibitions. First identify the law, purpose and relevant condition.
Is hashed personal information anonymous?
Not automatically. If a hash can be matched, linked or otherwise used to identify someone, the information may remain personal data. Pseudonymisation reduces some risks but does not automatically remove privacy obligations.
Is publicly available sensitive data unrestricted?
No. GDPR's condition concerning data manifestly made public by the person is specific and does not displace other requirements. California has its own statutory publicly available exclusion. Finding information online is not sufficient to assume either test is met.
Can a cookie banner make health-related advertising lawful?
A banner alone cannot establish that. Assess the data, purpose, recipients, applicable law and any restrictions or prohibitions. Technical consent settings should implement that assessment, and must not send sensitive fields to destinations that should not receive them.
Related reading
-
Data controller versus data processor: who makes decisions and who acts on instructions.
-
US state privacy law tracker: effective dates and scope questions.
-
CCPA sale versus sharing: separate disclosure concepts and opt-outs.
-
GDPR and ePrivacy for websites: personal-data and device-access obligations.
