Data Classification and Discovery for DPDP in India

Data classification and discovery is the process of finding every place personal data lives across your databases, cloud storage, SaaS applications and employee endpoints, then sorting it into sensitivity tiers so you know exactly what you are protecting. Under India's Digital Personal Data Protection (DPDP) Act 2023, you cannot honour a data principal's right to access, correct or erase their information, and you cannot demonstrate "reasonable security safeguards" to a regulator, if you do not first know where that data sits, what it is, and who touches it. Classification and discovery are the foundation every other DPDP control is built on.

Why You Cannot Protect What You Have Not Inventoried

Most Indian businesses do not have a data problem — they have a data blindness problem. Personal data accumulates in CRM tools, support ticket systems, payroll spreadsheets, marketing platforms, backup buckets and laptops belonging to people who left the company two years ago. Nobody deliberately hides this data; it simply spreads faster than anyone tracks it.

This matters for DPDP compliance concretely. The Act obliges a Data Fiduciary to implement "reasonable security safeguards" against personal data breaches, to respond to data principal requests for access or erasure within a defined timeframe, and to notify the Data Protection Board and affected individuals when a breach occurs. Every one of those obligations assumes you already know where the data is. A consent-management workflow is meaningless if the customer's phone number also sits, unclassified, in a marketing export sheet nobody remembers creating. An erasure request cannot be fulfilled completely if a copy survives in an untracked backup or a departed employee's downloads folder.

Data classification and discovery converts an abstract compliance obligation into an operational checklist: scan every store, label what you find, and only then decide what protection, retention and access rules apply.

A Practical Four-Tier Classification Scheme

You do not need an elaborate fifteen-tier taxonomy to get value from classification. A simple, four-tier scheme that maps cleanly to DPDP's concept of personal data is enough to drive real decisions about access, encryption and retention.

Running Discovery Across Databases, Object Storage, SaaS and Endpoints

Discovery has to cover four distinct surfaces, because each one hides data differently.

Structured databases. Relational and NoSQL databases are the easiest starting point because schema and column names give strong hints. Automated scanners that pattern-match against PAN formats, phone numbers and Aadhaar-like sequences classify the bulk of structured data quickly, but validate a sample manually — columns like notes or remarks often contain free-text personal data that pattern matching misses.

Object storage and file shares. Cloud buckets and document repositories are where classification programmes usually fail first, because file content — PDFs, scanned KYC documents, exported spreadsheets — is unstructured and undocumented. Content-inspection scanning, reading inside files rather than trusting filenames, is essential here.

SaaS applications. CRM, helpdesk, HRMS, payroll and marketing tools each hold personal data outside your own infrastructure, often reached through OAuth-connected apps your security team never approved. Discovery here means enumerating every connected SaaS application, not just the ones IT officially provisioned.

Endpoints. Laptops accumulate exported spreadsheets, email attachments and local database dumps that never touch central monitoring — usually more copies of the same customer data than teams expect, and where "shadow" data with no clear owner lives longest.

Discovery is not a one-time project. New databases, SaaS tools and spreadsheets appear every week. A scan that runs once a year is stale by the time the report is presented; treat it as a recurring, automated process, not an annual audit.

Mapping Classification to Your Record of Processing

Classification tells you what data you hold and how sensitive it is. It becomes useful for DPDP compliance only when you connect each classified dataset to why you are processing it — the purpose, the legal basis, the source it came from, who inside the organisation can access it, and which third parties it is shared with.

This connective layer is often called a record of processing. For each significant dataset, a usable record answers: What is it? Which tier? Why do we hold it? Who consented, and when? Who can access it? Where does it flow, and how long do we keep it?

Building this record from a spreadsheet filled in once, disconnected from your actual data stores, decays within months as systems change. The more durable approach ties the record directly to your discovery output, so a newly found dataset gets classified and mapped to a purpose before it goes into production use — not months after a complaint or a regulator's inquiry forces the question.

Applying Controls, Retention and Feeding Rights Fulfilment

Once data is classified and mapped to a purpose, three things should happen automatically rather than being decided case by case.

Controls scale with tier. Restricted data gets encryption at rest and in transit, strict role-based access, and access logging reviewed on a fixed schedule. Confidential data gets lighter review; Internal and Public data need basic hygiene but not the same overhead — applying maximum controls everywhere is how security teams burn out and stop enforcing anything consistently.

Retention follows purpose, not habit. DPDP's purpose-limitation principle means data should not be kept indefinitely "just in case." Once the purpose is served and no other law requires retention, it should be deleted or anonymised on a defined schedule tied to its classification record — not left in storage because deleting it feels risky.

Rights fulfilment depends on both. When a customer exercises their right to access or erase data under the DPDP Act, your team needs to locate every copy fast enough to meet response obligations. That is only realistic if discovery already told you where the data lives — otherwise every request becomes a manual, error-prone search that risks missing a copy.

What a Typical Data Landscape Looks Like

Across most mid-sized organisations, the bulk of stored data is not the highly regulated core a compliance team worries about first — it is internal business content that has simply never been sorted. The illustrative distribution below reflects a pattern commonly observed during early-stage discovery exercises, before any deliberate classification or clean-up has happened.

The practical implication is that classification work is rarely about the Restricted tier alone. The Internal tier is usually the largest by volume and the least governed, which is exactly why it is where unclassified personal data hides in plain sight — inside exported reports, meeting notes and working files nobody labelled as containing personal information.

Common Mistakes That Undermine Classification Programmes

Treating classification as a one-time tagging project. A classification exercise done once and never repeated is accurate for a matter of weeks before new systems and exports make it stale.

Scoping discovery to production systems only. Staging, test, backup and archive environments routinely hold copies of production personal data with weaker controls, and are frequently excluded from scan scope entirely.

Classifying by system instead of by data. Labelling an entire database "Confidential" because it contains some personal data, without distinguishing sensitive fields from routine ones, forces maximum controls everywhere until teams quietly stop applying the scheme.

No named owner per dataset. Without a business owner accountable for a dataset's classification and purpose, the record decays the moment the person who built it moves teams.

Getting Started This Quarter

Start narrow and real rather than broad and theoretical. Pick your three highest-risk systems — typically the customer database, the primary CRM, and the object storage holding exported reports — and run a full discovery and classification pass on those first. Use the four-tier scheme, assign named owners, and connect the output to a processing-purpose record before expanding to the rest of the estate.

For organisations that also want to validate the technical controls sitting on top of classified data — exposed storage buckets, weak access restrictions, misconfigured databases — a free VAPT scan run through Bachao.AI's automated platform, built by Dhisattva AI Pvt Ltd and delivered with a CERT-In empanelled partner where formal empanelment is required, is a practical next step. Broader guidance on structuring a DPDP programme is available at /dpdp-compliance, and further reading is on the compliance blog.

Reference frameworks for classification, including the NIST approach to information categorisation, are documented at nist.gov. The current text of India's DPDP Act 2023 is published by the Ministry of Electronics and Information Technology at meity.gov.in, and CERT-In's incident advisories are at cert-in.org.in.