India's Data Protection Law: What Analysts Must Design For in Interviews
Before India’s new data protection regime, many analytics teams behaved as if customer data was a warehouse - collect everything, keep it forever, use it later. The DPDP Act changes that mental model: personal data is now closer to borrowed property, usable only for a clear purpose, with accountability attached.
- India’s Digital Personal Data Protection Act, 2023 governs digital personal data processed in India, and some processing outside India linked to offering goods or services in India.
- For analysts, the core question is not “Can we get the data?” It is “Do we have a lawful purpose, valid consent or legitimate use, minimum fields, retention logic and audit trail?”
- The key roles are Data Principal - the individual, Data Fiduciary - the organisation deciding purpose and means, and Data Processor - the vendor processing for the fiduciary.
- Consent must be specific, informed, unambiguous and revocable; analysts must design consent tags into datasets, not treat consent as only a legal-page checkbox.
- Purpose limitation means a dataset collected for one reason should not be freely reused for another, especially for targeting, credit scoring, insurance or profiling.
- Retention must be designed upfront: delete or anonymise personal data when the purpose is complete or consent is withdrawn, unless a lawful requirement says otherwise.
- The biggest interview win is to answer like a product-risk thinker: map data flow, identify personal data, state lawful basis, minimise fields, add controls, measure compliance.
The Big Picture: Privacy Is Now a Design Constraint, Not a Legal Appendix
A DPDP-ready analyst does not wait for the legal team after the dashboard is built. They design the data product so every personal data point has a reason to exist, a permission path, a safe processing method, a deletion rule and evidence if questioned.
Core Explanation: What Analysts Must Actually Design For
The DPDP Act is not a “privacy policy law” alone. It changes how personal data should be collected, tagged, joined, modelled, shared and deleted. For analysts, the law becomes practical in five design questions.
The DPDP Role Map
Most candidates confuse the parties. Think of it like this: the individual owns the rights, the company deciding why data is used carries the main obligation, and vendors act under contract.
Old Analytics Habit vs DPDP-Ready Analytics
The sharpest way to understand the shift is through a before-after comparison. Old analytics maximised data availability. DPDP-ready analytics maximises usable, justified and governable data.
The Six Controls an Analyst Should Build Into Any Personal-Data Use Case
Privacy Metrics Analysts Should Track
Privacy cannot be managed only through policies. A mature analytics team uses operational metrics that show whether data is actually governed.
Definitions You Must Be Able to Say Cleanly
- Personal data: “any data about an individual who is identifiable by or in relation to such data.”
- Data Principal: the individual to whom the personal data relates.
- Data Fiduciary: a person who determines the purpose and means of processing personal data.
- Data Processor: a person who processes personal data on behalf of a Data Fiduciary.
- Processing: an automated operation on digital personal data, including collection, storage, use, sharing or erasure.
Two notes make your answer sharper. First, the DPDP Act uses the term fiduciary, not controller, to emphasise responsibility. Second, unlike some earlier Indian draft bills, the Act does not create a separate “sensitive personal data” category, but analysts should still treat health, financial, children’s, biometric and location data as high-risk in practice.
Case Study: Star Health and the Analyst’s Lesson from Health Data Risk
Star Health shows why analysts working with high-trust data must design for access control, minimisation, monitoring and breach response before analytics scale.
In 2024, Reuters reported allegations that customer data linked to Star Health, one of India’s major health insurers, had been exposed through online channels including Telegram chatbots. The company said it was investigating and had reported the matter to authorities. Regardless of final legal findings, the episode is a powerful analytics lesson because health insurance data is especially trust-sensitive: it can combine identity, policy details, claims history and medical context.
The primary risk driver was the nature of the data itself: health and insurance records are high-impact if exposed. Supporting drivers in such ecosystems typically include distributed access across employees, agents, hospitals, third-party administrators, cloud tools and support workflows. That is exactly why analysts must not design dashboards or models as if data is sitting inside one neat database.
So what: the lesson is not “never use health data.” The lesson is that high-value analytics requires high-control design: minimise before modelling, restrict before sharing, monitor before breach, and delete before data becomes permanent liability.
How AI Changes India’s Data Protection Law Design
AI makes the DPDP challenge more important because models consume data at scale, create derived features and can reveal patterns even when direct identifiers are removed.
- AI increases data lineage pressure. A model feature may combine app activity, transaction history, location proxy and support-ticket text. Analysts must document where each feature came from, why it was used and whether the original consent or legitimate use covers that modelling purpose.
- AI pushes privacy-enhancing techniques into mainstream analytics. Tokenisation, pseudonymisation, aggregation, differential privacy, synthetic data and federated learning are no longer theoretical. They help reduce exposure, though they do not automatically remove all DPDP obligations if re-identification remains possible.
- AI changes breach and rights operations. LLM-based tools can classify data-principal requests, flag risky datasets, detect unusual access and summarise incident timelines. The caveat: these tools themselves must not receive unnecessary personal data or leak it into external systems.
Load a company privacy policy, its annual report and this lesson into NotebookLM. Ask: “List the personal-data use cases, likely DPDP risks, consent gaps, retention questions and interview questions an analyst may face.” Then convert the output into a 5-point answer structure.
Interview Relevance
“Suppose you are building a customer churn model for an Indian fintech. What would you design for under India’s data protection law?”
Use the phrase “purpose-data-control-retention map.” It signals that you understand privacy as an operating design, not a legal disclaimer.
Common Mistake
The mistake: saying “we will take consent” and stopping there. It costs candidates because consent alone does not solve purpose creep, over-collection, vendor access, breach risk, retention or rights handling. One-line fix: answer with the full chain - purpose, lawful basis, minimisation, access control, processor governance, retention and audit trail.
What to Revise Next
Now move from the law to the two analyst skills that make it real in data products: how consent and retention work operationally, and how models can create unfair outcomes even without using protected labels directly.