DPDP for Data Science and Analytics Teams: Working With Personal Data Responsibly

A single customer record in production can end up copied into a data warehouse, a BI dashboard extract, a notebook export, and a training dataset — each one a new location holding personal data, often with weaker access controls than the source system. From a DPDP perspective, every one of these copies is still 'personal data in your possession or control' under Section 8(5), regardless of how far it sits from the primary database.

The team most likely to notice this problem is the team causing it — data scientists and analysts are usually the ones who know exactly how many notebooks, exports and shadow tables exist, even when nobody else in the company does. That makes proactive inventory work from this team disproportionately valuable.

Before pulling a dataset for analysis, ask whether direct identifiers (name, email, phone, exact address) are actually needed for the analysis, or whether a pseudonymised key and aggregated fields would answer the same question. Building this as a default step — not an occasional best practice — reduces exposure across every downstream copy.

Where a research or statistical purpose is the actual goal, Section 17 provides a narrower path for processing carried out purely for research, archiving or statistical purposes where the data isn't used to make decisions about specific individuals — but this exemption is easy to lose the moment outputs get used to target or decide about individuals, so keep genuinely aggregate analysis separate from anything that folds back into individual-level decisioning.

If personal data is used to train a model — a recommendation engine, a churn predictor, a fraud score — that use needs to trace back to a lawful ground, and the resulting model's predictions about an individual are themselves a form of processing personal data about them. Don't treat 'it's just a training set' as outside the scope of the same obligations that apply to the source data.

Where a model's output affects an individual (a risk score that leads to account restriction, for instance), Section 8(3)'s accuracy expectations and the individual's correction rights under Section 12 are both relevant — there should be a route to challenge a decision that was driven by inaccurate underlying data.

Audit who has access to BI dashboards and raw export capability versus who actually needs it — broad 'everyone in analytics can query everything' access is convenient but hard to defend if a breach investigation asks who could have touched a given record.

Set expiry and cleanup habits for ad-hoc exports (CSV pulls, notebook checkpoints, shared spreadsheets) — these are exactly the copies most likely to be forgotten, and most likely to surface in a breach post-mortem months after anyone remembers why they were created.

Log warehouse tables, exports and model training datasets in the Personal Data Inventory, and use the Data Flow Mapper to trace how a single production record fans out across your analytics stack.