DPDP 3.7.3: DPDP & Generative AI – She mentioned a prescription drug in a customer service chatbot. Twelve months later, she received a targeted advertisement for a competing medication. The only digital record of its relevance to her was that complaint conversation.

September 22, 2026 Karthik & Sunil#DataPrivacyIndia, #DPDPAct, #DPDPCompliance, #EmergingTechnologies, #GenerativeAI, Karthik & SunilLeave a comment

The Scenario

Kiran is a 38-year-old consumer goods marketing manager in Chennai. In October 2024, she used the customer service chatbot of a major e-commerce platform to lodge a complaint about a defective product. During the conversation, she disclosed her name, order details, delivery address, phone number, and — because the issue involved a medication she had purchased — the name of a prescription drug and the reason she needed it urgently.

Unknown to Kiran, the platform’s terms of service contained a clause stating that “conversations with our assistant may be used to improve our AI services.” This clause was buried in a sixteen-page document she had agreed to at account registration, three years before the chatbot was deployed.

Twelve months later, Kiran received a targeted advertisement for a competing medication — delivered through a third-party advertising platform — that directly corresponded to the medication she had named in her complaint conversation. She had never searched for this medication online. The only digital record of its relevance to her was the chatbot conversation.

Investigation revealed that the e-commerce platform had been using customer service conversations — including Kiran’s — as fine-tuning data for its next generation customer service AI model, and had shared anonymised conversation datasets with an advertising technology partner. The anonymisation had been superficial: name and order ID had been removed, but the medication name, delivery address, and phone number — when cross-referenced against the advertising partner’s own data — were sufficient to re-identify Kiran.

The DPDP Act Position

Kiran’s situation is the most layered of the three stories because it involves three cascading compliance failures — consent fragmentation, inadequate anonymisation, and downstream re-identification — all enabled by generative AI training practices.

First — Buried terms of service do not constitute valid consent under Section 6(1). Section 6(1) of the DPDP Act requires consent to be free, specific, informed, unconditional, and unambiguous. Rule 3 of the DPDP Rules requires the notice to be presented and understandable independently of any other information — meaning it must stand alone, in clear and plain language, without requiring the Data Principal to extract relevant information from a sixteen-page document. A clause buried in terms of service agreed to three years before a chatbot was deployed does not give specific, informed consent to the use of chatbot conversations for AI model training. These are meaningfully different processing activities and require meaningfully different consent.

Furthermore, Section 6(1) limits consent to personal data necessary for the specified purpose. Kiran agreed to an account creation purpose. The collection of her complaint conversation for AI training is a different purpose — and the personal data involved, particularly health-related information, demands its own specific consent basis.

Second — The re-identification of pseudonymised data is a personal data breach under Section 2(u). The e-commerce platform argued that the data shared with its advertising partner had been anonymised. However, true anonymisation — as recognised in IS Audit Standard 430 (Section 4.6) — means that the data cannot be linked back to an individual through any means reasonably likely to be used. Removing a name and order ID while retaining a medication name, delivery address, and phone number does not constitute anonymisation when those elements, in combination, can be cross-referenced against other datasets to identify the individual.

When the advertising partner re-identified Kiran using this cross-referencing — evidenced by the targeted advertisement — a personal data breach occurred under Section 2(u): accidental or unauthorised disclosure of personal data that compromises its confidentiality. The platform bears responsibility for this breach under Section 8(1), because the sharing with the advertising partner was processing carried out on its behalf.

Third — Health information processed without specific consent. Kiran disclosed the name of a prescription medication — personal data directly relating to her health status. This is the most sensitive category of personal data in the context of the DPDP Act’s proportionality framework. Processing it for AI model training, without a specific notice disclosing health information as a training data category, and without specific consent covering that use, is processing without a lawful basis under Section 4(1). The advertising outcome — targeted medication advertising — demonstrates that this sensitive data was not merely processed for training: it was used to drive commercial targeting that affected Kiran directly.

Fourth — Third-party data sharing as undisclosed Data Processor engagement. Section 8(2) requires that every Data Processor engaged by the Data Fiduciary process personal data only for the specified purpose under a valid contract. The advertising technology partner received Kiran’s personal data for AI training purposes. However, by using it for advertising targeting — a different purpose — it operated outside its Data Processor mandate. Under Section 8(1), the e-commerce platform bears liability for its Data Processor’s actions. The inadequacy of the Data Processor contract — which apparently did not restrict downstream use to the training purpose — is a governance failure attributable to the platform.

The CERT-In and IS Audit Dimensions

CERT-In CIGU20260002 (May 2026, Section 12, Area 7) identifies data protection and privacy in AI systems as a governance priority requiring organisations to classify and protect sensitive data, define retention and deletion policies, and monitor AI-related data flows. The platform’s failure to classify health information disclosed in service conversations as sensitive personal data — and to restrict its downstream use accordingly — is precisely the governance gap CERT-In’s framework addresses.

IS Audit Standard 430 by ICAI requires professionals conducting DPDP audits to have technical knowledge and competence covering profiling of digital personal data, pseudonymisation, and anonymisation. The distinction between true anonymisation and pseudonymisation that can be reversed through cross-referencing is a core technical competence in this standard — and a core compliance obligation for any organisation using AI training datasets derived from customer interactions.

IS Audit Standard 420 notes that data lineage, completeness, transformations, and regulatory conditions must be assessed to determine whether technology-driven analyses produce valid outputs and whether data handling meets privacy and legal expectations. Kiran’s data travelled from a chatbot conversation through anonymisation, to a training dataset, to an advertising partner, and back to Kiran in the form of a targeted advertisement — a data lineage of five steps, none of which was disclosed to her, and none of which was covered by a lawful consent.

The Compliance Fix

E-commerce platforms, AI product companies, and any organisation using customer interaction data for generative AI training must:

→ Issue separate, specific consent notices — not buried terms of service — for the use of customer interaction data for AI model training. This notice must identify: the data categories (including any health information that may arise in service conversations), the training purpose, and the identity of any downstream partners who will receive training data.

→ Apply genuine anonymisation — not pseudonymisation — to any data shared with AI training partners. IS Audit Standard 430 defines anonymisation as the removal or modification of identifiable information so that it cannot be linked back to an individual. Re-identification through cross-referencing means the anonymisation was inadequate.

→ Implement Data Processor contracts under Section 8(2) that restrict downstream partners to the training purpose only, with explicit prohibition on using training datasets for advertising targeting, profiling, or any purpose beyond the stated training objective.

→ Build data lineage tracking for all AI training pipelines: every piece of personal data entering a training pipeline must be traceable to a specific consent record, a specific data category disclosure, and a specific purpose. If the lineage cannot be demonstrated, the processing has no lawful basis.

→ Apply AI data usage controls specifically to health information — flagging, quarantining, or excluding health-related disclosures from training datasets unless specific, separate consent has been obtained for that category.

→ Treat the re-identification of pseudonymised training data as a personal data breach under Section 2(u), and implement breach notification workflows accordingly.

Kiran disclosed a medical need in a service conversation. That conversation built a model, fed an advertising engine, and returned to her as a targeted advertisement. The DPDP Act calls every step of that journey processing — and the platform was the Data Fiduciary responsible for each one.

The Central Compliance Question for Generative AI Deployments

Generative AI presents a compliance challenge that is qualitatively different from every other technology in this series. With blockchain, the problem was that data could not be deleted. With IoT, the problem was that data was collected without awareness. With RPA, the problem was that automated processing created invisible data footprints. With data analytics, the problem was that consent architectures were outpaced by analytical capability.

With generative AI, all of these problems appear simultaneously — and a new one is added: the model can generate outputs that reveal, infer, or recreate personal data that was never explicitly in its prompt. IS Audit Standard 420 (ICAI ISAS) acknowledges this directly: generative AI models are non-deterministic. Their outputs cannot always be predicted, traced, or reproduced verbatim. IS Audit 3.0 course material by ICAI identifies this mathematical uncertainty as a governance gap that organisations have not yet resolved.

The DPDP Act does not exempt non-deterministic outputs from its coverage. Every output of a generative AI system that contains personal data — however that output was generated — is a processing event subject to the Act’s full consent, notice, and accountability framework.

Every organisation deploying generative AI on personal data must therefore answer six questions before and continuously during deployment:

One. What personal data is accessible to the model as context, training data, or retrieval input? Is every data category covered by a specific, itemised notice and a lawful consent under Section 5 and Rule 3?

Two. Does the model’s output filtering architecture prevent personal data from appearing in responses to users who are not authorised to receive it?

Three. Have we conducted a DPIA under Rule 13 that specifically assesses the risk of unintended personal data surfacing in AI-generated outputs — and the risk of model outputs being used to re-identify individuals from pseudonymised inputs?

Four. Are all generative AI vendors and downstream AI processing partners governed by Section 8(2) contracts limiting them to specified purposes — with explicit restrictions on using processed data for model training, advertising, or any purpose beyond the stated scope?

Five. Do we have audit logging at the inference level — recording every query and response in a form that allows a DPDP Act compliance review or breach investigation to trace which personal data appeared in which output?

Six. Have we assessed our generative AI deployment against CERT-In’s CIGU20260002 framework for AI system security — covering prompt injection risks, sensitive data leakage, training data integrity, and adversarial threats to AI inference systems?

IS Audit 3.0 course material by ICAI frames this governance requirement clearly: AI governance must establish accountability and oversight, ensure that responsible parties have the necessary skills and expertise, and ensure that AI activities result in decisions and actions aligned with the ethical, social, and legal responsibilities of the organisation. Under the DPDP Act, those legal responsibilities include every Data Principal whose personal data touches a generative AI system.

What Responsible Generative AI and DPDP Compliance Looks Like

The organisations that will navigate generative AI responsibly under the DPDP Act are not those with the most capable models. They are those that ask the hardest questions before deployment — and build governance architectures that survive those questions.

Responsible generative AI and DPDP compliance means:

Scoping the model’s data access to what is necessary. Issuing specific notices for every processing purpose the model serves. Building output controls that prevent unintended data surfacing. Logging every inference for compliance accountability. Treating AI vendors as Data Processors with binding contracts. Conducting DPIAs before deployment, not after incidents. And applying CERT-In’s AI security framework as a complement to DPDP compliance — because the same technology that poses a compliance risk inside the organisation is simultaneously being used by adversaries to attack it from outside.

The Puttaswamy judgment (2018) described the era we live in with extraordinary prescience: humans forget, but the internet does not. Data mining and knowledge discovery processes create new knowledge about individuals — including facts they did not themselves possess. In 2018, that observation described the risks of data analytics. In 2026, it describes generative AI with even greater precision. A well-trained LLM has absorbed patterns from personal data at a scale no previous technology has matched — and can generate outputs that reflect those patterns in ways no individual who contributed that data ever anticipated or agreed to.

The DPDP Act exists to govern that reality. The compliance deadline is 13 May 2027. The governance work begins now.

The Series in Retrospect: A Unified Compliance Principle

This is the seventh and final episode of DPDP Meets Emerging Technologies. Together, the seven episodes have covered AI, Cloud Computing, Blockchain, IoT, Data Analytics, RPA, and Generative AI — seven technologies that are transforming India’s digital economy, and seven compliance frontiers that the DPDP Act governs with equal force.

Looking across all seven episodes, one principle has run through every story, every violation, and every compliance fix: technology changes the mechanism of data processing, but it does not change the law that governs it.

Blockchain made data immutable — the erasure right still applied. IoT made data collection invisible — the consent requirement still applied. RPA made data processing automated — the Data Fiduciary’s liability still applied. Data analytics made inferences from data — those inferences were still personal data. And generative AI makes outputs non-deterministic — the accountability framework still applies.

The DPDP Act, 2023 was designed precisely for this reality. It does not enumerate technologies. It governs processing — in whatever form, at whatever scale, by whatever means. The definition in Section 2(x) is deliberately broad: any wholly or partly automated operation on digital personal data. No technology sits outside it.

The Series is Complete. Seven Technologies. Seven Compliance Frontiers. One Deadline.

Over the past seven episodes, DPDP Meets Emerging Technologies has examined how the Digital Personal Data Protection Act, 2023 applies to the technologies reshaping India’s digital economy.

Episode 1 — AI and DPDP: When the algorithm decides without consent.
Episode 2 — Cloud Computing and DPDP: When your data lives on someone else’s server.
Episode 3 — Blockchain and DPDP: When the ledger never forgets.
Episode 4 — IoT and DPDP: When every device becomes a witness.
Episode 5 — Data Analytics and DPDP: When the numbers know too much.
Episode 6 — RPA and DPDP: When the bot processes more than it should.
Episode 7 — Generative AI and DPDP: When the machine learns what it should not know.

Across all seven stories, one principle remained constant: technology changes the mechanism of data processing. The DPDP Act governs the processing, regardless of mechanism.

The compliance deadline is 13 May 2027. Every Indian organisation that processes personal data through any of these technologies is already in scope — today.

If your organisation needs a DPDP compliance assessment, a technology-specific privacy architecture review, or a staff awareness programme covering these emerging technology compliance risks, we are here to help.

📩 Reach us at: karthikandsunil@karthikandsunil.in
🔗 Full series:

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.2: DPDP & Generative AI – Ananya’s Voice Note and the Deepfake That Signed a Contract

September 17, 2026 Karthik & Sunil#DataFiduciary, #DataPrivacy, #DeepfakeFraud, #DPDPAct, #GenerativeAI, #VoiceBiometrics, Karthik & SunilLeave a comment

The Scenario

Ananya is the founder of a small fintech startup in Hyderabad. In early 2025, she received a voice call from what appeared to be her bank’s relationship manager, requesting verbal authorisation to release funds from a current account for a vendor payment. The voice was familiar — warm, specific to her account, and contextually accurate. She authorised the transfer.

The call was a deepfake. An AI-generated voice, synthesised from recordings of the actual relationship manager’s previous interactions with Ananya and other clients, had been used to impersonate the banker with sufficient realism to bypass Ananya’s verification instincts. The transfer of ₹28 lakh was irreversible by the time the fraud was detected.

Investigation revealed that the relationship manager’s voice recordings — captured across customer service calls — had been exfiltrated from the bank’s call recording system in a prior data breach. Those recordings contained personal data: the manager’s voice, name, customer account references, and contextual details that made the synthesised interaction credible.

The DPDP Act Position

This scenario operates at the intersection of two DPDP Act obligations: the Data Fiduciary’s duty to prevent personal data breach, and the consequence of that breach being weaponised through generative AI.

First — Personal data breach enabling the deepfake under Section 2(u) and Section 8(5). The exfiltration of call recordings from the bank’s system was a personal data breach under Section 2(u) — unauthorised acquisition of personal data that compromised its confidentiality. Section 8(5) of the DPDP Act requires the Data Fiduciary to take reasonable security safeguards to prevent personal data breach. Rule 6 of the DPDP Rules specifies that these safeguards must include encryption or obfuscation of personal data, access controls over computer resources, and monitoring logs that enable detection of unauthorised access. If call recordings containing voice biometrics and customer account details were stored without adequate encryption, without access controls, and without monitoring — the bank failed its Section 8(5) obligation before a single deepfake was generated.

Second — Failure to classify voice biometrics as high-sensitivity personal data. Voice recordings that contain sufficient data to synthesise an individual’s voice are personal data under Section 2(t) of the DPDP Act — they are data about an identifiable individual. When used to train or feed a generative AI voice synthesis model, they become the direct input to a process that can impersonate that individual. The sensitivity of this category of personal data is therefore significantly higher than a simple audio archive might suggest, and the security architecture protecting it must reflect that sensitivity.

Third — Section 8(6) and Rule 7 breach notification failure. The prior data breach that enabled the deepfake should have triggered a notification obligation under Section 8(6) and Rule 7 — notification to the Data Protection Board and to each affected Data Principal, without delay, upon the bank becoming aware of the breach. Had notification occurred promptly, Ananya — and other customers whose interaction data was in the exfiltrated set — would have been on alert. The window for the deepfake fraud would have narrowed significantly.

Fourth — The deepfake generation itself as a further processing violation. The attacker who synthesised the relationship manager’s voice used the bank’s exfiltrated call data to train or prompt a voice generation model. Every step of that process — acquiring the recordings, training the model, generating the synthesised voice — constituted processing of personal data under Section 2(x) of the DPDP Act. This processing had no lawful basis, no consent, and no legitimate purpose. It was, by definition, unlawful processing — and the Data Fiduciary whose security failure enabled it bears legal responsibility under Section 8(5) for creating the conditions in which it occurred.

The CERT-In Dimension

CERT-In CIGU20260002 (May 2026, Section 4.2) explicitly names deepfake voice and video fraud as a primary AI-assisted threat vector, noting that AI technologies are increasingly used to generate highly convincing impersonation attempts and deepfake-enabled fraud that bypass traditional awareness-based detection due to their realism, contextual accuracy, and personalisation. Section 11 of the same document requires organisations to build deepfake and impersonation detection readiness, including verification procedures, executive impersonation monitoring, and escalation mechanisms.

Applied to banking and financial services, this means that verbal authorisation processes — for fund transfers, account changes, or contract executions — must not rely on voice alone as a verification factor in an era of generative voice synthesis. CERT-In’s framework, read alongside the DPDP Act’s security safeguard obligations, requires that financial institutions redesign their authorisation architectures to account for the synthetic impersonation risk that generative AI now makes operationally accessible to attackers.

The IS Audit Perspective

IS Audit Standard 420 (ICAI ISAS, Section 4.3) identifies opacity, embedded bias, and non-deterministic outcomes as risks specific to AI systems. In the context of voice synthesis, the opacity risk runs in two directions: the attacker’s model is opaque to the victim, and the bank’s internal monitoring was opaque to the attack. IS Audit Standard 420 requires that professionals maintain professional scepticism when using automated AI outputs and ensure that sensitive data handling meets privacy and legal requirements.

IS Audit 3.0 study material identifies data privacy and security — specifically the risk of ML systems being prone to data breach and identity theft — as a primary AI governance concern. For financial institutions, this risk now extends to the use of their customers’ and employees’ voice data as raw material for generative AI fraud.

The Compliance Fix

Banks, financial institutions, and any organisation that holds voice recordings or biometric personal data must urgently:

→ Classify all voice recordings containing sufficient data to enable voice synthesis as high-sensitivity personal data and apply maximum security standards under Rule 6: encryption at rest and in transit, access control scoped to minimum necessary, and comprehensive monitoring.

→ Implement Rule 7 breach notification workflows that specifically cover the exfiltration of voice and biometric data, with immediate notification to the Data Protection Board and affected Data Principals, without delay.

→ Redesign verbal authorisation processes for financial transactions: multi-factor authentication that cannot be bypassed by synthetic voice alone — including callback protocols, one-time codes, and out-of-band verification — must replace or supplement voice-only authorisation.

→ Build deepfake detection capabilities, as required by CERT-In CIGU20260002 (Section 11), for customer-facing and internal voice channels. AI-generated voices have detectable characteristics that real-time or near-real-time analysis can flag.

→ Train operational staff — particularly relationship managers and customer-facing teams — on the reality of AI voice synthesis fraud, the verification procedures to apply, and the escalation channels available when synthetic identity suspicion arises.

Ananya lost ₹28 lakh. The bank lost her trust. Both losses were preventable — if the bank had treated its call recording archive as the high-sensitivity personal data it was, and had built a security architecture proportionate to that sensitivity.

The compliance deadline is 13 May 2027. Voice data is personal data. Biometric impersonation through generative AI is a foreseeable risk. The DPDP Act requires organisations to design security against foreseeable risks — not merely react to them after loss.

Disclaimer

DPDP 3.5.1: DPDP and Data Analytics

August 15, 2026 Karthik & Sunil#BehaviouralProfiling, #DataAnalytics, #DataFiduciary, #DataPrivacy, #DataProcessor, #DPDPAct, #PredictiveAnalytics, Karthik & SunilLeave 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 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.3.1 : DPDP and Blockchain – Case Study 1

July 1, 2026 Karthik & Sunil#BlockChain, #BlockChainCompliance, #DataFiduciary, #DataProtection, #DPDP, #DPDPCompliance, #EraseRequest, #RightToBeForgotten, Karthik & SunilLeave a comment

“The blockchain won’t let me delete your data.” That is not a legal answer under Indian law.

Arjun resigned from his employer and asked them to erase his personal data. His HR team apologised — the data was on their blockchain-based verification system and, they said, could not be deleted.

Under Section 12(3) of the DPDP Act, 2023, every Data Principal has a statutory right to erasure. The Data Fiduciary must comply — unless retention is necessary for a specified purpose or legal obligation. The DPDP Act creates no exception for immutable ledgers.

Furthermore, Section 8(1) places non-derogable liability on the Data Fiduciary. An organisation cannot transfer that liability to its technology architecture.

IS Audit 3.0 by ICAI identifies legal and compliance uncertainty as a primary blockchain risk. Before the DPDP Act, that uncertainty was structural. Today, the law is clear.

The compliance design choices are not complicated — but they must be made at the architecture stage, not after deployment:

→ Store personal data off-chain. Record only a hash on the ledger. Delete the off-chain data on erasure request.
→ Alternatively, encrypt personal data before writing to the chain. On erasure request, delete the encryption key. The block remains — but it is unreadable.
→ For permissioned chains, build node-level governance with erasure-triggering protocols.

Arjun’s employer had an immutable ledger. However, they did not have an erasure plan. Those are two different problems — and only one of them was a technical constraint.

The DPDP Act compliance deadline is 13 May 2027. Blockchain architectures processing personal data today need an erasure design now.

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.2.3 : DPDP and Cloud – Case Study – The Erasure Request That Broke Three Clouds at Once

June 21, 2026July 1, 2026 Karthik & Sunil#CloudComputing, #DataErasure, #DataGovernance, #DataPrivacy, #DataProcessor, #DPDPAct, #DPDPCompliance, #ECommerce, #MultiCloud, #RightToBeForgotten, Karthik & SunilLeave a comment

Suresh runs the technology operations of a growing e-commerce company in Chennai. Two lakh registered customers. Three cloud vendors — one handles transactions and payments, one runs the analytics and recommendation engine, and one powers the customer support chatbot.

Each vendor has a copy of customer personal data. Some overlap. Some don’t. Suresh has never mapped exactly which data lives where.

One afternoon, a customer sends a formal email invoking her right to erasure under the DPDP Act. She has deleted her account. She wants confirmation that all her personal data has been erased.

Suresh opens his systems. He can delete her record from the primary database. He can see her in the analytics platform. He thinks she might be in the support chatbot’s conversation history. He is not sure whether the payment processor retains her card data or whether the analytics engine has derived any insights about her that are stored independently.

He has 48 hours before he must confirm erasure. He does not know where to start.

The multi-cloud erasure problem under DPDP

Section 8(7)(b) of the DPDP Act, 2023 creates the cascade obligation: when erasure is triggered — whether by purpose completion, consent withdrawal, or Data Principal request under Section 12 — the Data Fiduciary must erase the personal data and cause its Data Processors to erase the personal data made available to them.

The word “cause” is important. The obligation is not to request. It is to cause — to ensure that erasure actually occurs across every downstream processor. Suresh cannot discharge this obligation by sending an email to three vendors and hoping they comply. He must have a contractual mechanism — and a technical verification mechanism — that confirms the data has been erased.

IS Audit Module 6 identifies multi-tenancy as a specific cloud privacy risk: in a shared cloud environment, data from different customers may be commingled, creating scenarios where erasure of one customer’s data requires careful isolation to avoid affecting other tenants’ data — and equally, to ensure complete deletion rather than merely marking a record as inactive.

The Data Processor contract that Suresh does not have

Rule 6(1)(f) of the DPDP Rules requires the contract between the Data Fiduciary and every Data Processor to include appropriate provisions for taking reasonable security safeguards — which, by extension of the Act’s overall framework, includes the ability to execute erasure on instruction.

Suresh’s three vendor agreements are standard subscription contracts. None of them include a clause that obligates the vendor to erase personal data on a specific Data Principal’s request within a specified timeframe. None of them include an API endpoint for automated erasure triggering. None of them require the vendor to confirm deletion with an audit record.

Without these contractual provisions, Suresh’s erasure obligation is practically unenforceable against his own vendors. He is accountable to the Data Principal — and he has no mechanism to discharge that accountability.

The technology architecture Suresh needed to build

A DPDP-compliant multi-cloud environment for a Data Fiduciary requires a data mapping inventory — a live register of which personal data categories sit with which Data Processor, updated as the technology stack evolves. Without this map, Suresh cannot identify all the locations that must be cleared when an erasure request arrives.

It requires Data Processor contracts that include specific erasure API or webhook obligations — technical hooks that allow the Data Fiduciary’s erasure workflow to send a deletion instruction directly to each processor’s system and receive a timestamped confirmation.

It requires an erasure orchestration layer — a workflow engine that receives the Data Principal’s erasure request, identifies every processor in the data map holding that individual’s data, dispatches deletion instructions simultaneously, collects confirmations, and generates an audit trail of the completed erasure.

IS Audit Module 6 identifies cloud migration risks including insufficient planning and processes as a leading cause of cloud security failures. Suresh’s situation is exactly this: the cloud architecture was expanded incrementally without a corresponding expansion of data governance. Each new vendor added a compliance obligation that was never mapped, never contracted for, and never operationalised.

What the customer actually has the right to

Under Section 12 of the DPDP Act, Suresh’s customer has the right to erasure of her personal data unless retention is required by law. Under Section 11, she has the right to know the identities of all Data Processors with whom her data was shared. She does not need to know that Suresh has three cloud vendors — but she is legally entitled to find out.

Under Rule 8(3), personal data and processing logs must be retained for at least one year — so complete immediate erasure across all systems is not always possible. But the customer’s primary profile data, her transaction history shared with analytics, and her support conversations must be erased on schedule, with the one-year minimum applying only to logs.

The distinction between what must be retained for compliance and what must be erased on request requires data classification — another element of governance Suresh has not yet built.

The cloud is not one system. Neither is the compliance obligation.

Every Data Processor your organisation engages creates a branch of the same compliance obligation. Consent. Security safeguards. Breach notification. Erasure on instruction. Data Principal rights access. Each branch must be contractually formalised, technically implemented, and operationally testable.

The cloud makes personal data processing faster, cheaper, and more scalable. The DPDP Act ensures that those efficiencies do not come at the cost of Data Principal rights — regardless of how many cloud vendors the efficiency requires.

Sources: DPDP Act 2023 | ICAI IS Audit 3.0 Course

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.

FM Press Conference – Statutory Compliances Extension – Income Tax

March 24, 2020March 24, 2020 Karthik & SunilCovid-19, Income Tax, income tax due dates, Karthik & SunilLeave a comment

Income Tax Return of FY 2018-19 – The last date for filing extended to 30-06-2020. Interest rate for delayed payment reduced to 9% till 30-06-2020.
Delayed deposit of TDS – Interest rate reduced to 9% from 18%
Aadhar PAN linking extended 30-06-2020
Vivad Se Viswas – The date without additional 10% extended till 30-06-2020
All due dates extended till 30-06-2020 – This includes, notices, orders, statements, returns, time limit for buying tax saving investment etc will be extended till 30-06-2020

Please see the link below for the press note:

Wish you all a Happy, Healthy and Prosperous New year.

January 1, 2020 Karthik & SunilKarthik, Karthik & Sunil, SunilLeave a comment

Directors KYC – Due date Extension

May 4, 2019 Karthik & SunilComapnies Act, DIR-3 KYC, Directors, Directors Identification Nuber, Directors KYC, Due date Companies Act, Karthik & SunilLeave a comment

As per rule 12A of the Companies (Appointment and Qualification of Directors)Rules 2014, “every individual who has been allotted a Director Identification Number (DIN) as on 31st March of a financial year, has to file Form DIR-3 KYC. The due date for filing the form was 30th April of the immediate next financial year.

As per notification issued by Ministry of Corporate Affairs ( G.S.R. 339(E) dated 30th April, 2019), the due date was extended to 30th June of the immediate next financial year

Sharing of ITR data with GST Department by CBDT

May 2, 2019 Karthik & SunilAuthority, Data Exchange, Exchange of Information, GST, GST Return, GSTR details, Income Tax, ITR, ITR Details, Karthik & SunilLeave a comment

CBDT issued an order ( F. No. 225/105/2019/ITA.II dated 30th April, 2019) specifying the Income Tax authority for furnishing information in respect of assessees to the Nodal officer, GSTN.

The text of the order is given below:

Order

In exercise of powers conferred under section 138(1)(a) of the Income tax Act, 1961 (‘Act’), for purposes of sub-clause (i) of section 138(1)(a) of the Act, the Central Board of Direct taxes (‘CBDT’) hereby directs that Principal Director General of Income-tax (Systems) or Director General of Income-tax (Systems), New Delhi shall be the specified income-tax authority for furnishing information respecting assessees to the Nodal Officer, Goods and Services Tax Network (‘GSTN’).

2. The data/information to be furnished by the specified income-tax authority shall be:

(a) Request based exchange of data, wherein, important financial fields which are captured in the Income Tax Returns (ITRs) such as (i) status of filing of ITR; (ii) turnover; (iii) gross total income, (iv)turnover ratio; (v)GTI range; (vi) turnover range and (vii) any other field, the modalities of which shall be decided by the concerned specified authorities.

(b) Spontaneous exchange of data, the modalities of which shall be decided by the concerned specified authorities.

While furnishing the information, the specified income-tax authority shall form an opinion that sharing of such information is necessary for the purposes of enabling the specified authority in GSTN to perform its functions under the Goods and Services Tax.

3. To facilitate the process of furnishing information, Principal Director General of Income-tax (Systems) or Director General of Income-tax (Systems) would enter into a Memorandum of Understanding (‘MoU’) with nodal officer, GSTN, which inter-alia would include modalities of exchange of data, maintenance of confidentiality, mechanism for safe preservation of data, weeding out after usage etc. The time line for furnishing information shall also be decided by Pr. Director General of Income-tax (Systems) or Director General of Income-tax (Systems) in consultation with concerned nodal officer and included in the said MoU.

4. A copy of MoU shall be forwarded to this division for record purposes.

5. This issues with the approval of Chairman, CBDT.

A similar order is expected from CBIC also in the near future,

INC-22A – Form Active – Due date for filing extended till 15th June, 2019

April 25, 2019April 26, 2019 Karthik & SunilCompany Compliance, Company Law, Form Active, INC-22A, Karthik & Sunil, Private Limited, ROC, ROC filingLeave a comment

The government has extended the deadline for uploading photos of business premises to June 15, giving corporates more time to comply with a provision aimed at spotting shell companies.

“It has been decided to extend the date to June 15,” confirmed a corporate affairs ministry official. The same is reported in Economic Times.

This new electronic form INC 22A, which is also known as e-Form ACTIVE (Active Company Tagging Identities and Verification), was notified as part of the Companies (Incorporation) Amendment Rules, 2019 in February. If the form is filed within the due date, there is no fee, while late filing will attract a fine of Rs 10,000.

Ministry of Corporate Affairs, issued notifications regarding extension of due date for filing Form Active (INC-22A) and also changing the date of filing without any payment of fees and till 15-06-2019 and with payment of Rs.10,000/- for filing on or after 16-06-2019, by amending Companies (Incorporation) Rules, 2014 and Companies (Registration offices and Fees) Rules, 2014. Both the notification were issued on 25th April, 2019.

Source: https://economictimes.indiatimes.com & http://www.mca.gov.in

Karthik & Sunil

Chartered Accountants

Karthik & Sunil

DPDP 3.7.3: DPDP & Generative AI – She mentioned a prescription drug in a customer service chatbot. Twelve months later, she received a targeted advertisement for a competing medication. The only digital record of its relevance to her was that complaint conversation.

Like this:

DPDP 3.7.2: DPDP & Generative AI – Ananya’s Voice Note and the Deepfake That Signed a Contract

Like this:

DPDP 3.5.1: DPDP and Data Analytics

Like this:

DPDP 3.3.1 : DPDP and Blockchain – Case Study 1

Like this:

DPDP 3.2.3 : DPDP and Cloud – Case Study – The Erasure Request That Broke Three Clouds at Once

Like this:

FM Press Conference – Statutory Compliances Extension – Income Tax

Like this:

Wish you all a Happy, Healthy and Prosperous New year.

Like this:

Directors KYC – Due date Extension

Like this:

Sharing of ITR data with GST Department by CBDT

Like this:

INC-22A – Form Active – Due date for filing extended till 15th June, 2019

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: