DPDP 3.5.1: DPDP and Data Analytics

INTRODUCTION

Data analytics and DPDP compliance may appear to be an unlikely pairing. One is a business tool. The other is a legal framework. Yet they collide precisely because analytics, at its most powerful, is built on personal data — and the DPDP Act, 2023 governs every piece of it.

IS Audit 3.0 study material by ICAI defines data analytics as the science of examining raw and unprocessed data with the intention of drawing conclusions from the information thus derived. At its simplest level, descriptive analytics tells us what happened. Diagnostic analytics explains why it happened. Predictive analytics forecasts what may happen next. Prescriptive analytics recommends what should be done. Cognitive analytics — the highest tier — uses Big Data and artificial intelligence to recognise patterns and take proactive action.

Each tier of this evolution processes more personal data, draws more intimate inferences, and creates more consequential outputs for the individuals at the centre of that data. By the time an organisation is running predictive or cognitive analytics at scale, it is not merely analysing data. It is constructing detailed models of human behaviour — including patterns the individual herself may not be aware of. The Puttaswamy judgment (2018) confronted precisely this reality when it held that data mining and knowledge discovery processes can create new knowledge about individuals, including facts that even those individuals did not possess about themselves.

The DPDP Act does not prohibit analytics. However, it requires that every stage of the analytics pipeline — from data collection to model output to decision-making — be governed by a lawful basis, a specific purpose, and a respect for Data Principal rights. Three stories show exactly where that governance breaks down in practice, and what responsible Data analytics and DPDP compliance looks like.

Story 1 — Devika’s Loan Application and the Score That Came From Nowhere

The Scenario

Devika is a 33-year-old chartered accountant in practice who applied for a personal loan from a digital lending platform. Her credit profile was clean. Her income was verifiable and above the threshold. Nevertheless, the platform’s system rejected her application within seconds, flagging her as a high-risk borrower.

Devika asked for a reason. The lender’s customer service team explained that an internal risk model had assessed her application and that a detailed explanation could not be provided. She then invoked her right to know what personal data the platform held about her and how it was being processed. The platform sent her a generic response listing basic data categories — name, income, PAN — but made no mention of the behavioural and transactional data from third-party sources that the model had actually used.

Devika had been profiled based on data she had not provided and had never been informed about.

The DPDP Act Position

Three distinct compliance failures arise from Devika’s situation.

First — Absence of notice for third-party data under Section 5. Section 5(1) of the DPDP Act requires that every request for consent be accompanied or preceded by a notice informing the Data Principal of the personal data to be processed and the purpose for which it will be processed. Rule 3 of the DPDP Rules reinforces this: the notice must give an itemised description of the personal data, including its source. When the lender ingested Devika’s behavioural data from third-party platforms without disclosing this as a data source in its notice, it failed this obligation entirely.

Data analytics pipelines routinely pull data from multiple external sources — credit bureaux, social media signals, transaction aggregators, app usage patterns, telecom data partners. Every one of these data categories must be disclosed, itemised, and tied to a specific processing purpose in the notice. A generic privacy policy that refers to “data from third parties” does not satisfy this standard.

Second — Processing beyond the stated purpose under Section 6(1). Devika’s consent, to the extent it was obtained, covered the processing of her application data for a lending decision. Behavioural profiling using third-party data analytics is a materially different processing activity. Section 6(1) limits consent to the personal data that is necessary for the specified purpose. Conducting wide-scope predictive profiling on data not covered by the stated purpose, and not disclosed in the notice, has no lawful consent basis.

Third — Right to access information violated under Section 11(1). Section 11(1) of the DPDP Act gives every Data Principal the right to obtain from the Data Fiduciary a summary of personal data being processed, a description of processing activities, and the identities of all Data Fiduciaries and Data Processors with whom her personal data has been shared. The platform’s generic response — listing only basic data categories — is an inadequate discharge of this obligation. Devika had a statutory right to know that third-party data was feeding the model that rejected her. She was denied that right.

The IS Audit 3.0 and Puttaswamy Perspective

IS Audit 3.0 material by ICAI explicitly identifies data privacy and confidentiality as a primary risk of deploying data analytics, noting that the copying and storage of client data risks breach of confidentiality and data protection laws. In an analytics context, this risk is not limited to the data that is explicitly collected — it extends to every data source the analytics model ingests, however indirectly.

The Puttaswamy judgment (2018) is even more direct. Justice Kaul’s concurring opinion described profiling — the use of personal data to evaluate a person’s performance, economic situation, health, personal preferences, reliability, behaviour, or movements — as a fundamental privacy concern, and warned that proprietary algorithms used to make consequential decisions about individuals can, if biased or unaccountable, produce discrimination based on religion, ethnicity, caste, or gender. This concern is not hypothetical in India’s digital lending sector. It is a live compliance and human rights risk.

The Compliance Fix

Digital lenders and any organisation using predictive analytics for individual decisions must:

→ Issue a Rule 3-compliant notice that itemises every data source used in the analytics model — including third-party data providers, their categories, and the specific purpose for which each is used.

→ Limit data ingestion to what is necessary for the stated lending purpose. Section 6(1) applies to every data point in the analytics pipeline, not just the primary application form.

→ Maintain a Data Processor register of every analytics partner or data provider, with contracts under Section 8(2) that specify permitted data uses.

→ Build a meaningful Section 11 response mechanism — one that can accurately answer a Data Principal’s question about what data sources contributed to a decision about her.

→ Where predictive analytics is used for credit, insurance, or employment decisions, conduct a DPIA under Section 10 to assess algorithmic risk to Data Principal rights before deployment.

Devika’s loan was rejected by a model she could not question, fed by data she did not know existed. Under the DPDP Act, that outcome has a name. It is a compliance failure.

Four things digital lenders using predictive analytics must do now:

→ Issue Rule 3-compliant notices that itemise every third-party data source feeding the lending model.

→ Build a meaningful Section 11 response capability — one that can accurately identify which data sources contributed to a specific decision.

→ Limit data ingestion to what is necessary for the stated lending purpose under Section 6(1).

→ Conduct a DPIA under Rule 13 of the DPDP Rules before deploying or updating predictive models used for credit decisions.

The DPDP Act does not permit algorithmic opacity when personal data drives consequential decisions.

Disclaimer

The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.

The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.

Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.

The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.


Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.

DPDP 3.5.1: DPDP and Data Analytics

DPDP 3.4.3: DPDP and Internet of Things (IoT) – Case Study 3 – Lakshmi’s Smart Home and the Data That Left the House

The Scenario

Lakshmi is a homemaker in Bengaluru. Her family uses a suite of smart home devices — a connected doorbell with a camera, a voice-activated home assistant, smart lighting controlled by an app, and a connected refrigerator that tracks grocery inventory. All devices were purchased from different manufacturers, each with its own app and privacy policy.

Over time, Lakshmi realised that advertisements on her phone were displaying products she had discussed verbally at home and items she had added to her refrigerator’s shopping list. She had never consciously consented to any of this data leaving her home and being used for targeted advertising. She also had no single point of contact to understand what data was being collected, by whom, or how to stop it.

When she attempted to delete her data from one manufacturer’s platform, she received a response that her data had been shared with “technology partners” and could not be fully recalled.

The DPDP Act Position

Lakshmi’s situation illustrates the most complex IoT-DPDP compliance scenario: the multi-vendor smart home, where data collected by one device travels through multiple Data Fiduciaries and Data Processors, none of whom have a co-ordinated compliance architecture.

First — Consent fragmentation failure. Each device manufacturer that collects personal data within Lakshmi’s home is a Data Fiduciary. Each must independently satisfy Section 5 (notice) and Section 6(1) (specific, informed, free consent). A bundled privacy policy buried in a device setup wizard does not constitute the clear, plain-language, itemised consent notice required by Rule 3 of the DPDP Rules. Moreover, oral conversations captured by a voice assistant constitute personal data under Section 2(t) of the Act — any data about an individual who is identifiable by or in relation to such data. Capturing and processing these without specific, affirmative consent is unlawful.

Second — Data sharing with technology partners as undisclosed processing. When a Data Fiduciary shares personal data with a third-party technology partner for advertising targeting, that third party is either a Data Processor or a separate Data Fiduciary. Under Section 8(2), if it is a Data Processor, the original Data Fiduciary must ensure it processes data only for the specified purpose. If the specified purpose was “device functionality” and the actual use is “advertising targeting,” the sharing is unlawful — regardless of what the fine print says.

Third — Structural inability to respond to erasure requests. Section 12(3) of the DPDP Act requires the Data Fiduciary to erase personal data on request. When the Data Fiduciary has already shared data with technology partners — who are now using it independently — the original Data Fiduciary cannot honour this obligation without binding downstream agreements that require cascading deletion. The absence of such agreements is a compliance failure at the architecture stage, not a technical impossibility.

Fourth — Children’s data risk. If Lakshmi’s home includes minor children who interact with voice assistants or other smart devices, Section 9 of the DPDP Act applies. Processing personal data of a child requires verifiable parental consent. A voice assistant that captures a child’s voice — identifiable personal data — without verifiable parental consent is in direct violation. The penalty for breach of Section 9 obligations extends to ₹150 crore under the Schedule to the Act.

The IS Audit Perspective

IS Audit 3.0 by ICAI is explicit: IoT privacy risk arises because objects within the IoT collect and aggregate fragments of data that relate to their service, and that individually innocuous data points combine to reveal sensitive attributes. Lakshmi’s scenario is the textbook illustration of this risk at the consumer level.

The Puttaswamy judgment (2018) directly anticipated this concern, observing that IoT and data mining processes together can create new knowledge about individuals — something even the individuals themselves did not possess. The court noted that this is an age of “ubiquitous dataveillance,” where users of wearable devices and smart home technology generate vast data about lifestyles, choices, and preferences without conceiving of themselves as having volunteered that data. Indian law now governs that data.

The Compliance Fix

Smart home device manufacturers and platform operators selling to Indian consumers must:

→ Provide a separate, device-specific consent notice in clear and plain language — not a buried privacy policy — before any data collection begins. Rule 3 of the DPDP Rules applies to every device sold in India that collects personal data. → Identify and disclose every “technology partner” as a named Data Processor or co-Data Fiduciary in the consent notice, along with a specific description of what data they receive and for what purpose. → Build cascading deletion mechanisms so that an erasure request to the primary Data Fiduciary propagates to all downstream Data Processors. → Implement verifiable parental consent mechanisms under Section 9 before any smart home device capable of collecting children’s data is activated in a household. → Apply transport-level encryption across all device-to-cloud data flows — IS Audit 3.0 (Section 6.5.6) identifies the lack of transport encryption as a primary IoT risk.

Lakshmi’s home was smart. Its manufacturers were not compliant.


The Central Compliance Question for IoT Deployments

The IoT-DPDP compliance challenge is, at its core, a consent architecture problem. IoT devices are designed to collect continuously, silently, and at scale. The DPDP Act requires consent to be specific, informed, and granular. These two imperatives pull in opposite directions — and organisations that do not resolve this tension before deployment will face it as an enforcement problem after 13 May 2027.

There are five questions every organisation must answer before deploying IoT systems that collect personal data:

One. Have we issued a Rule 3-compliant notice — itemised, plain-language, and device-specific — for every category of personal data our IoT system collects?

Two. Is each downstream use of that data — analytics, scoring, advertising, pricing, performance management — identified as a specified purpose at the time of initial consent?

Three. Does every vendor, cloud platform, and analytics partner in our IoT data chain have a written Data Processor contract under Section 8(2) limiting them to the specified purpose?

Four. Have we built cascading deletion mechanisms so that a Section 12(3) erasure request can be honoured across the full data chain?

Five. If children may interact with our IoT devices, do we have a verifiable parental consent mechanism that meets the Section 9 standard?

IS Audit 3.0 by ICAI sets the governance standard clearly: IoT governance must address the lifecycle of IoT devices, the data managed by the IoT solution, and IoT applications in the organisation’s IT landscape. The DPDP Act makes this governance framework legally mandatory, not merely a best practice.


What Responsible IoT and DPDP Compliance Looks Like

The DPDP Act does not prohibit IoT. It requires that every IoT deployment be designed so that Data Principal rights — consent, purpose limitation, erasure, and correction — can be meaningfully exercised.

Devices will continue to collect data. Networks will continue to transmit it. Platforms will continue to analyse it. None of that is prohibited. However, every step in that chain — from sensor to server to insight — must be governed by a consent framework that the person at the centre of it all understood and agreed to, in plain language, before collection began.

The Puttaswamy judgment (2018) described this era as one of ubiquitous dataveillance. IoT is the infrastructure of that dataveillance. The DPDP Act is the law that governs it. Together, they mean one thing for Indian organisations: design your IoT systems for privacy first, not compliance as an afterthought.

The compliance deadline is 13 May 2027. Every IoT device collecting personal data in India today is already in scope.


Sources: IS Audit 3.0, ICAI | DPDP Act 2023| DPDP Rules 2025 | Puttaswamy v Union of India (2018)


Disclaimer

The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.

The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.

Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.

The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.


Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.

DPDP 3.4.3: DPDP and Internet of Things (IoT) – Case Study 3 – Lakshmi’s Smart Home and the Data That Left the House