DPDP 3.6.1: DPDP & Robotic Process Automation (RPA)

August 27, 2026 Karthik & Sunil#DataBreach, #DataFiduciary, #DataPrincipal, #DataProcessor, #DPDP, #DPDPAct, #PayrollPrivacy, #RPAComplianceLeave 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.4.3: DPDP and Internet of Things (IoT) – Case Study 3 – Lakshmi’s Smart Home and the Data That Left the House

August 2, 2026August 15, 2026 Karthik & Sunil#DataFiduciary, #DataPrincipal, #DataProcessor, #DPDPAct, #InternetOfThings, #IoT, #SmartHomeLeave 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 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.

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

July 22, 2026August 15, 2026 Karthik & Sunil#DataPrincipal, #DataPrivacy, #DPDPAct, #InternetOfThings, #IoT, GST by K&SLeave 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 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.1.3 – Artificial Intelligence and DPDP

June 9, 2026June 9, 2026 Karthik & Sunil#AICompliance, #AIEthics, #AIGovernance, #ArtificialIntelligence, #ConsentManagement, #DataPrincipal, #DataPrincipalRights, #DataPrivacy, #DataProtection, #DPDPAct, #KarthikAndSunil, #ResponsibleAI, #WearableData, ai, artificial-intelligence, chatgpt, DPDP, dpdp-act, news, technologyLeave a comment

Meena’s Story – She Consented to Track Her Health. She Did Not Consent to Losing Her Insurance.

Meena is a 38-year-old marketing professional. Health-conscious, financially aware, and careful about her choices.

She uses a health tracking wearable — diligently logging her steps, sleep, heart rate, and diet. She consented to the health app processing this data to help her monitor her own wellbeing. That felt like a fair exchange.

What she did not know is that her health app shares data with an insurance aggregator platform. That aggregator’s AI model analyses her sleep patterns, exercise consistency, dietary choices, and heart rate variability — and produces a health risk score. When Meena applies for health insurance, she is offered a premium three times higher than her colleague who does not use a wearable.

She tracked her health to take care of herself. The algorithm used that data to price her out of coverage.

The consent problem — specific purpose, specific basis

The DPDP Act, 2023 draws a hard line on this. Section 6(1) requires consent to be specific — each processing purpose requires its own distinct consent. Meena consented to health monitoring for her personal wellness. She did not consent to health risk profiling for insurance underwriting by a third party.

The telemedicine app illustration in the DPDP Act itself makes this principle concrete: when a telemedicine app asks for consent to access the user’s mobile contact list along with health services consent, the Act declares that second element invalid because it is not necessary for the stated purpose. The principle extends directly to Meena’s situation — health data collected for personal monitoring cannot be repurposed for insurance risk scoring without a separate, specific consent for that distinct purpose.

Section 6(6) reinforces this: once consent is withdrawn, the Data Fiduciary must within a reasonable time cease — and cause its Data Processors to cease — processing that personal data. The insurance aggregator is a Data Processor. If Meena withdraws her consent from the health app, that cessation must cascade downstream.

The Puttaswamy warning — AI creates knowledge people never gave

The Supreme Court’s landmark judgment in Justice K.S. Puttaswamy (Retd.) vs Union of India (2018) contains a prescient warning, referenced in the project knowledge base: the creation of new knowledge complicates data privacy law as it involves information the individual did not possess and could not disclose, knowingly or otherwise.

Meena’s health risk score is new knowledge — created by the AI from her data, about her, that she never produced or shared. She shared step counts. The algorithm inferred cardiovascular risk. She shared sleep data. The algorithm inferred stress patterns. She shared dietary logs. The algorithm inferred metabolic risk. None of these inferences are what she consented to share. Yet each is personal data under Section 2(t) of the DPDP Act — data about an identifiable individual — and the creation and commercial use of that inferred data requires a valid processing basis.

The data security dimension — what the AI pipeline holds is a high-value target

IS Audit Module 6 of the ICAI IS Audit 3.0 Course identifies this clearly: most AI applications are based on massive volumes of data to learn and make intelligent decisions. Machine learning systems depend on data which is often sensitive and personal in nature. Due to this systematic learning, these ML systems can become prone to data breach and identity theft.

The aggregated health data pipeline that feeds Meena’s risk score — wearable data, app analytics, insurance scoring parameters — is not just a compliance liability. It is a high-value breach target. If that pipeline is compromised, the personal data of thousands of health-conscious users is exposed, along with the inferred health risk scores that the algorithm produced from it. Under Rule 6(1) of the DPDP Rules, every layer of this pipeline — encryption, access control, logs, breach detection — must be implemented. Under Rule 7, a breach must be reported to the Data Protection Board within 72 hours.

The CERT-In Guidelines on Secure Adoption and Governance of AI Systems (Version 1.0, 25 May 2026) specifically require organisations to ensure secure and compliant handling of data processed by AI systems — classifying and protecting sensitive data, defining retention and deletion policies, and monitoring AI-related data movement and third-party handling. A health data pipeline shared with an insurance aggregator, without documented data handling obligations, fails this standard.

What Meena is entitled to — and what the platform must build

Under Section 11 of the DPDP Act, Meena has the right to access a summary of all personal data being processed about her, and the identities of all Data Fiduciaries and Processors with whom it was shared. She has the right to know that her wearable data reached an insurance aggregator. She was never told.

Under Section 12, she has the right to request erasure of her personal data. That erasure must cascade to the aggregator. The health app cannot fulfil the erasure obligation without a contractual mechanism to cause downstream processors to delete as well — which Rule 6(1)(f) requires to be built into the Data Processor contract.

Under Section 13, she has the right to grieve the processing. The Data Fiduciary must respond within the prescribed period. If the platform cannot explain how her health data reached an insurance pricing model — it cannot respond to that grievance.

The question every health tech and insurtech organisation must answer

Does your data-sharing agreement with downstream AI platforms define, in writing, the specific purposes for which shared personal data may be used? Does it prohibit repurposing of health data for insurance risk scoring without separate user consent? Does it require the downstream processor to honour erasure requests? Does it include security safeguards aligned with Rule 6?

If the answer to any of these is no — Meena’s situation is not a story. It is your organisation’s next compliance exposure.

Series 2, Episode 1 — Post 3 of 3 | DPDP Meets Emerging Technologies.

Sources: DPDP Act 2023 (Sections 2(t), 6(1), 6(6), 8, 11, 12, 13) | DPDP Rules 2025 (Rules 6(1), 6(1)(f), 7) | ICAI IS Audit 3.0 Course Materials | CERT-In Guidelines on Secure Adoption and Governance of AI Systems (Version 1.0, 25 May 2026) | Justice K.S. Puttaswamy (Retd.) vs Union of India (2018)

Disclaimer

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.1 – Artificial Intelligence and DPDP: When the Algorithm Decides

June 4, 2026June 4, 2026 Karthik & Sunil#AI, #AICompliance, #AIEthics, #AIGovernance, #AlgorithmicBias, #ArtificialIntelligence, #CISO, #DataPrincipal, #DataPrincipalRights, #DataPrivacy, #DataProtection, #DigitalIndia, #DPDPAct, #DPDPCompliance, #ITCompliance, #KarthikAndSunil, #ResponsibleAILeave a comment

DPDP Series 2, Episode 1.1

Priya’s Story

The AI That Rejected Her Home Loan Without Reading Her File

Priya is a 31-year-old schoolteacher in a village in Tirunelveli. Clean credit history. Stable government salary. Zero defaults.

She applies for a home loan through a fintech platform. Within seconds, the response arrives: Rejected.

No reason. No human. No explanation. An AI credit-scoring algorithm made the call — silently, instantly, and without looking her in the eye.

She tries a second platform. Same outcome. She begins to wonder what is wrong with her, when the real question is: what is wrong with the algorithm?

Why AI credit scoring creates a DPDP problem

IS Audit Module 6 of the ICAI IS Audit 3.0 Course is direct: AI is widely used in banking apps to provide a faster, more accurate assessment of a potential borrower at less cost, accounting for a wider variety of factors. Credit scoring provided by AI is based on more complex and sophisticated rules compared to traditional systems.

More complex. More factors. And entirely invisible to Priya.

The problem is this: Priya’s loan application was rejected because the AI model had never meaningfully encountered a borrower profile like hers — a government employee in a Tier-3 city, with a savings-heavy profile and no credit card history — trained predominantly on urban, credit-card-using, high-transaction-volume data. IS Audit Module 6 names this explicitly: datasets applicable to AI applications to learn are really rare. Models trained on incomplete data produce biased outcomes for underrepresented groups.

The algorithm was not wrong about what it was trained to do. It was wrong about what it was trained on. And Priya paid the price.

The DPDP dimension — consent was not built for this

When Priya downloaded the fintech app and applied for the loan, she tapped “I Agree” to a terms-of-service document she likely did not read in full. That consent, under the DPDP Act, 2023, is not valid for everything the AI subsequently did with her data.

Section 6(1) of the DPDP Act is unambiguous: consent must be free, specific, informed, unconditional and unambiguous, limited to such personal data as is necessary for the specified purpose.

The specified purpose was loan evaluation. But the AI ingested Priya’s location history, app usage patterns, device behaviour, social interactions, and transaction metadata — far beyond what is necessary to evaluate creditworthiness. Every data element beyond the specified purpose is processing without a valid basis.

Furthermore, if her data was used to train or refine the AI model — improving the algorithm for future use — that is a separate processing purpose that required separate consent. She did not give it. Section 6(1) requires each distinct purpose to be separately consented to.

The right she did not know she had

Under Section 11 of the DPDP Act, Priya has the right to access a summary of all personal data being processed about her — including the processing activities undertaken. She has the right to ask what the algorithm used, what it concluded, and why.

Under Section 13, she has the right to raise a grievance with the Data Fiduciary. An AI system that cannot explain its decision — cannot identify what data points drove the rejection — cannot satisfy this right. A black-box model is, under DPDP, a grievance waiting to happen.

The CERT-In Guidelines on Secure Adoption and Governance of Artificial Intelligence Systems (Version 1.0, 25 May 2026) identify Human Oversight and Decision Governance as a mandatory control: validate AI-generated outputs, restrict fully autonomous critical actions, and maintain auditability and approval mechanisms. An AI that rejects a loan application with no human review and no audit trail fails every limb of this control.

The question every AI-first fintech must answer

Can you tell Priya — specifically, in relation to her file — what personal data the algorithm used, whether that data was within the scope of her consent, and how it contributed to the rejection decision?

If the answer is “our model doesn’t work that way” — the compliance gap is not in the algorithm. It is in the governance architecture around it.

The DPDP Act is not asking AI to stop working. It is asking AI to work accountably.

Disclaimer

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 Series 1.8: Penalty under DPDP Act, 2023

May 14, 2026May 14, 2026 Karthik & Sunil#Compliance, #ConsentManagement, #DataCompliance, #DataFiduciary, #DataObligations, #DataPrincipal, #DataPrivacy, #DataProcessor, #DataProtectionBoard, #DataSecurity, #DPDPAct, #DPDPPenalties, #IndiaDataLaw, #KnowYourRole, #PrivacyByDesign, #PrivacyCompliance, #SignificantDataFiduciaryLeave a comment

Penalties Under the DPDP Act, 2023

The DPDP Act establishes a clear and significant penalty framework. Penalties are imposed by the Data Protection Board of India after due inquiry, giving the accused an opportunity to be heard. The penalties are civil in nature — monetary fines, not criminal prosecution.

The Penalty Schedule

Breach	Maximum Penalty
Failure to implement security safeguards	₹250 crore
Failure to notify breach to Board or individuals	₹200 crore
Breach of children’s data obligations	₹200 crore
Breach of Significant Data Fiduciary obligations	₹150 crore
Any other provision of the Act or Rules	₹50 crore
Breach of duties by a Data Principal	₹10,000

What Factors Determine the Penalty Amount?

The Board does not automatically impose the maximum. It considers:

Nature, gravity, and duration of the breach
Sensitivity of the personal data involved
Whether the breach was repetitive
Whether any gain was made or loss avoided
Whether timely steps were taken to mitigate harm
The likely impact of the penalty on the organisation

Examples

Example 1 — Failure to Secure Data (₹250 crore) A large e-commerce platform stores millions of customer records — names, addresses, and payment details — without encryption or access controls. Hackers exploit this and steal the data. The platform had no reasonable safeguards in place. The Board finds them liable for up to ₹250 crore.

Example 2 — Failure to Report a Breach (₹200 crore) A telecom company discovers that its customer database has been compromised. Instead of notifying the Board and affected customers promptly, it delays disclosure for weeks hoping to manage the situation internally. This failure to notify attracts a penalty of up to ₹200 crore.

Example 3 — Children’s Data Violation (₹200 crore) An ed-tech platform collects data of students under 18 without obtaining verifiable parental consent. It also runs targeted advertisements directed at children on its platform. Both violations together attract a penalty of up to ₹200 crore.

Example 4 — Significant Data Fiduciary Default (₹150 crore) A major social media platform notified as a Significant Data Fiduciary fails to appoint a Data Protection Officer based in India and does not conduct its mandatory annual Data Protection Impact Assessment. The Board imposes a penalty of up to ₹150 crore.

Example 5 — Data Principal Misuse (₹10,000) An individual files repeated false complaints against a company with the Data Protection Board, with no genuine grievance. The Board finds the complaints frivolous and imposes a penalty of up to ₹10,000 on the individual.

Can the Government Go Further?

Yes. If the Board reports that penalties have been imposed on a Data Fiduciary on two or more occasions, the Central Government may direct platforms and intermediaries to block public access to that organisation’s services in India — making repeat non-compliance an existential risk for businesses.

The Key Takeaway

Penalties under the DPDP Act are not symbolic. They are substantial, scalable, and designed to deter. Compliance is not a one-time exercise — it is an ongoing obligation, and the cost of ignoring it far exceeds the cost of getting it right.

Disclaimer

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.

DPDP Series 1.7: Consent

May 14, 2026May 14, 2026 Karthik & Sunil#BusinessCompliance #ValidConsent, #ConsentManagement, #ConsentMatters, #CrossBorderData, #DataCompliance, #DataConsent, #DataFiduciary, #DataObligations, #DataPrincipal, #DataPrivacy, #DataProcessor, #DataSecurity, #DPDPAct, #IndiaDataLaw, #KnowYourRole, #PrivacyByDesign, #PrivacyCompliance, #PrivacyNotice, #SignificantDataFiduciaryLeave a comment

What is Valid Consent Under the DPDP Act?

Consent is the foundation of the DPDP Act. Before collecting or processing any personal data, a Data Fiduciary must obtain consent that meets every one of the following conditions. If even one condition is missing — the consent is invalid.

The Five Pillars of Valid Consent

Free — Consent must not be forced, pressured, or made a condition for a service where the data is not genuinely necessary. The individual must have a real choice.

Specific — Consent must be tied to a clearly defined purpose. A blanket “I agree to everything” is not valid. Each purpose requires its own consent.

Informed — The individual must know exactly what data is being collected, why it is being collected, and what their rights are — before they consent.

Unconditional — Consent cannot be bundled with unrelated terms or conditions. It must stand on its own.

Unambiguous with a Clear Affirmative Action — Silence, pre-ticked boxes, or inaction do not count as consent. The individual must actively and clearly say yes.

What is the Notice Requirement?

Before seeking consent, every Data Fiduciary must serve a Notice to the individual. This notice must be in clear, plain language — not buried in legal jargon. It must be available in English or any language listed in the Eighth Schedule of the Indian Constitution.

The Notice must contain:

What data is being collected — A clear description of the personal data proposed to be processed.

Why it is being collected — The specific purpose for which the data will be used.

How to exercise rights — A clear explanation of how the individual can access, correct, erase their data, or withdraw consent.

How to withdraw consent — The notice must explicitly tell the individual the manner in which they can withdraw consent. This is a distinct and mandatory element, separate from the general rights section.
The notice must make clear that consent is limited to data necessary for the specified purpose — the individual should understand they are not consenting to unlimited data collection. The notice must clarify that withdrawing consent will not affect the legality of processing already carried out before withdrawal — so individuals understand what withdrawal does and does not undo. For existing data collected before the Act, the notice obligation is triggered as soon as reasonably practicable — this timeline aspect was mentioned but could be more explicit.

How to complain — Details of how the individual can raise a complaint with the Data Protection Board of India.

Who to contact — Business contact information of the Data Protection Officer or a designated person who can answer questions about data processing.

What About Data Already Collected Before the Act?

If consent was obtained before the Act came into force, the Data Fiduciary must still issue a notice — as soon as reasonably practicable — informing the individual of the data held, its purpose, and how to exercise their rights going forward.

What Happens to Invalid Consent?

Any portion of consent that violates the Act is invalid to that extent. The rest of the consent may still hold — but the Data Fiduciary cannot rely on the invalid portion to justify processing.

A Practical Example

A food delivery app asks you to sign up. Before you proceed, it shows a notice stating: your name, phone number, and address will be used to deliver your orders. It tells you how to delete your account and who to contact for queries. You then tap “I Agree” — actively, not by default. That is valid consent.

If instead the app pre-ticks a box agreeing to share your data with advertising partners — that portion of consent is invalid.

Disclaimer

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.

DPDP Series 1.6: Services to Indian Individuals by Foregin Entity

May 14, 2026May 14, 2026 Karthik & Sunil#ConsentManagement, #CrossBorderData, #DataCompliance, #DataFiduciary, #DataObligations, #DataPrincipal, #DataPrivacy, #DataProcessor, #DataSecurity, #DPDPAct, #ExtraterritorialLaw, #GlobalDataPrivacy, #IndiaDataLaw, #InternationalBusiness, #KnowYourRole, #PrivacyByDesign, #PrivacyCompliance, #SignificantDataFiduciaryLeave a comment

I’m a US Citizen Providing Services to Indians. Am I Covered Under the DPDP Act?

The short answer is — Yes, very likely.

The DPDP Act, 2023 is not limited to organisations or individuals based in India. Its reach is intentionally extraterritorial, designed to protect Indian individuals regardless of where the entity collecting their data is located.

What Does the Act Say?

The Act applies to the processing of digital personal data in two scenarios:

Within India — Any personal data collected in digital form (or digitised from non-digital form) within the territory of India.

Outside India — Any processing of digital personal data outside India, if such processing is in connection with offering goods or services to individuals in India.

This second provision is what covers you directly as a US-based service provider.

Does This Apply to Me?

Ask yourself these questions:

Do you collect personal data of individuals located in India? If yes — names, email addresses, phone numbers, payment details, usage behaviour — you are processing personal data of Indian Data Principals.

Do you offer goods or services to individuals in India? If your platform, app, or service is accessible to and targeted at Indian users — even if your servers are in the US — you fall within the scope of the Act.

Do you receive payment or registrations from Indian users? If Indian individuals are signing up, subscribing, or transacting with you, you are offering services to Data Principals within India.

If your answer to any of the above is yes, the DPDP Act applies to you.

What Are Your Obligations?

As a Data Fiduciary operating from outside India, you must:

Obtain free, informed, and unambiguous consent from Indian users before collecting their data
Provide a clear notice describing what data is collected and why
Use the data only for the stated purpose
Implement reasonable security safeguards to prevent breaches
Delete the data once the purpose is served or consent is withdrawn
Report breaches to the Data Protection Board of India and affected users promptly

Are There Any Restrictions on Sending Data Back to the US?

Yes, potentially. The Central Government has the power to restrict transfer of personal data to specific countries. If India notifies the US as a restricted destination, additional compliance steps may apply before you can transfer or store Indian users’ data on US servers.

What Happens If You Don’t Comply?

Non-compliance exposes you to penalties imposed by the Data Protection Board of India — up to ₹250 crore for security failures and up to ₹200 crore for failure to report a breach. The Board has jurisdiction over processing that affects Indian Data Principals, regardless of where you are based.

Disclaimer

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.

DPDP Series 1.5: Data Breaches

May 14, 2026May 14, 2026 Karthik & Sunil#BusinessCompliance #DataBreach, #ConsentManagement, #CyberSecurity, #DataFiduciary, #DataObligations, #DataPrincipal, #DataPrivacy, #DataProcessor, #DataProtection, #DataSecurity, #DPDPAct, #KnowYourRole, #PrivacyByDesign, #PrivacyCompliance, #SignificantDataFiduciaryLeave a comment

What is a Data Breach?

A personal data breach under the DPDP Act, 2023 is any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data — that compromises its confidentiality, integrity, or availability.

In plain terms: if personal data ends up where it shouldn’t, gets changed without authorisation, or becomes inaccessible when it should be available — it is a breach.

How Does a Breach Happen?

Breaches can occur in many ways — through external attacks, internal negligence, or simple system failures.

Example 1 — Cyberattack A hospital’s patient database is hacked. Names, phone numbers, diagnoses, and medical histories of thousands of patients are stolen and published online. This is a breach of confidentiality.

Example 2 — Accidental Disclosure An HR executive accidentally emails salary slips of 500 employees to the wrong mailing list. The data was not stolen — but it was disclosed without authorisation. Still a breach.

Example 3 — Insider Threat A bank employee downloads and sells customer account details to a third party for personal gain. This is unauthorised processing — a serious breach.

Example 4 — Ransomware Attack A company’s servers are encrypted by ransomware. All customer data becomes inaccessible. Even though data was not stolen, loss of availability is a breach under the Act.

Example 5 — Third-Party Vendor Failure A Data Fiduciary shares customer data with a cloud service provider (Data Processor). The vendor suffers a security failure and the data is exposed. The Data Fiduciary remains accountable.

What Must a Data Fiduciary Do After a Breach?

The Act imposes a strict response obligation:

Notify immediately — Inform every affected Data Principal about the nature of the breach, its likely consequences, and the steps being taken to contain it.

Report to the Board — Intimate the Data Protection Board of India with full details: the root cause, timeline of events, persons responsible, mitigation measures taken, and steps to prevent recurrence.

What Are the Consequences?

Failure to implement safeguards that could have prevented the breach attracts a penalty of up to ₹250 crore. Failure to notify the Board or affected individuals attracts up to ₹200 crore — both imposed by the Data Protection Board.

The Key Takeaway

A breach is not just a hacking incident. Sending data to the wrong person, losing a device with unencrypted data, or a vendor’s server going down — all can qualify. The obligation to protect data, and to respond swiftly when things go wrong, rests squarely on the Data Fiduciary.

Disclaimer

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.

DPDP Series 1.4: Data Fiduciary – Obligations

May 14, 2026May 14, 2026 Karthik & Sunil#ConsentManagement, #DataFiduciary, #DataObligations, #DataPrincipal, #DataPrivacy, #DataProcessor, #DataSecurity, #DPDPAct, #KnowYourRole, #PrivacyByDesign, #PrivacyCompliance, #SignificantDataFiduciaryLeave a comment

Am I a Data Fiduciary? What Are My Obligations?

Q: How do I know if I am a Data Fiduciary?

If your organisation decides why and how personal data is collected and processed — you are a Data Fiduciary. This includes businesses, hospitals, schools, employers, apps, government bodies, and NGOs. Size does not matter; if you collect personal data of individuals in India, you qualify.

Q: Do I need consent before collecting data?

Yes. Before collecting any personal data, you must give the individual a clear notice describing what data is being collected and why. Consent must be free, specific, informed, and unambiguous.

Q: Can I collect more data than I need? No. You may only collect data that is necessary for the stated purpose. Collecting excess data is a violation of the Act.

Q: How long can I keep the data?

Only as long as the purpose requires. Once the purpose is served or the individual withdraws consent, you must delete the data — unless a law requires you to retain it for a specific period.

Q: What security measures must I put in place?

You must implement reasonable technical and organisational safeguards — including encryption, access controls, monitoring logs, and data backups — to prevent unauthorised access or breaches.

Q: What must I do if there is a data breach?

You must immediately notify the Data Protection Board and every affected individual, describing the nature of the breach, its likely impact, and the steps being taken to contain it.

Q: Must I have a grievance mechanism?

Yes. Every Data Fiduciary must establish an effective grievance redressal system and publish contact details of a person who can respond to Data Principal queries.

Q: What are the penalties for non-compliance?

Penalties can reach up to ₹250 crore for failure to implement security safeguards, and up to ₹200 crore for failure to report a breach — imposed by the Data Protection Board.

Disclaimer

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.

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Penalties Under the DPDP Act, 2023

The Penalty Schedule

What Factors Determine the Penalty Amount?

Examples

Can the Government Go Further?

The Key Takeaway

Share this:

Like this:

What is Valid Consent Under the DPDP Act?

The Five Pillars of Valid Consent

What is the Notice Requirement?

What About Data Already Collected Before the Act?

What Happens to Invalid Consent?

A Practical Example

Share this:

Like this:

I’m a US Citizen Providing Services to Indians. Am I Covered Under the DPDP Act?

What Does the Act Say?

Does This Apply to Me?

What Are Your Obligations?

Are There Any Restrictions on Sending Data Back to the US?

What Happens If You Don’t Comply?

Disclaimer

Share this:

Like this:

What is a Data Breach?

How Does a Breach Happen?

What Must a Data Fiduciary Do After a Breach?

What Are the Consequences?

The Key Takeaway

Share this:

Like this:

Am I a Data Fiduciary? What Are My Obligations?

Share this:

Like this: