What Is Personal Data?
LawSection 2 of the Act defines personal data as any data about an individual who is identifiable by or in relation to that data. That's a deliberately broad definition — it doesn't require the data to be sensitive, financial, or embarrassing to count; a first name attached to an email address is personal data in exactly the same technical sense as a bank account number.
What matters is identifiability, not the nature of the data itself. A device ID or a cookie identifier that can be linked back to a specific person — directly, or by combining it with other data you hold — is personal data. The same identifier, genuinely stripped of any way to reconnect it to an individual, generally isn't.
Digital Personal Data
LawDPDP's scope isn't "all personal data" — it's specifically digital personal data: data that's already in digital form, or non-digital personal data that's later digitised. This is a real, practical boundary, not a technicality. A handwritten customer feedback form that's filed away on paper and never scanned or entered into a system sits outside the Act's scope. The moment someone types those responses into a spreadsheet, that data becomes digital personal data and DPDP applies to it going forward.
Names, email addresses, and phone numbers stored in a CRM; IP addresses and device identifiers logged by a website; biometric data captured by an attendance system; location data from a mobile app; financial account details entered on a checkout page; browsing behaviour tied to a logged-in account; employee records held in an HR system.
Personal vs. Non-Personal Data
PracticeDPDP doesn't define "non-personal data" as its own regulated category the way some earlier draft Indian data-governance proposals did — it simply doesn't apply once data can no longer be tied back to an identifiable individual. The practical question is always the same: could this data, alone or combined with other data you hold, identify someone? Aggregated analytics ("14% of visitors used mobile") is typically non-personal. A dataset of individual browsing sessions with device fingerprints, even without a name attached, often isn't — device fingerprints are frequently re-identifiable.
Treating "we removed the name field" as equivalent to anonymisation. If a dataset still contains enough unique identifiers (device ID, precise location history, a rare combination of demographic fields) to single out one person, removing just the name doesn't take it out of scope — it's still personal data, just pseudonymised rather than anonymised.
Sensitive Information Considerations
LawThis is a genuine and easy-to-miss departure from both GDPR and India's earlier SPDI Rules, 2011, which each carry a defined "sensitive" or "special category" class (health data, financial information, biometrics, sexual orientation) with extra procedural requirements. DPDP doesn't create an equivalent category — every category of personal data is subject to the same baseline obligations under Sections 4 to 10. That doesn't mean sensitivity is irrelevant in practice: it's still good practice (Chapter 09, Data Security) to apply stronger safeguards to health or financial data than to a newsletter signup, even though the statute itself doesn't mandate a tiered approach.
Collection, Processing, and Sharing
These three activities — and storage and disclosure alongside them — are all forms of "processing" under the Act's broad definition, covering essentially any operation performed on personal data. Rather than repeat that ground here, Chapter 06, Data Processing covers the lawful grounds for each of these activities in depth.
Data Lifecycle
PracticeIt's useful to think of personal data moving through a lifecycle: collection → use → storage → sharing → retention → erasure. Most of DPDP's specific obligations attach to one or more stages of this lifecycle rather than to "personal data" as an undifferentiated whole — which is why later chapters are organised around these stages (Chapter 07 on locating your data, Chapter 08 on how long to keep it, Chapter 10 on what happens when something goes wrong with it) rather than repeating the same generic advice under each one.
Data Classification
PracticeClassifying the personal data you hold — by sensitivity, by the harm a breach of that specific category would cause, by which system it lives in — isn't a DPDP requirement in itself, but it's the practical foundation for nearly everything else in this guide. You can't apply proportionate security safeguards, set sensible retention periods, or scope a breach quickly if you don't already know which systems hold what. A simple three-tier scheme (e.g., standard / confidential / restricted) is usually enough to start with; the goal is a working reference your team actually uses, not an exhaustive taxonomy that goes stale.