#DPDPAct

DPDP 3.7.1: DPDP & Generative AI – When the Machine Learns What It Should Not Know

Karthik & Sunil, , , Leave a comment

INTRODUCTION

Generative AI and DPDP compliance represent the most consequential frontier in India’s data protection landscape — and the one that is evolving fastest.

Generative AI refers to systems — large language models (LLMs), image generators, voice synthesisers, code generators, and multimodal models — that are trained on vast quantities of data and can produce new content: text, images, audio, video, and code that did not previously exist. These systems are already embedded in enterprise workflows across India: drafting documents, summarising records, answering customer queries, analysing contracts, generating reports, and supporting HR processes.

IS Audit 3.0 by ICAI identifies data privacy and security as a primary AI risk, noting that most AI applications depend on massive volumes of data — often sensitive and personal in nature — to learn and make intelligent decisions. As machine learning systems become more capable, they also become more capable of learning, retaining, and inadvertently reproducing the personal data on which they were trained or with which they were prompted.

IS Audit Standard 420 (ICAI ISAS) goes further, acknowledging that generative AI models present non-deterministic outputs — meaning the same input may produce different outputs across sessions. For AI models with these characteristics, it notes, reproducibility requires that parameters, prompts, and methodology be documented sufficiently to allow independent verification. This observation is not merely an audit standard. It is a compliance architecture requirement: if a generative AI system cannot reproduce how a personal data output was generated, the Data Fiduciary deploying it cannot adequately defend its processing decisions under the DPDP Act.

CERT-In’s Blueprint on AI-Assisted Cyber Threats (CIGU20260002, May 2026) adds a threat dimension that no organisation can afford to ignore: generative AI is being actively leveraged by threat actors to generate highly convincing phishing content, deepfake voice and video fraud, synthetic identities, and spear phishing campaigns that bypass traditional awareness-based detection — all of which directly target personal data of Indian citizens. Consequently, generative AI is not merely a compliance risk as a tool of enterprise productivity. It is simultaneously the instrument of some of the most sophisticated personal data threats India’s digital ecosystem has ever faced.

Against this backdrop, the DPDP Act, 2023 applies with full force — to every organisation that deploys generative AI on personal data, to every generative AI vendor that processes personal data on behalf of Indian organisations, and to every system that generates outputs touching identifiable individuals. The compliance deadline is 13 May 2027.

Three stories ground this in the reality of Indian organisations today.

Story 1 — Vikram’s HR Query and the LLM That Remembered Everyone

The Scenario

Vikram is an HR manager at a large IT services firm in Bengaluru. His company had deployed a generative AI chatbot — integrated with its internal HR system — to help managers answer HR policy questions, draft performance review language, and retrieve employee records. The system was built using a commercially available LLM, configured with access to the company’s HR data warehouse containing salary records, performance ratings, disciplinary histories, medical leave records, and confidential appraisal notes for approximately twelve thousand employees.

Over several months, Vikram and other managers used the system extensively. Gradually, however, a pattern emerged. When managers queried the chatbot about HR policies unrelated to specific employees, the model’s responses occasionally incorporated specific employee details — names, salary ranges, performance descriptors — drawn from the training context it had been given, even when those details were not requested and not relevant to the query.

In one instance, a senior manager querying about leave policy received a response that referenced a specific employee’s medical leave pattern as an illustrative example — without Vikram having requested that information. That employee had not been informed that her medical leave data was part of the AI system’s accessible context. She had not consented to its use as illustrative material in chatbot responses to other managers.

The DPDP Act Position

This scenario reveals a compliance failure that is specific to generative AI deployments: the gap between data that is technically accessible to the model and data that has lawful authorisation to appear in the model’s outputs.

First — Processing without lawful basis under Section 4. Section 4(1) of the DPDP Act permits processing only for a lawful purpose for which the Data Principal has given consent, or for certain legitimate uses under Section 7. Medical leave data, performance ratings, and salary information were collected for HR administration — a specific, documented purpose. Incorporating this data as illustrative context in chatbot responses to third-party managers is a materially different processing activity. It has neither a consent basis nor a legitimate use basis. The data appeared in the output not because it was requested but because the model’s context window encompassed it and its generation logic surfaced it as relevant. That is still processing — and it is processing without a lawful basis.

Second — Notice failure under Section 5 and Rule 3. The employee whose medical leave data appeared in the chatbot response had never been informed that her personal data would be processed by an AI system for the purpose of generating responses to queries by other managers. Section 5(1) requires that every Data Principal be given notice of the personal data to be processed and the purpose for which it will be processed. Rule 3 of the DPDP Rules requires that this notice be in clear and plain language, with an itemised description of personal data and a specific description of its processing purposes. “Your data will be used for HR administration” does not cover “your data may appear in AI-generated responses to your colleagues’ policy queries.”

Third — Rule 13(3) algorithmic software due diligence obligation. Rule 13(3) of the DPDP Rules places a specific obligation on Significant Data Fiduciaries to observe due diligence to verify that technical measures — including algorithmic software — adopted for storing, updating, or sharing personal data are not likely to pose a risk to the rights of Data Principals. A generative AI system configured with access to twelve thousand employee records, with no output filtering controls, no data minimisation at the inference layer, and no audit trail linking specific outputs to specific data inputs, is an algorithmic architecture that poses a risk to Data Principal rights. Due diligence requires its assessment before deployment — not after an incident surfaces.

Fourth — IS Audit Standard 420 (ICAI ISAS) governance failure. IS Audit Standard 420 requires that organisations deploying AI tools establish governance controls covering approval, validation, reproducibility, accreditation, and oversight. For AI models with non-deterministic outputs — which all current LLMs are — this requires documenting parameters, prompts, and methodology sufficiently to allow independent verification. Vikram’s company had no mechanism to trace which data inputs contributed to any specific chatbot output. When the problematic response appeared, there was no audit trail to investigate it, no log linking the output to the employee’s data, and no governance framework to determine whether a personal data breach had occurred.

IS Audit Standard 430 (ICAI ISAS, Section 3.3) requires that auditors understand the entire lifecycle of personal data — from collection through storage, processing, sharing, and eventual erasure. An LLM deployed on an HR data warehouse has a data lifecycle that extends into every inference it generates. Without lifecycle mapping specific to the AI layer, ISAS 430 compliance cannot be demonstrated.

The CERT-In Dimension

CERT-In CIGU20260002 (May 2026, Section 12) specifically identifies sensitive data leakage as a primary adversarial risk to AI systems. It notes that AI-assisted offensive tooling can target AI inference systems and AI-integrated workflows — meaning that an LLM with broad access to employee personal data is not merely a compliance liability. It is an attack surface. An adversary who manipulates the model’s input — through prompt injection — can potentially extract personal data that the model has in context, without any system alert being generated.

CERT-In’s framework requires organisations to restrict upload of sensitive information to public AI platforms, define acceptable usage policies, and implement access control and authentication on AI system workflows. Applied to enterprise LLM deployments, these requirements mean that personal data context must be scoped and governed — not simply made available to the model in bulk.

The Compliance Fix

Organisations deploying LLMs or generative AI systems on employee or customer personal data must:

→ Scope the model’s data access to the minimum necessary for each specific use case. An LLM answering HR policy questions does not need access to twelve thousand employees’ disciplinary histories and medical leave records simultaneously.

→ Issue a specific, itemised notice under Rule 3 to every Data Principal whose personal data forms part of the model’s accessible context — identifying the AI system as a processing activity and the inference generation as a purpose.

→ Implement output filtering controls at the inference layer: if the model’s response includes personal data not requested by the querying user, the response must be intercepted, logged, and reviewed before delivery.

→ Maintain an AI processing register that links every LLM deployment to the personal data categories it can access, the purposes for which it was deployed, and the consent records that authorise that processing.

→ Conduct a DPIA under Rule 13 before deploying any generative AI system on personal data at scale, with specific attention to the risk of unintended data surfacing in model outputs.

→ Implement audit logging at the inference level: every query and every response must be logged in a form that allows post-hoc investigation if a personal data concern is raised.

Vikram’s company gave their AI system a broad memory and no output accountability. Under the DPDP Act, the outputs that memory generated were processing events — each one requiring a lawful basis.

The compliance deadline is 13 May 2027. An AI system with a broad memory and no output accountability is not a productivity tool. It is an uncontrolled personal data processor.

(to be continued)

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.7.1: DPDP & Generative AI – When the Machine Learns What It Should Not Know

DPDP 3.6.3 : DPDP & RPA – Sunita’s KYC Bot and the Credentials That Were Left Unlocked

Karthik & Sunil, , , , , , , , Leave a comment

The Scenario

Sunita is the compliance head of a mid-sized non-banking financial company (NBFC) in Mumbai. Her organisation had deployed an RPA solution to automate the KYC onboarding process — the bot collected applicant documents, cross-referenced identity data against government databases, triggered verification workflows, and updated the CRM with onboarding status. At its peak, the bot processed over eight hundred KYC applications per day.

The bot operated using a shared service account with administrative-level access to the customer data platform, the CRM, and the document management system. The credentials for this service account were stored in plain text in a configuration file on the deployment server — a common but critically insecure practice that IS Audit 3.0 had flagged as a known RPA risk.

In March 2025, an external attacker gained access to the deployment server, retrieved the bot’s credentials, and used them to access the customer data platform. Over three days, approximately 14,000 customer records — including names, Aadhaar numbers, PAN cards, income data, and bank account details — were exfiltrated. Because the bot routinely accessed the same systems under the same credentials, the access logs did not initially flag the intrusion as anomalous.

Sunita’s team discovered the breach only when a customer reported a fraudulent loan application made in her name.

The DPDP Act Position

The NBFC’s RPA deployment created four overlapping compliance failures — each of which independently triggered DPDP Act liability.

First — Rule 6(1)(a) security safeguard failure: absence of encryption or credential protection. Rule 6(1)(a) requires the Data Fiduciary to protect personal data through encryption, obfuscation, masking, or the use of virtual tokens. Storing bot credentials in plain text in a configuration file is the antithesis of this requirement. These credentials provided direct, unrestricted access to over 14,000 customer records containing sensitive personal data. The absence of any credential protection is a straightforward violation of the minimum security standard.

Second — Rule 6(1)(b) failure: inadequate access control. Rule 6(1)(b) requires appropriate measures to control access to computer resources. A shared service account with administrative-level access to multiple systems is structurally non-compliant. Principle of least privilege — a foundational security and governance concept — requires that the bot be granted only the minimum access necessary to complete its specific task. Administrative access across the customer data platform, CRM, and document management system simultaneously is access far in excess of what any individual process requires.

Third — Rule 6(1)(c) failure: inadequate monitoring and log review. Rule 6(1)(c) requires visibility on the accessing of personal data through appropriate logs, monitoring, and review to enable detection of unauthorised access. The breach went undetected for three days because the attacker’s access was indistinguishable from the bot’s normal access pattern. This means the NBFC had no mechanism to detect anomalous access against the baseline of expected bot behaviour — a direct failure of the monitoring obligation.

Fourth — Section 8(6) and Rule 7 breach notification failure. The NBFC discovered the breach only through a customer report. Had detection systems been in place, earlier identification would have been possible. Upon discovery, Rule 7 required immediate notification to affected Data Principals and notification to the Data Protection Board of India within seventy-two hours — including the nature and extent of the breach, its likely consequences, measures being taken to mitigate risk, and remedial steps to prevent recurrence. The delay caused by inadequate monitoring made timely compliance with these obligations impossible.

The penalty exposure under the Schedule to the DPDP Act is substantial. A breach of the obligation to take reasonable security safeguards under Section 8(5) attracts a penalty of up to ₹250 crore. A failure to notify under Section 8(6) attracts up to ₹200 crore. These are not theoretical upper limits — they are the statutory framework within which the Data Protection Board will exercise its discretion.

The IS Audit 3.0 Perspective

The study material on IS Audit 3.0 by ICAI identifies tool selection risk and operational execution risk as primary RPA governance failures. Specifically, it notes that when bots are deployed without a proper operating model, roles and responsibilities become blurred in production. In Sunita’s case, the operating model had no provision for credential management, access scoping, or anomaly detection — a governance gap that directly enabled the breach.

IS Audit 3.0 requires that RPA governance frameworks specifically address operational risk and data security through cross-functional team involvement, including legal and risk functions. Had this standard been applied, credential storage protocols, access control scoping, and monitoring requirements would have been part of the deployment framework — not afterthoughts discovered in a breach investigation.

Furthermore, IS Audit 3.0 notes that auditors engaging with RPA-enabled organisations must focus on control design opportunities and develop new testing approaches for bot-driven processes. Specifically in the DPDP compliance context, this means IS auditors should treat each RPA bot as a data processing entity and audit its access rights, credential management, output routing, and log review protocols as rigorously as they would audit any human-operated system.

The Compliance Fix

Any NBFC, financial institution, or organisation deploying RPA for processes involving sensitive personal data must urgently address:

→ Credential security: bot service account credentials must be stored in an encrypted secrets management vault — never in plain text in configuration files. This is the minimum standard under Rule 6(1)(a).

→ Access scoping: every bot must be assigned a service account with the minimum permissions necessary for its specific task. Administrative-level, cross-system access for a single bot is never appropriate when individual process-scoped access is achievable.

→ Anomaly detection baselines: organisations must establish normal bot behaviour profiles — typical access volumes, access times, data retrieval patterns — and configure monitoring alerts that fire when actual behaviour deviates from these baselines. Rule 6(1)(c) requires this level of visibility.

→ Breach response rehearsal: RPA-related breaches are difficult to detect quickly because bot access is indistinguishable from normal operations without baseline monitoring. Organisations must rehearse their breach detection, escalation, and notification workflows specifically for bot-related incidents — so that the Rule 7 seventy-two-hour notification obligation can be met when it matters.

→ IS Audit 3.0-aligned annual review: every RPA deployment processing personal data must be audited annually using IS Audit 3.0 standards, with specific attention to credential management, access control design, and log review sufficiency.

Sunita’s NBFC had an efficient KYC bot. However, it had no compliant security architecture around it. Fourteen thousand customers paid the price for that gap.

The Central Compliance Question for RPA Deployments

The unique DPDP compliance challenge that RPA creates is one of invisibility. Unlike a human employee who processes personal data visibly and accountably, an RPA bot processes data silently, continuously, and often without any mechanism for the organisation to know precisely what it touched, where it sent it, and what secondary data stores it created in the process.

The DPDP Act, however, applies equally to automated and human processing. Section 2(x) defines processing to include every operation performed on digital personal data — and Section 2(b) defines automated as any digital process capable of operating automatically. Together, these definitions mean that an RPA bot is not operating outside the Act’s scope. It is operating at the centre of it.

Every organisation deploying RPA on personal data must therefore answer five questions — not once at deployment, but continuously throughout the bot’s operational lifecycle:

One. Have we mapped the complete data footprint of every RPA process — including every system accessed, every intermediate file created, every output generated, and every downstream system that receives data?

Two. Does every bot service account operate on the principle of least privilege — with access strictly scoped to the minimum data necessary for the specific task it performs?

Three. Are bot credentials stored securely — encrypted in a secrets management system, rotated regularly, and audited for access?

Four. Do we have anomaly detection baselines for each bot’s data access behaviour, with alerts configured to flag deviations for human review?

Five. Can we honour a Data Principal’s Section 12(3) erasure request across the full data footprint of a bot process — including staging environments, output files, and communication logs?

IS Audit 3.0 states that a governance structure defining roles and responsibilities for automation activities is essential for successful RPA initiatives. Under the DPDP Act, that governance structure is not a success factor — it is a legal obligation.

What Responsible RPA and DPDP Compliance Looks Like

IS Audit 3.0 correctly observes that RPA is not replacing accountants but augmenting their effectiveness — creating space for professionals to focus on higher-value analytical and advisory work. That observation is true, and the productivity benefits of well-governed RPA are real. However, realising those benefits without simultaneously creating DPDP compliance liability requires a deliberate, structured approach to bot governance.

Responsible RPA and DPDP compliance means treating every bot as a named, scoped, audited data processor. It means mapping every process before deployment, monitoring every execution in production, and maintaining the ability to respond to any Data Principal rights request across every processing environment the bot touches.

The organisations that achieve this are not those with the most bots. They are those with the best governance around each one. Automation scales efficiency — but without proper controls, it also scales compliance risk at exactly the same rate.

The DPDP Act has made that tradeoff unambiguous. Organisations now need to make a deliberate choice. The compliance deadline is 13 May 2027.

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.6.3 : DPDP & RPA – Sunita’s KYC Bot and the Credentials That Were Left Unlocked

DPDP 3.6.2: DPDP & RPA – Data erasure failed due to untracked bot copies

Karthik & Sunil, , , , , , , , , , Leave a comment

He asked for erasure. The hospital cited regulatory retention. But the bot had created fourteen data instances across staging environments, output logs, and a marketing file — none covered by that retention basis.

The Scenario

Ramesh is a 52-year-old former patient of a corporate hospital chain in Hyderabad. He had been treated at the hospital for a minor procedure in 2021 and had not returned since. In 2024, the hospital implemented an RPA solution to automate its patient record management — including pulling records from the clinical management system, flagging inactive accounts, generating discharge summaries, and triggering follow-up communications.

Ramesh received an automated follow-up message in 2025, referencing his 2021 procedure. Concerned, he submitted a request for erasure of his personal data under the DPDP Act. The hospital’s patient services team replied that his records had to be retained for medical and regulatory purposes — a position that was partially accurate for core clinical records under applicable health law.

However, Ramesh’s personal data had also been ingested into the RPA bot’s active processing queue, the bot’s intermediate staging environment, the output logs of every follow-up communication run, and a marketing segmentation file generated by the bot for the hospital’s patient re-engagement programme. None of these secondary processing instances were covered by the regulatory retention obligation cited by the hospital.

Ramesh’s erasure request was thus effectively denied for his entire data footprint — when, in reality, only a narrow subset of it was covered by any lawful retention basis.

The DPDP Act Position

This scenario illustrates one of the most practically important DPDP challenges in RPA deployments: the gap between data that is lawfully retained and data that is incidentally retained across multiple processing environments created by bot execution.

First — Section 12(3) erasure rights apply to every processing instance. Section 12(3) of the DPDP Act requires the Data Fiduciary to erase personal data upon request, unless retention is necessary for the specified purpose or for compliance with any law in force. This obligation applies to all instances of personal data — not merely the primary source record. Ramesh’s personal data in the bot’s staging environment, the output logs of follow-up communications, and the marketing segmentation file had no regulatory retention basis. Each instance was subject to his erasure request. Declining to erase these instances while citing a regulatory obligation applicable only to core clinical records is a misapplication of the retention exception.

Second — Rule 8 purpose limitation for retained data. Rule 8 of the DPDP Rules governs the time period after which personal data must be erased when its specified purpose is served. Clinical data retained under health law does not carry a blanket licence for use in marketing automation or patient re-engagement analytics. The specified purpose of clinical record retention is regulatory compliance — not marketing. Processing retained data for marketing through an RPA bot is a purpose drift violation under Rule 8, compounded by the absence of any fresh consent for that use.

Third — RPA-generated output logs as personal data. The DPDP Act’s definition of processing in Section 2(x) includes “recording, organisation, structuring, storage, adaptation, retrieval, use, alignment or combination.” Every time the bot read Ramesh’s record, the act of retrieval was processing. Every output log generated by that retrieval stored personal data in a new location. The hospital’s RPA deployment had created multiple secondary personal data stores — none of which the hospital had mapped, none of which it could manage in response to a Data Principal rights request.

The IS Audit 3.0 Perspective

The study material on IS Audit 3.0 by ICAI specifically flags vaguely defined business continuity and maintenance plans as an RPA risk. In the context of DPDP compliance, this observation extends to data lifecycle management: organisations that deploy RPA without mapping the full data footprint of every bot process — including staging environments, output files, logs, and downstream data stores — create invisible personal data inventories that are unresponsive to Data Principal rights.

IS Audit 3.0 Governance and Controls requires deployment frameworks that account for data security and operational risk across the full RPA lifecycle. Data lifecycle governance — specifically, the ability to trace and erase personal data from every processing environment a bot touches — is a core component of that framework under the DPDP Act.

The Compliance Fix

Healthcare organisations and any entity deploying RPA processes on personal data must:

→ Conduct a full data footprint mapping for every RPA process before deployment. The map must identify every system the bot accesses, every intermediate file or staging environment it creates, every output it generates, and every downstream system that receives its outputs.

→ Apply Section 12(3) erasure obligations to every node in the data footprint — not merely the primary source system. A Data Principal rights response must be capable of reaching and clearing every instance of the individual’s data across the full bot execution chain.

→ Apply Rule 8 purpose limitation controls technically: personal data retained for regulatory compliance must be firewalled from RPA processes used for marketing, re-engagement, or analytics. These are different purposes with different lawful bases.

→ Maintain a personal data register that is updated whenever a new RPA process is added or modified, so that the full scope of automated processing is always visible for compliance management.

→ Designate a clear accountability owner for each RPA process who understands both its operational function and its data privacy obligations under the DPDP Act.

Ramesh’s hospital retained his data for good reasons. However, it processed it for additional reasons it had neither disclosed nor obtained consent for. The DPDP Act makes that distinction matter.

The compliance deadline is 13 May 2027. Regulatory retention is a defence for what it covers. It is not a blanket exemption for the entire data trail a bot leaves behind.

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.6.2: DPDP & RPA – Data erasure failed due to untracked bot copies

DPDP 3.6.1: DPDP & Robotic Process Automation (RPA)

Karthik & Sunil, , , , , , , Leave a comment

INTRODUCTION

RPA and DPDP compliance is a pairing that most organisations have not yet considered — and that oversight is becoming a serious liability.

Robotic Process Automation, as defined by study material on IS Audit 3.0 by ICAI, refers to software tools that automate human activities that are manual, rule-based, and repetitive. RPA bots replicate the actions of a human interacting with software applications — logging in, reading data, copying records, filling forms, sending communications, and closing cases — all without human involvement at the point of execution. They work across functions and applications, often with privileged system access, processing thousands of transactions per hour in the background.

Here is the compliance problem that this efficiency creates: the DPDP Act, 2023 defines “processing” in Section 2(x) as any wholly or partly automated operation or set of operations performed on digital personal data. This definition covers collection, recording, organisation, structuring, storage, adaptation, retrieval, use, alignment, combination, indexing, sharing, disclosure, restriction, erasure, and destruction. Every time an RPA bot touches a field containing personal data — a name, a PAN, an address, a bank account number, a medical record — that action is processing under the Act.

Furthermore, Section 2(b) of the DPDP Act defines “automated” as any digital process capable of operating automatically in response to instructions given or otherwise. RPA is, by definition and by design, automated. Consequently, RPA bots are not merely productivity tools. They are automated personal data processors — and the Data Fiduciary that deploys them is fully responsible for every record they touch.

The Study material on IS Audit 3.0 by ICAI identifies operational and execution risk as a primary RPA challenge: when bots are deployed into operations without a proper operating model, roles and responsibilities become blurred. Under the DPDP Act, blurred roles in data processing are not a technology governance gap — they are a compliance failure. The responsibility remains clearly with the Data Fiduciary, regardless of whether a human or a bot performed the processing.

Three stories make this concrete.

Story 1 — Priya’s Salary Data and the Bot That Shared It Across Departments

The Scenario

Priya works as a senior executive at a manufacturing company in Pune. Her employer had deployed an RPA solution to automate its monthly payroll reconciliation process. The bot was configured to pull salary, tax deduction, and bank account data from the HR system, cross-reference it with the finance system, and generate a reconciliation report that was emailed to a shared distribution list covering the finance team, the CFO’s office, and — due to a misconfiguration in the bot’s output routing — the entire operations management team as well.

For seven months, Priya’s salary, tax deductions, advance loans, and bank account details were visible to approximately forty colleagues who had no business need for that information. No human reviewed the bot’s output routing. No alert was raised. The misconfiguration was discovered only when an operations manager mentioned a colleague’s salary in a team meeting.

Priya filed a complaint with HR. The company’s response was that the error had been in the bot’s configuration, implying that the technology, rather than the organisation, bore responsibility.

The DPDP Act Position

The company’s response was legally incorrect in two distinct ways.

First — Data Fiduciary liability is non-derogable under Section 8(1). Section 8(1) of the DPDP Act makes the Data Fiduciary responsible for compliance with the provisions of the Act in respect of processing carried out by it or on its behalf by a Data Processor. An RPA bot deployed by the company, on the company’s systems, processing the company’s HR and payroll data, is unambiguously acting on the company’s behalf. Consequently, the misconfiguration was not the bot’s fault. It was the company’s compliance failure.

Second — Unauthorised disclosure constitutes a personal data breach under Section 2(u). The DPDP Act defines a personal data breach as any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises the confidentiality, integrity, or availability of personal data. Priya’s salary and bank account data being shared with forty employees who had no authorisation to receive it is a textbook personal data breach — accidental, but real and attributable.

Under Section 8(6) and Rule 7 of the DPDP Rules, the company was required to notify both the Data Protection Board of India and each affected Data Principal — including Priya — of the breach, without delay. A description of the breach, its nature and extent, the consequences likely to arise from it, the measures being taken to mitigate risk, and the safety measures that Priya could take were all required to be communicated promptly. None of this was done.

Third — Rule 6 security safeguard failure. Rule 6(1)(b) of the DPDP Rules requires the Data Fiduciary to implement appropriate measures to control access to the computer resources used by it or by its Data Processor. Rule 6(1)(c) requires visibility on the accessing of personal data through appropriate logs, monitoring, and review. The RPA bot’s output routing was misconfigured for seven months. No access control review detected this. No log monitoring flagged the anomaly. Both requirements were violated — not as a single incident, but as a persistent governance failure sustained across thirty-plus payroll cycles.

The IS Audit 3.0 Perspective

IS Audit 3.0 study material identifies operational and execution risk as one of the most significant RPA challenges. Specifically, when bots are deployed without a proper operating model and without clearly defined roles and responsibilities, problems in production environments can go undetected for extended periods. Priya’s case is exactly this: a production bot operating outside its intended parameters for seven months, with no human oversight mechanism in place to detect the deviation.

IS Audit 3.0 material on, Governance and Controls is equally direct. Governance of RPA must cover operational risk and data security through a cross-functional oversight team. Legal, risk, and IT teams must all be involved in the processes being automated. In Priya’s case, neither legal nor data privacy considerations appear to have been included in the bot’s deployment framework — an omission that allowed a structural data breach to persist across a full financial year.

The Compliance Fix

Organisations deploying RPA for payroll, HR, or any process involving personal data must:

→ Treat every RPA bot as an automated data processor and apply Rule 6 access controls and logging standards to every process it executes. Bot-level access must be scoped to the minimum data necessary for the specific task — not system-wide access because it is convenient.

→ Configure mandatory output routing reviews before any bot deployment that involves personal data in its output. Distribution lists must be verified against a need-to-know register, not simply inherited from historical email groups.

→ Implement bot execution monitoring logs under Rule 6(1)(c) that flag anomalies — such as data being routed to recipients outside the specified access list — and trigger human review.

→ Establish a breach identification and notification workflow specifically for RPA processes. When a bot misconfiguration results in unauthorised disclosure, the organisation must be capable of identifying it, classifying it as a breach, and notifying under Rule 7 — all within the required timeframe.

→ Designate an RPA governance owner who is responsible for DPDP Act compliance across all bot deployments — not merely for technical performance.

Priya’s employer blamed the bot. Under the DPDP Act, the bot has no liability. The organisation does.

The compliance deadline is 13 May 2027. The bot had no liability. The organisation did — from the first payroll cycle.

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.6.1: DPDP & Robotic Process Automation (RPA)

DPDP 3.5.3: DPDP and Data Analytics – Retail Chain Loyalty Points

Karthik & Sunil, , , , , , , Leave a comment

Nalini’s Retail Loyalty Programme and the Profile She Never Agreed To

The Scenario

Nalini is a 29-year-old working professional in Mumbai. She had enrolled in a large retail chain’s loyalty programme several years ago. At the time of enrolment, she provided her name, phone number, email address, and date of birth in exchange for discount points.

Over the following years, the retail chain built an increasingly sophisticated analytics capability. It combined Nalini’s purchase history — over 400 transactions across groceries, personal care, clothing, and home products — with her app browsing data, location signals from in-store beacons, and inferred demographic data purchased from a data enrichment vendor. The analytics platform then classified her into behavioural segments — “health-conscious millennial,” “premium spender,” “likely expecting” — and used these segments to target her with personalised advertising and to adjust the pricing of certain dynamic offers.

Nalini had not been informed that her purchase history would be used to infer personal attributes. She had not consented to location tracking via in-store beacons. She had no knowledge of the data enrichment vendor or the categories of inferred data it supplied. Furthermore, when she eventually tried to delete her account, the platform told her that her historical transaction data had to be retained for seven years under applicable tax and commercial regulations — and that her behavioural segments were derived data and therefore could not be erased.

The DPDP Act Position

Nalini’s situation is the most layered of the three stories, because it involves multiple compliance failures running simultaneously across the full analytics pipeline.

First — Consent obtained for enrolment is not consent for analytics profiling. Section 6(1) requires consent to be limited to personal data that is necessary for the specified purpose. The specified purpose at enrolment was participation in a loyalty programme for discount points. Predictive profiling, behavioural segmentation, demographic inference, and dynamic pricing optimisation are materially different purposes — each requiring its own consent basis.

Rule 3 of the DPDP Rules further tightens this standard. The notice must give an itemised description of personal data and a specific description of the goods, services, or uses that processing will enable. A loyalty programme enrolment form that says “your data will be used to improve your shopping experience” does not satisfy this requirement when the actual use involves inferring pregnancy likelihood or segmenting users by spending disposition.

Second — Inferred data is personal data under Section 2(t). The DPDP Act defines personal data as any data about an individual who is identifiable by or in relation to such data. Behavioural segments derived from Nalini’s purchasing patterns — “likely expecting,” “premium spender” — are data about an identifiable individual. They are personal data. Their creation and storage are processing activities subject to the Act’s full consent and purpose requirements. The retail chain’s argument that derived data cannot be erased does not hold under Section 12(3) — the erasure right applies to personal data in whatever form it exists, including derived outputs of analytics processing.

Third — Third-party data enrichment without disclosure under Section 5. The retail chain ingested demographic inference data from an external vendor to enrich Nalini’s profile. This enrichment vendor is a Data Processor under the Act. Its data categories were never disclosed to Nalini in the original notice. Section 5(1) and Rule 3 together require that the source and category of every piece of personal data used in processing be disclosed to the Data Principal at the time of notice. Using enrichment data that was never disclosed violates this requirement.

Fourth — In-store beacon tracking without consent under Section 6. Location signals collected from in-store beacons constitute processing of personal data. Nalini had enrolled in a loyalty programme — she had not consented to being tracked by physical location sensors during her store visits. This is a separate processing activity requiring a separate consent.

Fifth — The “seven-year retention” argument does not justify analytics profiling. The retail chain’s argument that transactional data must be retained for seven years under commercial law is legally accurate for transaction records — but retention for regulatory compliance does not authorise the retained data to be used for new purposes. Section 8(1) and the purpose limitation principle require that data retained for regulatory compliance be isolated from analytics processing pipelines. Retaining data is not the same as having a continuing licence to process it for all purposes.

The IS Audit and Puttaswamy Perspective

IS Audit 3.0 by ICAI describes data analytics as a series of processes designed to sanitise raw data and transform it into a form appropriate for analysis to facilitate decision-making. In Nalini’s case, the analytics pipeline transformed loyalty programme enrolment data into a comprehensive personal profile — a transformation that was never disclosed, never consented to, and that the DPDP Act does not permit on the basis of an original loyalty enrolment consent alone.

The Puttaswamy judgment (2018) is especially pertinent here. The court directly addressed the concept of the “quantified self” — individuals generating vast amounts of data through everyday activities, without conceiving of themselves as having volunteered it for profiling. Justice Kaul’s analysis of profiling under data protection law applies directly: using personal data to evaluate aspects of an individual’s life — her economic situation, personal preferences, behaviour, or movements — is a privacy-sensitive activity that requires explicit, specific authorisation. A discount programme sign-up is not that authorisation.

Furthermore, the court’s description of the “Big Data” era as one where data sets are linked, searchable, and permanently collected maps directly to Nalini’s situation: her 400 transactions, combined with location signals and enrichment data, created exactly the kind of linked, searchable, permanent dataset that the Puttaswamy judgment identified as requiring robust legal governance.

The Compliance Fix

Retail loyalty programmes and any organisation using analytics for customer profiling must:

→ Separate enrolment consent from analytics consent. Loyalty enrolment and behavioural profiling are different processing activities. They require separate, specific consent notices that clearly describe what profiling will occur, what data will be used, and what outputs will be generated.

 → Treat all derived data — segments, inferences, scores — as personal data under Section 2(t). Design erasure mechanisms that reach derived data, not just source data.

→ Disclose every external data enrichment vendor by name and category in the consent notice under Rule 3. “Third-party partners” is not adequate disclosure.

→ Obtain separate consent for in-store location tracking via beacons. Physical location processing is a distinct activity requiring a distinct lawful basis.

 → Apply a regulatory retention firewall: data retained for tax or commercial law compliance must be technically isolated from live analytics pipelines. Regulatory retention and analytics processing are separate activities requiring separate legal bases.

 → For organisations using analytics on large volumes of personal data for profiling, segmentation, or prediction, a DPIA under Rule 13 of the DPDP Rules is a mandatory exercise — not an optional governance measure.

Nalini’s retail chain ran excellent analytics. However, it ran them on a broken consent architecture. The quality of the insights does not determine the lawfulness of the processing.

The Central Compliance Question for Data Analytics Deployments

Data analytics is not inherently incompatible with the DPDP Act. Organisations can legitimately use data analytics for internal operations, fraud detection, product improvement, and customer service — provided the analytics is designed from the ground up around a compliant consent and purpose framework.

The compliance failure that runs through all three stories in this episode is the same: analytics capabilities grew beyond the consent architecture that was in place when data was originally collected. Devika’s lender ran predictive models on data never disclosed to her. Harini’s hospital activated a marketing module without patient consent. Nalini’s retail chain built a behavioural profile using data from sources never itemised in any notice.

Every organisation running data analytics on personal data must therefore answer six questions before each analytics deployment:

One. Does our Rule 3 notice itemise every data source feeding this analytics model — including external enrichment vendors, third-party data providers, and inferred or derived data categories?

Two. Is every analytical use case — profiling, segmentation, prediction, decision-making — identified as a specific stated purpose at the time of consent?

Three. Are all Data Processors in the analytics pipeline — vendors, cloud platforms, enrichment providers — covered by Section 8(2) contracts that limit them to the specified purpose?

Four. Does our analytics pipeline have a purpose limitation control that prevents data collected for one purpose from feeding into models built for a different purpose?

Five. Can we honour a Section 11 access request accurately enough to tell a Data Principal which data sources contributed to a decision about her?

Six. Can we honour a Section 12(3) erasure request that reaches derived data — segments, scores, and inferences — not just source records?

IS Audit 3.0 study material by ICAI identifies data privacy risk as the primary challenge for analytics deployments. Rule 13 of the DPDP Rules mandates annual DPIA and audit for Significant Data Fiduciaries using analytics at scale. Together, they establish that governance of data analytics is not optional — it is the compliance baseline.

What Responsible Data Analytics and DPDP Compliance Looks Like

The organisations that will manage this intersection well are not those with the most sophisticated models. They are the ones that invested in governance architecture before their analytics capabilities outgrew their consent frameworks.

Responsible data analytics and DPDP compliance means one thing above all else: every data point entering an analytics pipeline must be traceable to a consent record that specifically authorises its use for that specific analytical purpose. Where that traceability breaks down — at the point of data collection, at the point of third-party enrichment, at the point of model output — the compliance obligation is violated, regardless of how valuable or accurate the analytical output may be.

The value of an insight does not determine the lawfulness of how it was generated. The DPDP Act makes that unambiguous. The compliance deadline is 13 May 2027.

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.3: DPDP and Data Analytics – Retail Chain Loyalty Points

DPDP 3.5.2: DPDP and Data Analytics – Healthcare Analytics

Karthik & Sunil, , , , , Leave a comment

The Scenario

Harini is the CFO of a mid-sized private hospital group in Tamil Nadu. The group had invested significantly in a business intelligence platform, which pulled data from their hospital management system, OPD records, pharmacy transactions, and diagnostic reports. The platform generated dashboards that the management team used for operational decisions — bed utilisation, consumable planning, department profitability, and patient retention.

At the end of the financial year, the analytics vendor offered a value-added service: a patient re-engagement module that would use the same data to identify patients who had not returned for follow-up visits and send them targeted health alerts via SMS and email. The hospital management approved the feature.

What the hospital had not done was revisit the consent it had obtained from patients at registration. That consent — collected through a standard hospital intake form — covered the processing of personal data for the provision of medical care and for billing purposes. It did not cover the use of diagnostic and prescription data for automated marketing outreach.

The DPDP Act Position

This scenario involves a textbook purpose limitation failure — one that also carries significantly aggravated risk because the personal data in question is health data.

First — Processing beyond the specified purpose under Section 8(1). Section 8(1) of the DPDP Act makes the Data Fiduciary responsible for compliance with the Act in respect of processing carried out by it or by any Data Processor on its behalf. The analytics vendor, when it ran the re-engagement module, was a Data Processor acting on the hospital’s behalf. Consequently, the hospital bears liability for this processing. The specified purpose under which patient data was collected was medical care and billing. Re-engagement marketing is not a purpose covered by that consent — regardless of whether the hospital subjectively considered it beneficial to patients.

Second — Data Processor contract inadequacy under Section 8(2). Section 8(2) requires the Data Fiduciary to ensure that its Data Processor processes personal data only for the specified purpose under a valid contract. The analytics vendor’s contract, in this case, covered the provision of BI dashboards and reporting. The re-engagement module was a new capability added under an expanded commercial arrangement — but without a corresponding update to the Data Processor contract to reflect the new processing purpose, and without fresh consent from patients for that purpose.

Third — Retention and purpose drift under Rule 8. Rule 8 of the DPDP Rules, 2025 governs the time period for which personal data may be retained once its specified purpose is served. Health data collected for a specific episode of care — an OPD visit, a diagnostic test — remains subject to the purpose for which it was collected. Feeding that data into a marketing analytics module after the specified purpose has been served is a purpose drift violation, compounded by the retention obligation.

The IS Audit 3.0 Perspective

IS Audit 3.0 by ICAI identifies data privacy and confidentiality as the leading challenge for data analytics deployments, specifically calling out the risk of data being misused once it is accessible to an analytics platform. Hospital management systems are among the most data-rich environments in any organisation. However, that richness also makes them among the highest-risk environments for purpose drift — the gradual expansion of analytics use cases beyond the original data collection purpose.

Importantly, IS Audit 3.0 material by ICAI also flags the risk that insufficient evidence is retained on file about the procedures and inputs used in analytics processing. In the hospital’s case, there was no audit trail linking the re-engagement module’s data inputs to a consent record. Consequently, if the Data Protection Board of India ever investigated, the hospital would be unable to demonstrate that lawful basis existed for the marketing processing.

The Compliance Fix

Healthcare organisations — and any organisation running analytics on data collected for a primary service purpose — must:

→ Conduct a purpose mapping exercise before activating any new analytics module. Every new use case must be traced back to a consent record that explicitly covers it.

→ Review and update all Data Processor contracts each time the analytics vendor introduces a new processing module or capability. Section 8(2) compliance requires the contract to reflect the actual processing being performed.

→ Maintain consent records that are granular enough to support an audit trail. “Patient consented to data processing” is not sufficient. The consent record must specify what data was covered, for what purpose, and at what point in time.

→ Apply purpose limitation controls at the analytics platform level — configure data access so that each module can only access the data categories covered by the relevant consent record.

→ Obtain fresh, specific consent before using health data for any purpose beyond direct patient care and billing — including patient outreach, marketing, research, and quality benchmarking.

Harini’s hospital had good intentions. However, the DPDP Act governs outcomes, not intentions. Unlawful processing remains unlawful even when it is well-meaning.

The compliance deadline is 13 May 2027. Health data analytics is high-risk processing. Its governance must match that risk.

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.2: DPDP and Data Analytics – Healthcare Analytics

DPDP 3.5.1: DPDP and Data Analytics

Karthik & Sunil, , , , , , , Leave a comment

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

Karthik & Sunil, , , , , , Leave a comment

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

DPDP 3.4.2: DPDP and Internet of Things (IoT) – Case Study 2 –  Suresh and the Smart Office That Never Stopped Watching

Karthik & Sunil, , , , , Leave a comment

The Scenario

Suresh is a mid-level manager at a logistics company in Chennai. His employer had implemented an IoT-enabled smart office system — access badges tracked movement across the building, smart cameras monitored workstations, occupancy sensors logged time at desk, and a connected printer recorded who printed what and when.

All of this data flowed into a workplace analytics platform that generated individual productivity scores. Suresh was placed on a performance improvement plan based partly on his occupancy metrics — he had spent less time at his desk during a period when he was, in fact, attending client meetings in the conference rooms.

He was never told that his movement and occupancy data were being collected and used for performance evaluation. He had signed a general IT usage policy when he joined — three years before this system was installed.

The DPDP Act Position

This scenario raises three compliance failures.

First — Absence of lawful consent for a new processing purpose. Section 6(1) of the DPDP Act requires consent for each specified purpose. A general IT usage policy signed three years earlier does not constitute valid consent for IoT-based occupancy tracking and performance scoring. The purposes are different, the data categories are different, and the consequences to the employee are materially different.

Section 5(1) of the 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. No such notice was given when the IoT system was deployed. Consequently, all processing of Suresh’s location and occupancy data for performance evaluation was unlawful.

Second — Use of incomplete data to make decisions affecting the Data Principal. Section 8(3) requires that when personal data is likely to be used to make a decision that affects the Data Principal, the Data Fiduciary must ensure the completeness, accuracy, and consistency of that data. Suresh’s occupancy data was accurate — he was not at his desk — but it was incomplete, because the system had no mechanism to capture the reason. An employee attending client meetings generates the same occupancy reading as one who is absent without reason. Using this data for performance decisions without ensuring completeness is a direct violation of Section 8(3).

Third — Breach of proportionality under the Puttaswamy doctrine. The Supreme Court’s judgment in Puttaswamy v Union of India (2018) established that any encroachment on informational privacy must satisfy the proportionality test: there must be a lawful basis, a legitimate aim, and the measure must be proportionate to that aim. Continuous occupancy monitoring of every employee for the purpose of productivity scoring is disproportionate to any legitimate workplace management aim — particularly when other, less invasive means of performance assessment are readily available.

The IS Audit 3.0 Perspective

IS Audit 3.0 by ICAI identifies insufficient authentication and authorisation, insecure web interfaces, and lack of transport-level encryption as key IoT risks. In Suresh’s case, the workplace IoT system aggregated movement data with no individual access controls, no audit trail for the analytics platform, and no individual visibility into what data was being collected about each employee.

IS Audit 3.0 (Governance and Controls) is direct: IoT governance must define the lifecycle of IoT data, cover the changes to IT governance for distributed IoT architecture, and ensure that the principles for managing that architecture deliver on the stated business goals. A workplace analytics platform that generates employment consequences without a lawful consent framework is not a managed system — it is an uncontrolled compliance liability.

The Compliance Fix

Employers deploying workplace IoT systems must:

→ Issue a fresh, specific consent notice — separate from general IT policies — for each new IoT deployment that collects employee personal data. → Conduct a Data Protection Impact Assessment (DPIA) under Section 10 of the DPDP Act before deploying any system that collects employee movement, biometric, or occupancy data at scale. → Ensure that any data used to make employment decisions is complete, not merely accurate — which means building context-capture mechanisms alongside sensors. → Apply proportionality: if the legitimate aim is productivity management, the least invasive means of achieving that aim should be used. Continuous movement tracking is rarely the least invasive option. → Give employees visibility into what data is being collected about them, and provide a mechanism to raise corrections under Section 12(2) of the DPDP Act.

Suresh’s employer automated its surveillance. However, it did not automate its compliance.

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.2: DPDP and Internet of Things (IoT) – Case Study 2 –  Suresh and the Smart Office That Never Stopped Watching

DPDP 3.4.1: DPDP and Internet of Things (IoT) – Case Study 1 –  When Every Device Becomes a Witness

Karthik & Sunil, , , , , , Leave a comment

INTRODUCTION

IoT and DPDP compliance represent one of the most underestimated challenges in India’s data protection landscape today.

Your fitness band knows your resting heart rate. Your smart meter knows when you wake up. Your office access badge knows exactly where you were at 9:14 am. Individually, each of these data points seems harmless. Together, however, they compose a surveillance portrait of extraordinary detail — one that its subject never agreed to provide and may not even know exists.

This is precisely the privacy risk that IS Audit 3.0 (ICAI Module 6, Section 6.5.6) identifies when it notes that IoT devices collect and aggregate fragments of data that, in combination, can reveal religion, health information, lifestyle choices, and other sensitive personal attributes — even when no single data point appears sensitive in isolation.

The Internet of Things is defined in IS Audit 3.0 (Module 6, Section 6.5.1) as a system of interrelated computing devices, mechanical and digital machines, objects, animals, or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. In simple terms, devices collect, send, and act on data — largely without human involvement at the point of collection.

That last phrase is the compliance problem. The DPDP Act, 2023 is built on the premise of informed, specific, and free consent. IoT is built on the premise of seamless, continuous, and frictionless data collection. These two architectures sit in fundamental tension — and that tension has a deadline: 13 May 2027.

Three Case Study bring this tension to life.

Case Study 1 — Rohini’s Wearable and the Insurance Company That Knew Too Much

The Scenario

Rohini is a 41-year-old schoolteacher in Pune. She purchased a health insurance policy from a mid-sized insurer. As part of a wellness incentive programme, the insurer offered her a discount in exchange for syncing her fitness wearable to their app. Rohini agreed, expecting only her step count to be shared.

Over eighteen months, the wearable transmitted her heart rate variability, sleep patterns, stress indicators, menstrual cycle data, and location history to the insurer’s cloud platform. The insurer’s algorithm then recalculated her risk profile — and at renewal, her premium increased substantially. No one told Rohini that these data points were being collected, how they were being used, or that they would influence her premium.

The DPDP Act Position

Rohini’s situation discloses at least three distinct violations.

First — Consent specificity failure under Section 6(1). The DPDP Act requires consent to be free, specific, informed, unconditional, and unambiguous. It must be limited to personal data that is necessary for the specified purpose. Rohini consented to sharing her step count for a wellness discount. She did not consent to the sharing of menstrual cycle data, stress indicators, or sleep patterns. Any processing beyond the specified purpose is unlawful.

Rule 3 of the DPDP Rules, 2025 reinforces this directly. A Data Fiduciary must give notice in clear and plain language, with an itemised description of personal data to be collected and a specific description of the purpose. A general reference to “health data” does not satisfy this standard. Each category of IoT data being collected must be identified separately in the consent notice.

Second — Purpose limitation failure under Section 8(1). The purpose for which Rohini’s data was processed — premium recalculation — was never disclosed as a specified purpose at the time of consent. Consequently, processing her data for that purpose is unlawful under the Act, regardless of what the policy fine print may say.

Third — Sensitive personal data processing without adequate basis. Menstrual cycle data and health metrics constitute personal health information. While the DPDP Act does not yet have a separate “sensitive personal data” category in the manner of some foreign frameworks, Section 8(5) requires the Data Fiduciary to implement reasonable security safeguards. Moreover, when data is used to make a decision that affects the Data Principal, Section 8(3) requires the Data Fiduciary to ensure completeness, accuracy, and consistency of that data. An algorithmic premium revision based on wearable data must meet this standard.

The IS Audit 3.0 Perspective

IS Audit 3.0 (Module 6, Section 6.5.6) specifically identifies privacy concerns in healthcare IoT as a primary risk, observing that devices in this domain collect at least one piece of personal information and that the aggregation of IoT data fragments can reveal health information that was never explicitly disclosed. This aggregation risk is precisely what happened to Rohini.

Furthermore, IS Audit 3.0 (Section 6.5.7) identifies governance of IoT data as requiring a clear reference architecture, defined governance processes, and lifecycle management of the data managed by the IoT solution — none of which the insurer had implemented.

The Compliance Fix

Insurers and any organisation using wearable or health IoT data must:

→ Issue a separate, itemised consent notice for each data category collected by the device — not a single bundled consent covering “health data.” → Clearly specify every downstream use — including risk assessment, pricing, and underwriting decisions — as a stated purpose at the time of initial consent. → Ensure that data collected via wearable integration is not used for purposes beyond what was disclosed, unless fresh consent is obtained for the new purpose. → Implement data minimisation controls at the IoT gateway level, so that only the specific data categories covered by consent are transmitted to the cloud platform.

Rohini’s insurer collected far more than it disclosed. The DPDP Act calls that a violation — not a feature.

Rohini’s insurer had a wellness programme. It did not have a consent programme. Under the DPDP Act, that distinction matters enormously. The compliance deadline is 13 May 2027.

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.1: DPDP and Internet of Things (IoT) – Case Study 1 –  When Every Device Becomes a Witness