Data Classification Requirements Under New Privacy Laws

📌 When Privacy Gets Personal: How GDPR and CCPA view Sensitive Data You’ve mapped out your privacy obligations. But do you know what kind of personal data you’re dealing with? Some data is more… sensitive. Let’s break it down 👇 🇪🇺 GDPR 🔬 Special Categories of Personal Data Clearly defined under Article 9, including: • Health data • Ethnic origin • Biometric and genetic data • Political opinions, trade union membership • Sexual orientation, religious beliefs, etc. 🔐 Requires stronger safeguards Typically needs explicit consent — or must fall under narrow legal exceptions (e.g., public health, employment, legal claims). ⚖️ Risk-based & contextual Processing can trigger DPIAs, stricter contracts, and regulatory scrutiny. 🧪 Example: An employer installs facial recognition to control building access. Since this involves biometric data, it's classed as special category data under GDPR — requiring explicit consent or a valid legal justification. 💡 Bottom Line: Clear definitions. High thresholds. Built-in guardrails. 🇺🇸 CCPA/CPRA 🧩 “Sensitive Personal Information” (SPI) Introduced under CCPA, and more broadly framed: • Social Security Number (SSN) • Precise geolocation • Financial account + login info • Ethnic origin, religion, union membership • Contents of messages, biometric info, etc. 🚪 Consumers can limit its use/disclosure Businesses must offer a “Limit the Use of My Sensitive Personal Information” link in applicable cases. ⚠️ No explicit consent required Unlike GDPR, CCPA doesn’t require a separate legal basis — it’s more about giving consumers control. 🧪 Example: A company uses facial recognition for identity verification in its services. If that involves a California resident, the business must provide an option to limit the use of this biometric data — or risk non-compliance. 💡 Bottom Line: CCPA treats SPI like a “do-not-track” toggle — not a hard stop. 🎯 The Core Difference GDPR → “Some data is off-limits unless you can strongly justify it.” CCPA → “Use it if you must — but give consumers a way to opt out.” 🌍 What This Says About Privacy Culture 🇪🇺 GDPR: Protection through restriction 🇺🇸 CCPA: Protection through empowerment Same data — different sensitivities. #DataPrivacy #PrivacyLaw #GDPR #CCPA #BiometricData #SensitiveData #DataProtection #Compliance #CIPPE #CIPPUS #LegalTech #InfoSec #LinkedinLearning

Understanding Personal Data, Indonesia’s UU PDP vs. the EU GDPR Many organizations still question what qualifies as personal data under the Personal Data Protection Law. Some assume that collecting names or employee data like ID numbers doesn’t count, hoping to avoid compliance. However, the law defines personal data broadly, any information that can identify a person, directly or indirectly, is covered. This includes names, contact details, employment records, and even online identifiers. PDP Law also distinguishes specific personal data, which requires stricter protection due to its sensitive nature. This includes health records, biometrics, financial information, and criminal history. Interestingly, different jurisdictions classify sensitive data differently. The EU’s GDPR considers sexual orientation, religious beliefs, and political views as sensitive due to their potential for discrimination. In contrast, Indonesia mandates religion in official documents but does not categorize sexual orientation as sensitive, reflecting cultural and legal differences. Beyond classification, UU PDP and GDPR take different regulatory approaches. Under GDPR, processing special category data is strictly restricted unless a company meets specific legal justifications, such as explicit consent or legal obligations. Meanwhile, Indonesia’s UU PDP does not explicitly restrict processing sensitive data but automatically considers it high-risk, requiring a Data Protection Impact Assessment (DPIA) to evaluate risks and mitigation measures. Here is a table of the differences between special category data in Indonesian PDP law and GDPR

October comes next week, and so do new privacy requirements in three states. Here's a recap and what to check ⤵️ 1️⃣ Colorado Privacy Act amendments related to minors' personal data will: 🔸impose obligations where a controller knows or willfully disregards that a user is a minor; 🔸require opt-in consent to sell or use a minor's personal data for targeted advertising, or to use system design features to increase engagement; 🔸limit how precise geolocation data of minors can be processed; and 🔸mandate data protection assessments in additional contexts. Rulemaking is underway to provide further clarity on these new requirements, including to specify when a data controller "willfully disregards" that a user is a minor and what system design features increase engagement. See the draft regulations here: https://lnkd.in/gcBtzyTi 2️⃣ Montana privacy law amendments that: 🔸lower the law's threshold for applicability; 🔸remove the general non-profit exemption; 🔸add privacy policy content requirements; 🔸require sale and targeted advertising opt-out links outside the privacy policy; and 🔸remove the right to cure violations. 3️⃣Maryland's Online Data Privacy Act takes effect. It has a low bar for applicability, and unique or less common requirements like: 🔸prohibiting processing of sensitive personal data unless it is strictly necessary to provide or maintain a consumer-requested product or service; 🔸forbidding collection of personal data unless it is reasonably necessary and proportionate to provide or maintain a consumer-requested product or service; 🔸banning sales of personal data of minors, and processing of their personal data for #TargetedAdvertising; 🔸broad data deletion right unless retention is required by law (though other provisions may give some flexibility); 🔸privacy policy requirements including to disclose the type of, business model of, or processing conducted by each third party to which personal data is disclosed; and 🔸consumer health data requirements.   If you haven't already, identify which of these laws apply to your organization, and see if your current privacy practices address what's required. Consider especially: ✔️ How your organization identifies accounts, profiles, and personal data of minors, and treats them in line with Colorado's, Maryland's, and other states' increasingly complex requirements 💡 Validate that there are processes to address parental reports, app store provided age information, and other reports and signals that a data subject is a minor; ✔️ Data collection and use limits to address Maryland's strict data minimization requirements, particularly for sensitive personal data 💡 Updates may be appropriate in #privacy impact assessment processes, organizational policies, and organizational privacy training; ✔️ Confirming your organization's privacy policy has the third party details required under the Maryland law.

The Data Protection Pyramid: Why Special Category Data (SCD) Sits at the Top (and the Problem with “Sensitive Data”) For effective data governance, we need to stop relying on the vague term “Sensitive Data” and start thinking in clear, legally grounded layers. In a previous post, I explained why under GDPR and UK GDPR, using “Sensitive Data” interchangeably with Special Category Data (SCD) is not just imprecise, but risky. It often leads organisations to misunderstand the legal requirements that apply to the data they process. Building on that, let’s move away from labels and look at this properly, as a Data Protection Pyramid. At the top of this pyramid, requiring the highest level of care and justification, sits Special Category Data (SCD). The 3-Layer Data Protection Pyramid 1. Base Layer: Personal Data (PD) What it is: Any information that can identify an individual, names, email addresses, phone numbers, IP addresses, or location data. Analogy: Think of this as your house key. You protect it, but you may share it with trusted parties when necessary. Legal requirement: You need one lawful basis under Article 6 of GDPR to process it. 2. Middle Layer: Highly Confidential Data What it is: Data that could cause serious financial or reputational harm if compromised, even though it is not classified as Special Category Data under the law. Examples include bank account details, credit card numbers, and commercially sensitive information. Analogy: This is your bank PIN, access is tightly controlled because the risk is high. Legal focus: Strong technical and organisational measures, such as encryption and strict access controls, are essential. 3. Top Layer: Special Category Data (SCD) What it is: Data that reveals deeply personal aspects of an individual, including: - Racial or ethnic origin - Political opinions - Religious or philosophical beliefs - Health data - Biometric or genetic data used for identification - Sex life or sexual orientation - Trade union membership Analogy: This is the blueprint of a person’s life. Misuse or exposure can result in discrimination, social harm, or loss of fundamental rights. Legal requirement: Processing requires two separate justifications: - A lawful basis under Article 6 and - A valid condition under Article 9 (such as explicit consent or vital interests). Key Takeaways All Special Category Data is Personal Data, but not all Personal Data is Special Category Data. Terms like “Sensitive,” “Restricted,” or “Highly Confidential” are useful for internal security and data classification policies, but they do not replace the legal definition of Special Category Data, nor do they trigger Article 9 requirements on their own. Which layer does your organisation deal with most today? Share your thoughts in the comments 👇 #DataProtection #GDPR #Privacy #SpecialCategoryData #DataGovernance #Compliance

Privacy programs that scale are not built around static compliance tasks. They are built to produce evidence by design, grounded in principles that drive consistent decision-making. That evidence is what creates confidence in data practices as regulatory requirements become more operationally specific. The latest CCPA regulations illustrate why this matters. The updated regulations, effective January 1, 2026, are not incremental. Programs built as one-time or check-the-box implementations will find it more difficult to adapt over time, while programs grounded in principles, controls, and continuous regulatory awareness are better positioned to manage change without reactivity becoming the default operating model. If you joined my recent Fireside Chat, these themes will sound familiar. Below are several updates and what they mean for evolving privacy programs. Part 1: Sensitive Personal Information Definition Expanded Personal information of consumers under 16 is now classified as Sensitive Personal Information where the business has actual knowledge of the consumer’s age. Willful disregard of a consumer’s age is deemed actual knowledge. Operational: Update your Privacy Risk Assessments policy and process, Right to Limit processing workflows (including downstream), and update data classification logic and practices. Opt-Out Confirmation will be Mandatory Providing confirmation that an opt-out request has been honored will no longer be optional, including for requests submitted through Global Privacy Control (GPC). Examples include displaying “Opt-Out Request Honored” on a website or using toggles or radio buttons in consumer privacy settings to reflect opt-out status. Operational: Test GPC functionality and review consent manager and cookie banner configurations. Right to Know Scope Expanded Currently, businesses must provide a method for consumers to submit a right to know request. Under the updated regulations, if a business retains personal information for longer than 12 months, that method must allow consumers to request access to personal information collected prior to the 12-month period preceding the request, going back as far as January 1, 2022. Consumers may be given the option to specify a date range for their request or request all personal information the business has collected about them. Operational: Review record retention policies, data maps, understand where you store collection dates, and update data subject rights intake forms and procedures. In upcoming posts, I’ll continue examining the remaining requirements and what they mean in practice.